zoukankan      html  css  js  c++  java
  • 敏捷估算与规划—跟踪与交流

    1 监督发布计划的执行

      速度度量的是小组在每次迭代中完成的工作量。应该采用全有和全无的规则来计算速度。如果完成了一个故事,小组就可以在计算速度的时候得到它所有的估计值。如果再迭代中只是部分完成了故事,确定速度时就完全不要考虑它。

      燃尽图显示出每次迭代开始时项目中剩余的功能点或理想日数目。小组的燃尽过程从来都不会是完全平滑的。例如,不准确的估计,估计值的变化和范围的变化等都会导致它的起伏。燃尽图甚至可能在一次迭代中显示出待完成的工作量的增加。这意味着虽然小组可能完成了一些工作,但他们要么认识到剩下的工作被低估了,要么就是增加了项目的范围。解释发布燃尽图的一个关键在于理解它显示的是小组的净进度,也就是他们的进度减去所有被增加到项目中的工作。

      发布耗散条形图提供了一种某些时候会有用的对燃尽图的变形。它把小组相对规划的工作进度和对发布范围的改变给分隔开,通过把条形的底部降到水平轴以下来显示范围的变化。这类图比燃尽图更有表达力,但是必须小心使用,因为她在一些公司中可能导致关于某个变化影响的到底是图中条形的顶部还是底部的争论。

      停车场图提供了一个有用的高层次视图,体现了小组在实现项目中所规划的不同主题时的进度。

     2 监督迭代计划的执行

      任务板——常常是一张白板,软木板或者只是墙上特定的一片区域——可以帮助开发小组组织他们的工作,并把他们可视化。任务板的纵栏都带有标题,小组成员根据工作进展把任务卡片在各栏间移动。

      迭代燃尽图类似发布燃尽图,但只是用来跟踪当前迭代中的工作。它的纵轴是剩余工作的小时数,横轴是迭代中的天数。

      小组要做出更好的估计,就应该反对跟踪花在任务上的实际小时数,这样做所付出的工作量和带来的风险通常超过了它带来的好处。在一个项目中,了解还剩多少事要做远比了解已经做了多少事有用。

      小组不应该计算或跟踪个人速度,因为我们鼓励以小组的形式工作。

    3 与计划有关的沟通

      我们希望就估计和计划进行的沟通时频繁的,诚实的和双向的。甘特图可以用作对计划进行沟通的有益工具,不过不应该让它进入到低于功能分解的层次,而且途中的功能应该显示为在整个迭代持续期内都在进行处理。

      耗散图是对进度进行沟通的主要手段,它显示开发小组在每次迭代中的速度。把速度考虑成一个取值范围而不是单个值是有益的。有一个好办法可以达到这一目的,就是同时使用最近一次迭代的速度,前8次迭代的平均速度和前8次迭代中最差的3次迭代的平均速度。这3个值很好地描绘出刚发生的情况,长期平均的情况和最坏条件下可能发生的情况。

      迭代结束小结在某些项目中可能是有用的,它既可以传递当前的信息,也可以作为供将来使用的历史文档。迭代小结可以包括:迭代日期信息,人员的工作天数,每日构建结果,迭代燃尽图和耗散图,用户故事完成情况,回顾行动事项等。

  • 相关阅读:
    JavaWeb 之 XML 约束
    JavaWeb 之 XML 基础
    Java 之 方法引用
    Java 之 Stream 流
    Java 之 常用函数式接口
    Java 之 函数式编程
    Java 之 函数式接口
    Java 之 JDBCTemplate
    Java 之 数据库连接池
    Java 之 JDBC
  • 原文地址:https://www.cnblogs.com/angela217/p/10834667.html
Copyright © 2011-2022 走看看