本文内容包括:

持续为小项目提供资金来适应不断变化的需求 制定严格的时间安排，但是保持灵活的特性 通过协作改进需求 将维护人员调入开发团队 问合适的问题，并要求增加的功能演示 消除不必要的关闭 不断调整计划和期望 感谢 参考资料

来自于 Rational Edge：负责对软件开发项目做出重大的资金和管理决策的筹划指导委员会，通常对迭代化开发实践不太熟悉。这篇文章介绍了，为了有效地管理一个迭代化开发项目，这些委员会应该知道些什么和他们应当问哪些问题。

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

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

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

持续为小项目提供资金来适应不断变化的需求

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

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

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

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

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

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

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

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

制定严格的时间安排，但是保持灵活的特性

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

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

在这个项目的非常早期的阶段，我们能设计一个阶段计划， 作为在我们的软件开发计划里的一个部分，该计划概括了每阶段的长度和及其迭代，并且为每一个迭代阶段制定了严格的时间计划，包括应用软件的发布。 （在一项RUP项目里的每个阶段可以包含多次迭代。) 我们所不知道的是，什么功能将准确地在每一个迭代过程中被交付。

在下一个阶段——精化阶段，我们将关注在详细描述需求上，根据这些需求来开发软件，降低由技术、计划和资源带来的不确定性。随着我们的精化过程进行，我们可以在阶段计划中补充一些细节的东西。基于在先前一个迭代阶段中学到的东西，我们能将需要实现的软件的功能安排到项目的一个个迭代阶段。在精化阶段的最后，项目中的大多数不确定（危险）会得到减轻，我们能谈判做出确定的关于软件功能范围的承诺。 如果我们已经采取有规律的版本式方法来开发我们的应用程序，功能范围的协商会容易得多，因为我们总能在未来某一个版本中完成所要求的功能。

根据精化阶段制定的详细的程序功能范围，我们可以进入开发阶段。此时，我们的重点转移到根据经过校订的关于功能范围的合约，开发剩下的功能。现在我们该对我们的能力感到满意，因为我们能做到根据在项目先启阶段制定的时间表来完成所需要功能的开发。

通过协作改进需求

要成功地使用RUP需要在项目研究团队和相关利益方之间形成一种新的合作关系。过去，IT界已经提出了，向商业相关利益方正确定义需求存在一定风险，但是还是假设交付软件的风险取决于这些需求。 IT界会让用户签订一份文档，然后来控制这些需求的变化，从而达到管理这些风险的目的。 IT界会由于这些变化向用户收费，然后根据这些变化相应增加事先的估计，从而得以修改时间计划和 超额的支出，从而声称项目依然准时而且不超支。这种行为会在相关利益方和IT界之间引发猜疑，导致彼此感觉不舒服。

另外一种合作的方法会大大优于上述的方法。相关利益方和项目研究团队在事先都清楚认识到，在项目一开始完全正确地定义需求事实上是不可能的。因此让项目研究团队按照预算和时间计划下执行任务也是不可能的，因为这个预算和时间计划本就基于不确定的需求、资源和技术。

采用了“RUP精神”的项目中，相关利益方和项目研究团队成员清楚，随着他们了解更多，需求可以而且应当变化和改进。在项目研究团队排除项目中大多数不确定因素之前做精确的计划是不明智的。项目管理者必须尽快地说明那些不确定因素，这样负责实现的团队能够根据需要实现的功能的范围来确定软件功能。

团队经常会问：“精化阶段应该持续多久？”答案是，让这段时间足够长，从而项目研究组能降低已知的风险，项目管理者可以根据这个项目的时间安排、支出和功能范围来做出明确的说明。在一个典型的项目中，这个阶段意味着开发百分之二十的功能，或者足以证明整个框架能够支持所有的需求。

在精化阶段的最后，当研究团队已经将和进度、功能、技术和资源相关的大部分不确定性消除之后，他们可以列出需求，同时把将来需求的变化纳入正常的变更控制过程中。

将维护人员调入开发团队

很多组织将新程序开发和现有程序维护区别对待。通常来说，他们会外请顾问来根据新的技术建立新的程序，但是一旦这项程序开发部署完毕，他们会将该程序应用交付给内部维护人员支持。这会让工作人员失去动力。来维护一个别人建立的应用程序，对工作人员来说不会太满意，尤其是当这些维护人员还很少和最新技术接触的情况下。同样，在不知道先前的开发基于何种决策的情况下，要有效地维持一个应用程序也非常困难。如果你应用了这种方法，你必须给维护人员提供足够的材料，这将会增加系统的开销。

在迭代化开发环境中，将维护人员调到开发队伍中，让他们同时负责维护现有版本以及为未来的新版本开发新功能，就更有意义了。这促使团队始终关注系统的终极商业目标和特色，使得团队成员能够帮助完善这个商业目标和特色。最终，这种方法将带来一个更高效更愉快的开发队伍，同时也会减少文档负担。

问合适的问题，并要求增加的功能演示

迭代化开发方法会如何影响指导委员会管理与项目管理者会晤的方法呢？首先，管理者必须确认委员会了解在整个RUP各个阶段中项目会如何变化。只有这样委员会才能够问出有意义的问题，在不同阶段中调整提供的资金水平。比如，在精化过程中，他们应该问项目管理者索取定时更新的风险列表，从而能确认这些风险是否在该阶段最后过程被消除。

在一个项目先启阶段中，应集中关注于降低风险和不确定因素，这是使用RUP优于使用其他迭代化方法的重要优势。在开发软件的精化阶段中，如果使用降低风险的方法，发现最大的不确定性是十分必要的。很多风险与构架关系有关。尽管客户相关利益方可能会给开发团队施加压力，要求先建立他们所认为的最重要的功能，在精化阶段还是要根据结构而不是客户来设置优先级。指导委员会必须知道这些。在精化过程的最后，当最大的不确定性已经被解决，项目也将进入开发建设阶段，这时候优先级设置可以多考虑以用户需求为驱动。

在有些情况下，先完成主要功能的构建，来降低和需求相关的风险以及工作流中的不确定性，可能是有意义的。然而，如果这种功能是很直接的而且并不和一些很明显的不确定性相关，开发团队可以将该功能的开发推迟到构建阶段进行。记住：我们的目标是尽快完成精化阶段，这样我们就能给相关利益方确切的承诺，转入开发构建阶段。

指导委员会应当也需要基于一个已基线化的架构，验证关键用例场景（使用真的可以运行的软件而不是模型！）。 事实上，他们可能会考虑在他们的会议间放上投影机来使得软件演示更顺畅。这和传统的瀑布式方法有着根本的不同。指导委员会通常只有在整个应用程序即将投入使用的时候，看到demo版本而不是看到一个功能型的演示版本。另外，他们通常用甘特图来衡量整个项目的进程，在甘特图上会显示已经完成了33％尚未完成66％，诸如此类。或者，他们会问管理者是否已经签订了需求和设计文档。首先，而且也是最重要的是，项目管理者需要教育指导委员会成员，如何来衡量进度：唯一的有效方法是看能够工作的软件而不是签订的文档。

指导委员会应该在整个项目生命周期的早期开始关心项目的质量问题。我们不能仅仅根据已经完成的项目来衡量项目的进展，这样当我们发现质量差的时候就已经太晚了，这是我们低估了检测需要付出的努力。在可迭代化方法中，我们很早就有次品率的指标，也很早要求投入精力来进行检测，但是管理委员会可能不知道需要在整个项目的早期开始费心问一些有关质量的问题。因此，初级的RUP项目管理者可能不能遵从RUP的指导方针，在一开始的时候不能全面地检测。但是不幸的是，很多这样的管理者声称他们在用RUP管理项目，但是他们其实还是在采用瀑布式技术。通常来说，他们会将他们的任务计划按照RUP方法组织阶段分类，尤其是在测试领域。指导委员会必须检查确认项目管理者在项目开展的早期就有测试者，并且给测试者分配好任务检查使用情景下的任务执行情况。

总之，委员会应该对项目组做出以下的要求：

1. 使用演示版本展示项目进度：
   • 你完成了多少用例场景?
   • 在这次迭代过程中你完成了什么功能?
   • 在下一次迭代过程中你将创建什么功能?
2. 说明你已经完成的系统的质量：
   • 缺陷数是多少，并且这些缺陷的严重级别是什么？
   • 缺陷趋势是怎样的？（发现率和解决率）

消除不必要的关闭

将RUP引入传统的瀑布式环境一个富有挑战性的方面是：它对于结束的依赖性大大降低。人们只有在确保文档是完整和准确的情况下才会结束文档。因此，他们总是倾向于坐等而耽误了决策，这会推迟决策，从而减慢项目的进程，浪费经费。作为新的选择，RUP承认我们从过去的经验中得到的知识：在任何情况下文档都不可能完整和精确。因此RUP指导方针鼓励我们接受这样的现实：所有事情都会改变，都会往前走。.

软件开发界流行的名言是：你付出的努力的20%用以完成你80%的工作。因此这就意味着你需要付出你80%的努力来完成剩下的20%的工作。很符合逻辑推论的结论就是：在项目的迭代过程中，最好先做完那80%的工作，然后再完成那剩下的20%。敏捷的迭代开发都和追求“足够好”有关，你会在你的工作中继续改进你的产品。相关利益方和项目开发组连续的日常协作就保证项目的进展而言，是一个比间歇生产和关闭正式文档方法好得多的方法。

然而，对于重要的项目工件，我还是会要求正式关闭的文档，比如在先启阶段结束时的远景文档和软件开发计划，还有在精化阶段结束时。通常，当项目组对整个需求有更进一步理解的时候，在精化阶段的结束会产生重大的变更。尽管我倾向于调整范围维持预算和计划，但是有时重新规划剩下的迭代开发阶段是很有意义的，尤其是在你不能够降低功能范围，或者在项目还存在着交付功能的不确定性而引入另一个精化阶段的迭代的情况下。

不断调整计划和期望

我经常说管理一个瀑布式的或者传统的项目，在项目的前80%非常直接而有趣，在那段时间内，任务是线性的，在一段时间内你可以集中注意于一项规则（比如需求）. 然而当集成和测试开始的时候，你会经常发现不是模版不能整合，测试很费劲，系统架构有缺陷，执行效果很差，就是用户提出这个应用不是他们所需要的。如果你在管理一个瀑布型的项目，你在项目临近结束的时候，需要找一个借口将这个项目转交给另一个可怜人。

管理一个RUP项目在开始的阶段会更有些挑战性，因为我们同时考虑各种条件约束，包括需求、编程以及测试。然而在接下来的阶段，非正式沟通和良好的生命周期管理工具支持会使得项目的复杂性容易管理得多。

对一个RUP项目管理者来说最困难的阶段是精化过程的末期。这时候他们会发现范围、预算以及时间计划没有意义。这时候他们不得不做出很艰难的决定，可能还需要重新规划整个项目的一部分。但是这也有好的一方面，这发生在项目的先启阶段，这时候能让相关利益方调整他们的期望。

在整个项目的最后，尽管我们可能不能达到相关利益方开始的 预期, 我们应该可以达到我们在精化阶段最后达成的协议所规定的要求。让相关利益方学会期望团队实现在精化的最后阶段所拟订的要求，而不是他们开始所期望的要求，这是成为一个成功RUP项目管理人的关键所在。

我希望我已经向大家说明，在建立部门应用软件的时候，采用不断增强的版本策略可以在IT投资上有非常显著的好处。RUP为这种方法提供了很好的指导。我希望您的组织可以考虑这种方法。 如果你已经决定创造一个迭代化软件开发环境，那教育相关利益方就非常重要，你必须让他们懂得RUP项目的合作特性。你的指导委员会管理你开发应用的方法对你的成功有效地使用预算，避免传统瀑布式方法的不佳行为有着非常重要的意义。

祝你好运！

感谢

感谢Philippe Kruchten 和 Joshua Barnes输入了本文内容。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文。