作为一名QA，之前有过一些非系统、打游击式的敏捷工作经验。一直随波逐流跟随公司的文化和管理者对敏捷转型的支持程度去推广敏捷实践。终于，在长行敏捷转型的背景下，专业敏捷老师的带领下，感觉找到了组织，有了一场专业的敏捷实践经历。这篇文章就谈谈我在开发团队如何开展迭代计划的一些经验和心得。
一、会前准备
1、规划好本迭代开发需求；
2、拆分好创建的系统任务；
3、各小队成员都已完成各自个人任务的创建；
4、创建好本次迭代版本；
二、迭代计划会步骤
迭代计划会：why、目标（计划好、承诺好、交付好）（交付：有业务价值、可感知）2周一个迭代1、做什么：明确当前手头需求，对需求进行任务拆分。在本迭代开展前，需要完成需求澄清的工作。即迭代第一天开始就能够进入编码。所以每一个迭代都要预留一定的时间来作为下一个迭代的需求澄清和评审，且大家对需求的理解都能达成一致。
2、确定任务优先顺序：根据业务提供的需求优先级，对本次迭代的系统任务进行排序。
3、我的可用开发容量：我们团队的迭代周期为2周一个迭代。因此每人的一个迭代的工作容量为10人天。但为了应对风险和一些日常事务，以及紧急事务，还有前面提到的需求澄清、会议及一些管理工作，每个人的工作容量都要有所预留。除非是可以全心投入开发的人员，或通过一些加班补充工作量。
如：团队人数为10天，一个迭代为10天，则团队的开发容量为10X10=100人天
4、我们一起排任务（紧密协作、team work）谁有意外一起帮助、达成交付目标
各自认领任务。将任务分配到每个人的名字，并估算出每个任务所需的工作量。当 某人的工作容量超过10人天时，需要其他容量不足的人员进行任务认领，协助完成整个团队的工作任务。
5、这个迭代的交付目标
大家都制定一个共同的迭代交付目标，可交付到下游的交付物。一般为可演示的工作产品/程序。
对于交付物，大家也要有共同的质量认识。我们团队达成共识可交付下游的工作产品即通过了SIT测试的程序。
6、大家的信心指数投票（识别风险，外部依赖）
最后大家通过一个手势来表示对本次迭代能完成的信心。1表示信心指数最低，5表示信心指数最高。同时举手表示。当出现差异时，大家再各自说明理由，进行调整。挖掘团队计划中的风险。
以上，为个人在带领和辅导团队开展迭代计划的一些总结和心得，希望看到这篇文章的敏捷同行能够指导及点评，让我知道有那么一批敏捷的志同道合者也在互相鼓励、努力。谢谢！
网友评论