开放司克兰板指南Open ScrumBan Guideline
•Download as PPTX, PDF•
0 likes•155 views
整合Scrum和Kanban，发挥两者优势，用来分析、研发、交付、维护复杂产品和IT服务，尽早尽快最大化实现业务价值。
Recommended
Recommended
More Related Content
Recently uploaded
Recently uploaded (20)
Featured
Featured (20)
开放司克兰板指南Open ScrumBan Guideline
- 1. 开放司克兰板指南 V2020/12 2020年12月更新说明：Scrum指南在2020年11月更新了一版，本指南引用了Scrum指南，因 此配套更新，另外重大变化是本指南从ScrumBan SimpleOpen Edition Guideline改名为 Open ScrumBan Guideline，新名称更加简短，突出Open，另外版本号采用发布年月。 2019年12月版的写在前面： 曾经在微信群里面多次聊起ScrumBan，总有群友说不知道ScrumBan，考虑到目前确实没有 一个清晰简明的ScrumBan说明，起草本文件，欢迎反馈。 考虑到ScrumBan得到多方阐述，并没有绝对权威，给本版加了SimpleOpen版，意思是指简 单&开放，欣奔是Simple Open的音译。为了突出Kanban，把常见的Scrumban改为了 ScrumBan，文中指的ScrumBan指的是ScrumBan SimpleOpen。 出品人：张克强， 陈勇， 徐陈飞， 熊小龙 微信联络 Open ScrumBan Guideline
- 2. 目录 前言 Open ScrumBan宣言 Open ScrumBan总览图 Open ScrumBan之1234 Open ScrumBan原则 后记
- 3. 前言 历史： • 书-Scrumban，作者Corey Ladas， 2009年出版 • 书-The Scrumban [R]Evolution，作者Ajay Reddy，2015年出版 • 电子书-IBQMI Certified Scrumban Practitioner®: The official training material，2019年2月 出版 • 2019年敏捷年度调查报告里面，Scrumban占比为8%，Scrum占比54%，Kanban占比5% • 2020年敏捷年度调查报告里面，Scrumban占比为10%，Scrum占比58%，Kanban占比7% 目的： • 整合Scrum和Kanban，发挥两者优势，用来分析、研发、交付、维护复杂产品和IT服务，尽早尽 快最大化实现业务价值。 存在的问题： • ScrumBan是Scrum吗？ 还是Kanban？ • Open ScrumBan与其它Scrumban是什么关系？
- 4. Open ScrumBan 宣言 交付成品 胜过 评审产物 按需发布 胜过 定时发布 价值流动 胜过 遵循教条 渐进改善 胜过 模型突变
- 5. 缩写说明 • PB – Product Backlog 产品待办列表 • DoS – Definition of Start 启动的定义，满足DoS才能启动分析 • DoR – Definition of Ready 准备好的定义，满足DoR才能进入 开发排队 • DoD – Definition of Done 完成的定义，每个状态达到完成的 条件 • WIP – Work In Progress 在制品 • PM – Product Manager 产品经理 • SL - ScrumBan Leader 司克兰板组长
- 6. Open ScrumBan总览看板 探索 分析[5] 排队 [1-5] 编码[5] 测试[5] 交付 提出 选择 进行中 完成 进行中 完成 进行中 完成 待交付 完成 加速横道 DoR DoD DoD 待交付 DoD 普通横道 其它横道 史诗 故事 史诗 故事 故事 故事 故事 故事 故事 史诗 史诗 故事 史诗 史诗 展现PB探 索 史诗 批量按节奏 交付 卡片不 同属性 显示故 事不同 性质 不同横道 表示不同 优先级 限制WIP促进协作 和加速 排队列WIP设下限， 让编码不等待 满足DoR 才能排队 列流转都有 DoD 卡片标明 负责人员 WIP限制 带来聚拢 史诗 梳理过程得到 可视化 人员同时担 当的故事数 受WIP限制 ScrumBan Leader，引 导团队使用 ScrumBan 回顾会检视 调整 计划会议按需 召开 故事 评审实时尽早发生，不依 赖迭代末专门会议 利用看板站会 跟踪 V2020/12 出品人：张克强，陈勇，徐陈飞，熊小龙 Product Manager， 主持需求探 索和故事分 析 DoS
- 7. Open ScrumBan之1234 故事看板Story Kanban • 展现敏捷故事（包含史诗）各个环节，故事被团队的客户使用，都可选可调；迭代初始选择首批故事，再 根据进展滚动补充 角色Roles • 产品经理 Product Manager, 对等于Scrum中Product Owner • 司克兰板组长ScrumBan Leader，对等于Scrum Master, 或者Team Leader 推荐动作Recommended Activities • 澄清 Clarification，产品经理汇同开发、测试人员澄清用户故事，确认DoR • 回顾 Retrospective，组长汇同团队成员反思和展望更好的做法 • 发布计划 Release Planning，结合故事板情况按需持续进行，每次都是短时间 • 站会 Standup Meeting，每天在故事板前跟踪交流，观注风险/阻碍 工件Artifacts • 产品待办列表Product ToDo List，收集来自各方的创意或者要求，先以史诗出现，不作是否采纳的预判 • 故事待办列表Story ToDo List，经过探索满足DoR的故事 • 交付批量Release Batch，满足DoD可发布上线的增量
- 8. • 推进故事满足DoR，给出故事优先 级，在编码测试过程中解释并验证 故事 • 不使用Owner这个说法的原因是在 复杂产品和业务当中，绝大多数的 一线团队需求负责人并不掌握最终 决策权，使用常见的产品经理的说 法更加贴切，既可以是决策者，也 可以是决策实施者。不强制要求其 对需求的ROI负责 2大角色 产品经理 Product Manager • 对等于Team Leader，组长， Scrum的Scrum Master，引领团 队开展按需ScrumBan的各项活动， 建设故事看板。既可以对接原 Scrum Master，也可以对接原项 目经理和原团队领导者 • ScrumBan Leader引领团队对 ScrumBan进行裁剪和补充，建立 和维护团队章程 • 组长是一线团队的服务型领导者， 给团队赋能，透明团队工作，向外 展现团队各方面情况 司克兰板组长 ScrumBan Leader • ScrumBan不排斥其它角色，甚至鼓励根据流程特征设立不同角色 • 首先尊重团队现有角色，利用故事板体现全部角色的工作 • 然后再根据表现来寻求角色调整机会 其它角色 Other Roles
- 9. 3大工件 产品待办列表 • 对接来自用户的 声音，收集来自 各方的创意，甚 至抱怨 • PM根据DoS筛选 选择启动分析 故事待办列表 • 经过分析后，满足 DoR的史诗或者故 事进入故事待办列 表 • 推荐采用鸡蛋估算 法，故事经过梳理， 按相同量级的小颗 粒度识别和切分 交付批量 • 满足DoD的故事批 量，一起作为增量 对外交付 • 在迭代交付前最晚 时候确定满足DoD 的故事进入迭代交 付批量
- 10. 4大推荐动作 澄清 • 梳理澄清史诗 和故事，确认 满足DoR • 保证满足WIP 故事在排队列 中 • PM主责推进 回顾 • 既回顾方法 工具等， • 也回顾产品 本身 • 修订团队章 程 • PM和SL共同 推进 发布计划 • 根据故事板 情况补充故 事进入开发 • 滚动进行计 划 • SL主责推进 站会 • 在故事板前 全队交流进 展 • 识别协作， 障碍和风险 • PM和SL共同 推进
- 11. 史诗和故事的识别和转换 • 对外承接的需求往往出于业务目标来考虑，因此其颗粒度天然未 必符合单个迭代能够完成，因此Open ScrumBan以史诗Epic先 来承接各类外部需求，再识别故事安排到各个迭代。 • 在识别分析中，如果发现该史诗颗粒度足够小，那么可以转化成 故事进行后续，也可以直接跟踪，也可以为了保持结构，再识别 一个对应故事，这由具体场景来决定。但如果史诗颗粒度大于单 个故事，那么须识别多个故事来分解处理，又能保持对史诗的跟 踪。 • 从保持对外沟通一致性出发，推荐尽量保持史诗，也就是说就算 史诗颗粒度小，也不转换到故事，避免外部误解。
- 12. 颗粒度和排序 • 对于估计在迭代内单人工作量能够完成的故事，不细究具体故事点数，按看 板上顺序处理故事，更加关注针对外部需求能否快速交付。 • ScrumBan分为加速横道和普通横道，在现实工作中，往往不断涌现新的、 紧急的需求需要插队上线，综合各种因素来判定如何加速，对于识别的紧急 需求可以插队安排到加速横道高优先处理，可能因此而挤出当前发布版本的 其它需求，或者延期发布。 • 对比Scrum，Scrum中不存在“加速”这一说法，所有冲刺内需求往往基于 Scrum承诺的价值观（5大价值观之一）一起交付，团队需要承诺完成计划 的需求范围，对于突发涌现的高优先需求的应对稍显缓慢。
- 13. Open ScrumBan迭代与交付 迭代与交付 每个迭代末安排例行迭代交付，也支持迭代中按需交付。 在交付前最晚时间确定交付批量。 持 续 分 析 持 续 澄 清 迭代节奏 在迭代进入前，提前澄清的需求足够支持迭代开工。 迭代末，按迭代节奏进行交付和回顾。 持 续 开 发 批 量 交 付 满足DoR的 故事足够 启动迭代 迭代中根 据进展补 充故事 最晚仍然可以补 充故事赶上本迭 代交付 分析轨 实现轨 待交付DoD 检查 迭代交付 迭代交付 按需交付 冻结 冻结 待交付DoD 检查 回顾
- 16. Open ScrumBan 原则 精益敏捷 • 将精益思想落实到 敏捷实践当中，追 求增值，消除浪费， 具体如工作流、稳 定系统等 • 追求系统思考，识 别各类系统以及系 统的系统，结合上 下文环境来决策 迭代节奏 • 追求单件流，可以 单件进入计划，但 不强求单件发布， 缺省地按照固定间 隔批量交付 • 聚焦价值交付，每 个迭代都必须有实 际发布增量，不再 如Scrum那样只要 求潜在可发布增量 尊重现状 • 首先着眼利用看板 来展现交付价值流， 从价值流角度分析 改进机会，比如度 量前置时间 • 启动时不要求马上 按Scrum团队模型 改变团队，根据团 队现状来选择角色 和实践 演进优化 • 采用演进而不是革 命的方式来优化， 帮助团队发展对适 宜他们的各类实践 • 并不是容忍 Scrum 所暴露的不足和功 能障碍，而是结合 不同团队组织特定 环境寻求有效方式 去解决它们
- 17. 后记 • 争议的Scrumban vs Scrum vs Kanban • https://www.scrum.org/index.php/forum/scrum-forum/33122/scrumban-same- scrum-kanban • Scrum的维基百科解释 • https://en.wikipedia.org/wiki/Scrumban • Scrumban历史及目的 • https://news.ibqmi.org/history-and-purpose-of-the-scrumban-framework