3'.什么是迭代化开发？

在迭代中，其中数个或更多的应用被连续地组织 起来以构成一个完整的项目。 不幸的是，开发可以不包含增量而迭代地进行。
• 例如，在一个迭代化的方式中，活动可以一遍又一遍 地被采用，而并不能增长对问题的理解或是扩展解决 方案，从迭代开始前的位置有效地进行分离。

它也可以实际上不包含迭代的，增量的过程。

由于时间计划不能再简单的通过对非常复杂的组件（这种 情况中，所有组件都是不互相依 赖的）预估开发时间， 或是对所有组件（这种情况中，所有组件相互依赖，他们 仅可以依次的对其进行工作）的开发时间求和的方式所决 定，在不同开发者的组件间 存在着相互依赖，这也导致 了对更规范计划制定的需求。必须要理解组件之间的依赖 关系以建立一个有效的时间计划方案。
• 例如，一个大型解决方案的开发可以被分解为数个增 量，而不包含对核心开发活动的重复应用。




要在实际意义上更有效，开发必须同时采用迭代 与增量。 对于迭代化的，增量开发的需求要求我们在未知 的世界中可预测地产生结果。 既然我们不能寄希望于未知事物的消失，因此我 们需要一种技术来控制它。 迭代化的增量开发为我们提供了一种技术，这种 技术使得我们可以控制这种未知，或至少可以从 系统级别上将其充分地至于控制之下以达到我们 所期望的效果。
为了降低风险，应采用迭代方式递进开发。每次迭 代完成都会发布一个可执行文件
在瀑布式生命周期中，只有到生命周期 的后期才能确知周围是否存在风险
在迭代式生命周期中，您需要根据主要风 险列表选择要在迭代中开发的新的增量内 容。每次迭代完成时都会生成一个经过测 试的可执行文件，这样就可以核实是否已 经降低了目标风险
迭代的经验



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


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



为了集成多个开发人员的工作，需要完成数个计划编制。首先，需要 将工作以最小化开发人员间相互依赖的方式分配给开发者，采用这种 方式，即使开发者确实需要依赖于另外一个开发人员，他们也可以在 一定程度上独立地进行开发工作。 第二，他们必须采用一种方案以对他们的相互依赖关系达成一致；例 如他们必须对组件，函数调用以及参数等的命名保持一致。随着依赖 关系数目的增长，团队最终会达到这样一个点，在这个点上团队成员 间非正式沟通也许需要使用开发人员间一致约定的记录。 当复杂性增加时，并且，随着为了使团队间成员有效协作而需要做出 的努力变得越来越复杂，团队领导将需要一种能够确定什么工作需要 完成以及以什么顺序完成的方 法。这带动了对更规范的计划制定的 需求，这也依次导致了对预算的需求。
开发人员视角


对迭代化应用的一种迭代方式，一遍又一遍重复 地采用“编写测试部分，编写程序代码，测试程 序代码，修正程序代码”的周期，直至完成各个 部分，并使单元测试代码可用，以使其能够包含 到一个发布版本中。 虽然这些“开发”活动包含了许多被迭代化开发 支持者所建议的，最好的实行方式（例如测试优 先，频繁测试等），然而他们所描述的这种应用 将会导致一个非常紧密的迭代，这种迭代的持续 时间通常以分钟来测量。



与单独的开发人员不同，开发团队的领导者关注 于多个开发人员的协作以及优化，为了完成整个 团队公共的目标，每个开发者均要修正或实现多 个将要集成到发行产品中的组件。 从开发团队领导者的角度来看，迭代并不仅仅是 一个包括分析，设计以及实现的核心开发活动的 周期。迭代是一个有代表性的小型项目，以得到 软件产品的有意义的新发布版本。 图1-3说明了如何利用一组独立的开发人员的工 作来制造一个完整的发行产品，并使得所产生的 改进请求以及需求定型的反馈对下一次迭代发生 作用，并将其包含到下一次发行版本中。
从开发团队领导者角度的迭代


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





允许变更需求。 逐步集成元素。 及早降低风险。多数风险在过去只能到集成阶段才被处理 或发现 有助于组织学习和提高。 提高复用性，因为分部分设计或实施比起预先确定所有共 性更容易确定公用部分。 生成性能更强壮的产品，因为在多次迭代中您总是不断地 纠正错误。 容许产品进行战术改变；例如同现有的同类产品竞争。 迭代流程自身可在进行过程中得到改进和精炼。




它代表了一种很自我的迭代开发观点，仅关注单独个体的 贡献而忽略了团队的作用。 它也与要讨论的，更广阔的团队领导者的观点角度相冲突。 单独的开发人员遵从他们自己的节奏，使得传统的分析， 设计及实现阶段开始变得模糊，并且，他们的日常活动在 他们自己的方式下进行。 在任何一个时间，各个开发者做出无数战术上的决定以作 为系统软件组成或改写的一部分。 各个开发者的活动试图在共享事件周围被同步起来，例如 日常构建或是系统集成点。团队活动试图集中 在架构工 作，接口定义以及组件的再分解上。




因此，我们需要更像科学家一样进行工作。现代的，科学 的解决方案建立在如下直接观测准则上： • 提出理论，然后设计实验以验证这些理论。从这些标 准的结果中，我们或者抛弃或者确认这些理论。 如何将这种方法应用于软件开发中？ 在某种意义上，在软件开发项目中的很多事物都是理论， 或者更精确的说，论断是需要被评估的。 计划本身是由许多关于事物需要多长时间以完成的论断组 成。 甚至需求也是关于适宜的解决方案特征的一种论断。
什么是迭代化开发？
牛顿迭代求秋方程的根
瀑布式开发的问题
需求分析
需求要完备，谁参与？ 设计不允许出问题，谁参与？
概要设计
设计不允许出问题
详细设计
发现问题怎么办？
测试
发布
参照控制学理论

开环控制 闭环控制
开环控制
闭环控制系统
比较
开环控制系统
瀑布式开发
迭代式开发
闭环控制系统
瀑布式开发
迭代式开发

我们对其进行如下的定义：
• 一种包括对一系列活动的重复应用以对一系列论断进 行评估，解决一系列风险，达成一系列开发目标，并 逐步增量地建立并完善一个有效的解决方案 。 • 由于它通过对核心开发活动的重复应用，包括了对问 题，解决方案定义以及解决方案实现的连续的细化， 因此，它是一个迭代的过程。 • 由于在一次迭代运行的周期中，对问题的理解以及解 决方案提供的功能均会增长，因此，它是一个增量的 过程。



正是因为即使一些涉众或是问题领域的专家表示 需求是有效的也并不能代表他们是正确地。我们 甚至需要评估需求以论断它们是否对手边的问题 定义了正确的解决方案。 这引导我们采用这样的一种软件开发方式，计划 内固有的论断通过系统演示版本的设计或开发进 行重复的验证与评估，每一个均被客观的演示， 以减少项目风险及建立另一个完整的解决方案。 这种开发方式通常被理解为迭代的增量开发过程，

管理团队。
• 它们集中于确保客户，业务以及开发目标的保持一致， 正确地解决问题，为这些问题构建适合的解决方案并 且保证开发在一个正确的，高效的，可控的方式下进 行。
从核心开发团队角度的迭代


这个团队负责应用关于架构，分析，设计， 实现，单元测试以及集成测试等方面的开 发准则，以建立能够满足客户需求的系统 发行版本。 即使存在客户代表，或被永久指派为直接 与开发团队协同工作的业务分析师，需求 仍然被认为是客户团队的职责。



从开发人员的角度，迭代化增量开发中的增量部 分在所发行产品中持续增长的完整性以及功能的 丰富方面表现的很明显。 有希望地是，这与被等待实现的需求或请求变更 的数量变得越来越小形成对比。 重要的需求以及变更请求列表经常会在产品堆积 中被找到，－－这代表了等待被完成的堆积的工 作。每天，开发人员从产品堆积中取走更多的条 目，每天，产品构造包括更多的实现条目，并且 每天都有一些新的工作会被添加到产品堆积中。 这种日常的，通过产品堆积进行工作的增量过程
进展以及产品堆积

单独的开发者很少会对非技术性事物感兴 趣，
• 例如效益实现，投资回报或是风险管理。


他们以构建出实际可运行的产品来完成自 己的工作。 开发者通过选择一组需求并变更请求以进 行分析，设计，实现，构造，单元测试， 然后将其集成入产品发行中以进行自己的 工作。
开发者对分析，设计，实现，准则应用 的重叠特性
信息集随着各开发阶段逐步演进
迭代和科学的方法

在为一个问题开发解决方案的过程中包括很多活 动行为。
• 我们需要理解待解决的问题，为一个潜在的解决方案 收集需求， • 将这些需求转换至设计中，构建解决方案， • 并对方案进行测试。

这个顺序非常自然，并且在一般情况下是正确地。 然而，当我们试图将规模扩大时－也就是说，当 我们按照一个严格的线性流程试图搜集所有的需 求，并完成所有的设计，所有的开发，进行所有 的测试时，一些问题就悄悄地出现了。
每次迭代与前一次迭代相比，均生成了更完整的发布版本


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

ห้องสมุดไป่ตู้
一旦开发者正确理解了他们职责的限制以 及他们当前的目标，典型地，他们将挽起 袖 子，开始进行他们可以做的任何工作以 完成他们的责任，并交付将一个或数个工 作组件以将其集成入发布版本中。 每个单独的开发人员（或一对开发者，如 果采用对 偶程序设计的方式）将在项目所 采用的流程框架中发展自己的工作方式。

这种以开发者为中心的解决方案对那种开 发者能够紧密的协作，并且所开发组件间 的交互极为松散的小型团队，或是基于公 用代码基础进行开发，例如开源项目的大 型团队来说可以很好地运行。当规模上升 至对于组件间具有强交互性的大型项目来 说－在大型开发项目中是很典型的－额外 的考虑视角是必须的。
开发团队领导者视角


为了对原始材料进行组织，我们将准则分为三组 进行探讨是极为有益的： 核心开发团队。
• 他们集中于对需求所确认的解决方案进行明确表述与 开发，包括对核心架构开发准则的应用，分析，设计， 实现，以及测试，以便开发出高质量的的组件及方案。

客户团队。
• 他们集中于对需要解决的问题进行定义，并构建（包 括业务的修正）解决这些问题的事情。他们必须确保 任何构建处的解决方案对组织都是充分有效的。