敏捷教练如何辅导发布计划的制定之统一思想

发布计划实践要达到的效果

    把产品设想转换成用户故事列表；

    确保用户故事列表可视、可评估；

    提供可预见的发布点路线图；

    发布计划是展望、调整，不是承诺与控制。

做好发布计划需要理解的观点

    很多人都有这些疑问：“如何让发布计划做的更精确？”“敏捷不是说要响应变化吗，为什么还要做计划？”“当需求有变化的时候计划该怎么办？”……所有这些类似的疑问其实都来源与一个对一个理论的理解程度：过程控制论。

过程控制理论

    过程控制理论主要关注如下几部分：输入、系统（过程）、输出、反馈。可以用一句话来描述这个理论，“输出无法通过过程来100%确定，但是可以通过反馈来控制”。

过程

    过程分为两种，确定的过程和不确定的过程。在确定的过程中，输出100%由输入决定。而在不确定的过程中，输出是随机的，不可完全预测的。除了理论上和实验室中，真实世界不存在确定的过程。也就是说，几乎所有的制造和开发系统都会有随机的输出，即系统是部分确定的。

输出

    输出可分为3种形式：完全不可预测，宏观可预测，微观可预测。

    完全不可预测的输出是我们所不希望发生的。因此重点研究的是宏观可预测和微观可预测。

    微观可预测很难预测并控制，比如我们无法通过定义过程来预测和控制单次投掷的硬币落地后是正面和反面。

宏观可预测则是在一定程度上可以通过定义过程并利用反馈来预测和控制的，比如我们可以通过明确定义投掷硬币的方法和落地规则等来预测并控制正面和反面出现的几率。

反馈

    反馈就是通过观察输出，分析并调整过程，达到控制输出的目的。反馈来源于可视化，需要对输出和过程进行持续调整。

过程控制理论在发布计划实践中的应用

    发布计划其实就是关于通过定义软件开发的过程，并且在过程中设置固定的反馈点，达到控制软件开发结果的目的。用户故事backlog就是软件开发过程的输入, 最终的软件产品则是输出。

用户故事backlog

    用户故事backlog作为软件开发的输入，需要具备一定程度的确定性。但是由于软件开发的特殊性导致作为输入的用户故事backlog本身也会不断变化，所以也需要一定程度的不确定性。具体如下：

1. 用户故事的优先级要确定
2. 用户故事的实现细节可不确定，但是前几个迭代要实现的故事要尽可能细化
3. 关联性故事以及需要打包发布的需求要标识清晰
4. 来源于产品愿景的故事要标识清晰

开发过程

    虽然说现实世界不存在明确的过程，但是大家都知道明确的过程是可以产生明确的输出。因此，我们应尽可能清晰的对软件开发过程进行明确。具体体现在发布计划中要明确的内容如下：

1. 开发节奏要确定
2. 反馈机制要确定
3. 开发团队要确定
4. 需打包发布的需求的打包机制要确定

开发结果

    开发结果就是在什么时间交付什么样的软件产品。同开发过程一样，我们无法定义准确的结果，但是我们也应该尽量明确地定义它，只有这样我们的反馈才能有方向。具体要求如下：

1. 预计发布日期要确定
2. 预计发布内容可不确定，但是我们要最大可能性地定义目标。比如：来源于愿景的故事一定要确定发布时间点

反馈提出的要求

    良好的反馈需要对输入、过程以及输出都具备充分的可视化，同时需要持续不断地开展反馈。

1. 保证可视化：前期项目的开发速率要搜集、总结，开发速率不稳定要分析原因并解决，风险列表以及风险状态要分享，用户故事backlog要充分共享。
2. 做好持续调整：持续不断地对工作量进行评估，需要不断审视、调整目标，需要不断刷新用户故事列表，需要不断地开展风险识别与控制。

    有了以上的正确观念后，我们就可以与团队一起围绕这些观念制定适合团队的发布计划。