利用发布计划,我们顺利地将粗粒度的故事分配到发布中的多轮迭代。这种层次的计划--不包含很多细节,可以避免给出精确需求的错觉,却足以根据它开始行动--适合作为发布计划。然而,在开始一轮迭代的时候,再做进一步的计划也很重要。
迭代计划概览
整个团队通过举行迭代计划会议来为下一轮迭代做计划。客户以及团队中的所有开发人员到要出席参加这个会议。由于团队将仔细研究用户故事,所以毫无疑问他们会有一些问题。他们需要客户随时回答这些问题。
迭代计划会议的一般内容如下。
1.讨论故事。
2.从故事中分解出任务。
3.开发人员承担每个任务的职责。
4.讨论过所有故事,并且接受所有任务后,开发人员单独估计他们承担的任务,以确保他们不会做出过于乐观的承诺。
讨论故事
会议开始时,客户从最高优先级的故事开始,读给开发人员听。然后由开发人员提问,直到他们充分理解故事,能从故事中分解出任务。没有必要理解故事的所有细节,过分地深入每个故事的细节会让会议变得冗长,低效,因为会议中不是每个人都需要聆听所有故事的所有细节。在计划会议后,开发人员仍能喝客户一起理清故事的关键细节。
分解任务
事实上,为何要分解故事呢?为何不直接把故事作为独立的工作单位呢?
1. 尽管故事的确可以小到作为工作单位,但将他们分解出更小的任务,一般更符合项目需要。
2. 其次,故事是对用户或客户有价值的功能的描述,他们并不是开发人员的待办事项。
3. 一个故事的任务分解其实是即时设计中的一次短脉冲,而这些端脉冲的集合取代了瀑布过程的前期设计阶段。
故事分解的准则:
1. 如果故事的某个任务特别难于估算,就把那个任务从故事的其余任务中分解出来。
2. 倘若有些任务可以很容易安排给多名开发人员共同完成,就分割他们。
3.若有必要让客户了解故事某一部分的完成情况,就可以把那部分故事拿出来作为一个任务。
承担责任
一旦确定故事的所有任务,就需要有团队成员自愿执行每个任务。如果任务写在白板上,开发人员可以简单地把自己的名字写在他们认领的任务旁边。
即使才采用结对编程,每个任务通常也最好只关联一个人的名字。
虽然任务是由每个人认领并承担责任的,但在迭代期间,这并不是一成不变的。随着开发的进行,以及对任务的理解,可以进行调整。
估算并确认
任务以及承担任务的开发人员的名字写在白板上,每个开发人员就可以在白板上加上他或她的估算。一旦开发人员估算好自己的每个任务,就需要把这些估算加起来,进而做出实际的评估,看看在迭代中能否完成所有的任务。例如,假设为期2周的迭代开始了,我已经承担了一个任务,目前我估算完成任务实际需要53个小时。算上我必须要做的其他事情,我没有把握在这些任务上投入那么多的时间。如果没有其他人可以接手我的工作,那么这个时候客户就有必要帮忙从迭代中移除一些工作。每个开发人员必须能够放心地承诺完成自己将要承担的工作。而且,由于整个团队必须同舟共济,所以每个人都必须对整个团队做出的承诺有把握。