经典重读：什么是迭代化开发(1)从开发人员角度

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

本文为三篇连载之一，论述了软件开发项目团队成员如何进行迭代的，增量的工作方式。作者介绍了隐含在迭代式增量开发方案背后的理论基础，并探索了团队成员应用此类方法的经验。

“迭代的，增量的开发过程对于精确的业务解决方案的会聚是必须的”－准则5，动态系统开发方法论。
一个以迭代化的、增量的工作方式的项目意味着什么？本系列文章论述了这个问题。我们首先定义“迭代化的，增量的开发”，然后，我们从几个通常采用的视角（项目管理，开发人员，用户等）对这种方法进行探索。澄清并阐明了迭代化的增量开发方式中的实际意义。
本文第一部分着重于开发团队如何体验这种迭代化的生命周期。第二及第三部分，发表于下两期的 Rational Edge中，将分别探讨客户及管理团队的经验。

迭代和科学的方法
在为一个问题开发解决方案的过程中包括很多活动行为。我们需要理解待解决的问题，为一个潜在的解决方案收集需求，将这些需求转换至设计中，构建解决方案，并对方案进行测试。这个顺序非常自然，并且在一般情况下是正确地。然而，当我们试图将规模扩大时－也就是说，当我们按照一个严格的线性流程试图搜集所有的需求，并完成所有的设计，所有的开发，进行所有的测试时，一些问题就悄悄地出现了。
因此，我们需要更像科学家一样进行工作。现代的，科学的解决方案建立在如下直接观测准则上：提出理论，然后设计实验以验证这些理论。从这些标准的结果中，我们或者抛弃或者确认这些理论。
如何将这种方法应用于软件开发中？在某种意义上，在软件开发项目中的很多事物都是理论，或者更精确的说，论断是需要被评估的。计划本身是由许多关于事物需要多长时间以完成的论断组成。甚至需求也是关于适宜的解决方案特征的一种论断。正是因为即使一些涉众或是问题领域的专家表示需求是有效的也并不能代表他们是正确地。我们甚至需要评估需求以论断它们是否对手边的问题定义了正确的解决方案。
这引导我们采用这样的一种软件开发方式，计划内固有的论断通过系统演示版本的设计或开发进行重复的验证与评估，每一个均被客观的演示，以减少项目风险及建立另一个完整的解决方案。
这种开发方式通常被理解为迭代的增量开发过程，我们对其进行如下的定义：
一种包括对一系列活动的重复应用以对一系列论断进行评估，解决一系列风险，达成一系列开发目标，并逐步增量地建立并完善一个有效的解决方案 。
由于它通过对核心开发活动的重复应用，包括了对问题，解决方案定义以及解决方案实现的连续的细化，因此，它是一个迭代的过程。
由于在一次迭代运行的周期中，对问题的理解以及解决方案提供的功能均会增长，因此，它是一个增量的过程。
在迭代中，其中数个或更多的应用被连续地组织起来以构成一个完整的项目。
不幸的是，开发可以不包含增量而迭代地进行。例如，在一个迭代化的方式中，活动可以一遍又一遍地被采用，而并不能增长对问题的理解或是扩展解决方案，从迭代开始前的位置有效地进行分离。
它也可以实际上不包含迭代的，增量的过程。例如，一个大型解决方案的开发可以被分解为数个增量，而不包含对核心开发活动的重复应用。
要在实际意义上更有效，开发必须同时采用迭代与增量。对于迭代化的，增量开发的需求要求我们在未知的世界中可预测地产生结果。既然我们不能寄希望于未知事物的消失，因此我们需要一种技术来控制它。迭代化的增量开发为我们提供了一种技术，这种技术使得我们可以控制这种未知，或至少可以从系统级别上将其充分地至于控制之下以达到我们所期望的效果。

迭代的经验
如果你曾经浏览过方法学中描述的各种不同迭代化软件开发过程的文献，你就会发现对迭代的含义以及如何作出适宜的增量存在着各种不同的理解。这些趋向反应了作者在他们的项目中所处的角色以及在他们的项目团队，企业或同组中，被认为是最重要的，迭代化开发的各个独特方面。
各种潜在的不同的阐述是对各种工作于迭代化项目中的，不同的经验，对于在项目中不同的团队成员，它表现的极为不同。让我们来考虑对迭代化开发的采用是如何在软件开发项目中对常规准则发生影响的。
为了对原始材料进行组织，我们将准则分为三组进行探讨是极为有益的：

核心开发团队。他们集中于对需求所确认的解决方案进行明确表述与开发，包括对核心架构开发准则的应用，分析，设计，实现，3 以及测试，以便开发出高质量的的组件及方案。
客户团队。 他们集中于对需要解决的问题进行定义，并构建（包括业务的修正）解决这些问题的事情。他们必须确保任何构建处的解决方案对组织都是充分有效的。
管理团队。 它们集中于确保客户，业务以及开发目标的保持一致，正确地解决问题，为这些问题构建适合的解决方案并且保证开发在一个正确的，高效的，可控的方式下进行。

在本文的剩余部分以及接下来的两篇文章中，我们将从上面所概述的三个方面对迭代化开发过程做更进一步的阐述，并探讨迭代是如何帮助项目达到所有的目标以及它如何对项目所关联的所有人员产生作用。

从核心开发团队角度的迭代
让我们从核心开发团队的角度考虑项目动力。这个团队负责应用关于架构，分析，设计，实现，单元测试以及集成测试等方面的开发准则，以建立能够满足客户需求的系统发行版本。即使存在客户代表，或被永久指派为直接与开发团队协同工作的业务分析师，需求仍然被认为是客户团队的职责。（我们将在下一篇文章中探讨从客户团队角度的迭代）

开发人员视角
对迭代化的增量式开发的看法通常来自小型开发团队中的各个开发者的角度。毕竟，这是来自技术团体的观点，这类观点构成了关于迭代化，增量式开发的大部分文献。同时，它们也为这些实践方法的采用提供了很大推动力。
我们中的一位同事近来参加了一个关于软件开发的研讨会。主题是关于使用特定迭代开发环境的迭代化开发。
很显然的，报告者探讨了对迭代化应用的一种迭代方式，一遍又一遍重复地采用“编写测试部分，编写程序代码，测试程序代码，修正程序代码”的周期，直至完成各个部分，并使单元测试代码可用，以使其能够包含到一个发布版本中。虽然这些“开发”活动包含了许多被迭代化开发支持者所建议的，最好的实行方式（例如测试优先，频繁测试等），然而他们所描述的这种应用将会导致一个非常紧密的迭代，这种迭代的持续时间通常以分钟来测量。
将迭代看作一个单一开发人员“编写测试部分，编写程序代码，测试程序代码，修正程序代码”的生命周期似乎与经典管理学的，将迭代看作一个由一组开发人员的小型项目的观点相抵触。它代表了一种很自我的迭代开发观点，仅关注单独个体的贡献而忽略了团队的作用。它也与我们下面将要讨论的，更广阔的团队领导者的观点角度相冲突。
正如研讨会中报告者所描述的那样，这种紧密的，迭代的周期阐明了开发者在迭代化增量开发项目中所采用的，最自然的方式。单独的开发人员遵从他们自己的节奏，使得传统的分析，设计及实现阶段开始变得模糊，并且，他们的日常活动在他们自己的方式下进行。在任何一个时间，各个开发者做出无数战术上的决定以作为系统软件组成或改写的一部分。各个开发者的活动试图在共享事件周围被同步起来，例如日常构建或是系统集成点。团队活动试图集中在架构工作，接口定义以及组件的再分解上。
一旦开发者正确理解了他们职责的限制以及他们当前的目标，典型地，他们将挽起袖子，开始进行他们可以做的任何工作以完成他们的责任，并交付将一个或数个工作组件以将其集成入发布版本中。每个单独的开发人员（或一对开发者，如果采用对偶程序设计的方式）将在项目所采用的流程框架中发展自己的工作方式。

进展以及产品堆积
单独的开发者很少会对非技术性事物感兴趣，例如效益实现，投资回报或是风险管理。他们以构建出实际可运行的产品来完成自己的工作。开发者通过选择一组需求并变更请求以进行分析，设计，实现，构造，单元测试，然后将其集成入产品发行中以进行自己的工作。开发者对分析，设计，实现，准则应用的重叠特性显示于图1-1 中。开发人员的迭代过程的时间及规模从数个小时，数日，直至数周而不同，这取决于所进行工作的规模与复杂度。


图1-1：从开发人员角度进行的迭代

开发人员将继续依照这种方式进行工作，选择并实现一小部分的需求，从他们的显要任务列表中对请求做出改变，直至他们已经完成了分配给他们的所有工作条目。
从开发人员的角度，迭代化增量开发中的增量部分在所发行产品中持续增长的完整性以及功能的丰富方面表现的很明显。有希望地是，这与被等待实现的需求或请求变更的数量变得越来越小形成对比。重要的需求以及变更请求列表经常会在产品堆积中被找到， ⁴ －－这代表了等待被完成的堆积的工作。每天，开发人员从产品堆积中取走更多的条目，每天，产品构造包括更多的实现条目，并且每天都有一些新的工作会被添加到产品堆积中。这种日常的，通过产品堆积进行工作的增量过程示于图1-2中。

图1-2：增量地处理产品堆积

这种以开发者为中心的解决方案对那种开发者能够紧密的协作，并且所开发组件间的交互极为松散的小型团队，或是基于公用代码基础进行开发，例如开源项目的大型团队来说可以很好地运行。当规模上升至对于组件间具有强交互性的大型项目来说－在大型开发项目中是很典型的－额外的考虑视角是必须的。
开发团队领导者视角
与单独的开发人员不同，开发团队的领导者关注于多个开发人员的协作以及优化，为了完成整个团队公共的目标，每个开发者均要修正或实现多个将要集成到发行产品中的组件。
从开发团队领导者的角度来看，迭代并不仅仅是一个包括分析，设计以及实现的核心开发活动的周期。迭代是一个有代表性的小型项目，以得到软件产品的有意义的新发布版本。
图1-3说明了如何利用一组独立的开发人员的工作来制造一个完整的发行产品，并使得所产生的改进请求以及需求定型的反馈对下一次迭代发生作用，并将其包含到下一次发行版本中。

图1-3：从开发团队领导者角度的迭代(引自Agile and Iterative Development, A Manager's Guide, by Craig Larman, Addison-Wesley, 2004.)

迭代的目的是将整个开发团队的工作集成到一个稳定的，完整的，可测试的系统发行版本中。对大多数迭代来说，这些发布版本为内部发布－主要为开发团队所建立的基线，并且为迭代以及对所做出的进展进行度量提供关闭条件。这些只是内部发布版本，而并不是为用户所开发的。
典型地，在软件公共发布版本之前，存在着三次或更多次的迭代。在此序列中的每次迭代过程审查系统发布产品，从第一次迭代中的小型的，部分实现的系统，通过一次又一次地迭代，逐次增长地实现更多需求，直至产生出最终地客户发布版本。图1-3距离说明了代表产品发布的每次循环中的增长幅度。

将开发者及团队领导者视角相关联
对于许多开发者来说，迭代的增量开发是一个通过无穷级数的迭代进展过程，每一次迭代都会是系统变得更庞大，直至客户对其满意，或是决定停止对后续开发的投资。从这个角度来说，只要工作在持续进行，并且能够对产品做出持续改正，项目就在继续发展中。
从团队领导者角度来说，为了能够有所进展，数个开发者的工作必须被联合并集成在一起，或者可以成功的协同工作。图1-4表明了这种整体的，在多个迭代中对于项目进展的开发团队的观点。



图1-4：每次迭代与前一次迭代相比，均生成了更完整的发布版本。

在图1-4中，项目进展以开发团队对完整的，可运行的发布版本的完成情况所度量，而不是采用对规范说明或其他文档的完成情况。在每一迭代中，应用软件的完成情况通过对完整应用中可以被展示的已完成的需求条目来计算，着重于对一个可运行的产品发布版本，而并不是一组项目文档或是还未被集成的组件。
对团队的进展需要对完整的发布版本作为一个整体来考虑，这一点是极为重要的。我们见证了着数个这样的真实项目，其中大量的组件被开发者所建立并测试，然而却不能被集成进一个甚至仅仅是部分完成的产品。在这些案例中，显示于图1-4中的项目视图从未发生过，因为并不存在任何客观凭证以证实对这种已完成的的项目做出了任何进展。

计划制定的需要
为了集成多个开发人员的工作，需要完成数个计划编制。首先，需要将工作以最小化开发人员间相互依赖的方式分配给开发者，采用这种方式，即使开发者确实需要依赖于另外一个开发人员，他们也可以在一定程度上独立地进行开发工作。
第二，他们必须采用一种方案以对他们的相互依赖关系达成一致；例如他们必须对组件，函数调用以及参数等的命名保持一致。随着依赖关系数目的增长，团队最终会达到这样一个点，在这个点上团队成员间非正式沟通也许需要使用开发人员间一致约定的记录。

当复杂性增加时，并且，随着为了使团队间成员有效协作而需要做出的努力变得越来越复杂，团队领导将需要一种能够确定什么工作需要完成以及以什么顺序完成的方法。这带动了对更规范的计划制定的需求，这也依次导致了对预算的需求。由于时间计划不能再简单的通过对非常复杂的组件（这种情况中，所有组件都是不互相依赖的）预估开发时间，或是对所有组件（这种情况中，所有组件相互依赖，他们仅可以依次的对其进行工作）的开发时间求和的方式所决定，在不同开发者的组件间存在着相互依赖，这也导致了对更规范计划制定的需求。必须要理解组件之间的依赖关系以建立一个有效的时间计划方案。

迭代化的开发有时被认为在很短的时间上执行，以至于不需要进行计划制定或预估。这种观点是不正确的；这有点像既然说我们在一个时刻仅仅进行一步活动，我们完全可以对下一步应该转向哪里做出连续的决定，因此我们没有必要计划我们的路线。如果你并不关心你将会在哪里结束，这种策略可以很好的运行，然而人们对项目有所付出时，他们当然对项目将要达成的目标有所期望。

计划以及预估基本上是这样一种机制，首先，决定项目值得去做，然后作为一种方案，保持项目始终处于轨道中。至少，在某种程度上，很少有人会在不知道花费或是不知道持续时间的情况下雇佣某人以修整他们的房屋。软件开发项目也没有区别，为项目投资的人需要知道这个项目的开销以及结束时间。这都需要计划与预估。在下两篇文章中，当我们从客户以及团队管理的角度进行探讨时，我们还将返回到这个主题。

结论
为了理解如何能够达到迭代化的，增量的开发过程所保证的优点，正确认识它是如何影响到项目相关的所有人是很重要的。在本篇文章中，我们可以看到迭代化开发是如何影响到软件生产人员，即核心开发团队成员的，但是这仅仅是项目所关联的一部分人员。如果你们想使迭代化项目真实地产生效果，你们还必须理解迭代化的，增量的开发过程是如何影响到其他成员的，同样重要的，还要包括项目的其它领域：客户以及管理者。
我们还将在下两篇文章中探讨这两个观点，采用迭代化的，增量的工作方式是如何影响到客户以及管理者。

注释
¹ 更多的关于Dynamic Systems Development Methodology, 或者 DSDM, 请见 http://www.gamcom.com/dsdmoverview.htm
² 核心的规律是关于项目管理，需求，分析，设计，实施，测试，开发，配置管理和变更管理。
³ 通过本系列我们将会使用“实施”来指开发的规律。
英文原文

作者简介
Lan Spence为Ivar Jacobson Consulting UK的首席科学家。他的主要职责是为建立并运行软件改造以提高他们软件开发能力的客户提供帮助。最后，他专门研究IBM Rational Unified Process的大规模应用，用例驱动，以及所推荐的架构中心解决方案。Lan有着超过18年的软件工业经验，涵盖完整的开发周期，包括需求捕获，架构，分析，设计，实现，以及项目管理。 

Kurt Bittner为IBM软件组，Rational软件部门的产品策略进行工作。他已经为找出能够帮助团队软件开发的更好的方法工作了20多年。他是original RUP开发团队的成员，并且在不同的工业界中领导开发关对。当不需要进行软件开发工作时，他喜欢通过攀爬冰瀑的方法进行放松。

Ian和Kurt合作编写了Use Case Modeling (Kurt Bittner, Ian Spence -- Addison-Wesley 2003) 并且他们正在合作进行下一本书籍的编写，本系列文章便是摘自这本书。