1.4 敏捷的本质

Martin Fowler将复杂的软件话题转化为一段经过深思熟虑的、恰到好处的解释。这是“敏捷软件开发的本质”最好的解释之一：

敏捷开发方法是适应性的，而非预测性的；是面向人的，而非面向过程的[3]。

——Martin Fowler

1.4.1 适应性而非预测性

还记得“CHAOS报告”吗？它说只有六分之一的软件项目是成功的，它对成功有非常具体的定义。

成功

项目按时、按预算完成，所有的特性和功能都符合最初的规定。

有挑战

项目完成并投入使用，但超过了预算，超过了估计的时间，而且提供的特性和功能比最初规定的少。

受损

项目在开发周期的某个阶段被取消。

这些定义完美地诠释了预测性思维方式。它们都与计划的一致性相关。很简单：如果你做了你说的要做的事，你就成功了，如果你没做，就是不成功。

这句话起初很有道理，但仔细看看，这里缺少一些东西。正如Ryan Nelson在CIO杂志上所写的那样[Nelson2006]：

　　那些在时间、预算和规范方面符合所有传统成功标准的项目到头来仍然可能是失败的，因为它们没有吸引到预期的用户或者最终未能为企业增加多少价值……此外，那些按照传统的IT衡量标准被认为是失败的项目，最终反而可能会成为成功的项目，因为尽管有成本、时间或规范方面的问题，但系统还是受到了目标用户的喜爱，或者提供了意想不到的价值。

敏捷团队将成功定义为交付价值，而不是符合计划。事实上，真正敏捷的团队会积极寻找机会，通过改变计划来增加价值。

回顾一下《敏捷宣言》（见图1-1和图1-2）。花点时间真正研究一下敏捷的价值观和原则，看一看其中有多少是与交付有价值的软件和适应反馈有关的。

1.4.2 面向人而非面向过程

那些烦琐的流程试图通过详尽定义软件开发的方方面面来防止错误，将“智慧”赋予流程，人的技能在其中反而变得不那么重要了。理论上，你可以反复应用相同的流程，即便与不同的人合作，也能得到相同的结果（仔细想来，他们确实这样做了，只是没有得到想要的结果）。

在敏捷方法中，人是软件开发中最重要的因素。不仅仅是他们的技能，还有他们人性的所有方面。团队成员之间的合作有多顺利，他们遇到的干扰有多少，他们说话的安全性如何，以及他们是否对自己的工作有积极性。

每个敏捷团队都会有一个流程——每个团队都有，即使是隐性的，但这个流程是为人服务的，而非服务于其他因素，并且敏捷团队掌管着自己的流程。当团队成员想到更好的工作方式时，就会改变它。

再看一下《敏捷宣言》（见图1-1和图1-2），哪些价值观和原则与以人为本有关？