微软项目求生法则 求生心态之求生概念1（转）

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

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

“开发程序”的威力

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

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

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

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



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

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



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

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

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

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

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

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

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

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

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

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

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/7839396/viewspace-942018/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/7839396/viewspace-942018/