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

項(xiàng)目管理大致有項(xiàng)目計(jì)劃和開發(fā)團(tuán)隊(duì)管理兩方面。

                            

建立項(xiàng)目計(jì)劃

(1)設(shè)計(jì)總體架構(gòu)

針對(duì)項(xiàng)目的實(shí)施需要，采取適合項(xiàng)目且相對(duì)成熟的框架結(jié)構(gòu)。

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

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

那時(shí)候公司用asp.net +mssql server技術(shù)，并沒有采用相應(yīng)的框架，代碼冗余多，后來(lái)團(tuán)隊(duì)經(jīng)過(guò)兩個(gè)多月的整改，系統(tǒng)才勉強(qiáng)能正常使用。

(2)控制可擴(kuò)展度

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

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

(3)建立基礎(chǔ)設(shè)施

合理分配軟、硬件等基礎(chǔ)設(shè)施的部署所需要的時(shí)間與成本。

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

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

(5)部署開發(fā)進(jìn)度

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

(6)測(cè)試項(xiàng)目成果

每個(gè)工作包都應(yīng)該同步部署測(cè)試工作，提高項(xiàng)目的質(zhì)量。對(duì)出錯(cuò)BUG的工作包應(yīng)該由測(cè)試人員以文本方式記錄，向開發(fā)人員展示錯(cuò)誤所在，讓開發(fā)人員及時(shí)進(jìn)行修改。

管理開發(fā)團(tuán)隊(duì)

(1)組建團(tuán)隊(duì)

按照工作任務(wù)與項(xiàng)目時(shí)間的前提條件建立團(tuán)隊(duì)，按團(tuán)隊(duì)職責(zé)分配人員，一般小組控制在6~10人之間。當(dāng)團(tuán)隊(duì)人數(shù)超過(guò)20人時(shí)，應(yīng)該考慮把團(tuán)隊(duì)分解成2個(gè)獨(dú)立團(tuán)隊(duì)，負(fù)責(zé)不同的開發(fā)任務(wù)。

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

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

(3)跟進(jìn)開發(fā)進(jìn)度

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

每天舉行一次10多分鐘的站立會(huì)議，讓組員匯報(bào)昨天已完成的開發(fā)任務(wù)，當(dāng)天將要做的任務(wù)，以及開發(fā)過(guò)程中所遇到的問(wèn)題。

并在每周末舉行一次例行會(huì)議，交待總體進(jìn)程。

在迭代末期舉行一次沖刺會(huì)議，總結(jié)項(xiàng)目的進(jìn)展，交行已完成的任務(wù)，回顧該迭代周期內(nèi)所遇到的問(wèn)題，為下一個(gè)迭代做好準(zhǔn)備。

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

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

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

有人會(huì)對(duì)代碼審查的流程反感，我寫的代碼還要?jiǎng)e人審查，難道懷疑我們的編碼能力。

其實(shí)不然，有人檢查我們的代碼其實(shí)是件好事，能減少因?yàn)榇中牡姆稿e(cuò)帶來(lái)的風(fēng)險(xiǎn)。 即使再好的開發(fā)人員也會(huì)有大意的時(shí)候。

在團(tuán)隊(duì)中的每個(gè)人都有自己的強(qiáng)項(xiàng)，通過(guò)代碼審查。有些人可能會(huì)提出一個(gè)更聰明的解決方案，用一個(gè)更適合的設(shè)計(jì)模式來(lái)降低復(fù)雜度并提高性能。

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

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

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

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

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

這里的績(jī)效考核就要慎重了，搞不好會(huì)導(dǎo)致團(tuán)隊(duì)人員的流失

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

對(duì)開發(fā)人員進(jìn)行前期培訓(xùn)，可適當(dāng)按工作能力分配任務(wù)，指導(dǎo)組員的開發(fā)。當(dāng)遇到問(wèn)題時(shí)應(yīng)該在當(dāng)天的站立會(huì)議時(shí)即時(shí)提出，避免影響開發(fā)進(jìn)度。

(6)流程化管理

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

針對(duì)一個(gè)IT軟件管理來(lái)說(shuō)，應(yīng)該抓好以下四大流程管理：

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

流程化的管理減少了團(tuán)隊(duì)成員盲目與重復(fù)的去工作，提高了團(tuán)隊(duì)的工作效率。同時(shí)也提高了團(tuán)隊(duì)管理者的效率，為管理提高了一個(gè)便捷的管理工具，所以一個(gè)高效團(tuán)隊(duì)的打造，離不開流程化的管理。

(7)需求變更，修改項(xiàng)目計(jì)劃

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

筆者曾遇見過(guò)，項(xiàng)目開發(fā)過(guò)程中，需求變更了，可給予相應(yīng)的開發(fā)人的工作量卻沒有任何變動(dòng)，這對(duì)開發(fā)人員很不公平，開發(fā)人員只好通過(guò)加班加點(diǎn)來(lái)完成任務(wù)。這樣很容易導(dǎo)致人才流失，做完了這個(gè)項(xiàng)目，組員都陸陸續(xù)續(xù)辭職了。

軟件開發(fā)管理，必須得提高軟件團(tuán)隊(duì)管理能力，管理者就要利用一切機(jī)會(huì)讓團(tuán)隊(duì)成員感受到團(tuán)隊(duì)的力量，讓他們不孤單，不委屈，并通過(guò)每一次的開發(fā)任務(wù)讓他們不斷成長(zhǎng)。

做好項(xiàng)目管理，在軟件開發(fā)中不容忽視，只有做好了，才不會(huì)影響項(xiàng)目進(jìn)度，才能推動(dòng)項(xiàng)目向前發(fā)展，最后達(dá)到項(xiàng)目通過(guò)驗(yàn)收，順利完成項(xiàng)目的開發(fā)任務(wù)。