辅导发布计划的制定

发布计划的最终制定是通过发布计划会议完成的，因此，针对发布计划实践的辅导主要也是围绕发布计划会议开展。分为会前的检查与辅导、会议过程中的辅导、以及会议后的跟踪与辅导。

会前的检查与辅导

会前要准备的内容很多，通常也会持续比较长的一段时间，通常至少需要一个星期，甚至两个星期才能完成。主要包括三个交付件（用户（技术）故事backlog、团队能力分析报告和项目初始风险列表）的输出，以及会议议程的制定。

用户（技术）故事backlog

用户故事backlog是整个产品的价值集合，完成每一个用户故事都能够被用户所感知，并给用户带来价值。技术故事backlog是完成产品开发所需要做的一些用户故事backlog所不能包含的工作，如平台搭建、技术预研、系统性缺陷修复等等。技术故事的完成本身不会给用户带来直观的价值，但是它们是完成用户故事的先决条件。

在制定发布计划时，一个好的故事backlog需要具备如下条件：

故事优先级已经被明确定义
相互之间关联性的故事应经被标识，并清晰注明关联关系
故事规模都已被评估，且不能有特大规模（需要至少两个迭代才能完成开发）的故事。
不需要所有故事都已被精细定义（已澄清清楚，各角色之间无异议，开发拿到后能直接进入开发工作，测试能够进行测试用例的编写），但是被精细定义的用户故事要能支撑至少两个迭代的开发工作。

团队能力分析报告

团队能力分析报告定义了团队平均每个迭代所能完成的故事点数，更准确的团队能力分析有助于制定出更具指导意义的计划。团队能力分析主要来源于项目管理者对团队的了解，可以通过对之前项目的迭代数据进行分析得出。

一个好的团队能力分析报告在一定程度上依赖于前期项目团队开发速度的稳定程度，开发速度越稳定，得出的结果越准确。因此团队能力分析报告中应当尽可能地分析出前期项目中团队能力不稳定的原因。在得出更客观的分析结果同时，避免马上要开展的项目出现同样的问题。

项目初始风险列表

项目初始风险列表定义了根据现有状况所能预计到的项目风险。

主要来源于对前期项目的项目总结中发现的问题。可以将前期项目中已发生过的问题作为新项目的风险进行管控，防止犯同样的错误。

另外因为一些新的事情肯定会在新项目中出现。如新的技术应用，新的团队成员，新的开发模式等等都可能引入新的风险。这些新的事情也要进行分析，并在必要的情况下列入风险列表进行管控。

制定会议议程

一个好的发布计划会议议程要能够确保会议完成发布计划所要达到的目标。不同的团队，不同的业务内容可以采用不同的会议议程。这里有一个推荐会议议程可以用来参考。

会议必备资料检查、会议目的、议程、纪律宣导

用户故事backlog陈述(突出重点、避免冗长，不需要一一介绍)
用户故事优先级以及规模确认（在必要的情况下可以进行调整）
风险列表确认（在必要的情况下可以进行调整）
发布节奏定义（发布点路线图），要至少包含：关联性故事的如何梯次发布，需打包发布的需求的打包机制、愿景故事的发布、项目整体范围（目标）定义
发布计划反馈机制的定义，要明确什么时间以什么样的形式对发布计划进行刷新
制定迭代日历，迭代日历包含迭代周期、迭代数量以及每个迭代的固定活动定义。迭代日历要能与发布点路线图相匹配

会议中的辅导

敏捷教练在会议过程中要避免过多地参与团队的业务讨论，要把主要精力用于：关注会议是否按照议程进行，会议议程是否偏离会议目的；关注会议进展情况，在会议陷入僵局时要能打破僵局，让会议重新顺利起航；关注意见领袖与沉默者确保每个人都已充分表达自己的想法。

会议后的辅导

发布计划会议要的辅导只要做好两件事情即可：会议总结和交付件存档。

会议总结不能简单地理解为对发布计划会议进行总结，会前的一些准备工作也应该纳入总结范围，在会议总结时发现的一些与发布计划相关问题要及时解决。交付件存档只要适当地跟催下即可。

确保反馈机制的有效运转

在前面的过程中，我们已经完成了输入、过程、输出以及反馈的定义。发布计划的制定基本上已经完成，但是发布计划能否对工作开展更具知道到意义，能否随着开发的进展而不断精化，就要看反馈机制是否有效运行。

一般情况下，反馈机制都是通过发布计划刷新会议开展运作，发布计划刷新会议可以把它理解为小型化的发布计划制定会议。其辅导方式也可以借鉴发布计划制定会议。关注点在如下几个：

用户故事列表是否需要更新
风险列表是否需要更新
开发速率是否需要更新
项目目标是否能进行更精确地定义
互动需求与计划内需求的平衡

辅导发布计划关键角色

发布计划是否能得到认可，是否能有效指导开发进行，与下列关键角色是否发挥出应有的作用息息相关。因此对他们的针对性辅导也要纳入日程。

首先，不论是对谁进行辅导，都要与其就“做好发布计划需理解的观点”达成共识。其次才是根据其角色定位开展针对性的具体工作辅导

辅导PO

PO是用户故事backlog的管理者，用户故事backlog的是否按照要求输出是PO的责任。

PO用户故事的澄清主责人，在发布计划会议前与发布计划会议中的每一次用户故事澄清PO都要在场。

PO要理解并贯彻“发布计划不是承诺”的思想，要防止PO与PM不断地就完成多少个用户故事进行纠缠。

辅导UE

UE要辅助PO管理用户故事backlog和对用户故事进行澄清。每一用户故事澄清UE也需在场。

UE是交互设计计划主责人，交互设计是UE的本职工作，交互设计一定要有一定的提前量，发布计划制定完成后，要辅导UE完成交互设计计划的制定。

辅导PM

PM是发布计划会议主持人，是发布计划的执行与管理者。也要要理解并贯彻“发布计划不是承诺”的思想。

辅导QT

QT是测试计划主责人，发布计划制定完成后，要辅导QT完成测试计划的制定。

辅导核心SWE

核心SWE要辅助PO/UE澄清用户故事，每次的用户故事澄清要尽量到场。

核心SWE是技术故事提取者，要在充分理解产品要求和技术要求的前提下尽可能地提前发现需要完成的技术故事。

核心SWE是技术风险识别者，要尽可能地识别出相关的技术风险，同时在定义故事的风险优先级时发挥作用。

辅导干系人

干系人是项目期望的提出者，最好能出席发布计划会议。要相信团队的计划结果。同PO一样，干系人也要理解并贯彻“发布计划不是承诺”的思想。

敏捷教练如何辅导发布计划的制定之开展行动相关推荐

对话阿里敏捷教练 | 成功辅导过淘宝、闲鱼，他都是如何帮助团队
为了让大家对敏捷有更多的了解,小编特意采访了阿里巴巴高级技术专家.敏捷教练张燎原.他是如何看待敏捷.如何帮助团队落地敏捷的,作为研发团队的一员,我们可以从哪些地方着手敏捷,以下是对他的采访. 嘉宾简介 ...
中国区首发 | 规模化敏捷RTE(企业级敏捷教练/发布火车工程师)国际认证课程
SAI-SAFe规模化敏捷官方重磅推荐,由SCALED AGILE全球金牌合作伙伴联合提供,中国区独家课程首发. | 全文约有1800字 | 阅读完约需2分钟中国区独家RTE认证课程 01 课程 ...
敏捷项目管理敏捷工作之发布计划
发布计划发布:指发布出来用于生产的一组可用的产品特性.无需包含所有的路线图的功能,至少要包括最小的可上市的特性集. 计划发布:确定下一组最小可上市的特性集,并确认团队能够行动起来将最迫切的产品推出的 ...
阿里敏捷教练：多团队开发一个产品的组织设计和思考
Scrum等敏捷开发框架,最初都是为5到9人的小团队设计的.通过保持专注和合理利用新技术,在相当长的时间里小团队仍然可以支撑业务发展. 随着业务成长,小团队的产出可能跟不上业务需要,团队就会面临规模化 ...
敏捷教练和专业教练有什么不同?
我们在高阶A-CSM的课堂上,几个经常碰到的问题:什么是敏捷教练?敏捷教练和专业教练有什么不同?ScrumMaster是不是敏捷教练?下面我们一起探讨这些话题. 什么是教练? 权威机构对教练的定义: ...
敏捷 scrum_敏捷教练，Scrum大师，交付经理
敏捷 scrum ``有人不时地在我的邮箱中出现问题. 我希望在这里发布问题和答案,希望其他人可以从中受益. 我之前已经做过几次("敏捷诊所:我们的敏捷问题--") 我总是很乐意为 ...
硝烟中的Scrum和XP-我们如何实施Scrum 12)发布计划 13)组合XP
12 怎样制定发布计划, 处理固定价格的合同一次只计划一个sprint的事情会显得提前量不足, 提前做计划是个好习惯; 尤其是签了固定价格的合同之后, 不得不预先计划好, 防止无法按期交付的危险情况 ...
阿里敏捷教练何勉：论精益思想及精益产品开发实践体系
摘要: 精益求精是工匠精神实现的最佳方法,通过引入实践精益思想的原则和方法进行精益产品开发,打造对客户最好的产品进行交付,其次通过精益思想的理念降低企业的运营成本,提高企业的运营效率.阿里资深解决方案 ...
带你了解敏捷和DevOps的发布策略
摘要:随着数字化.信息化.网络化和智能化的普及和发展,企业对软件服务的质量和上线速度要求越来越高.传统研发模式难以满足要求,企业的开发运维模式逐渐向敏捷和DevOps 转型,敏捷和DevOps理念正被 ...
【Scrum模式语言15】发布计划（Release Plan）
译者导读: 这篇文章,让我想到了全局观,应该是作为产品负责人具备的基本素养,不仅给产品以愿景,给团队以方向,同时也能帮助产品负责人与干系人很好的进行沟通.而发布计划应该是这种素养的可视化的表述之一.发 ...

敏捷教练如何辅导发布计划的制定之开展行动