在第1部分中 ，我写了关于功能集的思考以及如何快速创建更小功能的功能集（如果有的话）。
这是因为功能在一个季度中的到达率不一样，而且它们的价值也有所变化。
由于要素的价值在变化，并且某些要素集需要更定期地交付价值，因此真实的路线图看起来更像这张图，“敏捷路线图发生变化时”。
请注意，最重要的功能集在第一季度具有更多功能，在第二季度和第三季度变得更小，而在第四季度还不那么完整。 第二行是功能集，我们希望可以更经常地看到到货和交货。 第三行的功能集较小，我们需要更多的交付时间。
如果仅按常规节奏进行功能到达和交付，则我们也许能够进行四分之一的计划并使其工作。 但是，我的客户对“您能做更多”和“我们知道我们要求您做出承诺，但现在我们需要您进行更改”感到很大压力。
当PO意识到他们可能不需要MVP或MVE的功能集中的所有功能时，他们就会看到进行更频繁计划的可能性。
输入滚动波计划。 在滚动计划中，您可以确定详细计划的持续时间，并在完成一个星期后计划下一个星期。 滚动浪潮始终以“浪潮”（计划的持续时间）作为详细信息，您可以在继续进行下一周（或一个月）的优化。
示例1：两个月的波动
而不是每季度进行一次详细计划，让我们看看如果有两个月的滚动浪潮会发生什么。
您可能决定进行为期两个月的波动，在该波动中您具有第一个月的详细信息，下一个月的假设，并在完成第一个月后计划第三个月。 您可以优化第三个月，甚至在进入第三个月后甚至可以创建一个假定的第四个月。 您总是会有两个月的波动，其中第一个月是明确的，第二个月是假设。
我的一位客户以这种方式尝试了两个月的滚动。
产品负责人聚在一起，创造了第一个月的详细信息。 他们有一个假设的第二个月（粉红色），灰色的第三个月显示了他们的假设，但没有承诺。
在第一次迭代之后，他们意识到他们意识到需要更改下一次迭代（第一个月的第一部分）。 他们还意识到，他们对两个月的最后一次迭代的去向并不十分了解。 这就是为什么他们将最终迭代的时间变灰的原因。
他们在该计划中非常成功。 然后他们有了一个新程序，他们意识到两个月的滚动浪潮对他们没有用。
示例2：一个月的滚动浪潮
该组织有一个由六个功能小组组成的计划来开发新产品。 他们以为自己了解客户。 但是，这项工作将彻底改变客户使用产品的方式。 这些PO确信他们不能承诺长达两个月的时间。 他们决定使用一个月的滚动计划。
他们在路线图上注明了MVP和演示，这对他们来说是一个新主意。
他们有一个为期一个月的计划，但前两个星期只提供详细信息，而第三个星期只提供详细信息。 请注意，没有为第四个星期指定任何故事，并且在路线图上没有任何其他内容可以用于过去的第四个星期。 他们用自己的大路线图来谈论几个月，而不是季度。
果然。 第一次迭代后，事情发生了变化。 因为学习率很高，所以他们改变了第三次迭代和第四次迭代。
他们对此学习感到有些惊讶。 但是，他们使用MVE和MVP来指导他们的工作。
您可以按小块计划的频率越高，团队就可以按小块交付。 当团队提供较小的价值时，人们不太可能向团队施加更大的压力和/或改变团队的工作方式。 （在以后的文章中，我将更多地讨论管理缺乏现实性。）
并非每个人都可以使用一个月的滚动浪潮。 接下来，我将讨论基于流的映射。
扫一扫
2140
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
