談談軟件項目管理的重要性(2)

2019-11-17 04:39:11

字體：大中小

來源：轉載

供稿：網友

作者:馬云冬(xacn)
版權所有：馬云冬(xacn)

二、軟件項目治理問題：

1、現代的軟件開發，技術不是要害：

　　隨著日益增長的軟件需求和軟件系統功能的增強，過去一個人開發的歷史以不復存在。現在單槍匹馬寫程序也只是一種娛樂。我們一般開發的系統都是一個小組才能完成的。所以治理才是開發出好的軟件的前提條件，沒有治理一定出不來好的軟件，當然有治理也不一定出軟件的。一個成功的軟件不一定是最好的技術，但在它背后一定有一個好的治理。所以現在的軟件開發已不像從前把技術放在第一，而是該把治理放在第一位。我在網上看到一篇關于中國軟件和印度軟件的比較。我現在記的不是太多，但對我影響最深的是他們會去權衡技術和開發效率問題。如現在開發一個軟件，用戶要求去在三個月內完成，你在做系統分析時也認為在三個月能完成。但你沒有考慮到一些細節，你寫完系統的總體設計，在進行具體設計時碰到要建一張不是太大的路由表。這時大多數國內的設計人員就會想用什么算法，去花很多時間去設計研究新的算法和技術，而人家首先考慮的是系統的運行環境，而這個軟件設計了是在（CPU：1.1G，內存：512M）中運行，用戶也沒特意提出其運行效率要求。所以人家就在內存中開一個大數組來對這個路由表進行操作。從這點看，人家注重的是軟件的整體，而不像國內大多數據設計員那樣，把個體放在首位。其實這方面我覺得我們的開發員應當多向共產黨學習（本人不是共產黨員，團員也因沒交團費被Cancel掉了）。把軟件設計的整體放在首位，而不去花太多的時間在不一定成功的技術上。假如花太多的時間在技術上去，這將對系統的按時完成帶來影響。我也不是說不該研究技術，我只是說開發中應當以全局為重。假如要加入新的技術，必須在分析時就預算其所需要的時間，并設置技術風險治理。假如風險太大就應當取消用這項技術，改用其它的已成功的技術代替。風險治理這是近來才提出的軟件治理方法。它對我們的軟件項目有著很好的控制作用。對于一些中、大型系統，它是一把走進成功之門的鑰匙。這里就不談了，我將在下面進行說明。
2、好的治理才能開發出好的軟件（小系統除外）：

　　大家都知道，軟件開發中有太多的不可預知性。但這種不可預知是對總體來說的，當軟件進行到一點程度時，不可預知的東西就會變成可預知的東西。以住的做法是不去治理它，這樣所帶來的就是項目的失敗。要是有好的治理方法就可以控制這些不可預知的東西，軟件項目就會一步步隨著你的設計思路起向成功。現在就和大家一起討論一些常用的軟件治理方法。

2.1、錯誤治理：

　　小時候當我做錯事的時候，我父親總是把我叫到他身邊，對我說：“沒事，只要下次不做相同的錯事就行了。”這話也許很多家長都對自己的小孩這么講過。小時還不覺得，慢慢長大后，會發覺其中深刻的道理。這就是說從錯誤中吸取經驗教訓。軟件項目開發中的錯誤也是一樣。軟件開發是一項復雜的活動。一個典型的軟件開發項目可能會給我們提供很多的機會去從錯誤中吸取經驗教訓。一般的軟件項目也會提供少量的錯誤給我們學習。學過開車的人都知道，教練老是會這么講：“我希望你們從我身上學習我和前人的的經驗，這些經驗你們就不要再去試了。假如要試你也許會賠上錢甚至于生命。”雖然軟件項目開發不會賠上生命，但是失敗的軟件項目是一定會賠錢的。所是在軟件開發中少不了要對錯誤進行治理。在項目的錯誤治理中我一般是這么做的，現在和大家討論一下：

a、列出典型錯誤：

典型錯誤中有人員方面的。如：對有問題的員工失控、挫傷積極性、人員素質低、英雄主義、項目后期加入人員、開發人員與客戶之間發生摩擦、不現實的預期、缺乏有效的項目支持、缺乏各種角色的齊心協力、政治高于物質、布滿想像等…

典型錯誤中有過程方面的。如：過于樂觀的計劃、缺乏足夠的風險治理、缺乏計劃、在壓力下放棄計劃、在模糊的項目前期浪費時間、前期活動不合要求、缺少治理控制、缺少質量保證措施、魯莽編碼等…

典型錯誤中有技術方面的。如：過高估計了新技術或方法帶來的節省量、項目中間切換工具、缺乏自動的源代碼控制手段等…
.
b、列出自己的最差實踐：

注重典型錯誤，建立自己的最差實踐列表，可以避免在以后的項目中犯同樣的錯誤。

c、列出項目中的最差實踐：

組織機構和其他項目組總結經驗，學習他們的錯誤中得到的經驗。和其他組同事交流項目開發中的磨難，學習他們的經驗。列出潛在的錯誤，看到它我們就會盡量避免今后犯同樣的錯誤。

打個適當的比喻，典型錯誤好比我們學車時教練講的經驗，自己的最差實踐就像我們在實際開車當中出的問題，而項目中的最差實踐就是我們學車前的筆試的書。

公司在發展的同時，也會積蓄一些各方面經驗。列出所有的經驗，按其分類。系統分析中的經驗提供給系統分析，設計人員中的經驗提供給治理人員，技術中的經驗提供給開發員。這樣我們就會有更多的時間花在新的錯誤的防范上面。開發出來的系統就會一個比一個好。
2.2、風險治理：

下面先看一下來自一段網上的文章吧！

“一般認為賭博是在冒險。拉斯維加斯老機的設計者將老虎機的最大賠付率定為97%，即你花一天時間，往老虎機里塞進100元，最多只能贏回970元。

但是，假如比起軟件開發所冒險，拉斯維加斯的賭博簡直就可以稱為“安全的冒險”了。軟件項目所面臨的不斷變換的用戶需求、糟糕的計劃與估算、不可信賴的承包人、欠缺的治理經驗、人員問題、傷筋動骨的技術失敗、性能欠佳…..等等不勝枚舉的風險，使大型項目按時完成的概率幾乎為0，大型項目被取消的概率和賭博一樣成敗參半（Jones 1991）。”

所以項目開發中對風險進行控制治理就大大提高了軟件開發的成功性。軟件風險治理工作就是在風險成為影響軟件項目成功的威脅之前，識別、著手處理并消除風險的源頭。一般我們可以在幾個層次上定位、治理風險。

危機治理---救火模式，就是在風險已經造成麻煩后才著手處理它們。
失敗處理---察覺到了風險并迅速做出反應，但只是在風險發生之后。
風險緩解---事先制定好風險發生后的補救措施，但不做任何防范措施。
著力預防---將風險識別與風險防范作為軟件項目的一部分加以規劃和執行。
消滅根源---識別和消除可能產生風險的根源。

1、2、3項都是被動進行的，亡羊補牢，為時以完。所以我們應當著力于預防風險，更好的是消除風險根源。

風險治理由風險評估和風險控制。而風險評估由風險識別、風險分析和風險優先級組成：
風險識別：就是提出一個潛在破壞項目進度的風險列表，就像生成錯誤列表一樣。
風險分析：評估每一個風險出現的可能性及其影響，判定風險的級別。
風險優先級：按風險影響大小排出一個風險優先級，這個風險列表將作為風險控制的基礎。

風險控制由風險治理計劃，風險化解和風險監控組成。
風險治理計劃：制定一個應對每個重要風險的方案，同時就確保每一個單獨的風險治理計劃之間以及與整體項目計劃之間相一致。
風險化解：每個重要風險所對應計劃的執行。
風險監控：就是對解決風險的過程進行監控，風險監控還可以包括識別新的風險并將其反饋到正在進行的風險治理進程中等方面的工作。

　　現在以我以前做的項目來說明一下我是怎樣進行風險治理的。

　　接到項目對項目進行調研工作，在調研中就要注重到刻服錯誤列表中的錯誤。調研完成后，寫需求說明書初稿（一般根據情況至少給出二個以上的方案），為客戶進行講解，結合客戶意見再次進行修。把修改后的說明書和同士進行討論，再次進行修改。在此期間寫出總體設計的初稿（大的框架）。最后再為客戶講解，再次修改少量的功能。客戶確定需求滿足后就可進行總體設計了。在生成需求分析的同時，注重列出需求中存在的風險。如：需求改變問題、需求定義欠佳等風險。在進行總體設計時，多和客戶交流。因為在總體設計中修改需求比在具體設計中修改要輕易比在編碼階段修改就更加輕易了。之后生成總體設計說明書。同時在總體設計中也要對一些不定的因素進行風險監控。列出風險列表。根據總體設計說明書就可以開始具體設計了。在具體設計中除了要考慮系統設計外還要考慮一些技術風險問題。把很難預見的問題列到風險列表中。注重，從需求分析到具體設計，隨著系統開發的進行度。以前不明的因素將會慢慢顯露。同時也會出現新的不明因素。這樣就讓我們必須在整個設計開發過程中進行風險監控、風險識別、風險分析和風險化解工作。同理，在編碼中也同樣處理。在開發過程中根據分析不同，把風險按階段分為需求分析階段風險、總體設計階段風險、具體設計階段風險和編碼階段風險。并交由此階段的人員進行監控和化解。同時，假如在化解安全區（規定解決問題的時間段中）內無法完成解決，則提交專家組（包括到外請的專家顧問）解決( 我們一般是在周五下午的討論會上進行)。當然軟件開發中所碰到的風險是很多的。但不可能完全同時進行風險監控的。通常是把風險列表中認為最會發生的風險乘損失的大小后的最大數進行嚴格的監控起來。隨著開發進度，風險是在變化的，所以風險列表可能會增加也可能會減少。只要風險治理好了。系統就成功了一大半。
2.3、人員治理：

　　不同人員之間經驗的不同導致績效差別是有目共睹的，大家可能對不同開發人員之間生產效率差距達10：1的觀點較為熟悉，大家也知道一些明確激勵措施所帶來的正面影響。所以人員治理在軟件項目中也有較重的分量。

很清楚，人力因素極大地影響著生產效率，同時任何關注提高生產效率的組織首先必須有一套良好的人員激勵、團隊合作、員工選擇及培訓的機制。這樣才能充分發揮人員的自身能動性。為公司創造更多的價值。

　　　除了以上幾個面的治理外還有其它方面的治理也決定軟件項目的成功與否。如：團隊合作、團隊結構、生產率工具等等。這里就不多說。大家還是抽空多看看書。因為只要你選擇了從事計算機工作，你就選擇了永不能停止的學習、學習，再學習。否則你就將被淘汰。這是多么殘酷但又多么現實的事呀！

上一篇：談談軟件項目管理的重要性(3)

下一篇：IBM的MARS加密算法實現(3)