本文来自于 Rational Edge：在软件开发项目生命周期的中间阶段应该度量哪些方面，以确保该项目的全面状况良好并按计划进行呢？通过本文弄清风险列表、待完成工作队列，以及其它项目工件是如何被客观地用来度量项目的全面状况的。

 这是由三部分组成文章中的第2部分，它描述的是作为管理软件开发项目的一部分，即评估策略问题。第1部分介绍了作为评估项目全面状况机制的度量的概念，我还描述了可以帮助您在先启阶段评估项目全面状况的特殊度量方法。在这个系列的第2部分中，我专注于开发工作中的主流部分的度量方法：即详细精化和构建阶段。

精化和构建阶段有很多的相似性，这些相似性导致它们有相似度量方法。在这两个阶段中，主要的焦点是产生能够逐渐实现令人期待的日益增长的系统功能的可执行版本。两个阶段中的主要不同来源于不同阶段所处理的不同风险：在精化阶段处理的是影响解决方案体系架构的技术方面风险，而构建阶段处理的是有关于预定的时间和预算之内完成开发项目一大部分工作的风险。这些不同之处致使两阶段中度量方法的重点有些不同。

精化阶段

精化阶段中的主要焦点是检验基本的技术方法是否被用作先启阶段的评估基础，并且填充必要的技术细节以保证将来解决方法的交付。如果技术风险很低 --由于它们在一个稳定且被验证过的构建基础上，对现有的系统功能性增加的作用很小－－精化阶段可以相当简短，度量方法可被约束来测量这个断言，被提议的变化将不会破坏现有的构建。由于这个原因某些“敏捷的”途方法，如 Scrum 和 Xtreme Programming 就缺少一个等同阶段。这些方法或含蓄地或明显地假设构架的风险很低，并且任何结构性变化将从正常的开发工作中暴露出来。

在精化阶段执行的典型的开发工作也会执行附加的场景， ¹ 这将证明技术方法是可靠的并且粗略的时间进度表和来源于先启阶段的成本数据也是合理的。从规划的角度来说，精化和构建两个阶段的最主要区别是开发场景的选择。在精化阶段，风险决定了它们的选择——就是说，他们选择场景就要面临风险。

解决这些富有挑战性的技术性问题不仅会增加技术方面选择性解决方案的确定性，而且将最大限度地解决那些在解决方案中会有威胁尚未解决的项目的问题。在清除技术性风险过程中，将获得有价值的经验和信息，致使项目剩余部分的评估和计划可靠性大大提高。当我们在构建阶段考虑度量方法时，这将成为重要的因素。

从人员配备来说，精化阶段和构建阶段的最主要区别在于精化阶段倾向于用更小的队伍专注于探究技术性风险的解决。这种具有探索性精化阶段意味着项目人员和相应的成本不会成比例的增加直到构建阶段，项目小组可能被扩增来完成剩余的工作。

精化阶段的度量

如前所述，降低技术性风险是精化阶段的主要目标。因此，在此阶段的度量将专注于是否真的降低了技术性风险的问题。为了有效地管理项目（实线部分）和预期发展（虚线部分），图1展示了典型风险的概况。

图1：迭代的项目中预期风险的概况

注意总的风险实际上因为项目中早期的一个或两次迭代而产生，因为项目研究小组在他们探究更多的推进项目的实际需求时还将发现商业风险，并且当他们考虑不同的可选择的解决途径时也将发现技术风险。显而易见，对技术性风险的关注引起了此点之后直线的下降。曲线上的拐点，即倾斜的曲线在这点改平，对应于技术风险已经远离的精化阶段的结束和构建阶段的开始时期。

度量进度在项目的早期开始也是很重要的。 图2展示了在项目生命周期中预期发展的轮廓。

图2：预期的项目进度概况

在图2中，灰色区域描绘的是正常预期可能存在的进度观测资料，而曲线图描绘是一个理想状态的进度轮廓图。在此例中，注意在先启阶段的某个进度（最初的一次或两次迭代），尽管改进缓慢，但仍需要做大量的重复性工作，就像技术方法被不断地测试和修改一样。

度量风险的降低

这是一个在项目早期显示风险列表是项目的一个普通实践，尽管很少项目在整个项目生命周期中保留这份列表。当项目开发团队和其他人一起回顾这份清单时，这份清单能够简化最高的十个风险以保证人们可以专注于最重要的那些风险。图3中展示了一个例子。

例3：最高十个风险的例子

选择的最高的十个风险是基于它们影响的次数（从1到10等级，1是最低影响，10是最高影响）和严重性（从1到10的等级，1是最低严重性10是最高严重性）。数字用来划分风险等级的，并用于给整个项目风险的降低以度量。为了有效地管理项目的期望风险的轮廓（展现所有风险的风险等级之和）在图1中已经展示。

如果总体风险从一次迭代到另一次迭代中没有降低，那么有些地方是出了问题的：多数情况下，降低风险的策略无效并且风险从一个迭代到另一个迭代中没有减少；或者新风险的增长速度超过了旧的风险的减少速度。在任何一种情况下，途径的改变是必需的。可能是开发小组缺乏减少技术风险的技术方面的经验，或者可能是项目应变的速度跟不上商业环境改变的速度。无论什么情况，一系列的迭代降低风险失败表明途径的重大改变是必需的。

度量进展状况

进展状况可以由一定数量已经被执行和成功测试过的特定场景来度量。最好是使度量方法简单，忽略实际上有些比较复杂的场景。正如您将在图2中注意到的那样，当技术问题被解决并且团队获得了与其他团队合作工作的经验时，进度曲线先是缓慢的上升。当项目进入构建阶段时，无论如何，项目应该拥有大量的动力和多产的迭代。那么在项目接近尾声时，进度等级会下降就像此项目被附上了绝笔一样。

平滑的进度曲线在图2中已经展示，该曲线源自积累的实现了的并成功地测试过的场景。但是实际上进度很少平滑向上的前进。当用一个迭代的方法时，尤其是当项目开发小组没有经历过迭代及增量的软件开发项目时，某些返工是可以预料的。新的想法会被采用或者被否决，当得到越来越多的信息时，新的解决方法就会出现。因此，当图2中的曲线表示全部进度时，伴随着偶尔的后退，一个很接近实际结果的审查将展现全部的进度，正如图4所示。

图4：进度中返工的影响

图4实际上表现的是极端的例子，随着时间而增多的返工，标志着一些运用的初始途径和开发小组的开发技巧很可能有潜在问题。它说明了评估全部进度和返工为什么很重要：为了创造出更符合实际情况的图表。正在执行的工作是一个真正的开发工作——分析、开发和测试场景；当执行的代码通过测试时就会产生进度结果。当发现执行的代码缺失和不完整时就会发生被该写的情况，从而导致一些执行的代码被废弃和改写(由此得到变化的根源)。图5显示了预期的返工贯穿了项目整个生命周期。

图5：返工贯穿项目的整个生命周期

注意到返工在前期阶段是十分重要的，但是在精化阶段末尾体系结构已经确定之后，它就会剧烈下降。

如上所述，返工一般起源于缺陷的发现，尽管它也会来源于请求的改变，并且缺陷应当在项目开始阶段就被发现。图6表现了典型缺陷的发展趋势。

图6：缺陷贯穿项目的生命周期的趋势

度量阶段的度量

度量阶段主要的焦点是勾画出在先启阶段解决方法和在精化阶段的“构架的”的草图。您要确定所有剩余的需求和发展测试解决方法。尽管有些粗糙的边缘需要平整化，但是在此阶段结束前您应该拥有一个可以运行操作的系统。

除了在精化阶段完成了的度量之外，还应该加上一些新的度量方法。

• 待完成工作的增长性和收缩率
• 测试覆盖率
• 构建的稳定性

项目待完成工作的度量

项目待完成工作包括所有您现在没有工作的东西。当需要完成新东西被确定时待完成工作 会增长，并且当那些东西被完成和检测之后它会收缩。当构建阶段开始运行时它仍然在不停地增长，说明有些地方出了毛病。在构建阶段的末尾，所有的场景应该被执行和测试，这就意味着待完成工作 在此阶段末尾必须衰减至零（或者完全关闭）。

通过宣告待完成工作中有些条目在未来的版本中被完成，待完成工作是可以被管理的，这意味着在现有的项目的待完成工作 中将被移出并且转移到将来版本的待完成工作 中。这通常需要风险利益者之间大量的商议，但是这也是管理待完成工作 通常所必须的。

度量测试覆盖率

在前面有关于项目评估的讨论中曾暗示过当项目被完全测试过以后才可以认为完成了工作这个概念。推荐的项目度量方法是一个完善的方案。有时候，很大程度上因为人员分配的问题，很难测试所有的已经完成的工作。当这种情况发生时，度量中两个事情是显而易见的：1）因为存在一种“测试待完成工作”，进度将降到期望的水平以下；2）测试覆盖率不会像其应该的那样快速增长。

当开发者完成他们的工作时，有些项目开发小组会在计算完成的场景个数时出错。犯这样的错误有如下几个原因：1）计算诸如完成的但实际上在测试中因为返工被拒绝的事件使项目进度膨胀2）那些可能因人手不够而不能完成测试的项目掩盖了事实真相。

当您不断前进时，您就需要不断地测试，不仅仅是单元的测试而且是整个方案的测试。如果您可以使用户测试改善的解决方案，那就更好了！您将得到非常有价值的信息反馈。测试可以时真正了解您是否做完某事的唯一途径。测试也始终揭示着那些需要做的事情，所以如果您没有跟上测试的成果您就落后了。当您评估测试结果时您也需要留意一下正在完成的工作的质量。失败的测试可能是您的进度没有想象中那样完美的迹象。

为确保过程度量不是虚拟膨胀的，保持测试的覆盖率——应该是100％覆盖到所有完成的场景。如果出现了一个覆盖率缺口，您就应该采取及时且有准备的措施尽快使它降低到零。

测试构建的稳定性

“构建”是当解决方案的代码被汇编并连接到这个系统的一个可执行版本时所产生的成效。有效的构建过程包括根据这个构建运行自动化的测试，来验证它能够正当地工作。这个构建的成效和自动化的测试产生了项目全面状况的有用测量方法。

图7显示了在连续时间内这个构建过程的成效

图7：构建状态随时间变化的趋势

图7中展示了在一段连续的时间内，已经成功完成并通过自动化测试的构建的百分率。这个曲线图显示，当许多天内这些构建都能成功地达到100％时，构建在接下来的时间里也会有很长一段时间的完全衰退，在这个时期末尾显示的结果十分不稳定。这表明变化的引进影响了许多小组成员，这些变化没有很好的沟通。这可能是一个更深奥的问题需要进一步研究。

在这个项目中构建的全面状况通常是许多其它问题的一个关键的指示器。如果一个小组不能产生稳定的构建，它就不能取得一定的进展。损坏的构建通常是有更糟糕问题的信号——有时是不充足的小组技巧，有时是一个有瑕疵的构架，有时是粗劣划分的工作。如果您正在进行迭代式的工作您就应该在频繁地构建，如果您真的在进行迭代式的工作，您应该已经在不断地构建。

来自连续的构建和自动化测试过程的度量将会让您对整个项目的过程和全面状况有一个非常好的了解。如果您有个连续的构建过程，您就可以在可被测试到的重大变化发生的任何时候进行构建，您将会有很多数据来评估过程。在一个典型的4－6周的迭代整个过程中，将达到数以千计的构建和自动化测试的执行次数，为您提供了相当多用来评估过程和全面状况的数据。

再次度量进度

正如上面所提到的，所有的计划中工作在构建阶段末尾时都要完成。这个项目的下一个也是最后阶段，产品化阶段，重点是将这个解决方案部署到一个生产环境中去。产品化阶段不应进入那个待完成工作 仍然在被处理的“清除”阶段。在部署一个应用软件时还有很多的工作需要做，这里没有时间继续实现场景。

在构建阶段需要回答的一个重要的问题是：“我们在此阶段结束之前能够完成所有的必要任务吗？”评估这个小组的生产力是十分重要的。您需要经常对这个小组的生产力和剩余的待完成工作 进行评估，从而决定它是否能降低到零。一个很有帮助且比较主观的度量方法是度量这个项目小组的“速度”，这是一个度量开发小组生产力的奇特的方法——在整个过程中它们能完成的工作量。您可以把速度理解为这个过程曲线的变化速率，或者是待完成工作增长或者收缩的速率。根据待完成工作 的增长或者收缩，您可以评估这个小组的生产力，并可以预言待完成工作 在这个阶段剩下的时间内是否会降低到零。如果这看起来不可能，您还有几个可选的方法：延长这个阶段的长度，或者协商待完成工作向下的范围。

总结

精化与构建阶段的相似之处在于，它们主要强调的都是产生可执行的代码；两者之间的不同之处在于它们对技术风险和构架问题的重视程度上。由于执行工作相似的原因，管理工作的方法也趋于相似，进一步强调了精化阶段对技术风险的重视程度。

在构建阶段，技术风险大大降低，此时的主焦点问题是“我们在此阶段结束之前能够完成所有的必要任务吗？”。因此，确定测试覆盖率，生产力以及过程的度量方法变成了这个小组的焦点。在构建的末尾阶段，待完成工作应该降低到零，解决方案在功能方面应该能够全部完成，从而产生一个最初的发布候选者。

这个系列的下一篇也是最后一篇文章中，我们将着眼于产品化阶段的度量方法，它主要强调这个解决方案发布的准备就绪。同时我们也会将注意力转移到对由多个项目组成的程序间交叉度量方法的问题上，包括管理包含有多个项目或者程序的业务。

进一步阅读

这篇文中是从最初呈现在由 Kurt Bittner 和 Ian Spence 编写，于2006年在出版的 Managing Iterative Software Development Projects 中抽取出来的。

注释

¹一个场景就是一个“思路”的观念贯穿了这个用例的全过程——即一个基本的信息流加上零或者更多备选的信息流。

参考资料

• 您可以参阅本文在 developerWorks 全球网站上的 英文原文。
• 您可以参阅 Rational Edge 电子月刊中文版 的其他文章。

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号