敏捷开发是如何被跑偏的

今天聊聊敏捷软件过程。

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

与你们一般的认知是相反的，敏捷过程并非一个很是容易实践或者实施的过程规范。

一般来说，没有天上掉馅饼的事儿，因此使用敏捷软件过程带来灵活性收益的同时，必定是要付出相应的代价的。

例如：

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

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

敏捷过程实施起来其实仍是有一些难度的。有一些团队准备实施按部就班的策略：针对敏捷过程所要求的一些最佳实践，先上一些比较容易实施的，而后在陆续加入其余。

使人失望的是，这样的作法也会引起一些问题。就拿很是流行的极限编程来说，极限编程所要求的最佳实践其实是相互循环依赖的！因此仅仅选择某几项最佳实践来进行实施的话，最终会致使整个系统的崩溃！好比：

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

因而，有很多团队在实行了敏捷软件过程以后，仍然停留在（或者说倒退回了）游击队式的野生软件开发过程。

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

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

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