在敏捷开发过程中，我们还需要对系统架构进行设计吗？事实上，Martin Fowler在《Is Design Dead?》一文中已经给出了答案，那就是我们同样不能忽略对系统架构的设计。与计划性的设计（Planned Design）不同，我们需要演进式的设计（Evolutionary Design）。在敏捷开发的生命周期中，我们通过每一次迭代来丰富与更新我们的设计方案，以使其最大限度地符合客户对系统的需求。这里所指的需求，包括功能性需求和非功能性需求。

    在Agile Journal四月刊中，IBM's Methods Group的敏捷专家Scott W. Ambler详细地阐述了在敏捷语境中的架构设计方法，他提出了所谓“架构预测（Architectural Envisioning）”的方法，以应对敏捷开发中逐步演进的架构设计过程。

    Scott指出，敏捷模型驱动开发（Agile Model Driven Development，AMDD）明确地包括了初始需求分析与架构建模，这个过程发生在敏捷项目开发的第0次迭代中。所谓第0次迭代，就相当于项目的热身活动，是项目得以启动的基础。在此迭代期间，团队需要充分地理解项目的范围，甄别可行地技术策略。这个阶段所能够收集到的信息将有助于你对整个项目最初的粗略估计，以制定合适的项目计划，从而获得启动项目的资金与足够的支持。

    敏捷模型驱动开发的生命周期如下图所示：

    根据图中所示，在每次迭代的初期，制定的迭代计划都应该包括建模的工作。在此期间，可以召开建模的头脑风暴会议，讨论系统的功能特征，并思考实现这些特征的高层设计策略。大多数敏捷团队都会通过测试驱动开发（TDD）确定需求与设计的细节。

    通过对架构的预测，可以在项目早期进行一些高层次的架构建模，以助于团队与关键利益相关人商讨系统采取的技术策略。这一行为的关键目标是识别出架构策略，而不是撰写如山一般堆积的文档，从而使得你能够快速完成架构建模。其中的窍门就是尽量保持简单。开发者不需要对大量的细节进行建模，而只需要足够即可。如果你正在编写用例，意味着你只需要以标注形式列出用例的要点就足够好了。如果你正在对领域建模，可以直接在白板上绘图，或者使用CRC卡片。你的目的在于对信息的共享与交流，而不是编写细致的文档。

    如果采用架构预测的方式，你需要对哪些内容进行建模呢？Scott在文中指出有如下四部分内容需要建模：
   1. 技术图表。例如UML部署图。这些图表有助于开发者预测主要的软件和硬件组件，包括你需要访问的旧系统和数据库，系统有可能会与它们进行交互。
   2. 用户交互流程图。通过分析用户交互的主要页面/外观和报告，对系统的UI进行架构设计。如果在进行架构设计的时候不考虑用户交互界面，就可能存在潜在危机，那就是你构建的系统不是利益相关人所希望看到的。请记住，UI才是最终用户使用的系统。
   3. 领域图。在最初的架构建模中，一个重要的组成部分是对领域的高层建模。模型可以非常微小，只需要捕获主要的业务实体，以及它们之间的关系。有的人可能认为领域模型应该属于需求建模的一部分，而不是架构建模。但正如上图所示，这两者在第0次迭代中是并发进行的。
   4. 变更情形。就是在架构级需求中描述可能的技术或业务变更，而这些变更需要在未来能够提供支持。变更情形要求你考虑架构的扩展能力，但并不是过度构建你的系统。因为你只是要考虑由于变更所造成的影响，以确保你构建的系统还能够正常工作。

    架构建模是贯穿于整个项目周期的，因此这些图表就是在项目结束时形成的整体文档的基础。由于你事先明确架构是演进的，因此就不必承担架构设计在项目早期必须“正确无误”的压力，而只需要在当前形势下保证足够好就可以了。Scott建议使用白板和草稿纸等简便工具，勾勒出这些模型的初始版本。当然，如果团队成员具有熟练的建模技巧，也可以使用专门的建模工具。这一建议足以体现架构设计的敏捷性，与长篇累牍的传统架构设计方式迥然不同。

    对于这样一种架构设计方式，熟悉传统架构设计方式的架构师普遍不以为然。Scott对这一看法给与了强有力的反驳。他将架构设计场景分为三种类型。第一种是架构师熟悉系统架构设计所必需的技能与经验。既然你已经熟悉了这些内容，当然就没有必要作出完整的设计了。你只需要在白板上体现你的架构设计，保证团队的每个人都能够按照相同的体系架构进行实现就可以了。

    第二种场景是架构师对相关技巧与经验完全不知。此时，仍然只需要作少量的初始建模即可。因为你缺乏足够的知识来完成细致而又全面的架构设计，反而会因为了解不够而导致错误，从而增加项目的风险，并且阻碍了项目的进度。

    第三种场景则是架构师熟悉部分知识。这种情形也是团队开发中最常见的场景。在这种情况下，可以耗费几天时间作出一个初始的架构建模，以验证系统可能存在的风险，并制定可能策略以减轻风险可能造成的后果。你可以实现一些可工作的代码来验证架构。建模在这种情况下是非常有意义的，因为它使得你可以定义一个一致的技术愿景，为团队成员所分享，并对系统的主要问题进行思考。

    当你的团队成员是分散在各地时，或者当团队非常庞大，下面分为多个小组时，这种初始的架构建模就能够带来无与伦比的价值。它有助于在团队成员之间建立一个公共的愿景，更重要的是它能够识别出分离的组件/子系统，以及这些组件的初始接口。一旦识别出这些耦合度较低的组件或子系统，就能够合理地对团队进行分组，并保证小组之间设计与实现的一致性。

    Scott指出，所谓的“架构预测”能够提供如下价值：
    1. 提高生产力
    2. 降低技术风险
    3. 减少开发时间
    4. 增强沟通
    5. 可伸缩的敏捷软件开发。

    需要明确的是，这样的一种架构预测方式，正好符合敏捷开发迭代的需要。在项目开发早期，对系统整体进行一次高层次的概览，并对关键业务需求进行甄别与分析，划分合理的系统模块，有助于在迭代开发中为团队成员建立一个统一的标准与目标。而在每次迭代过程中，团队就可以对本次迭代期间的功能进行深入的架构建模，然后通过TDD充分理解需求，对模块的细节进行设计与实现。这是敏捷架构设计的核心操作原理，它与敏捷开发原则是一脉相承的。

本文最初发表于IT168。

---

作者介绍
张逸具有多年的软件开发与设计经验，他是两届微软最有价值专家（MVP），著作/译作包括《软件设计精要与模式》、《WCF服务编程》。张逸熟悉C#，ASP.NET，WCF等技术，同时深谙面向对象领域的相关技术。目前，他主要从事 SOA企业信息解决方案的设计与研究，以及敏捷方法的推广与实践。张逸是捷道·敏捷堂的创始人。

“敏捷方法”本为舶来品，追求的是灵活、小巧、敏捷地应对软件开发过程中的变化，而不像某些重量级开发方式那般笨拙不堪，流于形式，而忽略了软件开发的变 化万端。敏捷重思想、重精神、重原则、重实践，而轻形式、轻过程、轻方法、轻管理，讲究的是敏捷为本，交流至上，持续改进，因地制宜。若体会了敏捷思想， 只要遵循敏捷的基本原则，各种方法皆可敏捷。若未曾领会敏捷的真谛，那么即使应用了敏捷方法，也不过是“空有其形，大失其意”，终究是“画虎不成反类 犬”！

敏捷方法并非玄之又玄的“道”，不过对于国人来讲，用“道”来阐释敏捷之精神，至少可以避免陷入某种思维定势，少去许多约束与条条框框。至于如何去理解 “道”的含义，就需要实际去推行敏捷方法，从而在过程中去体悟。《敏捷之道》电子杂志荟萃了国内诸多敏捷专家或爱好者的思想体会、工作实践以及个人 认识，是发表在捷道·敏捷堂的优秀文章摘选，其目的在于推广敏捷方法的实践与运用。

本期电子杂志精选了7篇文章，分为敏捷思考、敏捷实践、敏捷方法、敏捷工具、好书推荐五个栏目。由于捷道·敏捷堂还处于草创时期，因而文章内容或有不足之处，或有偏颇之处，不过套用许多电视台的用语，那就是文中观点仅代表作者个人意见，仅供参考。文章包括：

印第安人的灵魂——敏捷回顾

印第安人在赶了3天路后，会停下来小憩一天，因为他要等着自己的灵魂跟上来。敏捷开发在经历了一次迭代或者冲刺（Sprint）后，也需要休整，以等待团队的灵魂跟上来，这一过程被称之为“敏捷回顾（Agile Retrospectives）”。

解开最后期限的镣铐
 
在大型遗留系统基础上运作重构项目

本文以ThoughtWorks中国公司与客户合作的咨询项目为背景，为读者介绍如何在一个大型遗留系统的基础上组织和运作重构项目，从而切实有效地改善系统质量。

单元测试实践小结

异地分布式敏捷软件开发

异地分布式软件开发（Distributed Software Development）是指由多个位于不同地理位置的团队进行同一个软件项目的开发过程。
 
McDonald & Scrum

Scrum是一种敏捷方法，强调快速反应，讲求人的配合等等。而其团队组织方式是多功能型，由具有各种才能的人组成足以达成既定任务的团队。 

欲善敏捷开发 先利敏捷工具

敏捷开发的潮流并不是由敏捷工具来推动的。但近年来，为了更好地支持敏捷开发，敏捷工具也有了很大的发展。

杂志下载，点击：敏捷之道第1期.rar (725.72 kb)

几天前，InfoQ发表了文章《给敏捷团队发奖金就像在刀尖上跳舞》，单从标题就可以看出其中的“惊心动魄”，显然我们需要高超的技艺，以及皮粗肉糙的脚底，就像某些非洲土著那样，方才能够游刃有余地舞动在刀尖之上。

确实如此，通过发奖金的形式来激励团队成员，本身就是一把双刃剑，弄得不好，可能就会破坏团结，导致彼此之间的矛盾与冲突，这对于一个团队而言是绝对致命的。然而，如果一个团队缺乏合理的激励方式，又无法调动成员的积极性。如何取舍，真是伤透脑筋。

看完这篇文章，我思索良久也没有寻求到一个好的答案。昨日阅读Larry L. Constantine的《人件集——人性化的软件开发》，才发现其实Constantine早已给出了答案，就在书中的第59章《受奖励的程序员》中。原来，我们为什么要受限于发奖金这样一种形式呢？套用一句俗语说，“提到钱，就难免伤感情了。”要激励团队成员以及开发团队，我们还能够寻求到很好的方式。

概括起来，Constantine提出的激励机制包括如下内容：
1、“技术玩具”。开发人员大多数都是技术型人才，一个通病就是对于技术的执著追求有时候甚至高于对金钱的追求（前题是他已经具有优裕的生活基础）。因此，一套最新的正版软件工具，或者一件当前最酷的数字产品，都会让他们欣喜不已。这种“投其所好”的馈赠方式，既没有奖励金钱那么赤裸，又能够让开发人员从内心深处激发对公司的认同与感激，真可谓两全其美。

2、小礼品。书中写道：“绝不要低估T恤衫的力量。各式各样的‘刺激’手段——团队夹克、特殊的领带、特别的杯子或者鼠标垫——都是可以使用的方法，这些，能够告诉那些取胜的团队以及团队成员：他们与别人不太一样。最好的团队还可以获得自己设计团队徽章样式的机会，并有公司负责找人生产。”这种方式或许是高层领导最愿意看到的，投入不多，却极尽蛊惑人心之能事，尤其是设计团队徽章的做法，既能够激发个人的集体荣誉感，又能够激励整个团队的战斗力。

3、自由控制的时间。这里提出的自由时间，并不是奖励成员出去旅游或者度假，而是对于那些按时交付了高质量软件的开发人员，奖励他们能够在公司的上班时间内，自由支配自己的工作，做自己感兴趣的事情（当然是与技术相关的）。例如，你可以自由自在地在没有最后期限的压力之下研究网格运算，或者神经网络，人工智能，哪怕你所在的公司实际上只是从事SAP二次开发。

Rob Thomsett说，按照他的经验，如果你把时间和钱放在一起让程序员挑选，大多数都更喜欢前者。而这类由公司赞助的研究活动，反过来对公司也是有益的，不但是获得了一位拥有新技能和新点子的快乐的开发者，而且，没准儿还能得到一个新的软件或者其他什么有用的技术。这种奖励方法对整个团队可能更有意义。如果一个项目团队显示出他们的高超的开发执行能力，当他们超越了公司建立的最好实践之上时，那么就应该对这个团队进行奖励，让他们可以无拘无束地选择研究和开发项目。

如果你的公司是一家研究型公司，或者从事产品开发，这样的奖励方式在激励成员以及团队工作热情的同时，或许还能得到意外的收获。最关键的是，这种做法无形中营造了公司的研究氛围，创造了一种良好的价值取向。

4、教育与培训机会。特别对于具有进取心的开发人员而言，获得教育或培训的机会，绝对比获得奖金更加诱人。即使管理者担心教育与培训投入的成本太高，甚至会造成人才流失的可能，那么，给团队人员一次参加技术大会的机会好了。这些大会往往都是免费的，开发人员需要获得的仅仅是你的一个许可而已。然而，已经足见你的栽培之心了。Constantine还说道：“报销书籍和杂志费用也是一种低费用的激励方式”。管理者们，你们看到了吗？

5、选择团队成员的权利。权利也是一种奖励。例如让他主持一次会议，或者提供监督别人的机会，都是一种廉价的权利，但有可能得到的回报却很丰厚。最好的权利就是允许团队成员能够挑选自己认可的合作者。书中提到：“一旦一个小组已经学会了如何协同工作，为什么要把他们分开呢？对于那些能够高效开发的团队，奖励方法之一就是让他们在下一个项目中继续共同工作。对这个方法进行一个推广，那么，我们可以让他们自行挑选工作伙伴，这种行为可以有效地激励员工，使他们能够达到最好的工作效果。同理，让那些在上一批项目中干得最好的团队，在下一批项目中自由选择员工，对他们来说，也是一种奖励。”还有什么比这个更加廉价的奖励。

除了以上提到的五点之外，Cockburn在《敏捷软件开发》一书中，还提到了Darin Cummins发明的一种开发游戏的奖励方式，奖励一些类似于代金券之类的伪币，然后在项目结束后，利用这些伪币来竞拍一些真正适用的物品。关键不是这个结果，而是开发中的过程，对于成员的奖励就像玩游戏一般轻松自在，不知不觉就剥去了成员的功利之心，有效地消除成员之间的恶性竞争。

Darin写道：“开发人员会因为他们的代码被评审、评审其他人的代码、按照进度完成任务、重用代码以及创建单元测试等得到奖励”。要消除成员之间的恶性竞争，这种方法一定要遵循两点。第一是将过程尽可能最小化，这样的度量会更加准确与透明，不会出现太大的分歧。第二则是给参与者反败为胜的机会。可以在开发过程的结尾，设计一些额外的活动来让开发人员赚取更多的奖励。这样一来，即使开发人员在前面输得太多，他仍然有机会在后程发力，反败为胜。

适当的奖励可以让我们踢开刀刃，自在轻舞，但必须还要谨记如下两个原则：
1、在奖励优秀的开发人员的同时，不要忘记对优秀团队的奖励；
2、奖励方式应因人而异，必须最大程度地投合员工的喜好。

因此，在对你的团队以及员工进行奖励之前，最好先询问他们究竟喜欢什么，也许你能够以最小的投入换来最大的回报。坦白说，有时候上级也需要好好考虑如何对下级“拍马屁”呢。

本文最初发表于IT168。

---

作者介绍
张逸具有多年的软件开发与设计经验，他是两届微软最有价值专家（MVP），著作/译作包括《软件设计精要与模式》、《WCF服务编程》。张逸熟悉C#，ASP.NET，WCF等技术，同时深谙面向对象领域的相关技术。目前，他主要从事 SOA企业信息解决方案的设计与研究，以及敏捷方法的推广与实践。张逸是捷道·敏捷堂的创始人。

印第安人在赶了3天路后，会停下来小憩一天，因为他要等着自己的灵魂跟上来。敏捷开发在经历了一次迭代或者冲刺（Sprint）后，也需要休整，以等待团队的灵魂跟上来，这一过程被称之为“敏捷回顾（Agile Retrospectives）”。敏捷回顾与项目总结会议不同，它并非项目结束之后的盖棺论定，而是在项目过程中，通过回顾会议及时总结上一次迭代中的得与失，以期达到改进项目开发、团队合作等敏捷活动的目的。

如果将项目开发比作是一次征途，那么在项目中期的短期休整是很有必要的。然而这种休整并非是将团队成员集体拉出去腐败一次，或者到K厅去鬼哭狼嚎一番，以泄心中的郁闷，如此种种只能说是身体心灵的休息与放松。就像是运动员在比赛期间，队医的按摩、擦汗的毛巾、解渴的饮料。这些重要吗？当然重要，放松疲惫的身体与心灵，方能更好地走向更远的目标。但更重要的是灵魂的“反刍”，就像教练员针对运动员在上一局比赛的盘点与指导，指出选手以及对手的优与劣，从而制定出后面比赛的对策，方能把握取胜之钥。

敏捷回顾不是一场没有主题的讨论会，大家坐下来，七嘴八舌漫无目的的一阵“乱弹”，这样的形式对于项目进展没有任何帮助。Scrum对于回顾有一个主要指导原则，这也是敏捷回顾的“最高指导原则”：
无论我们发现了什么，考虑到当时的已知情况、个人的技术水平和能力、可用的资源，以及手上的状况，我们理解并坚信：每个人对自己的工作都已全力以赴。

听起来，有些像一团和气的“和稀泥”做法，这样的原则会否让回顾会议的参与者一个个都变成好好先生呢？难道我们一定要善意地评价团队中的害群之马，对他们的过错视而不见，使其“逍遥法外”，并天真地以为我们的好心能够感化他们？难道我们要在项目开发中建立一个乌托邦式的大同世界，同薪同酬，为了团队利益而抹煞团队成员之间的个体差异。

坦白说，我反对在进行团队成员评价时，采用这么一条“最高指导原则”，但这样的看法已经偏离了攻击的靶子了。需要知道，“最高指导原则”是应用在敏捷回顾中，而敏捷回顾的最终目的是学习，而不是绩效评审活动[1]。

如果敏捷回顾没有确定这条“最高指导原则”，用来倡议团队成员信任自己的伙伴，就会让回顾会议成为互相攻讦、互相推诿的批斗大会，忘记了我们召开回顾会议的初衷。“最高指导原则”就是为回顾会议竖立一个标杆，那就是在项目开发中没有破坏者，没有替罪羊，没有关键人物，只有整个团队的利益。虽然某个人或许在上一次迭代中出现了错误，但我们会善意地相信此人之所以犯下错误，并非有意为之，或者消极怠工，而是囿于当时之识见、经验、技能。我们的回顾会议必须指明这些错误，并试图总结出最佳实践以避免在下一次迭代中犯下同样的错误，而“最高指导原则”则能够消除因为错误的指出而给成员带来的负疚感，消除同事之间可能因此出现的隔阂与误解。换句话说，回顾会议提出的所有批评都应该是“对事不对人”。

我曾经在一个项目的回顾会议上，听到了测试经理对于某开发小组产品质量的评价，认为该小组开发的模块出现了太多的bug。经过回顾会议的认真分析，最后得出的结论是该小组Leader迫于进度压力，因而盲目地追求开发进度，却忽略了保障代码质量的单元测试覆盖率。于是，我们仔细讨论了下一次Sprint的Sprint Backlog，根据团队成员的能力进行了合理的分配。果然，在下一次Sprint中，该小组开发的模块出现的bug率降低了差不多50%，即使bug总量并不大，这样的比例仍然是非常可观的。而且，由于项目组成员都明白回顾会议的原则，因此并没有产生团队成员之间的不快，开发人员和测试人员仍然能够合作得非常愉快。

在《Scrum Checklists》中，指明了Scrum回顾会议的议程：
1、在白板上写上主要指导原则；
2、在白板上画上一个至少三页纸连在一起长的时间轴；
3、在白板上写上“我们的成功经验是什么”；
4、在白板上写上“有什么能够改进”；
5、在白板上写上“谁负责”，然后分成两个区域——“团队”和“公司”。

从以上的步骤可以看出，敏捷回顾的主要工作就是明确目标、持续改进、处理问题。敏捷开发之所以采用迭代的方式，实际上是利用蚕食方式逐步完成开发任务。将一个宏伟的目标切割为一个个小目标，会给与团队成员更大的信心，并能够更加清晰地明确目标。而每次迭代后的回顾，则使得团队成员可以更加清晰地明确我们在这个征途中，已经走到了哪里，未来还有多远的路程，就像印第安人那样，等待自己的灵魂，否则就会不知身在何处了。

在项目中持续改进至关重要。所谓“取其精华，去其糟粕”，唯有如此方能够去芜存菁，提高敏捷团队的战斗力。每一个敏捷团队都不可能是十全十美的，要么是在技术上存在个体差异，要么就是缺乏足够的领域知识，或者，还未曾找到符合团队现状的开发方法（即使采用敏捷方法，也需要因地制宜，切忌生搬硬套。即使现在符合，也不等于永远符合，即使符合这个项目，却未必符合下一个项目。敏捷方法不可能放之四海而皆准）。即使这些均已具备，那么团队成员之间的磨合也并非一朝一夕之功。若没有持续改进，团队就会像生锈的刀刃，不仅会褪去摄人的光芒，还会逐渐钝化腐朽。

在项目过程中，有一个原则是处理问题越早，那么付出的代价与成本就越小。问题是，当我们在紧张的开发任务中，有时候很难发现这些错误，更加意识不到这些错误会带来严重的影响。通过回顾会议，利用团队成员互相善意地“敲击”对方，或者反复“锻炼”开发过程与方法，就能够让每一位成员都炼就“火眼金睛”。在会议中，我们经常会发现，一旦某个成员发现了一个问题，接踵而来的就是每个成员都会发现一大堆问题。

发现问题仅仅是第一步，我们还要在回顾会议中合理分析这些问题出现的原因、所属类别，并因此划定问题的“责任田”。我们要明确这些问题是团队内部的，还是由于外在因素导致的，也就是说要明确“责任田”的归属，指定处理人和处理时间。

此外，《敏捷回顾——让团队从优秀到卓越》一书的作者Esther Derby在接受InfoQ的采访时，还提到：“使用回顾来解决冲突问题。他们在每个迭代中都进行检视、实验，并构建解决冲突的技能和信心。随着时间推移，他们学会了如何处理每个团队都会发生的“平常的”冲突。当大家意见出现严重分歧时，他们有能力、也有信心在团队内部解决问题。而且更有利的是，由于他们可以在团队内部解决全部问题，他们的经理就可以花费更多的时间来消除组织中对团队造成的障碍。当然，这使得团队能够轻装上阵，以更加轻松的心态来开发软件。”[2]

现在，在你的项目团队经历了一次艰难的迭代之后，你需要休息一下以等待灵魂的到来么？那么，就请尝试一下敏捷回顾会议吧，或许你会从中得到意想不到的收获。

[1] Linda Rising，敏捷回顾活动“最高指导原则”答疑解惑
[2] Deborah Hartmann，图书节选：敏捷回顾——让团队从优秀到卓越

---

作者介绍
张逸具有多年的软件开发与设计经验，他是两届微软最有价值专家（MVP），著作/译作包括《软件设计精要与模式》、《WCF服务编程》。张逸熟悉C#，ASP.NET，WCF等技术，同时深谙面向对象领域的相关技术。目前，他主要从事 SOA企业信息解决方案的设计与研究，以及敏捷方法的推广与实践。张逸是捷道·敏捷堂的创始人。