走出硝烟的精益敏捷：我们如何实施Scrum和Kanban 下载 pdf 百度网盘 epub 免费 2025 电子书 mobi 在线

《走出硝烟的精益敏捷：我们如何实施Scrum和Kanban》真实反映了一个团队的精益敏捷落地过程。第Ⅰ部分介绍了团队是如何实施主流敏捷方法 Scrum的。主题涵盖如何写产品列表，如何准备、制定、公开和编写计划，如何布置团队空间，如何 开每日站会，如何做演示和回顾，如何对待固定价格的合同，如何结合使用Scrum和XP，如何做测 试，如何管理多个团队，如何管理分布式团队。*后，作者还给出了一个很有价值的ScrumMaster检 查清单。第Ⅱ部分主要介绍Scrum和Kanban的结合使用。在对比两者之后，作者通过一个具体的案例 来说明如何搭配使用两种方法来实现价值*化。 《走出硝烟的精益敏捷：我们如何实施Scrum和Kanban》行文风趣，具备较强的知识性和可读性，适合所有打算导入并实施精益敏捷的软件从业人员 阅读和参考。

第Ⅰ部分 硝烟中的XP和Scrum

第1章 简介 3

免责声明 4

撰写本书的原因 4

Scrum到底是什么 4

第2章 我们怎样编写产品backlog7

额外的故事字段 9

我们如何让产品backlog停留在业务层次上 9

第3章 我们怎样准备sprint计划11

第4章 我们怎样制定sprint计划13

为什么产品负责人必须参加 14

为什么不能在质量上让步 15

无休止的sprint计划会议 16

sprint计划会议日程 17

产品负责人如何对sprint放哪些故事产生影响 20

团队怎样决定把哪些故事放到sprint里面 21

定义“完成” 28

使用计划扑克做时间估算 29

明确故事内容 30

确定每日例会的时间地点 33

后界限在哪里 33

bug跟踪系统对比产品backlog  36

sprint计划会议终于结束了  37

第5章 我们怎样让别人了解我们的sprint 39

第6章 我们怎样编写sprint backlog  41

sprint backlog的形式  41

任务板怎样发挥作用  42

燃尽图如何发挥作用  44

任务板警示标记  45

第7章 我们怎样布置团队空间  49

让团队坐在一起  50

让团队坐在一起！  50

让团队坐在一起！  50

让产品负责人无路可走  51

让经理和教练无路可走  51

第8章 我们怎样进行每日例会  53

我们怎样更新任务板  53

处理迟到的家伙  54

处理“我不知道今天干什么”的情况  54

第9章 我们怎样进行sprint演示 57

为什么我们坚持所有的sprint都结束于演示  57

sprint演示检查列表  58

处理“无法演示”的工作  58

第10章 我们怎样做sprint回顾  61

我们如何组织回顾  61

在团队间传播经验  63

变，还是不变  64

回顾中发现的问题示例  64

第11章 不同sprint之间的休整时刻  67

第12章 怎样针对固定价格合同制定发布计划  69

定义你的验收标准  69

对重要的条目进行时间估算  71

估算生产率  72

统计一切因素，生成发布计划  73

调整发布计划  74

第13章 我们怎样结合使用Scrum和XP  75

结对编程  76

测试驱动开发（TDD）  76

持续集成  79

代码集体所有权  79

充满信息的工作空间  79

代码标准  80

可持续的开发速度或精力充沛地工作  80

第14章 我们怎样做测试  81

你大概没法取消验收测试阶段  81

把验收测试阶段缩到短  82

把测试人员放到Scrum团队来提高质量  83

在每个sprint中少做工作来提高质量  85

回到现实  90

第15章 我们怎样管理多个Scrum团队 91

创建多少个团队  92

虚拟团队  92

的团队规模  93

是否同步多个sprint  94

为什么我们引入了“团队领导”的角色  95

我们怎样在团队中分配人手  96

是否使用特定的团队  97

是否在sprint之间重新组织团队  99

是否拆分产品backlog  103

多团队回顾  107

第16章 我们怎样管理分布式团队 109

离岸  110

在家工作的团队成员  111

第17章 Scrum Master检查清单  113

sprint开始阶段  113

每一天  114

在sprint结束时  114

第18章 小结  115

推荐阅读  115

第Ⅱ部分 相得益彰的Scrum与Kanban

第19章 Scrum对比Kanban 121

究竟什么是Scrum？什么是Kanban  121

Scrum和Kanban有什么关系  123

Scrum规定了角色  126

Scrum规定了固定时长的迭代  127

Kanban按流程状态限制WIP，Scrum按迭代限制WIP  128

两者都是经验主义的  130

Scrum在迭代内拒绝变化  134

Scrum板在迭代之间重置  135

Scrum规定了跨功能团队  136

Scrum的backlog条目必须能跟sprint搭配得上  137

Scrum规定了估算和生产率  137

两者都允许在多个产品上并行工作  138

两者都是精益敏捷的  139

小小差异  140

Scrum板对比Kanban图—一个不大不小的例子  143

小结──Scrum对比Kanban  149

第20章 案例回放 151

技术支持的现状  152

到底为什么要改变  152

我们从哪里开始  152

迈开腿，上路  153

团队启动  154

直面相关干系人  155

做出个图  155

设置个WIP上限  157

守住WIP上限  158

什么任务能放到Kanban图上  159

怎样做估算  160

具体说说我们是怎么工作的  161

哪种做计划的方法好呢  163

度量什么呢  165

忽然之间，一切都不一样了  166

经验心得  170

结语173

作者简介175

作者简介

亨里克•克里伯格（Henrik Kniberg）

作为一名IT从业人员，他热爱调试、重构和优化。同时，也更爱即兴表演。

他曾经担任三家瑞典IT公司的CTO，帮助很多客户改进过流程。作为精益敏捷社区的活跃人士，他和Scrum联合创始人苏瑟兰、精益专家波彭迪克以及看板创始人安德森过从甚密。在国际性会议中，他也曾多次获得讲师奖。亨里克在东京长大，目前全家居住在斯德哥尔摩。他热爱音乐和作曲，是当地乐队的贝司手和键盘手。 

马蒂斯•斯加林（Mattias Skarin）

看板的早期实践者，精益教练，主要帮助软件公司顺利实施精益和敏捷。

他擅长从开发到管理各个层面的实践，曾经帮助一家游戏开发公司的开发部门把开发周期从24个月缩减到4个月，使其重新赢得了公司的信任。

他拥有10年核心业务系统开发经验，先后创建过两家公司。他拥有质量管理硕士学位。

译者简介

李剑

（凉粉小刀）  全栈程序员，2004年参加工作至今，目前专注于移动开发领域。曾任ThoughtWorks高级咨询师和InfoQ首席编辑。出版的作品恰好可以凑够朋友圈九宫格，算是为国内敏捷社区的发展做了一些微不足道的贡献。 

暂无出版社相关信息，正在全力查找中！

产品backlog是Scrum的核心，也是一切的起源。从根本上说，它就是一个需求或故事或特性等组成的列表，按照重要程度进行了排序。它里面包含的是客户想要的东西，并用客户的术语加以描述。

我们称之为“故事”（story），有时候也称之为“backlog条目”（事项）。

我们的故事包括这样一些字段。

ID 统一标识符，就是一个自增长的数字而已，以防重命名故事以后找不到。

Name（名称），简短的、描述性的故事名。比如“查看你自己的交易明细”。它必须要含义明确，这样开发人员和产品负责人才能大致明白我们说的是什么东西，跟其他故事区分开。它一般由2到10个字组成。

Importance（重要性），产品负责人估出一个数值 ，指出这个故事有多重要。例如10或150。分数越高，表明越重要。

我一直都想避免“优先级”这个说法，因为一般说来优先级1都表示优先级，如果后来有其他更重要的东西，岂不麻烦了？它的优先级评级应该是什么呢？优先级0？优先级-1？

Initial estimate（初始估算）团队的初步估算，表示与其他故事相比，完成该故事所需要的工作量。小的单位是故事点（story point），一般大致相当于一个“理想人天”（man-day）。

问一下团队：“如果可以投入适合的人员来完成这个故事（人数要适中，通常为2个），把你们锁到一个屋子里，有很多食物，在完全没有打扰的情况下闭关工作，需要几天才能给出一个经过测试验证、可以交付的完整实现呢？”如果答案是“把3个人关在一起，大约需要4天时间”，那么初始估算的结果就是12个故事点。

不需要保证这个估值无误（比如两个故事点的故事就应该花两天时间），而是要保证相对的正确性（即两个点的故事所花费的时间应该是四个点的故事所需的

一半）。

How to demo（如何做演示）它大略描述了这个故事应该如何在sprint 演示上进行示范，本质就是一个简单的测试规范。“先这样做，然后那样做，就应该得到……的结果。”

如果在使用TDD（测试驱动开发），这段描述就可以作为验收测试的伪码表示。

Notes（注解）相关信息、解释说明和对其他资料的引用等。一般都非常简短。

在线阅读地址：走出硝烟的精益敏捷：我们如何实施Scrum和Kanban在线阅读

在线听书地址：走出硝烟的精益敏捷：我们如何实施Scrum和Kanban在线收听

在线购买地址：走出硝烟的精益敏捷：我们如何实施Scrum和Kanban在线购买

sprint会议是为了让团队获得足够的信息，能够在几个星期内不受干扰地工作，是scrum中最重要的活动。

sprint计划会议需要一些实实在在的结果：

1：sprint目标

2：团队成员名单以及投入程度

3：sprint backlog

4：确定好sprint演示日期

5：确定每日scrum会议的时间和地点

我们已经证实，如果团队拥有高度的代码集体所有权，这个团队就会非常健壮，比如某些关键人物生病了，当前的sprint也不会因此隔屁着凉。

对待离自身尚远的事物时，人们

可以把它分析的淋漓尽致；但到了自己身上，就往往成了当局者迷，

旁观者清。譬如青春、譬如爱情、譬如敏捷软件开发。

通常我们会把 backlog 存放在共享的 Excel 文档里面（是为了多个

用户可以同时编辑它）。虽然正规意义上这个文档应该归产品负责

人所有，但是我们并不想把其他用户排斥在外。开发人员常常要打

开这个文档，弄清一些事情，或者修改估算值。

基于同样原因，我们没有把这个文档放到版本控制仓库上，而是放

到共享的驱动器里面。我们发现，要想保证多用户同时编辑而不会

导致锁操作或是合并冲突，这是最简单的方式。

短的 sprint=短反馈周期=更频繁的交付=更频繁的客户反馈=在错

误方向上花的时间更少=学习和改进的速度更快，众多好处接踵而

来。

但是，时间长的 sprint 也不错。团队可以有更多时间充分准备、解

决发生的问题、继续达成 sprint 目标，你也不会被接二连三的 sprint

计划会议、演示等等压得不堪重负。

产品负责人一般会喜欢短一点的sprint，而开发人员喜欢时间长的

sprint。所以sprint的长度是妥协后的产物。做过多次实验后，我们

最终总结出了最喜欢的长度：三个星期。

羞辱式做法： “如果你不知道怎么帮助团队，我建议你还

是回家去，或者看书，或者怎么都行。要不也可以找个地

方坐下，等别人需要帮忙的时候你就过去。”

守旧式做法：简单给他们分配个任务了事。

施加同事压力的做法： 对他们说，“Joe，还有 Lisa，你

们两个可以放松点，我们会站在这里慢慢等，直到你们找

到帮助我们完成目标的事情为止。”

奴役式做法：对他们说，“你们今天可以给大伙儿干干杂

活。倒咖啡、做按摩、清理垃圾、做午饭，一切一切大家

今天让你们做的事情。”你会惊讶的发现 Joe 和 Lisa 在霎

那之间就找出了有用的技术任务:o)

编辑推荐

真实回放全球知名实干家的精益敏捷实施过程

结合实例回放，充分演绎敏捷方法的选用智慧

引领国内近万名读者进阶敏捷精益的启蒙读物

中小型团队（项目）不可或缺的敏捷精益入门

精彩主题：

如何写产品列表（Product Backlog）

如何准备、制定、公开和编写冲刺（Sprint）计划

如何布置团队空间

如何开每日站会（Daily Meeting）

如何做演示和回顾

如何对待固定价格的合同

如何结合使用Scrum和XP

如何做测试

如何管理多个团队

如何管理分布式团队

ScrumMaster检查清单

Scrum和Kanban如何结合使用

前言

前言

嘿，Scrum成了!

Scrum成了！至少对我们来说它已经成功了（这里指的是我当前在斯德哥尔摩的客户，名字略过不提）。希望它对你们也一样有用！也许这本书会对你们实施Scrum的过程有所助益。

这是我次看到一种开发方法论（哦，对不起，Ken，它是一种框架）可以脱离书本成功运作。它拿来就能用。所有人——包括开发人员、测试人员和经理——都为此而高兴。它帮助我们走出了艰难的境地，而且让我们在剧烈的市场动荡和大规模的公司裁员中依然能够集中精力在项目上。

我不该说我为此感到惊讶，但实情确实如此。在一开始我大致翻了几本讲Scrum的书，它们把Scrum描述得挺不错，却给我留下了一种太过美好以致于不太真实的感觉（我们都知道“某些东西看上去太好了……”这类说法的含义）。所以我没法不对它有一丁点儿点怀疑。但在使用Scrum一年以后，先前的零星疑虑早已烟消云散。我被它深深地震撼了（我们团队中的大部分人都和我一样），以后只要没有充分的理由来阻止我，我都会继续使用Scrum。

书籍介绍

本书真实反映了一个团队的精益敏捷落地过程。第1部分介绍了团队是如何实施主流敏捷方法Scrum的。主题涵盖如何写产品列表，如何准备、制定、公开和编写计划，如何布置团队空间，如何开每日站会，如何做演示和回顾，如何对待固定价格的合同，如何结合使用Scrum和XP，如何做测试，如何管理多个团队，如何管理分布式团队。最后，作者还给出了一个很有价值的Scrum Master检查清单。第2部分主要介绍Scrum和Kanban的结合使用。在对比两者之后，作者通过一个具体的案例来说明如何搭配使用两种方法来实现价值大化。