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

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

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