迭代增量开发

迭代增量开发 迭代增量开发 Iterative and Incremental Development (第一讲) 在1970年Winston Royce博士发表了一篇名为“Managing the Development of Large Software Systems”的论文。这篇论文发表在Proceedings of IEEE 9页。这篇论文被公认为是软件开发瀑布模型的鼻祖，但是RoyceWESCON的1- 的思想是被以某种扭曲了的方式认同的。一些软件项目的管理者对Royce的话断章取义，捏造并传播了这样的一种思想:软件在之前是可以被完整地分析的，在编码之前是可以完整地被设计的和在测试之前是可以被完整地编码的——这就是瀑布模型。假如Royce博士还在世的话，我想他会对瀑布模型对软件开发产生了如此深远的影响感到吃惊，同时也会对他的思想被歪曲感到愤怒。 并不奇怪，甚至今天我们还能听见管理人员斥责开发人员在编码阶段还在作设计。管理人员希望能够通过在进度表上的设计阶段处画一个X来表示设计阶段的结束，以控制项目的进度。Royce的论文实际上描述了我们今天称为迭代增量式的开发风格。在他的论文中他描述了分析是如何被设计中的问题所约束的，设计中的问题是如何反馈到分析中，以及编码中的问题是如何反馈到设计中的。他还描述了增量式地逐渐发布一个项目的过程，在每个增量中，都有这个版本自己的分析、设计、编码和测试活动。 在下面几讲中，我们将概要介绍迭代增量开发的一些基本知识。首先，我们先了解一下瀑布模型及它的一些缺陷，然后我们介绍迭代增量开发过程(IIDP)和它是如何解决瀑布模型的缺陷的。 瀑布模型(Waterfall) 以下是一个故事，情节纯属虚构，请勿对入座。 任务: A君:某软件公司的项目经理 B君:A君的直接上司，某软件公司的软件部经理 BB君:B君的直接上司，某软件公司的总经理 日期是某年1月2日，A君坐在一间会议室中，在座的还有几个公司的高级主管和一群和A君一样的项目经理，B君也在。此次会议是BB君召集的。 “我们有一个新项目需要开发。”BB君说。接着BB简要描述了公司对市场的分析和对要开发的产品的简单想法。 “我们必须在10月1日之前将产品投放市场，”BB这样要求，“A君，你们需要多长时间进行系统分析,” A君说:“先生，我们现在对需求一无所知，无法告诉您系统分析需要花多长时间。” “需求文档准备好还需要3到4个星期，” BB说，“现在假设需求文档就摆在你面前，进行分析需要多长时间,” A君没有吱声。 “如果分析的时间超过了4月1日，那么我们就有麻烦了。A君，你们能在4月1日前完成分析工作吗,” BB继续问。 B君硬着头皮说:“我们会找到办法的～” A君顿感脑袋发大。 “很好，”BB微笑着说，“现在，再说说设计需要多少时间,” “先生，”A君说，“没有分析，我们无法判断设计需要多少时间。” BB的表情变的严厉了，“假设，A君你已经有了分析，”他说，同时紧盯着A君，“设计需要多少时间,” B君犹豫着说:“先生，完成项目只剩仅仅8><#004699'>6个月的时间，我认为设计最好不要超过3个月” BB说:“OK，分析在4月1日前完成，设计在7月1日前完成，还有3个月，你们可以用来完成整个项目。今天的会议充分体现了我们公司的团队合作精神和授权工作的，我很满意。现在散会，开始工作。我希望在下星期在我的办公桌上看到项目计划。” 极度的烦躁使A君什么都不想干。 B君递给A君三页纸的文档，说:“记住SEI下星期要来评估。这是评估指南，你必须仔细阅读并记住它，然后再撕了它。它会会告诉你如何回答的评估问题，还会告诉你可以带他们去哪里，哪些地方应避开。公司正争取在<#004699'>6月达到CMM等级3～” 分析阶段 A君带领项目组开始进行新项目的分析工作。这很困难，因为没有需求，只是从BB在那个决定性的早晨10分钟的介绍中，A君对这个产品应该作些什么有了一些模糊的印象。 需求文档在2月15日拿到了。然后是20日、25日，以后的每个星期都有一个新版本送来，新版本的需求和前一个版本有很多相矛盾的地方。显然负责编写需求的市场人员对产品还没有一个明确的认识。尽管如此，A君和他的伙伴们仍然进行着分析工作。 然后，一个奇迹发生了～在4月1日，分析完成了～ A君对B君说:“你怎么告诉BB我们完成了分析,” “你过来看看日历，已经是4月1日了～”B君说。 “但是我们还有太多的东西要考虑，太多的内容要分析～”A君说。 “你为什么认为分析还没完成,”B君不耐烦地说，“分析永远没个头，你必须在某个点上停下来。根据进度要求分析工作应该结束了，所以你们必须立刻停止进行系统分析，马上开始进行系统设计。” A君脚步沉重地返回了工作室时，他开始考虑在工作台的抽屉中应该放上两瓶酒，必要时可以麻醉自己。 设计阶段 公司举办了一个聚会来庆祝分析工作的按时完成。BB进行了一次慷慨激昂的演讲。B君的上司也受到了BB的表扬。最后公司的CIO 登场了，告诉大家SEI评估进行的很顺利，并且感谢每位学习和熟记了评估指南的人员。 随着日期的推移，A君和他的小组进行着系统的设计工作。当然，A君发现设计所依赖的分析实际上漏洞百出。但是当A君告诉B君需要返回头再进行一些 分析工作来修改分析中的不足时，B君只是简单地说:“分析阶段已经结束了，现在你们应该作的唯一的工作就是设计。” 于是，A君和他的小组尽最大的努力拼凑着设计，根本无法保证需求是否被正确地分析了。当然这实际上也不是什么大问题，因为需求仍然每星期不断地被更改着。在设计阶段进行到中间时，市场人员突然宣布他们要重新考虑系统的定位。他们的需求文档被彻底重写了。他们消除了系统原来的几个重要的特性，并代之以在客户调查中显示的非常重要的特性。A君告诉B君需要对系统重新进行分析和设计。但是B君说:“分析阶段已经结束了。现在你们应该作的唯一的工作就是设计。不要再罗嗦了” 于是，A君照做了。删改„„删改„„删改„„删改。A君竭力想创造出一个能准确反映新需求文档要求的设计文档。但是，需求文档虽然经历了革命性的变化，但是反复变更的现象却仍继续着，而且变更的频率和幅度越来越剧烈了。A君的项目组艰难地前行着。 然后，在7月1日，又一个奇迹发生了～设计工作完成了～ 这次A君没有去找上司抱怨，而是打开了抽屉中的酒。 实现阶段 公司又举办了一个聚会庆祝设计阶段的按时完成以及公司通过了CMM等级3的评估。会议之后，A君发现在他的头上多了很多新的标语和装饰牌，是一些雄鹰展翅和登山者的照片，以及一些口号。 A君和他的小组开始编码。但是A君很快发现设计在某些重要的方面存在重大的缺陷。A君召集了一个设计讨论会，试图解决一些问题。但是B君发现并解散了会议，严厉的对A君说:“设计阶段已经结束了。你们现在应该抓紧时间编 码。” B君在他的办公室墙上挂了一个图，上面标着累计开发出来了多少行代码，顶端标着1,000,000。三天后，B君在大厅里拦住了A君，说:“你们现在编码的速度不够快。我们需要在10月1日前完成一百万行代码。” “我们甚至还不能确定这个产品是否需要一百万行代码”，A君嘟囔着。 “我们必须在10月1日前完成一百万行代码，”B君重申到，“你能保证你们的注释块足够大吗,” 然后，他以管理者的口气说:“我有办法了～我希望你在工程师中执行新的编码。每行代码不得超过20个字符。任何超过的行必须分为两行或多行，所有已经完成的代码必须根据这个标准从新改写。这会让我们的代码行数上升～” A君知道这件事需要并未被排入进度计划的2个人月的时间，但他没有与B君争辩，因为他知道争也没有用。A君知道唯一的解决就是让自己的血管中充满酒精，他对公司项目管理的一些做法已经麻木了。 A君进行了适当的安排。删改„„删改„„删改„„删改。A君和他的小组疯狂地编码。到8月1日，B君对着墙上的曲线皱着眉头，他强制要求项目组延长工作时间，每周工作50小时，但是没有多于的报酬。 删改„„删改„„删改„„删改。到9月1日，曲线达到了120万行～B君却要求A君写一份报告解释为什么超过了代码估计量的20%，同时，他要求项目组星期六上班，同样没有多于的报酬。 删改„„删改„„删改„„删改。 怒火在燃烧，人员在退出～ 质量部的问题报告向A君雪片一般地洒来～ 客户追着要求安装和提供～ 销售人员需要为特殊的客户准备演示～ 需求仍在变更～ „„ 在9月15日，BB再次召集会议。 BB怒气冲冲地说:“质量部主管告诉我这个项目缺少了应该实现的功能的50%、系统总是崩溃、经常产生错误的结果，并且出奇的慢。而且，质量部主管说他们无法跟上你们每天更换版本的速度”，他停了几秒钟，显然想稳定自己的情绪，“质量部主管估计按这种速度开发，我们不到12月根本不可能发行一个象样的产品～” A君心里说，“不到3月份，根本就不可能”，但是A君什么也没说。 “12月～”BB咆哮着。大家都垂着头，仿佛BB正用枪指着自己。“12月绝对不行。A君，我希望明天早上知道你对项目新的估计。我现在要求每周工作 <#004699'>65个小时，直到项目完成。项目必须在11月1日前完成。” 当他离开会议室时，他听见了嘀咕声，“授权——呸，骗子～” 接下来的事 会后，B君问A君:“你准备采取什么措施来结束这个项目,” “我们需要冻结需求，然后重新分析需求，重新设计和重新编码，也就是推翻重来。”A君冷淡地说。 “在11月1日前你能办到吗,”B君惊异的大叫着，“我看不行，赶快回去，检查和修改编码上的问题”。 A君说:“11月1日当然不行，需要到3月份。不重来，解决不了问题。” B君说:“绝对不行～” A君没再说什么。几天后，A君发现B君被降职了。 „„ 公司的销售额在飞速下降，客户因为在最后一分钟被告知他们的订单不能按 时履行而开始纷纷取消订单。公司被迫对市场重新进行分析评估，分析产品定位是否合适，等等„„等等。 备忘录乱飞～ 人员大量流动～ 公司的政策朝令夕改～ 公司的外部形势极为严峻，内部气氛空前紧张 „„ 最后，在3月份，经过长时间的每周<#004699'>65小时的高强度工作，A君的项目组终于弄出来了一个性能不稳定、功能不完善的产品版本。软件的BUG之多，使技术支持人员即使竭尽全力也难于应付生气的客户的抱怨和要求。 没有人高兴～～～ 结论 尽管这个故事过于讽刺挖苦，但我认为与实际情况的偏差并不很大。这里所发生的事在一家公司里不一定都发生，但是在许多公司中，这些事是都确实存在的。瀑布过程的问题可以用一句话总结。瀑布过程不产生管理开发过程所需要的可靠的数据。 分析和设计不是可以被完全测量的活动，因此，你永远不会知道是否完成了 它们。如果你不知道你何时完成一项工作，那么进度计划将告诉你什么时候你完成了它们。从此得到的所有管理认识就是项目在按进度进行。在另一方面，编码实现可以通过测试来验证完成。因此，只有等到编码完成之后，管理人员才意识到他们原先的计划可能是不充分的。 正如我们所见，在瀑布过程中，分析和设计也是不充分的。当编码实现进行到相当程度时，它与设计已经相去甚远了，更不要说分析了。厚厚的分析和设计文档通常被搁置在文件架上，落满厚厚的灰尘，很少有人去看它们。 迭代增量开发(2) Iterative and Incremental Development (IID) 在上一讲中，我们研究了瀑布开发模型，并且研究了这种开发模型的一些缺点，在这一讲中我将介绍另一种开发模式，来看看它是如何克服这些缺点的。 在开始之前，我想说明一点看法:瀑布开发模型是70年代早期时出现的。在那个时期，人们对软件的结构几乎根本不考虑，而只是考虑怎么编码实现它。瀑布开发模型至少有一点不可磨灭的贡献:它使我们接受了在编码之前需要认真思考，进行分析设计的思想。 瀑布开发模型问题的总结 从上一讲中所讨论的项目所表现出来的各种问题，我们可以归纳出瀑布开发模型的三个主要缺点: 在各阶段之间没有反馈。一旦分析完成了，所有的人的工作就必须转向设计。一旦设计完成了，所有人的工作又都转向了编码实现。 为各阶段定义了僵化的期限。完成分析和设计的日期是被设置用来检查项目进度的主要里程碑。 无论是分析，还是设计，都没有明确的、可验证的完成标准。 让我们来依次分析一下这三个问题。 在各阶段之间没有反馈 尽管Winston Royce博士清楚地说明了在项目的各个阶段之间必须有反馈机制，许多开发管理者都忽略了这一点。忽略分析和设计之间的反馈等于说:在对所开发的软件的结构和行为完全不了解的情况下，我们可以预先对整个系统作出完整的分析。尽管这很诱人，但是大多数情况下，这是骗人的。为了强调这点，Booch引用了Gall的一段话: “一个可以工作的复杂系统总是从一个简单的系统演化来的„„一个根据胡乱分析设计出来的复杂系统不可能会工作，也不可能通过打补丁的方式使它工作。你必须从一个可以工作的简单系统开始” 我们是弱小而可怜的人类，我们还不具备在我们的大脑中完整地把握一个复杂的系统的能力。为了能真正地了解和分析这些复杂系统，我们必须能够真实感受它们、摆弄它们、进入它们的内部和不断使它们演化。没有后续阶段反馈信息的分析只能是一个假设，一种基于经验的猜想。系统越复杂，这种分析就越象是在建造空中楼阁。 为各阶段定义了僵化的期限 在瀑布开发模型所有的可怕的特性中，这一条是最令人痛苦的和对项目成功最具杀伤力的。当管理者发现软件开发可以被分成几个阶段时，他们自然的反映 就是为各个阶段设置里程碑日期，来跟踪和控制项目。尽管从项目管理角度来看这是很合理的，但是实际上这是一种最恶劣的开发过程管理方式。 项目组在分析过程中不是线性工作的。他们不一定先分析需求1，然后分析需求2，„„因此你就不可能通过检查分析人员当前在处理第几个需求来测量分析工作的进展。分析工作经常是“革命性”的。在对需求的某个重要部分思考之后，一些富有创造性的分析人员会得到一些对应用软件的认识和观点。这些认识和观点可能是正确的，也可能是错误的。如果是错误的，沿着它继续下去会导致新的错误。这是创造性工作的特点。我们从错误中学到的远比从成功中学到的多。分析工作就象是在布满错误荆棘的道路上蹒跚前进，我们可能走错路，然后在退回来从新寻找新的道路，直到我们找到正确的道路为止。因此为这一过程加上一个完成期限是可笑的，因为它无法测量，我们不知道我们何时才能找到正确的道路，进度也就无从谈起。 那么，是不是说，软件开发就根本不需要有进度计划了呢,当然不是～我们可以为软件开发制定进度计划，但制定计划的对象不应是分析这类无形的东西。 没有完成标准 对分析和设计阶段规定完成日期最危险的事，也是最具讽刺意味的是:这些期限要求经常可以被满足～这不是因为我们的工作已经进行的很充分了，而仅仅是因为分析和设计阶段完成的唯一的标准就是——它们的期限。 “按照进度计划分析工作应该完成了，所以我们必须停止分析，进行设计。” 没有方法可以告诉我们分析和设计是否已经真的完成了。分析不断持续下去总是可能的。而设计真正完成也仅是在代码本身不在变化的时候。判断分析和设计是否完成是一件毫无意义的事。因此，当分析和设计阶段到了期限时，管理者 通常会收到好消息——“分析工作按时完成了～”——但是这种“好消息”实际上是谎言。这种错误的信息，可能使管理者盲目乐观，进而可能在这些错误信息基础上做出错误的判断和决策。 反馈:通用的控制机制 我们的身体是如何调节我们的呼吸的,那是因为当我们血液中二氧化碳的浓度上升时，相应的信号被发送到大脑来提高呼吸频率。 为什么星星永恒般地闪烁了亿万年,那是因为不断扩散的能量足够维持恒星的质量。 为什么无论是上坡还是下坡，导航控制系统总能使汽车保持以同样的速度行驶,那是因为导航控制器感应汽车的速度并调节流向发发动机的油量来保持速度的平稳。 所有这些系统，无论是自然系统、演化系统，还是人造系统，它们都使用了相同的机制来保持控制。 这种机制就是反馈。 为了对软件开发项目保持控制，我们也需要使用类似的反馈机制。真正控制一个软件开发项目的唯一方法就是持续地对它的过程进行测量，收集项目过程数据，不断地比较计划和计划的执行情况，然后调节开发参数来校正计划的偏差。 听起来很简单。不幸的是，在实际中，过程测量通常不能被持续地进行，而且我们可以调整的开发参数是少之又少。 实现持续测量的途径 既然我们不能持续地对项目过程进行测量，我们就必须在一些特定的里程碑处进行测量。我们设置的里程碑越多，我们就越逼近持续测量的效果。但是，我们必须小心仔细地选择我们要测量的对象。如果我们选择象“分析完成”或“设计完成”这样的对象进行测量，测量将是毫无意义的。 Tom Demarco对项目管理有这样的评论: “你的项目，整个项目，有一个可执行交付项。在计划完成日，项目要么交付一个用户接受的系统，要么不能交付。每个人都知道到那一天应该完成什么。构造一个项目模型的目标就是将项目划分成多个组成部分。每个组成部分都有相同的特征:每项活动必须通过一个有完成标准的交付项来定义。交付项要么是被完成了，要么没完成。” 一个可执行交付项只有两种状态:完成和未完成。显然分析和设计不是可执行交付项，它们可能永远被证明完成了。 垂直切片(Vertical Slice) 当我们采用迭代增量开发(IID)模型开始一个项目时，我们的第一个目标是将项目划分成多个可执行交付项。这些可执行交付项被定义为整个项目的可执行的片段。 图 1显示了如何进行切片划分。项目以两个已知的数据——项目的开始日期和结束日期——开始。实际上，结束日期是任何项目最先知道的数据。 市场压力经常使我们在有一组合理的需求之前就确定了项目的结束日期。你可以对这一可恶的事实进行任何形式的抱怨，但是现实就是这样。我们必须面对它。 另一个我们要应对的丑恶事实是需求在整个开发阶段，甚至在已经过了项目结束日期之后，一直不停地变化。实际上，需求文档可能是项目中最反复无常的文档。同样，尽管我们憎恶这一事实，但现实情况就是这样，我们必须面对它。 为了创建一组可执行交付项，我们首先进行某种非常高层次的分析。这种分析有一个非常特殊的目的，并且规定了一个合理的结束日期。这种分析的唯一的目的是将项目划分为一组垂直的可执行交付项，即，进行切片划分，每个切片是可执行的，并且是与需求一致的。这种分析需要的时间取决于项目的规模，但是通常应限制在几天或几个星期的范围内。这里要记住的是你选择的切片不一定是在你最终完成项目时的切片。象其它预测性质的工作一样，切片划分也是一种猜测，它也可能有错误。因此不要花费过多的时间去试图使它很完美。 选择切片的标准包括: 切片必须是垂直划分的，即切片不是子系统，切片应尽可能地根据系统的功能进行划分。例如，一个IO 驱动子系统或者一个IPC框架不是一个合适的切片，切片应实现一个use case或一个use case的一部分。它应是你能展示给用户的某种东西，用户可以使用它完成某项业务。 切片必须代表系统的特性，以后我们可能为了满足进度而决定消减项目的部分内容。在消减时应能消除整个切片，而不是部分地消除许多切片。 切片必须是可执行的和可验证的。切片必须有完成和验收标准。用户应能够明确地得出切片是完成了，还是没完成的结论。 完成一个切片的周期应控制在几天或几个星期之内，而不是需要几个月。通常不要超过2个星期。切片的划分要与你的人力匹配。 这些标准是理想的，实际中，不是每个切片都能满足上面的条件。但是，预先进行的高层次分析应努力使大部分的切片满足这些标准，迭代过程能否成功就依赖这一点。 迭代 一旦完成了切片划分并编写了验收标准，项目经理就可以选择第一个切片进行开发。这个切片应是风险最大的切片或者它是所有切片中最复杂的、最容易出错的切片。这样做的原因在于: 我们希望尽早地知道这个项目是否会成功。因此我们首先处理风险最高的问题。 我们希望尽可能保守地来校准估计模型。因此我们希望第一个切片是需要时间最长的一个。 当然，当在整个项目的进行过程中，你会发现有比你选择的切片更复杂或风险更高的切片。这不要紧，主要的思想就是尽可能选择一个你知道的风险最高的切片。你可能会发现选择这样的切片有时不太可能，因为这个切片可能依赖其它 更简单的切片。在这种情况下，你应首先完成这些简单的切片。但是应尽早地引入高风险的切片。 项目的人力可能超过完成第一个切片的需要。在项目进行过程中，你当然可以同时进行多个切片的开发，但是通常对至少前两个切片应顺序地进行。项目组将会从最初的几个切片中获得项目的许多信息，学到大量的知识，这些信息和知识可能会在后续的开发中为我们节约大量的时间。 切片是被孤立地开发的，即开发者不关心它们与其它切片的关系。分析、设计、实现和测试切片，开发单个切片的过程好像就是瀑布开发模型。在某种意义上，是这样的。但是，这是Winston Royce预想的瀑布开发模型，而不是被这些年了歪曲了的瀑布开发模型。 在分析、设计和实现之间的反馈机制都在起作用。开发者将以一种紧密的循环过程进行开发:分析一小部分、设计一小部分、实现一小部分。Booch 称这种紧凑的迭代过程为微循环(Microcycle)。 每次迭代结束时的可交付项是: 一个满足验收标准的可执行交付项。 可执行交付项对应的分析和设计文档 切片不是里程碑 将项目划分为切片然后迭代地开发它们的目的是为了获得项目数据。 我们希望知道开发一个切片需要多少时间。因此，我们不对单个切片的开发设置期限。必须拒绝这种诱惑～如果你试图为单个切片开发设置期限，你将得不到真实的项目数据，并使进度失控。 这不是说我们不要设置目标，或者说项目不可管理。正如我们马上要看到的，项目管理是在比切片开发更高的层次上进行的。 持续估计 当第一个切片完成时，我们就得到了几个项目数据: 我们有了一段我们知道能工作的代码，换句话说，项目的一部分真正地完成了。 我们有了所完成部分的分析和设计文档。 我们知道完成这个切片花了多长时间。 使用最后一个数据，我们可以进行一个简单地计算。我们可以用这个数乘上剩余切片的数量就可以估计出项目的结束日期。 当然，这是一个非常粗糙的估计，误差很大。但是，这个对完成日期的估计毕竟是基于真实数据进行的，总比完全凭空猜测要好的多。 显然我们不应根据第一个估计就做出任何重要的决策，这时的误差还太大。然而，这个估计已经可以开始帮助我们来评估原先制定的项目计划是否合理，是否需要变更。 完成了第一个切片后，我们开始第二个，再接下来我们可以考虑增加项目人力同时进行2个或3个切片的开发。实际中，人力增加不要太快。这些早期的切片将产生代码的基础性结构。如果同时进行过多的切片，这种基础性结构就没有机会形成。 在开发第二个切片的过程中，工程师可能会发现第一个切片的结构可能存在 错误。这时，对第一个切片进行修正的工作被纳入第二个切片的开发中。所有的分析和设计文档同样要被更新。因此，第二个切片的开发可能比第一个需要的时间长一些。实际上，每个切片都将修正前面的切片中存在的分析和设计错误。项目的结构性基础就是这样形成的。通过在切片中包含形成这种结构的时间，使分析和设计变更的时间被考虑了近来，使我们对项目的进度估计也会更实际、更准确。 一些人可能会说:如果项目中有人有点先见，这种“重复劳动”是可以避免。也许如此。但是，有先见之明的人很少，而且这些先见之明往往是不准确的。对一个大型项目，我们不太可能真正地预先想出最终的软件结构 在迭代增量开发中，我们在早期切片开发上下的工夫实际上就是某种先见，并且我们利用设计和编码来及时地验证我们的这些先见是否正确。 当切片一个接一个完成时，估计误差会变得越来越小。几个切片开发完成之后，一般我们对整个项目就能有相当的把握了。当然，也许这时带给我们的不是什么好消息，但是这总比在项目的快结束时才听到类似的坏消息要好的多。 我们越早发现问题，我们的选择余地就越大。 对一个项目从头到尾进行控制 项目经理可以使用三种不同的控制维度来管理项目:人力、范围和进度。 如果在几个切片完成后，我们发现估计出的项目完成日期超过了项目计划规定的完成期限，项目经理这时有三种选择: 增加人力 通过减少功能缩减项目范围 改变进度计划，延长完成日期 如果所有三个控制维度都不可调节，那么没有项目能成功。因为如果在项目开始时，三个维度都被限定，那么项目将是不可管理的。项目经理没有任何选择和回旋的余地，他只能向上帝祈祷。 记住，通过切片产生的估计是在项目生命周期的早期出现的。 如果我们决定增加人力，它不是在最后一分钟决定的。我们将有时间来集结和训练新的项目成员。 如果我们决定限制项目规模，我们将有时间与我们的客户进行协商。 在极端不情愿的情况下我们决定延长项目完成日期，我们也有时间与客户协商这种变更。 如果你不喜欢这三种选择中的任何一种，你还有一种选择。那就是象上一讲中提到的，你可以不停地在项目会议上威胁你的工程师们，强迫它们加班工作。但是我保证这是最坏的选择，只会使项目进行的更慢，甚至万劫不复～ 迭代增量开发过程关键是它能产生关于进度的项目数据。切片的完成时间为我们提供了对项目进度明确的测量，帮助我们预测项目何时能够完成。项目经理可以使用这些项目数据去做一件漂亮的事—— 有了这些数据，项目经理可以„„管理～他们可以停止命令、停止劝说、防止失控。 总结 不希望这篇文章误导你。即使你遵循上面的建议并且开始用迭代增量方式开始项目的开发，问题也不会立刻全部消失。进度仍可能会被延误，BUG、问题和不可预见的意外仍可能发生。 Software is, after all, software; and software is hard4>>. 然而，你应该立刻开始使用一种能产生项目数据的开发过程模式，有了这些数据，项目经理才可能真正地管理项目。 在这一讲的开头，我提到应该感谢瀑布开发模型教会了我们在编码之前应该思考。难道现在我们要放弃这点吗,根本不是～编码之前应该思考是必须的，只不过现在我们是以一种小的增量来思考，并通过代码来验证我们的思考的正确性。在下一讲中，我们将讨论怎样具体的操作，以及早期的客户反馈、抛弃切片和构造可重用框架等方面的问题。 迭代增量开发(3) 在上一讲中，我们了解了迭代增量开发过程的一些基本知识，包括如何将一个软件项目划分为垂直的切片、在每个迭代循环中如何进行分析、设计和实现工作、如何通过单个切片的完成时间和切片的数量来估计整个项目的完成时间、分析和设计文档是如何随着每个切片的完成被不断完善的，以及如何使用开发过程提供的反馈信息来管理项目的规模、进度和人力资源。 这一讲我们将深入到IID内部去探索一下它是如何被用在采用瀑布开发模型进行管理的项目中的，包括如何用里程碑来管理项目、如何使用户更早地参与，如果早期的切片有很大的错误会发生什么和如何管理可重用框架的创建等问题。 “包装瀑布开发模型” Parnas告诉我们:永远不可能有一个完全合理的开发流程，因为: 通常，用户不能确切地知道他们到底想要什么，也不能清晰地表达他们的想法; 即使我们能够将所有的系统需求清楚地陈述出来，还有很多系统的细节只有在我们真正实现它们时才会被发现; 即使我们知道了所有的细节，系统中还存在着大量一时难以理解掌握的复杂性因素。 即使我们能够理解掌握所有的复杂性因素，还存在一些超越项目控制能力之外的外部因素。这些因素会导致需求的变更，一些变更甚至会完全否定先前的决策。 人类建造的任何系统都会存在人为的错误。 当我们着手每个新项目时，我们通常会应用先前类似项目得到的经验去进行分析和设计，这有时会对我们有帮助，但有时也会成为包袱。设计时，还会因为为了使用已经存在的软件或组件背上不必要的经济包袱。这两种情况都容易使我们过分依赖过去的经验，而忽视了新项目真正的系统需求，进而做出了错误的决定。 Parnas 评述到:“因为上述原因，软件工程师仅从需求的一个描述中导出一个合理的、没有错误的设计是不现实的。” 但是Parnas认为“包装瀑布开发模型”是可能的和合适的。 假设你的项目组目前采用瀑布开发模型进行开发管理，并且在短期内不可能改变它。那么是不是意味着你要被迫要放弃IID呢, 根本不是～实际上，IID可以被用作瀑布开发模型之下的一种迭代机制。 将代码作为分析和设计的工具 考虑下图，它显示了一个已经被划分为迭代性切片的项目。在最初的几个切片的开发中，我们主要是在研究问题域。尽管我们也生产代码，但是这时的代码是我们正在获取的知识的副产品。那些知识才是真正和问题相关的。用户通过观察这最初几个切片所表现出的行为来加深他们对问题的认识，并且增加新的需求、去掉无用的需求和修改旧的需求。简单地说，这就是分析。 问题分析地一种途径就是构造问题域的模型，并且根据用户的期望检查这些模型。但是，另一种非常有效的进行分析的方法是构造可以执行的项目增量切片，并让用户检查这些切片。无论采用哪种方法，我们的工作都集中在问题域中，主要的工作是理解我们要解决什么问题。 代码是相当有效的分析工具，它可以被当作一种能非常准确的预测需求并根据用户的期望验证需求的工具。因此，在一套切片的某个点上，我们可以说分析完成了。实际上，分析是永远不可能绝对地完成的，这里说“完成”是指经过充 分地时间后，分析已经足够的充分，可以作为瀑布开发模型设计阶段工作的基础了。 相同的技术可以用在设计上。一旦我们真正地进入切片的创建工作，开发的焦点就从问题分析转移到寻找解决方案上了。在这个阶段我们要寻找合适的系统体系结构。切片的工作内容被聚焦到寻找解决问题域中的问题的最佳方法上。因此，代码又被用作设计工具。一个个的切片不断将新知识添加到软件体系结构上。 记住，在每个切片的开发过程中，我们都会发现在前面的切片中存在的一些错误。我们应该立即重构这些早期的切片，并将这部分工作作为当前切片开发任务的一个组成部分。这样，系统设计就会随着迭代过程的进行变得越来越精致，越来越稳定。 当系统的体系结构稳定下来时，我们可以认为对应于瀑布开发模型的设计阶段的工作完成了。“稳定”是指从这个切片之后的迭代中，不稳定的因素已经很小，对早期切片的改变也很少再发生了。现在，问题已经被确定了，体系结构也稳定了，我们剩下的工作就是编码实现了，我们就可以进入瀑布开发模型的实现阶段了。 应当注意的是在IID流程中任何点上的活动，或换句话说每个切片的开发过程是没有差异的。每个切片根据它自己的需求被开发。从一个切片到另一个切片，在流程操作上没有什么不同。然而，随着切片不断增多，开发人员对项目的理解变得越来越具体了，把握也越来越准确。 总结一下上面的流程，分为三个步骤:首先分析问题域，然后寻找相应的解决方案，最后是实现。因此，如果你的项目组仍在使用瀑布开发模型，你也可以使用IID来包装瀑布开发模型。事实上，你可以得到所有必须的工作产品。 例如，在分析结束时，你可以产生一个问题域的模型。在完成了解决这些问题的切片后，你将处在创建这模型非常有利的位置上。因为你几乎没有进行任何猜测性质的工作。你所构造的问题域模型就是已经实现了的切片所告诉你的内容的复述。类似地，在设计结束时，你可以产生一个设计文档，它描述了项目的设计。这个文档将十分准确，因为它是直接从切片构造演化出来的。 如果从更高的层次来看这种开发流程，它看起来非常象瀑布开发模型。唯一的差别是你使用代码作为研究问题域和解决方案域问题的工具。你使用切片作为一种手段，来收集瀑布开发模型分析阶段和设计阶段所需要的关于问题域和解决方案域的知识。 设置里程碑 瀑布开发模型一个对管理人员特别有吸引力的地方是它能够让项目管理人员为项目设置里程碑日期。 使用IID，这仍可以办到。但是，在IID中的里程碑与瀑布开发模型中的有非常不同的含义。在IID中，一个里程碑不在是某种承诺的确认，而是一个决策点。 在IID中我们使用的流程能够产生项目数据，这些项目数据可以告诉我们计划执行的情况如何。在IID中，我们不承诺在一定的时间要完成那些切片，而是使用一个或几个切片所花费的时间来估计完成所有切片需要的时间。这就为我们提供了一种实际的测量项目进度和预测完成日期的手段。 但是，人为项目应该没有里程碑是不现实的。实际上，应该有而且必须有里程碑～这些里程碑可能有令人舒服的名字，如“分析完成”或者“设计完成”，因此从更高的层次看就好象我们正在采用瀑布开发模型。这些里程碑可能是完成 特定的工作产品，或者就是个日期。不管里程碑是什么，它的本质是某种类型的事件。 IID与瀑布开发模型的不同之处在于我们处理这些事件的方式。我们不将里程碑看作某种承诺的确认。项目组不承诺完成所有的里程碑规定的任务，而项目管理者承诺通过里程碑管理项目以得到一个可接受的结果。项目管理者将里程碑作为触发决策的事件使用。 这些决策应事先写下来，并且经常地进行复审。当一个里程碑被超过时，项目相关的人不应该大惊小怪; 例如，假设我们有一个项目，它在2001年9月1日有个里程碑。这个里程碑没有一个具体的完成标准。它只是一个日期，在这个日期我们要进行某种决策判断。下面是这种决策判断的一些示例: 如果切片7完成了，按照计划继续进行。 如果切片<#004699'>6完成了，那么从计划中去掉切片12。 如果切片5完成了，那么从计划中去掉切片12和15。 如果切片4完成了，那么从计划中去掉切片12和15，并在10月1日前增加一名工程师。 如果切片4没完成，那么取消项目。 使客户尽早地参与 在IID的“分析阶段”，用户或用户代表的参与是至关重要的。当我们的客 户能够确实地接触和感受项目时，他们会不断地判断和决定他们所看到的东西是不是他们真正想要的，如果不是，他们就会提交需求变更请求。 这是好事情～我们希望需求变更越早发生越好。我们希望客户能够确信我们正在构造正确的软件。因此项目计划在这个初始阶段可能会有点动荡不定:一些切片被增加进来，另一些切片被去掉，大量的切片变动剧烈„„ 随着时间的推移，“分析阶段”逐渐接近完成，用户会逐渐减少变更的数量。但是，想让他们完全彻底地停止变更是不可能的。实际上，随着用户的环境和业务问题的变化，他们很可能增加变更请求的数量。 每个需求变更都可能会影响项目中的一组切片，它会影响一些已经完成的切片和即将完成的切片，也可能会增加或去掉一些切片。但是因为我们已经根据完成切片的时间测量了我们的“开发速度”， 我们将能够比较准确客观地估计出每个变更对进度的影响。 当与用户对项目进度产生分歧时，我们可以向用户提出接受进度变更或推迟变更的具体建议，这有助于提高与用户协商成功的可能性。使用户尽早地参与项目，实际上是加强了我们对用户的控制能力。用户永远不应只根据一些“神秘莫测”的文档来理解项目，他们应该积极地参与到项目的开发中。 当切片发生错误时„„ 当然，使用户以这种方式参与进来意味着我们要进行一定数量的重复劳动。实际上，在问题域和解决方案域稳定下来之后也还会有返工的。有时当项目组决定重新实现整个切片时，返工的工作量是很显著的。只要不是很频繁，这不是坏事。 一旦我们能够清楚地确定一个切片是错误的，我们就应该毫不留情地抛弃它或重新实现它。对项目的早期切片和那些定义了关键体系结构元素的切片尤其要 这样做，因为我们不希望这些错误危害项目后面的工作。保留它们等于迫使每个人都在围绕错误的体系结构工作，这会严重拖延整个项目。重构和修复它们才能消除了我们前进路上的障碍。 有人可能说:难道我们不能分析和设计上多下些工夫，这样就会消除或减少这种重复劳动。这种说法是站不住脚的～ 当一个切片发生了错误，这些错误是毫无争议的。但是当一个分析模型或设计模型发生错误时，我们通常直到我们实现了它们才会发现这些错误。因此，当切片中的错误在它们产生更大的危害之前能被尽早地发现和修复，而分析和设计模型中的错误在被发现之前，我们已经在它们的基础上建立了其它的模型或进行了某些项目决策，这时我们要返工的东西就更多了，很可能使整个项目流产。 管理可重用的框架 这很自然地将我们带到了创建可重用框架的主题上来了。这样的一个框架应该永远不是一个切片，或者一组切片。一个被它自己开发的可重用框架是不可重用的。一个可重用框架需要在应用程序切片的上下文环境中进行构造。并且如果可能，是多于一个切片的。 如果你要构造一个可重用框架，那么你要小心仔细地选择切片。通常，这些切片是包含了丰富的用户要求的特性，并且是横跨整个系统的，而不是实现子系统。切片开发人员要想在创建可重用框架上进行合作，他们就必须坚持只将被多于一个切片重用的东西放入框架中。你永远不要只因为“这是个好主意”这样的理由而将任何东西放入框架中。放入框架中的东西一定是被两个或两个以上切片重用的东西。开发人员应该就如何对可重用元素进行抽象进行协商，以保证可重用元素能被每个切片正确地访问。 总结 最后，我们对这三讲的内容进行一个小结。 在这三次讲座中，我们讨论了瀑布开发模型的失败之处，说明了如何将一个项目划分成可迭代的、增量形式的可执行交付项，论述了如何估计项目完成时间和如何管理项目以得到一个理想的结果。 这里推荐的方法和策略不是完美无暇的。它们不能解决所有的软件开发问题。软件仍有可能会被延迟发布，仍可能会变得复杂的难以控制，仍会很难被开发完成。 Software is， after all，Software>. 这里介绍的开发流程最核心的一点是它是一种能够提供项目数据的流程。我相信，这一点是一定会为你带来实惠的。记住: 一个能够产生项目数据的流程才是可管理的，可改进的。不能产生项目数据的流程是不可管理的。