迭代计划执行与管理全解析
1. 迭代计划后的工作开展
迭代计划完成后，工作便正式启动。团队成员需要确定如何履行承诺。通常情况下，程序员会主动承担任务，并寻找搭档进行结对编程。当一对程序员完成任务后，他们会分开，各自从任务板上选取新任务，再组成新的结对小组。
其他团队成员也各有职责。由于程序员通常是系统中的瓶颈，客户和测试人员无需像程序员那样使用任务规划板。他们的主要职责是关注程序员的进度，并提前安排好工作，以便在程序员需要时能够及时提供支持，从而提高整个团队的生产力。
随着工作的推进，要根据实际情况及时修订迭代计划。但需记录原始的任务和故事估算，以便为下一次迭代计划提供参考。要时刻牢记，团队的承诺是交付故事，而不是完成任务，因此需不断审视当前计划是否能达成这一目标。
迭代结束时，将完成的软件交付给相关利益者。若构建过程高效（如10分钟内完成），只需按下按钮，稍作等待即可。次日上午，通过展示前一晚完成的工作开启新的迭代。
2. 应对长时间的迭代计划会议
迭代计划会议通常应控制在半小时至四小时之间，大部分时间用于讨论工程任务。对于经验丰富的团队，如果早上进行迭代演示，计划会议通常在午餐前结束。
新团队往往难以快速完成计划会议，这在最初的几次迭代中是正常现象。团队需要时间来熟悉问题领域、掌握设计问题的常见解决方法以及了解如何更好地协作。
若一个月左右后，迭代计划会议仍然耗时过长，就需要寻找提速的方法。常见问题包括在迭代计划会议中花费过多时间进行发布计划，实际上大部分发布计划应在上一次迭代中由客户完成，而程序员专注于故事开发。从发布计划中选取本次迭代的故事应是简单的操作，无需进行估算和
