第1章　DAD

每个复杂的问题都有一个看似简洁、实则错误的解决方法。
——亨利·路易斯·门肯
2001年春天，敏捷软件开发模式伴随着《敏捷宣言》（www.agilemanifesto.org）突然闯入人们的视野。《敏捷宣言》的17位作者，用4个价值观和12条原则描绘出了敏捷思想和策略。这些思想和策略的宗旨是，促进开发人员和利益相关者之间的密切协作，推动渐进和有规律的软件构建，从而为组织带来真正的价值。这些策略始终如一地注重质量，它们采纳了具有高价值的实践方法，而避免了低价值的实践方法（例如，更聪明而不是更辛苦地工作），并在整个软件生命周期中，追求开发方法的持续改进。当然，对于拥有成功经验的软件开发团队来说，这些策略可能已似曾相识。
毫无疑问，敏捷不是一时的*。当主流敏捷方法（例如，Scrum和极限编程）出现时，其所包含的思想并不是全新的，也并不是革命性的。事实上，其中许多方法已在其他方法中做过深入的描述，例如，快速应用开发（Rapid Application Development，RAD）、Evo和各种统一过程（Unified Process），更不用说其他那些经典著作了，例如，弗雷德里克·布鲁克斯的《人月神话》。这样来看，就不必奇怪，工作地点集中在一起的团队，成员以统一的方式密切协作，把生产可工作软件设定为前进目标，他们所生产的成果势必优于那些只关注个人而不是团队绩效的专业团队所生产的成果。减少文件和行政方面的繁文缛节可以节省金钱，加快交付速度，这同样不足为奇。
敏捷开发方法曾经被认为只适合规模较小的、地点集中的工作团队，但它提升产品质量、团队效率和按时交付的事实，激发了大型团队对敏捷开发方法的关注，他们开始在自己的环境中采用敏捷原则。事实上，IBM公司拥有许多超过数百人的开发团队，他们往往分布在全球各地，但采用敏捷技术来开发较为复杂的产品，多年来，他们已经非常成功地运用了敏捷实践。最近由《敏捷杂志》（Agile Journal）发起的一项调查表明，在拥有超过10?000个员工的公司中，有88%的公司在他们的项目中正在采用敏捷实践，或者正在评估敏捷实践，准备采用。敏捷正在成为主导的软件开发方式。在其他研究中，这一趋势也得到了印证，例如，由《Dr.?Dobb’s Journal》（DDJ）杂志发起的调查研究发现，敏捷技术的采用率已达76%，并且，在这些采用敏捷的机构中，平均有44%的项目团队都在以某些方式使用着敏捷技术。
遗憾的是，我们不得不对敏捷采用率这样的调查结果持保留意见：Ambysoft在一项后续的调查中发现，实际上，只有53%的人认为，自己所在的团队是真正的“敏捷团队”。很显然，多年来，敏捷方法已经被各种媒体过分夸大，导致滥用和误用。事实上，从收集到的信息中似乎已经听到这样一种不同的声音，即敏捷并没有像想象中使用得那么多，或者在使用时并没有采用过程方法。有太多的项目小组，由于这种滥用和误用导致了无*状态和混乱局面，最终使项目遭受失败。这些方法也受到信息技术（IT）和系统工程社区的强烈抵制，因为他们更喜欢传统的方法。
使用得当的话，敏捷并不是散漫的借口。主流敏捷方法（例如，XP等）对执行方法一向要求严格，当然比传统的方法（如瀑布方法）要求更为严格。不要误以为许多高调的传统方法是纪律的象征，恰恰相反，它们可能象征粗暴和失控的行政机构。然而，主流敏捷方法并没有为一般企业提供足够的指导。成熟的敏捷实现方法认为，企业对敏捷实践需要有一定的严谨度，而核心敏捷方法反对这样的认识，认为不需要诸如治理、架构规划以及建模这样的策略。不过，核心主流的敏捷方法的确承认，他们的策略需要进行重要的补充和调整，从而得以扩展，使得规模超出约8人的团队也能紧密协作。此外，大多数“财富1000强”企业和*机构都拥有规模较大的解决方案交付团队，这些团队往往分布在不同的地域。可以证明，这些企业或机构花在定制和剪裁流程上的精力，既昂贵又有风险。现在是新一代敏捷过程框架呼之欲出的时候了。
图1.1以思维导图的形式显示了这一章的组织结构。我们将从右上角开始，按顺时针方向逐一描述其中的每个主题。

本章要点
人是IT项目成功交付的主要决定因素。
转型到规范的敏捷交付过程是实现可伸缩敏捷开发策略的第一步。
规范敏捷交付（Disciplined Agile Delivery，DAD）是具有企业意识的混合软件过程框架。
敏捷策略的运用应贯穿整个交付生命周期。
与传统团队相比，敏捷团队更容易管理。