作者：[美]Chris Sims Hillary Louise Johnson 著
出版社：人民邮电出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
Scrum要素试读：
内容提要
Scrum 是一种迭代增量式的软件开发过程，用于敏捷软件开发。Scrum 是一个包括一系列实践和预定义角色的过程框架。
本书以一种轻松易懂、简洁精练的方式，介绍了Scrum 方法的核心要素。全书分为3 部分，共19 章。第一部分从瀑布方法开始切入主题，介绍了敏捷方法的缘起、敏捷的价值观和原则，并给出了一个典型的敏捷商业案例。第二部分详细介绍了Scrum 的历史和Scrum的各种要素，包括角色、周期、工件，以及如何确定用户故事、如何估算工作，如何召开每日站立会议。第三部分则介绍了发布规划、原型、重构、测试驱动开发和结对编程等实践和方法。
当前，Scrum 方法在国内已被逐渐普及，为众多知名IT 公司和软件开发团队采用。本书内容精练，轻松易读，是帮助软件开发人员认识、初步了解Scrum 方法的佳作。通过阅读本书，你可以厘清Scrum的相关知识和概念，为采用和实践Scrum 方法做好充分准备。
版本 1.01 发布说明
你手中是《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
Scrum团队周记
现在是周一的早上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)第一部分敏捷力介绍1 起初：瀑布方法
1901年的时候，一位名叫安妮·爱德森·泰勒的63岁冒险家，把自己装进木桶从尼亚加拉大瀑布上冲下去，没有任何明确的理由。浮出水面后，除了有些轻微伤口之外，看起来别无大碍，她随后宣称“我情愿走到炮口前面，被轰成碎片，也不要再来一遍瀑布冲流。”
如果你曾参加过使用瀑布方法、乱糟糟的大型企业级软件项目，兴许就能理解安妮的感受。然而让人惊讶的是，沮丧的开发人员对安妮不幸遭遇的认同感，和瀑布这个词的本义并无关系。
Winston W. Royce在他提交给1970年IEEE WestCom软件工程会[1]议的论文中，首次提出了著名的传统瀑布方法。Royce并未使用瀑布这个词，但他确定描述了一种线性顺序流程，其中每一阶段都必须等待上一阶段结束之后才能开始。颇有点讽刺的是，Royce之所以提供这个模型，就是要拿它当靶子说明不能这样做软件开发！如图1-1所示。图1-1
Royce继续说，人们肯定不愿意按此方式操作软件项目，接着又描述了一种他宣称绝对更高级的迭代式流程，该流程跟当今的敏捷方法论很相像。然而，不知怎么的，偏偏是描述瀑布模型的部分受到听众的追捧，并由此变得广为人知。
1985年，美国国防部决定采纳瀑布方法作为旗下所有项目的官方标准，不管是政府机构还是独立防务承包商都要遵守此标准。此事件巩固了“瀑布”的地位。瀑布模型由此成为所有企业级软件开发项目的可信模型。
到了21世纪，就连政府也开始隐隐地感觉到，瀑布模型可能是[2]有缺陷的。2005年NASA一篇介绍此方法的官方文档写到，“一些大型系统的失败或取消被认为跟标准瀑布模型有关。它还非常昂贵。”文中接着还提到，“极限编程”看似很有前途。
4年后，NASA的一篇新闻采访引起了骚动，他们宣布其工程师设计发明了NASA自己的敏捷方法论，名为“大师风味极限编程[3]（Extreme Programming Maestro Style）”。我们知道，这听起来更[4]像是在In-N-Out汉堡店里合着薯条一块点餐的东西，但NASA却用来开发火星登陆者机器人的控制程序!定义瀑布
瀑布模型将开发和交付企业软件项目的流程分割为相互独立的阶段：
1．需求收集
2．设计
3．编码
4．测试
在瀑布流程中，每一步骤都必须等待前一步骤结束后才能继续，也只有等待所有步骤都结束后才有可能向客户交付价值。
在图1-1上你可以很清晰地看出“瀑布”这个名字的来由，开发流程正是从一个阶段流向下一个阶段，（往往都是不折不扣地）带着项目向下冲，不可阻挡。
瀑布方法的支持者喜欢使用这种方式的确有原因。对新手来说，用“瀑布”来安排进度和作汇报，首席执行官、首席财务官、企业律师和其他干系人在签合同与定预算的时候才能用上熟悉的工具和流程。毫无疑问，让这些家伙拥抱变化是难度很大的挑战，难度远远大过改变那些最固执的项目经理和开发人员而让他们接受敏捷。
设计方面，“瀑布”支持者所坚持的哲学是大设计前置（BDUF，Big Design Up Front），这也是众多计划驱动型软件开发方法论的普遍做法。（使用BDUF短语和简写最多的是它的批评者，发[5]音时嘴唇略微卷曲，颇像是一些学生对Big Man On Campus短语或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。[1]2 加入敏捷实践者行列
虽然现在还只是遐想，但我想我能够弄到钱先折腾个概念出来，随后再把它包装成一个好点子。——伍迪·艾伦
2001年，17位超级极客齐聚犹他州的雪鸟滑雪山庄，共同探索有关软件开发未来发展的共同理念。其中包括Scrum、极限编程、水晶、特性驱动开发等一些新生方法论的发起者，还包括Jim Highsmith所说的“寻求文档驱动型重型软件开发流程替代品的同道中人”。Jim为后人记录下了这些事件。
与会者达成了一致意见，将这场“运动”命名为“敏捷”。他们授予自己“敏捷联盟”的称号，草拟出一份言简意赅的《敏捷宣言》。联盟成员们在那个周末发现了各自哲学上的共同基础，也都体现在这份纸巾大小的文档中。但成员们并没有编纂什么实践或方法的宝典。“敏捷运动并不是要反方法论，”Highsmith写到，“事实上，我们多数都想要恢复方法论这个词的威名。我们想要恢复一种平衡。我们拥抱建模，但绝不是为了记录成图表放进企业库里积灰尘。”
这一切可不是横空出世。敏捷联盟其实是对一贯以来软件项目管理方式做出了反应：像“瀑布”那样的开发流程，把计划、设计、开发和测试分割成不同的独立步骤集，就像尼亚加拉瀑布的水一样，它们也一个接着一个顺流而下……最后在底部巨石上砸得粉身碎骨。[2]
变革的时机业已成熟。1995年Standish Group发布的年度“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、精益、极限编程，还是要糅合多种敏捷方法论创建你自己的混合方法，你都要：
边做边测试，别等到最后关头，现在就修复缺陷，等它有机会在系统里繁衍存活好几个月后，修复成本可就高了。
及早且频繁地交付产品，只有通过展示可工作软件的方式，你才能发现客户真正想要的是什么。正因为敏捷流程能够照顾到客户的持续反馈，项目才能不偏不倚地走下去；也因为只交付已完成的增量，敏捷开发才能规避项目被取消的风险，客户还能用上按期交货的软件。
文档边做边写，只写必需的文档。将文档工作融入流程，只写有关的、有效用的文档。[3]
打破筒仓（silo）构建跨职能团队，不要让任何个人或部门成为流程、信息的瓶颈。
敏捷方式的核心思想在于迅速交付商业价值，体现为可工作的软件，还要以定期增量的形式持续地交付价值。在随后的章节中我们将看到，迭代地完成开发工作，带给业务的好处不仅立即可见还会不断累积。
[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”，常译作“职能筒仓”。3 敏捷价值观与原则
重要的是，永不可依据活动或方法来定义目标。目标必须与改善人生直接相连。——威廉·爱德华兹·戴明
教大家方法进行推理并非我意，我唯一的目标就是揭露我尝试推理的过程。——勒内·笛卡儿
别被敏捷宣言的理想范儿给蒙骗，还真以为它是一群不切实际的空想家或者是象牙塔永久居民给整出来的；作者们可都是久经沙场的老兵，经历过早期软件开发茹毛饮血的时代。
他们所秉持的信条也都源自实战所学。因此，由敏捷联盟创始人所设计的这些价值观和原则才能稳稳地站住脚跟，而且，每一天你都能感受到它们是如此地适合真实世界里的软件项目。[1]
敏捷宣言由价值观和原则组成，我们逐条进行了讨论，如下是讨论的注解版记录。敏捷价值观个体和互动 高于 流程和工具工作的软件 高于 详尽的文档客户合作 高于 合同谈判响应变化 高于 遵循计划
第一次听到敏捷价值观时，你会觉得它和大多数自然而然的道理一样，简单且显而易见。敏捷联盟创始人把它用作“敏捷宣言”的第一部分内容，从发布之日起，它就一直没改过。
但是，要能够把这些价值观用于日常工作，日复一日、不畏艰险地坚持下来，需要做到禅修般严苛（Zen-like rigor）。如果你曾经历过命令与控制式的工作（或校园）环境，不管时间有多长，你都必须得针对这些价值观进行有意识的练习，直到你完全吸收它们成为第二本性为止。即便你听到敏捷价值观的悦耳声音，就已然从头到脚直到心底都兴奋得颤抖不已，也得如此。积习难改，不管是自愿或不自愿养成的习惯都一样。
如果你在命令与控制式的环境中待得太久，早已开始对他人施以号令和掌控，你也许会气急败坏地说出“等一等！给我等几分钟先……没有工具、文档、合同或计划，我们要怎么去服务真实客户啊？！？”这样的话来。
答案是：你不能。而且敏捷力也不要求你那样做。
注意这些价值观的表述方式，它说，某一个因素“高于”另一个，而非“取代”另一个，对吗？敏捷的哲学可不是“必须”、“应该”、绝对或权衡。正是因为这样，敏捷思想才如此强大、灵活，同时也相当精妙和难以把握！它没有什么规则手册，别想着依样画葫芦，只有可供吸收同化的价值观和原则。
我们接下来就一个一个地剖析敏捷价值观：个体和互动 高于 流程和工具
敏捷力的基本宗旨之一就是，干活的人最清楚该如何完成工作。比如说，你的团队总共6个人，全都赞成用计划扑克的方式做估算。现在，你筹备了一个新团队，你会指示他们必须使用计划扑克吗？如果你实行的是敏捷开发方法论，例如scrum或极限编程，答案是极其肯定的“不！”要让每一个自组织团队都选择最适合他们的工具。你问是否可以建议新团队尝试计划扑克，毕竟其他团队用得蛮好的，就让他们试用一两个sprint？当然可以！好的实践方式是在试验和犯错[2]的过程中达成决议，例如选定使用的工具，也吻合了检验和适应的流程。
这样想吧：如果你禁止或阻止试验，那么你和你团队的其他人就永远也无法得知，除了计划扑克之外是不是还有更好的工具存在。
各种敏捷工具、方法论和流程的选择非常多，你应该尽力做到都尝试一遍。
工具和流程可是很棒很有用的东西，但必须要放对地方，要让使用者来掌控它们。流程和工具必须是为人服务的，而不是反过来。工作的软件 高于 详尽的文档
这是另一句容易引起误解的金玉良言。如果文档着眼于创造价值和以有利方式推动项目进展，那就没问题。例如，对大多数产品来说，用户文档都是很有价值的组成部分。但如果关注焦点不再是产品本身，[3]而变成了流程文档，例如“你的测试规程说明报告，记得要用新封[4]皮！” ，那就有问题了。
如果在开发流程刚开始的时候，你对前期详尽文档太过投入（还记得我们之前讨论的瀑布方法里的BDUF吗？），那就会错失检验和适应的良机，无法做到不断地从错误中学习并调整流程和需求。人类天生会执著于自己辛勤工作所收获的成果，如果你写文档所用得时间堪比托尔斯泰写作《战争与和平》的话，也许你会发现自己真把这宝贝玩意儿直接就当做工作产品了。
人们普遍误以为敏捷团队是不写文档不做计划的，但实际上，敏[5]捷团队为规划和文档工作所花费的时间、精力远多于传统团队，因为计划需要不断地进行细化和更新。敏捷软件项目中的计划以各种形[6]式出现在我们身边，例如用户故事、列表（backlog）、接收测试和大型可视图表，它们组成了富沟通环境。
整个项目生命期内敏捷计划一直在积累和演变，是活物，而不是奉为典籍的大部头。这意味着，给定任何时间点，计划都能代表我们当时对项目的最佳理解，但我们仍然期待，在我们检验和适应的同时，它也在演变和改进。
那么，如果不是文档，敏捷团队该到哪里去找答案呢？你可以求助于可工作软件，它包含了最近构建、测试和集成的一切。有了可工作软件、自动化的测试、维持在最新状态的产品列表，还有积极参与的产品负责人，你就有了一切，可以尽可能有效且高效地向前进。客户合作 高于 合同谈判
敏捷价值观试图赶走前期计划的幽灵，但同时也着重强调，开发团队和客户之间要保持尽可能公开和顺畅的对话。我们都知道合同是好东西，也是必需品，一份完善的合同尤其如此，对相关各方的照顾都很周全。
敏捷联盟的创始人中，很多人都曾做过顾问，因此他们很熟悉合同型工作的缺陷所在。承包商的出价通常就是份赌注，赌他们能够在一定时间内完成工作，而利润则取决于他们能否多快好省地满足客户最低要求。你要是折腾过厨房改造，就会知道招标合同只能承载温和的对立关系。当然，合同是能够保你不被涨价困扰，但却无法避免偷工减料和最低标准施工的情况。万一，你诚实的穷承包商发现，你这人事事干涉还很挑剔让人很头疼，而他出价太低要亏到衣服都穿不起了。结果会是你支付可能拿到的最佳价格收获最好的厨房？恐怕没戏，除非承包商是你姐夫。
敏捷宣言的作者们最终得出结论，基于合同的项目侧重方向不[7]对。他们更喜欢采用时间材料模式，相关各方就像是一群合伙人，齐心协力在规定时间和预算范围内努力构建最有价值的系统。降低客户风险，不是靠前期担保方式转嫁风险给承包商，而是依靠流程中客户的持续参与，以及敏捷团队定期交付可工作软件增量的能力。
遵循尽早且频繁交付软件的敏捷框架可以带来高效率，因而保障了客户可以实现所投入时间和金钱的最大化价值回报，进一步也排除了对前期合同洽谈的需要。响应变化 高于 遵循计划
计划驱动型组织通常都有“变化控制”流程，设计的初衷很美好，预防使命蔓延、特性蔓延以及其他各种形式的超支和延时影响项目。这事值！可是，有问题。只有在变更可控的情况下，变化控制才会有效果。如果你管理的是药物测试实验室，那么确实是需要严格管控，以便确保结果的一致性。这一类项目中，不受控制的变化能让你白忙活一场。[8]
然而，软件开发和双盲药物测试稍有相似。它是充满未知数的流程，是一场发现之旅。
打个比方吧：如果你打算扬帆出航穿过英吉利海峡，登船时却只带一张图表和一个坚定的计划，那就太愚蠢了。要成功抵达多佛尔港，离开加来港时你得带上罗盘，而且，由于会受到气流和水流的影响，[9]你还需要频繁使用罗盘以修订航线。
软件开发的世界里，变化就像海上的天气一样不可避免，因而理所当然的，认为变化是好事的流程就是最好的流程。软件项目的规划必须是流动而非固定的，这是为了团队好，但主要是为了产品的好，最终是为了客户的好。因而你需要为变化做计划，还要改变你的计划。可没别的方法可以成功了，否则你最后会发现不知自己迷失在何处。
敏捷实践者乐于指出，传统软件开发方法是计划驱动，敏捷项目是规划驱动的区别。成为敏捷这回事，就是要创建一个灵活的流程，它可以预见且欣然接受变化，因而团队可以适应新需求和预期外开发。再重复一次大家非常熟悉的：检验和适应。呃，你有否注意到这句咒语在所有敏捷价值观的所有讨论中都有出现？
如果你觉得弄清楚这些价值观并不容易，那就拿支记号笔，拿张纸，用大写字母写下“检验和适应”。然后再用蓝色美纹纸胶带把这张纸贴在墙上，位置要高，要让团队里所有人都能看见，需要时用来参考。当你们不再需要参考这张纸的时候，再返回来关注价值观。
现在你应该发现，它们都言之有理的，而且用的是敏捷的方式，那就是选择一点易于管理的工作增量先做起来，接着就是持续地检验和适应！敏捷原则
敏捷原则可视为是对敏捷价值观的进一步深化和实际应用，它们[10]构成了敏捷宣言的另一半内容。我们建议把它们打印出来贴在墙上，印制在抱枕上或是喷涂在高速公路天桥上……
1．我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
2．欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
3．经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
4．业务人员和开发人员必须相互合作，项目中的每一天都不例外。
5．激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
6．不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
7．可工作的软件是进度的首要度量标准。
8．敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
9．坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
10．以简洁为本，它是极力减少不必要工作量的艺术。
11．最好的架构、需求和设计出自组织团队。
12．团队定期地反思如何能提高成效，并依此调整自身的举止表现。
接下来让我们更为详细地了解一下每条原则的内容。
1．我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
如果，如Standish Group的“Chaos”报告所言，失败的项目占20%到30%，且大多数都明显地预算超支，那么，这些项目的“最高优先级”是些什么？我们要尊重团队，别乱猜，别以为他们的最高优先级会愚钝到要“装得很忙碌消耗时间”，或是“不管最后有没有东西可交付，也要先留好退路，满足合同文字的要求”。例如“就算计划已过时也依照其内容执行”或“为了赶上干系人所设立不切实际的最后期限而日以继夜地工作”。
项目的事实（de facto）优先级是让脾气古怪的经理满意，而不是客户，你有在这样的项目里干过吗？优先级等于办公室政治。有太多要求必须出席的会议，因此你不得不待到很晚才能真正干点活？优先级等于官僚主义。虽然你知道正在开发的特性永远也无法交货，但还是低着头继续苦干？优先级等于组织一致性。
把客户放在第一位，承诺将持续交付价值，能给交付流水线带来核查和平衡，还能阻止人和组织滑向服务组织而非客户的行为模式。采纳敏捷方法的组织通常会经历显著的成长之痛，因为这些被误导的优先级类型会被连根拔起暴露得一览无遗。
2．欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。[11]
创业公司康菲尼迪的故事是我们最喜欢的科技传说之一，它们的一款软件产品鲜为人知，可能你从未听说过，叫做贝宝。刚开始的时候，康菲尼迪的核心产品是在Palm Pilots设备间实现相互“转”账的功能。创始人们毫不怀疑自己的设想，人们将会使用此技术去做重要的事情，例如借给别人20美元、分开付账等。他们还增加了邮件发送付款单的功能，作为次要特性。有意思的是，反而是这个候补队员成为了杀手级应用，所幸创始人们也拥有足够的敏捷力意识到了自身竞争优势的所在。他们因而能够彻底扭转产品的需求，把握住这个巨大的机遇。
科技巨变时有发生。竞争对手会带给市场惊喜。监管环境也会变化。经济衰退也会对行业形成打击。天才总是在黑夜之中有了新发现。团队要应对需求变化，变化再大也不至于到了要致电联邦紧急事务管[12]理署（FEMA）寻求帮助的地步。
3．经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。[13]
希拉里曾经出席过一个叫做创业周末的活动。每周五晚，上百名有理想的科技创业者齐聚于此，分享创业想法，组建小团队，经历54小时紧张忙乱的工作后，周日晚的时候，成立真正的在线创业公司。
这就是格言“时间越少，工作必须越高效”的极端案例。创业周末团队可没有时间来召开冗长的规划会议。多数团队组建不到一小时就已开始编码，从最基本的网站特性开始，产品边做边设计。周日晚的时候，所有周末刚刚组建的创业公司都会现场进行演示，但很少能做出完全运作的网络应用。
当然，你肯定不想用这种方式开发航空公司调度系统，或是金融服务数据库应用，但企业团队仍可从此案例中学到经验，那就是短周期可带来工作效率的提高。
很多团队都认为长周期sprint是走入“敏捷”的最佳起步方式，真实情况恰恰相反。短周期强迫你专注于重点，还要废除那些消耗生产力的瀑布时代积习。
裁剪冗余会议无非是让你更清楚地知道，自己每7天都必须能交付工作的软件！
4．业务人员和开发人员必须相互合作，项目中的每一天都不例外。
众所周知，当事双方都很抗拒这一点。开发人员说，业务人员总是悠悠然地问些浅薄的问题，提些愚蠢的要求。而业务人员则认为，开发人员骄傲自大还很古怪，关心代码的抽象美比关心最终产品多。
当然了，如果两大派别一个月才见面一次，猜猜看会怎样？这些判断都会变成真！定期合作能让业务人员领会到开发人员所面临的那些技术挑战和机遇。定期合作也能帮助开发人员理解并分担业务干系人所坚持的愿景。业务和开发的协作应该向芝加哥的投票学习，早协[14]作、多协作！
5．激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
软件开发并不是工业化流程，软件开发团队成员也不是在装配流[15]水线上执行刻板任务、可随意替换的无能之辈。因而程序员们才会一致抱怨，他们为了公司奋斗，公司似乎只是把他们当成没有面庞[16]的“人力资源”而已。少许开发高手则以“程序猿”称号自嘲。
好消息是，几乎所有软件开发团队都是由人类组成的，他们技术娴熟，有时很烦人但都各有独特的价值。他们都是能做到对工作满怀激情的专家人才。给他们所需的空间和自由，然后就等他们以伟大的成果作为回报。
6．不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。[17]
你曾在隔间农场环境下工作过吗？你知道的，就是所有人都坐在格子间里，通过文本和邮件与其他人进行交流，就算是都待在同一个房间内也是如此。敏捷团队则在更加开放的共享空间中工作，只要有可能都会选择口头交流的方式。为什么呢？因为敏捷力就是富沟通（communication-rich）这么一回事。[18]
纽约大学和芝加哥大学的两位心理学家进行的一次研究结果表明，人们想当然地以为，90%的情况下其他人能够看出他们邮件中的语气是讽刺还是直叙，而实际上这个数字只有56%。喜欢煲电话粥的人能做得更好些。面对面交谈时可以通过身体语言增强表达，因而效果也最好。
有些敏捷方法支持者误解了这条原则，以为分布式团队就不能“敏捷”了。可是，要注意到这条原则只不过是说面对面是最好的而已。远程方式也可以实践敏捷团队协作，只是你得格外留意如何建立沟通流。
在Agile Learning Labs，也就是我们公司，就有一名队友是通过视频会议远程加入scrum日会的。[19]
每隔一周左右，我们就会组织现身日，而且每个月的回顾会议也是所有人要到现场的。如果你的团队隔得有印度和怀俄明州那么远，那就想办法找到预算，至少让大家可以聚集到一起开项目启动会。面对面沟通最有价值的地方可以说就在于互相认识的阶段。根据我们的经验来看，团队一旦团结起来后，远程沟通也是能顺畅进行的。
7．可工作的软件是进度的首要度量标准。[20]
这条原则相当简单：布丁何味，吃过便知。不在购物单，不在菜谱，不在主勺厨房的壮丽，也不在上菜的银匙，就在布丁。
你会发现此原则直接关系到第一条原则，也即“我们最重要的目[21]标，是通过持续不断地及早交付有价值的软件使客户满意。”
8．敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
我们都经历过“关键时刻”，就是在项目结束阶段大家都待到很晚，生活就是睡觉、吃饭、工作，看似处于一种放大生产力的状态。[22]软件厂商则把此办法用到了极致。2004年，游戏发行商EA一名开[23]发人员的老婆掀起一场轩然大波，她发文章抱怨所有开发人员每周必须工作85小时的公司制度。
这就是那种“关键时刻”永存的计划表。设计师和程序员将EA告上法庭，混乱导致了这样一场价值百万的诉讼。各地的软件厂商们也开始考虑，开发人员长时间工作的习俗是否是明智之选。或许你并不知道（EA很明显不知道），超限度时长的工作实际上会降低而不是提高总体生产力。
我百思不得其解，为何软件行业集体迷失，选择这种疯狂的工作方式，尤其是历史已经证明，超负荷工作的人在任何领域都只能收获低效益。亨利·福特知道这一点，因而在盛行每周6天10小时工作制的1926年引入了5天8小时工作制，这震惊了世界。福特接受《World’[24]s Work》杂志采访时说道：“每周工资不变、工时减少的时代即将[25]到来”。他是对的，缩短工作安排，净生产力因此提高而不是降低。虽然知识型工作和生产型工作有诸多不同，但不变的是，加大投入到一定程度后，人类的认知功能就会下降，而后我们开始犯错，在软件行业这就意味着会产生更多缺陷。
9．坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
敏捷力可不是通过走捷径来加快速度的。接触过那种乱七八糟、维护很差的遗留代码库的人们，他们都可以证实，进展缓慢正是前人抄近路所导致的结果。
相比之下，当团队持续地关注设计、架构、测试和代码整洁度的时候，修改就容易得多了。这也提升了团队更快速交付价值的能力。
一些人认为，因为敏捷团队不做BDUF，所以他们这就是省去了设计和架构。不是这样的！敏捷团队一直都在做这些工作。团队引入变化时，他们在架构、设计、技术文档、测试代码覆盖率等各方面都会进行检验和适应。在项目期间，这些活动敏捷团队都比大多数传统团队都要做得更多，只不过是以即时的方式。这样一来，架构总是很适合代码的现状，不多不少刚刚好。
试读结束[说明：试读内容隐藏了图片]