scrum回顾_Scrum敏捷管理的整理

1. 文档目标

梳理适应型生命周期 敏捷的相关概念和管理流程，以及各环节中的注意事项。

2. Scrum流程框架概览

图片来自网络

Scrum流程框架一般包括：

• Scrum团队：3个角色
• Sprint会议：5个会议
• Sprint原则：12个原则

3．敏捷宣言

个体及互动 而不是 过程和工具

让自组织团队选择最适合他们的工具。

工具和流程非常有用，但需要用对地方，要让使用者来掌控他们。

流程和工具是为人服务的，而不是反过来。

可用的软件 而不是 完整的文档

用户文档很有价值，但更应该关注产品本身而是流程文档。

开发初期太过详尽的文档反而难以从错误中学习并调整流程和需求，船小好调头。

敏捷不是不写文档，相反它的时间往往多于传统模式，因为计划需不断细化和更新。

客户合作 而不是 合同谈判

Scrum团队与客户不是对立关系。

采用时间材料模式，在规定的时间和预算范围内，努力构建最有价值的系统。

应对变化 而不是 遵守计划

变化难以避免，拥抱变化，为变化做计划，以改变你原有的计划。

认为变化是好事的流程就是最好的流程。

敏捷是规划驱动的，而规划是流动的而非固定的。

宣言的右侧的项目固然有价值，但我们更重视左侧的项目。

4．Scrum团队

Scrum团队由一名产品负责人、开发团队和一名敏捷教练组成。Scrum团队时跨职能的自组织团队。自组织团队自己选择如何以最好的方式完成工作，而不是由团队之外的人来指导。

4.1 产品负责人(PO)

职责：

将开发团队开发的产品价值最大化。

特点：

是产品待办列表(Product Backlog)的唯一负责人；

通过PBL展示业务方最期望的诉求，所有优先级的调整必须经过PO；

PBL(Product Backlog)的管理：

1) 清晰地表达产品待办列表事项；

2) 定义待办列表事项的优先级，使其最好的实现目标和使命；

3) 优化开发团队所执行工作的价值；

4) 确保待办事项列表对所有人可见、透明和清晰的，同时显示下一步要做的工作；

5) 确保开发团队对产品待办列表项有足够深的了解。

4.2开发团队

特点：

开发团队是自组织的，没有人有权告诉团队如何将PBL变成潜在客发布的功能增量；

开发团队是跨职能的团队，它拥有开发产品增量的全部技能；

4.3 敏捷教练(SM)

职责：

根据Scrum指南中的定义来促进和支持Scrum，帮团队理解Scrum理论、实践、规则和价值。

特点：

SM服务于产品负责人；

SM服务于开发团队；

SM服务于组织；

5．Sprint 5个会议

5.1 待办事项整理会(Backlog Grooming Meeting)

与会人员：PO、SM、关键开发者或架构师。

会议目标：根据客户价值，输出最新的、可预估故事点的PBL

会议内容：

将新需求与已有的PBL汇总，所有人员一起分析用户故事。

对新需求进行分析、拆分、估算及优先级排列，对原有PBL进行调整与删改，形成最新的PBL。

分析： 分析用户故事，指出需求不明确的地方。

拆分：SM与开发识别所需技术，拆分子任务，方便后续预估故事点。

注意事项：

PO现场记录问题，会后补全，确保迭代计划会议之前全部解决。

5.2 迭代计划会(Sprint Planning Meeting)

与会人员：全体成员。

会议目标：决定本次迭代需要做什么，确定相应的验收标准(DOD)

会议内容：

回顾上一次迭代收获的改善项；

PO从PBL中选取高优先级的需求进行讲解，明确DOD(完成的定义/验收的标准)；

团队成员进行任务识别与拆解，预估相应的工作量，直到本次迭代的工作量饱和；

将所选的需求拖进Sprint Backlog(SBL)中，并确定本次冲刺的目标；

开发团队主动认领用户故事/需求/任务，并确定相应优先级顺序。

注意事项：

迭代计划会在每个迭代的第一天召开；

PO参与并讨论需求相关的问题，但不干预估算结果；

会议一般控制在2小时左右(3-4周左右迭代周期)。

5.3 每日站会(Standup Meeting)

与会人员：全体成员。

会议目标：更新任务的状态/燃尽图，了解今日的计划，发现问题和阻碍。

会议内容：

团队成员依次阐述：昨天做了什么？今天将要做什么？是否有需要帮助的地方或遇到的阻碍？

注意事项：

记录会议中遇到的问题或障碍，会后专项讨论；

会议每天召开，一般控制在15分钟以内。

5.4 评审会议(Review Meeting)

与会人员：全体成员、相关干系人(选择性参加)。

会议目标：根据已完成情况及冲刺期间的PBL的变化，讨论如何优化交付价值。

会议内容：

PO说明SBL中的已完成项和未完成项；

开发团队讨论Sprint期间做的好的工作，分享解决棘手的问题的方法；

开发团队演示已完成/已交付的工作，并根据DOD解答相关问题；

PO分享冲刺期间PBL的变化，所有人就下一步工作进行探讨和建议；

注意事项：

会议在冲刺结束前召开；

一般控制在1-2小时左右；

5.5 回顾会议(Retrospective Meeting)

与会人员：全体成员。

会议目标：总结良好实践形成经验，对有需要提升的地方形成TODOList。

会议内容：

基于本次迭代中的客观数据(燃尽图、需求变更数、Bug数等)，引发团队进行回忆、思考与总结；

检视本次Sprint中关于人、过程、工具等情况如何；

找出并加以排序做得好的和潜在需要改进的主要方面；

制定改进Scrum团队工作方式的计划；

注意事项：

SM鼓励Scrum团队改进开发过程与实践。

6．Sprint 12个原则

l 我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。

l 欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。

l 要不断交付可用的软件，周期从几周到几个月不等，且越短越好。

l 项目过程中，业务人员与开发人员必须在一起工作。

l 要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。

l 无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。

l 可用的软件是衡量进度的主要指标。

l 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。

l 对技术的精益求精以及对设计的不断完善将提升敏捷性。

l 要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。

l 最佳的架构、需求和设计出自于自组织的团队。

l 团队要定期反省如何能够做到更有效，并相应地调整团队的行为。

7．常见误区

1) 敏捷就是快，所以不需要文档。

答：敏捷团队在规划和文档上的时间，远远多于传统团队，因为计划要不断的细化和更新。

2)敏捷就是拥抱变化，所以可以随便改需求插需求。

答：每次冲刺的人员和时间是固定的，优先级更高的需求插进来，就要有相同工作量的需求被替换出去。

3)项目太大无法采用敏捷的方式。

答：基于频繁交付有价值的产品为核心，将大项目拆解成小里程碑，划分成一个个冲刺。亦可以采用Scrum of Scrum的方式进行快速反应。

4)开发团队需要等需求完全详尽才能进入开发。

答：敏捷强调自组织团队，即团队成员自己管理实现代表事项的方式、如何完成工作的方式及团队成员间如何协调。产品owner描述清楚目标，拆解成详细的故事点，即可进入到开发。

8．我们的套路

Scrum+OKR

1) 产品owner收集用户需求，对其进行价值评估和优先级排列；

2)邀请关键团队成员参加《待办事项整理会》，描述详细需求背景/目标。成员讨论未明确的地方，整理排列出最新的PBL；

3)产品owner完善《代办事项整理会》纪录的问题，择日启动冲刺，并在第一天召开《迭代计划会》。会议中 产品Owner从优先级高到低，描述需求的背景和目标，团队尽可能的将需求拆解成故事点，定义验收标准，团队成员认领并估算时间，直到时间跨度达到冲刺周期。

4)SM组织每日站会，共享成员任务情况，解决遇到的问题。特定问题拉专会进行讨论。团队成员自发的进行任务的沟通与协调。

5)冲刺结束前，SM邀请大家或主要干系人进行《冲刺评审会议》，演示本次冲刺完成的需求，说明未完成的需求，团队成员分享过程，并且就产品交付价值最大化探讨下一步。

6)冲刺结束后，SM邀请所有团队成员进行《冲刺回顾会议》，找出本次冲刺的优缺点，扬长避短，将改进项汇成准则或团队公约，并在下次迭代前用于改进团队工作方式。