(书摘：用户故事与敏捷方法)第十章 迭代计划

     利用发布计划，我们顺利地将粗粒度的故事分配到发布中的多轮迭代。这种层次的计划--不包含很多细节，可以避免给出精确需求的错觉，却足以根据它开始行动--适合作为发布计划。然而，在开始一轮迭代的时候，再做进一步的计划也很重要。

 

迭代计划概览

    整个团队通过举行迭代计划会议来为下一轮迭代做计划。客户以及团队中的所有开发人员到要出席参加这个会议。由于团队将仔细研究用户故事，所以毫无疑问他们会有一些问题。他们需要客户随时回答这些问题。

    迭代计划会议的一般内容如下。

    1.讨论故事。

    2.从故事中分解出任务。

    3.开发人员承担每个任务的职责。

    4.讨论过所有故事，并且接受所有任务后，开发人员单独估计他们承担的任务，以确保他们不会做出过于乐观的承诺。

 

讨论故事

     会议开始时，客户从最高优先级的故事开始，读给开发人员听。然后由开发人员提问，直到他们充分理解故事，能从故事中分解出任务。没有必要理解故事的所有细节，过分地深入每个故事的细节会让会议变得冗长，低效，因为会议中不是每个人都需要聆听所有故事的所有细节。在计划会议后，开发人员仍能喝客户一起理清故事的关键细节。

 

分解任务

    事实上，为何要分解故事呢？为何不直接把故事作为独立的工作单位呢？

    1. 尽管故事的确可以小到作为工作单位，但将他们分解出更小的任务，一般更符合项目需要。

    2. 其次，故事是对用户或客户有价值的功能的描述，他们并不是开发人员的待办事项。

    3. 一个故事的任务分解其实是即时设计中的一次短脉冲，而这些端脉冲的集合取代了瀑布过程的前期设计阶段。

 

    故事分解的准则：

    1. 如果故事的某个任务特别难于估算，就把那个任务从故事的其余任务中分解出来。

    2. 倘若有些任务可以很容易安排给多名开发人员共同完成，就分割他们。

    3.若有必要让客户了解故事某一部分的完成情况，就可以把那部分故事拿出来作为一个任务。

 

承担责任

    一旦确定故事的所有任务，就需要有团队成员自愿执行每个任务。如果任务写在白板上，开发人员可以简单地把自己的名字写在他们认领的任务旁边。

    即使才采用结对编程，每个任务通常也最好只关联一个人的名字。

    虽然任务是由每个人认领并承担责任的，但在迭代期间，这并不是一成不变的。随着开发的进行，以及对任务的理解，可以进行调整。

 

估算并确认

    任务以及承担任务的开发人员的名字写在白板上，每个开发人员就可以在白板上加上他或她的估算。一旦开发人员估算好自己的每个任务，就需要把这些估算加起来，进而做出实际的评估，看看在迭代中能否完成所有的任务。例如，假设为期2周的迭代开始了，我已经承担了一个任务，目前我估算完成任务实际需要53个小时。算上我必须要做的其他事情，我没有把握在这些任务上投入那么多的时间。如果没有其他人可以接手我的工作，那么这个时候客户就有必要帮忙从迭代中移除一些工作。每个开发人员必须能够放心地承诺完成自己将要承担的工作。而且，由于整个团队必须同舟共济，所以每个人都必须对整个团队做出的承诺有把握。