Success/Failure Criteria for Software Projects

Success/Failure Criteria for Software Projects

 

Introduction

什麼是軟體項目成功或失敗的標準？對此，可能每個人都有自己的觀點。一個軟體項目如何才能成功？需要具備哪些要素？比如出色的開發人員，正規的開發流程、細緻的需求、UML、有效風險管理、周全的計劃、明確的商業目標、頻繁的評估和回顧。記得以前看《軟體工藝》的時候，為書中新穎獨特的觀點所深深吸引，慮及自己所經曆的項目，發現很多地方印證了書中的觀點。軟體工藝強調人的作用，不過，它似乎並沒有改變大多數人心中軟體工程的地位。很多PM還是在對制定“計劃”樂此不疲，費盡心機想匯入某種正規的“Process”，想盡辦法去進行“風險管理”，強調“明確需求”；很多設計人員整日抱著UML，畫著各種“Diagram”……可是現實世界發生的事情可能令我們感到困惑甚至吃驚。

 

A Study

有位澳大利亞的教授研究了400個美國、澳大利亞和智利的軟體項目後，得出一些驚人的結論，大致如下（斜體部分是我的看法）：

1、  大多數沒有進度表的項目最後成功了。

這的確令人感到驚訝，沒有進行計劃安排的項目居然能成功，要麼是組員比較優秀，要麼項目比較小，容易達成目標。

 

2、  需求對於項目的成功是需要的，但是在項目早期並非必須的。

通常我們期望需求得到得越早越好……

 

3、  沒有明確的需求，項目常常也能成功地繼續開展下去。

就我的經曆而言，沒有明確的需求是很正常的事情，特別是做產品的時候，往往還不知道最後的產品應該具有哪些特性。如果是做具體的項目，我則期望需求越明確越好。但是需求總是會變化，team需要對客戶的反饋有能力作出及時的調整。

 

4、  需求方法論的選擇並不重要，UML沒有什麼協助。

我是UML的熱愛者，喜歡使用UML來表達我的想法，表達設計，和組員進行交流。不過事實表明，UML只是一部分人（喜歡可視化的圖表的人）的工具。對於表達需求來說，UML的確沒有什麼用，Use-Case Diagram就是幾個用例（橢圓、連線和角色），看了之後你能對需求瞭解多少呢？還是看文字描述的Use-Case比較直接和準確。但我相信使用UML表達設計是很好的做法。

 

5、  使用某開發方法論是成功的要素，特別是它適合我們的應用的時候。

的確如此，適合我們的過程就是最好的過程。國內有很多企業都使用CMM/CMMI、6Sigma、RUP甚至XP，不過大多數的軟體企業還是沒有progress。即使有些企業獲得了CMM/CMMI的認證，執行中也常常是留於表面。

 

6、  很少有項目使用風險管理，而且這些項目也很少管理其風險。

事實如此，但並不說明風險管理不值一提，它還是很重要的。公司要規避風險，項目當然要規避風險。

 

7、  很少有能堅持進行頻繁地評估和回顧的，幾乎總是在成功的項目中才做到了。

我認為進行評估是規避風險的一個具體做法。比如對架構設計進行評估，就是為了從技術上盡量降低項目失敗的可能性。但這個評估和回顧應當是在良好的氣氛中進行，適時變化。

 

8、  ……

 

該研究還提出了一些預見（似乎是眾所周知的）：

• Success comes from a culture that investigates and deals with problems

最贊同的一點。

• The vision for the project (its business goals) must be shared among all project personnel, especially the project manager

• Project managers should be involved in the estimation activity

• Project managers should be good at customer and developer communication; they need not be good at the technology

這點可能會有爭議，專案經理到底有無必要精通技術？

 

更多內容請看原文。