自由源码项目管理

项目管理和工程是自由源码开发中在很大程度上被忽略的问题。最近，Monty R. Manley 在 linuxprogramming.com 发表文章指出这一问题，但我对他的某些意见持保留态度。

 

简介

 

项目管理和工程是自由源码开发中的被忽略的重大问题。Monty R. Manley 在一篇题为《开放源码道路上的项目管理》文章中指出这一问题。他建议在自由源码(以我的理解，是指自由软件和开放源码)项目中采用更加传统的软件开发模式。我绝对赞同更好的工程实践是需要的。然而，我认为我们需要做的是，理解自由源码的操作，尤其是其中成功的实践，并从中发见符合其文化的工程实践。

 

Manley 的文章是发人深省的，并刺激我进一步思考一些曾经考虑过的问题。我曾经领导过一个自由源码的项目(gimp-print)，我曾经面对过很多这样的问题。在我的职业生涯中，我常常既是开发者也是发行工程师，也锻炼了一些这方面的观察能力。

 

本文中，我将探讨 Manley 提出的一些问题，分析在自由源码社区中如何应用这些方法，并提出一些建议，或至少指出一些在未来的工作中要注意的问题。

 

瀑布模型和传统的方法论

 

多年以来，在软件开发中采用的方法论是瀑布模型：首先是仔细的需求分析，开发组有步骤的制定一份功能(结构)说明，接着是概要设计，详细设计，然后才着手编码。编码结束后进行测试，然后才能发布软件。这看上去是很有逻辑的；只在理解后才开始构造。以这样严格的方式构造软件，工程师很明确每一步应该做什么。许多人提出了基本是基于这一模型的多种方法论；也有相当多的商业工具可以使这些步骤更机械化且不易出错。

 

据我理解Manley 的观点是，自由源码开发的一个弱点在于 (瀑布模型中的) 早期步骤 (需求和设计分析) 在很大程度上被忽略了。我不同意这一观点，理由如下：

 

1. 瀑布模型存在严重缺陷。
2. 自由源码开发确实有需求分析，只是使用了不同的方法。

 

首先讨论瀑布模型自身的缺陷。Manley 问道:

 

如果你不知道想做什么你怎么能写程序？

 

问得好。不知道做什么怎么去构造？没有一个正常人会考虑造一座桥而不知道要连接什么，交通流量有多大，地质条件如何以及一些类似的问题。软件会有什么不同吗？

 

通常不会。航天飞机项目的软件队伍一举成名，因为他们不用每周工作80小时就及时交付了bug-free 的软件。为医用监视器开发嵌入代码的程序员必须在同样严格的条件下按部就班的发布产品。在这些案例中，纪律严明的队伍的确是遵循了这样的模型：获得需求，经过反复的迭代设计和检查，然后才开始编码。在许多情况下，编码只是大规模的机械流程，早期构造中的 bug 受到相当的关注，因为这表明在前期有错误。但这一模型真的很高效吗？还是对自由源码软件或更商业化的软件更适当？我相信大多数时候它既不是高效的也不是适当的。

 

我刚才讲的两个例子都是任务苛刻的应用，软件只是关乎人命的大项目的一部分。这只是为了可靠性牺牲了创新的缓慢、小心翼翼的过程。比如这个医用监视器，程序员强调可靠性和正确性而不是新潮的图像，我不知道我是否和这样的项目有什么关系。大多数人直接接触到的大多数软件都不是这么苛刻的；它们只要有效的完成任务就行。

 

这不是表示我同意这种折衷，比如，像微软那样；他们过于极端，甚至