《硝烟中的Scrum和XP》书摘（1）

Nokia的Scrum标准：

1. 迭代要有固定的时长（TimeBox），不能超过六个星期。
2. 每一次迭代的结尾，代码必须经过QA的测试。
3. Scrum团队必须有产品负责人，而且团队都清楚这个人是谁。
4. 产品负责人必须有产品的Backlog，其中包括团队对它进行的估算。
5. 团队必须有一个燃尽图，而且要了解他们自己的生产效率。
6. 在一个Sprint中，外人不能干涉团队的工作。

Backlog是Scrum的核心，从根本上说，他就是一个需求、或故事，或特性组成的列表，并且按照重要性进行了排序，一定是客户想要的东西，并且用客户的语音进行描述，没一个条目是一个故事（Story），建议每个故事包含这些字段：

1. ID（统一标示）
2. Name（名称）
3. Imp（重要程度）
4. Est（初始估算）
5. How to demo（如何做演示）
6. Notes（其它）

每一个故事有3+1个变量（范围、重要性、估算）+质量，无论如何不能在质量上让步。

质量分为内部质量和外部质量：

1. 外部质量是用户可以感知的，如运行缓慢，让人迷糊的界面等。
2. 内部质量一般指用户看不见的原素，它对系统的可维护性有深远的影响，如系统设计的一致性、测试覆盖率、代码可读性等。

记住，在松散的沙滩上永远不能建立起精美的楼阁，经验证明牺牲内部质量是一个糟糕透顶的想法，现在省下来的一点时间，接下来的日子，你就要一直为它付出代价。

在Scrum中一切事情都是有时间盒的，到时必须交货。

“这个Sprint让大家不太好过，但是我们应该看到它的正面影响，整个团队从中获益匪浅，下个迭代会议会更有效率。”

学会按照时间盒安排工作，学会制定各种合乎情理的时间盒，这对sprint会议的长度同样有效。

典型的Sprint时间表，每一个小时休息10分钟：

1. 30分钟的总体介绍，概括产品的Backlog。
2. 20分钟的时间估算。
3. 1个小时的Story选择，计算生产率。
4. 1个小时的站立会议安排和将故事拆分为任务。

比较理想的一个Sprint长度为3个星期，（目前公司每日的Build版本，发布到测试部进行测试，应该是一个自动化测试的过程，而人工测试的应该是每个月发布的正常版本）

半死不活的目标比什么都没有强。

在Sprint中包含多少个故事由团队决定，而不是产品的负责人或其它人，但是产品负责人要对sprint中放入哪些Story产生影响。

自动生成故事卡的脚本下载地址：http://blog.crisp.se/henrikkniberg/2007/12/18/1197973740000.html

计划指派的点数：0、1/2、1、2、3、5、8、13、20、40、100、？、Coffee。