討論軟件開發的特征，需要站在一個大的背景下來看。我以前考過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的獎勵了，如果我的老板允許的話。

 

(未完待續)