敏捷软件开发实践-Sprint Task Split

介绍：

在开完了Sprint Setup Meeting,并且吧所有的Story Point都合理的估算之后，下面一步就是吧story细分到每个开发者/测试者手里，让他们在story下面建sub-task. 这里最关键的问题是，如何更高效的利用团队的人力资源并且做最合理的分配。

实现方式：

这个其实都是根据skill set来的，因为大家都知道，一个团队的人的水平，经验都层次不齐，有高级/中级的工程师，有这个领域专家，有的擅长另外一个领域。

所以我们团队，去年刚建立的时候，第一件事情就是收集下每个人的skill set.从而team leader可以更好的了解每个人的长处和短处，从而更加科学的分配任务。

一个skill set往往是一个excel表格，这里晒下我的skill set（局部）

在有了所有人的skill set之后，我会根据团队情况进行合理的任务分配，如果这个Sprint估算的总的story point很多，估计团队会很忙，那么我会尽可能吧按照skill set分配任务，吧story分给这个领域最擅长的人来做来达到极限的速度。如果Sprint估算下来不算很忙，那么我会让大家去挑选story,尽量做自己不擅长的，从而可以更有效的提升团队的整体战斗力，而且可以相互学习共同提高。

在分配完所有的story之后，我会让团队的人在自己负责的story下面建自己的sub-task,并且给上估算时间 ，这个时间让开发者自己来估计，因为只有自己才对自己的速度有比较靠谱的认识，别人估算的结果对于他来说是没有任何意义的。这个时间其实不要太精确，只要不是太离谱就行了。（不要象出现修改一个页面某表单的js校验估上10个小时这种差异就可以）， 然后所有人都建立好sub-task之后，我和模块负责人会依次review每个sub-task。

总结：

(1)分配story到各人建议根据skill set和sprint 进度来定，如果时间充裕，尽量分配大家做自己不擅长的模块，领域来达到锻炼和建设团队的作用，如果时间紧凑，尽量按照最高skill set来分配从而保证项目按时交付。

(2)建立sub-task一定要及时，最好在story确定下来之后立刻建，而不是要等story开始了再建，这样可以确保burn down chart比较好看，而且这些sub-task一定要专门的人负责review下确保他们的时间估算都合情合理。