为什么你可能会争取渐进的阐述

渐进式制定是将史诗中删除到用户故事中并定义这些故事的细节的过程随着时间的推移随着故事在发布计划中移动，并越来越接近于添加到Sprint中。我一直在探究为什么一些组织很难将其付诸实践。

背景信息：我经常与大理石组织合作，使承诺2至4个月。他们使用Scrum，稳定的团队，稳定的速度和某种数量的史诗/特征/故事分解来制定这些承诺。敏捷可以帮助他们预测。每当我开始使用这些产品所有者和程序经理时，我解释了需要快速识别发布的所有故事（以便我们可以创建或验证发布计划），但也可以为团队准备2-3个Sprints的Backlog因为他们很快就会开始冲刺。有时，这就像魅力一样。其他时代队伍难以进入渐进的阐述方法。他们无法超越定义一个传递中所有故事的所有细节。

当人们考虑定义需求时，他们通常会有这样的想法计划发布和/或减少误解．一个人的主要目的会影响他的速度和细节水平:

因此，似乎必须进行妥协 - 在迅速或写作之间写作快速和写作之间的速度之间的平衡，在迅速规划或减少开发的误区之间进行写作。

这种想法背后隐藏着一些假设:

• 在一步中完全分析任何功能更有效。
• 没有所有细节，我们无法计划释放。

相反,我们可以仅通过用户故事列表来计划发布．规划具有功能列表和用户故事的版本是一个完全独立的需求，而不是“拥有开发和测试所需的所有细节”。前者是早期需要的，后来需要后来。这次时间通常被忽视。

进一步，它是不如果您需要执行分析的某些人，可以在一步中完全分析任何特征，更有效地分析任何功能。（例如，它们可以完全分配以包裹先前的释放。）即使可以证明只能看到一次只能看一次功能，以精益思维，我们不太关注个别工人的效率，远远知名对顺利的工作流程感兴趣。本地优化子优化整体。通过控制成本来保持宝贵的工作流动，我们通过控制成本来获得更多价值。在这种情况下，该工作是规划释放和分解功能的工作，进入故事和（最终）及时开发的细节。如果我们能够快速提出释放计划的用户故事列表，请保持（程序）管理工作流程。在这种情况下，管理工作是确保我们可以按时完成释放;并做利益相关者管理，风险管理和范围管理，如果不是。要是我们不能列出发布的所有故事，然后管理的工作就会受阻。

现在我们可以分离这两件事:发布计划和获取开发细节。我们可以重新定义这个问题，画一幅新的图:

客观的	目的	前提
计划发布时间表	快速识别故事	< -现在少写
计划以后冲刺	< - 定义血腥细节JIT	< -稍后再写

当我说“快速识别故事”时，我通常只是谈论故事标题，1个衬里。当我说“少写下”时，我也意味着现在分析。我们需要分析足够可能的候选用户故事的清单。

当我说“稍后写下更多”时，我也意味着更稍后分析。为此，考虑提前期。在我操作的背景下（见上文），我的建议是有2或3个Sprints的工作准备。什么“准备好”的手段以及需要多少细节取决于组织。请注意，“后来”可能只是1天后，但它仍然比“现在”更晚。

那个说，可以吗？产品所有者团队“现在”确定剩余特性的(可能的)描述之前想好它们的全部细节了吗?在我看来，BA或PO与技术人员配对，应该能够查看愿望列表上的功能，并为每个功能提供1到5个用户故事。一天或更短时间内就能搞定。

P.S.如果有人关心，这种方法解决了一个看似的冲突是从中约束理论并且被称为蒸发的云法。