没有银弹,量体裁衣Visual Studio Team Architect团队的敏捷软件开发之一.docVIP

没有银弹,量体裁衣Visual Studio Team Architect团队的敏捷软件开发之一.doc

  1. 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  4. 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  5. 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  6. 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  7. 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
没有银弹,量体裁衣Visual Studio Team Architect团队的敏捷软件开发之一

没有银弹,量体裁衣——Visual Studio Team Architect团队的敏捷软件开发之一 没有银弹,量体裁衣 VisualStudioTeamArchitect团队的敏捷软件开发之一 _文/RameshRajagopal译/钱量朱永泰陆榕林裕科 在黧黧 82程序员 开发团队的实践中取得不错的效果. 它的最大好处之一就是使负责某个 功能的团队在独立开发过程中有更大 自由.在工具方面,我们使用微软的 VisualStudio团队套件,充分利用这 个丰富的工具集使团队的每个成员各 司其职同时又保持高效协作.这套工 具配合我们采用的敏捷开发流程使用, 在实践中体验了卓越的价值.由于篇 幅所限,在这篇博文中我将侧重介绍 我们团队是如何进行敏捷软件开发 的,之后我将为大家介绍我们是如何 在日常工作中使用这套VisualStudio 团队套件的.我们团队负责Visual Studio系列中的Visual StudiOTeamSystem ArchitectureEdition,帮 助架构师,运营经理及开 发人员以可视化方式构 造面向服务的解决方案, 降低(软件产品开发的) 复杂度.目前我们已开 发了基于UML和DSL几 个建模工具.这基本上 是一个全新项目. 在本文后半部分和之后的文章中, 我所谈及的敏捷软件开发流程都是同 一 个功能小组所遵循的,即是我们中 国团队所遵循的. 我们中国团队主要负责开发基于 UML的核,图形设计工具,包括即将 发布的LogicalClassDesigner,Use CaseDesigner.我们所采用的敏捷开 发方法是Scrum的修改版.就如我之 前提到的,我们认为敏捷开发方法和 技术没有哪一种是万灵丹,适合自己 才是最好的.下面是一个我们敏捷软 件开发流程的概要视图: 产品待开发事项(Product ~一o=.=:O一 从产品开发来看,我们属于全球 分布式开发,团队分布在三大洲的四 个城市,包括亚洲的上海,北美洲的 雷德蒙和夏威夷,以及欧洲的剑桥. 为了尽可能减少分布式研发对团队问 交流所造成的障碍,我们尽量使功能 小组的成员集中于一地. 1-r 0 敏捷软件开发流程的概要视图 Backlog,视图的左上角)可以被视作 一 份这个团队以优先级排列的,需要完 成的功能需求单:来自相关产品利益相 关者(Stakeholders)对产品提出一系 列高端要求.例如,我们最初的要求是 为客户增加逻辑级(更抽象的)和物理 级(更靠近代码)建模提供支持,由此 衍生出高端功能需求,诸如开发在逻辑 级方便客户生成逻辑模型,兼容UML 的关系图和开发帮助创建无力模型的 DSL关系等.然后我们会对将要支持 的UML关系图种类按优先级进一步分 解(UML共有13种不同的关系图).产 品利益相关者的意见会驱动整个优先级 选择过程,最终我们得出五个最重要的 关系图:LogicalClassDiagrams,Use CaseDiagrams,SequenceDiagrams, ActivityDiagrams和Component Diagrams.于是,团队依据当时对产 品和市场的了解,以故事标题的形式完 成一份产品待开发事项.无疑,整个开 发工程中一旦要求发生变化,也会导致 需求排列优先级的变更. 在与客户的交流中,我被问得最 多的问题之一是是否需要在敏捷开发过 程中创建架构模型设计.和咨询公司一 样,我的答复也是:视情况而定.围 绕BigDesignUpfront(BDUF),发You AreNotGoingtoNeedIt(YAGNI)以及 让团队在开始实施新功能时重构现 有的代码/设计等所存在陷阱的争论也 不少,其中有不少值得借鉴.尽管如此, 我坚信设计初期存在这么一个阶段可以 尽责地做架构设计以生成高端架构.例 如,你打算建一个网上贷款流程的应用 程序,你可能需要决定在这个架构里有 几层.当然,能有这样一个基于最初要 求的,并可能随着项目进展有所变更的 架构是很重要的.在我看来,重构在敏 捷开发中有其重要地位,但是如果是变 更基础架构的大重构代价就太大了. 在我们团队所遵循的敏捷软件开 发实践过程中,我们的项目被分解成 类似Scrum的若干个四周spdn~或迭 代开发周期.尽管没有测试驱动开发 (TestDrivenDevelopment)或结对编程 fPairProgramming),但我们的开发人 员会编写单元或签入测试(Unit/Check- inTest)来检查功能,开发和测试工程 师也会在一起调试,调查或评审某个特 定问题和变更等.我们还会使用极限编 程(eXtremeProgramming)中的用户 故事(UserStory)模式.事实上,我 们的产品待开发事项和每个迭代周期中 的待开发事项(Spri

文档评论(0)

shenlan118 + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档