迭代计划

在迭代开始之前,要召开迭代计划会议,并得到一份开发计划。每个迭代一般1~3周时间。客户从发布计划(故事列表)里依次选择高优先级的用户故事加入到当前迭代。失败后待修复的验收测试也会被加入到迭代计划中。客户要参照团队上一个迭代的速度,为当前迭代选择数量合适的故事。

团队速度将决定当前迭代包含的故事是否过量。计划故事的理想开发天数之和,不能超过前一个迭代的开发速度。如果迭代包含了太多的故事,客户需要考虑将一些低优先级故事纳入后续迭代。同样,如果迭代任务不饱和,那就再加几个故事进迭代。

然后,团队将用户故事和失败的测试分解为编程任务(Task)。用客户能理解的语言来描述用户故事,而用更倾向于开发者的语言来描述任务。将任务以索引卡片的形式记录下来,移除重复的任务。这些任务卡片构成了迭代的计划细节。

看到任务开发进度变慢时人们常会担忧,但其实不用惧怕。需要坚持单元测试重构,这两个事情任何一个若做得不到位,都会降低你的速度。

不要试图在迭代进行中调整故事点估算。计划过程的基础是对现实有持续一致的估算,强行修正估算会造成更多的问题。

不需要过分关注项目速度或开发进度变慢。每隔3~5个迭代,你可能需要重新估算所有故事并且重新调整发布计划,这都是很常见的情况。只要秉持着“最高价值故事优先开发”的原则,你就在持续为客户及管理者创造着最大的价值。

迭代式开发给开发过程带来了敏捷性。只对当前需要的故事进行计划,而不要过多考虑后续迭代的具体开发任务。