【假一罚四】走出硝烟的精益敏捷 我们如何实施Scrum和Kanban[瑞典]亨里克·克里伯格 马蒂斯·斯加林著 李剑译

前言
嘿，Scrum成了!
Scrum成了！至少对我们来说它已经成功了（这里指的是我当前在斯德哥尔摩的客户，名字略过不提）。希望它对你们也一样有用！也许这本书会对你们实施Scrum的过程有所助益。
这是我次看到一种开发方法论（哦，对不起，Ken，它是一种框架）可以脱离书本成功运作。它拿来就能用。所有人——包括开发人员、测试人员和经理——都为此而高兴。它帮助我们走出了艰难的境地，而且让我们在剧烈的市场动荡和大规模的公司裁员中依然能够集中精力在项目上。
我不该说我为此感到惊讶，但实情确实如此。在一开始我大致翻了几本讲Scrum的书，它们把Scrum描述得挺不错，却给我留下了一种太过美好以致于不太真实的感觉（我们都知道“某些东西看上去太好了……”这类说法的含义）。所以我没法不对它有一丁点儿点怀疑。但在使用Scrum一年以后，先前的零星疑虑早已烟消云散。我被它深深地震撼了（我们团队中的大部分人都和我一样），以后只要没有充分的理由来阻止我，我都会继续使用Scrum。

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

作者简介
 
亨里克•克里伯格（Henrik Kniberg）
作为一名IT从业人员，他热爱调试、重构和优化。同时，也更爱即兴表演。
他曾经担任三家瑞典IT公司的CTO，帮助很多客户改进过流程。作为精益敏捷社区的活跃人士，他和Scrum联合创始人苏瑟兰、精益专家波彭迪克以及看板创始人安德森过从甚密。在国际性会议中，他也曾多次获得讲师奖。亨里克在东京长大，目前全家居住在斯德哥尔摩。他热爱音乐和作曲，是当地乐队的贝司手和键盘手。 

马蒂斯•斯加林（Mattias Skarin）
看板的早期实践者，精益教练，主要帮助软件公司顺利实施精益和敏捷。
他擅长从开发到管理各个层面的实践，曾经帮助一家游戏开发公司的开发部门把开发周期从24个月缩减到4个月，使其重新赢得了公司的信任。
他拥有10年核心业务系统开发经验，先后创建过两家公司。他拥有质量管理硕士学位。

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

第Ⅰ部分 硝烟中的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

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

作者简介
 
亨里克•克里伯格（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（注解）相关信息、解释说明和对其他资料的引用等。一般都非常简短。