《硝烟中的 Scrum 和 XP》这本书并不厚，只有一百多页。在Scrum的圈子里面这本书很有名气，是很多人首推Scrum学习的入门资料。翻看了一半左右的内容，这本书的内容确实很接地气，敏捷不是说出来的，是干出来的，需要注重实践而非理论研究，而本书作者也正是一些真枪实弹的故事来介绍自己实践敏捷的经验，这也很有可能是本书的名字的来源---硝烟来自于实战。不过我觉得另外一个很受欢迎的原因也是书不算厚，入门阅读起来相对容易一些。
Scrum是什么？
不像很多书开始就从基本概念讲起，这本书只有短短几句推荐了几个网站自己学习Scrum的ABC知识。
对不起，你完全不了解Scrum或者XP？那你最好先去看一下这几个链接：
• http://agilemanifesto.org/
• http://www.mountaingoatsoftware.com/scrum
• http://www.xprogramming.com/xpmag/whatisxp.htm
要是你真没耐心去访问这些网站，也没关系。随便翻翻看看吧。大多数Scrum的相关术语都会在书中慢慢讲到，你会感兴趣的。
好在Scrum本身的一些概念也并不是很复杂，Scrum不是开发产品的一种流程或一项技术，而是提供了一个框架，在这个框架里可以应用各种流程和技术。另外有一个交流的说法是Scrum也是对一些PDCA这些基本管理方法的一个实例化的框架，所以有一定实战经验的人开始用这个框架应该也是可以找到共鸣的。
Scrum的基本概念和重要术语
为了便于后面的理解，还是需要有一个术语表，一图胜千言，介绍前先上个图：
-
Scrum的主要内容可以用“1334”来表达
-
1 就是一个共同的价值观
敏捷价值观 第一个3是三个关键角色：
1．PO： Product Owner，产品负责人，描绘产品远景，定义优先级。互联网公司的 PO一般由相关的产品经理担任；如果是为客户项目， PO一般就是客产负责人。
2．Scrum Master: Scrum的推动者，消除障碍，带领过程运作。
3 . Team一般由多个 developer组成，开发的主力,实现产品-
第二个3是三件神器：Production Backlog、Sprint Backlog 和燃尽图是三大神器。
PB vs SB -
最后一个4是四会：Sprint 计划会、每日站会 Daily Scrum、Sprint 评审会（Sprint Review） 和Sprint回顾会（Sprint Retrospective）
四会
战斗开始
虽然说是一篇短文，实际上也有100多页的样子，有18个章节，详细的方法还是建议把书仔细看一遍，下面只摘取一些有感觉的观点，并尽量附上自己的理解。
1. 怎样编写产品 backlog
产品 backlog 是 Scrum 的核心，是一切的起源，在Scrum里面一般称为故事 （ story ） ，有时候也叫做 backlog 条目，其实也就是我们常说的需求。backlog又跟我们常见的需求有什么差别呢？
- 产品 BACKLOG（示例）：
| ID | Name | Imp | Est | How to demo | Notes |
|---|---|---|---|---|---|
| 1 | 存款 | 30 | 5 | 登录，打开存款界 面，存入 10 欧元， 转到我的账户余额 界面，检查我的余 额增加了 10 欧元。 | 需要 UML 顺 序图。目前不 需要考虑加 密的问题。 |
| 2 | 查看自己的交易明细 | 10 | 8 | 登录，点击“交易”， 存入一笔款项。返 回交易页面，看到 新的存款显示在页 面上。 | 使用分页技 术避免大规 模的数据库 查询。和查看 用户列表的 设计相似。 |
几个特别需要关注的地方：
- 1） Imp：Importance（重要性）——产品负责人评出一个数值，指 示这个故事有多重要。例如 10 或 150。分数越高越重要。
- 2） Est：Initial estimate（初始估算）——团队的初步估算，表示与 其他故事相比，完成该故事所需的工作量。小的单位是故事点（story point），一般大致相当于一个“理想的人天 （man-day）”。
- 3）How to demo（如何做演示）——它大略描述了这个故事应 该如何在 sprint 演示上进行示范，本质就是一个简单的测 试规范。“先这样做，然后那样做，就应该得到……的结 果 ”。 如果你在使用 TDD（测试驱动开发），那么这段 描述就可以作为验收测试的伪码表示。
有时为了便于产品负责人判断优先级别，也可以在产品 backlog 中使用一些其它字段。需要让产品 backlog 停留在业务层次上，如果产品负责人有技术相关的背景，那他可能添加这样一个故事：“给 Events 表添加索引”。这就不是一个业务层次的故事，指出如何解决问题的应该是开发团队， 产品负责人只需要关注业务目标。
2. 怎样准备 sprint 计划
在 sprint 计划会议之前，要确保产品 backlog 的井然有序。 它表示的意思是：
- 产品 backlog 必须存在
- 只能有一个产品 backlog 和一个产品负责人
- 所有重要的 backlog 条目都已经根据重要性被评过分，不同 的重要程度对应不同的分数。
- 产品负责人应当理解每个故事的含义。他不需要知道每个故事具 体是如何实现的，但是他要知道为什么这个故事会在这里。
注意：产品负责人之外的人也可以向产品 backlog 中添加故事，但 是他们不能说这个故事有多重要，这是产品负责人独有的权利。他 们也不能添加时间估算，这是开发团队独有的权利。
3. 怎样制定 sprint 计划
Sprint 计划会议非常关键，应该算是 Scrum 中重要的活动。要是它执行的不好，整个sprint 甚至都会被毁掉。 Sprint 计划会议会产生一些实实在在的成果：
- sprint 目标。
- 团队成员名单（以及他们的投入程度，如果不是 100%的 话）。
- sprint backlog（即 sprint 中包括的故事列表）。
- 确定好 sprint 演示日期。
- 确定好时间地点，供举行每日 scrum 会议。
整个团队和产品负责人都必须要参加sprint计划会议，原因在于，每个故事都含有三个变量，它们两两之间都对彼此有着强烈 依赖。
SEI三角形
范围（scope）和重要性（importance）由产品负责人设置。估算 （estimate）由团队设置。在 sprint 计划会议上，经过团队和产品负责人面对面的对话，这三个变量会逐步得到调整优化。
3.1 不能在质量上让步
不管什么时候，团队都要保证系统质量，现在在质量上节省下来一点时间，接下来的日子里你就要一直为它付出代价，这一点毋庸置疑，也没有折扣可讲。现在如此、将来如此、 一直如此，直到永远。
把外部质量也看作范围的一部分。有时出于业务考虑，可能会先 发布一个系统版本，其中用户界面给人的感觉可能比较简陋，而且 反应也很慢；不过随后会发布一个干净的版本。可以让产品负责 人做权衡，因为他是负责定义项目范围的人。 一旦产品负责人弄清楚内部质量是不可能让步的，他一般都会处理 好其他变量。
3.2 决定 sprint 要包含的故事
因为有时间盒的概念，可能有一些用户故事（例如故事D）不能被包括在当前Sprint里面，产品负责人很失望。虽然产品负责人在正常情况下不能控制团队的估算生产率，他依然有很多种方式，对sprint 中放入哪些故事施加影响。
1.重新设置故事的优先级
2.缩小某个故事的范围，知道团队队相信故事D能在这个sprint 里完成为止
3.还可以拆分故事，把一些已有的故事拆小为几个部分，这样就可以放入故事D了
3.3 估算，团队怎样决定把哪些故事放到 sprint 里面？
书中提到了两个技术：
- 本能反应（专家拍脑袋）
- 生产率计算，这项技术包括两步：
- 得出估算生产率
- 计算在不超出估算生产率的情况下可以加入多少故事。
估算生产率其实也是一件很不容易的事情，又可以细化出不少方法，文中提了一个新名称“昨日天气（yesterday’s weather）”，其实也就是根据历史经验去估算。另外还有经典的PM中的人力资源计划方法，还有一种“投入程度”的折算方法，在新团队中默认放在了“70%”，这个数字挺有趣的。
“投入程度”表示“团队有多少时间可以放在当前所承诺的故事上”。它永远不可能是100%，因为团队会把时间用于完成未经计划的条目、切换环境、帮助其他团队、检查邮件、修复自己出问题的电脑、在厨房中讨论政治等等。
估算只是工具和手段，只要得出哪些故事要放到 sprint 里面，就算完成了目标。投入程度、资源可用性和估算生产率只是用来达成这个目标的手段。
3.4 DoD，定义“完成”
DoD在很多敏捷团队中都有很高的关注度，我看到很多敏捷团队宣传海报也都会突出显示DoD。这个确实是很多研发工作的痛点，而且敏捷很注重的质量内建活动对传统开发的认知是有一定冲击的，通过DoD可以协助开发人员进行自查，不仅仅开发完代码，而是要把测试，文档等一些交付必须的工作都完成。另外有一点很重要：产品负责人和团队需要对“完成”有一致的定义。
3.5 这不是我要的
在 sprint 演示会议上，团队演示了一个新特性，但产品负责人却皱起眉头，“呃，看上去不错，但这不是我要的！”这样的故事确实很常见。
书中提出了几个方法：
- 确保每个故事的所有字段都被填满
- 把故事拆分成更小的故事
- 把故事拆分成任务
- “任务”和“故事”的区别是什么呢？区别很简单。故事是可以交付的东西，是产品负责人所关心的。任务是不可交付的东西，产品负责人对它也不关心。
3.6 技术故事
技术故事，或者叫做非功能性条目，是指的是需要完成但又不属于可交付物的东西，跟任何故事都没有直接关联，不会给产品负责人带来直接的价值。
例如：
- 安装持续构建服务器
- 编写系统设计
- 重构 DAO 层
出于显 而易见的原因，技术故事常常会因为某种原因给设置一个低优先级，有时候产品负责人的做法是对的，但这只是少数情况。书中得出的结论是，产品负责人往往不能对此做出正确的权衡，需要跟PO去沟通协调，书中也提出了一些方法。
3.7 Bug 跟踪系统 vs. 产品 backlog
每个Sprint都可能会产生Bug，Bug不是故事，如何在Sprint中管理Bug就成为了一个问题。用 Excel 来管理产品 backlog 很不错，用Excel管理Bug比较麻烦，书中作者用的是Jira。书中也给出了4条意见，也比较容易理解。
4. 怎样让别人了解我们的 sprint
就是要宣传，透明有时候确实是最好沟通工具。要让整个公司了解我们在做些什么，这件事情至关重要。否则 其他人就会发出抱怨，甚或对我们的工作做出臆断。
Scrum master 要把 sprint 信息页打印出来，贴到团队房间外面的墙上。路过的每个人都可以阅读这张纸，了解这个团队所做的事情。因为其中还包括了每日例会的时间地点，所以他也能知道 到哪里去了解更多信息。
Sprint 接近尾声时，Scrum master 会把即将来临的演示告知每个人。
5. 怎样编写 sprint backlog
有了计划和宣传后，下一步就是执行计划了。Sprint Backlog就是任务列表，如果映射到传统的项目管理理论中就是WBS（work breakdown structure)，而且是典型的采用面向交付物的任务分解方法得到的WBS。
Scrum master 现在应该创建 sprint backlog 了。 它应该在 sprint 计划会议之后，第一次每日例会之前完成。 作者试了很多方法，得出的结论是：我们发现管理 sprint backlog 有效的形式 ——挂在墙上的任务板！
注意——如果你用贴纸来记录任务，别忘了用真正的胶带把它们粘好，否则有一天你会发现所有的贴纸都在地上堆成一堆（深有感触）。
可以通过燃尽图来直观的展示进度，通过观察看板发现问题并及时干预。
作者还提到了两个经验（我理解Scrum推崇的是人人平等的民主制，是自管理和为目标的团队，过细的跟踪式的管理是没有太大必要的）：
- 不需要特别针对某个任务的进展进行跟踪
- 用人天而不是人小时
--To be continued
