敏捷开发的常见问题

1. 技术负债在敏捷团队中会快速的膨胀。 

是事实，但这并不是敏捷本身的问题，只不过是在敏捷导入和实施过程中没有引起足够的重视。经验丰富的敏捷教练往往十分重视工程类实践，会强调重构在迭代中的重要性。很多的敏捷实践(比如TDD，持续集成，重构)及很多敏捷开发者提倡的原则(比如S.O.L.I.D原则，Clean Code,Implementation Patterns )都能帮助敏捷团队避免过多的技术负债。Uncle Bob甚至认为应该在最初的敏捷宣言中加入第五条原则“Craftsmanship over Crap”，来强调技术的对成功的敏捷项目的重要性。 

2. 敏捷软件开发团队会想当然地认为每个团队成员都专业，称职并富有责任心。如果事实不是如此，项目开发很快会变得举步维艰。

是事实，但这恰恰又是敏捷的卖点。我们应该做到：谦虚有耐心；勇于承诺；团队成员互信互助，而不是互相指责批评；承认自己的能力不足，不断追求进步，需要的时候寻求团队成员的帮助。很多方法论认为只能通过审查监控的手段来确保项目的顺利运行，而敏捷团队更多的是依靠个人的责任心。在优秀的敏捷团队中，能力较弱的的团队成员会感受到来自其他成员的压力，要不然尽力做好，要不然只有走人。

3. 由于对敏捷开发实践的错误理解，导致团队不合理地频繁交付，疲于奔命。

说老实话，在了解敏捷之前，研发团队才是疲于奔命。敏捷原理打破了传统的思维模式。人很容易犯错误，但是很多敏捷实践(结对编程，持续集成，TDD)能够帮助开发团队及早发现问题，纠正错误。因此敏捷反而把我们从传统的思想束缚中解脱出来。可能是由于对敏捷的过度宣传，导致大家对敏捷期望值过高，认为敏捷开发是解决所有问题的万灵药。其实我们导入敏捷也是受种种因素（客户环境，团队对敏捷的认识程度，成员的能力）限制的。如果能够从其他更成熟的敏捷团队或者敏捷教练那里吸取经验这样会更好，否则只能合理的逐步的导入实践。很多敏捷项目确实存在过于频繁的交付，那是由于人们迫于各种压力，“好大喜功”的天性而忽略了敏捷其实一直在强调的“根据每个迭代能够实际发布量”（也就是真正能够达到Done标准的工作量）来调整下一个迭代工作量。如果团队不能自主调整工作量，这其实已经偏离了敏捷。

4. 实施敏捷的门槛太高，敏捷开发需要更强的团队和个人的纪律性，勇于承诺和高度的公开性，但对一个不成熟的组织来说这个门槛太高。

是事实。但是这并不意味着不能在不成熟的组织中导入敏捷实践。这类组织可以逐步地导入敏捷实践。很多人太过心急，想“一口吃一个胖子”，但这往往是不切实际的。当然，同时必须要注意的是，不能因为采取逐步导入的手段，而降低敏捷定义的门槛(Ron Jeffries有一篇文章"Agile Is, Not, Maybe")。

5. 绩效差的团队成员很难在高度公开的敏捷团队中掩饰自己能力的不足。好的团队往往能够采取一定的措施来帮助这类成员。但如果没有采取措施，这些成员往往会想方设法通过消极怠工来掩饰自己能力的不足。

绝对是事实，敏捷需要勇气，但是这绝对是好事。态度决定一切！敏捷团队所不能容忍的是那种故意偷懒的成员。每个人都会经历从学徒到专家的过程（获得技能的Dreyfus模型，及Apprenticeship Patterns: Guidance For The Aspiring Software Craftsman）。由于每个人的能力不同，背景不同，能达到的高度也是不一样的。团队成员应该承认个体差异，努力帮助较弱的团队成员，使其快速成长。

6. 敏捷团队容易过份关注眼前的短期目标，而忽视长期的战略目标。尽管在短期内能够取得成功，长期注定还是会失败。

可能是事实，但是这在非敏捷团队中也屡见不鲜。不可否认的是在敏捷项目中，很多人过分强调了YAGNI，因而在早期忽视了一些战略性的目标，尤其是业务需求目标，从而导致后期重构十分困难。YAGNI是很有用的，但是需要其他实践比如TDD和BDD（行为驱动设计）的支持。Kent Beck在极限编程一书中讲述了怎样借助TDD，实现演进式设计。另外需要注意的是，这其实在很大程度上是一个平衡的问题，怎样在YAGNI与预先设计之间做平衡。

7. Product Owner承担了太多的责任，不堪重负，从而成为团队的瓶颈。

也是事实。但是作为对产品最有热情的人，Product Owner难道不愿意花时间和精力帮助团队开发出符合需要的产品么？敏捷极大地缩短了从需求到软件的周期。再也不会出现Product Owner等上6个月或者更长的时间，结果发现做出来的并不是自己想要的东西的情况。Product Owner可以在短时间内就能看到软件，及时作出调整，因此敏捷极大地减少了开发成本以及相应的机会成本。公司高层的支持也是十分必要的。没有高层的承诺和授权，不可能组成全功能的团队。

8. 敏捷的效用被过度夸大，大家的期望值太高，很多人认为导入敏捷能以最小的投入解决实际开发中的所有问题。

这可能也是事实。其实在其他方法论风行的时候，也遇到过类似的批评，比如RUP。大家都期望找到一种能够解决所有软件开发痛苦的方法论。作为有经验的敏捷实践者，教练，经理和架构师，对敏捷的宣传应当适度，尽管敏捷确实能够解决很多软件开发中遇到的问题，但是它毕竟不是万灵药。不要使他人有过高的期望。

9. 可能出现另一种形式的“相互诟病”。成功的敏捷开发团队一般不会成为产品开发的瓶颈，因此其他部门不能以这个为借口来指责开发团队，但是这有可能进一步演变成为政治游戏。

这绝对是事实。Chris Tyler提出的建议是，尽早与其他部门沟通，大家的最终目标是一致的，各个部门应当一起寻找生产系统的瓶颈，然后努力突破瓶颈（参见约束理论）。基于这个共同目标，各个部门一起对流程进行修改，就会减少相互诟病。

10. 当Product Owner开始决定开发的方向，他就会被过度授权。敏捷开发中缺乏足够的审查和平衡机制。

这并不是一个问题！Product Owner应该控制产品发展的方向。Product Owner应当熟悉业务，明确他最终想要什么。尽管开发团队要利用技术手段，提供解决方案，满足业务需求。但作为开发团队不应该对业务方面干涉太多。

11. 敏捷实践大多是针对程序员的，很难在组织内平衡工作量。缺乏对团队中的非程序员提供更好的文档以及培训支持。

对于这个Chris Tyler既同意也不同意。敏捷团队是全功能的团队。如果业务分析师、Product Owner没有和团队在一起参与开发，那不是真正的敏捷。敏捷教练、经理也应该承担培训团队中除了工程师以外的成员的职责。对某些团队来说，文档会是一个问题，因为客户总是要求开发团队提供文档。其实行为驱动测试BDD就是一种既能够提供需求文档又能够照顾到代码实现的好方法。敏捷中也有文档（参见“敏捷的文档”），只不过是文档的形式发生了变化，变成了XUnit测试以及代码。进一步BDD可以成为业务人员和开发人员的桥梁，能够使业务人员更好地理解XUnit测试以及代码（另外其实还有Fit）。对于已经习惯于基于类似于IEEE的那种需求管理方式的Product Owner和公司高层们，对开发文档形式的改变，他们应当保持开放和学习的心态，充分信任团队，而不是给开发团队带来阻碍。

最后，Chris Taylor总结到，敏捷理论很美好，但是实践起来还是会有各种各样的问题，也有可能失败。其实理论描述的是理想情况，实际情况往往不尽相同。但是我们不能因为这个就放弃向理想努力。尽管过去有很多团队导入敏捷失败，我们还是不能全面否定敏捷，毕竟也有很多成功的敏捷团队。正如敏捷项目团队在开发中不断进行反省修正一样，我们也要通过反省来加深对敏捷的理解和认识。