用户故事与敏捷方法 - 第十章 迭代故事

迭代故事

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

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

1.讨论故事

2.从故事分解任务

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

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

讨论故事：

        团队获得一个已经安排好的优先级故事集合，一次作为迭代计划会议输入。正如程序员可能改变他们对实现一个故事难度的看法，客户一样可能会改变他们故事优先级的想法。迭代会议会是调整故事优先级的良好时机。

       会议开始时，客户从最高优先级故事开始，读给开发者听，然后开发者充分提问，知道他们理解故事，可以从故事中分解出任务。没有必要理解故事所有细节，过分的讨论每个故事的细节会导致会议变得冗长，低效，因为会议中不会每个人都需要聆听故事的细节。在计划会议后，开发者仍然有时间有客户一起交流。

分解任务：

        将故事分解为任务没有什么窍门，许多开发人员他们的职业生涯一直在做这样的事情。由于故事已经比较小了，所以通常没有必要进行更多分解。

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

        尽管故事的确可以小到可以作为工作单位，但是将他们分解出更小的任务，更符合项目的需要。首先对于很多团肚来