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

辅导发布计划的制定

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

会前的检查与辅导

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

用户（技术）故事backlog

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

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

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

团队能力分析报告

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

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

项目初始风险列表

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

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

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

制定会议议程

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

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

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

会议中的辅导

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

会议后的辅导

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

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

确保反馈机制的有效运转

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

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

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

辅导发布计划关键角色

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

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

辅导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一样，干系人也要理解并贯彻“发布计划不是承诺”的思想。