敏捷测试（5）--基于story的敏捷基础知识

基于story的敏捷基础知识----需求管理（二）

（1）定期发布

定期发布上线，把整个项目划分为一个个迭代，每个迭代时间大小固定（基本固定），迭代结束时上线交付一次。

（2）迭代规划

迭代规划相当于整个迭代的计划，帮助我们管理并保证每个迭代的交付。

A.迭代规划的前提：

story沟通及验收条件的补充完成。

PM给出story的优先级

RD、QA给出story的估点，估点可取范围为（1、2、3、5），若有大于等于5点的story，尽量拆分成更小的story。

B.迭代规划

估算团队交付能力（通常经历几个迭代，团队的交付能力就会很明了了）：基于“昨天的天气”（很可能他们在当前迭代完成的工作量与上一个迭代相同，除非工作 环境或是团队构成发生重大变化）和常识，估算自己能够在当前迭代中完成多少工作。然后团队就会基于自己的工作交付能力，选择当前迭代要开发的工作。

有了团队交付能力值，便进行以下步骤安排本迭代的工作：

1. 按照优先级顺序，列出story，并注明它们的故事点数大小。
2. 判断一个迭代中可以交付多少故事点数。
3. 考虑团队需要完成的非用户故事工作可能产生的影响，比如在早期的迭代中，由于工具和工作环境不到位，工作效率会受到影响。
4. 向计划中加入一个新的迭代。
5. 向迭代中加入故事，直到用掉所有的工作能力。
6. 询问：是否所有的故事都已经解决、版本发布目标是否达成。
7. 如果没有，那么向计划中加入新的迭代，并重复步骤5和步骤6.
8. 一旦所有的故事都已经分配完成，与大家就计划进行交流，并征求他们的反馈，看看这些计划是否现实并且可以完成。

PS：通常只会进行到第五步，剩余的stroy放入需求池，下个迭代启动时再规划。