软件项目是发现与发明的过程。发现与发明融合为一的最佳方式是透过“阶段性完成”的做法，将产品的功能分阶段完成，而最重要的功能最早完成。当项目进行时，许多活动交互重叠，把产品有抽象概念转化成具体成果。项目进行中的源代码倾向以S形曲线而非线性成长，而大部分的程序代码都是在项目中间第三部分完成的。追踪程序代码的成长提供对项目状态的洞悉力。执行良好的项目也可以由一名上层主管选择最有效的一组来进行追踪。

本文描述一个成功的项目由两万尺的高空鸟瞰时的样子。它提供了通过不同的角度透视项目流程、人员、进展活动、程序代码成长与主要成效。

思考阶段

在讨论软件项目依照规划阶段分期完成的方法之前，我认为先对项目整个过程进行通盘了解会有用处。

软件项目如图5-1，被切分成三个概念阶段。在项目初期，焦点摆在“发现”，特别是发现使用者的真正需要。透过技术性调查、与使用者访谈和建立接口雏形，把不确定性的概念转换成确定的观念，这就是第一阶段的特色。


在项目进行中期，焦点移到了“发明”上。往大方向看，开发人员要发明软件构架与设计方式。细节的地方，如每个函数式或对象类别也不能忽略。

如同发现阶段般，发明阶段的特征在于将不确定的概念转换成确定的观念。如果还有别的特征，就是发明阶段的不确定性要高得多。在发现阶段，开发人员可以确定答案“就在”某个地方。可是在发明阶段，就不能以此类推。

在项目的最后部分，焦点又转移了，这次摆在实作上。不同于发现与发明阶段的是，实作阶段的不确定性少多了，故可发掘出许多已确定的观念并可实现成具体成果。

如图5-1所描述的，发现、发明与实作在软件项目中各自以一定程度进行着。太严格分段规划反而不能有效运作，好的项目计划必须让发现、发明与实作一起出现。

项目流程

在某些软件开发方式中，项目团队几乎是秘密完成开发的大部分工作。技术性项目常提供如“完成90%”之类的状态报告。对顾客来说，如果完成项目的90%就花去了90%的时间，那剩下的10%可能会花去另一个“90%”的时间。

本文提供的项目规划依循着“阶段性完成”的轮廓进行。由于她将项目中开发的软件分阶段完成，而不是到了项目结尾才一次完成，这种方式称做“阶段性完成”。图5-2说明了这种方式。


如你从这图所看到的，阶段性完成强调项目规划与风险降低。项目团队先发展软件概念，分析汇集需求；再完成构架设计。这些工作透过积极的风险管理与精心规划，朝着消除风险的目标前进。

在每个实作阶段中，项目团队进行细节设计、程序写作、除错与测试（以阶段1到n表示），在每个阶段都建立出可能推出的产品。这三个阶段也描绘在图中，不过你可能想随心所欲的操控项目的完成，有些项目可以只用三或四个阶段，而有些则有更充裕时间，使得每个星期都能推出新的软件。

分阶段完成的好处

阶段性完成提供下述5种好处。

1．关键功能更早出现。

阶段性完成的项目中各阶段一般都先规划产品最重要的功能。如果使用者期望特定功能，就表现出他们不想等到产品完工了才看到这些东西，他们只想在第一阶段就先睹为快。比起一些仓促完工的冒失项目，阶段性完成对一个有着时间压力的项目可说是个宝贵的做法。

早期降低风险这种做法强调项目的规划与风险管理。将产品分阶段完成并随时整合起来的方式，可降低项目末期才整合失败的技术性风险。同时将可用的软件尽早提供给一般使用者参与，借着产生具体进展成效来降低管理风险。

2．早期预警问题

当你及早计划各完成版本的软件时，你就会提早得到明白的进度报告。无论各个版本是否如期推出，工作质量可明显从推出版本看出。当开发团队碰上了麻烦，你也会先知先觉，不必等到项目“完成90%”了还摸不清头绪。

3．减少报告负担

阶段性完成也提供一个长久有效办法来消除开发人员花在建立临时性进度报告和传统的固定性进度报告。

=============================================
产品的动态比任何书面报告更能精确反映项目状态。
=============================================

阶段性完成能提供更多选择。项目团队在每个阶段末尾评估可推出产品并不代表产品非推出不可，不过如果真的有必要，产品可以随时推出，而且将产品完成到待命状态，所需的功能应有尽有。如果你没采用阶段性完成的做法，你就没有这种选择。

4．阶段性完成可降低估计失误

阶段性完成可通过对推出产品各部分功能逐步完成来避开估计错误的问题。与一次对整个项目做出大型评估相比，项目团队可以灵活地分别对几个小版本做小型评估。在每个版本中，项目团队可以从评估中吸取教训，重新校正做法，并改善项目现况，使项目的未来预估更为精确。

5．阶段性完成均衡了弹性与效率

分阶段完成产品让项目团队有精确的时间来决定软件中该更改哪些东西，这些时间来自阶段衔接的空挡。在空挡内决定软件规格的变更，让开发团队不必一直考虑软件改变，却能保证让项目不致遗漏该考虑变更的东西。

阶段性完成的代价

从前述所列的好处中，阶段性完成的做法听来似乎毫无缺点，其实则不然。阶段性完成的做法要付出相当代价。因为项目团队需要时间准备各种可推出的软件，在每个阶段重复测试已经测试过的功能，推出软件前进行相关的版本管制工作，提供试用的不同版本软件没预料到的问题的解决方案（如果阶段性完成的软件真的拿出去给人使用），还有规划阶段性发行这种做法的好坏等等，都会提高项目的负担。

其中的某些代价并不真的是额外多出来的它们不过是让本来隐藏在项目末尾的一些成本提早显现出来而已，找出缺陷并修正错误就是这类的隐藏成本。阶段性完成项目的有些工作人员在一开始会抱怨他们把时间都花在修正错误上。实际上他们是在修理早晚都得修理的东西，而且这些在项目中先找出来的错误愈早修正，花费的成本就愈低廉。

其他代价也许是多余的，如对外发出很多不同版本的软件，会增加项目的整体负担和总成本。

===============================================================
阶段性完成并不是万灵丹，不过总合起来，那些额外的负担相对于明显
改善了的状态、质量与时间的匹配、精确预估与降低风险等来说，不过
是一点小小的付出而已。
===============================================================

规划阶段

图5-2的阶段性完成流程图说明项目早期活动，如需求分析与构架设计都是连续不断进行的。在投入构架设计的阶段之前先完成大部分需求分析工作，以及在进行细节设计与实作之前先定好整体构架，都是重要的事情。不过实际上，这些活动都是在同时间内重叠进行的，这是不可避免而且必然的事情。图5-3所描绘的，就是这种重叠进行的情形。


从本图中，建立项目团队应该在开始构架设计前先做好大部分需求开发的工作。在开始细节设计以前，应该先完成大致的构架工作。这么做，是由于错误修正的成本会随着时间的延后而提高。80/20比例的规则可以应用到这上头来：在开始进行构架工作前，先完成80%的需求开发工作，而在开始细节设计以前，先完成80%的构架设计。80%并不是随便选定的比例，知识基于一条良好的经验法则：这样可以让团队在明白表示不可能一次把这些工作完全做好时，还能在项目初期先满足大部分需求。

细节设计、程序写作、整合与测试差不多在同一时间内完成，因为阶段性完成的做法会在各阶段中产生设计、实作、整合与测试的小循环。使用文件的撰写会提早进行，因为使用者需求先被开发好了（这在后面的文章会提到），而且这些工作会持续进行，管理与规划也会持续处理。这样的复杂性也许会让人以为这种做法只适用于大型项目，不过实际上几乎任何项目都可以应用这些法则，只是程度上多寡的问题而已。

汇聚人力

从人力观点来看，在阶段性完成项目中应有两个阶段。在第一阶段中，项目还在酝酿中，团队正在开发需求和建构构架。在这阶段的整体努力程度一般被认为要低于主要实作阶段。前述项目完成10%～20%后决定要不要继续进行下去就是在这阶段中处理的。这一阶段的工作人员应该是技巧高超的资深开发人员。

第二阶段是阶段性完成时期。在这阶段中，项目团队处理细节设计、软件构件与测试。技巧高超的资深开发人员在这一阶段也扮演重要地位，不过项目也需要质量保证人员、技术文件写作人员和资历较浅的软件开发人员。

在项目后半50%里，你可以看出质量保证、细节设计、程序写作的人员要求保持相对顺畅。在一次做完所有事情的做法中，项目通常得花费更多人力，而且到了项目末期可用人力会变少。阶段性完成的饿项目则在大部分时间里有着较流畅的人力比例，使资金流向、雇用、训练、测试和运算资源的使用跟着流畅起来。
图5-3中所描绘的动态并没有真正显示出各项活动花费了多少时间，图5-4说明了一个项目中的这些活动所需时间的分布情形。


注意，图5-4的“发行”活动不像在图5-3中是分开列举的。它包含取得所有项目资助者同意发行的时间，建立项目的最后记录，建立项目的历程报告和其他项目结尾的活动。

图表中的具体数据都是依照经验法则得来的，所以不是很严格的数字。不过它们还是提供了一些实际的概念。需求开发跟构架的上游活动消耗了项目努力中相对较少的部分，而下游的构建跟系统测试活动则消耗了太多的时间和精力。上游活动对下游活动起着极大的杠杆作用，两者都需兼顾是很重要的。

图5-5补足了上图，说明项目活动间的典型时间分布图。


从这些图表中得到一个很重要的概念是，项目中进行某一活动的时间比例不会跟耗用的精力成正比。需求开发工作一般会耗去项目12%的时间，可是只占用6%的努力。由于上游活动比较抽象而需要更多的深思熟虑，所以必须以较慢的步调进行。

程序代码增长曲线

前面的图表应该已经说明在项目初期有许多不会产生任何程序代码的工作要做。其实项目的头三分之一是用来详细了解需求与发展高质量的构架方式，好让项目团队能够好好检测项目规格，然后一次把产品做好，程序代码可能会教慢写出来。项目中间的三分之一主要在建立项目软件上，在这一阶段程序码会快速产生出来。项目的后面三分之一，则将焦点摆在检查前面阶段写出来的程序代码是否上得了台面。这一阶段着重错误修正和根本程序代码的更动。如同开头三分之一，程序代码增加得很缓慢。图5-6描述了一个执行良好的项目中程序码增长的方式。

黑线表示正常的程序代码增长方式，阴影部分则表示正常变化量。在项目中期程序代码增长的变化量仿照过渡版本提升现有程序代码品质而产生的。图5-6中的项目在最后推出产品以前，推出两个过渡版本。


一旦你了解了程序代码增长的方式，你就能很精确的估计项目的现况。执行良好的项目每周都会记录项目的程序代码。如果你认为项目快到结尾，新程序码几乎也停止增加，这时项目就已经可以准备发行了。如果新的程序代码还不停的加入项目中，那项目就还处于执行中期的三分之一，还没接近推出的成熟阶段。

同样的道理，如果开发人员在他们完成构架设计前加入太多程序代码，你几乎可以保证会在系统测试阶段停留许久，那是为了要让开发人员修正他们在系统设计还不是很成熟时所造成的错误。

一些项目犯下的严重错误是将产品在只完成了85%左右时就发行出去。

如果项目主持人不了解图中所说明的软件开发方式，他们会假设新的程序代码开发量开始降低时就可以立刻把程序推出去发行了，特别是项目执行受到明显的时间压力时。这个将产品只有85%完成度就仓促发行的决定，表示软件终究未臻完善，这样的决定就像搬砖头砸自己的脚。

主要完成点与推行点
有时候，前几节中描述的一般软件开发方式可缩减成以图像表示详细的完成时间点和推出时间点。主要完成点以极高水平来追踪项目执行进度，图5-7概述了本文中使用的高层次阶段和完成点的划分方式。

这里的通用项目要点几乎可以应用到任何规模的项目上。实际上每个阶段的初步工作常可以比图中所说的更早开始进行，而后头的工作可以比图中所示的要晚结束。本图说明了每段时间中主要强调的重点都放在个别的活动上（图5-3已经更完整的提到过各项活动重叠的情形了）。


上层主管与客户有时对于软件项目中的完成点模糊不清、无法依据而感到泄气，不过如果你依循着本文建议的做法，以完成点的方式追踪项目进度，将可以对项目状态得到良好的了解。表5-1列出这些完成点与图5-7的高层次阶段划分方式相对应的详细活动。

表5-1 高层次完成点与推行点的划分方式
◆ 项目初期
□ 找出项目关键决策者
□ 建立、检视并按照前景叙述进行项目
□ 建立软件的业务状况评估
□ 建立、检视初步努力与时间目标
□ 团队中拥有2～3名资深开发人员
□ 建立、检视变更管制规划，定案
□ 建立、检视十大风险清单，并以此避开已知风险
□ 开始记录软件项目的过程
项目这时期所进行的工作没有的明显终结点。这时期的工作是用来了解项目规模而进行的。这时期耗用的时间和精力会随着项目的不同而有极大变化
◆ 项目开启/可行性研究完成

□ 质量保证主导者就位
□ 文件说明主导者就位
□ 找出重要使用者，进行访谈
□ 建立简单的使用者接口雏形，由使用者审查直到能被接受后定案
□ 使用者接口格式简介建立，经过检阅后作为日后说明文件的基础
□ 建立第一次项目评估（精确度在-50%～范围线+100%的范围内），检视评估记结果后定案
□ 建立初步软件开发规划，经过审查后，据以执行项目过程
□ 更新十大风险清单
□ 更新软件项目记录
项目在这部分的工作也是不受结尾限制的，而且依照项目性质而决定

◆ 初步需求开发完成
在这时期，项目中开放性结尾的工作都已经完成了，现在需要一些检查来决定要不要继续进行项目
□ 建立细节使用者接口雏形，经过检视后定案
□ 建立使用说明/使用规格，经过审查后定案
□ 建立软件质量保证计划，经过检查后定案
□ 建立细节软件开发规划，经过检查后定案
□ 更新项目评估（精确度在-45%～+75%的范围内）
□ 更新十大风险清单
□ 更新软件项目记录
到这一阶段中约花费12%的项目时间跟6%的人手精力。这些比例不包括在项目开启/可行性研究与初步需求开发上的工作时间跟努力成效的花费

◆ 细节需求开发完成
◆ 审查规划，决定要不要继续进行项目

□ 开发团队大致就位
□ 管理人员大致就位
□ 完成使用说明/使用规格后撤除撰写文件的人力（除非有别的文件产品要写）
□ 建立软件构架文件，检查后定案
□ 建立软件整合程序，检查后定案
□ 建立阶段性完成规划，检查后定案
□ 建立第一阶段的软件测试项目，检查后定案
□ 更新使用说明/使用规格
□ 更新项目评估（精确度在-30%～+40%）
□ 更新十大风险清单
□ 更新软件开发规划
□ 更新软件项目记录
到这阶段，约耗费20%的项目时间与14%的精力

◆ 构架完成

□ 开发团队完全就位
□ 品管人员完全就位
□ 初步阶段规划完成
□ 建立第一阶段的细节设计文件，检查后定案
□ 建立包括小型完成点的第一阶段的细节软件构建规划，检查后定案
□ 建立下一阶段的软件测试项目，检查后定案
□ 更新第一阶段软件测试项目
□ 建立第一阶段软件建立指示（产生档案）
□ 建立第一阶段软件源代码，检查后定案
□ 创造安装程序，检查后定案
□ 更新使用说明/使用规格
□ 第一阶段“功能完成”产品
□ 更新项目评估（精确度在-20%～+30%）
□ 更新十大风险清单
□ 更新软件项目记录
假设项目分三个阶段，到这阶段约耗用45%的项目时间与40%的努力成效

◆ 第一阶段程序代码完成
□ 各项活动同上
到这阶段约花费65%的项目时间与65%的努力成效

◆第二阶段源代码完成
□ 建立最后阶段细节设计文件，检查后定案
□ 更新所有阶段软件测试项目
□ 更新所有阶段软件源代码
□ 更新所有阶段软件建立指示（产生档案）
□ 更新安装程序
□ 如果软件是个业务系统，完成使用文件（清楚的使用说明），完成使用者训练，使用团队准备上路
□ 整合已完成的“功能完整”产品
□ 更新项目评估（精确度在-5%～+5%）
□ 更新十大风险清单
□ 更新软件项目记录
到这阶段，约花费85%的项目时间跟90%的努力成果

◆ 最后阶段源代码完成（如果分三个阶段，这就是第三阶段）

□ 建立发行检查项目，检查后定案
□ 所有成员同意发行产品，不再更议产品
□ 完成功能正确的产品
□ 完成功能正确的安装程序
□ 完成最后测试项目
□ 完成软件正本的复制
□ 项目成果媒介（源代码、建立环境等）归档存放
□ 更新最后软件项目记录
□ 建立项目历程文件，检查后定案
到了这阶段，用去100%的项目时间与努力成效

◆ 产品发行

有时人们会想，为何软件项目要花那么久的时间。表5-1中的推进项目清单有助于回答这个问题。每个推进项目都代表一些必须完成才能让项目有效推进的重要工作。

大部分执行成效糟糕的项目最后都得做同样的事情，由于它们缺乏管理
，执行起来也缺乏效率，最后花费代价更多却没得到什么好处。

人们抗拒“开发程序”的一个理由是开发程序导向的项目在一开始就让人们看到一张这样的工作清单，使他们觉得“把这些事情都做完的话，项目就永远做不完了！”事实是如果项目中不做这些事，就得花更久时间才完成得了。即使小型的项目也得处理表5-1中列出来的绝大多数工作项目，虽然有些工作在小型项目中做起来不会花什么时间。我们也不希望做那么多工作，不过对软件项目而言，忽视一定得做的事情恐怕会功亏一篑，而如果人们知道一个项目中从开头就有哪些事情必须做的话，每个人都会好过得多。

=================================================================
求生检查
项目采用阶段性完成方式。
上层主管、顾客或两者都依据程序代码增长曲线盯紧项目进度。
上层主管、顾客或两者都留心着主要完成点和推行点的达成。
=================================================================

【 发表评论 0条 】