内容简介 　　短短几年时间，Scrum跃升为敏捷首选方法，在全球各地得以普遍应用。针对如何用好、用巧这个看似简单的框架，本书结合故事、模型和成功秘诀三大要素，透彻讲解确保Scrum取得成功的基本要素。全书4部分共30章。在简单介绍Scrum知易行难之后，在第Ⅰ部分中阐述导入Scrum之前的准备工作。第Ⅱ部分重点介绍实战基础。第Ⅲ部分提出急救包的概念，讨论如何使每日站会富有成效，如何提出Scrum的第四个问题，如何让人们在结对编程时保持专注，增加团队新成员时应该怎么办，发生文化冲突时应该怎么办，Sprint应急过程等。第Ⅳ部分则锁定八大主题，重点介绍高级生存指南。最后在附录中概述Scrum框架，以帮助读者快速入门。　　本书适合打算实现敏捷转型并导入Scrum的所有人员阅读，比如开发人员、架构师、测试人员、经理和项目负责人，是帮助他们顺利度过Scrum第一年的理想参考书。 Authorized translation from the English language edition, entitled The Scrum Field Guide: Practical Advice for Your First Year, 1E, 9780321554154 by MITCH LACEY, published by Pearson Education, Inc, publishing as Addison-Wesley Professional, Copyright ? 2012 Mitchell G. Lacey. All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from Pearson Education, Inc. CHINESE SIMPLIFIED language edition published by PEARSON EDUCATION ASIA LTD., and TSINGHUA UNIVERSITY PRESS LIMITED Copyright ? 2014. 本书中文简体翻译版由Pearson Education授权给清华大学出版社在中国境内(不包括中国香港、澳门特别行政区)出版发行。 推荐序1 Jim Highsmith，Thoughtworks执行顾问 “Scrum真的是优雅得近乎完美。它是最容易理解的框架之一，同时也是最难以实施好的框架之一”这本启人深思的、宝贵的Scrum指南开篇就是这样描述的。我见过太多团队陷入假设Scrum很简单的迷局，他们看似永远无法超越Scrum 101以更深沉的角度来理解Scrum。他们生搬硬套地进行敏捷实践，不觉得有任何讽刺意味。他们不理解变革，特别是在大型组织中，变革更难。不管如何投身于变革，道路都是曲折的，几条简单的规则远远不够。这本指南可以帮助你超越Scrum 101，稳定、现实地实施Scrum。这本书（除了附录以外）不讲基本的Scrum框架，它讲的是难点和实际的操作，帮助你和团队用好Scrum框架。在敏捷转型的过程中，应用Scrum（或者其他框架）时，有两个热点问题往往被忽略：发布计划与技术实践。Mitch一开始就明确指出，技术实践对有效实施Scrum至关重要。如同他指出的那样，如果没有坚实的技术实践，几乎不可能实现每个Sprint都提交可交付软件的目标。他的基本列表：测试驱动开发、重构、持续集成与频繁的代码提交、结对编程以及自动化集成与验收测试，很好地定义了技术实践。看见第11章的故事中的对话（每章都有一个引导故事来描述将要讨论的问题）：“但是Stephen，我们用Scrum，我不能准确告诉你我们什么时候可以完成”，我实在忍俊不禁。Stephen，当然就是在管理链中需要知道项目完成信息的经理。要想成为一个高效的敏捷领导者，需要的其中一个关键心态就是我所说的“和”的管理，即在两个看似冲突的力量中找到共同点的能力。在Scrum项目中的其中一个悖论就是在“预测性”与“适应性”之间。传统方法者倾向于站在预测性这一方，而一些敏捷方法者则倾向于站在适应性这一方。当然，秘密就在于这两者之间的平衡，即搞清楚如何在恰当的级别上同时做到这两者。在他这本书的第11章中，对于如何以 “和”的管理方式来解决这个悖论，Mitch给了我们一些很好的指导。在最近一次谈话中，有一个同事提到，他认为在Scrum实施初期中的两个关键是学习与快速致胜。在第2章中，当Mitch深入探讨对变革的管理以及在向Scrum转型的过程中开发学习与适应能力的时候，他同时提到这两点（表明它们是多么的重要）。在Mitch描述的深受欢迎的John Kotter的变革管理系统中，快速致胜是其中的一个要点。本书的另外一个亮点就是这些短小的章节，都分别专注于一个主题，通过倡导一个关键的实践，把基本的Scrum框架变成一个可操作的框架。这些主题的范围广泛，从讨论Scrum的价值，到定义Scrum的角色、计算速率、确定Sprint的长度、分解用户故事、主持客户的审核会议。书中另外还有一章令人陶醉，第7章定义了“完成”的真正含义，这是Scrum项目取得成功的根本。对于任何一个正在实施Scrum或者是其他任何敏捷方法的人，Mitch的这本书绝对可以帮助你实现从优雅的简单性转为有效的实际成果。它可能不会把困难的事情变得更容易，但至少你会看得更清楚。　　 推荐序2 Jeff Sutherland，Scrum公司 Mitch和我一起工作了很多年，为开发人员培训Scrum。因为敏捷实践（75%为Scrum）已经成为全球最主流的软件开发模式，学习这本书可以帮助用户克服在过去十年中出现的最大的挑战。在敏捷宣言发布的十年之后，原来的一些签署人以及更多敏捷思想领袖在犹他州的雪鸟度假村聚会，这次是为敏捷软件开发所十年做回顾会议。他们庆祝了应用敏捷方法进行产品开发取得的成功，检讨必须克服的障碍。他们一致同意未来十年的四个成功关键如下。 1. 追求技术卓越。 2. 推动个人变革，进而引领组织的变革。 3. 建立知识体系，加强教育。 4. 在整个流程中最大化价值创造。让我们看看Mitch的这本书可以怎么帮助你成为一个敏捷的领导者。追求技术卓越引爆互联网和智能手机应用的一个关键因素就是用小的增量来部署应用，从最终用户那里得到快速反馈。这在敏捷中得到了规范，即在短期Sprint中开发产品，常常是一个月或者是更短时间但更常见的两个星期中。在敏捷宣言中，我们这样表达这个问题：“相比复杂的文档，我们给予可工作软件更多的价值。” 敏捷宣言十年回顾得出结论，就是大多数敏捷团队的短期Sprint开发仍然困难重重（通常因为管理层、业务部门、客户以及开发团队并不想追求技术卓越）。工程实践是软件开发的基石，17%的Scrum团队在实施Scrum的同时实施XP工程实践。第一个这样做的团队出现在1993年，那时XP都还没有出现。这对于职业工程师来说，只是一些常识而已。 Mitch在第1章中说道，一些特定的XP实践是必不可少的，比如：可持续的步伐、代码集体所有、结对编程、测试驱动开发、持续集成、代码规范以及重构。这些都是技术卓越的基石。使用Scrum但不用这些工程实践的61%的敏捷团队应该仔细读读Mitch的这本书，并遵循他的指导。缺乏工程实践正是他们在Sprint结束时不能产生可交付代码的原因。 Mitch的书中还有更多对技术卓越的指导，敏捷领导者，不管是从事管理工作还是技术工作，都应该追求Mitch如此清楚表达出来的技术卓越。推动个人变革，进而引领组织的变革除了技术卓越以外，采用敏捷还需要能够对变化的需求做出快速响应。这就是敏捷宣言的第四个原则：“响应变化优于遵循计划。”但是，个人适应变化远远不够。组织也必须有能够敏捷的响应变化的组织结构。如果不是这样，它们将因为无法消除阻挡前进的障碍而摧毁高效团队或限制高效团队的产生。 Mitch一步一步地解释了哈佛商学院提出的成功应对变革的关键因素。这里还需要有一种紧迫感。没有它，变革就不可能。敏捷领导者需要适应这个现实。指导委员会对于制度变革至关重要。敏捷领导者需要确保管理层受教育、培训、支持并参与Scrum实施。建立一个愿景并授权是成功的基石。独裁的决策以及控制与命令式管理必定会扼杀敏捷的效力。敏捷领导者需要通过计划短期的胜利、巩固提高、消除障碍、新方法制度化来避免这些灾难。敏捷领导者需要成为管理层的一部分或给管理层培训工程实践，Mitch这本书可以帮助你发现你需要做什么以及怎么做。建立知识体系，加强教育大多数经理和很多开发人员都不是特别了解团队和生产力。Mitch在整本书中都在讨论这些问题。软件开发固有的不可预测性很少有人知道Ziv法则，即软件开发是不可预测的。全球范围内大量项目的失败率在很大程度上就是因为缺乏对这个问题的理解以及正确处理这个问题的方法。Mitch描述了对持续的变化进行检查与调整的需要。这本书中的策略可以帮助你避免很多陷阱，消除Scrum实施过程中的很多障碍。用户在看见可工作的软件之前并不知道自己真正需要什么传统项目管理错误地假设在构建软件之前用户知道自己需要什么。这个问题被正式称为“汉弗莱法则”，该法则在大学教育以及经理与项目领导者的行业培训中被忽视。这本书可以帮助你从容面对这个问题。组织结构会被嵌入代码中人们普遍不理解的第三个主要问题是柯维法则。组织的结构会体现到代码中。一个传统的层级组织结构会对面向对象的设计有负面的影响，会导致脆弱的代码、坏的糟糕的架构设计、很差的可维护性与适应性以及过度的成本与过高的失败率。Mitch花了大量的时间来解释如何正确建立Scrum组织。要仔细研读！在整个流程中最大化价值创造如果准备好产品列表，就可以使用敏捷实践轻易提高一倍或两倍生产力，并且在每个Sprint结束时交付可工作的软件。生产力提升为组织的其他部分带来问题，使其缺乏敏捷变得更明显，让他们更痛苦。运营与基础设施缺乏敏捷一旦人力与资源用于改善产品列表，流向生产系统的软件的速度至少会加倍，有些情况下可以是5～10倍之多。这就暴露了这样一个事实：开发运营与基础设施拖慢了生产系统，必须要修正。管理、销售、市场以及产品管理缺乏敏捷在流程的前端，商业目标、战略以及目的常常都不清楚。这导致即使软件的产量翻倍了，收入流出却下降或没有增长。因此，组织中的每个人都需要接受如何在整个价值流中优化性能的教育与培训。敏捷个人需要通过提高其组织知识的能力并培训整个组织来引导这个教育的流程。底线很多Scrum实施取得的提高很有限，并且发现很难消除使他们陷入持续挣扎的障碍。应该可以做得更好。所有的团队都可以做得很好，很多团队可以做得很优秀！工作可以很有趣，业务可以是盈利的，客户可以真的高兴！如果你准备搞Scrum，Mitch的这本书可以帮助你。如果你正在实施过程中挣扎，这本书对你的帮助更大。如果你已经做得很好，Mitch可以帮助你做得更好。改进是永无止境的，Mitch的洞察力真正很有帮助。 . 译者序傅勃(Brain) 敏捷开发，特别是Scrum，已经成为很多组织进行软件开发的默认方法。但是有多少团队因此成为了高效率团队呢？如果你是这样的团队，那么真的要恭喜你，这确实是一个很难达到的状态。如果还不是一个高效率团队，你一定会有不少的困惑。很多Scrum团队和你的团队一样，在经历初期的提高之后，很快就陷入效率提升的瓶颈。是敏捷方法言过其实，还是我们学艺不精？ Ken Schwaber和Jeff Sutherland在《Scrum指南》（Scrum Guide）中仅仅用13页的篇幅（2013年版）就定义了Scrum框架，这可能也是软件开发中最精炼、最简单的方法之一。也许正因为这样的简单性，才造就了我们在实践中的五彩缤纷。其中，一些人和团队在浅尝辄止之后，就认为Scrum不过尔尔；也有一些人和团队在未能显著提高效率之后，对Scrum产生了质疑；还有一些组织，其文化与敏捷格格不入，Scrum团队要么被迫成为（短命的）独立王国，要么仍然屈从于命令式管理的淫威。这些情况其实都不意外，正如Mitch在第1章中指出的那样，Scrum是最容易理解的框架之一，同时也是最难以实施好的框架之一。我认为Scrum与敏捷虽有其固然的局限性，但仍不失为我们“武器库中的杀手锏”（Mitch在本书中称为“工具带中的工具”）。相比动辄就归咎于方法本身，我们作为敏捷实践者应该具有开放、谦虚和学习的态度。那么，在形形色色的各种具体实现以及浩瀚无边的知识海洋中，我们如何才能做到大浪淘沙、去伪存真，以他山之石攻玉呢？依我愚见，有两个判断标准。Scrum与敏捷的实践虽然具有多样性，但是万法归宗，其核心与精髓就是它们的原则与价值观，这被很好地总结在众人皆知的敏捷宣言中。窃以为敏捷宣言应该是敏捷实践者信奉的圣经。同时敏捷也是一个开放的社区，《Scrum指南》开宗明义地指出Scrum是基于经验流程的控制理论。所以，第二个鉴别的标准就是各种具体的理论与方法是否来源于实践，是否能够应用于你的实践。 Mitch首先在第1章中诠释了Scrum依据的价值观以及实施Scrum所需要的条件。如果你的组织与团队不符合这些价值观，不具备这些条件，也许需要降低期望值或者考虑放弃Scrum。在现实中很多在困境挣扎的团队，他们的命运也许在此已经注定。在随后的章节中，Mitch介绍的每一个方法都提炼自他个人亲身的经历，并成功应用于他的实践中。难能可贵的是，其中的一些方法还来源于软件开发领域的一些理论与实证研究，或者是从中得到佐证。他这些方法要解决的场景与困难，在我读起来总是感到似曾相识。我相信你在阅读此书的时候也会感同身受。虽只是翻译，也得一字一字地码出来，个中辛苦不以言表。这个过程感觉是回到当年写程序的时候，忍不住改来改去，但很难完全令人满意。因时间仓促，个人中英文以及敏捷实践的水平有限，错误难免，欢迎勘正。最后，希望这本书物有所值，成为你的“及时雨”，对你的实践有所启迪与帮助。 前言 我的女儿Emma（爱玛）出生于2004年末，我感到力不从心，我们在医生办公室的时间似乎多于与其他孩子在一起的时间。我一直问我妻子：“这是正常的吗？”一个晚上，我在枕头边上发现我妻子那本书《新生儿父母手册》，里面有她写的一张小纸条：“读读这本书，你会好受一点。” 我读了。由此我知道了我们所经历的每件事情对于我的孩子都是正常的，即使对我或我以前观察到的来说不常见。这使我感到更有信心与安全感。这也正好是我开始试验Scrum与敏捷的时间。随着我开始遇到障碍与面临不熟悉的情况，我开始认识到，在做Scrum与敏捷的第一年，我真正需要一本指导手册。问题在于，不像一本指导手册，我不可能准确告诉你，在第1～3月或者9～12月，你的团队应该做什么或者是应该担心什么。团队并不像小孩那样，不会以一个可以预测的速度发展。相反，在他们第一年的实践中，随着他们学习团队合作、采用敏捷工程实践、与他们的客户建立信任、以增量迭代方式工作的过程中，他们常常摔倒、蹒跚、犯错误，前进两步就倒退一步。有鉴于此，我更倾向于以这种方式“我遇到了一个问题，该怎么办”来组织这本书。我收集了我参与过或者见证过的、在他们第一年敏捷旅途中的那些团队的故事。随着我继续我的敏捷旅途，我注意到各个公司中这些故事、模式通常都很相似。我在一个公司中实现一个想法，稍微调整一下就可以应用在下一个公司中。重复这个过程，我得以收集了这些现实世界的解决方案，并把它们加入我随身携带的虚拟工具带。在这本书中，我将与你分享一些最常见的痛苦与解决方法。当你的团队遇到麻烦或者是受伤的时候，你可以找到最接近你的症状的那一章，然后你可以发现，即使不能解决你的问题，至少也有一个办法可以减轻你的痛苦。《Scrum实战》旨在帮助你精心调试你自己的实践，在一些你不熟悉的领域提供指南，以及在前进的道路上更轻松地克服我们都遇到过的困难。谁应该读这本书如果你正在考虑开始Scrum或者敏捷的实践，或者刚刚开始你的旅途，或者已经实践了一年左右但却感觉好像迷失了方向，这本书就是为你准备的。我正式的目标群体就是，从那些在六个月以内将开始他们的项目，到那些已经实践了一年的公司，即有18个月的时限。这本书是为推崇实践的人准备的。如果你想学习理论或者是高深的讨论，可以从很多优秀的Scrum和敏捷的书籍中找到一本。另外一方面，如果你想寻求基于我在微软做过的项目以及我在福布斯100强的大型公司指导顾问过的团队的实践建议与真实数据，这本书会物有所值。怎样阅读这本书设计这本书是为了方便你在任何时间以任何顺序阅读任何章节。每一章都以一个故事开始，这些故事都是从我工作过的或者是指导过的团队、公司、项目中提取出来的。可以想象，为了保护那些清白的（或者是犯错的）人，我改变了他们的名字。在你看过这些似曾相识的故事后，我会介绍一个模型。这些模型是我在实战中用来帮助解决故事中存在的问题的。一些模型你可能会感到不太舒服，或者是认为对你的公司可能不适用。我强烈要求你反抗你的忽视建议或者是修改模型的直觉，至少努力尝试三次，然后看看结果如何，你可能会对结果感到惊讶。在每章的最后，我总结了成功秘诀，这些因素事关实践成败。这本书组织为四部分。第Ⅰ部分“战前准备”，对你准备开始使用Scrum提供建议，帮助你为成功做好准备。如果你正在考虑Scrum，或者是刚刚开始使用Scrum，就从这里开始。第Ⅱ部分“战地基础”，讨论的话题可以帮助你克服开始敏捷的旅途之后团队与组织会遭遇的初步障碍。如果已经开始了Scrum的实践，但是遇到了困难，你可以从这里开始。第Ⅲ部分“战地急救”，着眼于解决公司所面临的一些更大、更深层次的问题，比如往项目中增加人手或者是解决每日站会的功能失调。这些都是在第一年实践中某个时候很可能会遇到的情况。这几章可以帮助你诊断并处理这些情况，使团队恢复到健康的状态。最后一部分即第Ⅳ部分“高级生存技术”，讨论人们在实践Scrum的任何阶段都常常挣扎的一些话题。比如，项目成本、合同的制定、敏捷项目与Scrum项目中的文档等。如果你是从头开始，对Scrum还一无所知，我在本书的附录中包括了一个对Scrum的简短介绍，旨在帮助你熟悉这些术语与概念。在开始研究这本书之前，你可能还需要多了解一下Scrum。为什么需要阅读这本书不管你在敏捷旅途中身处何地，我们都需要一个友好的提醒，即我们的遭遇是正常的，它为我们提供了解决这些问题的建议和一些成功秘诀。这本书把这些东西都组织在一起，方便你根据具体需要选择阅读需要的章节或者整个部分或者全书。这是真实生活中的情况，可以与你产生共鸣，它的解决方法可以应用于任何团队。打开书开始阅读这些故事，这本书将是你经历Scrum与极限编程之高潮与低谷的忠实伴侣。 本书的补充材料在你阅读本书的过程中，你可能会想：“我真希望有个工具或者是可以下载一个模板来帮助我实践这个概念。”很在多情况下，这是可以的。访问http://www.mitchlacey.com/supplements/，你可以看到我在我每天的Scrum项目中用到的一系列文件、图片、Excel表格以及工具。尽管其中一些信息是精心准备过的，但大多数东西还很简陋。为什么？在我的项目中，我不需要它们很完美，我只需要它能实现功能。你在我的网站上得到的将是第一手的、真实的、偏重实战且有用的东西。 致谢 在我第一次想写这本书的时候，我的想法还很原始，我还不知道这是一项艰巨的工程。我的妻子Bernice（柏妮丝），让我有时间专注于这本书，我的孩子也是这样。没有她们的支持，就不会今天有这本书。 David Anderson、Ward Cunningham与Jim Newkirk帮助我和我在微软的第一个团队开始了我们的敏捷之旅。他们每个人当时都在那里工作，指导我们经历了一些艰难的时期。现在回头看看早期与Ward讨论的一些笔记，其中一个是重点显示的问题：“我们能不能不做TDD？”他们每个人都在帮助我们团队从不适应变成一个真正特别的团队。David、Ward和Jim，谢谢你们。我要感谢Mike Cohn与Esther Derby，他们让我得以在2006年敏捷大会上就我的初步想法向他们征求意见。Mike后来继续支持我，我们经常开玩笑，我的书会比他的《Scrum敏捷软件开发》更早问世。当这个目标没有实现之后，他提议我，一个更好的目标是在他成为祖父之前完成这本书。嗯，Mike，我做到了，而且还是在你大女儿在上高中的时候，我实现了我的目标。没有Rebecca Traeger的帮助，我也无法完成此书，她是这个星球上最好的编辑。她使我保持正确的方向并专注于此，帮助我把我原始的想法与文字变成浑然一体的章节。我还要感谢帮助我精心写就今天这本书的所有朋友。列在这里的每个人都给予我有价值的反馈并抽出很多时间听我总结自己的想法或者阅读草稿。我对你们每个人的感谢溢于言表，他们包括Tiago Andrade e Silva，Adam Barr，my artists Tyler Barton and Tor Imsland，Martin Beechen，Arlo Belshee，Jelle Bens，John Boal，Jedidja Bourgeois，Stephen Brudz，Brian Button，Mike Cohn，Michael Corrigan，Scott Densmore，Esther Derby，Stein Dolan，Jesse Fewell，Marc Fisher，Paul Hammond，Bill Hanlon，Christian Hassa，Jim Highsmith，Donavan Hoepcke，Bart Hsu，Wilhelm Hummer，Ron Jeffries，Lynn Keele，Clinton Keith，James Kovaks，Rocky Mazzeo，Steve McConnell，Jeff McKenna，Ade Miller，Raul Miller，Jim Morris，Jim Newkirk，Jacob Ozolins，Michael Paterson，Bart Pietrzak，Dave Prior，Michael Puleio，René Rosendahl，Ken Schwaber，Tammy Shepherd，Lisa Shoop，Michele Sliger，Ted St. Clair，Jeff Sutherland，Bas Vodde，and Brad Wilson。我还要感谢Addison-Wesley的团队，包括Chris Zahn与Chris Guzikowski。Chris Zahn让我质疑自己写的所有东西，使我从另外一个角度来思考我的观点。即使在我错过了计划日期的两年之后，Chris Guzikowski仍然没有放弃我。我感谢你的团队指导我经历整个过程。写作并不只是一个将头脑中的想法跃然纸上的过程。就像我经历的很多项目一样，这真的是集体努力的成果。我所提到的这些人（以及我很可能遗漏掉的一些人）倾听我的想法，在我迷失的时候提醒我，给我提供好的想法以便对团队与客户进行实践并在我需要有人审核的时候自告奋勇。我可以想象，他们和我一样高兴这本书终于付梓印刷。我希望在你读到此处的时候，也会像我一样我感谢他们为这本指南面世所做的贡献。 关于作者 Mitch Lacey是一名敏捷实践者与顾问，也是软件咨询与培训公司Mitch Lacey & Associates公司的创办人。Mitch擅长于帮助各种公司通过采用Scrum与极限编程等敏捷原则与实践来提高效率。 Mitch自称“技术宅男”，在1991年从计算机游戏公司Accollade Software开始他的技术生涯。在担任软件测试工程师、测试经理、开发人员以及期间各种不同角色之后，他开始了自己职业生涯中最重要的工作，即项目管理与项目群管理。在把敏捷加入他的项目工具带之前，Mitch是一个接受过正规培训的项目群经理。他在微软开始发展敏捷的技能，他的团队为Windows Live成功发布了核心企业服务。Mitch的第一个敏捷项目是由David Anderson、Ward Cunningham与Jim Newkirk指导的。Mitch在各种不同的项目中担任产品负责人或者是ScrumMaster，积累了很多第一手的敏捷经验。他继续发展其敏捷技能，直至他可以帮助其他团队采用敏捷实践。时至今日，他已经有超过16年的经验，Mitch通过在很多不同组织的项目团队中试验与实践来继续研磨他的技艺。作为一名认证Scrum培训师（CST）与PMI项目管理专业人士（PMP），Mitch通过ScrumMaster认证培训课程、敏捷导入服务合同、大会演讲、博客以及白皮书来分享他在项目管理与客户管理方面的经验。Mitch与全球各地的公司合作，从澳大利亚到哥伦比亚，从加利福尼亚到佛罗里达，从葡萄牙到土耳其，以及欧州各国。 Mitch在全球各种大会上发表演讲，他还是2012敏捷大会的主席，敏捷联盟与Scrum联盟的董事会成员。更多的信息，可以访问www.mitchlacey.com。在那里可以找到Mitch的博客以及各种文章、工具与视频，这些东西都有助于你采用Scrum与敏捷。还可以用@mglacey(Twitter)或者电子邮件mitch@mitchlacey.com联系他。 目录 第1章 Scrum：知易行难 1 故事 1 Scrum 9 什么是Scrum 9 实施Scrum 11 Scrum适合我吗 18 变化是困难的 19 实践与集成 22 新的现状 22 成功秘诀 23 引用 24 第Ⅰ部分 战 前 准 备 第2章 取得大家的支持 29 故事 29 模型 38 变革需要时间 39 建立紧迫感 40 成立一个强大的指导联盟 40 建立一个愿景/绘制未来的蓝图 41 沟通愿景 41 授权人们为愿景采取行动 42 计划并创造短期成功 43 进一步改善，巩固成效，继续深化改革 43 制度化新的方式方法 44 成功秘诀 44 耐心 44 提供信息 45 引用 45 第3章 用团队顾问来优化团队表现 47 故事 47 模式 54 建立一个团队顾问池 55 建立团队 57 团队大小 60 成功秘诀 63 责任 63 试验 64 小心过度 64 计划可能的空闲时间 65 团队顾问不应替代专职团队 65 第4章 确定团队的速率 67 故事 67 模型 74 使用历史数据的问题 74 为拍脑袋增加一些依据 76 计算平均速率，但要对范围进行交流 81 截断数据 83 成功秘诀 85 引用 86 第5章 Scrum的三大角色 87 故事 87 模型 92 选择角色 94 组合角色 95 如果实在万不得已，又该何时组合这三大角色 98 成功秘诀 98 第6章 确定Sprint的长度 101 故事 101 模型 105 项目期限 106 客户/项目干系人组 107 Scrum团队 108 确定Sprint的长度 109 警告 112 问卷之外 113 成功秘诀 113 长于4周的Sprint 114 延长Sprint长度 115 引用 115 第7章 我们如何知道何时才算完成 117 故事 117 模型 119 介绍 120 头脑风暴环节 121 分类环节 122 排序与整合环节 124 生成DoD 126 没有完成的工作呢？ 126 成功秘诀 127 引用 127 第8章 全职的ScrumMaster 129 故事 129 模型 133 成功秘诀 141 消除障碍/解决问题 141 结束争论/当团队的保姆 142 报告团队的行为表现 142 引导并在必要时提供帮助 142 教育组织并驱动组织的变革 144 结语 144 引用 145 参考 145 第Ⅱ部分 战 地 基 础第9章 Scrum中工程实践的重要性 149 故事 149 实践 155 实施测试驱动开发 156 重构 158 持续集成，随时了解系统的状态 159 结对编程 161 自动化集成与验收测试 163 成功秘诀 165 不是银弹 165 开始行动 165 获得团队的支持 166 DoD 166 把工程实践加入产品列表 166 获得培训与指导 166 结语 166 引用 167 参考 168 第10章 核心团队时间 169 故事 169 模型 173 在一起工作的团队 174 分布式团队与兼职的团队 175 成功秘诀 178 第11章 制定发布计划 181 故事 181 模型 186 画出初步的路线图 187 加上一个信心程度 189 得到日期并根据需要进行调整 190 在项目过程中维护发布计划 193 确定项目的结束 194 成功秘诀 196 事先进行沟通和交流，并且要频繁 196 每个Sprint后都更新发布计划 196 努力先做优先级最高的条目 197 更新对大条目的估计 197 交付可工作的软件 197 Scrum与发布计划 197 引用 198 第12章 分解故事与任务 199 故事 199 模型 203 做好准备 203 故事分解 204 任务分解 208 成功秘诀 211 引用 213 参考 213 第13章 缺陷管理 215 故事 215 模型 217 成功秘诀 220 引用 221 参考 221 第14章 可持续工程与Scrum 223 故事 223 模型 227 专用时间模型 227 随着时间收集的数据 228 专职团队模型 229 成功秘诀 231 专职维护团队成员的轮换 232 用良好的工程实践来改进遗留代码 232 结语 232 引用 233 第15章 Sprint审核会 235 故事 235 模型 240 准备会议 241 进行会议 242 成功秘诀 243 花时间准备 244 记录决策 244 要求认可 245 勇敢 245 参考 246 第16章 Sprint回顾会 247 故事 247 实践 251 回顾会议的检查作用 251 计划一个有效的回顾会议 252 召开回顾会议 254 成功秘诀 256 告诉他们为什么要保留回顾会议 257 营造一个良好的环境 257 有需要就开 258 高度重视回顾会议 258 引用 259 第Ⅲ部分 战地急救第17章 富有成效的每日站会 263 故事 263 模型 268 开会的时间 268 准时开始和结束 269 暴露隐藏的障碍 272 结束就意味着开始 273 成功秘诀 273 保持会议的周期 273 站着，不要坐 274 团队工作方式 275 耐心 276 第18章 Scrum的第四个问题 277 故事 277 模型 281 成功秘诀 282 引用 283 第19章 真正参与结对编程 285 故事 285 模型 288 无序结对编程 289 微结对 291 成功秘诀 294 引用 295 第20章 新增团队成员 297 故事 297 模型 300 练习 303 成功秘诀 304 承认速率会下降 304 明智地选择新成员 304 风险 305 引用 305 第21章 当文化有冲突的时候 307 故事 307 模型 314 成功秘诀 320 掌握自己的命运 321 面对现实 321 坚持到底 323 引用 324 参考 324 第22章 Sprint急诊现场 325 故事 325 模型 328 消除障碍 329 获得帮助 330 缩小范围 330 取消Sprint 331 成功秘诀 332 引用 333 第Ⅳ部分 高级生存术第23章 可持续的步伐 337 故事 337 模型 343 缩短迭代周期 347 监测燃尽图 348 增加团队时间 349 成功秘诀 350 引用 351 第24章 交付可工作的软件 353 故事 353 模型 359 核心故事 359 用户数 360 从风险最高的组件开始 361 扩展和验证 362 成功秘诀 363 思维的改变 363 返工 364 专注于端对端的场景 365 参考 366 第25章 价值的度量与优化 367 故事 367 模型 371 功能工作 371 额外工作 372 试验 373 必要性工作 374 缺陷 374 组织数据 375 使用数据 375 成功秘诀 376 教育项目干系人 376 和项目干系人一起工作 377 确定模式与趋势 377 参考 377 第26章 项目成本预算 379 故事 379 模型 386 功能规范 386 用户故事 387 估算用户故事 388 确定用户故事的优先级 389 确定团队的速率 390 计算成本 390 制定发布计划 391 成功秘诀 391 引用 392 第27章 Scrum项目的文档 393 故事 393 模型 397 我们为什么要写文档 398 做什么文档 399 文档什么时候写？如何写 400 敏捷项目的文档 404 没有大量文档就开始项目 405 成功秘诀 406 引用 407 第28章 外包与离岸开发 409 故事 409 模型 413 考虑实际成本 413 面对现实 416 成功秘诀 418 选择合适的离岸团队 418 以痛苦最小的方式分配工作 419 坚守Scrum框架 420 建立团队文化 421 准备差旅 422 配备一个项目/团队协调人 423 绝不考虑离岸的情况 423 引用 424 参考 424 第29章 大型列表的优先级确定与估算 425 故事 425 模型 429 团队 431 项目干系人 432 成功秘诀 435 预先计划至关重要 435 专注于讨论并设定时间限制 435 为未解决的争议使用停车场 436 带上额外的卡片/纸张以备现场产生用户故事 437 提醒团队事情会变 437 引用 438 第30章 拟定合同 439 故事 439 模型 444 传统的合同与变更要求 445 时机 449 范围与变化 451 成功秘诀 455 客户的配合 456 验收窗口 456 优先级 457 终止条款 457 信任 458 引用 458 附录 Scrum框架 459