团队开始采用敏捷的方式开发产品了，一般都会应用一大堆的最佳实践。比如：用户故事、站会、敏捷扑克、演示会、回顾会、Velocity图、燃尽图等等。这么多的实践都用上了，团队做得风生水起、热火朝天。可是到了汇报进度的时候，大家习惯性的还是会用老方法。
这天，团队开始开站会了。Master主持会议，让大家都按站会的要求说说。每个成员还都学得挺好，说一说昨天做什么了，今天打算做什么，也会提一下风险与依赖。Master在每个人说完都会问一句：“进度正常吗？”，大家一般都会说：“正常”。有时候大家也会说：“有点延迟，不过问题不大，应该能赶回来，就算正常吧”。一圈说下来，基本上大家都会说“进度正常”。然后Master就会认为团队整体进度是正常的，也会向上汇报说：“我们组的进度是正常的”。
团队的领导收到各个团队口头或书面汇报上来的进度情况后，汇总一下，一般进度也会是正常的。但是每每到了迭代后期，尤其是快结束迭代的时候，进度就突然不正常了，出现大量的延迟。团队再想采取什么措施就已经来不及了。
这是比较常见的场景，虽然团队实施了敏捷，但是进度的管理方式仍然使用了传统的口口相传的模式，进度状态在一层层的信息传递转换中，逐步失真了。导致不能进行有效的进度管理。而且这种传统的进度管理模式进度状态的更新频率是日更。如何能拿到准确的、实时的进度信息呢？关键点在于如何能够保持透明的进度信息并进行有效的管理。
在敏捷环境下，大部分团队都会使用JIRA进行迭代的管理、Story或任务状态的更新。而有些团队会要求成员录入工时。对于这样的团队，在这里介绍一个方法来保持进度的透明性。这个方法有三个要求：
１、Master要要求团队成员养成拖动任务／修改任务状态的习惯。一旦开始一个任务就要把它拖动到工作中，一旦完成就要把它拖动到关闭状态。
２、当成员工作在一个任务上的时候，每告一段落之后要要更新工时。
３、更新工时的时候，要更新这个任务的到目前为止的最新剩余时间。
做到这三步以后，就可以得到实时的准确的进度数据了。
为什么做到这三步就能得到准确的实时进度数据了呢？
1、第一步要求实时更新Story/任务状态。这样从迭代面板上可以看到直观的各个任务的进展状态。Master和整个团队都可以随时通过面板了解到整个团队的任务进度状况，减少了口头沟通和信息损失。
2、第二步要求记录任务的花费时间，JIRA会自动从任务的原始估时里自动减去新记录的任务时间。如果团队做到这一步，Master和团队就可以了解到我们的计划进度目前完成到什么程度。也就是说当时计划会议制定的计划，现在完成了多少。
3、第三步要求不止记录任务的花费时间，而且要求根据对任务进一步的了解主动更新一下还需要多长时间才能真正完成这个任务。在这个步骤上，有可能剩余时间比计划的剩余时间小很多。比如：一个任务计划1.5d，实际花费了0.5d完成了一小部分，但是根据最新的判断这个任务实际上再花0.2d就可以完成了，此时就把剩余工时主动设置为0.2d（下图蓝色部分）。而如果根据最新的判断这个任务还需要1.8d才能完成，就把剩余工时主动设置为1.8d（下图绿色部分）。
完成上面三步以后，就可以得到上面这个燃尽图。由于这个燃尽图是由整个团队的每个成员对其负责的任务进行实时更新的到的数据，所以Master和团队就可以实时了解到真实的进度状况。
Master在向上级领导汇报进度的时候，就可以直接看图汇报团队进度。而不需要通过站会沟通才能获取团队的进度。从而节省了关于进度沟通的代价。更进一步，团队的领导或者PgM也可以通过查看各个团队的燃尽图直接获得各个团队的客观进度，省去了向各个团队Master询问进度的繁琐。
这就是敏捷的透明性的一种实现，减少了沟通成本，提高了沟通效率，并且让各个层次都能直接获得真实的信息。
注：如何解读燃尽图获取进度信息，请查看：敏捷里的燃尽图有什么用
