【破门点滴】敏捷究竟需要什么？

“简单、清楚的目的和原理引起了复杂、智能的行为，
复杂的规则和制度引起了简单、愚蠢的行为”
——（Dee Hock 1994）Visa International 前CEO，
他在职期间使Visa全年收益由7.5亿美金增长到650亿美金。

从贯彻敏捷原理的角度来说，过度强调对敏捷实践的严格执行其实反而会与敏捷背道而驰。因此任何一个团队准备引入敏捷方法之前，必须要从最本质的角度即敏捷原理来考察自己的项目（客户、团队和资源），确定是否要执行敏捷方法以及具体采用那些敏捷实践。那么敏捷方法所依据的核心原理是什么呢？实践敏捷究竟需要做到什么呢？本文谈谈敏捷原理以及一些实践应用体会。

破门

2007年5月17日

1        交付有用的产品

敏捷团队必须时刻提醒自己，软件项目的目标就是向客户交付有用的产品。如果没有能上线的系统产品，无论你怎么强调你的团队实力、项目的进展，从最本质的角度来看，没有可用的产品，项目就是失败的！“必须把红旗插在山头上！不然，死多少人都没有用！”——这是我在一个项目中客户领导对我说过的话。

因此，敏捷方法学首先考虑这个原理提供了一系列非常有用的实践。

1.1 现场客户

在集成公司做过项目的朋友们绝大多数都应该经历过现场开发了，客户总是希望能够与开发人员面对面的交流，并且他们希望能在出现问题的时候第一时间找到能够解决问题的人。现场开发让客户以为能够很好地解决上面两个问题。但实际上，效果可能并不如客户所想像。

这里的问题其实就是软件项目最初遇到的难题，需求获取和实现。现场开发项目往往将全部的精力放在满足用户需求方面了，但是谁又能保证说满足项目中说了算的那个客户提出的需求就是对产品最有用的呢？

这个实践就是要解决如果最快速提供有用的产品，必须满足需求你不满足肯定不行，但是全部的需求都去满足也肯定不行。因此，敏捷方法在这里要求现场客户的用意就是要时刻保持与客户的沟通，以便确定最合适的需求范围，让团队能否高效运作，用最小的代价提供出有用的产品。

1.2 小发布

敏捷方法要求最短时间内发布可用的产品，小发布是十分有效的实践。要实践小发布就必须有大幅裁剪需求的能力，结合现场客户实践，可以更有效地定义小发布需要实现的特性，并且保证每次发布的产品都包含有实际可用的用户价值。

因为小，所以简单。如何将大的需求和系统变小却是一门需要经验和胆量的学问。当你没办法决定的时候，直觉也许是最可靠的了。没有什么需要担心，反正每次的发布都很小，所以改变方向起来也容易J

小发布是敏捷方法响应和控制需求变化的有效机制，第一时间将系统发布给现场客户或是最终用户，就可以在第一时间获取反馈，从而降低需求变化对系统带来的冲击。

1.3 测试优先

测试优先是敏捷方法广为接受的实践了，先按照测试框架编写单元测试，再为系统添加实现的代码，可以有效防止过度设计。让程序员们自然而然的把注意力集中到提供客户价值上，而不是将精力泛滥在无边无际的代码技巧之中。

完善的测试也为系统重构提供有效的屏障，检验系统的重构是否成功的标准仍然是系统是否有效地提供用户价值。

1.4 持续集成

持续集成为项目提供了基线，为小发布提供便捷。每时每刻项目都有保障通过测试并且可以运行的系统。再也不需要为准备发布而辛苦地熬夜、匆忙地测试、混乱地运行，然后准备迎接无数的系统bug的煎熬了。持续集成让这些过程每时每刻都在项目中自动有序地进行着。

发布只需要从集成服务器上取出最新完成的版本就可以了。

2        依赖于人和协作

软件项目的成功依赖于人和协作，在这点上没有人能否认。传统软件方法也是想尽一切办法来加强协作的效率以及消除人对项目的负面影响。敏捷方法则从另一角度来强调要发挥人的积极因素以及强调直接的交流来提高协作效率，传统的标准化管理流程和基于文档的协作对于快速变化的项目要求已经明显不能适应。因此，敏捷方法重新回到了发挥人和团队潜力的方向。任何系统和过程的适应能力都无法与人来比，因此，充分发挥团队的个人和协作能力，就能够得到最高的效率和最好的效果。

2.1 白板

白板是敏捷项目团队必备的利器，没有白板的团队是无法想像的。

在白板前面站立着的时候就是思维最活跃的时候，因为谁也。敏捷团队最常采用的方法就是所谓头脑风暴法，大家针对目标主题在白板前讨论，将所有能想到的概念、方法、词句统统写到白板上，很快行之有效的解决方案就会突然之间出现在大家面前了。

2.2 站立会议

站着开会往往效率更高，目标更加清晰。每天团队之间需要时时刻刻保持高效的交流。夸张点说，敏捷团队的工作室往往更像一个热闹闹的市集。安静的环境并不一定就是软件开发最高效的环境。

2.3 PP

结对编程是提高个人效率非常有效的实践，人们往往说做什么都最好有个伴。巡警执勤，飞行战斗编队，拉力赛车，都是两两组合的生动案例。软件开发中的结对编程要求更高，两个人同时坐在电脑前面完成一个任务，一个人负责实际操作，另外一个人负责即时审查，任何需要的时候两人都可以互换角色。在PP对不同角色的名称来说，更类似拉力赛车手。

即时审查、点对点压力、即时沟通、目标导向、知识传播，结对编程的好处不用在这里一一细数了。结对编程是将协作效率发挥到极致的实践，不过认真执行它还真需要勇于尝试，甚至需要强制性的约束。

2.4 不加班

加班是否真的无法避免？至少我经历的项目还没有不加班的时候，有时候是必须，有些时候则是自愿，反正我个人是没办法做到每天8个小时满负荷运转然后每周只工作5天。作为一个典型的中国程序员，我进入工作状态以及从工作状态中退出都需要不少时间。不过身体状态的确是一天不如一天，这也许是中国程序员的编程生命周期普遍比欧美短的重要原因吧。

这个实践，只有真正的高手才能做到罢。用中国的古语来说：静如处子，动如脱兔。能够有效地控制自己工作状态的人，谁敢说他不是高手？因此，对于这个实践，我的建议是反过来考虑，努力不断地尝试控制自己的状态，应该算是向高手迈进的一个有效途径吧J。

3        做尽可能简单的事情

我个人认为敏捷原理中最核心的原理就是简单了。一句话，简单可不简单！复杂、厚重的方法自然是称不上敏捷的。因此，敏捷就是做尽可能简单的事情。简单的事情才有把握和可能去做好。当项目中无数简单的事情都被做好以后，它必然就是一个不简单的成功项目了。

3.1 将尽可能多的工作丢弃不做的艺术

简单是将尽可能多的工作丢弃不做的艺术。在开始动手之前，要问问自己和团队，如果我不做这件事情，会发生什么情况呢？会失去什么呢？

敏捷方法会帮助我们来确定哪些工作是可能丢弃的，反过来说，丢弃尽可能多的工作，你所使用的方法就尽可能地趋于敏捷了。这也是一个不断迭代和进步的过程。

3.2 更少的文档

敏捷方法最先倡导的一个实践就是丢弃繁重的文档，只用最少的时间和代价来记录需求、设计和会议。文档的目的也是为了交流，当团队或者客户能面对面交流的时候，我们就不要写文档，直接面对面讨论，然后用简单的方法记录下结论，尽快去落实执行。

3.3 简单设计

简单设计的目标依然是为了减少工作，在没有清晰地理解需求和目标之前，我们不去做那些前置设计工作。换句话说，只针对已知的需求设计和实现。这是敏捷方法能够快速适应的重要实践经验，设计的不足可以用不断的重构来弥补。重构设计的驱动过程也是针对变动的需求来的，只不过是针对进一步了解的更多已知需求来设计和实现，为此我们要对原先的设计进行调整和优化。

3.4 目标和特征驱动

敏捷方法中需要不断调整的内容就是阶段目标，因此我们采用快速迭代的过程，每次迭代都针对特定的功能需求和系统目标，在这点上敏捷也是特征驱动的。这同样也符合交付有用的产品原理。

4        结语

敏捷方法学提倡是知之而用的实践精神，所有的敏捷方法都是实践驱动的。因此认真地学习和理解敏捷原理才有助于我们理解敏捷实践规则背后的相互关系。我们仅仅是引入几条敏捷实践不能说就是实践了敏捷方法，而要看我们项目实施是否时刻贯彻了敏捷原理的精神，针对项目的实际需要选择甚至创造出最适合团队和项目环境的敏捷实践，每个敏捷团队和敏捷项目都拥有自己独特的敏捷方法。