|
承诺驱动——Scrum使用初期(最初的几个Sprint)项目经理圈子
在我们头几个Sprint中，由于开发小组对自己的Velocity没有足够的了解，对Scrum也没有足够的了解，所以我们用“承诺驱动”的方式来决定Sprint内会完成多少的任务(“故事”)，以下是我们的主要步骤：blog.mypm.net
1.明确功能的优先级项目管理者联盟
2.明确此次Sprint要达到的目标转自项目管理者联盟
3.选择优先级最高的功能，分解为实现任务，并评估如何实现blog.mypm.net
4.如果Team承诺可以在Sprint内实现，则此功能加入到Sprint Backlog中。如果不能承诺，和PO商议，一个办法是拆分功能，另一个办法就是放弃这个功能项目管理者联盟
5.不断评审优先级最高的一些功能，直至Team不能承诺完成为止项目经理圈子
Velocity驱动――Scrum使用一段时间后项目管理者联盟
随着几个Sprint，开发团队、管理层、PO对于开发的效率、质量等不断调整心理预期与实际的差距，需要一个量化的指标可以正确标识团队的开发能力，同时也可以作为团队绩效考核的一个参考，这个时候就需要评定团队的Velocity。我们是这样做的：www.mypm.net
1.记录每个Sprint可以实现功能的IMD(Ideal Man Day)，实现功能的标准是任务可以发布(编码、测试、部署、文档等)，而不是仅仅编码完成www.mypm.net
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的沟通较少所致www.mypm.net
b) 技术架构不成熟，还在不断构建，影响了实际业务层面的实现talent.mypm.net
c) 有一些技术支持的工作项目管理者联盟
4.平均前三期sprint的资源利用率。我们没有按照上一期Sprint的资源利用率来作为参考，是因为我们对于任务的完成按照100%完成的标准。按照前三期的平均值，更加可行
5.用第四步得到的资源利用率，乘以即将开始的Sprint内可以利用的资源，基本可以得到此次Sprint的团队开发能力(Velocity)项目管理者联盟
|
