结合工具来实现敏捷开发 - 9

好了，已经有了Product Backlog了，假设我们也已经放了不少功能点进去了，当然这里怎么放我就不说了，无非就是点哪个按钮的问题，如果说的太详细就变成介绍产品了，而不是在讲敏捷了。

 

这个池子既然已经有水了，接下来的事情就开始要把水放掉了，一次放掉一点。之前说Scrum是有增量的迭代，那么迭代是什么呢？简单来说，迭代就是一个周期，可能是一周也可能是两周，一般时间不会太长，在这个周期内，我们会从池子里拿出一些功能点让开发来完成并且需要经常有可用的版本让QA来测试通过，一个周期完成后就会紧接着另外一个周期。Scrum里把这么一个迭代周期叫做一个Sprint，中文叫做冲刺。

 

既然要把功能点放到一个Sprint里来，那就得确定哪些功能需要放进去做了，这样我们就要开始涉及到了Scrum的一个术语：Sprint Planning Meeting，中文翻译成计划会。这个会是干嘛的呢，主要是做以下几件事情：

1.       决定哪些功能点需要这个Sprint中完成

2.       预估每个功能点需要花费的时间

项目经理/产品经理，甚至设计人员会出来简单介绍一下这些功能是干什么的，然后由相关的开发人员讨论需要多少时间。最后肯定会得出一个结论来，因为一个Sprint的周期我们是固定的，所以根据功能点的开发难易而导致的时间花费长短，最后可能会增减某些功能点，当然减掉的功能还是会在下一个Sprint中完成的。

 

计划会当然不能靠DevSuite系统来自动开的，都是需要行政安排来召集一些人在会议室开的（呵呵，在Scrum中，其实人的因素还是主要的，设计、编程、测试都得靠人的，工具只是辅助的，人才是决定性的），不过过程中还是需要打开DevSpec来进行讲解的。DevSuite系统中，每个功能点都有定义两个主要属性：优先级和紧急程度，一般情况下，决定这个Sprint需要做哪些功能就是通过这两个属性来决定的，优先级高的，紧急的，当然会优先来做掉。

 

开计划会的另外一个结果也是非常重要的，也就是上面说的预估了每个功能点的需要花费时间，并且会把这个预估时间写到这个功能点里面去，以小时的形式，以后每天开发人员完成一天工作后，需要把当天在这个功能点上花费时间写上去，并且还需要写上预计剩余时间，这样子的话，通过Sprint各个功能点开发已用时间与剩余时间，DevSuite就会给出一个大约这个Sprint预计什么时候开发完成，是否会有延期之类的趋势报表图来，这个趋势图其实也是Scrum的另外一个概念，燃尽图（Burndown Report），我们的产品经理、项目经理对这个图非常有兴趣。以前是经常得天天去问他们做得咋样子了呀，能不能按时完成，现在是可以从产品里看出来做到什么程度了，减轻很多工作量了。当然，还是得用行政命令让各个员工认真填写那些时间值，有真实数据才能得到真实的结论。