敏捷开发是如何被跑偏的

今天聊聊敏捷软件过程。

先说结论：据我观察，至少有60%的团队误用了敏捷软件过程，或者说至少60%的团队在进行伪敏捷开发。

与大家通常的认知是相反的，敏捷过程并不是一个非常容易实践或者实施的过程规范。

通常来讲，没有天上掉馅饼的事儿，所以使用敏捷软件过程带来灵活性收益的同时，一定是要付出相应的代价的。

例如：

1. 如果需要实行结对编程，那么在选择团队成员的时候就需要考虑人员的性格特质，或者增加相应的培训和团建活动；
2. 如果需要实行测试驱动开发，则要求团队成员对于自动化测试的技术掌握更加熟练和深入；
3. 如果需要进行快速设计，则会对开发人员的设计经验有一定的要求，并同时未来一定要有进行重构的时间安排才可以；
4. 等等其它

最终，你会发现：如果一个团队没有能力实施传统的软件开发过程的话，则他们多半也无法很好的实施敏捷软件过程……

敏捷过程实施起来其实还是有一些难度的。有一些团队准备实施循序渐进的策略：针对敏捷过程所要求的一些最佳实践，先上一些比较容易实施的，然后在陆续加入其他。

令人失望的是，这样的做法也会引发一些问题。就拿非常流行的极限编程来讲，极限编程所要求的最佳实践实际上是相互循环依赖的！所以仅仅选择某几项最佳实践来进行实施的话，最终会导致整个系统的崩溃！比如：

1. 极限编程讲究的是快速设计，但是其最终的设计合理性和最优性是由CRC讨论会和后续的重构动作来保证的；
2. 极限编程省略了冗长的需求分析文档，代之以即用即抛的“用户故事”；但是为了保证功能的正确性，他会有一个更加严峻的要求：现场客户；
3. 极限编程没有专门的测试阶段，那么如何保证产品的质量呢？辅助以三个最佳实践：结对、测试先行和持续集成；
4. 重构动作保证了架构的最优化，但是谁来保证重构不会对系统带来负面影响呢？测试先行和持续集成；
5. 类似的等等

于是，有不少团队在实行了敏捷软件过程之后，仍然停留在（或者说倒退回了）游击队式的野生软件开发过程。

那么如何才能够正确的实施敏捷开发过程呢？我理解，至少需要具备如下的前提，才能够比较顺利的实施敏捷过程：

1. 团队成员对面向对象的开发和设计有相当程度的理解和经验（最起码有想要提高或者学习的需求）；
2. 团队成员能够熟练的使用自动化测试的框架，并编写自动化测试脚本；
3. 团队成员能够熟练的使用持续集成的框架或者产品；
4. 团队成员平均沟通能力中上，没有表达能力低下者；
5. 至少有一个渠道能和客户（或者有足够话语权的客户代表）进行频繁并流畅的沟通；
6. 管理者（包括甲方客户）和开发团队之间有相对比较平等的话语权；
7. 管理者（包括甲方客户）能够理解（或者信任）开发团队所提出的一些隐性的工作量（例如重构、编写文档、测试脚本等）所带来的时间成本；

上述看似并不太高的门槛，却挡住了60%的软件开发工程师……