敏捷开发到底适用什么样的情形？

在网上常常可以看到对敏捷开发是否有用的讨论，大家会从各自的感受出发回答这个问题。有的人认为小团队小项目更适合用敏捷，也有人认为对可靠性要求不高的项目适合用敏捷。针对这个问题，我想从一个长期从事组织精益敏捷转型的业内人士的角度说说我的看法。

其实回答出奇的简单：任何具有不确定性的项目都比较适合用敏捷。不确定性越大，采用敏捷方法得到的收益越大。而恰巧大多数情况下软件交付过程都具有相当的不确定性，所以我的经验是在绝大多数软件项目或产品开发过程中，采用敏捷方法都是能够受益的，这与团队大小、可靠性要求高低其实没有太大关系。为了更好的说明我的观点，我将从以下两个方面来阐述：

1. 软件开发活动大都具有相当的不确定性

2. 和传统软件工程方法相比，敏捷能够更好的应对不确定性

如果这两个命题成立，我的观点就是成立的。

一，软件开发活动大都具有相当的不确定性。软件开发过程就是对现实世界进行抽象的过程，现实世界的复杂多变带给了软件开发过程相当大的不确定性。这是软件开发的本质决定的。这种不确定性表现在多方面：

1.需求的不确定性。软件开发过程就是对现实世界的抽象建模过程，现实世界的复杂性和多变性导致了需求的复杂性和多变性。首先这使得充分理解需求变得越来越困难，从而在需求沟通过程中各方常常形成不一致的理解。其次现实世界的变化常常体现为业务的变化以及对产品认知的变化，这些变化都会导致需求的变化，越是高速发展的领域这一点就越明显，互联网行业就是明显的例子。所以复杂性和多变性导致了需求的不确定性。

2.技术的不确定性。通常某项新技术被采用时，通常都有很多暗藏的陷阱需要解决，稍不留神就会被意想不到的问题困扰，我想只要做过软件开发就会对这一点有感触。而这些问题很难在一开始就充分预知。

3.人的不确定性。不同的人背景不同，经验也不同，完成同一个任务所花的时间也不尽相同。

通常这些不确定因素在软件交付过程中普遍存在，这使得我们难以在一开始就掌握所有必要的信息并作出最最合适的决定。我相信一定会有例外，但据我对大大小小数百个团队的观察，这种例外并不常见。不信的话我来问一个假设性的问题：

你的团队刚完成一个耗时六个月的项目（里程碑版本），但因为某些神秘原因，代码全部丢失，不得不重新重新做一遍。那么同样的人、同样的需求，你觉得这一次会花多久？

这个问题我问过很多软件开发从业者，大家无一例外给出的估计都明显少于第一次的六个月。也就是说同样的软件开发项目，大家都会有做第二遍所花时间明显少于第一遍的预期。那么第一遍比第二遍多出来的时间花到哪里去了？答案是：学习了解那些你在一开始不知道的事。这是具有相当不确定性的活动的一个鲜明特征：对于这样的工程活动，你难以在一开始就获得所有的必要信息，所以必然有一个学习的过程。对软件开发项目来说，只有随着项目的深入，你才能逐步加深对需求的理解，更加熟练的运用当前的技术。所以你只要问问自己，之前做过的项目重做一遍多大程度上能够缩短时间，你就知道其中的不确定性有多大了。

综上所述，不确定性是软件开发过程的一个明显特征，当然例外肯定有（比如由于经验的积累，某些人格外擅长解决某类问题，这类开发任务对这些人而言不确定性可能就会比较小），但总体而言仍旧具有普遍意义。这一特征在我们所处的这个互联网高速发展的VUCA 时代就更加明显了。

二，和传统软件工程方法相比，敏捷能够更好的应对不确定性。两者的核心区别在于对待不确定性的思维方式完全不同。传统的瀑布式软件工程方法应对不确定性思路是：消灭不确定性。它通过引入繁重的流程、文档和检查机制，试图让整个过程实现高度的确定性。比如在项目一开始就必须形成完善的需求文档、完美的计划和恰到好处的设计，开发过程中严格执行计划。如果发生任何对计划的偏离，都会被认为是工作不到位，从而可能会引入更多的流程和检查机制。但是这类措施实际效果却极其有限，因为软件开发过程的固有特征就是不确定性。当我们假装不确定性被消灭后，变化仍会不预期的来临。届时团队并未为此做好准备，因此造成的大量浪费，大大削弱了团队交付能力。而敏捷应对不确定性的思路是：接受软件交付过程具有高度不确定性这一现实，通过引入各类实践提升应对变化的能力。通常有以下一些做法：

1. 追求快速反馈。这是应对不确定性的核心思想，即持续的行动和频繁的获取行动的产生的反馈结果，同时基于反馈信息来持续调整前进方向。具体做法通常是需求拆分成小功能并采用迭代开发方式小批量分批完成，从而可以快速获得反馈。持续集成、自动化测试等工程技术手段也有助于开发人员快速获得反馈。

2. 尽可能降低变化带来的成本。变化即有成本，因此要为变化做好准备使得变化成本尽可能的低。常见的做法有需求渐进明细、拆分成小粒度，滚动式计划、远粗近祥。另外交付过程尽可能自动化，减少人因为重复性劳动出错的可能性。

3. 充分发挥人的自驱力，提升协作水平。对软件开发过程的管理和对制造业流水线的管理不同，基于严格的流程和控制检查手段的管理方式对软件开发这种需要创造力和反复试错的任务并不太有效。虽然也能交付，但代价高昂，应对变化能力弱。相反，敏捷更看重发挥人的自驱力，通过基于简单规则自我管理的方式来更好的实现目标。所以建立有掌控感、成就感、持续成长的积极文化氛围是敏捷关注的重点。另外，透明和信任是团队协作的润滑剂，敏捷也强调通过充分的信息透明和加强团队成员间的相互信任来提升协作水平。

基于以上讨论，敏捷开发方式对充满不确定性的软件开发活动来说是非常有效的。这和你在哪里工作没有关系，最多只能说同一项开发任务对能力强、经验丰富的人来说不确定性更低一些。