我做了一些相当彻底的阅读和搜索，并没有找到关于这个主题的任何内容，所以希望我不会创造一个骗局。如果在我欣赏链接之前已经询问过这个问题。
我在一家企业开发商店工作，该商店目前主要使用瀑布流程进行软件开发项目。我已经阅读了很多关于敏捷方法的书籍和文章，我可以看到它中的很多内容可以真正改进我们的流程。我还可以设想如何在开发人员级别应用许多实践，即配对编码，更短的迭代，重构，TDD等。我们已经做了很多。
我认为，在我们组织管理层的头脑中，存在的巨大差距是长期规划如何在敏捷流程中发挥作用。在我们开始研究项目之前，我们需要获得内部客户批准的预算，这些预算是为我们正在生产的软件付费的。如果我们不预先做一些相当详细的要求和估算，我们怎么知道预算应该是什么？当然，我们的要求和估计并不完美（有时真的不合适），但它们总比没有好。
一个相关的问题是如何在施工期间判断项目的长期状态。如果一个特定的软件产品对组织来说值一定数量的美元，他们如何知道我们是否能够在我们最终花费超过它的价值之前实施该产品？我可以看出敏捷在确定下一次迭代中你可以做什么工作时的工作原理，但是你如何计算出到1.0版本的工作总和以及你是否可以完成到明年第四季度？
这个战略层面的规划如何在敏捷商店中发生？您是否只是根据您从最初的模糊用户故事开始估算？你不做这种性质的长期规划吗？您是否还有一个前期的高级需求/设计阶段，然后在项目开始后转变为敏捷流程？
谢谢，
~Justin
答案 0 :(得分：6)
纯粹敏捷的大画面规划极其困难。第一个大问题是（正如你所发现的那样）纯粹的敏捷和前瞻性规划（预算，长期时间尺度等）从根本上并不能很好地发挥作用。
如果您熟悉project management triangle（范围，成本，时间表），敏捷的重点是确定成本和进度并允许范围变化。在大型组织中，范围和时间表通常是固定的（我们需要在下个季度使用具有这些功能的产品X），然后您花费大量时间来讨论成本（即开发人员数量），并且由于时间表和允许的费用还不够。
这将我们带到第二个问题 - 在传统的公司环境中运行纯粹敏捷所需的思维方式的改变。理想的建议是让您的组织购买敏捷批发并认识到他们可以构建积压的功能，但并非所有功能都可以交付。然而，交付的将是高质量，准时和已知成本。改变为纯粹的敏捷可以导致组织思维的严重转变，Mike Cohen's book专业地概述。
不幸的是，很难将整个组织的想法从单个项目的背后改变，所以第三种方式是妥协 - 你不做纯粹的敏捷。你做的就像RUP /瀑布，你可以做一些前期需求分析，并做一些设计和架构工作。足以突出风险领域并理解大局复杂性。然后运行迭代“0”。
迭代0是高风险领域概念开发的证明，有助于理解关键估算和团队绩效。这可能是一个被扔掉的原型，它可能是你的应用程序框架的基础但重要的一点是要对估计的质量和团队的可能速度有一个基础感觉。这为你提供了构建的基础一些计划并设定可能的预算。
然后，您可以将开发工作作为正常的敏捷迭代运行，从早期用户反馈和可见性等方面获益。迭代方法还有助于为您提供定期里程碑，以便跟踪计划，允许重新计划点和早期预算警告/下运行。使用迄今为止的估算/实际值来重新制定未来的计划。
答案 1 :(得分：3)
不要执行项目，其价值如此之低，以至于您无法获得合理的投资回报率。
如果没有，请不要尝试创建假确定性。大局规划是，而且应该是模糊的。
敏捷实施流程允许客户引导和适应。如果您拥有一支经验丰富的团队，一个众所周知且稳定的领域，没有新的技术或方法，您就会知道它的速度。这也限制了您可以估算的项目的大小。团队定期更换，技术每隔几年就会发生变化。
如果客户需要详细的预算，她需要提供可估计水平的用户故事。这意味着必须提前做很多工作。必须完成所有可见的风险峰值。只有当要求足够稳定时，这项工作才有用。
Eric J.描述的详细程度完全没必要。这应该在软件中并从中提取，而不是事先在纸上指定。
[编辑]有一个客户或开发人员无法充分理解的故事列表可能很有趣。你不应该花很多时间在他们身上，因为他们的稳定性很低。使用购物车分类，您可以快速了解尺寸和优先级。在存在大量头寸差异的任何地方，您都有潜在的风险。 要求所有利益相关者提供新故事可以帮助您估计完整性。
答案 2 :(得分：2)
在进行战略规划时，内部客户往往更关心需求的功能。
我倾向于使用支持可追溯性的工具创建功能路线图（我更喜欢Sparx Systems的Enterprise Architect，但很多工具都可以）。我在项目发起人层面审查了所需的功能和所需的顺序。
然后，我与合适的人（有时是业务专家，业务分析师或高级IT人员，如架构师）合作，将每个功能分解为一组高级需求。我创建了从高级需求到功能的可追溯性。此时，要求通常处于“添加ABC屏幕”，“添加DEF屏幕”，“创建重新计算XYZ的后台进程”等级别，而无需进一步详细说明。此时，我与适当的人合作，根据可用的任何指标（从直觉到统计屏幕平均需要多长时间添加）来估算每个高级别要求的工作量。然后，我的建模工具总结每个特征的总估计工作量，然后可以将其呈现给项目发起人并放入项目计划中。
然后我们开始迭代来解决第一个特征或特征集。每个高级要求都被细化为详细要求（“屏幕ABC需要名字字段，最大长度40，需要”等等）。根据项目需求，我们可能会重新估算更详细的需求，并将其提升到追溯的高水平要求。更常见的情况是，开发人员将被指派开发Screen ABC，将在sprint计划工具中输入他自己的估计，并且该估计将回滚到原始模型。由于他实现（和估计）的需求跟踪追溯到功能级别的高级需求，因此我们在每次迭代时都会不断更新计划。
需要一些纪律和努力来设置它，但它是值得的。
答案 3 :(得分：1)
如何做大局敏捷？可以这样想：瀑布项目中业务分析师的主要目的是提出关于基本行为要求的最小但质量的全局图，并且敏捷项目中业务分析师的主要目的是提出关于基本行为要求的最小但质量的全局图。
答案 4 :(得分：0)
“SAFe”通过资助“敏捷释放列车”来代替Proyects来解决这个问题：