2 加入敏捷实践者行列
Scrum要素
虽然现在还只是遐想，但我想我能够弄到钱先折腾个概念出来，随后再把它包装成一个好点子。
——伍迪·艾伦
2001年，17位超级极客齐聚犹他州的雪鸟滑雪山庄，共同探索有关软件开发未来发展的共同理念。其中包括Scrum、极限编程、水晶、特性驱动开发等一些新生方法论的发起者，还包括Jim Highsmith所说的“寻求文档驱动型重型软件开发流程替代品的同道中人”。Jim为后人记录下了这些事件。
与会者达成了一致意见，将这场“运动”命名为“敏捷”。他们授予自己“敏捷联盟”的称号，草拟出一份言简意赅的《敏捷宣言》。联盟成员们在那个周末发现了各自哲学上的共同基础，也都体现在这份纸巾大小的文档中。但成员们并没有编纂什么实践或方法的宝典。
“敏捷运动并不是要反方法论，”Highsmith写到，“事实上，我们多数都想要恢复方法论这个词的威名。我们想要恢复一种平衡。我们拥抱建模，但绝不是为了记录成图表放进企业库里积灰尘。”
这一切可不是横空出世。敏捷联盟其实是对一贯以来软件项目管理方式做出了反应：像“瀑布”那样的开发流程，把计划、设计、开发和测试分割成不同的独立步骤集，就像尼亚加拉瀑布的水一样，它们也一个接着一个顺流而下……最后在底部巨石上砸得粉身碎骨。
变革的时机业已成熟。1995年Standish Group[2]发布的年度“Chaos”报告中，详实地介绍了传统软件开发方法所造成的令人震惊的失败案例。报告指出，以传统方式运作的企业级软件项目中，只有16%可以按时按预算交付，31%的项目被取消，还有53%的项目预算超标189%。当他们被问及这些项目为何失败得如此惨烈如此频繁的时候，IT经理们提到的首要原因就是“用户参与少”，第二位的是“需求不完整”，二者相距甚微。是的，一点没错，就算是BDUF也没能做到充分地收集需求，尽管它已经在流程上特别强调了这个开发阶段的重要性，也不行。
尽管联盟创始成员们颇有些浪漫主义情怀，但是他们也都曾是那些恼怒的IT经理中的一员，见识过，也经历过瀑布方法在现实中的溃败。他们都是经验丰富的老手，不是理论家，他们知道什么好用，什么不好用。
Alistair Cockburn是一名英国籍IT战略专家，居住在盐湖城，致力于研究他名为“水晶”的新方法论。根据他的观察，那些理性化线性方法论的问题在于，人类在本质上是非线性的，而所有的软件开发工作都是由人来完成的。“我们所设计的复杂系统，主要由具备可变性和高度非线性的人类组成，但一直以来，我们在设计系统时却并未把人类或人类对系统的影响考虑进去。”1999年的一次会议上，Cockburn对系统科学家和其他技术专家组成的听众群体如是说。“回想起来，虽然想想都觉得很荒谬，但是，在咱们业内，投入了大量精力致力于理解人类对软件开发所造成影响的，真的只有少得可怜的几个人。”
在克莱斯勒公司工作期间，Kent Beck和Ron Jeffries以及维基的发明人Ward Cunningham共同提出了“极限编程”，它是一种以开发人员为中心的方法论，包含了测试驱动开发和结对编程等实践。
而Jeff Sutherland、John Scumniotales、Jeff McKenna和Ken Schwaber则在努力完善另外一种迭代式方法论，他们称之为“scrum”。
他们和其他敏捷理论家前辈们都来到了雪鸟滑雪场，而他们一个个都开始相信迭代式方法论就是未来。
迭代式方法
BDUF的一个关键问题在于，它自认对未来了如指掌。只要是在企业级软件项目中干过的人都知道，唯一能够指望的只有变化。所有种类的敏捷流程都有一个共同点：它们拥抱变化，视变化为成长的良机，而非障碍。
敏捷团队做的开发工作和瀑布团队一模一样，但他们的做事方式很不一样。敏捷开发周期使用的职能和瀑布方法一样：需求收集、设计、编码和测试。
简单地看，敏捷开发和瀑布开发之间差别在于：瀑布开发必须先完成当前步骤之后才能头也不回地迈向下一步骤。这不是敏捷团队的方式，敏捷团队会做一点点需求收集，一点点设计、编码和测试，最后交付一点点价值给客户。接着团队再重复此过程……周而复始，工作推进过程中不断改善、调整流程，一直到项目完成为止。
增量式迭代开发所改变的不仅仅是做事情的时间点，还包括做事情的方式。敏捷迭代（在scrum中称作“sprint”）可不是微型瀑布，敏捷流程可是真的没有什么步骤之说。敏捷开发是一种整体（holistic）流程，即测试、设计、编码和需求收集是完全整合彼此依赖的流程。例如，测试被并入了设计流程。需求也不是简简单单收集一下就行了，相反，这需要团队、产品负责人和客户通过持续不断地沟通过程，建立起对需求深入细致的共同理解。
但这在实践中又是怎样的呢？
你要怎么做敏捷开发？不管你是要采纳scrum、精益、极限编程，还是要糅合多种敏捷方法论创建你自己的混合方法，你都要：
边做边测试，别等到最后关头，现在就修复缺陷，等它有机会在系统里繁衍存活好几个月后，修复成本可就高了。
及早且频繁地交付产品，只有通过展示可工作软件的方式，你才能发现客户真正想要的是什么。正因为敏捷流程能够照顾到客户的持续反馈，项目才能不偏不倚地走下去；也因为只交付已完成的增量，敏捷开发才能规避项目被取消的风险，客户还能用上按期交货的软件。
文档边做边写，只写必需的文档。将文档工作融入流程，只写有关的、有效用的文档。
打破筒仓（silo）[3]构建跨职能团队，不要让任何个人或部门成为流程、信息的瓶颈。
敏捷方式的核心思想在于迅速交付商业价值，体现为可工作的软件，还要以定期增量的形式持续地交付价值。在随后的章节中我们将看到，迭代地完成开发工作，带给业务的好处不仅立即可见还会不断累积。
[1] 译者注：敏捷实践者，此处原文Agilistas。
[2] 译者注：Standish Group是美国专门从事跟踪IT项目成功或失败的权威机构，其网站为http://www.standishgroup.com。每年发布著名的Chaos报告，http://blog.standishgroup. com/pmresearch。1995年的报告，http://www.projectsmart.co.uk/docs/chaos-report.pdf。
[3] 译者注： silo，或“functional silo”，常译作“职能筒仓”。
本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。