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 是一个包括一系列实践和预定义角色的过程框架。
本书以一种轻松易懂、简洁精练的方式，介绍了Scrum 方法的核心要素。全书分为3 部分，共19 章。第一部分从瀑布方法开始切入主题，介绍了敏捷方法的缘起、敏捷的价值观和原则，并给出了一个典型的敏捷商业案例。第二部分详细介绍了Scrum 的历史和Scrum的各种要素，包括角色、周期、工件，以及如何确定用户故事、如何估算工作，如何召开每日站立会议。第三部分则介绍了发布规划、原型、重构、测试驱动开发和结对编程等实践和方法。
当前，Scrum 方法在国内已被逐渐普及，为众多知名IT 公司和软件开发团队采用。本书内容精练，轻松易读，是帮助软件开发人员认识、初步了解Scrum 方法的佳作。通过阅读本书，你可以厘清Scrum的相关知识和概念，为采用和实践Scrum 方法做好充分准备。
版本 1.01 发布说明Scrum要素你手中是《Scrum 要素》的首版。这段文字则是我们的骚扰型弹 窗调查，希望能收集你的反馈以便为后续版本作准备。我们想要知道， 这本书有没有什么地方让你感到兴奋、有灵感、震惊或是疑惑不解？ 你喜欢我们讲回顾会议的那一章？觉得测试驱动开发的章节讲得还 不够，或是觉得，scrum 的书里放这玩意儿干嘛呢？“scrum”没用大 写字母，你觉得很震惊？发现了排版错误还是有歧义的内容？问题很 紧急，却找不到答案？如果是这样，那就请打开Agile Learning Labs 的网站，告诉我们你的想法。
本书所引用的大量主要信息来源和其他参考资料都可以在网站上 找到，还有相关组织机构的链接，以及我们推荐进一步阅读的材料。[1]
本书的网站是www.agilelearninglabs.com/resources/the-elementsof-scrum。
推荐序Scrum要素我和徐毅开始紧密地工作在一起是在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团队周记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 起初：瀑布方法 2 加入敏捷实践者行列
敏捷价值观与原则敏捷力的商业案例第二部分 ScrumScrum历史简述Scrum角色Sprint周期Scrum工件用户故事用故事大小值估计工作第三部分 辅助性实践好吧……现在咋办？发布规划用户角色人物绘制故事地图纸上原型项目微章程重构测试驱动开发结对编程欢迎来到异步社区！ 相关资源：Scrum权威指南.pdf