敏捷项目管理Scrum方法实践

敏捷项目管理Scrum方法实践

1.Scrum实践概述

        Scrum是迭代式增量软件开发的一种流程，是敏捷方法论中的重要框架之一，通常应用于敏捷软件开发。Scrum团队主要由敏捷教练、产品负责人（代表利益客户）、开发团队组成。

        首先产品负责人（Product Owner）获取相关方需求，并生成带有优先级的产品待办列表（Product Backlog），在每个迭代周期开始时，由团队成员召开迭代规划会议，从产品需求列表中挑选出本个迭代期要实现的功能，得到一个Sprint迭代待办事项列表，接下来开发团队会进入到一个1-4周的迭代期，在迭代期内，开发团队会进行项目的开发、测试等工作，并召开每日站会（控制在15分钟内），迭代完成后，召开迭代评审会议和迭代回顾会议，并生成潜在可发布的产品增量。

2.如何使用Scrum

       使用Scrum开发时，要从角色、产出物、支柱、会议的角度去执行，此方法注重的五大价值观为：“承若、专注、开放、尊重、勇气”。

 

2.1 敏捷实践的3个支柱

2.1.1透明性（Transparency）

        实施过程中的关键环节对相关方是显而易见的，同时保证相关方对这些关节的理解是一致的。

2.1.2检验（Inspection）

        Scrum使用者必须经常检视Scrum的输出成果和完成Sprint目标的进展，确保能够及时发现过程中的重大偏差。

2.1.3适应（Adaptation）

        如果检视发现一个或多个方面偏离可接受范围以外，并且将会导致产品不可接受时，就必须对过程或过程化的内容加以调整，并必须尽快执行，降低进一步的偏离。

2.2 敏捷实践的3个角色

2.2.1产品负责人（Product Owner）

        产品负责人一般为客户的代言人与相关方、客户及团队合作提供产品反馈，根据商业价值对任务进行排序并创建（或与团队共同创建）、维护产品待办事项列表，监控需求，根据实际情况清理、变更需求及排序，并帮助团队了解在怎样不产生浪费的情况下交付最大价值，同时有权利接受或拒绝团队的工作成果。

        产品负责人的任职要求：拥有相关工作背景，能为决策提供专业的技能知识。

2.2.2敏捷教练（Scrum Master）

       敏捷教练一般是由项目经理、Scrum主管、项目团队领导担任，服务于团对。工作重点从“管理协调”转向“促进合作”，促进个人参与、促进团队内部和团队之间的合作与对话，不代替其他责任人做出决策。

       将团队从详尽的文档、冗长的过程、频繁的打扰、跨部门工作等问题中解放出来。通过技术项目管理活动（敏捷实践与原则），提供培训或者支持性工作。

2.2.3项目团队（Scrum Term）

        项目团队由3~9（正负2人变动，人数过多时可拆分团队）名成员组成，100%专职成员，通才型专家（PO，SM不包含在人数中）。团队获取授权，自组织和管理他们的工作。团队成员有强烈的产品责任感，以价值驱动为导向，鼓励建设性对抗。

        作为一个独立的团队他们的特点是：“聚焦绩效、交付价值、自主决策、自主担责”。在工作地点上首选集中办公，倡导透明沟通（渗透式）、知识共享、致力于相互合作，若因地区差异也要能进行虚拟办公，使用在线协作工具（视频、看板）辅助沟通。

2.3 敏捷实践的3个产出

2.3.1产品待办事项列表(Product Backlog)

       产品待办事项列表有产品经理（或与团队成员一起）为即将进行的迭代、细化足够的故事所创建的，它是所有工作的有序列表，以故事的形式呈现给团队，价值越大的排在上面。同时向团队介绍故事创意、潜在的挑战或问题。如不确定依赖关系，会请求团队相应功能进行刺探，以了解风险。

       产品负责人PO制作一个产品路线图，以显示预期的可交付成果序列。产品负责人根据团队的实际成果重新规划路线。

产品待办事项列表的要点：

1	产品待办事项列表的本质是所有工作的有序列表，以价值为导向
2	产品待办事项列表的细化梳理是渐进明细的
3	过大的用户故事需要拆分，确保能够在迭代期间内完成
4	其排序考虑价值+风险，还可能考虑成本、依赖、政治等
5	其包含功能性内容和非功能性内容，技术债务、风险应对、运维工作等作为非功能性用户故事列入待办事项

2.3.2迭代待办事项列表（Sprint Backlog）

        在迭代规划会议上团队成员从产品待办事项列表中认领需要完成的用户故事，并在会议中产出迭代待办事项列表（Sprint Backlog）。

        迭代待办事项列表中定义了Sprint迭代的目标，明确了Sprint过程中具体需要完成的任务，团队成员可以增加、修改或删除任务，Sprint列表一般不会改变，但是如果“用户故事已经显然无效”也应该进行删除，或者当前情况紧急（不处理会危及整个迭代），可以对迭代待办事项列表进行调整。

        对于列表中的一些事项，如果团队同意，可以现做大的整体估算，在Sprint进行当中在分解成任务，同时对于每一个任务，每日应该更新剩余任务工作量的估算。

2.3.3可交付产品增量（Increment）

       可交付产品增量是一次迭代中实际完成的用户故事。

3. 敏捷实践5大会议

3.5.1产品待办事项列表梳理会议（Release Planning）

        产品待办事项列表梳理会其实是贯穿在所有Sprint中间的活动，这个会议不仅为当下的Sprint打下基础，还为之后的Sprint提供有限要做的待办事项。

3.5.2迭代规划会议（Sprint Planning）

       迭代规划会议是为即将要开展的Sprint制定计划、确定迭代目标、事项和任务，PO、开发团队、敏捷教练都需要参加，会议控制在8h/月以内（每周迭代时长对应约2h会议时间），相关方可通过参加迭代规划会议了解团队情况和产品情况，会议的基本内容如下：

• 一般由PO讲解待办事项列表，并细化故事，团队来进行评估，得出迭代待办事项列表；
• 将用户故事拆分成任务以估算时间；
• 团队领取任务；
• 更新Sprint待办事项列表；

3.5.3每日站会（Daily Scrum）

       在项目迭代期间，团队需要进行每日站会，团队中的任何人都可以主持会议，以某种方式“过一下”看板任务，会议时长一般不超过15分钟（如果人数过多可以稍微延长，或拆分团队）。

       站会是支撑敏捷原则的基石之一，不可随意取消，站会上我们的主要目的是为了同步信息，发现问题，不提倡在站会中解决问题，会议中每个人都需要轮流回答：

• 上次站会我完成了哪些工作？
• 现在我计划完成什么工作？
• 我遇到的障碍、风险或问题是什么？

        值得注意的是，我们不能让站会变成项目状态报告会或问题解决会，若有问题需要讨论可在站会后单独安排。

3.5.4迭代评审会议（Sprint Review）

        迭代评审会议一般会在sprint冲刺完成后召开，会议一般会控制在4个小时以内，参会人员主要有开发团队、产品负责人和受邀请的主要利益相关方，会议的内容：

• 由产品负责人说明产品待办事项列表中的已经“完成”和“未完”成的任务；
• 开发团队讨论在Sprint冲刺期间哪些工作做的很好，遇到了哪些问题和困难以及是如何解决这些问题的；
• 开发团队演示“完成”的工作并解答关于所交付增量的问题，获得相关方验收通过；
• 未完成或未通过评审的用户故事，重新放回产品待办事项列表，在下一次迭代规划会议评价；
• 参会的所有人员就下一步的工作进行探讨，为接下来的Sprint规划诡异提供有价值的输入信息；
• 评审市场或潜在的产品使用方式所带来的接下来要做的最具有价值的东西的改变；同时为下个预期产品功能或产品能力版本的发布评审时间表、预算、潜力和市场。

3.5.5迭代回顾会议（Sprint Restrospective）

       迭代回顾会议是是发生在迭代评审会议之后，下个Sprint规划会议之前，回顾会议最长不超过3小时，会议的目的是检视前一个Sprint中人、关系、过程和工具的实施情况如何，找出并加以排序做得好的和潜在需要改进的主要方面；同时制定改进Scrum团队工作方式的计划。

4.敏捷实践5大会议时间盒

序号	迭代周期	6周	4周	2周	1周
1	产品待办事项列表梳理会议	12h	8h	4h	2h
2	迭代规划会议	12h	8h	4h	2h
3	每日站会	15min	15min	15min	15min
4	迭代评审会议	6h	4h	2h	1h
5	迭代回顾会议	6h	3h	2h	1h

其它敏捷相关的资料欢迎大家查阅：

<<敏捷宣言和敏捷的十二原则>> huangkaiwuhan的博客-优快云博客