敏捷软件开发实践-Sprint Status Track

介绍：

对于敏捷软件开发来说，能时刻保持跟进项目的进度是非常重要的，因为你可以随时了解团队的健康状况，并且对各种突发情况进行突发的处理，从而保证每个迭代结束后我们的项目可以按时的交付。

实现方式：

看项目进度的最好的工具当然是burndown chart,我们使用Jira做项目管理工具，Jira中有一个Report视图，可以非常直观的显示story的burn down 曲线，从而让团队直观的明白这个sprint进展的如何。

当然了，这个是从story级别的，它衡量的是随着时间的流失，story point的变化曲线，比如上图可以看出，我们的项目开发速度先慢后快，那是因为多个story同时开展进行，但是都还没结束，所以我们的时间投入了，但是早期并没有相应的story被关闭。2是我们在sprint的中期又加入了新的story，导致story point纵坐标的上扬。

光有burn down图是不对的，我们还必须去track每个story的进度，这就需要大家对每个sub-task进行的过程要及时更新状态，一般story/sub-task有4个状态，Backlog(还没开始做），Work In Progress( 正在做),Ready For Review(做完了，等着被review), Done (review完并且认定是有效的，所以真正关闭这story/sub-task)， 为了让团队更加积极的更新状态，我们使用了white-board track,首先，第一天当所有人吧相应的sub-task都建立好之后，我吧所有的都打印出来，然后以小纸条的形式全部贴在白黑板上，并且放在Backlog中，如果团队成员有任何的进展，那么他们会吧小纸条往前面移动(如吧纸条从Backlog栏目移动到Work In Progress)。

然后，我们在每天的报表中会以2大块来分别阐述Sprint的项目进度，一个是以Story为单位，一个是以团队成员为单位。

比如，报表中以Story为单位的表格如下：

项目中以Resource为视角的报表如下：

总结：

我的经验是，追踪项目进度要各种工具/实践结合起来使用。

(1)用burn down chart宏观的来看项目开展情况，如果现实曲线和理想的benchmark曲线差异太大，team leader需要研究出问题原因并且相应的及时解决，这也是Agile的一个优势，“面向change"

(2)用dashboard来维护各个人的项目开展活动情况，一来提高大家的积极性，因为每次吧小纸条前移都能带来小小的成就感，二是让大家都有竞赛，赛跑的感觉，大家不落后，从而保证项目的健康。

(3)用daily report来提供每天运行情况的snapshot,这也是为了以后流程改善提供有力的事实依据和素材。