[破门点滴]当敏捷遇到过程

这份文档也是酝酿了很久，想对自己长久以来一直未能全面贯彻执行一次敏捷开发项目的遗憾做个分析和小结，另外从自己亲身的体会来对比一下敏捷开发与传统开发过程的文化冲突，期望能对各位支持敏捷开发和支持传统过程的同好有所帮助或提示。

破门

2007年5月6日于深圳

引言

自从2002年接触XP（极限编程）以来本人一直自封为敏捷开发爱好者，也算是国内第一批拥护和支持敏捷开发的程序员。不过一方面对于自己在敏捷开发的推广方面无所作为感到惭愧，另一方面则对于一直未能在一个实际项目中彻底地贯彻一次敏捷开发实践感到遗憾。去年又一次在合作型项目中亲身经历敏捷开发与传统过程的文化冲突，便有了认真总结一下的想法，本文算是开个头，也希望各位同行一起来探讨一下。

让我们还是先从“敏捷宣言”说起吧。

敏捷宣言

2001年2月11日到13日，在美国犹他州Wasatch山的滑雪圣地Snowbird的一幢大楼里，17位轻量级过程专家通过这次会议形成了敏捷软件开发运动，其中包括了：极限编程（eXtreme Programming, XP）、Scrum、动态系统开发方法（Dynamic Systems Development Method，DSDM）、自适应软件开发（Adaptive Software Development，ASD）、Crystal方法、特性驱动方法（Feature-Driven Development，FDD）、实用程序设计等。会议的结果是17名与会者共同签署并发布了“敏捷软件开发宣言”（The Manifesto for Agile Software Development）,宣告：

“ 我们通过实践寻找开发软件的更好方法，并帮助其他人使用这些方法。通过这一工作我们得到以下结论：

• 个体和交流胜于过程和工具

• 工作软件胜于综合文档

• 客户协作胜于洽谈协议

• 回应变革胜于照计划行事”

敏捷方法实践者

敏捷宣言中明确提出了四个核心观点，是否能够正确地贯彻执行这四个核心点决定了一个项目是否真正使用了敏捷方法——当然也包括了XP。事实上，这也是我本人最支持的四个观点，抛开对具体实践规则的执行程度——比如 结对编程（Pair Programming, PP）等XP实践，我还是可以比较自豪地宣称自己的确是一个敏捷方法实践者 :)。

管理和交流

敏捷文化认为传统过程在编织一个美丽的神话，那就是存在所谓的“银弹”——只要有良好的过程和管理，可以不用关注开发人员的技能提高。“我们需要软件蓝领！”自从我接触到CMM这类的过程文化的时候，就认为这个提法伤害着我作为程序员或者软件工程师的自尊，这也是为何极限编程从一开始就引发我狂热激情的根本原因。敏捷文化从根本就是程序员的文化，再次揭示了一个简单的却被管理者们忽视的根本事实——软件是人开发出来的！ 忽视了开发人员的素质提升，用过程屏蔽开发团队之间的交流，如何获得优秀的软件产品？

过程文化支持者们肯定会说，没有细致的管理规则和作业指导书，无法降低软件的开发成本，到哪里找那么多高手？软件开发过程的产生就是要降低对“牛仔”的依赖。这个观点我是接受的，在实践敏捷方法的初期，团队素质带来的困难是最大的。不过矫枉过正是人们常犯的错误，当过程文化过渡依赖过程神话的时候，初期对“牛仔”的依赖是不见了，“银弹”却产生了。最终，还是要依靠团队的某个超牛的“牛仔”来挽救项目危机。

我现实经历的无数个项目，都是依靠我们团队中的高手来渡过难关，俗称“救火队员”。他们才是我眼中的“银弹”，哦，偶的神哪，你敢说他们是什么蓝领？软件项目依靠蓝领和过程就够了？

我们要认真地体味敏捷文化的精髓，那就是依靠团队的交流，快速提升个人素质，抓住软件项目管理的实质，那就是人和协作——我们的软件开发团队。

文档和软件

过程文化中最让程序员们反感的就是铺天盖地的文档了，与之对应，敏捷文化中最受争议的部分自然也是对于文档的大刀阔斧的裁减了。程序员对文档的厌恶几乎是与生俱来的本能反应，简单的说，程序员应该就是写程序的，如果每天要花大量的时间在那些看起来没有人真正关注的文档上，简直就是无聊，或者直白地说有点“不务正业”了！

但是过程文化强调文档的原因也不是无依据的，以往程序“牛仔”们留下的一堆看不懂的代码，以及那些几乎无法维护的系统，是文档显得无比重要的根本原因了。我本人也亲身体验了无数次重新翻写整个系统的痛苦经历，用程序员的话讲，“让我改他的代码，那还不如重写”。

所以，就这个问题上，敏捷文化其实是支持文档的，不过所谓“矫枉必须过正”。过程文化带来的过度文档顽疾要解决，就必须用刺激性的办法。敏捷文化强调最小化文档，或者干脆不要文档（好的测试和代码就是最好的文档），让团队把目标重心重新放到正确的地方——那就是可以工作的软件系统上来。

协调和控制

过程文化对于客户价值的概括几乎完全依赖于前期分析，那份可以改上一千遍的《需求分析说明书》。我见过最猛的一个项目是花了整整一年的时间，将《需求分析说明书》出到11.0版本，然后还没有正式开始编码。

反之，我自己引入敏捷文化最成功的一个项目则是在一个1kw级别上软件系统开发过程中，先提交了运行版本后才提交给客户了一个《需求分析说明书》0.8版本。事实上，两个项目都是在客户现场开发的。不过在后者的启动阶段，我花了3个月的时间向用户和监理公司介绍极限编程XP的概念和应用，最终成功说服了客户，放弃了监理公司关于项目采用CMM2管理体系的建议。而最终用户对项目参与程度也是我经历的所有项目中最高的，我把这点看作这个项目最重要的推进因素。

而刚过去的半年，我们则遭遇了历史上最糟糕的项目管理模式，我被迫采用了商务谈判的手段来尝试解决纷争，几乎就让项目彻底沉入深渊。最终，还是派出“救火队员”依赖我们的经验和痛苦的加班加点来缓解问题。这样的项目，无论对任何人来讲，都是绝对的痛苦！事实上，只要我们的合作伙伴公司与客户的交流更深入一点，完全可以避免类似的项目风险。每次都对客户的需求简单理解，对客户要求的进度简单承诺，累积下来，自然失去客户信任，项目自然无法成功。

需求和进度

上面的话题已经谈到关于客户需求的问题，关于需求，敏捷文化的核心观点用XP的实践精神来说就是——拥抱变革。而在这方面过程文化遭遇的难题可以用一句俗语概括——“计划没有变化快”！

不是吗？用户的需求什么时候反馈的最多？就是你告诉用户“我们开发完成了，系统可以开始使用了”的那一天。因此，敏捷文化和过程文化都强调对用户需求的理解，同时也强调对需求的分析处理。不过由于双方的核心观点区别也就带来了在具体处理方式上的不同。过程文化强调对需求的精确分析，强调详细的计划，因为这样才能准确的贯彻过程体系，但是谁又能保障对需求的准确把握和精确分析呢？没有人可以。

因此，敏捷文化一开始就承认，客户的需求是不断变化的，双方的有效互动可以降低需求变化带来的风险。让客户参与进来，只关注已经确认无误的特性，不过度设计，不考虑那些明天可能会抛弃的东西（You aren’t gonna need it！，YAGNI）。

通过小发布加快用户需求反馈的进度，同时每次发布可工作软件系统都包括可以真正使用的用户特性，也就是包含有用户价值，这是敏捷文化中发布系统区别于快速原型的重要一点。夸张点说，从第一发布开始，用户已经不是“一无所有”了，他们已经看到和拥有了可以工作的系统！这解释了为什么引入敏捷文化后最终用户往往更具有耐心和信任度。

究竟谁更简单？

用这个问题来作为本文的结束，其实朋友们心中早就有答案了。

这个问题实际上是在问：软件系统开发简单么？答案自然是——不简单！

世界上没有真正意义上简单的东西。

因此，敏捷开发方法和过程开发方法都是不简单的。敏捷文化诞生过程中有无数的关于“没有银弹”的文章和讨论。所以，我在这里还是想告诉一些朋友们，无论你支持何种文化，都不要用简单来作为支持自己观点的论据。

无论你采用传统开发过程还是敏捷开发方法，在软件的道路上，大家依然任重道远。

让我们支持敏捷宣言的核心精神——“通过实践寻找开发软件的更好方法”！