经典重读：什么是迭代化开发(3)管理视角

对一个项目来说迭代增量模式的工作意味着什么？在这一系列文章中，我们通过讨论关联于项目的不同视角对这个问题进行探讨。在本系列文章中，定义了迭代式增量开发模式的意义，并且讨论了这种方式对从事软件生产的核心开发团队意味着什么。然后侧重于当一个项目选择采用迭代式增量开发工作时，对客户意味着什么，最后探讨对项目管理团队来说迭代式增量开发的影响。

迭代和增量开发要求项目管理人将每次迭代看作是一个单独的项目，并在最终的交付环境中进行管理。本文是具有三个部分的系列文章中的最后一个部分，其中探究了关于项目和质量管理问题的适当视角如何引导开发团队走向成功。


对于一个项目来说，以迭代和增量的方式进行运作意味着什么？在本系列的文章中，我们通过分析涉及项目的各种视角来回答该问题。在第一篇文章中，我们定义了什么是我们所谓的迭代和增量开发，并分析了这种方式对生产软件的核心开发团队来说意味着什么。在 第二篇文章中，我们集中讨论了以迭代和增量方式运作项目对客户意味着什么。在这最后一部分中，我们考虑迭代和增量开发对项目管理团队的影响。

一旦您让那些在一系列共享的迭代工作中进行协作的业务和开发团队致力于将业务价值移交回业务中，您就需要考虑管理视角以及为什么它是重要的。

首先，设想一个缺乏管理指导的软件开发项目。（也许您已经参与过一个这样的项目)。这种项目经常缺少中长期的方针，前进的方向似乎按照随机路线，并且很少有团队成员知道他们努力的方向。不制定迭代，您很难知道项目什么时候完成、完成项目需要什么资源，或者什么时候需要这些资源。不估计产品的成本，很难使客户和赞助人为最平凡的项目提供资源，且不能显示出项目是如何朝着交付解决方案的目标前进的。

人们很容易陷入这样一种理想的思维困境，即如果一个团队受委托要达到一个目标，那么他们将自动地自行组织并实现他们对组织的所有承诺，且迅速有效地交付高质量的软件。事实上，甚至最好的团队也需要一些监督来确保日常的工作向长期的目标进展着。更重要的是，管理的任务是将能够进行这样工作的团队集合起来。

糟糕的管理从根本上导致许多项目的失败，这一点也不意外。1很容易令人相信的是（如许多非管理人员所想的）管理只不过是疏远官僚主义，管理人员的作用是在其他团队成员工作时阻止官僚主义。事实上，许多普通的管理是这样的。但是，如果所有的管理人员都这样做，那么项目将很可能失败。

管理不仅是记录意见、保持进度及考虑预算：提供领导能力和方针是达成结果所必要的。适当的管理为必要的问题提供清晰的答案：

－我们解决的问题是正确的吗？
－我们拥有交付解决方案的资源吗？
－我们现在是在处理正确的东西，朝着最终的目标进行着吗？
－我们是在欺骗自己，认为能在分配的时间和资源之内真正交付解决方案吗？

计划和测量不是到他们自身的终结，而是帮助管理人员回答这些问题的工具。

项目管理人员的视角
如我们在第一部分所讲的，一个迭代包含将软件开发的核心规程应用于生产出可证明的，可执行的开发后的产品，并确保在一系列的迭代后（每次都根据产品和由先前迭代而来的教训）产品会不断增进。这在图 3-1 中表现出来，依赖于第 1 部分的图 3 和第 2 部分的图 1 和 5 中所示的开发团队、业务分析员和客户的视角。

图 3-1：从项目管理人员的视角考虑的迭代项目

从项目管理人员的视角出发，每次迭代似乎是将软件开发的所有规程应用于生产满足具体的已达成协议的目标集合的产品的过程中的小型独立的项目。迭代是小型项目的视角与应用最普遍的项目定义一致，如：

项目：承担创建独特的产品、服务或结果的临时努力。2

迭代确实是临时的、延续两个到六个星期、3 并在迭代的可论证的发布中生产出独特的产品。

最简单地说，迭代计划过程是协定、执行和评估的循环：
1)对迭代的目标，包括评估标准、时间表和限制，与团队达成协议。
2)对团队将如何实现目标的计划达成协议。
3)执行计划。
4)根据最初的目标集和评估标准来评估团队的成就。
5)从整体上评估迭代结果对项目的影响。
6)开始下一次迭代。

从管理人员的视角出发，这些活动在整个项目中会不断地发生，如图 3-2 所示，并形成基本模式（可以按照这样的模式对关于迭代的工作进行计划和管理）。

图 3-2：从管理视角考虑的迭代

管理人员还从整体上为项目提出方针，并组织工作以便每次迭代都逐渐地对解决方案的交付做出贡献。要做到这点，他们必须从整体上计划、执行和评估项目，并将项目作为一系列连续的迭代进行组织。管理过程的两层之间的关系如图 3-3 所示。

图 3-3：整体的且迭代的项目管理过程

迭代和增量项目的计划、监控、控制及管理在以下方面，从根本上异于非迭代的项目：

-项目团队交互的动态性
-里程碑的特性
-对依赖的处理
-度量和测度
-必要的资源

项目工作的并行程度
最重要的区别之一是进展的度量方式。取代用中间工作产物（如需求文档、分析模型和设计规格）的完成来度量进展，我们根据开发和测试的方案的多少来度量进展。 如图 3-4 所示，每次迭代都将导致向解决方案的交付的可度量的发展。

图 3-4：度量成功测试的软件中的增量

从对进展的主管评价（经常根据生成的文档）到对进展的客观度量（通过生产软件的工作量来度量）的转移是迭代方法和更传统方法的最根本的区别。分析每次迭代结束时对进展的客观评价的趋势可以使项目管理人员控制项目并做出变更以提高项目成功的几率。

迭代可以使项目成为一系列更小的独立项目，每个项目都依赖于前一个项目的结果和性能。由每次迭代的结束时刻进行的评价所形成的反馈使您可以对下一个和所有后来的迭代调整计划。

质量管理人员的视角
这些常规的迭代评估提供了评价进展的机制。在这些局部的里程碑上，要根据目的和目标集由团队评估迭代计划中的进展。一个暗示是基于活动的状态报告（您所处理的内容是什么？）并不像基于成就的状态报告（您已经完成了什么？您接近到什么程度？）那么重要。利用迭代的方法，很难将事实隐藏很久。

事实上，这种测量活动而不是真实进展的方法只会引发问题。项目团队需要灵活地使他们的活动达到所期望的目标，项目管理人也许不能足够准确地预见未来，以计划所有用来实现目标的工作。更加开明且解放的做法是给予项目团队一些需要达到的目标，并授权给他们可以灵活地响应变更。 通过约束创造能力和响应性，详细的活动程度计划实际上会危及项目成功而不是确保成功。

在每次迭代过程中对项目结果的客观测量省掉了通过对中间产品的主观质量评估来对项目进展进行的评估。取代通过坚持在开始建立任何内容之前结束使用需求来判定需求的质量，您可以通过拿到第一批可用的需求并使他们通过开发循环，在迭代的过程中，生成工作和测试了的代码来评估需求。这为项目是否达到目标提供了客观的证据，因为他们将在实际中使用而不仅是用于称赞。度量质量的方法从根本上改变了。质量度量着重于常规的可以提供对项目的持续洞察的迭代评估。对过程和工作实践的回顾有规律地捕捉从项目中得到的经验，并在项目中造成一个持续的过程改进的文化。这些观察可以立即被应用到下一次的迭代中以提高质量和团队效率。

通过在每次迭代过程中测试生产出的版本、提供管理和质量指示器，以及测量项目进展来进行客观的度量。因为每次都要对前一次迭代交付的需求进行反复回归测试，所以这种不断的整合及测试导致了随着项目进展而不断增加的测试覆盖面，如图 3-5 所示。

图 3-5：在不断的迭代中测试负载在增长

对迭代方法的采用可以帮助提高由以下内容交付的成果的质量：
-通过将需求迅速地转变成可以进行观察测量的内容来尽早地减少对需求的误解
-通过检验技术方法来尽早地减少开发风险
－从项目的一开始就调节并控制变更

在项目的早期，还可以进行变更的时候，提供一种方式来评估过程效力、进度表、团队生产力，及资源是否充足

在迭代的方法中，质量管理人员集中于产品和过程的有用性，从整体上支持团队的效率。强调从完整性到“适合目标”的其中一项内容的质量变更。质量管理人必须放开这样的误解，即“停止产品并不再做变更会带来更高级别的质量。”

这并不意味着事情永远不完结 —— 只是要求项目团队不要考虑这样的完成，以便他们发挥积极减少项目风险的才能。

有一个普遍的误解，迭代开发从未真正完成工作，一些人将灵活的迭代项目视为要永远进行工作。这肯定不是真的。 对所有的迭代存在一个最终的目标：最终版本。每次迭代就像一面墙中砌好的一列砖：每次迭代都为达到筑墙的最终目标做出贡献，并且可以测量每次迭代对整体目标的贡献，就像可以测量每个砌好的砖列对整堵墙的贡献一样。

总结：从团队视角考虑的迭代
采用迭代和增量开发技术不是只影响到开发人员和其他涉及项目的技术人员的纯技术决策。它代表着设计和发展项目所采用的方式的根本变更，一个影响到每个参与项目的人的变更。因此迭代开发要求整个项目团队改变工作和交互的方式。同时，项目管理不再必要，这不是一个意义深远的变更。而是它简单地需要一种不同的更适应管理的方法。

迭代开发是针对问题解决和解决方案开发的基于团队的方法。它要求所有参与的人 —— 包括开发团队、客户团队，和管理团队 —— 都采用协作的技术。

从开发团队的视角出发，采用迭代和增量开发是需要授权的，并要求团队成员积极进取地用他们认为最适当的方式处理项目危机和难题。通过设置清晰的目标和客观地度量结果（但不指示活动）来管理迭代可以确保轻松地找到最佳的方式来交付成果。

从客户和业务团队的视角出发，引入清晰有意义的目标，并结合回顾可论证成果的能力，可以使那些最终使用新软件的人在项目中发挥积极作用，并与开发团队分享所有权。迭代对所有涉及项目的业务人员产生深远且长久的影响，并且从根本上改变了他们规定、支付，并实现软件解决方案商业利益的方式。

从管理团队的视角出发，每个项目都被分解为一系列小的项目，称为迭代，每个迭代都建立在前一个迭代的结果之上，并不断增加地实现项目的总目标。当授权开发团队创造革新的且有效的解决方案时，这种对项目的分割引入了常规的，可度量的，使项目保持正轨的里程碑，将项目成功的几率最大化。

结束
我们希望您对这篇关于迭代开发如何支持并有助于各种软件开发的参与者的简短分析感到满意。如您从这最后一篇文章中推测到的，我们坚信，好的管理是成功应用迭代方法所必要的部分。我们将在即将面世的书籍 Managing Iterative Software Development（今年后期由 Addison-Wesley 出版）中更深入地探究此话题。

注释
1例如在 http://www.standishgroup.com 查阅 The Standish Group 的年度 Chaos Report。
2依照 Process Management Body of Knowledge（PMBOK）。参见 http://www.pmi.org
3迭代的真正长度会随着项目中的人数而变化，也会随着解决方案的复杂度而变化。更大的项目团队需要更长的迭代来处理用来管理通信的复杂的事物。

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

作者简介
Ian Spence 是英国 Ivar Jacobson 咨询公司的首席科学家。他的主要任务是帮助那些创建并执行变更程序的客户提高软件开发水平。为达到此目的，他致力于 IBM Rational Unified Process ® 的大规模采用，以及 IBM Rational Unified Process 所推荐的迭代的、由用例驱动且为中央体系结构的方法。Ian 拥有软件行业方面的十八年经验，涵盖完整的软件生命周期，包括需求获取、体系结构构架、分析、设计、实现以项目管理。

Kurt Bittner 在 IBM Software Group 的 Rational 软件部门进行产品策略方面的工作。他已经为找出帮助团队开发软件的更好方法努力尝试了二十三年以上。他是原来的 RUP 开发团队中的一个成员，并在多种行业中领导开发团队。除了做软件开发的工作以外，他喜欢在休息时间攀爬冰冻的瀑布。

Ian 和 Kurt 合著了 Use Case Modeling（Kurt Bittner, Ian Spence -- Addison-Wesley, 2003），并且正共同书写着下一本书，即 Managing Iterative Software Development（在今年的后期将由 Addison-Wesley 出版），本系列的文章就取自该书。