如何完善軟件項目管理方法

如何完善軟件項目管理方法

1.項目管理方法概述對于軟件開發(fā)過程，最關(guān)鍵的要素是可操控性。一個混亂的項目直接導(dǎo)致高費用、拖延的開發(fā)時段和低質(zhì)的軟件產(chǎn)品。當然這并不是我們想看到的結(jié)果。依我看來，當一個項目結(jié)束時，我們需要的不僅僅是一堆軟件，而要有更少的維護費用(意味著高質(zhì)量)和訓(xùn)練有素的團隊以及可繼承的開發(fā)過程。繼承意味著積累和連續(xù)性。這也是為什么那么多大的公司能夠快速發(fā)行他們的新產(chǎn)品以幸免于市場的競爭。這就像著名科學(xué)家(newton譯者注)講的那樣，“我之所以取得成功，是因為我站在巨人肩膀上的”。在項目管理方法中，對于那些小型開發(fā)公司，完全依據(jù)CMM(CapabilityMaturityModelforSoftware軟件能力成熟度模型)來管理軟件項目是不值得的。因為這樣的花費太大，以致于公司將失去它們的韌性。為了軟件質(zhì)量管理，軟件開發(fā)無論如何應(yīng)該遵守一定的基本規(guī)則。這將對于后期的產(chǎn)品質(zhì)量很有幫助。如果我讓我用一句話來描述項目管理方法，我想說它是一個可管理，可操控的過程。我其實也就是說，無論在軟件開發(fā)的那個階段，質(zhì)量和進度都應(yīng)該是可控制的。2.軟件中開發(fā)的一些提示于此我為軟件開發(fā)列出一些提示。由于背景和習(xí)慣的不同，這些提示可能并非對任何人有效。但是如果這些提示能帶給你某些深入的思考，我想它們是有價值的。2.1軟件預(yù)算任何計劃的制訂(working-out)都是基于軟件大小。一旦我們抓住了對項目的軟件大小和構(gòu)架的理解，我們就能初步安排人力數(shù)據(jù)和進度。這種安排不必精確。當軟件開發(fā)過程推進，理解加深之后，無論如何，軟件預(yù)算將變得越來越精確并且計劃安排將。在軟件項目的初始階段，我們應(yīng)該實施第一次軟件軟件評估。在項目管理方法中，軟件項目可以被分解成一些功能相對獨立的功能模塊(注意：這里的模塊不同于那些在HLD階段中被定義的模塊)。其間，我們也能認識到哪個模塊是最難以及哪個是最重要的。一旦我們有了這些數(shù)據(jù)，我們根本的人力數(shù)據(jù)和進度就離我們不遠了。同時，我們可以保持我們的眼光在這些困難和重大模塊之上，也就是那些投入較大的資源地方。在項目管理方法中，在每一個軟件開發(fā)階段的結(jié)束，正如SRS和LLD，我們可以重新評估軟件的規(guī)模并調(diào)整我們的項目計劃。實際上這是一個項目計劃的回顧過程。這種回顧的優(yōu)點是更好地使用項目資源和發(fā)現(xiàn)存在的項目問題。僅僅通過這些持續(xù)的更新，項目計劃真的能指引我們的開發(fā)行為。否則，隨著項目的進行，這將變成一塊沒有使用的白紙。于是，你會感覺進度總是在你的掌控之下。當然，這是一種非常令人愉快的感覺。2.2討論和評審軟件開發(fā)是一個團隊項目，所以我們認為團隊精神是非常重要的，甚至它是關(guān)鍵項目成功的一個關(guān)鍵。一般由于市場競爭我們沒有足夠的剩余時間留給軟件項目。因此，一個項目經(jīng)理，在任何時候應(yīng)該追蹤正在做的事情。討論和評審是通向目的非常好的路徑。好的項目必須有一個好的開發(fā)過程。在項目管理方法中，它是一個反映好的開發(fā)過程的文檔。我們?nèi)绾卧谟邢迺r間內(nèi)完成高質(zhì)量的文檔?我想有三方面的重大因素。第一，在你開始寫之前，和相關(guān)的團隊成員討論是必要的。這種討論不僅包括技術(shù)問題，而且還包括如文檔風格等細節(jié)問題。一旦這些問題被團隊解決了，接下來的文檔工作只是小菜一碟。第二，在寫文檔的過程中，如果你發(fā)現(xiàn)新的問題，而你不能理解或者你認識先前的設(shè)計是錯誤的，請毫不猶豫地把這些問題拿出來和你的同事討論。通過這種持續(xù)的討論，我們可以會聚所有團隊成員的智慧以保證在最終的文檔中出現(xiàn)更少的錯誤。隨著項目的進行，我們的理解也加深了。于是我們可能發(fā)現(xiàn)一些被忽略了的部分，這些將影響我們的設(shè)計。所以無論何時，只要我們有了新的發(fā)現(xiàn)，以獲得高質(zhì)量的文檔，我想第三種因素──評審和更新已經(jīng)結(jié)束的文檔是很有必要的。無庸置疑，在項目管理方法中，對于一個時段限制的項目，討論和評審意味著你要花費大量的時間，并且在某些情形下這不易于安排，特別是在工作同時變故的情況下。關(guān)鍵的解決這人問題的在項目管理方法中，是把時間和人力精心劃分。給個示例，如果我們下周有一些文檔需要評審，那么理所當然應(yīng)該在本周末完成安排。這種安排包括評審的參與者、時間、地點和持續(xù)時間等。只有通過這種仔細的安排，我們才能避免評審沖突。通常在正式評審之前，我們應(yīng)該留出時間給項目組成員來預(yù)告判斷評審的內(nèi)容。在評審會議上，為節(jié)省時間，唯一目的是發(fā)現(xiàn)問題，而不是解決問題。深入的討論應(yīng)當被在評審會議之后舉行。其間，我們應(yīng)該采取措施來跟蹤在評審會議上被發(fā)現(xiàn)的問題以避免缺失?；ㄙM大量時間來討論和評審是有價值的，因為許多人個錯誤會在討論和評審中被暴露出來。在項目結(jié)束時，我們發(fā)現(xiàn)討論和評審簡直令人難以置信。另外，通過這種持續(xù)的交流與合作，我們對彼此的了解更多了些并且團隊的效力也被加固了。風險到處都有。在軟件開發(fā)階段，我們會遇到許多困難，并且我們應(yīng)該真正嘗試克服它們。另一方面，我們?nèi)匀恍枰A(yù)見我們未來可能發(fā)生的風險，并采取行動來減少這種潛在風險對項目的影響。這就是風險管理的概念。對于一個軟件項目，最嚴重的風險是人力資源問題。大多數(shù)項目被分割為由單獨的工程師管理的功能模塊，你能想象某一個工程師的突然離去對公司造成的影響嗎?在軟件項目的開始階段，為避免災(zāi)難的接腫面至，人力后備計劃應(yīng)該被發(fā)起。假如缺少工程師，我們?nèi)绾翁幚砣肆髠溆媱?這在很多公司正在發(fā)生。盡管我們沒有辦法讓一些工程師作為另一些的后備，讓某些工程師部分掌控其它模塊也是可能的。至少，他們一定能理解別的模塊的基本原理。如果我們做到適當?shù)墓芾?，這種想法可以在討論和評審的過程中實現(xiàn)。如果一個工程師被選為一個模塊的后選人，他應(yīng)該參與到所有關(guān)于這個模塊的討論和評審之中。也就是說，他與這個模塊有關(guān)系。因此，當一個項目經(jīng)理布置一個過程，他應(yīng)當考慮這種關(guān)聯(lián)。只要我們堅持這種項目管理方法，那個工程師或都更多的工程師將熟悉那個本來不屬于他們掌管的模塊。結(jié)果，即使這種風險變?yōu)閷嵤?，項目也可以更平穩(wěn)地生還。除出人力，還有很多其它的風險，比如實驗設(shè)備，工具軟件以及測試環(huán)境。所以這些風險應(yīng)該被記錄和追蹤。其間，項目應(yīng)該有一個計劃來減少這種風險的影響。當一個風險過去之后，這個風險的記錄應(yīng)該被關(guān)閉。在每一個開發(fā)過程的結(jié)束，項目經(jīng)理應(yīng)該招開一次會議討論哪個風險可能會在下一階段發(fā)生。