第九章 发布计划

通过估算团队能在每轮迭代中完成多少工作来计划发布。Deadline与估算不一致并且客户不改变其发布内容时如何处理？

故事优先级：

必须有、应该有、可以有、这次不会有

如何排列故事优先级：在不同角色给出各自的评估信息后（工作量，重要度，风险，价值等）由不同的维度综合考虑优先级。

一个大的故事如果可拆分并且拆分后的故事可以单独发布则可以先拆分后再确定为不同的优先级

高风险故事、基础性或非功能性故事应根据不同的风险等级（对整体影响、后期改造难度、后期改造投入等适当调整优先级。

迭代长度：

开发人员和客户共同选择适合他们的迭代长度，并尽可能的坚持固定的迭代长度。短迭代：项目可频繁调整，进度更透明，但每轮迭代会有二外开销；长迭代：更易犯错；

团队速率：

猜测：当没有合适参考时使用。把一轮迭代三分之一到一半的开发日作为预计速率是很常见的。

执行一轮，使用这个速率：当从猜测开始迭代后，有了第一个真实速率后，代替猜测速率。

历史值：在不断的迭代中，不断的调整速率值，作为未来速率的参考。

加班在计划和迭代过程中如何处理？