Scrum

[b]转载自其它网站[/b]

Scrum

产品backlog是Scrum的核心，是需求/故事/特性组成的列表，根据重要性排序。以客户的角度来描述，一般称为故事，一个故事包括：

1. id - 唯一标识
2. 名称 - 少于10个字的简述
3. 重要性(Importance) - 评估的一个数值，例如15、80，分数越高越重要
4. 初始估算(Initial estimate) - 完成故事需要的工作量，最小单位为故事点(story point)，约为1人/天
5. 如何演示(How to demo) - 本质就是一个测试规范：先.. 然后.. 再.. 如果.. 最终..
6. 备注(notes) - 相关信息、解释说明和对其它资料的引用等等其他：Track、Component、Requestor、Bug tracking ID

Sprint准备

1. 一个产品负责人全权维护一个产品backlog
2. 产品负责人应当理解每个story的含义，知道story为什么存在，并估算story的重要性
3. 其他人也可以添加story
4. 重要的backlog已经根据重要性评过分
5. 开发团队添加story的估算时间

制定sprint计划
举办Sprint计划会议，让团队获得足够的信息，会议内容包括：

1. sprint达成的目标
2. 讨论每个故事，估算时间，并形成sprint backlog列表
3. 调整优化：scope、importance、estimate三者的关系
4. 演示日期
5. 每日scrum会议的时间地点

产品负责人通过调整story的优先级和story范围影响sprint backlog团队决定sprint backlog的方式：

1. 人为判断
2. 计算生产率：
可用人/天 x 投入度 = 估算生产率

实际生产率 = 上次sprint中完成的story的估算生产率总和一个story会被拆分出若干个task，由团队维护，不出现在产品backlog中。

TDD，几乎每个故事的第一个任务都是"编写一个失败的测试"，而最后一个任务是"重构"（提高代码的可读性，消除重复）。

优先级 1：sprint 目标和演示日期。这是启动 sprint 最起码应该有的东西。
优先级 2：经过团队认可、要添加到这个 sprint 中的故事列表。
优先级 3：Sprint 中每个故事的估算值。
优先级 4：Sprint 中每个故事的"如何演示"。
优先级 5：生产率和资源计算，用作 sprint 计划的现实核查。包括团队成员的名单及每个人的承诺（不然就没法计算生产率）。
优先级 6：明确每日例会固定举行的时间地点。这只需要花几分钟，但如果时间不够用，Scrum master 可以在会后直接定下来，邮件通知所有人。
优先级 7：把故事拆分成任务。这个拆分也可以在每日例会上做，不过这会稍稍打乱 sprint 的流程。

技术故事
我指的是需要完成但又不属于可交付物的东西，跟任何故事都没有直接关联，不会给产品负责人带来直接的价值。

* 安装持续构建服务器
* 编写系统设计概览
* 重构DAO层
* 升级Jira
* ......