多年来，我一直在教育和指导项目组，如何成功地使用包含在IBM® Rational Unified Process®（或者RUP）中的迭代化方法。我发现懂得迭代化方法并且将之运用于实践的团队在运用RUP的时候，会比使用传统的瀑布式方法的团队更有效率，更能集中精力。

不过，在这样的团队组织中，负责对软件开发项目做出重大的资金和管理决策的筹划指导委员会，通常对迭代化开发实践不太熟悉。他们不能提出正确的问题来估计项目进度，并且他们也不能提供适当的管理指导。

这篇文章概括了一些管理者和指导委员会在指导迭代化软件开发中，必须采用的一些方法。采用这些方法，他们能够使比较缺乏的IT资金优化，并且能够集中精力开发出能够提供大商业利润的软件特性。
持续为小项目提供资金来适应不断变化的需求

在许多组织中，都有一个每年的固定安排，是为不同部门的应用软件进行预算和安排不同的优先级，通常这些决策都是基于非常主观的商业案例来确定的，包括不太可靠的成本估算和无形的利益。但让人奇怪的是，这些组织常常会批准大的项目， 即使历史证明，这些大的项目失败的可能性是大的。这说明一些部门多年来没有足够资金来建立一个应用软件，用以记录他们订单的商业需求变化。当那个部门该年的资金终到位的时候，通常他们不但请求满足他们的需求的应用软件特性，而且还想象出一些他们认为他们在未来的五年中可能能用到的特性，直到他们的下一轮资金到位。我们把这种现象称为叫"软件膨胀"： 在应用软件上加上一些尚有疑问的商业价值。当组织将现有的软件迁移到一项新技术时，这种趋势也很常见。

比用来构建部门级应用软件的 "每5 年的大项目"方法更好的是，使用一种版本策略，该策略和很多产品公司构建软件的方法类似。这种方法需要不断地通过新版本改进软件，在一段时间内逐步增加新的功能。

商业行为会不断改变，因此应用软件需要相应地不断演进。因此，一项每 年20万美元的预算比每5 年100万美元的预算好。 版本策略有以下的一些优势：

    范围协商变得更容易。
        因为相关利益方知道将来总会有新的版本，他们会更愿意将一些目前不是特别重要和必要的对软件特性的要求推迟到下一个版本。
    软件膨胀更容易得到避免。
        相关利益方倾向于只支持那些可以带来大商业利润的特性。
    需求抽取是连续的。
        你能够在相关利益方提出要求的时候满足他们。你不必让用户再次重新解释他们的业务——可能是对着一个不同的人——每个一到四年。
    可以适当保持资源。
        由于正在进行的项目比较小，你可以保持资源的完整无缺，成为一个更有效的团队，研究表明，小的团队比大的团队更有效率。
    你可以在很长一段时间内调整过程改进。
        在新项目的先启阶段，生产力通常比较低，直到团队终建立了规律的节奏。
        在一个正在执行的项目中，你可以基于迭代评估不断改进该项目的各个方面。
    你可以大化工艺投资。
        由于你开发了度量标准和其他一些项目数据，比如构架蓝图、模式和机制，你可以不断地从整个生命周期管理工具中获得实际利益。

我鼓励各个组织改变他们的每年预算方法。我建议用以下方法来取代根据不可靠的商业项目来制定各部门IT预算的方法：

    给大多数部门分配固定的资金。
    每年根据前一年该部门所得的利润来调整资金的多少。

这种方法鼓励每个项目都有效地使用资金，这样他们不会危害下一年的获得的资金水平。因为每年相关利益方必须证明他们所做的是正确的，他们不会凭空想象他们接下来会做什么。

通过观察所获得的真实的商业利益，你会很快发现部门会从附加的自动控制中获利多，同时将他们获得的资金提高到适当水平。要求连续的、可说明的IT投资可以让你优化预算拨款。当然，至少保留你IT预算的一部份也是很谨慎的行为，这可用以保持更大的主动性来适应大的商业项目或者变化。
制定严格的时间安排，但是保持灵活的特性

我经常告诉人们我的项目总能准时和不超支。但是我通常不会解释其实这些项目的一些功能经常会和相关利益方原来希望的不同。这让我们知道，在我们行业中准确地制定一个重大项目功能范围，价格或者时间是非常困难的。我们的项目功能的范围总是会由于需求，资金，技术这些不确定因素而变化。改变项目的资源，技术或者截止日期会比调整该项目的功能范围影响更大。

在一个RUP项目里，生命周期由四个不同的阶段组成：先启，精化，构建和产品化。 虽然我们很早开始开发软件并且持续不断地在整个项目中都在开发软件，但是，我们的重点在这些阶段会有所改变。在开始过程中，我们关心的是，用所需要的小工作量来确定我们的高层功能范围，决定该项目进一步执行是否有意义（做或不做的决定）。