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之心，不仅关注到自己的节点，而要支持和促进上下游的工作共同顺利完成。
