軟件開發(fā)過程中，往往有很多細節(jié)和意外讓我們的計劃趕不上變化。譬如需求變更、人員流動等。為了保證項目進度可控，有效規(guī)避項目在開發(fā)過程中的風險，項目管理的作用在軟件開發(fā)管理中的重要性可想而知。

項目管理大致有項目計劃和開發(fā)團隊管理兩方面。

                            

建立項目計劃

(1)設計總體架構

針對項目的實施需要，采取適合項目且相對成熟的框架結構。

前些年，我在某集團技術部門擔任技術員時，那時公司的產品總出現(xiàn)各種各樣的問題，例如日常發(fā)布系統(tǒng)時或訪問量稍微過大時，系統(tǒng)就會出現(xiàn)故障，一天下來收到了100多份bug郵件，影響了業(yè)務系部門的正常使用。

之所以出現(xiàn)這么多的bug，是因為無論業(yè)務系提什么需求，技術部都全盤接受了，按理這樣也不會導致出現(xiàn)這么多bug，技術部服務于業(yè)務部，是正常的，畢竟公司的主要收入在業(yè)務部?？蓡栴}是，數據字典是每個開發(fā)人員自己設計的，導致大多數數據字典冗余、甚至設計不合理。各自只關心自己負責的模塊。等到模塊之間有關聯(lián)時，問題就接踵而至了。

那時候公司用asp.net +mssql server技術，并沒有采用相應的框架，代碼冗余多，后來團隊經過兩個多月的整改，系統(tǒng)才勉強能正常使用。

(2)控制可擴展度

擴展度過大，將提高系統(tǒng)的復雜程度，延長開發(fā)時間；擴展度過低，會直接影響系統(tǒng)的二次開發(fā)與維護?？刂葡到y(tǒng)的可擴展性，能提高開發(fā)效率，降低系統(tǒng)維護的難度。

不知你有沒有覺得，項目前期沒有做好，后面復制粘貼的現(xiàn)象就會到處可見，導致冗余的代碼越來越多，維護越來越困難。

(3)建立基礎設施

合理分配軟、硬件等基礎設施的部署所需要的時間與成本。

(4)劃分開發(fā)任務

利用WBS（Work Breakdown Structure，工作分解結構）對可交付結果進行分類與劃分。每個項目劃分為多個不同階段，每個階段又可以分為多個工作包（Work Package），工作包是WBS里最小的可交付結果，最后從工作包中分解出多個開發(fā)任務列表，分配給各個開發(fā)人員。

(5)部署開發(fā)進度

從需求調研、進行概要設計、進行詳細設計、執(zhí)行開發(fā)任務、測試、聯(lián)合調試、SIT部署、生產環(huán)境部署都常常延誤，項目經理必須有談判能力、預判風險能力、控制能力。項目經理就是在滿足各方項目干系人的利益的情況下，推動項目向前發(fā)展，最后達到項目驗收。

(6)測試項目成果

每個工作包都應該同步部署測試工作，提高項目的質量。對出錯BUG的工作包應該由測試人員以文本方式記錄，向開發(fā)人員展示錯誤所在，讓開發(fā)人員及時進行修改。

管理開發(fā)團隊

(1)組建團隊

按照工作任務與項目時間的前提條件建立團隊，按團隊職責分配人員，一般小組控制在6~10人之間。當團隊人數超過20人時，應該考慮把團隊分解成2個獨立團隊，負責不同的開發(fā)任務。

(2)分配開發(fā)任務

在每個迭代周期內（一般是15~30個工作日），應該把每個工作包進一步細分為多個開發(fā)任務，開發(fā)任務的開發(fā)時間應該控制在15個工作小時以內，如果開發(fā)任務的開發(fā)時間超出15個工作小時，應該考慮把任務再度細化。而開發(fā)任務應該以自由選擇的方式分配給每個組員。

(3)跟進開發(fā)進度

在迭代的前期舉行一次會議，讓組員了解開發(fā)的進展及流程，并以自主選擇的方式分配開發(fā)任務。用工具記錄開發(fā)流程的進展，在每個工作包完成開發(fā)后應該進行性功能的測試，并以文本方式記錄測試結果。

每天舉行一次10多分鐘的站立會議，讓組員匯報昨天已完成的開發(fā)任務，當天將要做的任務，以及開發(fā)過程中所遇到的問題。

并在每周末舉行一次例行會議，交待總體進程。

在迭代末期舉行一次沖刺會議，總結項目的進展，交行已完成的任務，回顧該迭代周期內所遇到的問題，為下一個迭代做好準備。

期間千萬不要忽視開發(fā)規(guī)范和代碼審查。

關于代碼規(guī)范，感興趣，請瀏覽《你見過馬化騰18年前編寫的代碼嗎？》

代碼審查，顧名思義，是一個檢查代碼并確保其能正常工作的過程，并且盡可能的優(yōu)化代碼。

有人會對代碼審查的流程反感，我寫的代碼還要別人審查，難道懷疑我們的編碼能力。

其實不然，有人檢查我們的代碼其實是件好事，能減少因為粗心的犯錯帶來的風險。 即使再好的開發(fā)人員也會有大意的時候。

在團隊中的每個人都有自己的強項，通過代碼審查。有些人可能會提出一個更聰明的解決方案，用一個更適合的設計模式來降低復雜度并提高性能。

通過別人的審查，他們可以察覺到可能的問題和發(fā)現(xiàn)能改善的地方，對代碼提交者的編碼水平提高有很大的幫助。

審查者則可以通過讀別人的代碼學習到很多新知識和技巧，并找出適合他們自己工作的解決方案。

(4)系統(tǒng)測試

對每個已完成的工作包進行適時的測試，保證系統(tǒng)質量與性能。對測試結果進行文本的記錄，并把測試結果與績效工資收入掛鉤，并以真實數據計算組員的績效收入。

測試人員應該以文本方式記錄bug，并與開發(fā)人員共同工作的，把突出的缺陷演示給開發(fā)人員，以提高修改的效率。

這里的績效考核就要慎重了，搞不好會導致團隊人員的流失

(5)解決開發(fā)中的問題

對開發(fā)人員進行前期培訓，可適當按工作能力分配任務，指導組員的開發(fā)。當遇到問題時應該在當天的站立會議時即時提出，避免影響開發(fā)進度。

(6)流程化管理

流程化管理(process　management)，是一種以規(guī)范化的點對點的卓越業(yè)務流程為中心，以持續(xù)的提高組織業(yè)務績效為目的的系統(tǒng)化方法。它是一個操作性的定位描述，指的是流程分析、流程定義與重定義、資源分配、時間安排、流程質量與效率測評、流程優(yōu)化等。因為流程化管理是根據團隊的具體情況而設計的，因而這種流程會隨著內外環(huán)境的變化而需要被優(yōu)化。

針對一個IT軟件管理來說，應該抓好以下四大流程管理：

編碼規(guī)范的制定與執(zhí)行;開發(fā)任務流程化的制定與執(zhí)行;開發(fā)進度流程化的制定與執(zhí)行;測試成果的制定與執(zhí)行。

流程化的管理減少了團隊成員盲目與重復的去工作，提高了團隊的工作效率。同時也提高了團隊管理者的效率，為管理提高了一個便捷的管理工具，所以一個高效團隊的打造，離不開流程化的管理。

(7)需求變更，修改項目計劃

在開發(fā)過程中，遇到需求變更，要做好詳細的文本記錄，讓客戶了解需求變更的實際情況和開發(fā)方為之所付出的成本代價。與客戶探討，讓客戶了解計劃修改對項目進度所造成的影響。同時為開發(fā)人員爭取工作量。

筆者曾遇見過，項目開發(fā)過程中，需求變更了，可給予相應的開發(fā)人的工作量卻沒有任何變動，這對開發(fā)人員很不公平，開發(fā)人員只好通過加班加點來完成任務。這樣很容易導致人才流失，做完了這個項目，組員都陸陸續(xù)續(xù)辭職了。

軟件開發(fā)管理，必須得提高軟件團隊管理能力，管理者就要利用一切機會讓團隊成員感受到團隊的力量，讓他們不孤單，不委屈，并通過每一次的開發(fā)任務讓他們不斷成長。

做好項目管理，在軟件開發(fā)中不容忽視，只有做好了，才不會影響項目進度，才能推動項目向前發(fā)展，最后達到項目通過驗收，順利完成項目的開發(fā)任務。