讨论软件开发的特征，需要站在一个大的背景下来看。我以前考过PMP，在PMBOK中，软件项目管理，是作为项目管理下的子课题来讨论的。看看下面这张图：

　　按照PMBOK的知识结构图，PMBOK已经告诉了我们那么大一个园。而要进一步搞好软件的项目管理，我们只需要再掌握相关应用领域的知识和实践，就ok了。

 

 　　这其实是大多数项目管理的理论，对于软件项目管理的看法，所有的项目，都是项目。软件项目与大多数其它项目，大同而小异。至于差异部分，往往被归入“风险管理”的领域，就算是“一切尽在掌握了”。

 

　　而事实上，软件项目与其它项目的差异是如此之大，以至于由量变而导致了质变，使得我们以传统的工程项目管理的方式来管理软件开发项目，注定是要失败的。

 

　　我们来看看这样一个关键词：“迭代”。这是其它的项目管理中，基本上不可能出现的概念，而在软件项目管理领域，却是几乎每一种方法学中，都要极力强调的概念。这就是最大的区别。如果我们能够搞清楚迭代的本质，也就能够搞清楚软件项目与其它项目的本质区别了。

 

　　在我看来，在软件开发的过程中，引入迭代，就是承认，软件开发需要承受大大小小的失败，而减少失败的办法，就是不跑步，不走路，尽可能的爬行，这样就算跌倒，也不会跌得太重。我们来看一个有趣的数据。这是我在竹笋炒肉的blog上看到的一段话。

 

　　1994年，由于其非凡的软件开发能力和优秀的软件质量，SEL成为第一个因软件过程的成就而赢得IEEE奖励的软件开发组织。与普通的软件开发组织相比，在同样的软件开发条件下，NASA所开发的软件的质量要好10到20倍。

 

　　这个成就是如何得出的呢？那么是怎样的项目呢？我搜索了一个google，找到另外一段话：

 

　　To put it a little differently, the average MIS shop would need about 14 calendar months and 110 staff-months to deliver a 100,000 line-of-code MIS system, and it would typically contain about 850 defects when delivered. The NASA SEL would deliver a system of that size with about the same amount of time and effort, but it would contain only about 50 defects.

 

　　也就是说，10万行代码的一个MIS系统，他们花了110个人月，一共14个月，才完成。平均下来，每个人每天大约需要写30行代码！如果这样也算成功的软件项目管理的话，我以后只要将所有的项目工作量估算，乘以10，就能同样拿到IEEE的奖励了，如果我的老板允许的话。

 

(未完待续)