我正在编写 程序管理书籍 ，特别是发布计划章节。我在项目中看到的一个问题是组织/高级管理人员/产品经理想要整个季度的“承诺”。由于他们考虑的是四分之一长的路线图，因此从他们的角度来看，这并非不合理。
承诺有问题，需要规划整个季度。这是遗留（瀑布）思维。承诺并不是公司真正想要的。交货是公司想要的。您交付的次数越多，您更改的次数就越多。
这意味着改变发布和重新计划的频率。
考虑四分之一承诺的这些挑战：
- 即使你有小故事，你也可能无法完美地估计。你可能会在比计划更少的时间内完成某件事。您想利用进度提前吗？
- 在故事太大的情况下，您无法轻易提供良好的估计（您需要百分比置信度或其他一些机制来解释风险），您（根据我的经验）可能会低估。
- 如果在季度中期发生变化，并且您想要更多选项或更改功能团队可以提供的内容怎么办？是否要等到季度末才改变计划的方向？
如果您以较短的节奏“投入”，就可以解决这些问题。 （我更喜欢重新计划这个词。）
如果你考虑不超过一个月的持续时间“承诺”，你可以看到产品的发展，提供整个计划的反馈，并改变你在每个月的里程碑所做的事情。那更好。
这是一个新颖的想法：根本不要承诺任何事情。使用连续计划。
如果您查看四分之一的路线图，您会发现我展示了三个迭代的故事作为 MVP。根据我的经验，这至少是一次迭代太多的前瞻性知识。我知道很少有球队可以看到六个星期。我知道很多团队可以看到下一次迭代。我知道有几个团队可以看到两次迭代。
这对规划意味着什么？
用短篇小说做持续的计划。您可以保留 6 季度路线图。没关系。路线图是一个愿望清单。不要 承诺 四分之一的路线图。如果您需要承诺，请一次承诺一个迭代。或者，在流程/看板中，一次提交一个故事。
这将鼓励每个人：
- 细想。小故事、短迭代、要求每个团队管理他们的 WIP（进行中的工作）将有助于整个项目保持动力。
- 请参阅相互依赖性。特征越小，相互依赖性越明显。
- 计划较小的事情并计划较少的时间，这样您就可以减少程序的计划负荷。 （我敢打赌，与四分之一的计划相比，您对一两次迭代的计划要好得多，花费的时间也要少得多。）
- 在滚动波中使用可交付计划（“做这些功能”）（在团队交付时继续重新计划）。
这些想法将帮助您更频繁地看到程序中的价值。当您经常发布并重新计划时，您就建立了作为 程序的 信任 。您的经理可能会停止要求“承诺”。
如果你保持小计划，你就不需要每季度一次将所有人聚集在一个大房间里进行发布计划。如果您进行持续计划，您可能永远不需要每个人都在一个房间里进行计划。您可能希望每个人都在一个房间里进行启动或帮助人们了解谁在参与该计划。这与大型计划会议不同，在大型计划会议中，人们计划而不是交付价值。
如果您正在管理一个项目，您需要什么来进行持续规划？你能看到什么障碍？您以这种方式进行计划会有哪些风险？
哦，如果您正在走向敏捷并且您使用 发布火车 ，请记住发布火车承诺 日期 ，而不是范围和日期。
考虑每周或每两周计划和重新计划。您的程序需要什么才能做到这一点？