关闭。这个问题是opinion-based .它目前不接受答案。
想改进这个问题？更新问题，以便 editing this post 可以用事实和引用来回答它.
4年前关闭。
Improve this question
我做了一些相当彻底的阅读和搜索，但没有找到关于这个主题的任何内容，所以希望我没有制造一个骗局。如果之前有人问过这个问题，我将不胜感激。
我在一家企业开发商店工作，该公司目前主要使用瀑布流程进行软件开发项目。我已经阅读了很多关于敏捷方法的书籍和文章，我可以看到其中的很多内容可以真正改善我们的流程。我还可以设想如何在开发人员级别应用很多实践，即结对编码、更短的迭代、重构、TDD 等。我们已经在做很多这样的事情。
我和我们组织管理层的最大差距是长期规划如何在敏捷过程中发挥作用。在我们开始着手一个项目之前，我们需要获得为我们正在生产的软件付费的内部客户批准的预算。如果我们不预先做一些相当详细的要求和估算，我们怎么知道预算应该是多少？当然，我们的要求和估计并不完美(有时真的很差)，但它们总比没有好。
一个相关的问题是如何判断一个项目在 build 过程中的长期状态。如果一个特定的软件产品对组织来说值(value)一定数量的美元，那么他们如何知道我们是否能够在最终花费超过其值(value)之前实现该产品？在确定下一次迭代期间可以做什么工作时，我可以看到敏捷是如何工作的，但是如何计算出达到 1.0 版的工作总和以及是否可以完成的估计到明年第四季度？
这种战略层面的规划如何在敏捷商店中进行？您是否只是根据最初的模糊用户故事进行估算？你不做这种性质的长期计划吗？您是否还有前期的高级需求/设计阶段，然后在项目启动后过渡到敏捷流程？
谢谢，
〜贾斯汀
最佳答案
使用纯敏捷进行全局规划是极其困难的。第一个大问题是(正如您已经发现的)纯粹的敏捷和前瞻性规划(预算、长期时间表等)从根本上不能很好地结合在一起。
如果您熟悉 project management triangle (范围、成本、时间表)，敏捷的重点是固定成本和进度，并允许范围可变。在大型组织中，范围和时间表通常是固定的(我们需要在下个季度之前具有这些功能的产品 X)，然后您会花费大量时间来争论成本(即开发人员的数量)，并且通常最终会延迟交付，因为时间表和允许的成本还不够。
这将我们带到了第二个问题——在传统公司环境中运行纯敏捷所需的思维方式的改变。理想的建议是让您的组织批量购买敏捷，并认识到他们可以构建积压的功能，但并非所有功能都可以交付。然而，交付的将是高质量、准时和已知成本的。转变为纯敏捷会导致组织思维的严重转变，如 Mike Cohen's book熟练地勾勒出轮廓。
不幸的是，从单个项目的背后改变整个组织的想法是非常非常困难的，所以第三种方式是一种妥协——你不做纯粹的敏捷。您所做的类似于 RUP/Waterfall，您可以在其中进行一些前期需求分析并进行一些设计和架构工作。足以突出风险领域并了解大局的复杂性。然后运行迭代“0”。
迭代 0 是高风险领域的概念开发证明，有助于理解关键估计和团队绩效。这可能是一个被丢弃的原型(prototype)，它可能是您的应用程序框架的基础，但重要的是要对估计质量和团队的可能速度等有一个扎实的感觉。这为您提供了构建的基础一些计划并设定一个可能的预算。
然后，您可以像正常的敏捷迭代一样运行开发工作，获得早期用户反馈和可见性等的好处。迭代方法还有助于为您提供定期里程碑跟踪计划，允许重新计划点和预算超出/不足的早期警告运行。使用迄今为止的估计/实际值来重新制定 future 计划。
关于project-management - 使用敏捷进行大图规划，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1976259/