Scrum使用不同阶段，如何判定Sprint内可以完成多少功能？.doc

Scrum 使用不同阶段，如何判定 Sprint 内可以完成多少功能？ 承诺驱动 —— Scrum 使用初期 (最初的几个 Sprint) 在我们头几个 Sprint中，由于开发小组对自己的 Velocity没有足够的了解，对 Scrum 也没有足够的了解，所以我们用“承诺驱动”的方式来决定 Sprint 内会完成多少的任务 (“故事” )，以下是我们的主要步骤： 1.明确功能的优先级 2.明确此次 Sprint 要达到的目标 3.选择优先级最高的功能，分解为实现任务，并评估如何实现 4.如果 Team 承诺可以在 Sprint 内实现，则此功能加入到 Sprint Backlog中。如果不能承诺，和 PO 商议，一个办法是拆分功能，另一个办法就是放弃这个功能 5.不断评审优先级最高的一些功能，直至 Team 不能承诺完成为止 Velocity 驱动―― Scrum 使用一段时间后 随着几个 Sprint，开发团队、管理层、 PO 对于开发的效率、质量等不断调整心理预期与实际的差距，需要一个量化的指标可以正确标识团队的开发能力，同时也可以作为团队绩效考核的一个参考，这个时候就需要评定团队的Velocity。我们是这样做的： 1.记录每个 Sprint 可以实现功能的 IMD(Ideal Man Day)，实现功能的标准是任务可以发布 (编码、测试、部署、文档等 )，而不是仅仅编码完成 2.记录每个 Sprint 实际的可以利用的资源。例如我们在第三个 Sprint 时，团队 7 个成员 (A， B， C， D,E， F， G)， 3 个星期的开发周期， A， C， E,F,G 将全勤， B 会请假 2 天， D 最后一个星期才会加入团队，所以此次 Sprint 团队实际的可利用资源为： 5*15+13+7=95(MD) 3.计算资源利用率：实际完成功能的 IMD / 实际可利用的资源。以我们的第三个 Sprint 为例，当时完成的实际功能的 IMD 为 52IMD，资源利用率为： 52 / 95 = 54.7%。我总结了团队资源利用率不高的一些原因： a) 团队刚接触新的业务，对需求的理解花费较长的时间，同时测试也发现了实现和需求不符的地方，这是由于开发人员和 PO 的沟通较少所致 b) 技术架构不成熟，还在不断构建，影响了实际业务层面的实现 c) 有一些技术支持的