走出硝烟的精益敏捷：我们如何实施Scrum和Kanban

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

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

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

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

精彩主题：

如何写产品列表（Product Backlog）

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

如何布置团队空间

如何开每日站会（Daily Meeting）

如何做演示和回顾

如何对待固定价格的合同

如何结合使用Scrum和XP

如何做测试

如何管理多个团队

如何管理分布式团队

ScrumMaster检查清单

Scrum和Kanban如何结合使用

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

　　亨里克·克里伯格（Henrik Kniberg），作为一名IT从业人员，他热爱调试、重构和优化。同时，也更爱即兴表演。他曾经担任三家瑞典IT公司的CTO，帮助很多客户改进过流程。作为精益敏捷社区的活跃人士，他和Scrum联合创始人苏瑟兰、精益专家波彭迪克以及看板创始人安德森过从甚密。在国际性会议中，他也曾多次获得讲师奖。亨里克在东京长大，目前全家居住在斯德哥尔摩。他热爱音乐和作曲，是当地乐队的贝司手和键盘手。
　　
　　马蒂斯·斯加林（Mattias Skarin），看板早期实践者，精益教练，主要帮助软件公司顺利实施精益和敏捷。他擅长从开发到管理各个层面的实践，曾经帮助一家游戏开发公司的开发部门把开发周期从24个月缩减到4个月，使其重新赢得了公司的信任。他拥有10年核心业务系统开发经验，先后创建过两家公司。他拥有质量管理硕士学位。
　　
　　李剑（凉粉小刀），全栈程序员，2004年参加工作至今，目前专注于移动开发领域。曾任ThoughtWorks高级咨询师和InfoQ首席编辑。出版的作品恰好可以凑够朋友圈九宫格，算是为国内敏捷社区的发展做了一些微不足道的贡献。

第I部分 硝烟中的XP和Scrum
第1章 简介
免责声明
撰写本书的原因
Scrum到底是什么
第2章 我们怎样编写产品backIog
额外的故事字段
我们如何让产品backlog停留在业务层次上
第3章 我们怎样准备sprint计划
第4章 我们怎样制定sprint计划
为什么产品负责人必须参加
为什么不能在质量上让步
无休止的sprint计划会议
sprint计划会议日程
产品负责人如何对sprint放哪些故事产生影响
团队怎样决定把哪些故事放到sprint里面
定义“完成”
使用计划扑克做时间估算
明确故事内容
确定每日例会的时间地点
最后界限在哪里
bug跟踪系统对比产品backlog
sprint计划会议终于结束了
第5章 我们怎样让别人了解我们白isprint
第6章 我们怎样编写sprintbacklog
sprintbacklog的形式
任务板怎样发挥作用
燃尽图如何发挥作用
任务板警示标记
第7章 我们怎样布置团队空间
让团队坐在一起
让团队坐在一起！
让团队坐在一起！
让产品负责人无路可走
让经理和教练无路可走
第8章 我们怎样进行每日例会
我们怎样更新任务板
处理迟到的家伙
处理“我不知道今天干什么”的情况
第9章 我们怎样进行sprint演示
为什么我们坚持所有的sprint都结束于演示
sprint演示检查列表
处理“无法演示”的工作
第10章 我们怎样做sprint回顾
……

第II部分 相得益彰的Scrum与Kanban
结语
作者简介

产品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成了!

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

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

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