2019年企业服务型初创公司中Scrum应用实践及与OKRs的结合实践.pdf

《2019年企业服务型初创公司中Scrum应用实践及与OKRs的结合实践.pdf》由会员分享，可在线阅读，更多相关《2019年企业服务型初创公司中Scrum应用实践及与OKRs的结合实践.pdf（21页珍藏版）》请在三个皮匠报告上搜索。

1、企业服务型初创公司中Scrum与OKRs的结合实践智链万源 CTO目录应用敏捷时遇到过的问题 解决思路和实例 Scrum+OKRs 总结场景一：客户口头提出需求，要求一个月内交付 场景二：收到招标文件，需要短时间内根据粗粒度的需求提交时间计划表 场景三：老板提出一个想法，问需要多少时间和人力能够实现矛盾一：交付时间表和Sprint迭代场景一：客户口头提出需求，要求一个月内交付 场景二：收到招标文件，需要短时间内根据粗粒度的需求提交时间计划表 场景三：老板提出一个想法，问需要多少时间和人力能够实现矛盾一：交付时间表和Sprint迭代表象一：Sprint计划会上发现无法按时交付 表象二：无法在一个

2、Sprint内完成时，剩余Story缺少明确交付时间 核心问题：未经详细分析和评估的需求在工作量上有极大的误差可能场景一：客户需要在三个月后上线，前期沟通、商务谈判、合同流程等等就花掉了两个月，留给研发的实际时间很少 场景二：一个迭代周期中，老板或客户要求提前交付阶段性成果，或者阶段性Review时临时调整需求矛盾二：迭代节奏和客户至上场景一：客户需要在三个月后上线，前期沟通、商务谈判、合同流程等等就花掉了两个月，留给研发的实际时间很少 场景二：一个迭代周期中，老板或客户要求提前交付阶段性成果，或者阶段性Review时临时调整需求矛盾二：迭代节奏和客户至上表象一：项目启动时间点和Sprint周

3、期不匹配 表象二：Sprint中途进行Story变更 核心问题：对客户需求的管理能力和对变更的控制能力场景一：Backlog中大量出现大点数的Story 场景二：Sprint计划会上发现Story总点数远超生产力，无法取舍 场景三：站立会谈到一个技术点或依赖项时，引发不必要的讨论矛盾三：细节和愿景场景一：Backlog中大量出现大点数的Story 场景二：Sprint计划会上发现Story总点数远超生产力，无法取舍 场景三：站立会谈到一个技术点或依赖项时，引发不必要的讨论矛盾三：细节和愿景表象一：站立会超时，讨论过于发散，无法形成对整体进展的认知 表象二：Sprint计划会上对Story优先级

4、产生分歧 核心问题：目标或意义迷失，方法未形成共识不要为了敏捷而敏捷，敏捷不是万能的，是为了更好的应对未知和变化一个常见的误区By Snowden-File:Cynefin framework Feb 2011.jpeg,CC BY 3.0,https:/commons.wikimedia.org/w/index.php?curid=53504988两个要点做到更有效的敏捷庞杂的需求和开发过程中仍需保持目标的清晰和一致 客户需求目标和企业目标进行关联 响应变化接纳变更的同时不要迷失目标目标清晰一致按迭代冲刺需要根据交付期限倒推时间表，和迭代周期要尽可能的匹配 客户时间不可控的情况下依然要保持冲

5、刺节奏用OKRs保持目标的清晰实施OKRs前 Sprint目标清晰，但团队仍反馈企业目标不清晰 实施OKRs后 用项目或小组的OKRs中的O支撑企业的KR 用小组的KR指导Sprint计划会 实现上下目标关联用OKRs保持目标的清晰实施OKRs前 Sprint目标清晰，但团队仍反馈企业目标不清晰 实施OKRs后 用项目或小组的OKRs中的O支撑企业的KR 用小组的KR指导Sprint计划会 实现上下目标关联例子 企业O1:实现项目收入KR1:30次新POCKR2:10个项目转化 团队O1:新增POCKR1:新增2个场景解决方案KR2:10次POC 团队O2:项目转化KR1:5个新需求转化为产品

6、功能KR2:3个客户痛点需求升级此外，OKRs还能够达到非常好的强制沟通效果把时间表的达成作为一项目标在给定的时间表内，向超预期完成项目迭代 超预期包括：更好的效果，更低的成本，更短的时间 量化KR：Story完成量或完成率，人员投入数量，迭代数量 迭代数量：尽早交付，频繁交付例子 项目O1:4月15日前交付第一期原型KR1:完成三次客户ReviewKR2:一期Story完成度90%适应大量的变化同样是一个关键结果难点在于如何保持迭代节奏 矛盾点：Sprint中途变更Stor