《敏捷软件开发 : Scrum实战指南》

敏捷软件开发

Scrum实战指南

(第2版)

[美]米奇·莱西(Mitch Lacey)      著

王国良  熊小龙  叶虎  郑璐璐    译

清华大学出版社

北京

推荐序１：追求技术卓越，创造最大价值

多年来，Mitch和我一起培训开发人员使用Scrum。随着敏捷实践(75%为 Scrum)成为全球最主流的软件开发模式，学习这本书可以帮助使用者克服在最近几年中出现的最大的挑战。

在《敏捷宣言》发布的十年之后，原来的一些签署人以及更多敏捷思想领袖在犹他州的雪鸟度假村聚会，对敏捷软件开发十年进行反思。他们庆祝了应用敏捷方法进行产品开发所取得的成功，回顾了取得类似成功必须要清除的关键障碍。由此，他们一致认为未来十年的须具备以下四个成功要素。

1. 追求技术卓越。

2. 推动个人变革，进而引领组织变革。

3. 整理知识，加强教育。

4. 在整个流程中将价值创造最大化。

让我们看看Mitch这本书怎么帮助你养成敏捷领导力。

追求技术卓越

引爆互联网和智能手机应用的一个关键因素就是用小的增量来部署应用，并从最终用户那里得到快速反馈。这一流程在敏捷中得到了规范，即在短期 Sprint 中开发产品，Sprint长度常常是一个月或者是更短时间，更常见的是两个星期。在《敏捷宣言》中，我们如此表达这个问题：“相比于详尽的文档，我们更看重可工作的软件。”

《敏捷宣言》十年回顾得出结论，就是大多数敏捷团队的短期 Sprint产品开发仍然困难重重(通常因为管理层、业务部门、客户以及开发团队并不追求技术卓越)。

工程实践是软件开发的基石，17%的 Scrum 团队在实施 Scrum 的同时实施 XP 工程实践。第一个这样做的团队出现在 1993 年，那时XP还没有出现。这对于职业工程师来说，只是一些常识而已。

Mitch 在第 1 章中说道，他认为一些特定的 XP 实践是必不可少的，比如：可持续的步伐、代码集体所有、结对编程、测试驱动开发、持续集成、代码规范以及重构。这些都是技术卓越的基石。使用 Scrum 但不用这些工程实践的 61%的敏捷团队应该仔细读读 Mitch 的这本书，并遵循他的指导。缺乏必要的XP工程实践正是他们在Sprint 结束时不能产生可交付代码的原因。

Mitch 的书中还有更多对技术卓越的指导，敏捷领导，不管是从事管理工作还是技术工作，都应该追求 Mitch 如此清楚表达出来的技术卓越。

推动个人变革，进而引领组织的变革

除了技术卓越以外，采用敏捷还需要能够对变化的需求做出快速响应。这就是敏捷宣言的第四个原则：“响应变化高于遵循计划。”但是，个人适应变化远远不够。组织也必须有能够敏捷地响应变化的组织结构。如果不是这样，它们将因为无法消除阻挡前进的障碍而摧毁高效团队或制约高效团队的产生。

Mitch 一步一步地解释了哈佛商学院提出的成功变革的关键因素。这里还需要有一种紧迫感。没有它，变革就不可能。敏捷领导者需要对此身体力行。指导委员会对于制度变革至关重要。敏捷领导者需要确保管理层受到教育、培训、支持并参与 Scrum 实施。

建立一个愿景并为其他人赋能是成功的基石。独裁的决策以及控制与命令式管理必定会扼杀敏捷的效力。敏捷领导者需要通过计划短期的胜利、巩固提高、消除障碍以及制度化新方法来避免这些灾难。敏捷领导者需要成为管理层的一部分或给管理层培训工程实践，Mitch这本书可以帮助你发现你需要做什么以及怎么做。

整理知识，加强教育

大多数经理和很多开发人员都不是特别了解团队和生产力。Mitch在整本书中都在讨论这些问题。

软件开发固有的不可预测性

很少有人知道 Ziv 定律，即软件开发是不可预测的。全球范围内大量项目的失败在很大程度上就是因为缺乏对这个问题以及正确处理这个问题的方法的理解。 Mitch 描述了对持续的变化进行检查与调整的需要。这本书中的策略可以帮助你避免很多陷阱，消除Scrum 实施过程中的很多障碍。

用户在看见可工作的软件之前并不知道自己真正需要什么

传统项目管理错误地假设在构建软件之前用户知道自己需要什么。这个问题被正式称为Humphrey定律，该法则在大学教育以及经理与项目领导者的行业培训中被整体上忽视。这本书可以帮助你从容面对这个问题。

组织结构会被嵌入代码中

人们普遍不理解的第三个主要问题是Conway定律。组织的结构会体现到代码中。一个传统的层级组织结构会对面向对象的设计有负面的影响，会导致脆弱的代码、糟糕的架构设计、很差的可维护性与适应性以及过度的成本与过高的失败率。Mitch 花了大量的篇幅来解释如何正确建立 Scrum 组织。一定要仔细研读！

在整个流程中创造最大价值

如果准备好产品Backlog，并且在每个 Sprint 结束时交付可工作的软件，软件开发团队就可以使用敏捷实践轻易提高一倍或两倍生产力。生产力提升为组织的其他部分带来问题，使其缺乏敏捷变得更明显，让他们更痛苦。

运营与基础设施缺乏敏捷

一旦人力与资源用于改善产品Backlog，流向生产系统的软件的速度至少会加倍，有些情况下可以是 5～10 倍之多。这就暴露了这样一个事实：开发运营与基础设施拖慢了生产系统，必须要修正。

管理、销售、市场以及产品管理缺乏敏捷

在流程的前端，商业目标、战略以及目的常常都不清楚。这导致即使软件的产量翻倍了，利润流却下降或没有增长。

因此，组织中的每个人都需要接受如何在整个价值流中优化绩效的教育与培训。敏捷个人需要通过提高其组织知识的能力并培训整个组织来引导这个教育的流程。

底线

很多 Scrum 实施取得的提高很有限，并且发现很难消除那些使他们陷入持续挣扎的障碍。应该可以做得更好。所有的团队都可以做得很好，很多团队可以做得很优秀！工作可以很有乐趣，业务可以是盈利的，客户可以真的满意！

如果你准备搞 Scrum，Mitch 的这本书可以帮助你。如果你在实施过程中苦苦挣扎，这本书对你的帮助更大。如果你已经做得很好，Mitch 可以帮助你做得更好。改进是永无止境的，Mitch 的洞察力真的对大家有实际的帮助。

推荐序2：一本真正的实战指南

1988年，Smalltalk研究团队从Xerox PARC研究中心(Palo Alto Research Center)分离出来之后，我是ParcPlace Systems雇佣的第一个员工。我们的任务是将面向对象技术的使用商业化。在对象技术运动的早期阶段，我们经常讨论编写一种类似食谱的书，用来帮助公司开始使用对象技术。我们的想法是收集我们看到的公司遇到的最重要的情况/问题，并将它们作为一组模式或菜谱呈现出来，格式是“如果你发现自己处于这种情况下，试着做下面的……”然而我们从来没有写过那本书。

时光荏苒，二十年过去了，我们来到敏捷开发的时代，Mitch Lacey已经写了自己的书：关于Scrum主题的一本实战指南，与准备使用Scrum或者那些仍处于应用初期阶段的的公司分享他丰富的Scrum经验。

我第一次见到Mitch是在2007年，在我成为全球Scrum联盟第一任总裁之后不久。那时，Mitch已经是认证Scrum培训师(CST)，并且已经应用Scrum好多年，包括在他第一次接触Scrum的微软内部，和后来在他作为Scrum培训师和教练所服务的大大小小的公司。

我可以从我们的第一次会面上看出，Mitch对帮助人们在Scrum中取得成功充满热情。在第一次见面时，他拿出笔记本电脑，开始给我看他收集的数据。他的目标是用从他的经历中获得的真实数据来强化轶事式的成功故事。事后看来，这一交流预示着这本书的诞生。

当你读这本书的时候，你会体会到我在2007年那次谈话中以及后来我在与Mitch的多次讨论和辩论中的那种感受——因为他有敏锐的收集和分析现实世界经验并将其归纳为可执行建议的能力。在每一章中，你都会受益于这种建议。每一章的开头都是一个故事，讲述Mitch在某一特定主题上的经历。我觉得这种技法非常有效，因为我喜欢好的故事，而Mitch则是一个讲故事的高手。但是不要在读完一章的故事介绍后就停下来！故事之后是对故事中所提出的概念的扩展和解释，而这种扩展和解释详述了所提供的建议。

在阅读这本书的时候，你会注意到的一点是，Mitch并不是在教你理论。他在努力让你免于碰壁。即使是几大部分的题目，也传达了这样的意图：“战前准备”“战地基础”“战地急救”“高级生存”和“荒野必备”。一本真正的实战指南！

阅读本书的第2版也有它的好处。自从2012年第1版出版以来，Mitch就一直没有停过。这个新版本包含许多原始章节的更新版本，以及在新增的“荒野必备指南”中五个全新的章节。这些章节涉及各种各样的主题，包括如何完成工作、故事点与小时的关系、面试和招聘的技巧、如何将激励与成果结合起来，以及在敏捷开发过程中管理风险的最重要的话题。如果你已经对第1版很熟悉了，我相信你会从Mitch对新版本的修改和补充中获益！

还有，对于那些熟悉《Scrum精髓》的读者，我相信你会发现我的书和这本书相得益彰，特别是由于两者在特定的问题或方法上的不同之处。很显然，其他很多人都同意！对于第1版，你可以快速浏览一下亚马逊网站，你会发现，这本书经常和我的《Scrum精髓》一起购买。所以，就像美酒和奶酪一样，我希望你们喜欢这样的天作之合！

译者序：执柯伐柯，活出SCRUM

《诗经》里有一句话：“执柯伐柯，其则不远”，意思是说，一个人拿着斧子到树林里去砍一截树枝当斧柄，如果不知道该砍什么样的树枝合适，那么只要看一看自己手里的斧柄就知道了。我们译者团队在接受翻译任务时，当即决定用Scrum来管理我们的翻译过程，因为我们有多年的Scrum使用经验，深知Scrum是取得项目成功的助力。

在试译阶段，我们套用Scrum“完成的定义”这个概念，清晰定义了试译完成的标准，包括完成时间、质量要求、对翻译活动的问题发掘和后续基本工作原则，并以此为基础组建了一个高质量团队。

在确定要正式翻译之后，我们按Scrum的团队估算和任务认领等方式制定了发布计划。非常巧的是，发布计划刚好是100天，大致从端午节到中秋节。我们确定了完成的定义，包括结对评审和配置管理版本控制等，以保证质量。我们确定了迭代频率、协作工具、任务板的布局和发布燃尽图，以保证有效协作和对进度的准确检查和适应。翻译过程中，我们的任务板和发布燃尽图数据更新了100多版。

回到这本书本身，我们认为它是一本真正的实战指南。它有以下几个特点。第一，整本书是按话题组织的，每一章是一个话题。各个话题既相互独立，也合起来组成一个有机的整体。话题既包括一些基本的，比如Scrum工件和仪式的有效操作，也包括一些高级的，比如合同、激励和招聘等。全书提供了在真实组织环境中运作Scrum时方方面面的建议。第二，书中的建议以“模式”这种经过分类整理和可重用的方法呈现。在每一章的模式之前提供一个故事，让读者可以生动领会该模式适用的场景。在模式之后提供了成功要领，让读者有机会再次思考解决方案与问题之间逻辑关系。第三，变通性。针对每一问题，并不是提供机械式的唯一解决方案，而是在讨论中提供了多种可能性，并在分析各种可能性的基础上，提出与场景最适配的方案建议。

翻译这个业余工作能够顺利完成，离不开家人的支持。我们每位译者在此对各自的家人致以最真诚的感谢。鉴于译者水平和时间限制，翻译中如有错漏之处，欢迎读者通过各种途径与我们交流。

又及，我们有一群热心的小伙伴为本书的故事录制了部分音频，扫描相应章节的二维码，就可以收听。他们是玲珑月、书山有伴、马畅、吴非、余丹、幸运、小熊、陈玲、Wade炜、丽婵 CC、吴言、鲁巧丽、Seven以及西卡。大家一起读故事，一起分享和深化对Scrum的理解。

前言

欢迎阅读第2版。

当我提出想要修订本书第1版时，我妻子怀疑这是不是个理智的决定。毕竟，她提醒我，第1版几乎把要分享的都写完了。然而，当我回想起我的第一次写作过程时，我觉得我不仅有更多要说的，而且我还想调整我已经发表的一些内容。简而言之，我想要重构，添加一些新特性，并发布2.0版本。所以就有了第2版。

阅读本书的方法跟阅读第1版一样：挑选能解决你在公司遇到的问题的一章并阅读它，然后应用我的建议，看看会发生什么。

敏捷是一个旅程。自2012年第1版出版以来，我学到了很多东西。如果你以前读过这本书，你会立刻发现我已经在原来的章节中添加了新的想法和概念。很多章节重写超过80%；其他的则只有10%。你将看到一个新的部分，第V部分“荒野必备”，包含了更多的实战技巧，其灵感来自于我与全球组织合作的第一手经验。这些新章节包括管理风险、面试、一次做对的谬论等等。

本书诞生过程

我女儿 Emma出生时，我感到有些力不从心。相比我们的其他孩子，我们这次在医生办公室的时间似乎要更多一些。我一直问我妻子：“这正常吗？”一天晚上，我在枕头边上发现我妻子那本《新生儿父母手册》，里面有她写的一张小纸条：“读读这本书，你会感到好受一些。”

我读了。由此我知道了我们所经历的每件事情对于我的孩子都是正常的，即使对我或我以前观察到的来说不常见。这使我感到更有信心与安全感。这也正好是我开始试验 Scrum 与敏捷的时间。随着我开始遇到障碍与面临不熟悉的情况，我开始认识到，在做 Scrum与XP的第一年(甚至之后)，我真正需要一本指导手册。

问题在于，不像一本指导手册，我不可能准确告诉你，在第 1～3月或者 9～12 月，你的团队应该做什么或者是应该担心什么。团队并不像小孩那样，不会以一个可以预测的速度发展。相反，在他们第一年的实践中，随着他们学习团队合作、采用敏捷工程实践、与他们的客户建立信任、和以增量迭代方式工作的过程中，他们常常会摔倒、蹒跚、犯错误，前进两步就倒退一步。

有鉴于此，我更倾向于以这种方式“我遇到了一个问题，该怎么办”来组织这本书。我收集了我参与过或者见证过的、在他们第一年敏捷旅途中的那些团队的故事。随着我继续我的敏捷旅途，我注意到各个公司中这些故事、模式通常都很相似。我在一个公司中实现一个想法，稍微调整一下就可以应用在下一个公司中。重复这个过程，我得以收集了这些现实世界的解决方案， 并把它们加入我随身携带的虚拟工具箱。在这本书中，我将与你分享一些最常见的痛苦与解决方法。当你的团队遇到麻烦或者是受伤的时候，你可以找到最接近你的症状的那一章，然后你可以发现，即使不能解决你的问题，至少也有一个办法可以减轻你的痛苦。

第2版旨在帮助你精心调试你自己的实践，在一些你不熟悉的领域提供指南以及在前进的道路上更轻松地克服我们都遇到过的困难。

谁应该读这本书

如果你正在考虑开始 Scrum 或者敏捷的实践，或者刚刚开始你的旅途，或者已经实践了一年左右但却感觉好像迷失了方向，这本书就是为你准备的。我正式的目标群体就是，从那些在6个月以内将开始他们的项目，到那些已经实践了一年的公司，即有 18 个月的时间窗口。

这本书是为推崇实践的人准备的。如果你想学习理论或者是高深的讨论，可以从很多优秀的 Scrum 和敏捷的书籍中找到一本。另外一方面，如果你想寻求基于我在微软做过的项目以及我在福布斯 100强的大型公司指导顾问过的团队的实践建议与真实数据，这本书会物有所值。

怎样阅读这本书

设计这本书是为了方便你在任何时间以任何顺序阅读任何章节。每一章都以一个故事开始， 这些故事都是从我工作过的或者是指导过的团队、公司、项目中提取出来的。可以想象，为了保护那些清白的(或者是犯错的)人，我改变了他们的名字。在你看过这些似曾相识的故事后，我会介绍一个模型。这些模型是我在实战中用来帮助解决故事中存在的问题的。一些模型你可能会感到不太舒服，或者是认为对你的公司可能不适用。我强烈要求你反抗你的忽视建议或者是修改模型的直觉，至少努力尝试三次，然后看看结果如何，你可能会对结果感到惊讶。在每章的最后，我总结了成功要领，其中的因素事关实践成败。

这本书组织为五部分。

第Ⅰ部分“战前准备”，对你准备开始使用 Scrum 提供建议，帮助你为成功做好准备。如果你正在考虑 Scrum，或者是刚刚开始使用Scrum，就从这里开始。

第Ⅱ部分“战地基础”，讨论的话题可以帮助你克服开始敏捷的旅途之后团队与组织会遭遇的初步障碍。如果已经开始了 Scrum 的实践，但是遇到了困难，你可以从这里开始。

第Ⅲ部分“战地急救”，着眼于解决公司所面临的一些更大、更深层次的问题， 比如往项目中增加人手或者是解决每日站会的功能失调。这些都是在第一年实践中某个时候很可能会遇到的情况。这几章可以帮助你诊断并处理这些情况，使团队恢复到健康的状态。

第Ⅳ部分“高级生存”，讨论人们在实践 Scrum的任何阶段都常常挣扎的一些话题。 比如， 项目成本、 合同的制定、敏捷与 Scrum 项目中的文档等。

第V部分“荒野必备”，包含了一些章节，这些章节关注的是那些被忽视的，但也同样代价高昂的问题。这些问题是大多数组织在敏捷采纳的过程中所面临的，比如风险管理，面试，一次做对，等等。

如果你是从零开始，对 Scrum 还一无所知，我在本书的附录中包括了一个对 Scrum 的简短介绍，旨在帮助你熟悉这些术语与概念。在开始研究这本书之前，你可能还需要多了解一下 Scrum。

为什么需要阅读这本书

不管你在敏捷旅途中身处何地，我们都需要一个友好的提醒，即我们的遭遇是正常的， 我们还需要解决这些问题的建议和一些成功要领。这本书把这些东西都组织在一起，方便你根据具体需要选择阅读需要的章节或者整个部分或者全书。这是真实生活中的情况，可以与你产生共鸣，它的解决方法可以应用于任何团队。打开书开始阅读这些故事，这本书将是你经历 Scrum 与极限编程之高潮与低谷的忠实伴侣。

本书的补充材料

在你阅读本书的过程中，你可能会想：“我真希望有个工具或者是可以下载一个模板来帮助我实践这个概念。”很在多情况下，这是可以的。访问 http://www.mitchlacey.com/supplements/，你可以看到我在我每天的 Scrum 项目中用到的一系列文件、图片、Excel 表格以及工具。尽管其中一些信息是精心准备过的，但大多数东西还很简陋。为什么？在我的项目中，我不需要它们很完美，我只需要它能用。你在我的网站上得到的将是第一手的、真实的、偏重实战且有用的东西。

致谢

在我第一次想写这本书的时候，我的想法还很粗糙，我还不知道这是一项艰巨的工程。我的妻子 Bernice，让我有时间专注于这本书，我的孩子也是这样。没有她们的支持，就不会今天有这本书。

David Anderson，Ward Cunningham和Jim Newkirk帮助我和我在微软的第一个团队取得了成功。他们仨当时都在那里工作，指导我们走过了一些艰难的时期。现在我依然会回头看看早期与Ward 讨论的一些笔记，其中一个是重点显示的问题：“我们能不能不做TDD？”他们仨都在帮助我们团队从不适应到变成一个真正特别的团队。David、Ward 和 Jim，谢谢你们。

没有我的的妻子Bernice Lacey和这个星球上最好的编辑Rebecca Traeger的帮助，我也无法完成此书。两个人都花了无数个小时编辑，让我保持正确的方向并专注于此，帮助我把我的原始想法和文字变成浑然一体的章节。

我还要感谢帮助我精心写就今天这本书的所有朋友。列在这里的每个人都给予我有价值的反馈并抽出很多时间听我总结自己的想法或者阅读草稿。我对他们每个人的感谢溢于言表，他们包括 Tiago Andrade e Silva，Adam Barr，艺术家Tor Imsland，Brent Barton，Martin Beechen，Arlo Belshee，Jelle Bens，John Boal，Jedidja Bourgeois，Stephen Brudz，Brian Button，Sharon Button，Mike Cohn，Jim Constant，Michael Corrigan，Scott Densmore，Esther Derby，Stein Dolan，Marc Fisher，Paul Hammond，Bill Hanlon，Christina Hartikainen，Christian Hassa，Martina Hiemstra，Jim Highsmith，Liz Hill，Donavan Hoepcke，Bart Hsu，Wilhelm Hummer，Ron Jeffries，Lynn Keele，Clinton Keith，James Kovaks，Ben Linders，Rocky Mazzeo，Steve McConnell，Jeff McKenna，Brian Melton，Ade Miller，Raul Miller，Jim Morris，Jim Newkirk，Jacob Ozolins，Michael Paterson，Bart Pietrzak，Dave Prior，Peter Provost，Michael Puleio，Scott Robinson，René Rosendahl，Ken Schwaber，Tammy Shepherd，Lisa Shoop，Michele Sliger，Ted St. Clair，Jeff Sutherland，Gaylyn Thompson，Isaac Varon，Bas Vodde以及Brad Wilson。

我还要感谢 Addison-Wesley 的团队，包括Elizabeth Ryan，Chris Zahn 与 Chris Guzikowski。感谢你们的团队所做的一切。此外，Carol Lallier和Kim Arney——编辑和出版项目协调员——感谢你们。你们敏锐地抓住了被我忽略的那么多东西，并使这一切变得很容易。

写书并不只是一个将头脑中的想法跃然于纸上的过程。就像我经历的很多项目一样，这真的是集体努力的成果。我所提到的这些人(以及我很可能遗漏的一些人)倾听我的想法，在我迷失的时候提醒我，给我提供好的想法以便对团队与客户进行实践并在我需要有人审核的时候自告奋勇。我可以想象，他们和我一样高兴见到这本书终于付梓。我希望在您读到此处的时候，也会像我一样感谢他们为这本书面世所做出的贡献。

Mitch Lacey是Mitch Lacey&Associates公司的创始人，他采用包括Scrum和XP在内的敏捷实践并以此建立高绩效组织，帮助公司充分发挥潜力。

Mitch 自称“技术宅”，1991年从计算机游戏公司Accollade Software开始他的技术生涯。先后担任软件测试工程师、测试经理、开发人员以及期间各种不同角色之后，他开始了个人职业生涯中最重要的工作，即项目管理与项目集管理。

2005年把敏捷加入项目工具箱之前，Mitch是一个接受过正规培训的项目集经理。他在微软开始发展敏捷，他的团队成功发布了MSN核心企业服务，他也在多个部门中推动敏捷的应用。

Mitch 的第一个敏捷团队是由 David Anderson、Ward Cunningham 与 Jim Newkirk 指导的。他在各种各样的项目中担任各种不同的Scrum角色。如今，带着他几十年的经验，Mitch继续通过在许多不同的组织中与领导和项目团队一起试验和实践来发展他的技能。

Mitch丰富、实际的经验和他的实用主义方法受到了许多公司的信任，包括Adobe Systems，Aera Energy，Bio-Rad，EchoStar，Microsoft，Oracle，Qualcomm，Salem Hospital，SAP和Sony等。他是认证Scrum培训师(CST)、PMI项目管理专业人员(PMP)和敏捷认证实践者(ACP)。

Mitch 在全球各种大会上发表演讲，他还是2012年和2014年敏捷大会的主席，Scrum联盟与敏捷联盟的董事会成员。

更多的信息，可以访问 www.mitchlacey.com。在那里可以找到Mitch的博客以及各种文章、工具与视频，这些东西都有助于你采用Scrum与敏捷。还可以用@mglacey(Twitter)或者电子邮件mitch@mitchlacey.com联系他。

目录

第1章  Scrum知易行难      1

故事         1

Scrum       6

什么是Scrum？      7

实施Scrum      8

Scrum的基本价值观      8

Scrum 需要转变思维方式    9

Scrum采用的是最短路径，而不是预设路径      10

Scrum发现问题      12

Scrum的最佳搭档 12

什么时候适合用Scrum？      13

变化是困难的         15

现状后期         16

从外部元素和混乱到思想转变     16

实践与集成     16

新的现状         17

成功要领         17

引用         18

第Ⅰ部分  战前准备

第2章  取得支持与组建团队     23

故事         23

模型         29

转变需要时间         30

建立紧迫感     30

成立一个强大的指导联盟     31

建立愿景/绘制未来的蓝图   31

沟通愿景         31

授权人们为愿景采取行动     32

计划并创造短期成功     33

进一步改善，巩固成效，继续深化改革     33

制度化新的方式方法     33

成功要领         33

引用         34

参考         34

第3章  用团队顾问来优化团队表现         35

故事         35

模型         40

建立一个团队顾问池     40

建立团队         42

核心团队         43

团队顾问         44

团队大小         44

核心团队与团队顾问一起工作     46

团队顾问与会议     46

成功要领         47

责任         47

试验         48

小心过度         48

计划可能的空闲时间     48

团队顾问不能代替专职团队         49

引用         49

参考         49

第4章  预估团队的速率     50

故事         50

模型         55

使用历史数据的问题     55

为拍脑袋增加一些依据         56

估算Product Backlog      57

分解参考故事         57

点数与小时数的大致关系     58

团队的生产能力     58

估算团队的速率     59

增强对这种技术的信心         60

走着瞧(使用靠谱的数据)       60

收集并以图表形式表示真实的数据     61

计算平均速率，但要对范围进行交流         61

截断数据         62

成功要领         64

引用         65

第5章  Scrum的三大角色 66

故事         66

模型         70

选择角色         71

组合角色         72

如果实在万不得已，又该何时组合这三大角色         74

成功要领         74

第6章  确定Sprint的长度 76

故事         76

模型         79

项目期限         80

产品负责人与项目干系人     81

Scrum 团队    82

确定 Sprint 的长度       82

警告         85

问卷之外         85

成功要领         86

长于1个月的Sprint       87

延长Sprint长度      87

引用         87

第7章  如何定义“完成”         88

故事         88

模型         90

介绍         91

头脑风暴         91

分类         92

排序与整合     93

生成与发布DoD     95

没有完成的工作呢？     95

成功要领         96

引用         96

第8章  全职的ScrumMaster      97

故事         97

模型         100

成功要领         106

消除障碍/解决问题        106

结束争论/当团队的保姆        107

报告团队的行为表现     107

引导并在必要时提供帮助     107

教育组织并驱动组织变革     108

结语         109

引用         109

参考         110

第II部分  战地基础

第9章  Scrum中工程实践的重要性 113

故事         113

实践         117

重构         119

持续集成以及更频繁的提交         120

结对编程         121

自动化集成与验收测试         123

成功要领         124

不是银弹         125

开始行动         125

获得团队的支持     125

DoD 125

把工程实践加入Product Backlog 126

获得培训与指导     126

结语         126

引用         127

参考         127

第10章  团队核心时间       128

故事         128

模型         131

在一起工作的团队         131

分布式团队与兼职的团队     133

成功要领         134

第11章  发布计划       136

故事         136

模型         140

项目成本         144

成功要领         146

事先进行沟通和交流，并且要频繁     147

每个Sprint后都更新发布计划      147

努力先做优先级最高的条目         147

交付可工作的软件         148

引用         148

第12章  分解故事与任务  149

故事         149

模型         152

做好准备         152

故事分解         153

任务分解         156

成功要领         159

引用         160

参考         160

第13章  缺陷管理       161

故事         161

模型         163

成功要领         164

附加信息         165

引用         165

参考         166

第14章  可持续工程与Scrum    167

故事         167

模型         170

专用时间模型         170

随时收集数据         171

专职团队模型         171

成功要领         173

专职维护团队成员的轮换     173

用良好的工程实践来改进遗留代码     174

结语         174

引用         174

第15章  Sprint评审会         175

故事         175

模型         179

进行会议         180

成功要领         181

花时间准备     181

记录决策         182

要求认可         182

勇敢         182

参考         183

第16章  Sprint回顾会         184

故事         184

实践         187

让回顾会议发挥应有的作用         187

计划一个有效的回顾会议     188

召开回顾会议         189

成功要领         191

告诉他们为什么要保留回顾会议         192

营造一个良好的环境     192

有需要就开     192

高度重视回顾会议         193

引用         193

第III部分  战地急救

第17章  富有成效的每日站会  197

故事         197

模型         200

准时开始和结束     201

开会迟到         201

议程、节奏和站位         202

打断         202

漫谈和深入讨论     202

暴露隐藏的障碍     204

忽略问题         204

过于模糊         204

结束就意味着开始         204

成功要领         205

保持会议的频率     205

站着，不要坐         206

像团队一样工作     206

耐心         207

第18章  每日站会的第四个问题       208

故事         208

模型         211

成功要领         212

引用         212

第19章  真正参与结对编程       213

故事         213

模型         215

混排结对编程         216

实践混排结对编程         216

混排结对编程的挑战     217

微结对     218

成功要领         220

引用         221

第20章   222

新加入团队成员     222

故事         222

模型         224

练习         226

成功要领         227

承认速率会下降     227

明智地选择新成员         227

风险         228

引用         228

第21章  处理文化冲突       229

故事         229

模型         234

成功要领         239

掌握自己的命运     239

面对现实         240

坚持到底         241

引用         242

参考         242

第22章  Sprint紧急情况处理流程    243

故事         243

模型         246

消除障碍         246

获得帮助         247

缩小范围         247

取消Sprint       248

成功要领         249

引用         249

第IV部分  高级生存

第23章  可持续的步伐       253

故事         253

模型         257

缩短迭代周期         260

监测燃尽图     260

增加团队时间         261

成功要领         262

引用         263

第24章  交付可工作的软件       264

故事         264

模型         268

核心模型         268

用户数     269

从风险最高的组件开始         270

扩展和验证     270

成功要领         271

思维的改变     272

返工         272

专注于端对端的场景     273

参考         274

第25章  价值的度量与优化       275

故事         275

模型         278

功能工作         278

额外的工作     278

试验性工作     279

技术债务         280

其他潜在的类型     280

组织数据         281

使用数据         281

成功要领         283

教育项目干系人     283

和项目干系人一起工作         284

确定模式与趋势     284

引用         284

参考         284

第26章  项目成本预算       285

故事         285

模型         290

功能规格书     290

用户模型         291

估算用户模型         291

确定用户故事的优先级         292

确定团队的速率     293

计算成本         293

制定发布计划         294

成功要领         294

引用         295

第27章  Scrum项目中的文档    296

故事         296

模型         299

为什么我们要做文档     300

我们会做什么文档         300

什么时候以及怎样做文档     301

在项目开始的时候做大量文档     301

在项目最后做大量文档         302

随着项目的进展写文档         303

敏捷项目的文档     304

文档准备不充分就开始项目         305

成功要领         305

引用         306

第28章  外包与离岸开发  307

故事         307

模型         310

考虑实际成本         310

交接成本         310

增加的开销     311

长期的人员流失     311

文化的挑战与管理工作         311

开发实践         312

面对现实         312

预算与成本     313

时间、距离与文化         314

成功要领         314

选择合适的离岸团队     314

以痛苦最小的方式分配工作         315

坚守Scrum框架     315

建立团队文化         316

准备差旅         317

配备一个项目/团队协调人   318

绝不考虑离岸的情况     318

引用         318

参考         319

第29章  大型产品列表的优先级确定与估算  320

故事         320

模型         323

团队         324

项目干系人     325

成功要领         328

预先计划至关重要         328

专注于讨论并设定时间限制         328

将未解决的争议放入“停车场”         329

带上额外的卡片/纸张以备现场产生用户模型   329

引用         330

第30章  拟定合同       331

故事         331

模型         335

传统的合同与变更要求         335

写用户模型     341

估算用户模型         341

成功要领         343

引用         345

第V部分  荒野必备

第31章  合作推动完成       349

故事         349

模型         353

任务扑克         353

结对编程         354

限制进行中的工作条目         355

两周迭代         358

用任务板创造可见性     359

成功要领         361

每个声音都有人听         361

对工作的共同理解         361

每位团队成员都对成果投入         362

不要平均任务估算         362

避免粒度更细的任务估算     362

Scrum建立在团队工作的基础之上      362

参考         363

第32章  故事点与时间的关系  364

故事         364

模型         367

恐惧因素         368

宽范围     368

成功要领         371

收集正确的数据     371

用数据来改善         372

故事点的REFLECT原则 373

参考         374

第33章  沉浸式面试与招聘       375

故事         375

模型         378

预测         378

雇佣要有正确原因         378

不良招聘的成本     379

技能，能力，还是两者兼顾         380

如何招聘         380

候选人筛选     381

准备与计划     382

候选人打分     383

招聘管理和非技术人员         384

成功要领         384

建立一个可重复的招聘流程         385

专注于能力而不是问题         385

技能容易学，能力不易学     385

找到比你强的人     386

理解成本并加大投资     386

引用         386

参考         387

第34章  激励与成果挂钩  388

故事         388

模型         391

设置关注点     391

按客户满意度统一目标         391

优先级的排定和调整     392

其他好处         394

成功要领         394

销售与开发一体化         394

停止牺牲人员和质量：对项目组合进行排序     394

管理层的支持         395

参考         395

第35章  Scrum项目中的风险管理    396

故事         396

模型         397

客户风险：PO         399

社会化风险：ScrumMaster   399

技术风险：开发(核心)团队  400

成功要领         400

放手         400

敏捷起来         401

参考         401

附录  Scrum框架

角色         404

ScrumMaster   404

产品负责人     404

开发团队         404

工件         405

Sprint Backlog 406

燃尽图     407

会议         407

计划会     407

每日Scrum      408

Sprint评审会  409

Sprint回顾会  409

结语         410

软件开发 敏捷开发

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。