软件开发

本文是2002 年4 月在完成XX项目后, 写的一篇总结。

当时公司的项目管理体制还没有现在这么完善, 本人的认识也十分有限, 所以以下的文字读起来不免会贻笑大方。 但是下面的这些文字是完全从实践中得来的, 这样来看这篇文章,就会发现其纯朴可爱之处, 并且希望读者可以从中更好地体会到项目管理的重要性。

在做过一个简单的项目之后，为了不使自己把项目中的感受忘掉，所以做此纪录。其内容，一是项目开发中，每个阶段都有一些需要注意的问题；二是整个项目中都要围绕的三个要素。 最后在第三章中写了其他应该注意的事项，或者是在整个项目中都存在的事项。

一、项目的要素
做一个项目，在整个项目进行过程中都必须要考虑到如下三点。这三点在项目的进行过程中，要时刻把握，不断地对其检查。

1、成本

动机：成本，一般在项目初期就已经估算好了。但是，项目进行过程中难免遇到增加成本的地方（减少是好的），这就需要我们不断的跟踪项目成本，防止成本扩大化。

解释：项目成本增加的最大因素在于追加功能或者对预定功能的实施所需成本估计不足。另外一点，在项目中为了按期完成项目而追加小组成员也是导致项目成本增加的一个重要因素。

改善：上面提到了三个增加成本的因素，对于这三点大致可以使用如下方法来进行改善。

i. 追加功能导致项目成本增加。
对于这一点，主要是防止功能扩大化。即在项目实施的过程中，一定要按照需求说明中所定义的功能去实现。而
其中最容易犯的错误就是，因为一个功能点很小，在需求中没有表现出来，而在实施中任意添加上。这应该是绝对不允许的。尤其在项目初期，由于项目本身扩大化的特点，在项目初期一个很小的功能，可能会造成在以后编码、测试
阶段工作量成倍的增加。为了杜绝这种情况，可以在需要增加功能的地方，做上标记，或留待下期（如果有的话），或在项目后期再对其检查，考虑增加后所需的成本，如果不得不添加，就应该将其作为一个风险点，进行跟踪。

ii. 估计不足导致项目成本增加。
对于这一点，一般是尽可能在需求设点的时候详细考虑，对于无法深入考虑的点，将其设定为风险点，进行跟踪。对于项目风险系数大的项目，这种风险点可能会很多，那么建议将其分类。如高风险点，或低风险点。

iii. 赶进度导致项目成本增加。
这点是很可怕的。当然在项目初期预计好项目进行时间、阶段是很必要的。当然，会存在估计不准的情况。然后导致这种情况发生。（如果客户允许延期很好）所以，当项目初期估计不足的时候，这点是几乎不可避免的。这点，导致的后果一般有两个——加班和加人。如果碰巧两个都需要，那真是太不幸了。但是保守的说，如果让选择现有人员加班或增加人手，我以为加班比增加新人要更为合算一些。

说到这里，就是，我们一直在说项目初期做好时间估计，就会避免这种情况。那么为什么会估计不足？凭经验来说，主要是因为中断处理。所谓中断处理，就是一天八小时，一周五天。实际工作时间可能不足这些的一半。而人们往往低估了中断所需要的时间。如果你已经意识到这点，那么恭喜你。但是你也可能忽略了中断所造成的更深层的影响，因为中断不仅浪费了时间，而且会打断你的思路，扰乱项目进行的节奏。而所有项目成员的精力都耗费在可能在任何时候退出项目，又必须在任何时候让自己回到项目中来的窘迫境地。你是否考虑到了呢？

所以说，在项目进行时间估计的时候，估计一天六小时，一周四天是必需的。但是如果你碰巧以为你的小组成员都是机器，一天十小时，一周七天的话，那真是太不幸了。中断包括，开会、生病、工作期间喝茶、上厕所、和别人聊天、家里有事情、老板找你、担心工资而导致心情不好、因为其中一个成员生病而使得相关的成员工作不能进行、因为工作不能进行不是自己的原因而导致心情不好……

2、时间

动机：任何一个项目都必须在一定时间内完成。（在其他生产资料不变的情况下）如果时间越短项目所需的成本越少；时间越长，成本越高；当时间超过了预计，成本可能成倍增加——这是我们所不愿看到的。

解释：其实我无非是想证明时间是项目实施的一个重要的要素。对于控制时间，阶段性的检查是必要。

改善：关于时间问题其实很简单，任何有项目经验的都知道，定期做检查。而在本文中也处处体现时间跟踪的重要性。所以还能说什么呢？就是Please do it. 在DO 中要注意两点：

i. 设计时间
定期的检查也需要时间；以小组形式开发项目过程中，开会的时间比你实际相象的要多。

ii. 文档化
任何在项目进行中形成的问题、观点、意见如果没有形成文档，都没有用。因为你无法对其跟踪、比较。

3、质量

动机：提高软件质量是必需的。其表现在优质的软件会带来更多的项目，赚更多的money。控制软件质量，使得后期维护费用大大降低，而在开发过程中，优质的设计，使得编码成本、时间相应降低、缩短；优质的编码使得测试的成
本、时间相应的降低、缩短；优质的测试使得维护的费用相应降低。反之，成倍增加。

解释：风险度低，开发经验丰富的小组开发的软件质量肯定比风险度高、开发经验少的小组开发的软件质量高。这是毋需质疑的。所以关键的问题是，对于开发风险度高、而相对经验较少的小组如何提高其软件质量？改善： 迭代开发。即首先开发系统核心部分，再依次慢慢追加新的功能。这样可以降低项目风险，避免项目后期因改动较大而又来不及完全测试而是软件质量降低。不过，其中要注意的是需要避免过早追加功能。过早的追加功能以及对还为实现的部分过于乐观的估计，都将为以后的开发埋下祸根。即导致时间延期、功能扩大化等。而另一方面的结果是功能不足。其次，review 也是提高软件质量的办法。时刻保持着时间跟踪，通过检查风险点，检查项目实施进度等方法纠正项目将会出现的偏差，使项目依照先前的设计顺利进行。

二、 过程

1、需求

需求分析是整个项目中最重要的一个环节。比较容易犯的错误是，往往对需求分析重视不足。
一旦需求固定了以后，整个项目开发过程中都必须围绕这个需求来进行。而对需求不重视的直接后果就是，功能扩大化和功能不足。功能扩大化就是在开发过程中任意添加“小”的功能点。功能不足主要表现在迭代开发中，由于一开始开发原型比较顺利，而对以后的开发过程过于乐观，最后导致在项目进入下一个阶段前必须的功能没有实现，或者没有对项目进行必要的跟踪，在项目交工前才检查，而发现还有功能没有实现。这都是极度危险的。
为了防止这两点，就要对需求分析结果（式样书）给于足够的重视。一个建议就是将需求分析结果构造成一个功能点（function point）树。设计每个功能点将如何实现，尽可能详细。对于没有办法细化的功能点（可以认为是对这类问题以前没有经验），标注为风险点（risk point），并将其分级（heigh or low），且决定在何时解决此点。因此就要对风险点进行跟踪。同时也会出现引入新的风险点的情况，一并考虑。

2、设计

设计时最重要的两点是：

一、整体设计围绕需求进行。

做设计时，最容易出现的情况是在需求做好后就将其抛到一边，凭借大脑中的印象来做设计。其关键是设计的每一部分都应该是围绕需求的。跟需求无关的部分要去掉，防止功能扩大化，尤其设计时的问题可能会带来以后成倍的工作量。在需求中的东西一定要加上，不要因为很小，或者想着实施很简单就放到以后的步骤中去。也就是说，所有功能点都要在设计中体现出来，任何在大脑中的东西都是不可靠的，必须付诸文字。

二、多次Review。

设计时的原则一般是找到跟此系统类似的系统，然后仿作。这应该是提倡的。尤其是曾经多次运用过的，修改过的系统。而设计者常常在设计时，忽略的这一步。
对于新的系统，假设很难找到与之相对应的系统（在网络上几乎有成千上万的case），则需要我们自己设计。那么迭代开发的威力又显露出来。即先行开发系统最基本的功能。然后依次添加新的功能。这时候，一定要注意review。即在添加新的功能时，要review 整个系统。一直到没有功能需要添加时，包括所有需求中定义的功能的整个系统中，每一个功能都是按照预想的方式实施。而经常被忽略的是添加新的功能后，不去review 以前的设计，导致互相影响，成为一个失败的作品。
最后，再要补充一点，我们在设计时看过很多介绍如何做设计的书，书上讲的不错。但是在一个侧面这导致我们产生了一个最坏的观点——我们需要design，而一般design 则多根据自己以往项目的经验。但是，事实情况是，现实社会中，充满了大量的设计case，和这个设计相类似的case 不尽其数。我们需要的只是拿来，修改（甚至几乎不用修改）。去寻找一个类似的case 其实很重要。

3、编码
如果在前两步作的非常好，那么这步其实并不重要。而相反的，我们常常把前两步作的推迟到这步来做。这是非常可怕的。其中一个最恶劣的影响就是回退。往往由于这样，而使我们的项目不得不重新退回到设计阶段。而更可怕的是，我们往往没有意识到这种回退，以为项目仍处在编码阶段，而事实是，设计已经改变了。
这里还要注意的一点是，前面提到的风险点。在编码阶段，正常来说，风险点应该不存在了，他们是在设计阶段被解决的。应该是完全不存在了，但很容易导致的失败就是这里。我们往往把低风险的点放在这里，但是，请注意，低风险的点在某种情况下仍然会转变为高风险的点。这种措手不及经常发生，但很少有人去追究它的原因。因为这些低风险的点发生在，“这个好办，我们到时候……就可以了”而往往这些低风险的点是纠缠在一起的，解决某个低风险的点的方法经常与另一个互斥。所以，付之文档是必要的。跟踪时间时的review 是必要的。
最后，请不要提前进入这一阶段。工程的时间压力是迫使我们过早进入编码阶段的一个原因。另一个是我们急于证明design 的正确性（往往在新系统开发时）。
原型开发是解决这一问题的办法。

4、测试
编码阶段结束的标志是使你的系统在正常状况下可以成功的运行所有需求中的功能，而不是写完该写的代码。
由于开发中将前两步的任务压缩到编码阶段，从而导致把调试的任务加到测试的头上。后果是系统质量，以及相应的环节不能实施。如，性能测试或重构。理想状态，我们希望高质量的系统，那么性能测试是必要的。而一般来说，如果我们只需要完成客户的要求而不用去考虑维护和升级或二次开发的问题，那么我们完全没有必要去做这些额外的工作。事实是，如果需要考虑维护或者二次开发的话，我们在分配测试时间的时候，我们将性能测试等时间安排在这里面，然后实施的时候，由于一开始提到的原因，使我们没有时间作这些工作。而如果我们从一开始就认为没有必要去做这些工作，那么一般是我们连测试的时间都没有！
明确测试是重要的是很不容易的事情。尤其是在当前测试体制还不很完善的情况下。如果我说，设计和编码要50%的时间，测试需要50%的时间，你会怎么想？因为我说的是，需要自己设计测试方案，写自动测试机，测试不同环境。譬如一个驱动程序的测试也许是80%的时间。
我以为一个稍具规模的公司能投入一定的成本开发一套自动/半自动测试程序是很必要的。

三、 TIPS

1、扩大化
扩大化的意思是，在项目进行中，随着时间的推移，任何错误（当然，所有问题都被扩大了）都会被扩大化。清楚地认识到这种扩大，并有效的防止是必要的。如何防止错误的蔓延？ 时间跟踪是唯一有效的办法——不断的确定当前存在问题并确定解决的时间。

2、责任
在team 开发中，责任很重要。每个人都应该有明确的责任，不应该存在某个问题不知道是谁负责的或者是两个或两个以上的人负责。作为team leader 应该清楚每个小组成员在默认情况下自己就清楚自己的职责是不可能的。而事先分配是必要的。随时给任何一个小组成员增加新的职责是愚蠢的。
理想的办法是，在项目一开始就确定每一个小组成员的职能，在项目实施进程中不再变更。当然这是最好，而事实是，任何人在一开始都不能预料到将会发生什么，所以应该在有新的需要负责的问题出现后，在第一时间指定负责人。而最好在项目开始时，预计将会出现的问题，而需要给某个组员增加任务时，事先通知本人，使其有接受新任务的心理准备。突然被通知需要对某个问题负责时，会严重影响组员的士气。
对于某一小组成员负责的部分，应尽量不被其他小组成员干涉，包括team leader。而这就会造成某一小组成员开发的问题影响整个项目。如何解决？跟踪是必要的。可以让小组成员定时向team leader 报告进展情况。对于，会出现问题的地方，可以召开小组会议解决。交流是必要的。

3、Check point
在项目过程中，我们要进行时间跟踪。其中包括，对上一步的review，对项目进度的review，对功能点的review，对风险点的review；制定下一步的方案，讨论项目进度提前/落后的原因，并制定解决方案，并预计将会发生情况对项目进
度的影响，讨论每一个功能点的实施情况，包括没有实现得如何实现，讨论风险点，包括上一步去掉了那些风险点，降低了那些风险点，增加了那些风险点，升高了那些风险点，并且如何有效的去除这些风险点，和应该在那个阶段去除。
这些check point 很重要，并且在小组举行这样的讨论时要付之文档。而且这样的讨论只应该增加而不要减少。交流是必要的。项目的时间压力很可怕，但是也不要忽略这样的讨论。那么如何解决这个问题？提高工作效率是最好的解决办法。如何提高工作效率？保持高的士气，并且使每一个组员在每一时间都知道自己要干什么，以后将如何进行，给予信心和希望是重要的，明确责任是重要的。