TFS看板的迭代规划

故事点

故事点更多体现的是用户情景或者bug的规模，采用斐波拉契数列(1,2,3,5,8,13)这样的数字表示，包含以下内容：

1. 相对工做量
2. 复杂度
3. 风险和不肯定性

相对工做量

下面演示一个Case来讲明：
假设有个编辑页面A有10个字段,B有100个字段：

B的相对工做量应该是较大可是不是绝对的10 倍。可能3-5倍。反应的就是故事点增长

若是考虑到已有的动态表单生成，那么A和B两个case应该是复杂度一致,反应的是故事点一致。

复杂度

对于上面100个字段这个case，若是字段中有一些数据绑定，复杂控件等等，那么必然带来复杂度的上升，反应的也是故事点的增长。

风险和不肯定性

对于新的技术调研分析等，例如最开始去调查一个第三方api。某个技术实现可行性分析能够转化成工做量。

注意

1. 考虑到不一样实现思路带来的不一样工做量估算差别，开发应该能够对故事点进行调整。
2. 就拿距离来讲，对于绝对距离的估算每每没有相对距离准确。
3. 故事点只作相对大体的估算便可，不要求十分精确，可是要有足够说服力。

速度图

速度图在待办事项列表右上角，随着时间的推移，速度应该是显示一个可靠的，可用于预测平均完成故事点的数量。为了发挥速度图的效益，须要知足如下要求：

1. 按照团队来规划迭代内容(不要在顶层团队规划)
2. 为团队定义迭代(迭代的时间应尽可能相同)
3. 为每一个团队选择迭代计划(应尽可能多分配2-3个迭代)
4. 需求尽可能独立,不要有太多关联性(需求不要嵌套需求)
5. 迭代结束之后要及时更新将待办项关闭，若是未关闭放到积压工做从新规划

6. 复杂bug须要评估故事点和任务拆分(复杂性须要开发本身评估)

   由于迭代内默认是由必定时间修复迭代内bug的，若是时间足够能够修复历史bug，可是部分复杂Bug须要时间较长，建议看成需求同样来估算

速度预测

在情景代办事项列表中打开趋势预测(推荐隐藏进行中的项目)便可打开预测工具。
能够根据速度图合理设置速度预测的值，便可使用预测功能。

注意事项

1. 要求针对每一个用户故事和Bug设置故事点
2. 能够对用户故事和任务进行排序来从新预测
3. 速度的预测只是一个相对的值并不是一个绝对的估算(这部分参照迭代容量规划)

做用

1. 对项目将来的进度进行大体的规划
2. 对待办事项进行规划(排序和优先级)
3. 针对预测合理的分配团队的资源

容量规划

基于迭代速度预测是大体的一个判断，容量规划能够帮助咱们作精确的计算。可是容量的规划，根据团队的状况实际能够调整，不该该提早太多，这部分能够能够由团队在迭代开始之初在计划会议上肯定。
配置步骤:

1. 选中某一个迭代，打开容量选项卡
2. 选择团队人员(能够包含产品，开发，测试等)
3. 配置天天的工做量(注意能够配置不一样的活动).
4. 配置团队休息日(周末默认休息，可把开发封板之后的工做日看成休息日)
5. 通常能够复制上个迭代的规划，按照须要稍做修改便可

右边便可出现团队的容量

任务拆分

有了容量规划,迭代的大体规划后，咱们须要对详细作什么进行规划，而迭代的具体工做是根据任务来划分,使用故事点作大体预测，使用任务剩余工做作详细划分,缘由以下:

1. 故事点只是一个相对的概念，比较模糊
2. 需求拆分的过程能够对某个需求或者bug作实现层面的设计
3. 需求的拆分包含设计过程能够对需求的缺陷作提早的预防
4. 任务更加详细方便作更加精确的估算
5. 任务初始估计和剩余工做新建时候相等
6. 任务初始估计和剩余工做以小时未单位

需求或bug拆分的任务须要填写初始估计和标题便可，能够根据须要填写详细的内容。默认是谁的需求谁来拆分，谁拆分的任务就是分配给谁的。注意事项:

1. 需求应该由测试拆除一个用例设计的任务，活动为用例设计
2. 复杂Bug应该拆分任务。活动为bug修复

通过上述拆分之后在右边既能够显示每一个人员整体的时间和完成迭代内任务须要的时间。根据最终拆分的结果适当的进行需求的删减。

燃尽图

选中某个迭代之后,右上角图形即为燃尽图。
可用容量的直线(最高点迭代开始出可用的最大工做时间，最低点0)
理想趋势(最高点剩余工做的最大值，最低点0)
剩余工做(天天剩余工做的折线图)

以下参考资料学习燃尽图:

1. https://docs.microsoft.com/zh-cn/vsts/work/scrum/sprint-burndown
2. http://www.methodsandtools.com/archive/scrumburndown.php