昨日PM小组例会，谈到了需求评估工作量远大于有效资源情况下，如何保证迭代周期稳定的问题。讨论的内容，对于PM如何控制、保持迭代周期稳定有较大的参考价值。
| |
有效资源 |
评估工作量 |
| 1 |
多 |
少 |
| 2 |
少 |
多 |
| 3 |
相同 |
相同 |
注：
有效资源：指迭代周期内，开发团队所能提供的有效工作日，单位人/天。
评估工作量：指迭代周期内，产品经理提供需要实现的业务需求所评估的工作量之和。
上表描述以固定周期为两周的迭代中，可能会出现的有效资源和评估工作量对比情况。其中，1、3两种情况因为评估工作量小于或等同能提供的有效资源，所以不会影响迭代周期。重点需讨论的是有效资源小于评估工作量时，如何保持固定周期？
例举：一迭代周期，能提供有效资源20人/天，需求评估工作量30人/天。
1、功能较独立，需求不能拆分发布；
安排一个release，两个iterative。这种情况需要在迭代2中附加一些技术改造或低优先级的小需求、bugfix，release日期相对会慢几天。
2、一个迭代中包括多个产品的需求(需要各位产品经理协商，决定需求优先级)；
a)、以保证质量为重：
忽略商业优先级，先处理一个迭代中就能全部完成的需求。
b)、保证价值
分两个迭代完成，一次release。
通常情况下，我们尽力保证迭代周期的稳定，但也允许例外，如：商业需求，产品上确定了发布时间点，或者节假期间团队请假比较多，一个迭代所能提供的有效资源相对比较少的情况。
保持迭代周期稳定，其核心是：
固定Timebox和可提供的资源，让产品经理来决定需求的优先级，每迭代只接纳(开发/QA资源)可承受的需求。
posted on 2011-01-13 15:31
josson 阅读(998)
评论(0) 编辑 收藏 所属分类:
项目管理