項目管理在軟體開發中的地位不容忽視

最新 08-31

我是不是你最疼愛的人

潘越雲

00:00/04:08

項目管理在軟體開發中的地位不容忽視

文|洪生鵬

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

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

建立項目計劃

(1)設計總體架構

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

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

之所以出現這麼多的bug，是因為無論業務系提什麼需求，技術部都全盤接受了，按理這樣也不會導致出現這麼多bug，技術部服務於業務部，是正常的，畢竟公司的主要收入在業務部。可問題是，數據字典是每個開發人員自己設計的，導致大多數數據字典冗餘、甚至設計不合理。各自只關心自己負責的模塊。等到模塊之間有關聯時，問題就接踵而至了。

那時候公司用asp.net +mssql server技術，並沒有採用相應的框架，代碼冗餘多，後來團隊經過兩個多月的整改，系統才勉強能正常使用。

(2)控制可擴展度

擴展度過大，將提高系統的複雜程度，延長開發時間；擴展度過低，會直接影響系統的二次開發與維護。控制系統的可擴展性，能提高開發效率，降低系統維護的難度。

不知你有沒有覺得，項目前期沒有做好，後面複製粘貼的現象就會到處可見，導致冗餘的代碼越來越多，維護越來越困難。

(3)建立基礎設施

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

(4)劃分開發任務

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

(5)部署開發進度

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

(6)測試項目成果

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

管理開發團隊

(1)組建團隊

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

(2)分配開發任務

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

(3)跟進開發進度

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

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

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

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

期間千萬不要忽視開發規範和代碼審查。

關於代碼規範，感興趣，請瀏覽《你見過馬化騰、劉強東編寫的代碼嗎？》

代碼審查，顧名思義，是一個檢查代碼並確保其能正常工作的過程，並且儘可能的優化代碼。

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

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

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

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

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

(4)系統測試

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

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

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

(5)解決開發中的問題

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

(6)流程化管理

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

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

編碼規範的制定與執行;

開發任務流程化的制定與執行;

開發進度流程化的制定與執行;

測試成果的制定與執行。

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

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

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

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

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

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

【END】