级别： 初级 Anthony Crain, 过程专家，RUP 部署, IBM
2008 年 2 月 15 日 
审查是一种提高瀑布模型项目的质量的好方法。但对于迭代项目来说，我们想要短的周期来做该工作。这篇引人兴趣的文章重新考虑了迭代开发生命周期中审查的角色。
来自 The Rational Edge.
当软件开发团队或个体实践者从瀑布方法转移到迭代方法时，当参与迭代的生命周期时，他们趋向于进行太多的审查。
这是可以理解的。在瀑布型过程中，审查对成功是至关重要的，因为团队不重看较早开发的代码，也就是，他们不回到前面的“阶段”。同样，瀑布周期时段很长，以至于到下游发现错误的时候，作者常常不能帮忙 —— 即使他们可以时，他们已经忘记了工作是关于什么的！当您使用瀑布方法时，审查是对抗糟糕质量的唯一安全措施。
相反，迭代开发使用短周期（平均 3-9 周）。每个团队成员都是促成迭代的成功的角色，而不是促成他们自己的独立规程的完成的角色。这意味着，当在下游找到错误时，关键的成员不仅可用，而且他们还准备好，并且期望继续生命周期中早期开始的工作。
审查的本质
当开发人员审查东西时，他们倾向于不管他们看到的错误对于迭代的成功的重要性是多少都猛扑向任何微小的错误。他们不顾明智的古老格言“完美是良好的敌人”，因为审查似乎要求我们争取完美。然而，在短的迭代中，我们不是如此“熟虑的”，而更关注完成工作。当我们有关于上游工件的问题时，这些问题通常只会令事情变慢。
那么使用迭代方法的原则是：让迭代自己证明自己。允许可疑质量的事情进行。当实际使用时，就是我们将认识到它是否足够好的时候。
这里有另一个审查特性：当人被命令审查时，他们经常延迟，跳过审查，或快速但糟糕地进行审查。Michael Fagan 创造的，Fagan Inspection Process 用“Reader”角色喜剧性地改进了它，当正确执行时，需要工作产品的消费者来解释他们对工件每个部分的理解。通过大张旗鼓地做这些，许多否则可能错过的问题将被揭露。
该过程的天才之处是认识到了审查中的主要声音需要是下游的消费者 —— 也就是，最有动机确保工件质量的人，因为他们将不得不使用系统。对于迭代开发，原则是一样的，除了与其在转手之前审查工件，不如工件实际地立即投入使用，而作者在实际使用过程中仍旧在场改进它。这形成了最重要的改进，而不用许多额外的工作时间。
重新考虑审查
那么这意味着在迭代生命周期中不应该有任何审查吗？不，但进行的次数应该比大部分项目团队少得多，特别是如果团队的根源是瀑布型的方法。如果您真的接受迭代的方法，那么审查的数量应该被自动地减少。举例来说，如果迭代是六个星期长，您真正进行多少审查，而仍旧完成迭代的工作呢？
如果您相信审查可以提高关键工件的质量，好的，向您的过程添加该步骤。谨记在迭代开发中，创建计划来证明您的迭代通常是必要的。在初始阶段，我管理的项目展示出每个用例到每个构造迭代的映射，然后是将被编码和测试的具体流到每个精化迭代的第二个映射。
对于介意审查的项目团队，在初始阶段还有一个额外的步骤。他们需要将想要审查的每个工件映射到迭代。假设限制在每个迭代最多 0-3 个工件，那么三个审查对于六周的迭代将是繁重的。这么多的开销的前途是减少审查的数量，因而为审查的计划提供许多提示，并且确保正确的人参与。
在我熟练迭代开发之前，我也落入了频繁审查的圈套。在其他技术中，我受过 Fagan 的训练，并且已经从我的审查过程中看到很大好处。它让我相信接受“迭代将证明自己”。还需要智慧来找到正确的平衡，但一旦我工作的团队开始起步，就是难以置信的值得。
审查训练
有时，审查的目的是获得一致。一个实例是项目愿景，初始阶段的关键工件之一，在关键角色可以转移到初始阶段的进一步工作之前，必须对文档取得一致。愿景文档是初始过程中最大的风险减少因素，确保我们的迭代拥有一个它们工作，或改进的坚固范围。
与其用“审查”这个词，我们更愿意使用“训练”，例如，我们协作地与关键项目涉众创建高风险工件所在的愿景训练（Vision Workshop）。这类型工件可以被审查，但工件的协作创建确保质量比一般情况下的审查要好。当审查开始时，如果进行了，我们共享规格 —— 例如，“100 个项目涉众已经帮助形成这个愿景。”在审查时，只有五个人审查，而清楚的是，审查远不及联合进行强大。
结束语
审查是提高瀑布项目质量的好方法。但对于迭代项目来说，我们想要短的周期来做该工作。审查真的可以改善我们的过程，并且改善对我们的解决方案的可见性。但短迭代也会更好地完成那两件事情。有太多的审查对于从瀑布生命周期出来的团队来说是典型的，那些团队特别需要关注减少审查，并且相信迭代推动成功和质量。
参考资料 学习
讨论
- 参与论坛讨论。
- 现在开办了一个特别为 Rational Edge 的文章创办的 新论坛，现在您就可以分享您对本文或本期杂志或以前杂志中的其他文章的想法。阅读世界各地您的同行们所说的内容，生成您自己的讨论，或者加入正在进行的讨论。单击 这里 开始。
-
全球 Rational 用户组社区
关于作者  | 
| | Anthony Crain 是 IBM Rational Services Organization 的软件工程专家。除了帮助客户进行 IBM® Rational Unified Process®，或 RUP® 之外，他还用用例、面向对象的分析与设计（object-oriented analysis and design，OOAD）和 RUP 在需求管理方面培训工程师。他在 Motorola 学习了五年的 OOAD 和用例建模，然后在 Rational 磨练他的技能。他荣幸地毕业于 Northern Arizona University，获得计算机科学与工程的学士学位。 |
对本文的评价
| 
