1. Scrum敏捷框架

1.1 Scrum概述
Scrum是一种敏捷过程，它使用迭代和增量方式管理和控制复杂的软件与产品开发。Scrum的开发流程非常简单。首先，Product Owner根据客户的需求编写Product Backlog，然后召开计划会议，评估各项功能的相对工作量，并确定Sprint的愿景和目标，生成Sprint Backlog。然后，在Sprint（即迭代）的开发过程中，召开每日会议，Scrum Master通过它了解开发的进展以及出现的问题，检查团队成员的工作与进度。迭代结束后，团队会召开评审会议，向项目关系人展示可运行的增量版本，并检查是否达到了Sprint的目标。评审会议之后的回顾会议则会总结以往的实践经验，以提高团队生产力。

Scrum的核心在于迭代。团队首先浏览开发需求，考虑可用技术，并对自身技术及能力做出评估。然后共同确定构建功能的方案，并每日调整方法，以应对新的复杂问题、困难和出乎意料的情况。团队找出并选择最佳方案去完成任务。此创造性过程便是Scrum生产力的核心[1]。Scrum的所有实践就是围绕着一个迭代和增量的过程开展的。

1.2 Scrum的不足

与XP（eXtreme Programming，极限编程）不同，Scrum并没有提供核心的价值观与指导原则，也缺乏具体的实践方法，例如结队编程、测试驱动开发。Scrum仅仅规定了实施的基本流程与检查表，它是一个开放的管理框架，重心在于项目管理，而不是指导团队成员如何进行开发。这既是Scrum的优点，因为它很灵活，能够适应大多数场景，也可以兼容并包地引入其他方法学所提倡的实践；同时也是Scrum存在的固有缺陷，使得它难以被实践。如果没有一位优秀的Scrum Master，而团队成员又缺乏自我组织和管理的能力，就会让开发过程变得一团糟，团队成员将会无所适从。

在开发实践方面，Scrum可以借鉴XP提倡的结队编程以及测试驱动开发实现编码，通过重构对编码进行调整以适应需求的变化。但是，Scrum在建模方面却是一片空白。例如，Scrum对于如何创建Product Backlog，如何建立架构模型，以及如何在编码之前进行必要的模型设计，都没有给出具体的解决方案。缺乏正确的建模活动，就可能会对Scrum开发过程造成阻碍，影响团队达成Sprint的目标。

2. 敏捷建模与Scrum的契合

敏捷建模（Agile Modeling）是一个基于实践的建模方法，包括一系列以特定原则和价值为导向的，可被软件专业人员应用到日常工作中的实际做法[2]。敏捷建模有效地将建模敏捷化，利用敏捷方法的思想对传统的建模理念进行了重新梳理，使其更加适用于敏捷开发。敏捷建模描述了一种建模的风格。当它应用于敏捷的环境中时，能够提高开发的质量和速度，同时避免过度简化和不切实际的期望。

敏捷建模可以弥补Scrum在建模方面的不足。如果说Scrum是一个对开发过程的所有活动进行了规定的基本框架，则敏捷建模由于其对建模活动的核心关注，极大地丰富和增强了Scrum的软件过程。建模在所有的软件开发中都是不可缺少的一个重要环节。传统的建模活动，常常会重视对文档与工具的使用，要求创建的模型涵盖软件开发过程的方方面面。这种重量级的建模活动与敏捷开发方法在核心思想上是相悖的。敏捷方法需要敏捷的建模，Scrum自然也不例外。

敏捷建模定义了一组与轻量级的建模有关的价值观、原则和实践，并说明如何把它们付诸实施。本文将从敏捷建模的价值观、核心原则和核心实践三个方面讨论敏捷建模与Scrum的契合。

2.1 敏捷建模的价值观与Scrum的契合

敏捷建模的价值观包括交流、简单、反馈、勇气和谦虚。前面四条来自于XP的价值观，但完全可以说是敏捷开发的价值观。敏捷软件开发宣言强调与客户交流和团队的合作。宣言对可工作软件的重视甚于详尽的文档，凸现了简单的价值观。宣言对变更的重视体现了反馈的重要性，以及拥抱变化的勇气。Scrum同样体现了敏捷建模的第五条原则——谦虚。Scrum将整个团队定义为一种角色，作为一个整体负责将Sprint Backlog转化为可运行的产品。在开发过程中，团队成员需要管理自身的工作，同时对每次迭代和整个项目共同负责。如果没有谦虚的精神，Scrum的团队是无法运作的。

2.2 敏捷建模的核心原则与Scrum的契合

敏捷建模提出了十一条核心原则。Ambler认为，只有完全采纳这些原则，才能真正地宣称自己在进行敏捷建模。Scrum虽然没有提出具体的指导原则，但在Scrum框架和实施流程中，仍然体现了部分敏捷建模的核心原则。表1展现了在Scrum项目中敏捷建模核心原则的适用性。

表1  在Scrum项目中敏捷建模核心原则的适用性

2.3 敏捷建模的核心实践与Scrum的契合

敏捷建模的精华在于它的实践，但敏捷建模的实践是在价值观和原则指引下体现的。它的核心实践分为四类，即迭代和增量建模、团队协作、简单性和验证。实际上，敏捷建模的实践并没有超出敏捷开发的范围之外，只不过它的关注对象被界定为建模活动而已。因此，敏捷建模的实践完全可以应用在Scrum的开发过程中。

迭代和增量建模实践与Scrum完全吻合，因为Scrum本身就是一种迭代和增量开发。既然建模活动贯穿整个项目开发周期，因而建模采用迭代与增量的方式自然顺理成章。Scrum定义了团队角色，从而突出了团队成员的协作，成员作为一个整体参与到软件开发过程中。在Scrum中，每个成员都可能是建模人员，例如Product Owner对需求进行建模，对用户界面进行建模，团队成员对设计进行建模。简单性实践要求建模人员使用最简单的工具，创建简单的内容，简单地描述模型。归根结底，模型只需要传达它应该展现的内容，不管是需求分析，还是架构设计，都应该尽可能地保持简单，既不需要考虑格式，也不需要考虑完整，甚至可以丢弃那些已经实现了的模型。Scrum大量使用了白板、索引卡、即时贴等简单工具，创建的模型非常简单，甚至是临时的。Scrum同样重视对产品的验证，避免出现错误或与需求产生偏差。

3. 贯穿Scrum敏捷过程的敏捷建模

3.1 Scrum软件生命周期

Scrum并没有明确划分项目开发过程的阶段，而是将几种会议（计划会议、评审会议和回顾会议）定义为软件开发的里程碑。如果借用软件生命周期的概念，我们可以将Scrum划分为初始阶段、计划阶段、冲刺阶段与发布阶段。初始阶段的活动主要包括组建团队、准备资源和编写Product Backlog。计划阶段包括了Sprint的两次计划会议。冲刺阶段即一个完整的Sprint迭代，周期通常不超过六个星期。发布阶段包括评审会议与回顾会议。此阶段结束后，将发布一个达到Sprint目标的增量版本。至于产品的维护，则属于Product Backlog的一部分，列入每次迭代的范围。

3.2 初始阶段的敏捷建模

Product Backlog的编写与建模活动息息相关。Product Backlog是Scrum的核心，也是一切的起源。从根本上说，它就是一个需求、或故事、或特性等组成的列表，按照重要性的级别进行了排序。它里面包含的是客户想要的东西，并用客户的术语加以描述[3]。编写Product Backlog就是对需求进行建模。根据敏捷建模“主张简单”的原则，我们在描述Backlog的条目时，通常借鉴XP对用户故事的描述方式，而不是采用用例驱动的模式。可以使用Excel工具来创建一个Backlog表。敏捷建模认为“内容比形式更重要”，在表示Backlog时，我们甚至可以使用即时贴，将其展示在白板上，使每个人都能直接看到需求模型。
编写Product Backlog时，项目的利益相关人必须积极参与，和Product Owner一起确定Backlog的条目以及优先级。Product Backlog应该能够“包容变化”，Product Owner通过与项目关系人的讨论，可以增加新的功能，或者根据新的需求变化对其进行修改。根据敏捷建模的“多种模型”核心原则，我们也可以在Product Backlog基础上，使用用例模型或用户界面模型，帮助说明Backlog的业务流程，促进开发人员对需求的理解。

3.3 计划阶段的敏捷建模

计划阶段仅仅包括两次计划会议，每次计划会议大约持续四个小时。第一个计划会议主要确定Sprint的目标以及Sprint Backlog。第二个计划会议则需要确定Sprint Backlog中每个任务的承担人，并根据实际情况裁减Sprint Backlog，生成最终的Sprint Backlog。
敏捷建模认为，项目关系人应积极参与到需求建模活动中。Scrum负责需求建模的主要是Product Owner和客户。在计划会议中，Product Owner必须出席会议，以便对Backlog的需求条目进行解释，帮助团队理解需求。

敏捷建模的核心实践要求“与他人一起建模”。在计划会议中，团队常常会对功能需求进行拆分，其目的主要是为了更容易对工作量进行估算，但另一方面也是对需求的一种细化。一种最佳实践是将需求条目细分为任务。任务与需求条目的区别在于，需求条目属于可交付的内容，是Product Owner以及他所代表的利益相关人所关心的。而任务则不可交付，它常常代表了分析、建模、编码、测试等实现需求条目的各个环节。在拆分任务期间，并不会真正开展建模活动，但团队成员在了解到需求的具体细节时，实际上已经开始考虑需求的实现。

计划会议会对Sprint Backlog进行工作量估算。Scrum建议发挥集体的智慧。方法是利用计划纸牌。团队中的每个人都可以在深思熟虑之后，出示自己手里的纸牌，根据出示纸牌的数值取平均值，就可以大致获得该需求条目的工作量。这种方式符合敏捷建模“简单”的价值观。在讨论Sprint Backlog的需求细节时，则可以使用索引卡。根据每个需求的重要程度与优先级依次将索引卡张贴在墙上。索引卡属于敏捷建模的临时模型，在失去价值之后可以考虑丢弃，而只保留更新后的Sprint Backlog。

3.4 冲刺阶段的敏捷建模

整个冲刺阶段就是一个迭代周期，即一次Sprint。在 Sprint的开始阶段，我们可以根据Sprint Backlog建立一个任务列表模型，以及一个能够直观反映开发进度和开发效率的Burndown（燃尽）模型，并形成一个任务板。任务板要尽量简单，只需要保留必要的列。Scrum要求召开站立的每日会议，通常就在任务板前完成。团队成员一边描述昨天已经做的和今天要做的事情，一边移动任务板上对应的即时贴。每日会议结束，则任务模型也随之更新，最后由Scrum Master负责更新Sprint Backlog和Burndown模型。

在冲刺阶段引入敏捷建模非常必要，它有助于解决团队在开发过程中遇到的需求、设计以及开发方面的问题。一个方法是召集相关人员举行简短的设计会议，这在敏捷建模中称为专门或即兴建模会议。通常的流程是：首先与项目关系人探讨相关的需求，可能需要创建基本用户界面模型或者讨论业务规则的逻辑；随后继续前进讨论这些需求潜在的解决方案，这时常常会画一张白板草图来帮助讨论；再往后就是继续前进编码并测试这个解决方案[4]。

Scrum团队没有设计人员、建模人员和编码人员之间的区别，它是自组织、自管理的团队。团队的每一个成员都具有项目中所有方面的参与权力，不存在单一的团队成员对系统架构、需求或者测试负责的情况[5]。这正是敏捷建模“有效团队协作的实践”的运用。
在冲刺阶段，通过引入敏捷建模，我们可以在开发过程中创建架构模型、类结构模型和测试用例模型等内容。根据项目的实际情况，我们可以选择使用UML建模工具，或直接利用简单的白板工具创建架构模型，利用CRC卡展现类的结构模型。我们还可以借助一些需求模型以及用户界面模型，深入对需求的理解。

3.5 发布阶段的敏捷建模

Scrum评审会议实际上就是一次增量产品的演示和发布。在进行Sprint演示时，需要确保清晰阐述了Sprint目标，并让演示关注于业务层次，而不要考虑技术细节。如果我们在冲刺阶段严格地遵循了持续集成原则，就可以在每次Sprint之后发布一个增量版本，供用户使用。这实际上是“快速反馈”和“包容变化”核心原则的体现。通过每次迭代发布的版本，可以及时获得客户的反馈，验证实现是否与需求相符。如果出现偏差，或者客户提出新的建议和变化，就可以将其列入到下次Sprint的范围和目标中。

回顾会议在Scrum中是一项特殊的活动。审视和适应的能力是Scrum的基础，这也是开展回顾会议的目的。在回顾会议期间，项目团队会分析Sprint中的成功经验和遇到的障碍。Scrum回顾会议不会涉及建模活动，但它对于敏捷建模而言却具有促进作用，因为我们可以在回顾会议中总结敏捷建模应用的得与失。例如我们可以讨论建模活动是否过于复杂，是否需要引入其它的建模工具，哪些模型属于临时模型或契约模型。简而言之，在回顾会议中，我们可以检查团队的建模活动是否背离了敏捷建模的价值观、原则和实践。

4. 结束语

在Scrum项目中，建模活动仍然属于必不可少的一个环节，但却是很多Scrum实践容易忽视或轻视的一部分。Scrum敏捷框架的不足主要体现于此。如果将敏捷建模的价值观、原则与实践应用到Scrum的整个开发过程中，将有利于规范Scrum的建模活动。二者的关系是框架与细节的有机契合。Scrum提供了一个基础的框架，对敏捷开发过程中的所有活动进行了规定，而敏捷建模的重点则是全部软件过程的一部分，因而需要与另一个完整的过程结合，以增强这些过程。敏捷建模是Scrum的有效补充，在Scrum中实施敏捷建模，能够提高Scrum的可操作性，并在建模活动方面给与指导与规范。敏捷建模帮助Scrum团队找到建模的最佳点，保证我们既进行了足够的建模，以保证有效地研究和记录系统，但又没有过多地建模以致变成减慢项目进展的负担。

参考文献
[1] Ken Schwaber. Agile Project Management with Scrum[M]. 上海：世界图书出版公司，2007：6.
[2] 王毅嘉，张为群. 一种基于UML和敏捷建模的JEMM方法研究[J]. 西南师范大学学报（自然科学版），2005，30（3）：426.
[3] Henrik Kniberg. Scrum and XP from the Trenches[M/OL].C4Media,2008, http://infoq.com/minibooks/scrum-xp-from-the-trenches
[4] Scott W Ambler. 敏捷建模——极限编程和统一过程的有效实践[M]. 张嘉路，朱鹏，程宾,译. 北京：机械工业出版社，2003：120.
[5] Robert C Martin. 敏捷软件开发——原则、模式与实践[M]. 邓辉,译.北京：清华大学出版社，2003：7.

极限编程中有一条著名的懒汉原则，称之为KISS原则，KISS是Keep it simple and stupid的缩写。简略地说，就是设计尽量保证简单。极限编程坚持只为今天的需求设计以及编码，而不用考虑明天。这颇有一些“做一天和尚撞一天钟”的意味。

这个原则带来一个问题，那就是我们还需要设计吗？

我们强调设计，其目的就在于设计出合理、优雅的结构，以提供具有良好复用性与可扩展性的系统，这是一种未雨绸缪，为未来考虑。而现在，我们若要遵循KISS原则，就是不再考虑明天的需求。显然，这两者的观点是相悖的。于是，矛盾出现：一方面我们需要保持设计简单，不做无谓的功能预测；另一方面，我们又需要拥抱变化，在尽可能少的改变结构与代码的情况之下，满足未来的需求。

如何解决这个矛盾。让我们先看看提出简单原则的初衷。在《敏捷开发思想之拥抱变化》一篇中，我提到需求的变化是不可避免的。即使是最优秀的需求分析师和架构设计师都不可能在项目之初穷尽所有客户要求的功能，作出最完美的分析与设计，即做到“增之一分则太多，减之一分则太少”。我们需要把握分析和设计的“度”。但事实却是，我们总喜欢越俎代庖，利用自己的经验帮助客户提出需求，而事后证明这些需求往往是多余的。我们总是在重复做着“吃力不讨好”的事情，与其如此，还不如在事先偷懒取巧。因为需求的变化总是不可控的，根据“利益趋避原则”，自然应选择对自己更有利的一个趋向。

但这种简单并不是“简陋”，即使我们不需要考虑明天的需求，一些好的重用原则与可扩展原则仍然需要遵循。例如，我们应尽量保证对象是高内聚、低耦合的；我们应遵循“面向接口编程”原则。一言以蔽之，我们需要做到：
1、减少依赖；
2、合理抽象；
3、功能最简。

简单设计还需要重构来保证设计的质量。我们之所以敢于奢谈“简单”，正是因为重构的保障。即使设计过于粗陋，合理利用重构也能够亡羊补牢。在重构过程中，我们仍然需要遵循简单原则，仅为当前的需求对系统结构进行重构。例如，我们在最初的需求分析中，只有一个功能要求发送电子邮件。那么，我们可以编写一个方法来封装发送电子邮件的实现，这个方法甚至可以放在业务对象的私有方法中。随着需求的逐步演进，新增的几个功能同样需要发送电子邮件，此时就有必要利用重构技术，将原来发送电子邮件的方法独立到单独的类中。但是，基于简单原则，我们没有必要完善所有功能，例如增加发送Meet Request的功能。因为目前的需求并不需要。

“简单”并不只限于设计。在敏捷开发过程中，我们还需要保证项目计划的简单，以及文档的简单，乃至于过程的简单。项目计划的简单可以由小步行进的迭代周期来保证，通过对项目阶段的分解，简化项目计划。至于文档的简单，我们完全可以抛弃复杂标准的文档模板，转而书写仅仅是自己需要关注的内容。至少，项目内部的文档完全可以言之有物，而不需要注重形式。我们还可以通过对项目过程进行裁剪，来保障过程的简单性。事实上，在极限编程中，很多原则和实践都是为了实现简单而提出的。例如计划游戏、小版本、简单设计，包括持续集成和代码所有权，都是为了提高开发过程的效率，这实际上也是简单的一种体现。

“简单最好”是一种心态，更是一条原则。

最佳的架构、需求和设计出自于自组织的团队。蜂巢中的工蜂们看似忙碌，但其工作却是有序而有效，归根结底就是它们的组织架构其实是自我组织的。在自我组织的团队中，团队是一个整体，没有角色之分、职位之分、也没有高下之分。团队成员的任务不是项目经理强加于身，而是根据自己的愿望和能力对任务进行合理评估，并主动进行领取。被动与主动所产生的驱动力显然不可同日而语。

自我组织的团队是一个平行的组织，由于没有管理与被管理之间的关系，因而氛围更加和谐，组织更加开放，管理更加松散，这种自由化的组织方式更容易让团队成员体现自我价值，对团队会产生一种认同感，促发他们的开发热情，从而提高开发效率。平等的关系会促进团队成员的有效沟通，自由的管理有助于发挥团队成员的技术特长，开放的平台则能够保证协作的效率。一个卓越的团队应该是目标一致，团结协作，同时又能各司其职，有条不紊。

自我组织的团队建立在团队个人能力的基础之上。它其实是一把双刃剑。如果团队成员个人能力有限，或者自我约束能力较差，而管理人员又无法把握松散管理的度，就很可能出现一些问题。例如：
1、团队人员无所适从，不知道该做什么。很多开发人员对敏捷方法不能适应，他们已经习惯了听从命令与安排的方式；
2、任务安排不平衡，团队成员在开发过程中偷工减料。耽于安逸的开发人员或许会利用管理的漏洞或管理人员对他的信任，胡乱估计任务的工作量，或者夸大任务实现的难度；
3、自由失去节制，无论是技术方案的讨论和评审，还是任务工作量的评估，因为没有绝对权威，很容易失去控制，因纠缠于细节而让大量的讨论浪费时间。

如何解决这三个问题？对于第一个问题，基本无解，除非你有足够的煽动力或超凡的演讲能力，改变这些开发人员的思想，乃至于开发习惯。最佳方式是循序渐进，并对自我组织的方式进行改进，例如和传统的管理方式结合起来。或者就放弃敏捷的管理方式吧。如果说敏捷是鱼，只能在水中生活，你怎么能让它上岸呢？

对于第二个问题，需要动用团队的力量。例如对任务的评估，我们可以利用计划游戏，或者设计计划纸牌对任务工作量进行估算。总之，我们应尽量让团队对任务工作量的估算不要出现太大的偏差，使任务的开发在可控的范围内。此外，即使召开回顾会议，也是杜绝这类问题的一件利器。

第三个问题需要团队的管理者建立某些准则，例如对技术问题的讨论设定时间的限制。一旦超出该时间，就应该把问题放在一边，或者由管理者利用自己的权威和经验下定结论，而不能无限制的争执下去。

自我组织的团队管理者需要因时因人而置宜。Larry L. Constantine在《人件集》中提到：“对于开放型的团队来说，最好的领导应该表现得像他们中的一个同事一样，能够参与所有的技术问题讨论，包括分析、设计和系统构建。”例如在Scrum中，团队角色就是一个自我组织的团队，由团队来确定每个Sprint的工作内容。而Scrum Master就不再是控制者，而是指导者；不是上司，而是教练。他必须理解自组织团队的重要性。

自我组织是敏捷管理的精髓，也是敏捷管理成败的关键！

秉承敏捷宣言的精神（个体与交付重于过程和工具；可用的软件重于完备的文档；客户协作重于合同谈判；响应变化重于遵循计划），我认为，敏捷开发大致应该体现如下的思想：拥抱变化、自我组织、简单最好、客户至上、有效沟通、精益求精。

1、拥抱变化

Kent Beck和Martin Fowler在介绍极限编程（eXtreme Programming）时，最先提到的就是要拥抱变化。这基本上代表了敏捷阵营对于变化的一种态度，那就是不拒绝，而且还要主动求变。有一句经典的论断说得好：“在软件开发领域中，唯一的不变就是变化。”其实，不仅仅是软件开发领域，世间万事万物都处在永恒的变化之中，这是宇宙的基本规律。奥巴马在竞选美国总统的时候，提出的口号就是“变化”。变化才是真正的常态。

传统的软件开发过程由于过分强调文档的完整，重视与客户的谈判与签订合同。所以，开发团队最希望的一件事情是冻结需求规格说明书。只要双方签字，需求就确定下来，不可更改。若要更改，必须经过需求变更委员会，走非常严格的需求变更流程。如果软件开发真能如此，倒也算是我们开发人员的幸事。但现实总是残酷的，需求总是会变化。变化的原因有以下几种：
1）业务发生了变化；
2）客户对业务的理解发生了变化；
3）需求分析人员对需求的理解出现了偏差，需要修正。

对于第一点，或许我们还能够根据合同与客户讨价还价，而对于后两点，尤其是第三点，我们显然是不可拒绝的。而敏捷方法则要求团队随时响应客户的需求，针对变化给出相应的解决方案。

如何拥抱变化呢？我想可以通过如下方式来实现：
1）现场客户

很多开发团队并不喜欢客户对他们指手画脚，甚至认为他们不停提出的需求变化让他们疲于应对。但现场客户给团队开发带来的益处还是要远远超过他带来的坏处。无论团队中聚集了多么权威的领域专家，但真正了解客户需求的还是客户自己。也许他们很难用语言来表述自己的想法，但有了和现场客户的及时沟通，我们才能够在发生变化的初始就能够获得第一手的资讯。如果事情总要发生，早解决绝对比晚解决要好，而且要好得多。

如果在开发中，没有办法让客户成为团队的一员，那么我们也应该指定一位客户代表，退而求其次，也应该在团队中指定一位业务专家负责业务事宜，也就是Scrum中Product Owner的角色。总之，我们需要在项目开发中，能够让开发人员在对需求理解发生困惑时，能够明确地知道由谁来负责。而一旦需求发生变化，也必须有专门的角色负责向整个团队或者相关人士传达。至于业务功能的优先级和重要程度排定，也必须由这个角色指定。

2）定期迭代和小版本交付

不仅要定期迭代，而且要尽可能地让迭代周期短，并及时交付可以工作的小版本发布。XP的迭代周期通常为一周，而发布一个小版本大约是一个月。而Scrum则将迭代称之为Sprint，持续时间推荐为一个月。Sprint结束就需要向客户展示当前迭代完成的版本。

敏捷方法绝对不可闭门造车，因为需求总是可能存在二义性，且需求总是处于不断的变化中。若能定期交付一个可以工作的小版本，一方面可以给与开发团队和客户以信心，另一方面也有助于我们及时获得客户的反馈。而衍生带来的还有一个好处是我们可以免费找到最优秀的测试人员了，那就是我们的客户。如果没有现场客户，则小版本的交付则显得尤为重要，因为它给了我们及早修订错误的机会。

3）持续改进

开发过程总是会出现错误，无论是开发方法、技能，还是团队管理与团队合作。持续地改进我们的开发方法、管理方法与开发过程，才能够及时而有效地解决错误，避免重蹈覆辙。一个能够持续改进的团队是一个成长的团队，同时必然会是一个拥抱变化的团队。

在Scrum中，每个Sprint完成并结束了评审会议之后，都会召开一个回顾会议，即使总结优秀经验，检讨错误与教训，团队方能够从错误中成长起来。此外，回顾会议还能够帮助团队正确地认识自己，帮助团队成员进行交流与沟通。作为“鸡”角色的客户若能参加回顾会议，可以让客户更直观地了解团队，比提出自己的看法，有助于在后面的开发过程改善合作的质量。

敬请期待第二篇《敏捷开发思想之自我组织》

站立会议对于Scrum的意义，就像我们每天早上起来总是希望看看报纸，听听新闻，了解每日时事，关心国计民生。站立会议有助于Scrum Master以及整个团队了解项目进展情况，以便于控制项目进度，掌握团队成员的开发效率，促进成员之间的交流与沟通，并使所有成员对整个项目能有一个全面的认识。

站立会议的重要性不言而喻。如何遵循Scrum的原则开展好每天的站立会议呢？我在推行的Scrum实践中，发现站立会议总是会随着项目的进展，慢慢地发生变形，最后甚至会变得物事人非。幸运的是，每日的会议却没有理由地达成了Scrum的目的。那么，在Scrum开展站立会议是否一定要极为死板地遵循Scrum的原则？我认为未必。以下是我在推行Scrum过程中的一些粗浅认识。

More...

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

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

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

——敏捷回顾之“最高指导原则”

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

More...

我在阅读Ken Schwaber所著的《Agile Project Management with Scrum》一书，就对ScrumMaster的其中一个职责抱有怀疑的态度。Scrum要求ScrumMaster保证开发人员在一个Sprint（冲 刺）过程中，不受到其他无关人员尤其是上司们的干扰。真的能做到这一点吗？即使ScrumMaster通过有效地与Product Owner沟通，确定了Product Backlog；然后我们开启了一个Sprint，并确认了Sprint Backlog；然而，根据客户的需求，一旦需求发生变更，我们还能保证Sprint不受到这一变更的影响吗？

More...

在InfoQ发表的一篇文章《实施TDD时的常见问题》中， Chad Meyers提出了关于TDD实施的问题，如下所示：

1. 我该容忍多大限度的预先设计？你怎么知道应该何时停止（也就是说，“当人们开始讨论算法，就是该测试的时机了”）？
2. 对于象“我心里清楚我们需要这个”这类东西——我们该如何处理（例如，在控制台main()方法中加上一个try/catch{Console.WriteLine(ex);}？）
3. 编写测试时，为了让代码编译通过，你不得不写下一两个接口，一个实体类，在类中还有一些NotImplementedExceptions等等。这一步该走多远？
4. 如果在测试一个用户故事期间，你发现先前的预先设计有问题，你是会马上停下来跟你的搭档讨论，做该做的事，然后继续；还是折返回去，在当前的故事中采用完整的测试优先模式？
5. 在处理一个新的用户故事时，你发现针对前一个故事所编写的测试已经不再体现需求。你是否会立刻重构那个测试，还是把它标记为“忽略”，等你完成当前的故事再回过头去处理那个被忽略的测试？还是有其它做法？
6. 如果新的用户故事要求对某个已有的测试做出轻微调整，你是会调整它，还是会写一个新测试，把旧的扔掉（也就是，“不许更改现有的测试代码！”，或者“只有出现小的编译问题时才准动它，否则就别碰！”）？
7. 如 果你构建了模型并且通过了测试，但是你发现这个设计很幼稚，而且即将要做的用户故事肯定会对其进行重大修改，并生成一个新的完全不同的模型。你是应该退 一步，考虑进行大型重构吗？还是应该继续修修补补，调整现有的模型，尽管这个模型最终会被目前看来显然超出该用户故事范围的工作所改进？

More...

    在敏捷开发过程中，我们还需要对系统架构进行设计吗？事实上，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次迭代，就相当于项目的热 身活动，是项目得以启动的基础。在此迭代期间，团队需要充分地理解项目的范围，甄别可行地技术策略。这个阶段所能够收集到的信息将有助于你对整个项目最初 的粗略估计，以制定合适的项目计划，从而获得启动项目的资金与足够的支持。

More...