软件项目本来就复杂，而复杂的软件项目若无细心的规划就不可能成功。一个良好策划过的项目会被有效控制着，其进度操控自如，且会照顾到参与项目进行者的福利。软件项目本质上也是危险的，缺乏风险管理就不可能获得成效。从头保持跟项目的使用者联系，努力将产品维持在满足客户的要求之上，并尽全力把焦点放在找出项目关键问题的解决方法上。

小项目可以只靠着毅力与运气而完成，中型和大型项目则需要更多系统化的做法。本文将概述一些让中型项目达到成效的技巧。

规划

许多技术工作者宁可直接做自己的工作而不想花时间规划一下工作方向。许多技术主管缺乏足够的技术训练并且不相信自己可以规划出改善项目的方式。由于两边都没人对项目好好规划，结果就是项目常常窘况百出。

没有一套规划方式是项目中最严重的错误之一。由于上一篇中描述的上下游效应，想在修正成本较低的上下游阶段将问题解决掉，一套有效的规划方式是必要的。一般项目约80%的时间花费在未经规划的重复工作上。

软件开发的成功归功于让所有错误变成一堆细心规划过后的小错误，避免出现未经规划的大错误。研究四种设计方式后，放弃其中三种，最多也不过是造成三个小错误而已。可是没做好设计工作而必须把程序重写三遍的结果，却严重到可能造成三个大错误。由于在下游阶段修正上游造成的错误比在上游阶段就修正好问题要多花费50～200倍的代价，细心协调过的项目就有机会以1/200～1/50的代价将许多错误修正好。

项目中哪里找得出时间来进行规划？很简单，把大部分项目花在未经规划的重复动作上的时间中的一小段拿来用在项目初期的规划上，避免之后将时间花费在高代价的重复动作上。尽管并非所有上游阶段用去的时间都会确实省去下游阶段该处理的麻烦，但是省下的麻烦还是很多。在上游阶段质量保证的经验法则是：用在进行技术检阅等早期规划工作上的一小时可以省下下游阶段3～10小时的工作时数。从不同的观点来看，一名开发人员每天花在项目要求规格或架构上检查的时间一般会省下后一阶段中3～10天的工作时数。

软件规划的例子

一个项目团队该如何规划项目，以在一定预算内完成软件？底下是一些项目规划的具体工作项目：

◆一个软件开发的规划反映项目进行的方式。把规划方式记录下来可以让项目的资助者透过这份规划来了解项目。

◆项目评估提供了项目规划的基础。一份仔细的评估可以确切地定出项目的规模，从而确切地定出预算上限、人员需求与时间需要。差劲的评估会低估项目在各方面的需要成本，使项目难以顺利而有效地完成。

◆在每个主要阶段末尾作个修正评估，可以中途修正项目成本，并让项目的进行以稳健的步伐前进。

◆一份包含技术审查与测试的质量保证规划，可确保项目不会被代价高昂而找不出错误的测试、除错和修正周期压垮。

◆一份详细规划出软件构建的方式，可确保软件解决方案有效地在各阶段以提高对客户价值和降低风险的方式进行。

除了以上这些明确的规划方式，软件项目的几个主要活动也可以被规划处理。

◆详细订出项目团队试着要解决的问题，确定正确解决问题的方式。

◆构架设计出解决问题方式的大体规格，建立正确的解决方案。

◆细节设计是关于如何建立项目软件的综合规划，以正确的方式建立正确的解决方案。

规划审查

规划方式对项目的成功是如此的重要，一些专家说项目的成败完全决定于项目初期10%的时间内。不管确实比例是10%还是多少，在项目的最早期，项目团队应该已经订出使用者接口雏形、细部要求跟包含成本与时间预估的细部项目规划，而这些信息可以用来决定要不要让项目进行下去。

两阶段出资方式

一些组织中对软件项目经费的问题在于项目主管在完成一些探索性的工作前就得要求上头支出必要经费。这样的请款要求必然失准，因为对软件了解不足。软件业界的经验是，在项目初始阶段的估计或多或少，可能会跟实际的要求差距达四倍。

一个较好的办法是让项目主管把经费要求分作两个阶段。项目主管先在项目完成初期10%到20%的探索阶段要求第一次经费。到了阶段结尾，项目团队进行一次规划审查，同时资深管理阶层或是客户决定要不要继续推动项目，然后再拨项目剩下的部分经费。这时项目成本仍有可能变动，不过先前已经完成的部分会让整个成本变动范围从四倍缩小到50%左右。

准备规划审查

在进行规划审查之前，得先要有下面的准备：

◆决定好项目关键决策者
◆前景叙述
◆该软件的业务状况
◆初步努力与时程目标
◆初步努力与时程目标估计
◆十大风险列表
◆使用者接口风格简介
◆使用者接口细部雏形
◆使用手册/使用需求规格
◆软件质量保证计划
◆软件开发细节规划

上述每一项准备在本书其他部分会更详尽的解说。

如果这些项目都没准备好，表示还没有足够信息来决定项目的质量如何，就不用进行
规划审查了。如果项目团队一直都没能够做好这些规划审查的准备，失败的风险很大。

做好这些准备所需要的时间依据软件所需要的工作量而定。当一般使用者知道他们要的软件是怎样的情形下，这个准备时间可能只需要软件总开发时间的10%。一般情况下，这段准备时间会占总开发时间的10%～20%。在一些项目中，这项工作最困难的部分是帮助一般使用者理清他们要的是什么，所以偶尔这部分的工作会占用总开发时间的25%以上。对规划审查的经费要求与计划应该将这项工作的变动考虑进去。

规划审查的一般项目

规划审查应该集中在下列各项目上：
◆本来的产品概念仍然可行吗？
◆发展一个满足项目前景叙述的产品可能吗？
◆该软件的业务状态在更新、更精确的成本与时间估计出炉后依然差距不大吗？
◆项目的主要风险可被克服吗？
◆使用者与开发人员都能够同意使用者接口的细节雏形布置吗？
◆使用说明/使用需求规格是否完整而稳定，足以支持更进一步的开发工作？
◆软件开发计划是否完整，并适合进行更进一步的开发工作？
◆完成项目所需的预估成本为多少？
◆完成项目所需的时间安排如何？

在项目开头10%～20%的完成部分应该足以解答这些问题，而且这些问题的答案应该足

以让客户或上层主管决定是否要继续拨款进行项目的后面阶段。

规划审查的主要好处

让软件组织将软件项目经费分成两阶段处理至少有三种好处。首先，被取消的项目常被看成失败的案子，可是一个进行了10%～20%就取消的项目反而应该视为彻底成功。完成80%～90%才被取消的项目所耗用的经费足以负担许多在探索阶段进行10%～20%就取消的项目。

再者，将庞大的经费延迟到项目完成10%～20%之后再拨款的话，可以对项目所需的庞大经费做出更可靠的要求。

最后，要求项目主管先完成项目的10%～20%才能要求拨款进行下面的部分，可以让这些主管做好与对项目成功息息相关的上游工作。这些工作往往被省去或忽略掉，带来的损失只有到项目下游阶段必须花费昂贵的成本来修正许多错误时才会突显出来。如果项目团队被要求在下游工作之前完成最重要的上游工作，项目的整体风险就会大大地降低。

风险管理

风险管理是一种特殊的规划方式。进行过大中型软件项目的人都亲身体验到许多事情都可能出错。最成功的项目就是采取积极步骤以免屈服在这些问题的困扰之下。你也许是完美主义者，可是对软件项目而言，就如人们说的，你可以有最佳期望，但是应该要有最坏准备。

几种最严重的软件项目风险与规划方式息息相关：

◆没规划好。
◆没照着规划方式做好。
◆没在项目环境变化后修正好规划方向。

在软件项目中不采取积极的风险管理就是忽视软件业界在过去几十年中从几千次教训

中总结的一个经验：软件开发是高风险的活动。如果项目采取积极风险管理的方式，就可以避免或降低许多风险，而这些风险有许多如果没处理好，就可能使项目陷入瘫痪中。

本文求生策略中包含（并在本书其他部分谈到）的做法比起其他方式风险更低，并能够增强对其他类型的项目风险的发现与控制，而被选录。对软件项目中要不要采取风险管理策略，你没什么选择余地。如Tom Gilb在《软件工程管理原理》（Principles of Software Engineering Management）一书中所说的，如果你不积极面对软件项目中的风险，你就会碰到这些问题。

项目控制

本文的一个主旨是，软件项目可被控制，从而迎合时间、经费跟其他目标。对一些人来说，这种项目“控制”的点子简直惨无人道，令人想象起一名专制的项目主管以皮鞭和铜链展现威权的样子。

--------------------------------
项目“控制”的反面就是项目失控。
--------------------------------

人们也许，会认为项目即使没人控制方向，也会顺利地进行下去而不会失控。我的想法和经验都告诉我那是不可能的，

有些人反对项目控制，因为他们认为这表示控制项目成员的行动。事情并不是这样，项目控制所控制的是项目本身。下面是一些我所指的“控制”的意思：

◆选用一种软件生命周期模型，如本文中使用的阶段完成模型，给项目中技术性工作一个轮廓构架。
◆管理需求的改变，只接受必要的改变。
◆确立设计与程序写作标准，使设计方式与源代码以彼此一致的方式产生。
◆建立项目的细节规划，使每一名开发人员的工作朝项目目标前进而不会防碍到其他人的工作。

控制并不是良好的技术性工作的附属品。项目控制必须透过积极的项目管理与持续渐进的控制行动来落实。项目控制的具体行动将在本文其他部分谈到。

项目洞悉力

与项目控制密不可分的是“洞悉力”的概念，这是指决定项目真实状态的能力。项目是否进行在时间、预算目标的10%范围内，项目是否按部就班地达到质量目标，或是远远落后目标？如果项目团队答不出这样的问题，这支团队就缺乏足够的洞悉力来控制项目。

下面是一些改进洞悉力的方法：

◆用前景叙述或目标来订出项目的概括目标。如果你不知道项目的行动方向，项目大概就推动不了了。
◆在项目完成10%后做一次规划审查，看看项目可行与否，以决定是否该完成这个项目。
◆经常比较实际进度跟规划进度，以决定规划方式是否有用，是否需要修正。
◆用二元完成点决定该做的事情是否完成。完成点只有“做好了”和“没做好”两种状况，因为事实证明，从“完全做好了”让步到“90%完成”只会让项目状态信息的质量从“很好”降到“极糟”。
◆定期将产品做成可推出状态，以决定产品的真实状况，并控制质量水准。
◆在每个阶段末尾修订估计数据，依据这些新信息来改善规划方式，并更进一步了解规划方式中的假设状况。

许多项目团队最后发现项目洞悉力并不是自动得来的。如果你想要有良好的项目洞悉力，得从一开始就把这一点放在项目规划中，而如果你想要有个成功的项目，你就得有良好的洞悉力。

人因工程

软件开发需要创意和智能、原创与持久再加上高度的干劲。任何对软件开发有效率的做法是，如果项目团队没进入状态，项目就不可能成功。成员们进入状态，但是他们有可能士气低落，或是缺乏一个可以让麻雀变凤凰的灵感，甚至连团队的核心都可能在推出产品之前就离开工作岗位。

Tom DeMarco与Timothy Lister让“人因工程（peopleware）”这个显示出在软件开发过程中人类成员才是最重要的字眼变得热门起来。如果你不是名软件开发者，人因工程的一些准则也许会吓倒你。

照开发人员的兴趣分派工作

一般来说，软件开发人员的最大动力就是工作能与个人兴趣相符。如果开发人员发现工作有趣，他们就会发挥高度干劲。如果他们觉得工作很无趣，就会趣味索然。Robert Zawacki研究了十五年后指出约60%的开发人员的生产力来自个人有兴趣的工作上。要让人们发挥最佳生产力，请依据开发人员的个别兴趣来分派工作。

---------------------------------
有些人的干劲来自不可能达成的目标。
可是开发人员有时太钻牛角尖了，如果目标达成不了，反而会让他们失去干劲。
---------------------------------

让开发人员知道你真的欣赏他们的成就

就像其他人一样，开发人员也喜欢别人对他们的赏识。如果项目主持人真心赞赏开发人员，他们对项目就会更加投入。如果主管对他们的赞美虚伪而做作，他们也以虚应对。不要用敷衍手法、离谱的目标或金钱诱惑来挑动开发人员的干劲。

提供思考导向的办公室空间

软件开发既要有发现也要有发明，缺一不可。整体过程中最好的环境就是既轻松又可以自在思考的场所。开发人员要如同数学家或物理学家般聚精会神。试想如果爱因斯坦坐在办公桌前听着他的主管责骂他说，“爱因斯坦，我们现在就要看你的相对论！快把它写出来！”你想他做得到吗？（译注：爱因斯坦发表相对论时还只是个邮局职员）况且软件开发人员远不如爱因斯坦般聪明，他们需要更有助于工作的环境。

避免采用开放式工作隔间

有个老生常谈的论调，说开放式的工作隔间有助于软件项目间的沟通。问题在于这样的隔间沟通起来反而杂乱无章，连带影响生产力。有效率而良好的沟通还不如在茶水间放部汽水机来进行。开放式工作隔间有助沟通的论调乍听起来很吸引人，可是经不起确切考验，而且软件研究资料清楚显示开发人员只有在一两个人的办公室内最具生产力。

一些研究发现开发人员在隐密、安静、一两个人的办公室内工作和在开放式隔间的办公室内相比，前者的生产力比后者要高出2.5倍。软件开发是个需要高度思考的活动，如果电话响个不停，广播系统播个没完，人们在你四周走来走去，每隔几分钟就来打扰，怎么可能专心思考问题。

---------------------------------
身为主管的工作要求是每隔几分钟就转移注意力以达到管理效果。
---------------------------------

一般软件开发人员要求几个钟头内最好不要转移注意力，才能专心。许多组织没办法提供开发人员安静隐密的办公室。他们有的是空间不足，有的是要留给副总裁之类的人用。有些组织发现，将他们的开发团队安排到另一个环境去会更好些。其他组织则试着让开发人员带着耳机工作杜绝干扰，或者干脆让他们在家工作。至于其他没办法提供开发人员安静隐密而不受干扰的组织，只好自求多福了。

使用者参与度

软件使用者参与的程度对软件项目很重要。软件成功的关键在于设计出一般使用者爱用的产品。如果没有使用者的参与，软件开发人员常常会考虑技术层面而忽略使用者的需要。这样的话或许软件产品中塞进过多功能，使用者实际用到的却没几种。

要想开发出使用者爱用的软件产品惟一方法，在于问问使用者的是什么，把开发中的产品先告诉使用者，并问问使用者喜不喜欢这东西，聆听使用者的心声并参考他们的意见。

也许项目团队得努力好几次才能了解使用者要的是什么。使用者们也必须了解开发人员让他们看的雏形跟未来的成品也许相差十万八千里。有时有分辨出哪些可能是未来的“使用者”都有困难。这些都会在以后提到。

由于使用者的参与消除了一大变量——摒除了“差不多先生”的心态，这样一来项目所费的时间就少得多了。如果使用者没从头参与，以后对项目产品进行检视时，一定会指出有好些地方没照顾到他们的需要。这时开发团队就得面对一个艰难的抉择：依循原来的预算与时程目标而忽视使用者意见，或是在项目的下游阶段接纳使用者意见而让预算跟时间超出预期限制。通常开发人员会妥协，先采用可立即修正的使用者意见，而将难以立即采用的意见留到程序的下个版本去处理。说老实话，让使用者在产品还具可朔性时愈早参与愈好，而且最好是在那些不被喜欢的东西出现以前。

由于“做了比没做好，早做比晚做好”的观念，使用者对自己参与开发过程的项目反而比没让他们参与的期望更深。表面上，愈早让使用者参与开发的软件愈能满足使用者需求与期望，而这也成了一种质量的认定方式。实际上这样的软件缺陷的确更少，因为它们在开发过程中方向变动较少，而让产品架构、设计方式与实作更稳定。如果在项目中途才加入使用者需求，被迫将没想到的功能加进体质不良的现有构架中时，软件质量一定会大副下降。

除了及早参与、持续参与外，很少有软件项目一开始就找出真正良好的解决方案，一般都必须在使用者坐下来说“是的，这就是我要的软件”以前做出不同版本的使用者接口雏形。一个良好而成熟的使用者接口雏形可以让项目推出后广受欢迎，不过软件的适用性得在开发时就调练好。参照使用者所需导向而做低廉、小型的修正，就不用到了项目末期再大兴土木以致付出高昂的代价（本文使用的阶段性完成策略提供了这样的过程中修正方式）。

参予开发过程的使用者用不着很多，在Jakob Nielsen的《Usability Engineering》一书中指出，当软件适用与否的测试人数在3～9个时，价格获益比最好。

在1994年，Standish Group对8000件以上的软件项目进行检查。结论是使用者的参与是项目成功最显著的因素。在那些失败的项目中，缺乏使用者反应是失败的主要因素。计算机软件的专家指出快速开发项目能够成功的最重要因素在于让一般使用者全程参与开发过程。

----------------------------------
让使用者参与项目开发过程可说是重要的软件项目求生技能。
----------------------------------

产品简化主义

成功的软件项目开发从需求制定到产品推出、继而被接受，都需要一种“化繁为简”的定位方针。因为软件开发工作相当费神，若能将项目彻底简化必然事半功倍。功能规格、设计与实作都应该简化。许多开发人员沉迷与复杂性，误以为“数大便是美”，事实上只有简化项目才是成功的唯一出路。

当开发人员致力寻求项目目标流程的简化时，可说又向成功迈进了一大步，对一般使用者也可能造成影响。一个功能通常可分两小时版、两天版和两周版，开发人员应该一开始先弄出两小时版，通常这个版本的解决方案最简单直接，问题最少。开始实际操作后，如果解决方案还不够，他们才应制作两天版甚至两周版的解决方案，再看看这样是否可以解决问题。解决问题的一贯态度是，先简单后复杂，才不致于因噎废食。

法国作家Voltaire说一篇散文不是在“增一字则太多”时完成的，而是在“减一字则太少”时完成的。软件项目亦同，应该是从软件中去除不必要的东西以进行简化，而不是不断加上更复杂的东西。

焦点防在推出软件

有效率的开发团队全心全力着重产品的推出。微软公司尤其重视“产品推出”。对产品推出有功的开发人员会获得一个“产品推出”奖，感谢他们的努力。在微软工作了许多年的开发人员一般都有一大堆产品推出奖。这样简单的做法强调一件事，微软公司不是靠着开发软件赚钱，而是靠推出产品赚钱，当然这也是大部分生产软件的公司赚钱的方式。

对于无论是替内部使用者开发软件或对一般大众发行软件的开发人员来说，焦点是一样重要的。一个清晰的前景描述可以让任何软件开发团队对产品推出的目标相同。如果开发人员到了项目结尾都还对产品的看法有歧义，将被迫花费上许多时间、努力与金钱来让他们的看法一致。

一个清楚的架构也有助于让开发团队在目标上步伐一致。反之，就难以同心同德。如果一套良好的产品架构确立了，项目的开发焦点自然集中在技术层次上。

软件开发团队必须确保每个技术性决定都朝着简化系统功能的方向前进。如果是开发大学教育项目，也许有必要让项目任意复杂化。不过当团队在开发商用产品时，他们的任务是提供最简单的问题解决方案，任何违反这些原则的决定都应被否决掉。

本文所要传达的信息是软件开发工作本质上主要为了满足实际目标，这个工作有着浓厚的美学标准与科学成分。有效率的软件开发人员了解软件项目不是为了让他们有个筑梦堡垒，而他们也依此排定各项条件的优先级。微软公司的经验显示，这样得到的行动方针能够在项目团队中培养。没有共识的开发人员对于项目是一个累赘，对组织可说没什么用处。

====================================================================
求生检查