系列文章

上一篇 “估算用户故事”

---

如有问题请留言

---

前言

大部分软件项目都会有一个比较固定的发布周期，某些网站项目可能会很频繁。因此搜集新功能放到一个发布中是很好的。产品开发路线图可以帮助展示未来几个新发布中关注的重点。产品开发路线图可以很简单，可以是未来几个发布要关注的重点列表。
一个笼统的开发路线图开始，我们可以使用以下两个问题来启动发布计划。

1. 我们想在什么时候发布？
2. 每个故事的优先级是什么？一旦得到这些答案，我们就可以估算团队在每一轮迭代中完成多少工作来计划发布了
   

---

提示：接下来的所有理论都会伴随一个实际的例子，而所有例子都基于一个假想的职位发布和搜索网站。

文章概览

1. 我们想在什么时候发布？

• 一般来说开发人员和客户只讨论一个范围日期。
• 或者由故事驱动的过程可以很容易确定一个日期，这样可以在指定日期交付某些功能。

2. 希望在发布中包含哪些功能？

• 为了一个发布计划，客户必须排列故事优先级。
• 借助DSDM的大方法，DSDM包含一个列优先级的方法，称为莫斯科规则（MoSCoW）
  1. 必须的（Must have）
     -系统基本功
  2. 应该有（should have）
     -很重要单短期内有可替代解决方法
  3. 可以有（Could have）
     -如果时间不够则可以不在此次发布中完成
  4. 这次不会有（Won’t have this time）
     -期望在之后的版本中出现

3. 排列故事优先级

• 排列故事优先级，可以利用如下要素。
  1. 故事不能如期完成的风险
  2. 推迟一个故事的现实对其他故事的影响
  3. 故事对于广泛用户或客户的重要性
  4. 故事对于少部分重要用户或客户的重要性
  5. 故事与其他故事的内聚性

4. 混合优先级

• 如果遇到无法为故事确定出优先级，那么就可能需要分解这个故事。

5. 高风险故事

• 一个项目是先做高风险部分还是最有价值部分？
• 对于敏捷方法来说，更倾向于有价值部分。

6. 根据架构需要安排优先级

• 高风险故事经常与基础性或非功能性需求有关，如性能需求。

7. 选择迭代长度

• 迭代长度通常为1到4周，由开发和客户共同确定。
• 在开发期尽可能固定这个时间。

8. 从故事点到预计工期

• 假设客户已经将优先级排列好，我们只需要根据速率确定工期就可以了。

9. 初始速率

• 根据：使用历史值，执行一轮迭代，使用那轮迭代的速率，猜测，这三个方法。

10. 创建发布计划

• 如果项目由100个故事点，若估算速率是每轮20个故事点，则可以预计总共需要5轮迭代。发布计划最后一步是把故事分配到每轮迭代中。

---

Finish

下一篇 “迭代计划”

参考书籍《用户故事与敏捷方法》