我所在的团队有六个开发人员,两个测试人员.我们的过程还不成熟,基本上处于初级阶段,需要不断的改进.一个新的版本开始了,开发计划的制定是首先遇到的问题.
计划始终依赖于需求和人员,涵盖的内容包括几个重要的里程碑:需求分析,设计与实现,测试.只要把这三个阶段的时间估算出来,基本上这个版本的计划就会更容易制定.人员是相对固定的,而需求是相对变化的,我们第一步就是要确定需求.通常我们和市场人员一起讨论优先级相对比较高的需求,这部分工作会在新版本开始之前就做好.接下来就是评估每个需求需要的时间.如何估算每个需求的开发时间是个大难题.XP提供的方法是把每项任务都分配一个点数,不确定一个点需要多长时间,只确定两个点需要的时间是一个点的两倍.基于目前我们的开发人员的整体能力和过程,这一点暂时还做不到,我们就做了一点变通,由我来判断大概一个需求需要的点数.如果没法判断,说明我对细节的了解还不够,那就把需求再细化,分成若干个任务,不是尽可能地细,而是尽可能地粗粒度.这样我就可以花最少的时间达到我的目的.
然后再对每项任务分配点数.现在,我的任务就是怎么样去分配点数了.通常每个任务都分表现层,业务层和持久层,根据任务的复杂度来安排点数,复杂度包括代码行数,业务的复杂度,功能点等,主要还是根据经验判断.
把每个需求的点数分配完后,再引开发人员的估算.有六个开发人员,每个人完成一个点的的时间各不一样.我只能先选择一个需求,根据过去我们开发类似功能经验估算能力最高的人需要N小时,能力最低的人需要多久M小时.再通常整体开发能力的分布情况稍微调整一下N+M/2.那么我们完成所有需求的时间大概就估算出来了.当然这只是计划,我们还需要在开发的各个阶段做出适当的调整.
如果完成所有需求的周期过长,一般来讲我们每个版本的开发周期都不应该超过一个月,那么就要把一些需求移一下个版本,相应地,这些需求的优先级会再升一级.
接下来是估算测试的时间.相关的测试人员领取自己要测试的需求,根据需求的分析文档来估算大概的测试的时间,这一部分不会有太大的出入,估得都会比较准.如果需求发生变化,根据情况调整测试时间.
现在三个阶段的时间都估算完了,接着就是增加缓冲时间,我们通常以开发时间的30%做为缓冲时间,这部分时间会被一些额外的工作,如比较紧急的产品bug或者突然生病之类的意外所占用.当然,30%是不确定的,要根据过去几个版本的历史数据积累来做出适当的判断.
此外还有一点是比较有趣的,算是意外的收获.当分配完每个需求的点数之后, 任务就被细化,那么任务的安排就会变得更灵活.同时,每个开发人员开发的点数就会被做为历史数据,如果你上一版本(两周的开发时间)开发了六个点数据的任务,那么这个版本(同样是两周)你就不可能离六个点数太远.同样的情况适用于整个团队,这样我只需要估算每个需求的的点数,而不用发愁到底我的团队在这个版本中可以开发多少需求,或是这么多需求我不知道要开发多久.实际上有点解耦的味道在里面,把需求和开发人员变化隔离开了.
XP有许多的概念和最佳实践,但真正要找到适合我们的最佳实践, 还有很长一段路要走.