迭代中期

         迭代中期，我们发现迭代初期制定的任务并非预料那么简单。 这很正常，正如我之前所说，迭代计划一定是和实际情况有出入的，如果发现完全符合计划，那只能说明两个问题：第一，该计划是在任务完成之后做的，做该计划的原因是项目规定。第二，迭代的完成是因为时间到了，而并非实际任务的完成。但是，这种出入会随着项目的不断深入，越来越接近于零值。所以在项目初期制定迭代计划时，需要将用例根据业务价值排序，在迭代划分上优先实现业务价值高的用例。根据旧故事或者完美编程将用例拆分成多个不少于一天不多于四天的任务，以人/日的方式制定在迭代计划中。这种计划只是初始计划，常常和实际的情况有较大出入，多数情况下应以最乐观形式规划。然后迅速寻找到业务价值高且风险较低的任务在三到四个工作日内加以实现，测试出基本速度，重新规代迭代。

         迭代计划与编辑是同步的，开发一些新功能->进行整体的重构->开发一些结构->尝试一些试验->从实践中总结经验。

         在迭代过程中，项目经理应该密切注视哪些任务已经完成，多少任务尚未处理完毕。提示团队可能出现的问题：任务过多，过少、人员负担过重或过轻。以便于及时调整计划。当工作较多时，尽可能不要更改日期，而是缩小迭代任务的范围。

• 列出本次迭代用例
• 在白板上写下每个用例中可以拆分的任务
• 向列表中添加所有需要完成的技术任务
• 开发人员根据个人的速度和能力申请并评估任务
• 如果任务没有被完全申请，则需要项目经理甚至客户介入
• 如果还有多余时间，添加新故事

          在每一天的开始，以任何一种非正式的形式花费5到10分钟讨论团队中各成员的任务及成员间的合作。确定后迅速分开，将自己的计划记录在团队协作工具里，便于检查和总结。

          在迭代的末期，大家一起总结这次迭代的经验，在下一次迭代中加以改进。如果工作有效，下一次迭代会更贴近实际。