详情
Scrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发。本书以一种轻松易懂、简洁精练的方式，介绍了Scrum方法的核心要素。全书分为3个部分，共19章。本书介绍了敏捷方法的缘起、敏捷的价值观和原则，并给出了一个典型的敏捷商业案例；详细介绍了Scrum的历史以及Scrum的各种要素，包括角色、周期、工件，如何确定用户故事、估算工作，如何开每日站立会议等等。
书名：Scrum要素
ISBN：978-7-115-30487-2
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
• 著 [美] Chris Sims Hillary Louise Johnson
译 徐 毅
责任编辑 陈冀康
• 人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
• 读者服务热线：(010)81055410
反盗版热线：(010)81055315
Simplified Chinese translation copyright ©2013 by Posts and Telecommunications Press ALL RIGHTS RESERVED
The Elements of Scrum, ISBN-13: 978-0-9828669-1-7 by Chris Sims, Hillary Louise Johnson
Copyright © 2012 by Chris Sims and Hillary Louise Johnson
本书中文简体版由作者 Chris Sims，Hillary Louise Johnson 授权人民邮电出版社出版。未经出版者书面许可，对本书的任何部分不得以任何方式或任何手段复制和传播。
版权所有，侵权必究。
Scrum 是一种迭代增量式的软件开发过程，用于敏捷软件开发。Scrum 是一个包括一系列实践和预定义角色的过程框架。
本书以一种轻松易懂、简洁精练的方式，介绍了Scrum 方法的核心要素。全书分为3 部分，共19 章。第一部分从瀑布方法开始切入主题，介绍了敏捷方法的缘起、敏捷的价值观和原则，并给出了一个典型的敏捷商业案例。第二部分详细介绍了Scrum 的历史和Scrum的各种要素，包括角色、周期、工件，以及如何确定用户故事、如何估算工作，如何召开每日站立会议。第三部分则介绍了发布规划、原型、重构、测试驱动开发和结对编程等实践和方法。
当前，Scrum 方法在国内已被逐渐普及，为众多知名IT 公司和软件开发团队采用。本书内容精练，轻松易读，是帮助软件开发人员认识、初步了解Scrum 方法的佳作。通过阅读本书，你可以厘清Scrum的相关知识和概念，为采用和实践Scrum 方法做好充分准备。
你手中是《Scrum 要素》的首版。这段文字则是我们的骚扰型弹 窗调查，希望能收集你的反馈以便为后续版本作准备。我们想要知道， 这本书有没有什么地方让你感到兴奋、有灵感、震惊或是疑惑不解？ 你喜欢我们讲回顾会议的那一章？觉得测试驱动开发的章节讲得还 不够，或是觉得，scrum 的书里放这玩意儿干嘛呢？“scrum”没用大 写字母，你觉得很震惊？发现了排版错误还是有歧义的内容？问题很 紧急，却找不到答案？如果是这样，那就请打开Agile Learning Labs 的网站，告诉我们你的想法。
本书所引用的大量主要信息来源和其他参考资料都可以在网站上 找到，还有相关组织机构的链接，以及我们推荐进一步阅读的材料。[1]
本书的网站是www.agilelearninglabs.com/resources/the-elementsof-scrum。
[1] 译者注：网站上的资源包括但不限于如下内容。
· 海报，http://www.agilelearninglabs.com/resources/downloads/)
· 博客，http://www.agilelearninglabs.com/blog/)
· 其他文章，http://www.agilelearninglabs.com/resources/articles/)
· 各种资源，http://www.agilelearninglabs.com/resources/)
我和徐毅开始紧密地工作在一起是在2006年初的时候，诺基亚网络部门当时刚开始在杭州试点敏捷和Scrum，我是试点项目的项目经理。我们的第一个sprint从2005年底开始，当时只有开发人员，工作了一段时间后，对如何充分测试网络设备，开发人员还是感觉有些心中没底。作为项目经理，我找来了徐毅。真正的跨职能Scrum团队是从徐毅加入的那个sprint开始的。在那个项目的合作中，我们一起在探索了很多未知的领域，比如测试自动化和持续集成。徐毅对敏捷的热情和在敏捷团队中的高效工作让我至今都印象深刻。1年多后，项目结束，我们还是在为同一个产品工作，但是来到了不同的部门。在此之后我们的交流更多的是围绕敏捷的话题，尤其是在徐毅担任起他所在团队的Scrum Master后，我当时作为部门经理，也把自己更多地看成是组织层面的Scrum Master。除了作为同事工作在一起之外，我们还一起贡献在敏捷社区的创建上。
2010年末，我离开了诺西，开始从事敏捷教练的工作，有机会接触更多的行业和公司。很多时候和一些已经实施Scrum多年的团队工作，却发现形式上的遵循似乎多于对实质的理解和运用。很多时候，Scrum的实施似乎就是每日例会开起来了和白板（任务板）竖起来了，但当你观察每日例会时，却会发现很多情况都是在面向Scrum Master汇报工作，试着问一下团队他们为什么开每日例会，得到的答案经常是“不清楚”。也有些团队会做sprint评审，但是参与评审的人员中却没有一个人是来自业务方或者客户端的，这些都隐隐地昭示出他们对sprint评审目的理解存在偏差。没有理解本质和目的的实施是很难产生效果的。
《Scrum要素》这本书看似很基本，但恰恰是我们最需要回归的。比如，书中详细阐述了敏捷的价值观和原则，对于实施Scrum的团队来说，能够多问一下我们的实践是否反映了敏捷价值观和原则，能够多想一下如何做到让我们的实践更能体现出敏捷价值观和原则，都是不无裨益的事情。本书第二部分和第三部分的结构则能够很好地帮助读者区分，哪些是更为核心且相对稳定的Scrum实践，哪些是有更多演进的辅助性的实践。书中描述实践时很重视讲解为什么，这一点我很欣赏。虽然我已实践Scrum多年，书中描述的那些实践背后的原因仍然给了我许多启发。
我现在是专职的敏捷教练，对我来说，选择读什么书的时候考虑更多的是书中有无新的想法或者能否带给我启发，至于是否易读倒是相对次要的考虑。但是，对于大多数在做产品的人来说，敏捷和Scrum只是一个思路和方法，他们会更多地把时间精力放在产品的身上——市场和用户、业务和商业模式、产品的发布交付等等。对他们来说，一本书是否能把最重要的信息用简单易懂的方式传递出来，才是最为至关重要的。《Scrum要素》在这方面做得很出色。比如在第一部分，它提供了一个敏捷力的商业案例，以浅显的方式展现对大多数人来说“仅够”的价值交付的本质。又比如，在第三部分的辅助性实践，它总结出各种实践背后的本质思想和关键所在，用“仅够”的篇幅进行有效的表达。我相信，作者在写书的时候是有明确的读者定位的！
翻译书籍在我看来是个艰巨的任务，译者不仅需要对内容有深入的理解，还要有精深的翻译技能，并有咬文嚼字的耐性和恒心。徐毅兼具了所有的这些。
徐毅的阅读量很大，确保了他的知识广度。除了团队和工程实践之外，在组织和管理方面他有许多的涉及，成功地翻译了《管理3.0》就很好地展示了这一点。而这一点，对于翻译Scrum这样的具有很大开放性的流程框架来说尤为重要。
徐毅同时也有着丰富的实践经验。从很早的时候作为团队的成员迭代增量式地开发软件，到作为Scrum Master带领Scrum团队的持续改进，然后作为公司内部的敏捷教练辅导不同的产品线，一直到后来帮助不同行业企业的敏捷实施和转型，他兼具了实践的广度和深度。
徐毅并非翻译专业科班出身，但他却在翻译上做出了很多的尝试并积累了很多的经验。他是多本敏捷相关书籍的译者，还是敏捷宣言简体中文版的核心译者。尤其在敏捷宣言的翻译过程中，他认真而又耐心地倾听社区的声音，通过若干迭代最终形成现在的版本，这本身也是遵循敏捷精神的一次翻译。虽然敏捷宣言很短，但是其翻译真正做到了字斟句酌。
回想起刚开始实施敏捷的时候，很缺少那些能够指导我们工作的书籍，然后慢慢地多了起来，但是也多限于英文版。到今天，敏捷的书籍出版频率已经很高，相应的中文译本也出得非常快。对于实践者来说，数量上的充裕也使得选择的余地变得更大，而随着实践者整体对敏捷的认识和经验的提升，他们对书的要求也在相应地提高。好书加好翻译，两者缺一不可，我相信这本《Scrum要素》能够做到！
吕毅，Odd-e 敏捷顾问、全球唯一中国籍CST
现在是周一的早上9:50，Brad正在准备他们团队的Sprint规划会议。他怎么看起来很放松、很开心呀，干活呢还吹着口哨，这是为啥呢？
Brad是一个高绩效scrum团队的产品负责人，跟往常一样，他会带着好的想法参加会议，希望在下一周的Sprint中团队能够将之实现。更棒的是，他将要面对的都是真心诚意想见他的人，人们想知道他会带来什么好东西。曾几何时，会议准备工作这件事可让呆伯特人担心不已、手心都会冒汗，但Brad如今已不再忆起往日。
Brad有一张工作项的候选列表，新特性和错误修复的工作都有，他认为这些都是项目上最重要的代办事项。
这些代办事项源自一个按优先级排序的清单，将它们挑选出来是Brad作为产品负责人职责的一部分，而这个清单则被称为产品列表。
选定范围之后，Brad会用文摘卡记录下这些特性，每张文摘卡记录一个特性。团队管这些工作项叫用户故事，或者就叫故事。是的，没错，他们的确觉得这些故事是好东西。程序员本来就喜欢有挑战性的、有意义的工作，更不用说他们还参与了这些用户故事的设计，这工作有多刺激，他们当然知道。
Brad带着一小叠的文摘卡，走进团队的scrum房间。Frank是团队的scrum master，他早已把房间布置得妥妥当当，就等会议开始。团队的工作大多数都是在这个房间内完成，各种会议差不多也在这里开。墙上贴满了手绘图表和白板纸，白板纸是用来做文字记录的，例如，团队都认可的故事“完成”定义。
整整一面墙被用来作团队的任务板。这事儿科技含量不高，用蓝色美纹纸胶带 脚注[1]贴出行和列来即可，而任务则填在便事贴上面。
在不明就里的人看来，这房间就像是刚刚被纸炸弹狂轰滥炸过一般。然而，对团队来说，这些涂鸦一点一滴都是有意义的信息，任务、约定和进度图表，大家喜欢一目了然的感觉。公司高层每次途经这个风暴后的工作室，脸色都苍白得很，但他们已经学会了信任团队的决定；首席财务官最近就给他的团队做了一块任务板，而后就发现，财务部门总算是能够准时给供应商开发票了。
团队成员Mark和Jeff已经在场，他们喜欢早到。早上10点的时候，Kira、Justus、Mick、Kai和Malay也都到了。
Brad开始讲话：“大家平均每个Sprint能够完成相当于40个故事点的工作量。我已经从产品列表里选出了最前面的8个故事，加起来刚好40个点的大小。我想知道团队会不会承诺这些故事。”
这些故事都是Brad、业务和客户想要的东西：故事是有商业价值的。
团队成员们和Brad逐一讨论这些用户故事，明确其验收标准，或者更确切地说，就是Brad心目中已完成故事的模样。团队成员还会继续讨论实现这些故事要做的工作，有哪些类型，有多少工作量。
讨论中团队发现，有个故事大家理解得还不够，没有想象中的好，他们要求Brad再去向某个关键客户多要些信息回来。推迟这个故事之后，团队还剩下7个故事，总共37个故事点。Brad看了一遍产品列表中的其他项，选择了3个大小差不多一个点的小故事，团队则同意把它们加入到这个Sprint的计划中。
曾几何时，Brad也想过试着给团队施压让他们多承诺些，后来他发现，团队的速率（velocity），即每个Sprint能够完成的故事点总数，是不会撒谎的。更搞笑的是，Brad发现，公司承诺维持可持续的速度并削减了疯狂时间之后，团队的生产力不降反升。（不然，Malay要是一门心思想要完成任务，他还是很喜欢挑灯夜战的。）
回顾会议的时候，Brad发现，施压团队接受“挑战性目标”所有的成果就是增长的缺陷数目，这都得归因于更多的压力和更长的工作时间。
不仅如此，压力多少也妖魔化了他在大家眼中的形象。
如今，开发团队信任Brad，大家把他当做同伴和盟友。反过来，他从中学到很多，他知道，不管是无法兑现某个承诺还是可以额外加活的情况，团队一旦发现这些情况就会立刻通知他。他可以很自信地告诉客户，自己的筹划绝不是空想。
上午11点，团队开始把用户故事分解成任务。要实现这些故事，团队得把它们分解开，转化为需要完成的具体的工作任务。团队一起上，要找到办法对这些故事进行设计、编码以及测试。在此过程中，他们会用便利贴把所有的任务都记录下来。
临近中午的时候，会议已接近尾声，团队已经为接下来一周的Sprint做好了计划。他们把这个计划称为Sprint列表，即一张清单，上面是团队承诺的故事，以及为了实现故事而必需完成的工作任务。他们还在Sprint列表里放上了一些团队改进的任务，都是他们自己想出来进行流程改进的点子。他们把任务全都记在便利贴上，通通都贴在任务板的“待办”栏里。
会议结束前，团队还用一页白板纸制作了一个图表，用来监测下一周任务完成过程中的进度变化。他们称之为Sprint燃尽图。
星期二的上午10点，团队在任务板前围成半圆形，准备开scrum日会。scrum日会是一种短会，用于团结和协调团队。为了鼓励大家都简洁点，这个会是站着开的。它也因此而得名“每日站会”。
团队成员轮流分享信息：前一天完成了什么任务；明天的scrum日会前打算做哪个任务；有没有碰到什么障碍或是受到了什么拖累。Kira提到窗口库的代码行为和她想的不一样，Kai说会后就可以帮她解决这个问题。Mick说他在重现手头某个缺陷的时候遇到了麻烦，Justus说他可以帮忙看看，他俩计划午饭后就联手解决。
人们一边讲话一边更新任务板上相应的部分，大家都觉得在板上移动任务贴的这种方式格外地让人满意。不到15分钟就开完会了，团队重新回到工作之中，确信自己可以如期交付Sprint列表上的工作项，兑现承诺。
周三开scrum日会时，Brad提醒大家要预留出时间为下午的“故事时间”会议做准备，会上要讨论他候选列表上新增和预定的那些故事，大家得先看一看。下午3点钟左右，团队再次聚集一个小时的时间，对产品列表上的故事进行精炼和完善。有些团队称之为“列表修整”（backlog grooming）会议，但这个团队认为叫“故事时间”更好玩。
Brad说：“我有6个故事需要大家评审，其中有两个是全新的需要进行故事点估计。其他4个是大故事，一个Sprint没办法做得完，需要大家把它们拆得小一点。”
团队从那4个大故事入手，想方设法把它们都拆成了小故事，这4个大故事最后变成了15个小故事，每一个都比刚开始的时候详细得多。
接下来，团队需要对这15个小故事以及Brad带来的两个新故事进行估计，估计它们各自代表了多少工作。作为scrum master，Frank开始带着大家做“估算游戏”，这是他参加会议学来的招，跟扑克牌游戏很像，能够帮助团队快速达成共识。刚到下午3:45，团队就已经完成了所有故事的故事点估值，于是Brad宣布会议结束。
走回座位的途中，Brad一直在想，团队修整好的这些故事应该放在产品列表的什么位置。他觉得，其中至少有两个优先级相当高的故事，应该置顶并排入下周的Sprint。剩下的故事都得塞进产品列表，按优先级进行排序，有些故事很靠前，其他的则更远些。有一些故事应该能赶上下一次产品交付，另一些则还得顺延。
在周四的scrum日会上，团队碰到了新问题。在当前sprint所承诺的故事中，有一个故事被证明比团队成员最初所想象的困难很多，他们报告说可能无法完成这个故事。
听到这个消息，Brad很生气，但也很感激能够得到预警。他还有机会可以调整团队的干系人的期待。
Mark和Malay决定结对编码，处理有风险的这个故事Mick则自告奋勇做自动化测试。当天快下班的时候，Kira结束另一个故事的工作后，也来帮助Mark、Malay和Mick了。
周五scrum日会的时候，团队虽然不能确定这个有风险的故事能否及时完工，赶上演示，但还是有信心的。
Brad告诉团队，如果他们有任何的问题需要解答，或是完成了这个故事需要签收，他随时待命。就在午饭前，Mark就把Brad叫了过来，向Brad展示他们正在工作中的软件，并说到：“可以通过验收吗？”Brad笑开了花，冲着团队喊：“我就知道你们一定行！走吧，咱们吃午饭去，我请客。”
午饭后进行当前Sprint的公开收尾，团队成员们都来了，这一事件就是sprint评审会议。整个团队都在场，还向所有干系人发出了参会邀请。干系人们当然不会每次都到场，但他们多数都觉得多参加这样的会议还是挺有益处的。
销售总监Anne今天也在场。团队先是宣布他们完成了这个Sprint承诺过的所有故事。接着就直接开始演示他们为故事所开发出的软件功能。Mick展示了某个关键客户乐于看到的一个缺陷修复，Justus则介绍了团队在日本市场本地化方面所取得的成果。团队最后展示的是Anne迫切想看的故事，也正是那个差点完不成的故事。
演示结束后，团队邀请参会者亲身体验新功能，问他们有没有疑问或者建议。Brad小心记录下不同干系人对于当前产品的看法，以及他们希望在下一次发布时看到的变化。Brad向提供信息的人们表示感谢，还向他们担保，他会在重排产品列表的时候把这些意见都考虑进去。会议随之结束，干系人陆续离开。
团队休息片刻，之后还要回到他们的scrum房间。
接下来是sprint最后一部分，团队的回顾会议。整个scrum团队的人都在，包括Brad、Frank、Kira、Mark、Jeff、Justus、Mick、Kai和Malay。团队之外的人都没有邀请。团队坦诚地谈论Sprint的情况，寻找他们的流程中可以提高的地方。
Mark说到他和Malay做的结对编程效果很不错，也许团队愿意多试试结对的方式。Kai愿意一直结对工作，但其他人比较担心结对的额外开销太大，尤其是团队已经有一条 “所有产品代码都要进行评审”的工作约定。
Jeff提议可以修改团队的工作约定，要求所有的代码要么是结对编写而成，要么就要通过评审。团队一致认同。Mark、Kai、Malay和Kira约定，在接下来的sprint中每天至少结对编程一小时。Jeff、Justus和Mick则同意，在下个sprint时至少尝试一次结对编程。团队把结对看做是一场试验，计划下周五回顾会议的时候检查试验的效果。
在收工结束当天以及当前Sprint的工作之前，大家还花了几分钟进行互相认可，能够圆满完成Sprint是所有人共同努力的结果。Brad特别感谢团队能够交付那个有风险的故事。
团队成员纷纷高高兴兴地离开，他们等待着周末的到来，也期待着下一周再续辉煌。
[1] 译者注：原文 blue painter’s tape，也即蓝色美纹纸胶带，可参考：
http://www.scotchblue.com/wps/portal/3M/en_US/Scotch-BlueBrand/Scotch-Blue/Products/Catalog/~/Product-Catalog?N=4294552291+5890400&rt=r3)
http://www.amazon.com/s/ref=nb_sb_noss?url=search-alias%3Dtools&field-keywords=Blue+Painter%27s+Tape)
http://en.wikipedia.org/wiki/Painter%27s_tape)
http://detail.china.alibaba.com/buyer/offerdetail/909509595.html)
1901年的时候，一位名叫安妮·爱德森·泰勒的63岁冒险家，把自己装进木桶从尼亚加拉大瀑布上冲下去，没有任何明确的理由。浮出水面后，除了有些轻微伤口之外，看起来别无大碍，她随后宣称“我情愿走到炮口前面，被轰成碎片，也不要再来一遍瀑布冲流。”
如果你曾参加过使用瀑布方法、乱糟糟的大型企业级软件项目，兴许就能理解安妮的感受。然而让人惊讶的是，沮丧的开发人员对安妮不幸遭遇的认同感，和瀑布这个词的本义并无关系。
Winston W. Royce在他提交给1970年IEEE WestCom软件工程会议的论文[1]中，首次提出了著名的传统瀑布方法。Royce并未使用瀑布这个词，但他确定描述了一种线性顺序流程，其中每一阶段都必须等待上一阶段结束之后才能开始。颇有点讽刺的是，Royce之所以提供这个模型，就是要拿它当靶子说明不能这样做软件开发！如图1-1所示。
图1-1
Royce继续说，人们肯定不愿意按此方式操作软件项目，接着又描述了一种他宣称绝对更高级的迭代式流程，该流程跟当今的敏捷方法论很相像。然而，不知怎么的，偏偏是描述瀑布模型的部分受到听众的追捧，并由此变得广为人知。
1985年，美国国防部决定采纳瀑布方法作为旗下所有项目的官方标准，不管是政府机构还是独立防务承包商都要遵守此标准。此事件巩固了“瀑布”的地位。瀑布模型由此成为所有企业级软件开发项目的可信模型。
到了21世纪，就连政府也开始隐隐地感觉到，瀑布模型可能是有缺陷的。2005年NASA一篇介绍此方法的官方文档[2]写到，“一些大型系统的失败或取消被认为跟标准瀑布模型有关。它还非常昂贵。”文中接着还提到，“极限编程”看似很有前途。
4年后，NASA的一篇新闻采访引起了骚动，他们宣布其工程师设计发明了NASA自己的敏捷方法论，名为“大师风味极限编程（Extreme Programming Maestro Style）[3]”。我们知道，这听起来更像是在In-N-Out汉堡店[4]里合着薯条一块点餐的东西，但NASA却用来开发火星登陆者机器人的控制程序!
瀑布模型将开发和交付企业软件项目的流程分割为相互独立的阶段：
1．需求收集
2．设计
3．编码
4．测试
在瀑布流程中，每一步骤都必须等待前一步骤结束后才能继续，也只有等待所有步骤都结束后才有可能向客户交付价值。
在图1-1上你可以很清晰地看出“瀑布”这个名字的来由，开发流程正是从一个阶段流向下一个阶段，（往往都是不折不扣地）带着项目向下冲，不可阻挡。
瀑布方法的支持者喜欢使用这种方式的确有原因。对新手来说，用“瀑布”来安排进度和作汇报，首席执行官、首席财务官、企业律师和其他干系人在签合同与定预算的时候才能用上熟悉的工具和流程。毫无疑问，让这些家伙拥抱变化是难度很大的挑战，难度远远大过改变那些最固执的项目经理和开发人员而让他们接受敏捷。
设计方面，“瀑布”支持者所坚持的哲学是大设计前置（BDUF，Big Design Up Front），这也是众多计划驱动型软件开发方法论的普遍做法。（使用BDUF短语和简写最多的是它的批评者，发音时嘴唇略微卷曲，颇像是一些学生对Big Man On Campus[5]短语或BMOC简写的使用，他们用来称呼学校里的“笨蛋运动员”。）
人们往往会举出如下论证支持BDUF，在开始实现之前先进行“完美化”（perfecting）设计，能够早点捕获错误和缺陷，从而降低项目全过程成本。
美中不足之处就在于那词语太不现实了：完美化。如果你是制造汽车，那么先调生产线再投入生产绝对是优良方案。要保证挡泥板和车体外壳吻合并不难，设计图纸阶段就可以做到，如果很晚才发现它们不匹配，那就得重塑贵重模具，还会耽误整个生产流程。
BDUF的思想基础在于，在投入生产前先“完美化”产品设计是可以做到的。如果是在说汽车挡泥板，那倒是说得没错……但软件产品是复杂系统，而不是静态物件，毫无经验数据只能设计出致命的烂系统，在出问题前把事情搞得一团糟，谁也不知道会有什么后果，留下一堆烂摊子等你收拾。
对软件开发行业来说这意味着，就算你在绘图板前耗上一整天，创造出了惊人的美妙理论，让人期待不已。但是，就在你将它付诸实践的那一刻……“我的妈呀”[6]，各种意料之外的状况和并发症开始涌现。更糟糕的是，说不定什么时候，你的客户就决定不再和这个软件继续玩了。
[1] 译者注：论文下载地址，http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/ waterfall.pdf。
[2] 译者注：可于如下链接阅读此文档，http://web.archive.org/web/20050310133243/http: //asd-www.larc.nasa.gov/barkstrom/public/The_Standard_Waterfall_Model_For_Systems_Development.htm。
[3] 译者注：可于如下链接阅读此文档，http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/ 20090029264_2009028698.pdf。
[4] 译者注：http://zh.wikipedia.org/wiki/In-N-Out汉堡。
[5] 译者注：Big Man On Campus为俗语，常用来称呼学校的某个“重要”学生，通常用于嘲弄不太聪明的运动员，参见http://idioms.thefreedictionary.com/big+man+on+campus。
[6] 译者注：原文Whoa Nelly，现代美语中用来指代某物（例如汽车、自行车或某状况）或某人突然失去控制，出现在面前并造成了无法预期后果，可参考http://www.urbandictionary.com/define.php?term=whoa%20nelly。
虽然现在还只是遐想，但我想我能够弄到钱先折腾个概念出来，随后再把它包装成一个好点子。
——伍迪·艾伦
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”，常译作“职能筒仓”。
