Scrum理论在业务线中的实践

简介: Scrum 的应知应会 Scrum 是什么 所有符合敏捷思想和原则的方法都是敏捷方法。Scrum是一种实现敏捷方法的框架。   Scrum的组成 Scrum Master 产品负责人 开发团队 业务负责人通过产品负责人和Scrum团队产生连接   Scrum Master ScrumMaster负责促进和支持Scrum。 ScrumMas

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
  • 提供愿景和边界
    • 为团队清晰解释产品未来会变成什么样
    • 清晰描述阶段性实现是什么样
  • 需求列表唯一负责人
    • 对需求列表排序,使其更好的达成目标
    • 确保开发团队对需求列表有足够深刻理解
    • 定义需求验收标准并验证

image.png

 

产品需求列表特点

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

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

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场会,保障整个迭代的目标有对焦、过程有抓手、结果有复盘。

image.png

 

1个组

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

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

机制:轮班制,leader提前确认好轮值名单

组长:轮值业务负责人

 

2张表

迭代的时间表

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

示例:

需求排期表

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

 

3场会

需求KO会

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

解决做什么方向性问题。

 

关键需求评审会

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

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

 

发版小组迭代复盘会

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

解决Scrum能力成长的问题。

 

迭代的正常流程

 

共识

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

 

 

 

 

相关文章
|
敏捷开发 测试技术 持续交付
Scrum敏捷开发:适应变化的核心能力
敏捷开发是一种以人为核心,迭代、增量式的软件开发方法。它强调团队成员的密切合作、快速响应需求变化、持续交付高质量软件。
|
设计模式 消息中间件 缓存
【工作学习方法论 一】成体系的学习方法论
【工作学习方法论 一】成体系的学习方法论
346 0
|
2月前
|
监控 数据可视化 项目管理
关键路径法在项目管理中的实践:从理论到落地的全过程
使用关键路径法(CPM),为你的项目梳理清晰的“优先级”与“全局策略”。
168 2
关键路径法在项目管理中的实践:从理论到落地的全过程
|
3月前
|
敏捷开发 Devops 持续交付
软件开发中的敏捷方法:从理论到实践
软件开发中的敏捷方法:从理论到实践
|
5月前
|
敏捷开发 数据可视化 Devops
敏捷测试价值观、方法和实践读书笔记(4)
本章节探讨了敏捷测试执行的关键概念与实践。首先介绍了用户故事及其重要性,强调其在敏捷开发中的角色,并阐述了用户故事的 INVEST 原则。接着分析了用户故事生命周期中的测试关注点,包括定义、处理、完成及验收阶段的测试活动。此外,还对比了不同测试术语的差异,并提供了敏捷测试计划的策略与过程。通过看板等工具实现任务管理与跟踪,确保测试活动高效进行。最后,介绍了敏捷测试中的度量指标,帮助团队评估测试效果。
63 5
敏捷测试价值观、方法和实践读书笔记(4)
|
5月前
|
敏捷开发 监控 测试技术
敏捷软件质量保证的方法与实践
本文介绍了软件质量保证(SQA)的重要性及其在敏捷开发中的实践方法。文章首先指出了传统测试方法的问题,如成本高昂和项目风险加大。为解决这些问题,文中提出了需求审核、代码审核与演练、基于会议的测试及基于风险的测试等多种实践方法。此外,文章还探讨了衡量软件质量的常见指标,如源代码行数、代码段/模块/时间段内的Bug数和代码覆盖率等。文中还详细描述了敏捷开发过程中QA的角色与活动,强调了QA需与开发人员、业务人员及客户密切协作,以确保产品质量。最后,文章指出了在敏捷开发中QA的特殊性及其对团队构成、测试阶段、工作方式等方面的影响。
145 3
敏捷软件质量保证的方法与实践
|
6月前
|
敏捷开发 数据可视化 持续交付
敏捷开发方法:理论与实践
【8月更文第22天】随着信息技术的发展,软件项目的复杂度不断提高,传统的瀑布式开发模式越来越难以适应快速变化的市场需求。为了解决这些问题,敏捷开发方法应运而生。本文将探讨敏捷开发的核心理念、敏捷宣言与原则、Scrum框架、Kanban方法以及相关的敏捷实践与工具。
684 2
SRE方法论之减少琐事
SRE中的E是Engineering。中文可以翻译为“工程工作”,SRE就是通过工程工作来减少琐事。
SRE方法论之减少琐事
|
9月前
|
敏捷开发 持续交付 开发者
拥抱变化:软件开发中的敏捷思维与持续学习
【4月更文挑战第30天】 在快速迭代的软件开发领域,"敏捷"不仅是一套方法论,更是一种哲学。本文将深入探讨敏捷软件开发背后的核心原则及其对开发者心态的影响,特别强调持续学习的重要性。我们将剖析如何在不断变化的技术环境中保持适应性和竞争力,并提出策略以促进个人和团队的成长。文章旨在为读者揭示那些成功适应行业变革、不断提升技术栈并保持职业生涯活力的专业开发者所遵循的实践方法。
|
9月前
|
开发者 UED
拥抱不确定性:软件开发中的敏捷思维与持续学习
【5月更文挑战第29天】 在快速变化的技术世界中,不确定性已成为常态。本文探讨了如何在软件开发实践中运用敏捷思维来适应和利用这种不确定性,以及如何通过持续学习保持个人和团队的竞争力。通过分析敏捷方法论的核心原则,我们揭示了它们如何帮助开发者更好地应对需求变更、技术演进和市场动态。同时,文章还将讨论持续学习的重要性,以及如何通过实践驱动的学习来不断提升技能和知识,从而在不断变化的环境中保持领先地位。

热门文章

最新文章