迭代周期Iteration长度控制

昨日PM小组例会，谈到了需求 评估工作量远大于有效资源情况下，如何保证迭代周期稳定的问题。讨论的内容，对于PM如何控制、保持迭代周期稳定有较大的参考价值。

	有效资源	评估工作量
1	多	少
2	少	多
3	相同	相同

注：
有效资源：指迭代周期内，开发团队所能提供的有效工作日，单位人/天。
评估工作量：指迭代周期内，产品经理提供需要实现的业务需求所评估的工作量之和。

上表描述以固定周期为两周的迭代中，可能会出现的有效资源和评估工作量对比情况。其中，1、3两种情况因为评估工作量小于或等同能提供的有效资源，所以不会影响迭代周期。重点需讨论的是有效资源小于评估工作量时，如何保持固定周期？

例举：一迭代周期，能提供有效资源20人/天，需求评估工作量30人/天。
1、功能较独立，需求不能拆分发布；
安排一个release，两个iteration。这种情况需要在迭代2中附加一些技术改造或低优先级的小需求、bugfix，release日期相对会慢几天。

2、一个迭代中包括多个产品的需求(需要各位产品经理协商，决定需求优先级)；
a)、以保证质量为重：
忽略商业优先级，先处理一个迭代中就能全部完成的需求。

b)、保证价值
分两个迭代完成，一次release。

通常情况下，我们尽力保证迭代周期的稳定，但也允许例外，如：商业需求，产品上确定了发布时间点，或者节假期间团队请假比较多，一个迭代所能提供的有效资源相对比较少的情况。

保持迭代周期稳定，其核心是： 固定Timebox和可提供的资源，让产品经理来决定需求的优先级，每迭代只接纳(开发/QA资源)可承受的需求。