一般的迭代工作流
本章的内容就是从四个阶段中发生的不同迭代里提炼出一般的模式以表征所有迭代的特征。
我们使用这种一般的模式作为基础来创建具体的迭代，而在哥哥阶段，迭代内容随着该阶段要达到的目的的不同而有所变化。
一般的迭代工作流包括五个核心工作流：需求、分析、设计、实现和测试。它也包括在这些工作流之前的计划和在这些工作流之后的评估。本章将集中讨论计划、评估以及在所有工作流中都普遍存在的其他活动。
计划在整个开发周期中是必要的。在计划开始之前，首先需要知道要做什么。五个核心工作流提供了一个起点。风险管理通过实现相应的用况集合来识别并环境风险，是梨花的另一个重要的方面。当然，没有对所需资源的估计，就不可能完成计划。最后，还必须对每一次迭代和阶段的执行进行评估。
对平衡的需要
在软件开发项目整个生命周期中的每一时刻，有许多不同的活动序列发生。面对这种复杂的情况，必须时刻注意保持这些不同的活动流序列的平衡与同步。
开发人员把整体上看来十分复杂的工作分解成一些小的部分，对这些部分的理解往往比对整体的理解要容易的多。
在每一次迭代中，该项目要力争在运行于迭代中的动作序列间达到平衡。这样就意味着我们应在每一次迭代中做该做的事情。什么是该做的事情屈居于我们在生命周期中所处的位置。项目的任务就是为每一个活动序列选择该做的事情去做。在决定活动序列的平衡时，确保其相对的重要性也是重要的，这样就能有效地进行优先级排序并保持同步。没有达到这种平衡和有效的执行，可能导致许多迭代曾老师开发过程失败。
在早期的迭代中，主要处理关键凤霞、关键用况、构架问题、开发环境的选择以及所有面向调研的活动，而后期的迭代则处理实现、测试、性能评估问题以及系统实施等面向开发的活动。将所有这些活动相互关联起来是一项微妙的平衡工作，正是这种微妙行使得软件的开发特别困难。
了解这些不同的活动序列并保持其平衡正是我们在每一次迭代中所要做的共。在统一过程中，一部分活动序列被确定和描述成核心工作流。还有一部分活动序列时没有被正是确定的，但对这些活动序列也可向对工作流一样认真加以处理。
阶段是开发工作的第一次划分
划分软件就开发过程的第一步是将其按实际分成四个阶段：初始阶段、细化阶段、构造阶段、移交阶段。每一个阶段又可以进一步分解成一次或多次迭代。
初始阶段确立系统可行性
初始阶段的主要目标是建立业务用况，即伴随项目的用况。初始阶段并不对所计划开发的系统进行彻底的研究，而是仅仅掏出一小部分用况来支持最初的业务用况。我们可餐区如下四步来构造业务用况：
- 限定所计划开发的系统的范围，即定义系统的边界并且确定与外部相关系统的接口。
- 描述或勾画系统的候选构架，尤其是系统中全新的、带有风险的或是难以实现的部分。目的是要确信在下一阶段我们能够建立一个稳定的目标系统构架。
- 识别出哪些影响系统建造能力的重大风险，并且断定是否可以找到方法环境这些风险。在初始阶段，只考虑哪些影响可行性的风险，也就是对系统的成功开发有威胁的风险，而把偶尔发现的次要风险列入风险清单，在细化阶段再加以仔细考虑。
- 通过建造一个证明概念原型，向潜在的用户或客户表明，带开发的系统能够解决他们想要解决的问题或者能够支持其业务目标。
作出相和谐努力使想说明，从经济角度看，开发这个产品使值得的。以使步骤表明：再相当大的限度内，系统可能提供与建造系统所需要的投资相称的收益或其他价值。
这么做的目的使将初始阶段中计划的实际、投入的人力和资金减少到最小程度，知道发i西安系统使切实可行时为止。
细化阶段关注“做的能力”
细化姐u但的主要产品是一个稳定的构架，用于再后续过程中指导系统的开发。细化阶段还对目标系统进行研究，一球能高度准确地制定构架阶段的计划。为了实现构架和高度准确的费用估算这两个目标，开发组应做如下一些工作：
- 床构架基线，使其覆盖系统中对构架有重要意义的功能和对项目相关人员来讲十分重要的特性。
- 识别出重大的分线。这些风险有可能对下一个阶段的计划、费用和进度产生负面影响。要从实际和资金两个方面将这些风险缓解。
- 通过可靠性和响应实际等质量属性来规定系统可以达到的水平。
- 捕获功能性需求中大约80%的用况，使其足够可以制定构造阶段的计划。
- 再业务实践所设定的界限内，准备一份有关进度、所需要的人员和费用的标书。
需求和构架是初始解u但和细化阶段的主要工作。
构造阶段建造系统
构造阶段的一般目标是由其主要里程碑指出的：具有最基本的可操作能力，即建造出能进行β测试的产品。
构造阶段的活动包括：
- 将对用况的识别、描述和实现扩展到全体用况。
- 完成分析、设计、实现和测试。
- 保持构架完整性，再必要时对其进行修改。
- 监控再上面两个阶段发现的关键和重大风险。如果这些风险确实存在，则应设法缓解其影响。
移交阶段转移到用户环境
移交阶段开始时通常伴随着β版本的产生，即开发组织将基本可操作的软件产品交付给真正用户去的代码。再用户组织苛刻的缓解中对产品开发状态所进行的验证，通常要比再开发缓解内更严格。
移交阶段的活动包括：
- 准备活动，如场所准备
- 建议用户更新软件将使用的环境
- 为产品准备用户手册以及其他文档
- 调整软，使其适应再用户环境参数下操纵
- 再收到β测试反馈后，纠正所发现的缺陷
- 修改软件中没有预见到的问题。
移交阶段伴随着产品正是版本的产生而结束。但再项目组完成项目前，开发租场必须针对以下两个目标进行总结：
- 寻找、讨论、评估并记录可提供给将来参考的经验教训。
- 记录再软件的新版本中或新一代软件中会用到的一些事情。
再论一般的迭代
我们要区分核心工作流和别带工作流。黑犀牛工作流再每一次迭代中重复发现。但再每次重新发生时，他们再具体内容上有多不同，而与该迭代的中心问题有关。
在每次迭代中重复的核心工作流
一般的迭代由五个工作流组成：需求、分析、设计、实现和测试；另外它还博阿凯计划和评估。
参与到工作流中的人员
计划先于行动
在初始姐u但开始时要指导以下三件事：
- 在四个阶段中，将按一系列的迭代来进行项目的开发。
- 我们有一些以前的开发人员搜集的关于目标系统的信息。
- 我们自己用于一些关于这个领域和所做过的类似系统的背景信息。
从这些信息中，我们指导必须为项目和每一次迭代制定计划（项目计划和迭代计划）。刚开始时，我们对要做什么所知有限，项目计划和迭代计划都只含有少量的细节。而随着初始阶段到细化阶段工作的开展，项目计划和迭代计划将变得越来越详细。
首先描述怎样为阶段和迭代制定计划以及怎样对迭代进行评估。
制定四个阶段的计划
统一过程规定了每一个阶段所涉及的内容。项目计划的任务就是将这些规定演化为具体的术语。
- 时间分配。要决定每一个阶段应分配多少时间以及准备完成的日期。
- 主要里程碑。当达到预先设定的准则时，标志着一个阶段的结束。
- 每个阶段的迭代。在每一个阶段中，我们通过一次或多次迭代推进工作。
- 项目计划。项目计划勾画了一个整体的路线图，包括进度表、主要里程碑日志和准则，以及由阶段分解来的迭代。
初始阶段的第一次迭代时比较困难的。因为除了迭代本身之外，还必须处理以下几个方面：
- 裁剪统一过程使其适用于这个项目，并且选使过程自动化的工具。
- 开始汇集具有项目所要求的各种才能的人员
- 构建各种关系以形成一个高效的开发组。
- 了解该领域的一些知识。
- 对项目特性的了解
- 使开发组熟悉将应用于裁剪后的过程和项目的开发工具。
制定迭代计划
每一个阶段由一次或几次迭代组成。制定迭代计划和制定阶段计划的步骤大致相似，也包括如下内容：
- 迭代进度表。决定允许每一次迭代需要的时间及其完成的日期，它在杠开始时是十分粗略的，随着所了解内容增加其精确性有所增加。
- 迭代内容。项目计划用术语勾画出所计划的迭代，而随着迭代开始日期的临近，我们将对要做些什么制定更详细的计划。迭代的内容基于以下几个方面：
- 在迭代期间，哪些用况将至少完成一部分。
- 哪些技术分线需要进行识别、转化为用况并将他们环境
- 已经发生的任何需求变化或者坑你已经纠正的缺陷。
- 要不分地或完整地实现哪一个子系统。
当前迭代的计划是十分详细的，而下一次迭代的计划则随着所了解内容的增加而越来越详细。猴戏迭代的细节有可能收但钱所能利用的知识的限制而比较粗略。
- 次要里程碑。达到预先制定的准则，标志每一次迭代的完成。
- 迭代计划。每一次迭代过程的活动都在细粒度迭代计划中进行了记录。
在每个阶段中，计划要进行的迭代的数码基本上随着目标系统的复杂度的不同而变化。例如：
- 初始阶段：一次迭代，主要用来规定系统的范围。
- 细化阶段：两次迭代，其中第一次迭代永久建造构架轮廓，第二次迭代用于完成构架基线。
- 构造阶段：两次迭代，以确保所产生的增量执行起来有令人满的效果。
- 移交阶段：一次迭代。
长远考虑
持续时期较长的系统会有各种各样的变化。
制定评估准则
相对于传统的项目而言，迭代的时间比较短。为了避免运行的不确定性，项目经理除了要制定开发进度外，还要确定每次迭代的主要目标。为了达到这些目标，项目经理建立知名迭代结束的准则。这些准则给出迭代的侧重点，着有利于迭代过程即使阶段。
项目经理提前为每一次迭代和阶段本身制定评估准则。每一个准则都需要有一个清晰的结束点，以便开发人员自己也名吧他们是否已完成了工作。另外，这些结束点提供了里程碑，共项目经理估计工作进度。
总的来说，评估准则分为两类：能验证需求的准则和更一般的准则。
影响项目计划的风险
制定新系统的开发计划很大程度上收所感知的风险的影响。因此，初始化阶段最初的工作之一就是要建立风险清单。
管理风险清单
模糊地认识到软件开发包含着风险是一回事；把分线展现出来，让大家都能看到且在其指导下对其餐区相应的崔氏则又是另一回事，着就是风险清单的目的。为了处理风险，需要了解其全部内容，包括风险清单中分象唯一的标识符。这些内容包括：
- 描述：从简短的描述开始，随着所了解内容的增多，逐渐增加更多的内容。
- 优先级：为风险分配优先级，开始时分为关键风险、重大风险和一般风险。
- 影响：风险会影响系统或项目的哪些部分？
- 键控制：由谁复杂跟踪持续发生的风险？
- 职责：由什么个人或小组复杂让该风险消退？
- 应急措施：如果风险确实发生，应采取什么措施？
影响迭代计划的风险
在初始阶段要识别关键风险，开发组要尽力环境这些风险。开发人员研究这些风险的性质以便准备迭代计划。
风险处理进度安排
一般的原则是要有计划地针对风险餐区措施。阶段移交阶段中的迭代都提供了风险处理进度安排的机制。
用况优先级排序
在本节中，我们将讨论单词迭代内用作驱动器的用况的选择。导致这一选择的工作就称为“对用况进行优先级排序”。按照用况或油坑的场景给在迭代中处理的顺序赋予不同的优先级，这些用况应被分别排列在几次迭代中。
控制这一排序是一种风险。我们按照用况是西安的风险的顺序来排列这些用况。
针对特定产品的风险
这类风险就是技术风险。我们把这些风险转换成用况，当正确是西安这些用况时，就能消除这些风险。
没有正确获得构架的风险
最严重的风险之一时没有能够建造一个在随后的阶段或在其生命周期中能逐步进化的系统。
怎样判定哪些用况时获得争取构架的最重要的用况呢？应如何消除哪些应建立稳定构架的风险？要解决这些问题，可以搜寻对构架有重要意义的用况，这些永康覆盖系统索要完成的主要任务和功能。可以想自己提出这样的问题：我们为什么要建立这个系统？
这一问题的大难在关键用况中发现。此外，有很重要的肺功能需求的用况也疏于管教用来。这些用况通过有助于发信系统的固件，在系统固件之上在添加所需要的其他功能。
其他类型的用况有：
- 次要的。这些用况支持关键用况
- 附属的。这些用况不是构建和关键风险的要害。
- 可选的。一些永康尽管不是市场出现，却可能时关键或重要的用况。
此外，我们希望确定移交便利了所有可能影响构架的用况。这就是为什么需要在西湖按揭u但覆盖大约80%的用况的原因。
没有正确获得需求的风险
另一个严重的风险时没有能获得用户真正期望的功能的系统。
答案的第一部分当然时要保证需求工作流的正确性，为此可以创建一个业务模型。答案的第二部分时，通过早期的迭代和原型，构建用户要求的系统并尽可能早地获得用户的反馈。
所需要的资源
可能你移交感觉到基于阶段的软件开发的迭代计划有相当多的有点，但也存在几个坤嵘你的问题：
- 初始监督和细化阶段将要划分多少费用？
- 这些阶段所需的经费来自何处？
- 初始阶段和细化姐u但将花费多少时间？
- 早期阶段要经过多少个余额的延续才能进入大家认为的震亨的软件开发过程？
项目间存在广泛的差异
目标软件系统在他们准备进行开发前当然存在着很大的差异。让我们来列举以下四个例子：
- 位置领域的一个非先验性的全新产品。
- 在某一领域中移交做过的产品。
- 就的系统已经存在，但要对它进行一致或升级。
- 构件已经存在于商业市场或开发组织内部。
一个典型的项目
复杂项目具有更大的需要
要在初始阶段和细化姐u但投入更多的时间的工作量
新的产品线要求经验
在大多数情况下，对于全新的或是复杂的系统，开发组需要获取自身所没有掌握的信息。而这种信息的自然资源时在目标系统所在领域有者丰富知识的人员。
资源消耗所需费用的支付
经费来自于什么地方？
- 如果软件组织生产的是用于出售的产品，那么经费来自企业的一般管理费用，并且处于挂历的控制之中。
- 如果软件组织是为内部客户生产产品，那么最初两个阶段的费用来自于组织自身的一般管理费用，或者来自从客户转账过来的自己，或者来自高曾管理人员分配的资金。
- 如果软件组织是为单个的公司类客户生产产品，那么前两个阶段的费用可能来自于其本身的一般管理蜂拥。
迭代和阶段的评估
如果要全部是西安迭代开发方法的有点，项目需要在每一次迭代和阶段的结束点对其所完成的内容进行评估。一般由项目经理复杂评估工作，这样做并不知识为了评估迭代本身，还是为了以下两个更深的目的：
- 为了利用开服在本次爹地啊中所学到的知识来重新制定下一次迭代计划，并做任何必要的变动。
- 为了修改过程，选择合适的开发工作，扩大人员培训，并按照迭代评估所获得经验对过程改进提出建议。
评估的第一个目标是检查已完成的内容是否满足预定的评价准则。第二个目标是根据迭代或项目计划审查所取得的进展。
- 开发工作是否符合经费预算和进度安排？
- 通过对原型、构件、构造的测试或者观察，或者通过项目相关人员所关系的增量操作，来判断其结果石佛满足质量要求？
没有达标时的处理
评估工作做起来并不是那么简单。通常，迭代不会充分达到准则。项目不得不在下一次迭代中来万和城这些工作。这些工作涉及：
- 修改或扩充用况模型
- 修改或扩充构件
- 修改或扩充正在开发的子系统
- 搜寻更深层的风险。
- 为开发组增添某些技能或背景知识。
否则，需要分配更多的时间来完成已有的计划。如果是这种情况，则需要演唱第一次迭代的时间，其应该制定一个固定的完成日期。
准则本身
评估人员不仅仅只是检查是否达到了准则，还要对准则进行必要的修改。
下一次迭代
在评估的基础上，项目经理做如下一些工作：
- 确定工作已经就绪，可以进入下一次迭代
- 如果需要反攻，确定要进行的迭代时后的哪一次迭代。
- 为下一次爹地啊制定详细计划。
- 更新下一次迭代以后的迭代计划，不要求太详细
- 更新风险清单和项目计划
- 把该迭代的实际耗费和进度与原计划i相应的部分进行比较。
模型集的进化
基于阶段的迭代开发过程的一个关键特性时模型集的进化。在迭代开发中，各种某些如同一个协调的集体在阶段之间共同进化。整个系统由所处的一个状态向更高级的另一个状态进化，来代替相互独立的模型的进化。