Scrum 的应知应会

Scrum 是什么

所有符合敏捷思想和原则的方法都是敏捷方法。Scrum是一种实现敏捷方法的框架。

Scrum的组成

• Scrum Master
• 产品负责人
• 开发团队

业务负责人通过产品负责人和Scrum团队产生连接

Scrum Master

ScrumMaster负责促进和支持Scrum。

ScrumMaster通过帮助每个人理解Scrum理论、实践、规则和价值来做到这一点。

SM职业发展路线

• 服务多个团队或更具挑战性的团队
• 提升自身技能，成为Agile Coach 或 将经验分享给新手SM
• 成为产品负责人
• 成为管理者 

职责

• scrum专家

• • scrum团队的流程专家，引导scrum的流程
  • 确保团队使用正确的流程
  • 确保团队正确的召开各种会议

• 教练

• • 训练团队的敏捷思维
  • 帮助团队提升自组织能力，引导团队不断改进
  • 帮助scrum团队内外的人了解如何团队内外交互是最有益的，通过改变互动方式来最大化团队所创造的价值

• 服务型领导

• • 为了帮助你和团队更加有效，今天我能做什么？
  • 包括但不限于扫清障碍、沟通、推动变革、协助产品负责人、指导团队
  • 推土机---推动解决一切阻碍团队工作的事情
  • 保护伞---保护研发团队免收外部干扰

每日工作列表

• 协调每日站会

• • 展示排期时间表
  • 听取团队3个问题的回答
  • 明确下一步计划和责任人
  • 和团队分享有用的信息

• 更新和检查排期时间表

• • 如果团队落后于时间表，需要帮助团队想办法追上进度
  • 检查信息不一致情况，追踪问题并提醒团队成员作出更正

• • • 已决定不做的仍旧在排期表中
    • 已完成的没有标记完成
    • 没完成的被标记成完成

• 检查待办需求列表的情况，是否有遗漏

• • 遗漏工作量评估
  • 遗漏需求安排人员及排期

• 找出所有影响进度的工作

• • 保护团队不被团队外的其他人打扰
  • 教育团队成员：应该先尝试自己解决问题，如果解决不了需要找SM解决

• 需求KO会准备

• • 协调产品进行需求列表优先级梳理
  • 统计下一个迭代的生产能力

• • • 团队成员休假计划、公共假期
    • 在电子、物理工具上更新信息

• 需求KO会

• • 协调评估过程
  • 记录讨论内容
  • 建议工作量多评估一部分以备应急

• 回顾复盘会

• • SM组织团队成员回顾上个复盘会后团队的工作状态
  • SM组织，收集、记录团队成员讨论信息
  • SM协调确认下个迭代团队需要做的改进措施及负责人

产品负责人

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

确保团队做出正确产品以便帮公司得到最高的投资回报。

在scrum团队中负责”做什么“的问题。负责愿景和边界。

是负责管理需求列表的唯一负责人。对做什么以及做成什么样有最终话语权。

• 清晰描述需求，清晰展示下一步工作
• 对需求列表排序，使其更好的达成目标
• 优化开发团队所执行工作的价值
• 确保开发团队对需求列表有足够深刻理解

一个好的产品负责人不仅需要是一个好的产品经理，还需要项目管理、沟通、甚至是技术方面的多种能力才能完成好自己的工作。

职责

• 代表客户和业务

• • 正确理解用户和业务诉求，进行产品化设计
  • 优化开发团队所执行工作的价值，将产品价值最大化
  • 确保团队做出正确产品以便得到最高的ROI

• 提供愿景和边界

• • 为团队清晰解释产品未来会变成什么样
  • 清晰描述阶段性实现是什么样

• 需求列表唯一负责人

• • 对需求列表排序，使其更好的达成目标
  • 确保开发团队对需求列表有足够深刻理解
  • 定义需求验收标准并验证

产品需求列表特点

• 内容详略得当且专业的：马上要做的要详细描述，短期不做的可粗略，包含一句话说清楚价值、基于真实的用户故事、为明确的角色设计考虑新用户视角、充分了解关注竞品
• 持续更新的
• 可以进行工作量评估的
• 排列优先级顺序的

如何解决有限资源和需求之间的矛盾

MoSCoW技术

• Must Have 必须有的功能
• Should Have 应该有的功能
• Could Have 可以有的功能
• Would Have 也许有的功能

计划变更

• 发现线上问题后不应该立即要求研发修改，而应该根据优先级排序进行计划，保证每个迭代都只做计划好的事情。但如果是致命的错误，应当另当别论

每日工作列表

• 检查待办需求列表和任务情况，如有进度疑问需要追踪
• 协助团队成员解决问题，澄清需求
• 尽早验收已开发完成的功能

• • 是否满足预期
  • 如有变更，是否在本迭代做出变更，或者放到下个迭代，或者需要创建新需求
  • 报告任何你发现的软件问题

• 编写新需求，并清晰传达给团队
• 参加每日站会
• 听取并回答每日站会的3个标准问题
• 发现需要你进一步跟进的任务
• 和团队分享有用的信息
• 需求KO会准备

• • 收集足够多的需求以便评审，并且按优先级排好顺序
  • 以商业价值作为排序依据，同时考虑风险、失败等其他相关因素
  • 需求信息要包括依赖关系

• 需求KO会

• • 和研发团队、SM一起使得会议更有效
  • 澄清需求，澄清有可能影响评估的问题
  • 如需要，需要更新需求描述以避免歧义和误解
  • 如需要，更新优先级排序

• 需求验收

• • 验收需求是否符合预期，确认是否可发布

• 回顾复盘会

研发团队

组成

开发、测试、UX

特征

• 自组织
  不需要项目经理或者研发TL告诉团队该怎样开展工作
  团队在没有外部力量干预的情况下，为了共同的目标而工作，逐渐达成默契，不断改进
• 跨职能
  为了提交潜在可交付的增量，团队需要具备所有相应知识和技能的成员
• 规模适中
  5~9人的规模

每日工作列表

• 检查待办需求列表和任务情况
• 如果团队落后于时间表，需要确认自己是否可以帮助团队追上进度。
• 确认所有已完成的任务已标注为完成
• 检查今天要做的工作
• 如果今天没有可以做的工作，需要和团队一起找到你可以做的工作
• 当完成一个任务时，及时更新任务状态为已完成
• 更新所有相关项的信息
• 当开始一个任务时，及时更新为进行中
• 如果有风险，请立即让大家知道
• 和协同方一起讨论你的工作，以便完成任务
• 参加每日站会，汇报你的工作信息：昨天做了什么，今天计划做什么，遇到什么阻碍工作进度的问题
• 确认是否可以帮助其他人
• 帮助产品负责人完成需求更新，回答产品负责人问题并提供你的理解
• 编写技术方案文档
• 报告测试中的产品缺陷
• 和产品负责人澄清需求细节。如验收未按期望完成，产品负责人决定是否当前迭代立即修改或者后面再修改
• 需求KO会

• • 讨论并评估每个需求
  • 会议结束后立即分解任务，提供任务工作量

• 回顾复盘会

• • 团队成员一起回顾上次复盘后团队的工作状态
  • 在SM协调确认下，团队成员一起确认下个迭代团队需要做的改进措施及负责人

注意：

开发团队对工作量的评估有绝对话语权。开发团队不受其他角色影响，对工作量进行估算，并且按照自己的承诺去履行目标。

钉钉开放平台PO线的Scrum机制

目的

根据开放平台的情况，落实钉钉整体的迭代及钉牛榜的机制，并持续精进。

迭代保障123机制

通过1个组、2张表、3场会，保障整个迭代的目标有对焦、过程有抓手、结果有复盘。

1个组

成员：业务负责人、PD、SM、UX、运营、数据

职责：为本迭代的协调运作和钉牛榜负责

机制：轮班制，leader提前确认好轮值名单

组长：轮值业务负责人

2张表

迭代的时间表

1个迭代跨4周，迭代时间表标明每个角色在哪个时间做什么，是scrum内所有人的协同表，各个角色按时间表协作。

示例：

需求排期表

研发侧交付时间表，每个迭代需求评审完后48小时内给出排期。排期表需要产品、运营、研发同学达成一致，用于研发侧交付完成度的衡量。

3场会

需求KO会

进行需求的scorecard对焦和优先级排序，及钉钉层面的应做必做需求对焦会。

解决做什么方向性问题。

关键需求评审会

需求视觉稿完成后，产品负责人发起，研发同学参与共同把关需求细节。

解决愿景与边界的关系问题。

发版小组迭代复盘会

对scorecard达成度、研发交付率等数据通晒，总结反思精进，产出action并持续落地

解决Scrum能力成长的问题。

迭代的正常流程

共识

机制、规则、流程的目的是为了保障一个良好的节奏感，不会因为没有抓手而混乱。过程中Scrum成员仍要始终保持owner之心，不仅关注到自己的节点，而要支持和促进上下游的工作共同顺利完成。