良好的开发程序对软件项目的存在是重要而必须的。有了良好的开发程序，软件开发人员可以将大部分时间用在让项目更稳定的生产性工作上。如果开发程序规划不良，开发人员将会花费大部分时间修正错误。项目成败的关键在于拥有良好的准备工作，并让有见识的项目出资者了解，项目人员投注了足够的精力在准备工作上，以减少后续发生的问题。

任务开始前，你会看到最重要的演示文稿。本章描述让软件任务成功的关键要素。

“开发程序”的威力

这是一篇有效的软件开发程序的教程。“软件开发程序”这字眼可以代表许多不同的东西，而底下就是这字眼所要表示的事情：

◆把所有需要的项目记录下来。
◆使用系统化的做法来控制产品的增加与更改。
◆推动所有要求、设计与原始码系统化的技术性审查。
◆在项目初期就发展系统化的品质保证计划，其中包含测试计划、审查计划与错误追踪计划。
◆建立一套产品功能组件发展与统合的实作规划。
◆使用自动化源代码控制系统。
◆在包括需求分析、构架确定、细部设计与实作阶段末尾等各个重要过程完成后重新评估成本与时间的表格。
◆这些开发程序都有着明显的快速成效。

对软件开发程序的负面观点

“开发程序”这字眼被一些软件开发界的人仅当成一个不实用的词汇。这些人认为“软件开发程序”是死板、苛刻而没有效率的。这种看法的论点是，最好的项目执行方式是聘请你能找到最佳人才，给予他们要求的所有资源，然后放手让这些你找来的人处理他们最专精的东西。照这种观点，不受任何程序约束的项目才能够特别效率。持有这种观点的人把项目的推动过程想象成了如图3-1所描绘的样子：

抱有这种论点的人承认“工作脱节”或非生产性的工作占有一些份量。开发人员会做错事，他们承认这一点，可是这些错误可以很快有效地修正过来当然比“开发程序”所要花费的整体成本要少。

依据这样的看法，如图3-2，在项目中加上程序设定只不过是多余的，还会耗去生产性工作时间。

这样的说法有着直觉性的吸引力。在项目开始（图中暗灰色部分），对执行开发程序的关切用掉了一些生产性工作的时间。如果这种情形从头到尾持续下去（图中亮灰色的部分），继续花时间去执行开发程序就不合理了。

不过根据软件业界的经验，在中型项目中，图3-2所示的情形不会在项目中持续下去。没在开始建立有效的执行开发程序的项目在一段时间之后还是被迫建立执行程序，而且花费时间更多而得到好处更少。下面就是些愈早设定开发程序愈好的情形：

到了项目末期，项目团队面对的是小问题，像是要采用哪一种技术算法，或者要不要让使用者能够取消还没完成的动作等等。如图3-6所示，软件开发是个持续渐进的程序，将问题由大到小分开处理，从决定大势走向到解决个别的小问题。推动软件项目所花费的时间，就是彻底思考并解决问题所需要的时间。

本图中的角锥状图形为项目中决策方向未定的事务量。软件项目中对问题的决策尺度由大到小。除非团队成员完成了前一个阶段的大部分工作，不然无法知道一个特定阶段中到底有多少需要决定执行方向的问题。

项目团队最擅于处理大型的决策问题，不过有时无法预见（而且不可预知的）的问题会在后头因为大型决策不当而出现，若要中途取消一个行动则表示项目团队得重新设计一个常式、一个模块甚至一整个子系统。

在某一尺度的决策敲定后，应可以事先精确预估下一尺度将面对的决策种类。不过项目团队或许可以先做好前头的决定，但对项目后头的决策问题只可能作出一般性的猜测。如果你想知道软件开发的工作为何，了解项目团队所有该思考的问题，并明白一个团队得在充分了解下一个阶段工作的内容之前便决定好现阶段中所有的执行方向，就成了重要的事情。

不确定性的角锥对项目预估的意义

不确定性的角锥对软件项目的预估有着强烈的意义。它不光表示在前期阶段精确评估项目的困难性，还说明那在理论上不可能办到。在需求规格阶段末尾，项目的范围还得由一大堆在购架阶段、细节设计阶段和构建阶段要作出的决策所决定。宣称能够预估未定决策对项目影响有多大的人如果不是先知，就是对于软件开发的本质不太了解的人。

另一方面，寻求控制决策方向以符合项目预计时间或预算目标的人是明智的。只要你愿意痛下决心砍掉一些规划功能，在项目初期就确立精确的时间表和预算目标，并在之后一直按部就班。成功的关键在于以这样的方式达成目标要求，做法包括在项目初期设定明确而不冲突的目标，保持产品概念非常有弹性，并主动追踪控制项目中的开发工作。

==============================================================
在项目开头，你能制定实在的成本和时间目标，或是制定充实的功能
组合，但是你不能强求两边的目标都要达成。
==============================================================
作者：彭湃

◆使用本文做法的项目会有个相当精细的开发程序，不会带来太多负担。
◆软件项目常常比第一眼看起来的要大得多。多数项目的问题出在本身，而不是出在开发程序中。
◆比较好的做法是开始先设定较多的开发程序以供执行、再视情况调整，比开头毫无章法其后再追加额外程序项目要容易。
◆多设定些程序项目所花的成本与时间代价要远低于不重视这档子事。接下来，就告诉你为何如此。

上下游

好的软件开发程序可及早处理项目中的问题。

你有时会听到经验老到的软件开发人员提起软件项目中的“上游”跟“下游”部分。“上游”这字眼只是用来表示项目的开始部分，“下游”则是指项目的末尾部分。

“上下游”的分法对于思考项目上的问题是很有用的。开发人员在项目开始所做的，在末尾未必有收获。如果一开始工作处理得当，末尾的收获就会健全并有助于项目成功。如果开始工作做得不好，后来的结果就可能严重影响成果，不客气地说，甚至可能让项目无法完成。

研究人员发现诸如规格或架构上的错误，事后才修正会比一开始就修正错误要花费多出50～200倍的代价。图3-5说明了这种效应。

要能让规格中的一句话很容易变成几个设计方式，而这些设计方式之后能再变成几百行的源代码、几打的测试情形、许多页的使用文件、线上求助画面及许多技术支持部门的操作说明等等东西。

当项目团队有机会阶段性修正错误，立刻修正错误会比过一阵子再去修正受影响之处要有意义。这种在错误发生的阶段内找出错误并马上休正的构想称作“阶段围堵”策略。

============================================
成功的项目借由仔细审查、要求规格与架构来制
造机会修正上游问题。
============================================

在上游动作时还没写出任何程序，找寻及修正错误，虽然可能让项目“该做的工作”表面上看来被拖延了，实际上却刚好相反。这些工作是在替项目的成功铺路。

过多程序项目的错误会越发的增加项目的负担，不过缺乏程序规划的问题会让错误变成必须花费50～200倍的效率成本才能修正的大麻烦。因此宁可多设定开发程序事项，也比不做开发程序设定来得好。

不确定性的角锥

上游错误要多花费50～200倍的代价才能在下游修正的一个原因是，上游决定的范围比下游的要广。

在项目初期，项目团队面对的是大问题，例如要不要同时支持Windows NT或Macintosh或是只支持Windows NT就好了，还有报表格式是使用者自订还是固定格式。在项目进行中，项目团队面对的是中型问题：有多少子系统；如何按一般情形处理错误状况；或是如何把一个打印例程从过去的项目移植到现在的项目中。

最好的消息是，你猜猜看，这些生产力、质量与时程表现的改善花费的成本是多少？只花费了整体开发成本的2%的代价而已——通常每名开发人员每年约花费1500美金而已。

开发程序对创意与士气

对于系统化开发程序的一个反对意见是认为这样会限制程序写作人员的创意。程序员们确实很需要有创意，不过主管与项目主持人也需要让项目维持在可掌握的范围内，让项目进展看得出来，而且满足时间、预算与其他目标。

系统化开发程序会限制开发人员创意的说法，是由于对开发人员创意与达成项目目标管理两者之间一些矛盾的想法所致。两者并行不悖的环境当然是可能的，而且许多公司都已经做到了，就像建立一个能够同时满足不同目标间的协调并完成这些目标的环境一样可行。

注重开发程序的公司已经发现有效率的程序可以支持开发人员的创意与士气。在一个针对约五十家公司的调查中，发现只有少数开发程序导向公司的人将自己公司评为“士气良好”或“士气高昂”。在对软件开发程序付出更多注意的组织中，约有一半的人将自己公司评为“士气良好”或“士气高昂”。而在最注重开发程序的组织中，有60%的人将自己公司评为“士气良好”或“士气高昂”。

当程序写作人员最具生产力时，他们的感觉也最好。好的项目领导者建立清楚的目标远景，并利用一套开发程序构架让程序员们觉得自己拥有不可思议的生产力。程序员们讨厌阻碍工作的各种障碍，他们不得不抛开眼高手低、毫无章法的脆弱领导者。程序员们欣赏有远见、有见识与有魄力的开明领导者。

在此对开发程序与创意之间所谓矛盾的适当响应就是，本文中没有任何一个程序规划会以任何方式限制程序写作人员的创意，最多是提供一个支持架构，让程序员们能够自由地对相关的技术性工作发挥创意，让他们免于分心在那些消耗注意力的琐事上。

过渡到系统化开发程序

如果一支项目团队目前没采用系统化程序，一个最简单的过渡办法就是描绘出目前的软件开发程序的细节，将没用的部分标示出来，试着改正那些地方。虽然项目团队有时会宣称他们目前没有规划开发程序，每个项目团队实际上都有自己的开发程序做法（如果他们说目前没采取开发程序的做法，他们大概只是没有一套好的开发程序规划）。

最粗糙的开发程序做法一般是这样的：

1．讨论要写出怎样的软件。
2．写出些程序来。
3．测试程序，找出缺陷。
4．除错，找出错误的根源来。
5．修正缺陷。
6．如果项目还没完成，回到第一步。

本文提供了一套更精巧的软件开发程序。

建立系统化软件开发程序的障碍之一，就是项目团队害怕自己会在面对太多开发程序项目时出错，害怕他们执行这些程序后，会变得太官僚化，对项目执行造成太大负担。这通常不构成显著的危险，因为：

补救程序

幸运的是对这样凄凉的场景，还有些变通的补救办法，最令人高兴的是完全不用依赖那些“死板而没效率的开发程序”。（译注：“死板而没效率的开发程序”原文为rigid，inefficient processes，缩写成R.I.P，刚好跟请死者“安息”的rest in peace的缩写相同。）

当然，有些软件开发程序确实死板而没有效率，所以我不建议把这些处理方式用在项目中。本章要描述的是使用能够增进项目弹性与效率的那些开发程序。
当这些开发程序被用到项目中时，项目的工作效率比例就会变成图3-4中的样子。

在项目进行的头几周，程序导向的团队似乎比害怕使用开发程序的团队更没生产力，因为两边工作脱节程度都差不多，而程序导向的团队会花费较多的时间来执行开发程序，这项投资稍后就会在项目中显出成效了。

等项目进行到一半，先前就重视开发程序处理的团队跟之前比较，工作脱节的程度会开始降低，程序的执行也会开始顺畅起来。同时害怕使用开发程序的团队则开始明白工作脱节已无法掩饰，开始自己寻求补救办法。

等项目接近尾声时，程序导向团队正处于顺畅运作状态，很少出现脱节的情形，而程序的执行也感觉不出有什么费时。少许的工作脱节状况难免存在，因为为消除这些脱节现象所花费的精力实在不划算。当上述提到的开发程序都被执行后，程序导向团队比起害怕使用开发程序的团队会更早进入状态。

================================================
项目一开始对开发程序所做的努力终究有所回馈。
================================================

明确注重改善开发程序的组织，可以在几年中把产品的上市时间缩减了一半，错误发生率降低了60%～90%倍。在五年里，洛克希德公司（Lockheed）把产品开发成本降低了75%，时间则缩减了40%，而错误发生率也降低了90%。在六年半的时间里，Raytheon公司的生产力提升了三倍，投资回报率（Return On Investment，ROI）达到八倍。Bull HN公司在经历四年的软件开发程序改进后，投资回报率也达到四倍。Schlumberger公司在花三年半的时间改善软件开发程序后，把投资回报率提升到接近九倍。NASA的软件工程实验室在八年中把每个任务的平均成本缩减了一半，错误发生率降低了75%，同时大幅度增进了每个任务中使用软件的复杂度。类似成果也出现在休斯、Loral、摩托罗拉、全录与其他注重系统化改善软件开发程序的公司中。

◆变动控制：项目推行到一半时，团队成员同意非正式地做个由主管或客户直接提出来的大副变动。他们一开始并没有系统化地控制项目的变动，结果产品范围扩大了25%～50%以上，而预算跟工时也跟着追加了。

◆质量保证：在初期没设定好消除错误程序的项目，陷入了似乎永无止境的测试—改错—修改—重新测试的冗长循环中。项目末尾的测试结果找到了相当多的错误，“更好控制布告栏“上每天都开会排定不同错误修正的顺序。由于错误太多了，软件推出时还有许多已知（虽然不严重）错误。最糟的情形下，软件质量可能永远达不到推出水准。

◆不受限制的审查：项目中太晚发现的重大错误让软件在测试阶段还须被重新设计并重写，使项目在本来不受任何规划控制的情形下严重脱轨。

◆错误追踪：太晚开始追踪项目中的错误情形，忘了来修正一些已知的错误，而让这些可能很好修正的错误跟着产品一起推出。

◆系统整合：不同开发人员发展的组件到项目末期才整合的结果，使得组件之间的接口缺乏协调，而要花费更多精力才能让这些组件步伐一致。

◆自动化源代码控制系统：源代码修定控制建立太晚，让开发人员以外将自己的程序版本盖过源代码正本或其他人的源代码档案。

◆时程安排：在缺乏时间表的项目中，开发人员常被要求每周或经常重估剩余工作所需花费的时间占整体开发工作时间的比例。

一个起初就对各种开发程序漠不关心的项目，会让开发人员在此后觉得他们把时间都花费在开会跟修正错误上，而非用在加强软件功能上。他们知道项目进度脱节了，当他们发现不能满足时间底限时，他们的求生念头开始萌生，使他们退回“单独开发模式“——只求满足个人的时间底限。他们不再去跟主管、客户、测试人员、技术写作者跟开发团队中的其他人打交道，使得项目纪律荡然无存。

远远不如图3-1所示水准稳定的生产性工作比例、不太注重开发程序的中型项目一般都经历了如图3-3中所示的生产力变化方式：

图中，项目经历了推动中工作过节状况递增的情形。等项目推动到途中，团队才会明白工作脱节耗去了许多时间，如果能进行一些对应的开发处理程序是会有好处的，不过已为时晚矣，对项目的伤害都已经出现了。项目团队试着增加开发处理程序的功效，可是这样的努力做得再多也弥补不了工作脱节的严重情形。有时努力步伐太慢一样会让工作脱节得更严重。

较幸运的项目还可以在仍有残余的工作时间里把产品赶出来，不幸的项目就没办法在工作脱节之前完成产品。这种情形持续数周或数个月后，这些项目一般都会因为主管或客户明白项目推动进度受阻而遭到取消。如果你认为项目中的开发程序设定是件不必要的额外负担，想想看一件被取消的项目可能让你更划不来吧。