Scrum敏捷发布和预算管理

Posted 2023-04-25

参考技术A 经常有学员询问敏捷预算是如何做的，与传统预算有什么本质的区别？特写此文与大家一起探讨。

谈到敏捷预算，首先要讨论敏捷发布计划是如何规划的。你会注意到，Scrum 中没有对发布计划专门的描述， 实际上敏捷发布计划前面要加一个关键词 “持续” ；发布计划是一个持续 (continuous) 的活动，而不是一次性的事件（one–time event）。“持续的敏捷发布计划” 来实时评估成本和时间的风险。

什么时候做敏捷发布计划？

1. 在产品的探索构想（envisioning）， 包括产品愿景，high-level product backlog ，产品路线图的建立之后, 最初的发布计划工作坊（workshop）, 可持续1-2天，围绕产品的目标去规划发布计划，我们经常用到的技术是用户故事地图(如下)。

 2. 在产品待办列表的梳理活动上，把大的需求拆成小的，并进行估算。每一个发布要定义一组 MRFs (最小的可发布的特性组合)，来实现发布的目标。发布计划的内容包括：什么时间发布，有哪些特性包括（must-have）, 成本预算的预期管理。下图有不同发布版本的划分。   

 3. 在每个 Sprint 的评审会结束后更新和调整发布计划，更新发布燃尽图，在范围，时间，和成本三个方面重新平衡和权衡 (trade-off) 决定新的发布计划。所以每次迭代评审会结束后，PO 拿到的是上个迭代团队交付的 “实际” 数据，以此来实时更新发布燃尽图，调整和更新发布计划。PO 和干系人沟通和对话管理预期，与干系人谈判协商，在范围，时间，和成本之间做出取舍和妥协， 实时调整。要么追加预算（加人和外包），砍范围，或延长发布时间， 这些活动是持续和动态的风险监控，也是为了响应市场变化，降低商业风险，根据当前的项目进度和进展，调整产品发布策略，以做出最经济明智和适时的商业决定。下图展示了发布计划活动的参加人，输入和输出参数。 

 固定范围 + 固定范围发布计划的诟病

如下图所示，通常我们是先试图固定范围（scoping）, 事实上范围是最难管理的，我们经常说范围在  “蔓延” ，实际情况是总有一些需求不可能在项目启动时都想明白，都预测到，我们对项目的理解也是一点一点学习到的。同时锁定时间和范围的发布是很困难的，这种情况下我们的预算是灵活不可控的，但大多组织期望预算可控制，“预算开口” 是不现实的做法。即使在项目晚期追加预算，通过加人来追赶时间，不一定会有大的帮助，而且，现状是大部分企业靠加班来赶工赶期，这种做法背离敏捷可持续的原则—— “敏捷过程提倡可持续的开发，项目方、开发人员和用户应该能够保持恒久稳定的进展速度” ，其结果会更糟糕， 员工士气也大减。

同时锁定时间和范围的发布策略带来的另一个后果是 “偷工减料” ，牺牲质量。技术债务不停累加，产品运维成本增加。如果再遇上运维和研发两张皮的团队，那就是扯皮 “打架” 和内耗。

所以，敏捷的发布管理，要么是固定范围的发布，要么是固定时间的发布，同时锁定时间和范围的发布策略是不切实际的。

固定范围的发布计划：

仔细想想，固定范围的项目只是一个 “理想” 的假设，审视一下我们大家日常面对和管理的项目，大多数情况下 “固定” 范围是不成立的。这里我们理解的固定范围是指这样一种情况：要求发布的产品必须包括一组必须有 (must-have) 特性才能实现发布目标，敏捷发布策略是通过牺牲（slip）发布的时间来满足产品目标。切记，这个时候要我们确确实实去识别绝对最小的功能（the absolute bare minimum）。需要我们放弃传统的 “标准”（standard）配置的旧思维。好多情况下，我们经常听到有关 “标准化” 的对话。

这里指的固定范围的意思是我们事先已经知道这些 MRFs （最小的可发布的特性组合）, 但是对于一些创新产品，总会在开发的过程中 “涌现” 出新的特性或功能。这些特性有可能属于 must-have , 那我们还会拥抱这些新的需求，通过发布时间调整或甚至推后来容纳这些变化。

固定日期的发布计划：

事实上，固定时间的发布比固定范围的发布更容易管理，省去我们再与多个部门的多次协调，这也是为什么业界更倾向于采用 “固定时间” 的发布策略，以形成发布的节奏 (cadence) , 比如，每个季度都有一个固定的发布日期和韵律，每个人都知道每次发布的时间点。这样，我们在发布的范围上可以做一些妥协，发布的范围是相对开放的。

固定时间发布一定也是围绕发布的目标来规划一些（must-have）的特性。我们不建议 100% 排满工作，原因如下，在开发的过程中总是会有一些功能会 “涌现” 出来，可能会属于 must-have 的特性, 必须包涵在这个发布版本里。我们如果排得满档， 就没有多余时间来应对这些新的功能，所以推荐用 60-70% 时间（capacity）规划 must-have 的内容，留有一些 buffer （比如30-40%） 规划 nice-have 的特性。一旦有新的涌现的 must-have 的特性， 我们会 drop 一些 nice-have 的功能，以灵活应对和接纳涌现出来的新的 must-have 的需求。     

以上两种发布策略都讨论了如何应对在项目交付过程中涌现出来的需求变化，也符合敏捷的原则 –  “欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势” 。

敏捷发布的一个重要的度量基准——团队Sprint速率

团队的速率是指在一个 Sprint 结束后的产出（output）, 常见以用户故事点来度量，比如 V=20。 新的 Scrum 团队的速率是不稳定，跑几个迭代以后, 多数团队的速率会稳定下来，这样团队就积累了自己的历史速率和形成了交付的节奏。速率对 PO 做发布管理是非常有帮助的一个度量基准。举个例子，如果我们估算一个版本的发布范围是 200故事点， 我们就可以大致估计需要 10个 sprint 来完成。度量准确的团队速率至为关键。我们反对在团队速率上做手脚或操纵速率。

发布成本和预算管理的三种情况：

Scrum 倡导的敏捷团队成员是稳定的， 或者说每个迭代的成本是相对固定的。如下例子：

Scrum 团队每个迭代的成本是固定的，总的人力成本是114,000（货币单位）。  

1. 固定日期的发布计划预算：

发布的日期是固定的，这样我们很容易算出需要多少个 sprint 来完成这个版本的内容,  发布的预算就是 #of sprints 乘以迭代的固定成本， 如果是10个迭代，总的预算是1140,000（货币单位）。

这种情况可交付的需求，依据最快和最慢的速率来预测，会给出交付范围是一个 range , 如下图的产品待办列表的 will have 和 might have 的范围：

 

2. 固定范围的发布计划预算：

这种情况下，假如发布范围是120 故事点， 团队的最快速率是 V=20， 那我们就可以推测需要6个迭代来完成，但最慢速率是 V=15，那就需要8个迭代来完成， 通常情况我们取保守值8个迭代来做预算， 即114,000 x 8 = 912,000（货币单位）。

这种情况预测可交付的日期，依据最快和最慢的速率，给出交付时间是一个范围（6-8 Sprints range）, 如下图：

 

3. 按用户故事点做预算：

对于一些相对成熟的有经验的 Scrum 团队， 团队已积累了自己的历史速率数据（至少1-2年），同时积累了相对准确的历史数据，我们会知道每个故事点的成本是多少（Y=cost per point ）。如果是同一产品的发布，我们假设发布范围是100故事点的发布规划，这样很快会粗略的计算出成本预算 = 100 x Y cost/point。

最后的提醒——敏捷预算的策略是增量式投资（incremental funding）

特别指出的是，敏捷的发布计划是动态的，当然我们在项目启动要申请预算，采用固定范围发布预算或固定时间发布预算策略，算出一个固定的成本预算数值。

有时我们会发现，即使范围满足了，时间节点没有超期，成本控制的也很好，但客户还是不满意我们的产品。所以度量项目成功的最重要的要素是价值（如下图），拥抱客户的变化，关注价值。我们必须有一套机制去响应变化，在 Scrum 中我们用产品待办列表来管理需求变更，同时一次只做一个迭代的计划，下一个迭代会灵活拉动新的需求，当然要经过核实的价值评估及需求梳理；注意到，我们在固定时间和固定范围的发布计划中都考虑了新的 “涌现” 的 must-have 需求情况如何去应对, 而不是简单回避或忽略，也不像传统的做法——机械教条地执行既定的合同或固定死的预算。  

当然质量也很重要，质量是不可牺牲的，产品质量是否可靠，运维成本是否很低。下图可示，唯一可调整的元素或者项目的约束条件是预算 (budget) , 范围 (scope) 和时间 (schedule) 。项目的成功更多是度量是否 “尽早和持续” 地交付价值给客户；如果有新的有价值的需求浮现， 敏捷的做法是，对于固定范围的发布，考虑延长发布时间；对于固定时间的发布，考虑放弃（drop）一些 nice-have 的特性以拥抱变化，关注价值。

 敏捷发布计划管理总的策略是，PO 关注产品的目标，定义和认别一些 MRFs（最小的可发布的特性组合） 来满足发布的目标，must-have 的特性组成了 MRFs。然后发布策略选择是固定时间或固定范围的发布，来规划和申请一个早期的预算成本。

成本 (cost) , 范围 (scope) 和时间 (schedule) 都是变量，三者会影响产品发布目标的实现， 所以，尽管我们有个预期的预算推算，但 PO 会持续实时的评估机会和风险，特别在每个迭代的评审会之后，积极与项目的赞助商（sponsor）讨论, 及时检视当前的产品增量，调整这三个变量，有时候会追加预算（加人和外包），多数情况先砍范围但也要考虑满足基本的 MRFs，有时候也会延长发布时间，敏捷发布是一个动态平衡实时监控的过程。

 如上图所示，与传统的预算相比，敏捷预算的策略是增量式 funding , 这有点像风险投资（VC）的 A, B,C 轮投资。这里包括：项目或产品立项前的初期评估投资；产品的探索构想 (planning/envisioning) 投资, 关键的验证学习（critical validated learning）投资， 发布计划1的投资，然后每个迭代结束后的评估和投资。每次的 funding 一定是基于更多的信息和学习点来决策。即使发布计划申请批准/allocated 的 funding 也不意谓一定要花掉这笔钱。永远是基于上一个迭代的产出和更多的信息来决定是否继续投资下一个迭代（Sprint by Sprint）。    

Scrum 中 PO 的角色更象是一个创业家或创业型的领导者，他/她在投资 Scrum 团队（固定的成本）和每个迭代。

 

Scrum敏捷发布和预算管理的几个要点：

（1） 固定时间的发布策略越来越来被业界采用，管理发布时间比发布范围的管理更容易。

（2） 度量项目成功的最重要要素是价值交付，质量不能牺牲，成本 (cost) , 范围 (scope) 和时间 (schedule) 都是变量和约束条件，调整范围是最优先考虑的手段。

（3） 团队稳定的交付速率对 PO 至关重要，特别是用于发布管理，最快和最慢的速率来管理发布预期（时间和范围）（range of dates or range of scope）; 切记不要用团队的速率做横向比较，做绩效考核。

（4） 敏捷固定时间或固定范围的发布，都要考虑 “涌现” 出来的 must-have 的特性。这里讲的 “固定” 范围发布是相对的固定。

（5） 敏捷的预算管理不是一成不变的，我们有一个前期的固定的预算测算（固定时间或范围的发布），但会基于每个迭代的交付速率和产品增量， 运用实际的真实数据和干系人的真实反馈来调整发布计划以优化产品。 

理解 Scrum 敏捷发布和预算管理机理，便于我们建立 “初期预算计划（plan）和响应变化策略 (planning)” 的平衡，这正符合敏捷的价值观和原则，既有一个大致的预算测算，同时基于实际交付的速率来监视和调整三个变量（范围，时间，成本）。Scrum 敏捷发布和预算管理的做法，降低了投资的风险，同时保证我们把钱用在刀刃上。

Jim Wang 

写于2020年11月15日疫情期间 

参考资料：

（1）CSPO 课件 (Jim Wang)  

（2）Essential Scrum: A Practical Guide to the Most Popular Agile Process by Kenneth S. Rubin.

（3）Agile Project Management: Creating Innovative Products (2nd Edition) 2nd Edition by Jim Highsmith (Author)

（4）user story mapping， Jeff Patton

SCRUM敏捷项目管理实战（深圳站）

1.    内容提要
SCRUM是目前各互联网公司普遍采用的敏捷项目管理模式，与传统的项目管理十大知识领域相比，敏捷更加直击要害，更加强调自组织和跨职能团队，更能帮助企业高效率交付和盈利！
而敏捷强调的是交付价值和交付价值驱动下工作，敏捷项目管理没有这么“迂回曲折”，而是简单直接和刀刀见血！
传统项目团队中有项目经理这样的角色，而SCRUM的团队模型中没有项目经理，而是由产品经理（Product Owner）、敏捷教练（SCRUM Master）和自组织开发团队所组成，强调协作和自我管理，让每个项目成员都成为项目的主人翁，让项目团队始终保持强大的战斗力。
PS：自组织开发团队，并不局限于开发人员，程序员、测试、运维、UE等其他角色都是开发团队的成员。

2.    废话不说，直接干！—— 内容简介
课程一开始，项目马上杀到，你将会围绕一个项目，实践：产品愿景->用户画像->用户故事->敏捷估算->敏捷迭代规划

1)    实战产品愿景
商业计划书可能太过于“重型”，我们需要的是能在60秒内说完、能抓住重点的、一页纸就能说明问题的产品愿景。

2)    实战用户画像
描述用户的基本信息（姓名、性别、教育程度等）、性格与喜好、期待、痛点等，为下一步的用户故事做好准备。

3)    实战用户故事
    理解用户故事的核心内容
    用户故事的识别与持续拆解
    用户故事的优先级

4)    用户故事的估算
这个估算不仅仅为了开发做准备，更重要的是帮助我们进一步澄清和拆分用户故事，这部分工作需要PO和开发团队合作共同来完成。
    故事点与相对估算
    团队共同参与估算
    估算的深层次意义

5)    用户故事地图——版本规划
    如何定义“最小的可交付成果”？
    产品经理与开发人员的沟通

3.    适合学员
    公司领导层
    产品经理（Product Owner）
    项目经理
    开发团队（包含程序员、测试、运维等人员）
说明：
1)    学员需要具备至少1-2年项目一线工作经验；
2)    本课程特别适合希望敏捷转型的企业和个人。

4.    老师简介
张传波，网名：Fireball（大大大火球）
    创新工场创业课堂敏捷课程老师
    华为研发及项目管理高级顾问、敏捷教练
    《敏捷开发知识体系》编写组成员
    PMI-ACP（国际敏捷项目经理认证）
    信息系统项目管理师
    工信部质量品牌公共服务平台专家
    广东省电子信息联合会专家
    中国软件行业协会系统与过程改进分会专业委员会（简称：CSPIN）主任委员
    广东软件行业协会软件过程改进专业委员会（简称：GDSPIN）高级专家
    需求分析畅销书《火球——UML大战需求分析》作者
二十年需求分析、软件开发、软件设计、项目管理、部门管理、公司管理及过程改进等经验，亲历“无数”项目，访谈“无数”客户，涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域，熟悉软件生命周期的全部过程，精通MSF、极限编程（XP）和SCRUM等并用于全公司的项目管理，先后帮助公司通过ISO9001审核、CMM3级及CMMI5级评估。
十多年的企业全方位改进经验，为上百家企业提供服务，善于针对企业实际情况给出针对性的改进“药方”，帮助企业解决实际的工作问题，提升生产力。
学员们对张传波老师分享风格的评价：（摘选）
每次都能直奔主题，波波老湿说得太直白，鲜血淋漓，一般人受不了。
非常到位，很契合实际！ 说道我心坎上了。
以前看了很多文章都没弄明白，经火球老师这么通俗易懂的例子，终于有概念了，谢谢！！

5.    时间、地点
时间：2019-3-31（周日）下午13:30-17:00（13:30开始签到，14:00开始实战）
地点： 深圳市南山区科技园高新南五道金证大楼9楼阶梯教室（感谢深圳金证为我们提供场地！）
交通指引：深圳地铁一号线（罗宝线）深大站C出口，步行约10分钟即可达到

6.    费用
公益价：250元/人
敏捷课程是“高大上”的课程，课程费用通常也是“高大上”的。
为了推广敏捷，让更多朋友可以实践敏捷，我们开办了这个敏捷公益课！
 (场地座位有限，我们可能会限制同一个公司的报名人数）

7.    报名
报名办法1：
 手机扫描二维码报名并支付。

报名办法2：
猛点链接在线报名和支付：http://douya222.mikecrm.com/tWqSWVb