2022年迭代开发[定 .pdf

《2022年迭代开发[定 .pdf》由会员分享，可在线阅读，更多相关《2022年迭代开发[定 .pdf（22页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、第 1 章什么是迭代开发“要打造完美的业务解决方案，就必须采用迭代和增量开发方法。”引自 Dynamic systems Development Methodology 中的第五原则：“动态系统开发方法论”(本书由 Addison-Wesley 于 1997 年出版， Jennifer Stapleton 著) 前言中曾提到过，为了能够在变幻莫测的现实环境中以可预期方式交付结果，“迭代”方法应运而生。“不确定性” 将持续存在， 我们需要采用一种与之抗衡的技术，这种技术就是迭代和增量开发，借助这种技术赋予的力量，我们能够克服不确定性，或至少能系统降低不确定性，使其处于可控范围，以达到预期的目标。

2、那么，迭代和增量开发过程有什么特点？按迭代和增量方式开发项目意味着什么？柯林斯现代英语词典给词语“迭代(iterate)”和“增量 (incremental) ”提供的定义如下：迭代 反复说念和执行动作。增量 (1)增加量； (2)变大、增加。假如以上术语沿用最常用的词语含义，那么通过重复做事情的迭代和以增量方式处理项目，以达到创建规模逐渐增大和更趋完整的产品意味着什么？本章将通过分析项目及其团队成员以迭代和增量方式开展工作的含义，来回答上述问题。将站在最具代表性的参与者(项目经理、开发人员和客户等)的角度审视迭代原理，由此澄清和阐明迭代和增量式开发的真义。1.1 迭代与科学方法人们会通过很多

3、活动来开发解决方案。我们需要了解问题、收集潜在解决方案的要求，将这些要求转化为设计，构建解决方案，最后测试解决方案。这样的顺序十分常见，通常也是正确的。不过，在尝试扩大规模时(即严格按顺序收集全部要求，而后完成全部设计，再去进行全面开发，最后进行全面测试)，问题会接二连三地冒出来。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 1 页，共 22 页 - - - - - - - - - 第部分迭代项目管理原理4 相反，我们更需要像科学家那样去工作。现代科学方法遵循亲身观察的原则：先提出

4、“理论”，然后设计和执行相关的实验来测试理论。会根据测试结果，来推翻理论或确认理论的正确性。如何在软件开发领域应用此方法呢？在某种意义上，软件开发项目的很多方面是“理论” ，更准确地讲是需要予以评估的“断言”。 “计划”本身由多个描述任务用时的断言组成。“要求”是描述适当解决方案的特点的断言。不能仅凭某些利益相关方或主题专家的判断来确定要求是否有效。甚至，我们需要评估这些要求，判断它们是否针对当前问题提出了合理的解决方案。此推理引导我们采用这样一种软件开发风格：通过设计和开发多个可论证的系统版本，来反复验证和评估计划的断言；会客观地评估每一版本确认它是否降低了项目风险；在前一版本的基础之上构建

5、新的版本，直至完成解决方案。通常更多地将这种开发风格定义为迭代和增量开发，它具有以下特点：迭代运用一组活动来评估一组断言、消除一组风险、完成一组开发目标，并逐步生成和提炼有效的解决方案。之所以称为“迭代”，是因为它通过反复运用核心开发活动，不断增进对问题的理解程度、完善解决方案的定义和促进实现解决方案。之所以称为“增量”，是因为每经历一个迭代循环，都可以增进对问题的了解，增强解决方案的能力。通过连续多次应用迭代循环来打造一个项目。真正有效的开发活动必须兼具迭代和增量特点。如果开发活动仅有迭代特点，没有增量特点，那么，虽然可以一次次地迭代执行活动，却不能朝着项目既定目标前进；换句话说， 不能降低

6、风险，也不能逐步构建解决方案。循序渐进地降低风险和稳步迈向项目目标是迭代和增量开发的品质保证。为简单起见，本书常将“迭代和增量式”开发简称为“迭代化”开发。1.2 迭代的含义迭代的定义如下。迭代：独立的微型项目，有明确定义的输出，即一个稳定的、集成的且通过测试的发布版本。一个迭代包含一组特定的活动，这些活动根据迭代计划和一组客观、可度量的评估标准执行。发布版本分为内部和外部两类。下面将详细探究此定义的三个方面。1.2.1 迭代是一个独立的微型项目软件开发项目通过将一组用户要求转化为全新的或经更改的软件产品，来生成软件产品的新发布版本。采用迭代和增量方法时，通过将完整项目分成多个微型项目(每个微

7、型项目称作一个迭代)，渐近地、逐步地完成此过程。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 2 页，共 22 页 - - - - - - - - - 第 1 章什么是迭代开发5 每个迭代都包含软件开发项目的全部要素：计划、应用核心软件开发原则(需求、分析、设计、实施1和测试 )以及准备发布。 但迭代并非完全独立的实体，而是大项目的一小部分。归属于大项目对它们而言十分重要。之所以称其为“微型项目(mini-project) ” ，是因为利益相关方并未要求开发此项目。在开发团队看来，

8、每个迭代都是一个独立项目。这种十分高效的方法使开发团队能全力满足直接目标，并确保频繁和客观地评估生成的结果。管理团队需要确保迭代目标是更宏大的总目标的可信赖部分。管理团队应该确保每个迭代都满足以下要求，以便强化这种运作模式：清晰的目标 必须清晰定义每次迭代的目标，并获得所有项目参与方的理解和认同。这样才能使大家拧成一股绳。可度量的评估标准为使目标成为团队的一致主题，必须为目标配备可度量评估标准，以便客观评估迭代成效。全心投入的团队团队必须坚定不移地为实现迭代目标而并肩工作：团队共担成败责任，每个成员都要按照安排做好每一件事，以达成设定的迭代目标。所有工作都是为了实现迭代目标。进度表 与在迭代目

9、标上达成共识一样，管理层必须协商制定进度表，并了解进度表对整个项目计划的影响。制定迭代进度表时，只需设置迭代起止日期，并了解如何使迭代融入整体项目计划。客观评估 在迭代将近尾声时，必须对照迭代目标和评估标准客观地评估生成的结果。在迭代期间连续执行评估，在结束迭代时进行总结。如果不做客观评估，将无法判断迭代的成败，也无法有效地控制项目。做好上述这些事情，可以确保明确定义的可度量迭代结果可与项目的总体成功紧密联系在一起。1.2.2 迭代有一组独特的活动每个迭代都具有唯一性。它采用一组独特的活动以便生成一个独特的产品版本，该版本客观地证明迭代目标已经被实现。由于这个独特的要求，每次迭代前都需要编写关

10、于本次迭代的计划。迭代计划包括团队为实现迭代目标必须完成的所有活动的详情。项目要求的活动级计划的数量和风格取决于诸多因素，包括项目风险、团队规模、经验水平和管理者倾向使用的管理风格。对某些项目而言，只要有一个描述需要达到的目标并列出要执行任务的非正式计划就足以满足要求。可由开发团队安排和分配活动。而其他项目则要求编制更详尽的计划，计划应该更详细地描述活动及安排，以便设计出不同团队成员完成的任务之间的依赖性。无名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 3 页，共 22 页 - -

11、 - - - - - - - 第部分迭代项目管理原理6 论采取何种方法，编制迭代计划的原则是一致的：确定目标和评估标准。确定可用的资源，编制活动进度表。在任何时候，使用的迭代计划均不超过两个：一个管理当前迭代，一个是对下一迭代的不断改进的计划梗概。这样，只需为这些即将产生结果的主题编写详细计划，避免生成不必要的详细计划，并鼓励项目人员精力集中交付直接结果。正如第 5 章和第 6 章中讨论的那样， 迭代计划存在于完整项目计划(也采用迭代方式开发此计划， 并吸取执行迭代的经验予以改进)确立的上下文中。 因为将所有细节都放在迭代计划中，相对而言，整体项目计划采用高度概括的形式。第 7 章和第 8 章

12、将详细讨论如何规划迭代项目及其中的迭代。1.2.3 每次迭代的结果都在“发布版本”中为了确保项目取得进展，每个迭代都要被要求产生可操作的结果，即“发布版本”。发布版本的类型如下。原型：演示某些特定功能。内部发布版本：用于获取反馈信息，将这些信息用作进一步开发和测试的基础。外部发布版本：以某种形式交付给客户的版本。发布版本的定义如下。发布版本：一个稳定的可以执行的系统版本。每次迭代期间生成可执行版本对迭代方法非常重要，以致有人断言“迭代的目的就是获得迭代发布版本，即一个稳定的、集成的、经过测试的、部分完成的系统”。2在每个迭代中，会将参与项目的所有团队开发的所有软件集成到一个发布版本中。这一系列

13、发布版本为项目提供常规的技术可视点，从中可以了解到整体项目的状态。如果仅将发布版本视为交给项目团队以外的人员的东西，则曲解了每次迭代生成一个发布版本的观点。提到术语“发布版本”时，我们指那些可执行、可评估的内容(包括仅在内部评估的内容，如原型和对外的产品发布)。系统的早期发布版本通常是不完善的系统版本，它们展示系统必需的重要特性，解决项目面临的主要技术风险。随着项目的推进，逐渐给早期迭代生成的软件添加功能；这种做法一直持续到系统拥有了足够的功能，可以交付真正的商业价值为止。此后，仍可以继续开发后续版本，以便实现附加功能。表 1-1 总结了发布版本的最典型类型、目的和时间顺序。表 1-1迭代发布

14、版本示例发 布 版 本受众目的2 敏捷和迭代开发：管理者指南，Craig Larman 著，由中国电力出版社引进并出版。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 4 页，共 22 页 - - - - - - - - - 第 1 章什么是迭代开发7 概念验证内部演示 /可行性研究原型内部演示 /调研某些功能中间发布版本内部获得用户代表的反馈信息，并展示进度产品发布版本 (测试版 ) 外部获得用户的反馈信息产品发布版本 (GA 版3) 外部提供价值和商业利益产品发布版本 (Poin

15、t) 外部修改故障，有时还提供次要增强功能一旦决定将某个迭代版本发布到运行环境供用户社区自由使用，这个迭代发布版本就成为一次产品发布。虽然生成的许多发布版本都具有产品发布版本所需的质量水平和完整性，但并非所有发布版本都值得发布。例如，某个发布版本未包含对用户有用的足量功能，或用户不准备接受相应的版本。每个持续发布的版本都应具有以下特点。增加功能：依据是迭代是否实现了新的功能。提升质量：依据是产品缺陷数量是否减少。降低风险：依据是评估用户忠诚度、风险严重程度和利益相关方的信心程度。编制迭代项目计划时，了解每个迭代的目的、类型、受众和生成的发布版本是十分重要的。1.2.4 迭代开发的特点以下三个要

16、素的有机结合赋予迭代和增量式开发以力量。迭代是一个微型项目这使得迭代易于管理，并为整个开发团队提供了清晰明了的工作重点。如果将项目组织为一系列微型项目，就能通过将特定问题和风险划分到特定迭代中来降低项目固有的复杂程度。这有助于将技术因素从管理因素中分离出来，减少参与项目的不同团队间的摩擦以及项目本身的重叠区域。每次迭代包含一组特定的活动每个迭代处理一组特定、独有的风险，因此需要一组活动来消除这些风险。每次迭代都集中精力解决一组问题，由此来推进项目。后续迭代基于前面的迭代来构建，随着项目以增量方式构建解决方案，项目提供的性能也逐步提高。每个迭代生成一个发布版本通过迫使项目团队生成一些结果(“发布

17、版本”)并客观测量目标和评估项目进度，可以关闭一组问题和风险。迭代生成的发布版本系列提供了常规项目技术可视点，以从中了解整个项目的状态。以上三点共同奠定了对软件和软件密集系统进行成功迭代开发的基础。这种方法还简化了向管理人员提供的报告：每个迭代完成后，只需报告达成的目标、未达成的目标，以及余下的风险。这些是可以客观描述的，而无需主观臆造。记分板可供查看，内容具体，简化了与利益相关方和高级管理人员的沟通。3 GA (General Availability ，通用版本 )：一般指某个软件产品首个公开发布的版本。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - -

18、- - - - - - - 名师精心整理 - - - - - - - 第 5 页，共 22 页 - - - - - - - - - 第部分迭代项目管理原理8 1.3 迭代体验迭代开发的本质是一种以团队为基础的解决问题和开发解决方案的方法。它需要各参与方 (包括开发团队、客户团队和管理团队)采用多种协作技术。为了研究这种理念，我们需要考虑迭代开发对参与软件开发项目的最常见角色的影响。想一想参与软件开发的角色，会发现这些角色分为三大类。核心开发团队这些人员关注于按照要求设计和开发解决方案，包括应用核心开发原理 (架构、分析、设计、实现和测试等)开发优质组件和解决方案。客户团队这些人员关注于确定要解

19、决的问题以及要构建的内容(包括更改业务流)；他们必须确保完成的解决方案为委托方提供足够大的利益。管理团队这些人员关注于确保客户、业务和开发目标是一致的，确定问题是正确的，构建了解决这些问题的正确方案，开发工作正以高效和受控方式进行。接下来的章节将站在以上三种角色的角度进一步体验迭代开发，分析迭代如何帮助项目实现所有目标，以及迭代对项目所有参与人员的影响。1.3.1 站在核心开发团队的角度分析迭代让我们站在核心开发团队的角度分析项目的变化。该团队负责应用开发原理生成满足客户要求的系统的发布版本，开发原理包括分析、设计(包括架构 )和实现 (包括单元和集成测试 )。即使分配客户代表或业务分析师直接

20、参与工作或永久加入开发团队，也认为应由客户团队提出要求。下一节将站在客户团队的角度分析迭代。1. 开发人员角度在迭代式和增量式开发中，最常见的视角是小型开发团队中个体开发人员的视角。这是完成大多数迭代和增量开发工作的技术社区的视角，这些开发人员还是推动采用迭代实践的主力军。最近，本书作者之一参加了主题为“利用特定交互式开发环境进行迭代开发”的软件开发人员研讨会。研讨会主持人很快流露出这样的观点：迭代就是迭代应用“编写测试、编写代码、测试代码、修改代码”周期，一次又一次地应用，直至一段已经完成的、经过单元测试的代码可以添加到某类发布版本为止。虽然这些“开发”活动包含迭代开发支持者建议采用的最佳实

21、践(如测试先行、常测试等)，但此主持人介绍的应用方法将导致密集迭代，迭代周期常以“分钟”计。将迭代视为一个开发人员的“编写测试、编写代码、测试代码、修改代码”周期的观点固然有其狭隘性，因为它忽略了项目团队的其他很多重要工作，但继续站在开发人员的角度观察问题却是有用的。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 6 页，共 22 页 - - - - - - - - - 第 1 章什么是迭代开发9 正如研讨会主持人所讲的，紧凑的反馈循环正是开发人员在迭代和增量项目中自然而然的做法。开

22、发人员个人按自己的节奏行事，通常一天多次快速连续地执行分析、设计和实现。任何时候构建和改进系统软件时，开发人员个人都要做出无数的战术决策。开发人员个人的活动趋向于在一些共享事件上做出同步，例如日常构建和系统集成点。小组的活动趋向专注于架构工作、定义接口和重构组件。一旦开发人员了解到职责和当前目标的范围，他们通常会尽力履行职责，交付一个或多个可以集成到一些发布版本的有效组件。每个开发人员 (如果使用了结对编程方法，是一对开发人员 )将在项目所采用的过程的框架中开发出适合个体的工作方式。2. 进度和产品待办事项开发人员个人很少对技术以外的事项感兴趣，例如实现利益、获得投资回报或者管理风险。开发人员

23、通过定期构建实用的可执行代码结束一项工作，他们选择要予以分析、设计、实现、构建、单元测试的需求或变更请求集合，并将经过测试的组件添加到产品的发布版本中。图1-1 显示了开发人员应用这些原理的循环特点。开发人员迭代过程的时间和尺度可以用小时、天或周度量，具体由所从事工作的规模和复杂度决定。分析设计实现需求或变更请求要添加到发布版本的经过测试的组件图 1-1 站在开发人员的角度分析迭代开发人员一直以这种方式工作，他们从待办任务列表中选择和实现少量需求或变更请求，直到完成分配给他们的所有任务为止。在开发人员看来，迭代和增量开发的“增量”体现在生成的开发版本更完整、功能更丰富。这和数量逐渐变少的待办更

24、改请求(当然，待办请求越少越好)形成对照的是，通常将一系列待办要求和更改请求称为“产品待办事项(product backlog) ”4，因为它代表了待办的积压工作。开发人员每天从产品待办清单中取走一些条目，构建项中包含的已实现条目逐日增加，而且每天都可能将一些新工作添加到产品待办事项中。图1-2 显示了如何一天天地逐步完成产品待办事项中的工作。4 SCRUM 迭代管理方法整理了“按优先顺序排列的产品待办事项”概念，并视其为核心概念。请参阅Ken Schwaber 和Mike Beedle 编著的 Agile Software Development With Scrum，该书于 2001 年由

25、 Upper Saddle River 的 Prentice Hall 出版社出版。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 7 页，共 22 页 - - - - - - - - - 第部分迭代项目管理原理10 日构建的进度产品待办事项天数新工作产品待办事项已完成工作图 1-2 逐日处理产品待办事项这种以开发人员为中心的方法适用于以下情况：小型开发人员团队密切配合来处理一组松散结合在一起的组件；较大的开发人员社区处理一个公共代码库(例如开源项目)。为了扩大到需要更多开发工作量的

26、较大项目(通常需要处理交互密集的组件组)，就需要从其他角度分析迭代和增量方法。3. 开发团队领导者的角度与开发人员个人形成对照，开发团队的领导者关心如何协调和优化多个开发人员的工作，每个开发人员更改或实现的多个组件必须集成到一个发布版本(此发布版本满足团队的共同目标 )。在开发团队领导者看来，迭代不仅是一个核心开发活动(分析、设计和实现)周期，迭代通常是一个要求在规定期限内完成的微型项目，会生成一个重要的新软件发布版本。由图 1-3 可知，演示团队融合一组开发人员的工作而生成集成的发布版本，此后使用它收集反馈，将根据反馈调整在下一迭代中实现(并且包含在下一个发布版本)的更改请求和需求。针对一些

27、需求/更改请求进行构建针对进一步的需求/更改请求进行构建针对进一步的需求/更改请求进行构建一个迭代时长通常为4 6 周为客户提供的发布版本反馈反馈图 1-3 从开发团队领导者的角度分析迭代迭代的目标是将整个开发团队的工作集成到一个稳定的、集成的、经过测试的系统发布版本中。大多数迭代的开发版本仅是内部发布版本基准，主要为开发团队带来利益，结名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 8 页，共 22 页 - - - - - - - - - 第 1 章什么是迭代开发11 束一个迭代，

28、并且衡量进度。这些“内部发布版本”通常不部署在用户系统上，但经常让用户过目以便收集反馈意见。通常，经历三个或更多迭代后才能获得一个公开的软件发布版本。每个迭代都能对系统发布版本起到作用，开始时，第一个迭代获得一个小型局部化系统实现，随后的迭代实现更多要求，逐步补全系统，直至生成最终的客户发布版本。在图1-3 中，圆圈表示生成的发布版本，在开发过程中，圆圈逐渐变大。将开发人员与团队领导者的视角联系起来在很多开发人员看来，迭代和增量开发通过近乎无数个迭代系列取得进展，每次迭代都使系统更完善，直至客户感到满意，并决定不再投入开发资金为止。从这个角度看，只要完成了工作，实施了更改，项目就取得了进展。在

29、团队领导者看来，只有将开发人员的工作集成在一起，或者说产生一个成功的结果，才算是取得了进展。图1-4 演示了在多个迭代上取得进展的宏观开发团队视图。开发团队的进度(完成应用程序的百分比) 迭代1 迭代2 迭代3 迭代4 图 1-4 每个迭代都生成比上一个迭代更完整的发布版本在图 1-4 中，由开发团队完成有效的集成发布版本的程度来衡量进度，而不根据规约或其他文档的完成程度来衡量。根据集成应用程序实施的要求数量来计算应用程序的完成程度。每个迭代重在生成有效发布版本，并非是一些项目文档或未集成组件的集合。必须测试集成发布版本，从总体上分析团队的进度。我们看到，在很多项目中，开发人员创建和测试了大量

30、组件，但是这些组件无法集成为部分产品，更不用说完整产品了。这些情况下，永远不会出现图1-4 显示的项目视图，因为没有客观依据显示完成产品的程度。4. 制定计划的必要性为了集成多个开发人员的工作，必须制定一些计划。首先，给开发人员分配工作时，要尽量减少工作之间的依赖程度，以便开发人员能够较为独立地工作，当然事实上，他们的工作必然是相互依赖的。其次，开发人员必须通过一种途径就依赖关系达成一致意见；比如，必须就组件和其名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 9 页，共 22 页 -

31、 - - - - - - - - 第部分迭代项目管理原理12 接口的名称达成一致。随着依赖数量的增加，最终必然到达一个转折点，即不能仅依靠随随便便的人际交流，还要制定开发人员之间的协议。随着复杂程度的增加，以及高效协调团队成员间的工作变得更趋复杂，团队领导者需要通过一种方式来了解该在什么时候按什么顺序做什么事情。这就需要制定更正规的计划，而为了制定计划，又需要进行评估。不同开发人员负责处理的组件的相互依赖关系是创建较正规计划的起因，因为不能再根据最复杂组件的预期开发时间(这种情况下， 所有组件都是独立的 )或者通过汇总所有组件的开发时间(这种情况下， 所有组件的相互依赖程度很高，每次只能处理一

32、个组件)确定时间表。只有理解了组件间的依赖关系，才能构建有效的时间表。有人说，迭代开发的时间规模如此短，以致于不需要制定计划，也不需要进行评估。这是一种哗众取宠的观点，好像在说，由于每次仅执行一个步骤，我们可以连续决定下一步去往哪里，所以无需规划路线，如果您不关心去往哪里，这样的策略固然可行，但项目投资者肯定有既定的项目目标。计划和评估是开始时确定是否值得投资项目的机制，也能使启动后的项目驶入正确轨道。几乎没人在不确定室内装修成本和装修时间的情况下雇人装修房子。软件项目与这没什么两样。项目赞助方需要了解项目成本及完成时间。这些都需要进行规划和评估。本章在后面分析客户和管理团队观点时还会讨论这些

33、主题；介绍如何规划和评估宏观计划和项目中的各个迭代的后续章节也将讨论这些主题。1.3.2 站在客户的角度分析迭代为了兑现迭代和增量开发的所有承诺，您必须确保这种实践的影响超出了技术和开发社区。在理想情况下，应用的迭代实践将深入地、持续地影响到参与项目的所有业务人员，还从根本上改变了这些人描述、支付和实现商业利益(由成功开发软件解决方案带来)的方式。如果迭代和增量开发的采用没有影响到业务，也不影响实现迭代开发解决方案提供的利益的方式。那么这种采用仅起技术保障作用，对开发团队之外的圈子几乎没什么影响。为了释放全部潜力，还必须改变项目与利益相关方的交互方式。绝大多数迭代和增量开发文献都浓墨重彩地分析

34、开发人员和开发团队领导者。虽然此方法对开发团队的影响至关重要，但迭代和增量开发的真正价值在于其极大地提升商业效果的潜力。为了取得这样的利益，客户代表、业务分析团队、系统的最终用户、业务领导者(赞助方 )等业务人员必须积极参与到项目中来，而且需要改变他们与开发团队的交互方式。本节将分析这些变化及影响。将分别考虑这四类客户的观点，以及采用迭代和增量的变化如何对整个业务产生积极影响。1. 客户代表软件开发项目采用的迭代和增量方法深刻影响着客户代表与项目开发团队的交互方式。如图1-5 所示，开发人员可利用每个迭代，收集关于解决方案适用性及潜在商业影响的客观反馈意见。使用演示可运行版本时获得反馈意见，沟

35、通时将重点突出，将能集中精力开发一个符合系统最低限度的基本特征的解决方案。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 10 页，共 22 页 - - - - - - - - - 第 1 章什么是迭代开发13 针 对 一 些 需 求 / 更 改 请求进行构建演示发布版本针 对 一 些 需 求 / 更 改 请求进行构建客户检查并接受图 1-5 通过演示每个迭代发布版本，可以收集来自客户的客观反馈意见客户代表可以利用每个迭代对正在进行的工作发表评论，并对未来开发方向施加影响。评审可用发

36、布版本(演示要求决策的含义，以及开发团队对这些要求的解释)后，客户可以根据情况改变项目方向或其余需求的优先级5。通过演示少量可用功能，团队能够关注于正确的业务方案的组成部分以及实现该结果需要的最少数量的功能。在每个迭代的边界处，客户代表都有机会接受或拒绝开发团队生成的发布版本，并调整项目进展方向。这样一来，客户团队可以更多地参与到项目中，并确保解决方案能够带来预期的业务利益。开发、演示和评估的快速循环为客户参与项目提供了很多机会。迭代的方法允许他们：在指导项目时扮演更主动、能提出更客观意见的角色，积极驾驭项目，以确保项目的每个参与者都能准确理解适当业务解决方案的组成部分。调整与项目的关系，以便

37、与协作方关系中的风险和信任程度相适应。从积累的经验中吸取教训，借此机会将它们都提供给开发团队。保持对迄今为止的项目风险和进度进行客观评估。对团队的交付能力树立信心。定期的客户演示也使开发团队受益，使他们能够：更好地从宏观上了解项目。更加集中精力开发得到被认可的商业解决方案。更好地树立他们的计划已得到被认可的信心。更客观地预期客户需求。结果，开发项目不再是一个消耗资金的黑洞，这些资金的注入是希望在未来的某个指定的时间点开发出一些软件。如果在开始的几个迭代中没有达到共识和相互理解，那么就要改变项目发展方向，或者根据需要取消项目。这为企业提供了一种监视和调整投资的客观方法6。5 当然， 如果项目在每

38、个迭代都在改变方向，则表明项目的基本假设是错误的。一旦遇到这种情况，最好将项目停下来，重新考虑项目的目标。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 11 页，共 22 页 - - - - - - - - - 第部分迭代项目管理原理14 2. 业务分析师角度业内人士对于是否应将需求工作视为迭代过程的一部分有着不同的看法。根据我们的经验，只有所有团队成员(包括业务利益代表)都积极参与到项目，迭代和增量开发才能真正发挥出作用。这意味着，需求过程应该与解决方案的迭代开发时间表紧密集成，

39、并按时间表执行。考虑下列观点。为不予交付的需求编制文档是毫无价值的。如在规定的时间和预算内完成只和目标有关的工作已经很困难了。将时间投入到不需交付的事项上会分散精力，并使项目处于风险之中。不要说多做些工作“将有助于下一个项目”，建议您将相应工作留到需要它的项目中去做。记住，如果第一个项目没有满足目标显著特点是付出了无谓劳动通常“下一个项目”也随之消失了。不必在开发人员开始工作前提出所有要求。只需提供驱动当前工作(这里指当前迭代)的所有要求即可。如果要提出所有要求，则需要在系统上完成大量工作，原因是并非所有要求都相关，也并非是同等重要的。开发团队能够远在设计所有用户界面前轻而易举地解决使系统支持

40、1000 个并发用户的问题。实际上，用户界面的设计通常几乎不影响或完全不影响此解决方案的扩展性。需求倾向于增加到占用所有时间。在大部分项目中，人们能轻松想出新要求的能力超出了任何团队在规定时间和预算范围内可交付产品的的能力。帕金森定律7中的“会扩展工作，以便填补完成前的时间”，将这句话用在与要求相关的工作再适当不过了。没有需求团队能声称在用完所分配的时间前发现了全部需求。如果需求团队真在时间用完前找到了足量的需求集合，他们总会提出更多要求，而非宣称已经完成了任务。与实现工作相比，定义需求几乎不费吹灰之力。定义需求的真正艺术并非体现在识别尽可能多的需求，而在于找到可以满足商业问题的一组尽量小的要

41、求。更多的需求并非好事，很多解决方案就是因为需求太多而走向毁灭。所有迭代和增量软件开发过程背后都有一个基本断言：唯一重要的事项是交付解决方案。任何对于交付解决方案没有贡献的活动都是多余的，应予消除。迭代旨在生成一个有用的解决方案版本(但通常只是一个局部完成的解决方案)。为此，必须了解迭代实现的需求。这并不意味着需要在开发迭代开始前了解最终需要满足的所有需求。相反，我们只需要了解足够的需求以便为当前迭代确定一个有意义的目标即可。有几种驱动迭代开发项目的需求开发模型。下面分析四种常见模型：瀑布需求、前置需求 /后置开发、需求管道和即时需求。瀑布式需求，迭代式开发解决方案此情况下，在迭代开发解决方案

42、之前定义所有需求。图1-6 显示了这种模式。7 C. Northcote Parkinson 编著的 Parkinsons law 或 The Pursuil of Progress(John Murray 出版社于 1958 年在伦敦出版 )。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 12 页，共 22 页 - - - - - - - - - 第 1 章什么是迭代开发15 指定的需求针对一些需求进行构建针对一些需求进行构建, 定义了所有需求后继续进行迭代图 1-6 首先定义需

43、求，然后进行迭代开发很明显，这种方法不够理想，因为这经常定义一些永远都不会去实现的需求，或者过分详细地定义了一些需求。这种方法提出了不切合实际的期待，随着参与者开始了解到无法实现每个需求的情况，对立和失望的气氛将不断蔓延。这也导致需求团队在孤立状态下工作，他们将无法从开发团队那里获得反馈意见，这使得需求团队与开发团队之间容易产生冲突。整个需求团队无法吸取实现第一组需求的教训，也无法运用它们来提高需求质量和整个团队的效率。以下组织经常使用上述模式：开发团队希望使用迭代方法，但尚未证明迭代方法是否适用于业务环境。这使很多组织就此踏上了新道路，开始采用协作性更强的迭代工作方法的一种方式。一家公司不了

44、解迭代和增量技术，该公司将开发工作外包给一家已经采用了迭代和增量技术的公司。业务团队与开发团队不和，业务团队不信任开发团队做出的任何决策，不相信开发团队会与他们开展协作。业务团队无法确定需求的优先顺序，坚持将多种需求视为一个不可分隔的整体。这是一种传统方法，它导致的组织结构通常使得团队成员基于工作类型各自为政地工作。团队成员之间有一堵无形的墙，降低了沟通效果和团队交付解决方案的效率。评估系统奖励那些做了必要工作(但并不能仅凭这些工作交付成功解决方案)的人，这通常使得问题变得更加复杂。交付了一份完好的需求文档或获得批准的软件架构文档，就认为职能化团队大功告成，这样的事情司空见惯。虽然说为了交付解

45、决方案必须完成这些事项，但它们自身并无价值。如果不能交付解决方案，完成的需求文档将毫无价值。虽然有必要按职能组织报告关系，以便提高技术水准促进职业发展，但进度和结果的评估需要与解决方案的交付保持一致。这通常导致“二元”报告结构，即每个人至少向两个组织报告：一个负责管理职业发展，另一个管理项目及其目标。前置需求 /后置开发如果部分需求已经稳定，如图1-7 所示，则可以在定义好所有需求前启动迭代开发。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 13 页，共 22 页 - - - -

46、- - - - - 第部分迭代项目管理原理16 需求规范针对一些需求进行构建针对一些需求进行构建针对一些需求进行构建最初的需求,初次迭代时使用, 定义了所有需求后，才继续进行迭代持续进行直到实现所有的需求图 1-7 需求规范与开发迭代重叠这似乎是一种更具迭代和增量特点的方法，但它仍使需求团队和开发团队以各自为政的方式工作，这种安排方法会带来各种沟通开销和冲突。3. 需求管道迁移到管道模型颇具吸引力，如图1-8 所示，当开发团队实现为当前迭代定义的需求时，需求团队再定义下一个迭代的需求。需求团队需求团队需求团队开发团队开发团队开发团队图 1-8 需求管道这个模式立刻引发的问题包括：团队在哪个迭代

47、上工作？迭代重叠吗？团队同时处理多个迭代吗？从个人和项目管理角度分析，人们如何了解自己在处理哪个迭代以及优先顺序？稍后将从管理角度分析迭代。4. 按需 (适时的 )需求理想情况下，为打造一支最敏捷、灵活和专业化的开发团队，应将需求和开发工作全面集成在一个完好定义的迭代集合中。这种方式扩展了典型的迭代开发模型，增加了发布版本的需求规范和系统测试。图1-9 的模型扩展了图1-1 显示的迭代模型。这种工作方式最有效，但依赖于有一个融合的、协作的团队，此团队包括业务和客户代表以及技术开发人员。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - -

48、- 名师精心整理 - - - - - - - 第 14 页，共 22 页 - - - - - - - - - 第 1 章什么是迭代开发17 需求分析设计实现系统测试经 过 测 试 的发布版本迭代目标或变更请求图 1-9 包含集成需求规范和系统测试的迭代这种方法打造一个致力于以高效、迭代和增量方式开发整个业务解决方案的团队，自然而然地遵循了迭代和增量开发原则。它允许团队调整路线，以便确保尽可能快地交付商业价值。正如所看到的，采用迭代和增量方法对商业分析团队的影响巨大，团队成员将发现，他们是项目团队集成的一部分，在整个项目周期中工作，并非仅在初始阶段参与进来。他们在实现的同一迭代中迭代(通常采用及

49、时方式)定义需求。商业分析师也将担当交付指定解决方案的责任，他们在一定程度上参与到项目中以便履行相应的职责。需求文档(而非一成不变的必须交付的“最终”需求)成为业务团队与开发团队之间的关于需要交付什么才能获得令人满意解决方案的有效合约。作为合约时，需求文档指出了双方的责任，并对外公开供大家协商。各方之间的互信程度越低，需求文档就越庞大、越复杂。5. 用户的视角用户视角接近于客户代表的视角，用户将看到定期公开的进展情况以便确保解决方案满足他们的实际需要。如果要使项目取得成功，用户必须观看和评估迭代生成的发布版本。我们说“通常有利”是因为确定期待效果对获得有用的反馈至关重要。如果用户不了解见到的内

50、容，也不了解您期望获得的反馈意见，将感到十分困惑。通过与用户定期交互，也会使开发团队意识到他们需要交付业务价值，而不仅是交付新技术。这样还可以验证需求本身，并对照需求验证系统。下面的故事介绍了尽早收集用户反馈，特别是可用性和用户界面设计方面的反馈的好处。这个案例提供了一个值得吸取的教训。一家保险公司任命了一名新IT 总监。新 IT 总监上任后首先宣布了以下规定。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 15 页，共 22 页 - - - - - - - - - 第部分迭代项目管