作者：CppExplore 網(wǎng)址：http://www.shnenglu.com/CppExplore/
一 項(xiàng)目管理流程
1 項(xiàng)目定義
在有限的時(shí)間、有限的人力、有限的資源內(nèi)，完成即定的功能，并保證項(xiàng)目的質(zhì)量。
項(xiàng)目具有時(shí)效性/資源受限，功能邊界明確等特點(diǎn)。
項(xiàng)目失敗，并不僅僅是指項(xiàng)目的功能沒有完成。超時(shí)/超支都算做項(xiàng)目失敗。
2 項(xiàng)目管理目標(biāo)
可重復(fù)：項(xiàng)目的成功性可復(fù)制。一個(gè)項(xiàng)目成功，另一個(gè)項(xiàng)目也可以成功。成功不是偶然性。
可管理：項(xiàng)目本身可管理，成功過程可控。
3 項(xiàng)目生命周期
項(xiàng)目具有固有的生命周期規(guī)律，項(xiàng)目管理需要遵循該規(guī)律，不要過分重視產(chǎn)出（壓縮時(shí)間），否則影響長期的穩(wěn)定的產(chǎn)出（同樣體現(xiàn)項(xiàng)目管理的可重復(fù)、可管理）。
項(xiàng)目生命周期分：需求意向 需求階段 開發(fā)階段 測試階段 維護(hù)階段。下圖給出一個(gè)模擬示例：
其中需求結(jié)束、開發(fā)結(jié)束、版本正式發(fā)布（測試結(jié)束）均為里程碑。
4 參與項(xiàng)目的角色
參與項(xiàng)目的主要角色有：項(xiàng)目管理人員/需求人員/研發(fā)人員/測試人員/配置人員/實(shí)施人員。他們分階段進(jìn)入項(xiàng)目，分階段離開項(xiàng)目。下圖為人力投入示例： 其中需求來源發(fā)生在立項(xiàng)之前，不予考慮，另產(chǎn)品人員需要參加需求文檔review，屬項(xiàng)目外，不考慮。
項(xiàng)目管理人員需要全程跟蹤項(xiàng)目，尤其是立項(xiàng)點(diǎn)、需求文檔review、需求結(jié)束、設(shè)計(jì)文檔review、設(shè)計(jì)結(jié)束、測試期間以后進(jìn)入維護(hù)期后。
需求人員除需求階段，還需要參與設(shè)計(jì)文檔review、測試文檔review。
開發(fā)人員除開發(fā)階段，還需要參與需求文檔review，以及測試期間bug修復(fù)、維護(hù)期保留部分人力。
測試人員除開發(fā)階段，還需要參與需求文檔review。
二 項(xiàng)目階段
1 立項(xiàng)
立項(xiàng)初期，更多的是資源申請(qǐng)、人力安排計(jì)劃等。盡量減少以后的溝通成本，比如確定項(xiàng)目編號(hào)、階段編號(hào)、功能編號(hào)、模塊名（如果能夠確定）、各模板版本號(hào)格式、系統(tǒng)部署的軟硬件平臺(tái)等。
2 需求階段
該階段是項(xiàng)目最重要的階段，代表了項(xiàng)目的使命。該階段的產(chǎn)出需求文檔則是項(xiàng)目最重要最核心的一片文檔，是設(shè)計(jì)文檔、測試用例以及后期維護(hù)的依據(jù)。
需求文檔的用語應(yīng)該是明確的、無歧義的。比如 “包含...但不限于這些...”、“這些功能請(qǐng)研發(fā)人員靈活掌握”“請(qǐng)參考某某網(wǎng)站/請(qǐng)參照某某項(xiàng)目的樣子”都屬于不合格的用語。
需求文檔整體內(nèi)容應(yīng)該是封閉的，不依賴于任何未知的內(nèi)容，引用的外部文檔需要嵌在需求文檔中，或者給出文檔號(hào)，可以在團(tuán)隊(duì)的文檔庫中查詢到。為更好的理解需求文檔的封閉性，舉例說明，比如要實(shí)現(xiàn)sip棧， 需求文檔應(yīng)該給出sip協(xié)議的介紹以及做到什么程度，研發(fā)不需要自己去看rfc文檔， 只需要參照需求文檔去開發(fā)即可。另任何業(yè)務(wù)上的知識(shí)盲點(diǎn)， 需求人員都要給開發(fā)人員解決，開發(fā)人員在任何時(shí)候(需求文檔review中或者設(shè)計(jì)文檔中或者開發(fā)中)發(fā)現(xiàn)業(yè)務(wù)知識(shí)盲點(diǎn)，都可以反饋給需求人員，要求給予支持或解決。
需求文檔需要明確定義系統(tǒng)的功能邊界、系統(tǒng)的網(wǎng)元?jiǎng)澐帧⒏鱾€(gè)網(wǎng)元的外部特性。這里給出一個(gè)大體的提綱：要實(shí)現(xiàn)的功能點(diǎn)、網(wǎng)元?jiǎng)澐忠约白詈蟮牟渴鸱绞健⒚總€(gè)網(wǎng)元的功能點(diǎn)、復(fù)雜網(wǎng)元的內(nèi)部模塊圖建議（可選）、網(wǎng)元間通訊接口、各網(wǎng)元間的交互時(shí)序圖、各個(gè)網(wǎng)元如何和其他網(wǎng)元交互完成前面的功能點(diǎn)。
其中各網(wǎng)元的交互時(shí)序圖需要能涵蓋網(wǎng)元間所有的交互，簡單的重復(fù)的交互也可用文字描述補(bǔ)充；網(wǎng)元間的通訊接口是明確的，每個(gè)命令中的字段名、類型、取值范圍都需要明確。
其他方面，比如性能要求、其他非功能性要求等，如果外部需求方有明確要求，可寫入文檔，否則可象征性寫一個(gè)一定可以滿足的值或者省略這部分（性能本身依賴于團(tuán)隊(duì)的積累）。
在需求文檔review階段，產(chǎn)品人員可以審核考量是否已經(jīng)滿足了預(yù)期的功能；開發(fā)人員可以審核考量是否已經(jīng)明確了自己負(fù)責(zé)的模塊特性，是否不再需要和其他模塊的開發(fā)人員溝通確認(rèn)某些接口上的問題；測試人員審核考量是否可以依據(jù)此寫出測試用例，不需要再向開發(fā)人員確認(rèn)。

最后需求文檔defect入庫、文檔本身入庫。
3 開發(fā)階段
開發(fā)階段可以細(xì)分為設(shè)計(jì)文檔階段、編碼階段、測試階段。其中重要的是前期設(shè)計(jì)和后期的測試階段。
 設(shè)計(jì)文檔中，開發(fā)人員要從各個(gè)角度向別人展示自己的系統(tǒng)，包括部署圖（在網(wǎng)絡(luò)中的位置）、模塊圖、數(shù)據(jù)流向圖、靜態(tài)類圖、交互圖、狀態(tài)圖 關(guān)鍵數(shù)據(jù)結(jié)構(gòu)等，最終需要能體現(xiàn)需求文檔要求的功能。
研發(fā)測試階段請(qǐng)參見測試系列之 c++ server測試全攻略，其中白盒測試、內(nèi)存測試、壓力測試必做，同時(shí)陪測程序需要和源碼一并提交在版本管理工具中。完善的log信息和必要的陪測工具是系統(tǒng)質(zhì)量的保障。
開發(fā)階段結(jié)束后，源碼/二進(jìn)制包上傳、代碼行統(tǒng)計(jì)、各種文檔入庫、defect入庫。
4 測試階段
測試人員的測試用例、結(jié)果必須文檔化。專項(xiàng)測試需要包含以下部分：測試目的、測試方法、測試環(huán)境、附測試腳本、測試結(jié)果。
測試人員不僅需要測試系統(tǒng)，在實(shí)施和維護(hù)期間更要回答現(xiàn)場人員的咨詢。
測試結(jié)束，各種文檔入庫、defect入庫，用戶文檔產(chǎn)生、版本打標(biāo)記或者打基線，作為以后開發(fā)的基礎(chǔ)。
5 實(shí)施階段
版本正式發(fā)布，基本標(biāo)志項(xiàng)目結(jié)束。實(shí)施人員將作為以后現(xiàn)場支持的Level1級(jí)，測試人員為Level2級(jí)，研發(fā)人員為Level3級(jí)，屬于未實(shí)現(xiàn)的功能，轉(zhuǎn)需求人員。

說下bug數(shù)量，一般c/c++代碼每千行16-20個(gè)bug左右，研發(fā)和測試階段按一定比例劃分。bug過少，從某個(gè)角度可以看作測試力度不夠，過多可以看作代碼質(zhì)量較差。任何時(shí)候，bug數(shù)量都不應(yīng)當(dāng)作為績效考核的標(biāo)準(zhǔn)。
以上階段中最重要的是需求階段，其次是研發(fā)階段的測試。
三 追求更好的項(xiàng)目管理流程
從某種程度上說，項(xiàng)目管理是一個(gè)團(tuán)隊(duì)的習(xí)慣。
一個(gè)好的項(xiàng)目管理習(xí)慣，可以讓一個(gè)團(tuán)隊(duì)的運(yùn)作如行云流水，又如微風(fēng)拂面。團(tuán)隊(duì)成員各司其責(zé)，既是在工作 又何嘗不是一種享受。整個(gè)項(xiàng)目管理，就象... （就象...最近裝修，團(tuán)購網(wǎng)上的標(biāo)語：就象）喝茶那樣輕松。即便是這個(gè)團(tuán)隊(duì)從公司脫離，在新的環(huán)境里也會(huì)保留以前的項(xiàng)目管理制度，從通訊企業(yè)里出走的團(tuán)隊(duì)很多這種例子。
而一個(gè)差的項(xiàng)目管理習(xí)慣，則是一個(gè)團(tuán)隊(duì)的噩夢。所謂的管理，可能流于形式，可能成為項(xiàng)目管理者的令箭牌，可能成為研發(fā)人員的催命符。
習(xí)慣的力量強(qiáng)大而可怕。不管是好的團(tuán)隊(duì)還是差的團(tuán)隊(duì)，遇到不符合自己習(xí)慣的改變，都會(huì)做出一致的決定：抵制。抵制的理由可能不同 ，有的是 我們現(xiàn)在已經(jīng)運(yùn)作的很好了，不需要做出改變，有的則是我們沒有那個(gè)能力去實(shí)施這個(gè)流程/我們?nèi)藛T有限/我們控制不住。改變后也不見的運(yùn)作比現(xiàn)在差，改變后也不見得會(huì)浪費(fèi)更多的人力，反而會(huì)有序，更節(jié)省人力，更利于控制。
養(yǎng)成習(xí)慣需要3個(gè)前提：知識(shí)（知道這么做是好的）、意愿（愿意這樣做）、可實(shí)施性（有明確的實(shí)施方法）。之后加上堅(jiān)持，一定時(shí)間（21天）后就可以形成習(xí)慣。
看培養(yǎng)好的項(xiàng)目管理習(xí)慣就是這么簡單，真的就象喝茶那樣輕松。
四 團(tuán)隊(duì)技術(shù)積累
項(xiàng)目管理理論容易給人以錯(cuò)覺，好象只要有了規(guī)范的項(xiàng)目管理流程，就可以保證項(xiàng)目的成功可重復(fù)/成功過程可控制。但事實(shí)往往并不是這么如意。
項(xiàng)目管理的順利進(jìn)行依賴于團(tuán)隊(duì)的基礎(chǔ)建設(shè)：團(tuán)隊(duì)人員組成、基礎(chǔ)代碼庫、基礎(chǔ)模塊庫等。沒有完備的團(tuán)隊(duì)和一定的基礎(chǔ)積累，談不上項(xiàng)目得可重復(fù)與可管理性。
成熟的團(tuán)隊(duì)中，項(xiàng)目的主角是需求人員、開發(fā)人員、測試人員。需求是個(gè)迭代的過程，是在已有系統(tǒng)或模塊上持續(xù)擴(kuò)充的過程。開發(fā)是充實(shí)基礎(chǔ)庫與模塊庫，在已有基礎(chǔ)代碼庫和基礎(chǔ)協(xié)議棧之上實(shí)現(xiàn)業(yè)務(wù)的過程。測試是一個(gè)測試工具積累的過程。完備的積累是項(xiàng)目成功的可靠保證。
總體來說，項(xiàng)目管理和團(tuán)隊(duì)建設(shè)相輔相成，共同發(fā)展，公司在不同的時(shí)期，偏重不同，初期重團(tuán)隊(duì)建設(shè)，成熟期重項(xiàng)目管理。
五 具體問題具體分析
項(xiàng)目管理流程并非一層不變。針對(duì)項(xiàng)目的規(guī)模和復(fù)雜性，可分大項(xiàng)目、小項(xiàng)目、mini項(xiàng)目。有的項(xiàng)目很小，不需要寫需求文檔，可能只需要增加一個(gè)ChangeRequest，也可能不需要寫設(shè)計(jì)文檔。以保證小項(xiàng)目的靈活性和響應(yīng)及時(shí)性。后期的補(bǔ)充正確區(qū)分defect和ChangeRequest。需求一定要遞交到需求人員，以便其把握整個(gè)系統(tǒng)以及后續(xù)架構(gòu)的走向。