产品开发和项目执行并存情况下的敏捷实践心得分享

1.周期性会议及会议安排

Sprint Planning	周一（两周/次）	选择和估算当前Sprint的工作项 产品负责人逐条讲解最重要的产品功能 明确各开发团队总的工作量，定义本Sprint产品增量开发工作量饱和程度和客户项目实施预留
Sprint Refinement	周三（一周/次）	Sprint运转状态同步 代办事项打分 问题追踪 Management Board讨论
Sprint Review	周五（两周/次）	Sprint事项完成情况review Retrospective 看板DigitalKey-Mgm中的行动项review
Daily Meeting	每天	开发任务状态同步。 分享对目标的理解。 协调工作。 分享问题和改进。 认同为一个团队。	各端团队自行组织，其余人员可按需主动参与讨论或旁听

2.Sprint工作范围确定

Sprint 工作范围需考虑多部分工作来源：产品增量开发、客户项目实施、临时行动项执行等，并考虑团队成员能力差异等因素最终确定各Sprint工作总和及范围。

根据如上描述，现针对一个7人的开发团队，2周（10个工作日）为一个Sprint，举例如下图所示：

在理想情况下，如该团队成员能力和评估Story Point标准人员一致，则此团队在一个Sprint周期内可完成70个Story Point。但团队的实际人员素质和标准人员有一定差异，我们把这个差异评估量化为10分，40分为产品增量开发，20分为客户项目执行预留，所以该团队在一个Sprint周期内实际可完成的分数的能力是60分。但在各Sprint实际执行过程中，客户项目执行部分的不确定性是很大的，因此客户项目执行部分的工作量总和可能大于或小于20个Story Points。针对小于的情况是可接受的，团队可在后续执行过程中随着经验的增加优化此部分预留；如果是大于20分的情况，此时各端负责人须在Sprint Refinement会议上提出，根据其优先级可讨论此事项是否一定要在此Sprint执行，或根据优先级将部分产品增量开发工作量移除。相关范围变动需做好记录。

3.规定

3.1Scrum运作规定

1. 原则上Sprint Planning会议上定义的所有产品故事必须完成。因不可抗力等原因不能完成，需提前在Sprint Refinement会议上提出评估。由数字钥匙整体团队共同决定是否接受。
2. 原则上如未出现客户项目执行、临时行动项大于预估的情况，产品增量开发部分范围在Sprint执行周期内冻结不可变。
3. 针对客户项目执行部分，实际情况小于预留分数是可接受的。
4. 各Sprint结束需考核各团队工作效率。其指标为实际完成分数除以理论应完成分数总和。如上图客户项目执行部分预留为20分，若实际执行的工作事项为16分而产品增量开发部分按计划完成。 则此团队的效率指数为：（40+16）/ 70=80%.
5. Sprint执行期间，各任务的状态维护责任人为各团队负责人。需保证状态和实际执行情况一致。

4.工具分享 

可通过一些Burn down或BurnUp的图表来直观显示执行的状态、范围的变动等，下图是Jira中的管理图表。