|
什么是迭代化开发？－－第一部分：从开发人员的角度
对一个项目来说迭代增量模式的工作意味着什么？在这一系列文章中，我们通过讨论关联于项目的不同视角对这个问题进行探讨。在本系列文章中，定义了迭代式增量开发模式的意义，并且讨论了这种方式对从事软件生产的核心开发团队意味着什么。然后侧重于当一个项目选择采用迭代式增量开发工作时，对客户意味着什么，最后探讨对项目管理团队来说迭代式增量开发的影响。
本文为三篇连载之一，论述了软件开发项目团队成员如何进行迭代的，增量的工作方式。作者介绍了隐含在迭代式增量开发方案背后的理论基础，并探索了团队成员应用此类方法的经验。
“迭代的，增量的开发过程对于精确的业务解决方案的会聚是必须的”－准则5，动态系统开发方法论。项目管理论坛
一个以迭代化的、增量的工作方式的项目意味着什么？本系列文章论述了这个问题。我们首先定义“迭代化的，增量的开发”，然后，我们从几个通常采用的视角（项目管理，开发人员，用户等）对这种方法进行探索。澄清并阐明了迭代化的增量开发方式中的实际意义。项目经理博客
项目管理者联盟
本文第一部分着重于开发团队如何体验这种迭代化的生命周期。第二及第三部分，发表于下两期的 Rational Edge中，将分别探讨客户及管理团队的经验。
迭代和科学的方法转自项目管理者联盟
项目经理博客
在为一个问题开发解决方案的过程中包括很多活动行为。我们需要理解待解决的问题，为一个潜在的解决方案收集需求，将这些需求转换至设计中，构建解决方案，并对方案进行测试。这个顺序非常自然，并且在一般情况下是正确地。然而，当我们试图将规模扩大时－也就是说，当我们按照一个严格的线性流程试图搜集所有的需求，并完成所有的设计，所有的开发，进行所有的测试时，一些问题就悄悄地出现了。 项目管理者联盟
项目管理论坛
因此，我们需要更像科学家一样进行工作。现代的，科学的解决方案建立在如下直接观测准则上：提出理论，然后设计实验以验证这些理论。从这些标准的结果中，我们或者抛弃或者确认这些理论。 PgMp.mypm.net
项目管理者联盟
如何将这种方法应用于软件开发中？在某种意义上，在软件开发项目中的很多事物都是理论，或者更精确的说，论断是需要被评估的。计划本身是由许多关于事物需要多长时间以完成的论断组成。甚至需求也是关于适宜的解决方案特征的一种论断。正是因为即使一些涉众或是问题领域的专家表示需求是有效的也并不能代表他们是正确地。我们甚至需要评估需求以论断它们是否对手边的问题定义了正确的解决方案。 项目管理者联盟
项目管理者联盟
这引导我们采用这样的一种软件开发方式，计划内固有的论断通过系统演示版本的设计或开发进行重复的验证与评估，每一个均被客观的演示，以减少项目风险及建立另一个完整的解决方案。项目管理者联盟
这种开发方式通常被理解为迭代的增量开发过程，我们对其进行如下的定义：www.mypm.net
一种包括对一系列活动的重复应用以对一系列论断进行评估，解决一系列风险，达成一系列开发目标，并逐步增量地建立并完善一个有效的解决方案 。项目管理者联盟
项目管理者联盟
由于它通过对核心开发活动的重复应用，包括了对问题，解决方案定义以及解决方案实现的连续的细化，因此，它是一个迭代的过程。
由于在一次迭代运行的周期中，对问题的理解以及解决方案提供的功能均会增长，因此，它是一个增量的过程。 项目管理者联盟
项目管理者联盟
在迭代中，其中数个或更多的应用被连续地组织起来以构成一个完整的项目。项目管理者联盟
不幸的是，开发可以不包含增量而迭代地进行。例如，在一个迭代化的方式中，活动可以一遍又一遍地被采用，而并不能增长对问题的理解或是扩展解决方案，从迭代开始前的位置有效地进行分离。 项目管理者联盟
转自项目管理者联盟
它也可以实际上不包含迭代的，增量的过程。例如，一个大型解决方案的开发可以被分解为数个增量，而不包含对核心开发活动的重复应用。www.mypm.net
要在实际意义上更有效，开发必须同时采用迭代与增量。对于迭代化的，增量开发的需求要求我们在未知的世界中可预测地产生结果。既然我们不能寄希望于未知事物的消失，因此我们需要一种技术来控制它。迭代化的增量开发为我们提供了一种技术，这种技术使得我们可以控制这种未知，或至少可以从系统级别上将其充分地至于控制之下以达到我们所期望的效果。
迭代的经验
项目管理者联盟
如果你曾经浏览过方法学中描述的各种不同迭代化软件开发过程的文献，你就会发现对迭代的含义以及如何作出适宜的增量存在着各种不同的理解。这些趋向反应了作者在他们的项目中所处的角色以及在他们的项目团队，企业或同组中，被认为是最重要的，迭代化开发的各个独特方面。 training.mypm.net
各种潜在的不同的阐述是对各种工作于迭代化项目中的，不同的经验，对于在项目中不同的团队成员，它表现的极为不同。让我们来考虑对迭代化开发的采用是如何在软件开发项目中对常规准则发生影响的。 项目管理论坛
为了对原始材料进行组织，我们将准则分为三组进行探讨是极为有益的：
核心开发团队。他们集中于对需求所确认的解决方案进行明确表述与开发，包括对核心架构开发准则的应用，分析，设计，实现，3 以及测试，以便开发出高质量的的组件及方案。 项目管理者联盟
客户团队。 他们集中于对需要解决的问题进行定义，并构建（包括业务的修正）解决这些问题的事情。他们必须确保任何构建处的解决方案对组织都是充分有效的。 项目管理者联盟
管理团队。 它们集中于确保客户，业务以及开发目标的保持一致，正确地解决问题，为这些问题构建适合的解决方案并且保证开发在一个正确的，高效的，可控的方式下进行。
在本文的剩余部分以及接下来的两篇文章中，我们将从上面所概述的三个方面对迭代化开发过程做更进一步的阐述，并探讨迭代是如何帮助项目达到所有的目标以及它如何对项目所关联的所有人员产生作用。
从核心开发团队角度的迭代 talent.mypm.net
项目管理者联盟
让我们从核心开发团队的角度考虑项目动力。这个团队负责应用关于架构，分析，设计，实现，单元测试以及集成测试等方面的开发准则，以建立能够满足客户需求的系统发行版本。即使存在客户代表，或被永久指派为直接与开发团队协同工作的业务分析师，需求仍然被认为是客户团队的职责。（我们将在下一篇文章中探讨从客户团队角度的迭代）
开发人员视角项目管理者联盟
项目管理者联盟
对迭代化的增量式开发的看法通常来自小型开发团队中的各个开发者的角度。毕竟，这是来自技术团体的观点，这类观点构成了关于迭代化，增量式开发的大部分文献。同时，它们也为这些实践方法的采用提供了很大推动力。 项目管理者联盟
blog.mypm.net
我们中的一位同事近来参加了一个关于软件开发的研讨会。主题是关于使用特定迭代开发环境的迭代化开发。项目管理者联盟
项目管理者联盟
很显然的，报告者探讨了对迭代化应用的一种迭代方式，一遍又一遍重复地采用“编写测试部分，编写程序代码，测试程序代码，修正程序代码”的周期，直至完成各个部分，并使单元测试代码可用，以使其能够包含到一个发布版本中。虽然这些“开发”活动包含了许多被迭代化开发支持者所建议的，最好的实行方式（例如测试优先，频繁测试等），然而他们所描述的这种应用将会导致一个非常紧密的迭代，这种迭代的持续时间通常以分钟来测量。 项目管理者联盟
项目管理者联盟
将迭代看作一个单一开发人员“编写测试部分，编写程序代码，测试程序代码，修正程序代码”的生命周期似乎与经典管理学的，将迭代看作一个由一组开发人员的小型项目的观点相抵触。它代表了一种很自我的迭代开发观点，仅关注单独个体的贡献而忽略了团队的作用。它也与我们下面将要讨论的，更广阔的团队领导者的观点角度相冲突。 项目管理者联盟
项目管理者联盟
正如研讨会中报告者所描述的那样，这种紧密的，迭代的周期阐明了开发者在迭代化增量开发项目中所采用的，最自然的方式。单独的开发人员遵从他们自己的节奏，使得传统的分析，设计及实现阶段开始变得模糊，并且，他们的日常活动在他们自己的方式下进行。在任何一个时间，各个开发者做出无数战术上的决定以作为系统软件组成或改写的一部分。各个开发者的活动试图在共享事件周围被同步起来，例如日常构建或是系统集成点。团队活动试图集中在架构工作，接口定义以及组件的再分解上。 项目管理者联盟
www.mypm.net
一旦开发者正确理解了他们职责的限制以及他们当前的目标，典型地，他们将挽起袖子，开始进行他们可以做的任何工作以完成他们的责任，并交付将一个或数个工作组件以将其集成入发布版本中。每个单独的开发人员（或一对开发者，如果采用对偶程序设计的方式）将在项目所采用的流程框架中发展自己的工作方式。
进展以及产品堆积club.mypm.net
项目管理者联盟
单独的开发者很少会对非技术性事物感兴趣，例如效益实现，投资回报或是风险管理。他们以构建出实际可运行的产品来完成自己的工作。开发者通过选择一组需求并变更请求以进行分析，设计，实现，构造，单元测试，然后将其集成入产品发行中以进行自己的工作。开发者对分析，设计，实现，准则应用的重叠特性显示于图1-1 中。开发人员的迭代过程的时间及规模从数个小时，数日，直至数周而不同，这取决于所进行工作的规模与复杂度。
图1-1：从开发人员角度进行的迭代
开发人员将继续依照这种方式进行工作，选择并实现一小部分的需求，从他们的显要任务列表中对请求做出改变，直至他们已经完成了分配给他们的所有工作条目。项目管理者联盟
从开发人员的角度，迭代化增量开发中的增量部分在所发行产品中持续增长的完整性以及功能的丰富方面表现的很明显。有希望地是，这与被等待实现的需求或请求变更的数量变得越来越小形成对比。重要的需求以及变更请求列表经常会在产品堆积中被找到，4 －－这代表了等待被完成的堆积的工作。每天，开发人员从产品堆积中取走更多的条目，每天，产品构造包括更多的实现条目，并且每天都有一些新的工作会被添加到产品堆积中。这种日常的，通过产品堆积进行工作的增量过程示于图1-2中。
图1-2：增量地处理产品堆积
这种以开发者为中心的解决方案对那种开发者能够紧密的协作，并且所开发组件间的交互极为松散的小型团队，或是基于公用代码基础进行开发，例如开源项目的大型团队来说可以很好地运行。当规模上升至对于组件间具有强交互性的大型项目来说－在大型开发项目中是很典型的－额外的考虑视角是必须的。 talent.mypm.net
blog.mypm.net
开发团队领导者视角 转自项目管理者联盟
项目管理者联盟文章
与单独的开发人员不同，开发团队的领导者关注于多个开发人员的协作以及优化，为了完成整个团队公共的目标，每个开发者均要修正或实现多个将要集成到发行产品中的组件。转自项目管理者联盟
|
