如何看待傳統軟體項目管理，例如PMP，它確實對項目進度和質量有幫助么？

12-27

PMP強調的是強項目管理，管理者對項目進度，項目狀態，有著很緊密的關注和控制。而新型的軟體開發流程，例如scrum，都是熱衷於把職責放到項目成員的身上，項目管理者的角色被弱化成資源分配者的角色上。
那麼PMP這種傳統的項目管理理念在軟體行業是否適用？在遊戲這種需求頻繁變化的項目又如何考量呢？（我自己是比較反對pmp的，認為它只是個商業組織而已）

推薦禪道，以下是本人用禪道的實踐總結：

原創文章，歡迎拍磚，歡迎轉載，但請全文轉載，謝謝

感謝禪道團隊開發了這麼好的一套軟體開發管理配置系統，使得軟體項目經理可以輕鬆的管理大型團隊，致謝！

=======================

全面採用禪道的敏捷開發模式進行整個軟體開發生命周期的管理，需求-&>設計-&>編碼-&>測試-&>交付這四個階段全部用禪道對應的功能進行規範化管理。

崗位劃分：
1、項目經理
2、技術經理
3、測試經理
4、高級程序員(一般擔任開發小組長)
5、程序員
6、前端工程師
以上2、4、5、6屬於開發組，3屬於測試組

具體開發工作流程如下：
1、與甲方做需求前期討論
負責人：項目經理
參與者：技術經理、測試經理及其它有必要參與的人員
外部需求討論階段不需要進禪道，用excel格式的會議紀要、郵件等進行溝通

2、與甲方一起確定需要進行開發的需求及優先順序
負責人：項目經理
參與者：技術經理
把最終確定的需求，細化之後把細化的需求錄入到禪道並設定好優先順序，優先順序為1的為下一個版本要實現的需求，這裡要注意一定是細化的需求，比如：原始需求是「支持多城市，定於4月15日上線區內其他4個城市」，從這個需求細化出來的應該是具體到頁面的需求，如：多城市_修改訂單列表頁面使之支持多城市...
確定下一次發版後要完成的需求後，項目組內部開全會通報所有需求，測試經理開始準備測試用例

3、確定好將要發版的組件版本
負責人：項目經理
每一次發版的版本號規範如下：
1）版本號第二位加1，第三位為0，如：V2.2.0
2）在正式發版之後如果有小改，則第三位遞增，如：V2.2.1，V2.2.2...

一般來說，按兩周發布一個版本的周期發版
在項目-版本中定義好版本，並把版本與需求關聯起來（一個需求可以和多個版本關聯，比如：需求002：訂單列表頁支持多城市的不同操作員只能看到本城市的訂單，此需求牽涉到：訂單中心組件V2.2.0、商品中心組件V2.2.0、微商城/PC商城組件V2.2.0這幾個版本，都要關聯上）
這裡要注意的是，要分組件定義版本，要求所有組件的版本號都保持一致，舉例如下：
1）微商城/PC商城組件V2.2.0
2）訂單中心組件V2.2.0
3）商品中心組件V2.2.0
4）門店系統組件V2.2.0
5）呼叫中心組件V2.2.0
6）門店APP組件V2.2.0
在項目-版本-查看bug，可查看此版本下的bug的清單

4、根據需求細化並分配開發任務
負責人：技術經理
禪道路徑「項目-任務」，做開發任務分配的時候，一般來說都會從一個需求分出多個開發任務，任務是最原子的事務，一個任務只能是一個執行人，如：
需求為：修改XXX頁面使之支持不同城市的操作員只能顯示本城市的信息
分配出3個任務：
1）修改XXX頁面使之支持不同城市的操作員只能顯示本城市的信息-詳細設計
2）修改XXX頁面使之支持不同城市的操作員只能顯示本城市的信息-後端編碼
3）修改XXX頁面使之支持不同城市的操作員只能顯示本城市的信息-前端編碼

5、根據開發需求做設計文檔
負責人：分配了任務的開發組相應人員
監督人：技術經理
根據情況安排編碼程序員做設計文檔（沒有太大難度的功能）或者是由高級程序員或技術經理做設計文檔（有一定難度的功能），統一放到SVN。
文檔標題格式：設計文檔_需求ID_需求標題，如：設計文檔_需求001_修改XXX頁面使之支持不同城市的操作員只能顯示本城市的信息

6、編碼階段
負責人：分配了任務的開發組相應人員
監督人：技術經理、開發小組長
1）程序員根據禪道上的任務按計劃編碼和做單元測試
2）程序員每天早上要自己去開啟分配給自己的任務，任務完成後點擊「完成」
這裡要特彆強調：採用禪道來分配任務並不是說不需要當面溝通，當面溝通依然是最重要的
禪道可與SVN集成，使得技術經理可以直接在禪道上review代碼（社區版無此功能）
3）技術經理負責每天的代碼review和解決技術難題
4）項目經理負責每天監控開發進度，發現情況及時溝通處理，項目經理根據任務的完成情況，及時修改需求的進度，使得甲方能及時了解進度情況，需求的進度統一寫在備註」，格式如下：
研發完畢時間：2016-04-08晚上7點
測試完畢時間：2016-04-19晚上7點
發布上線時間：2016-04-20凌晨2點

7、編碼完成，提交集成測試
1）技術經理自測後認為可以提交集成測試後，在禪道路徑「項目-版本」里，提交測試
2）技術經理把代碼部署到測試伺服器上
3）測試經理安排測試並提交bug（提交bug的時候，屬於這次發版要修正的bug，嚴重程度設為1，其他不屬於這次發版的bug，設為2或3）
4）如果測試進入收尾階段，即將定版的，技術經理把當前提交測試的代碼在SVN上打一個對應版本的Branch分支（名稱格式：V2.2.0_Testing），修改bug的人員集中在幾個核心程序員上，減少引發新bug的幾率，在通知核心程序員switch到此Branch後，立即修改SVN上的許可權設置從Trunk上刪除核心程序員的讀寫許可權避免人為錯誤，其他程序員在Trunk分支上繼續後續的開發
注意：
1）測試-bug中提交bug的時候，務必要選擇對應的版本號
2）每次技術經理更新文件到測試伺服器，都要在釘群里通告大家，並附上此次更新修復的bug清單

8、測試完成，發版前的最後審核
在測試經理回歸完所有1級bug，認為可上線後
1）測試經理報告項目經理可以發版了
2）項目經理自己要再做一次測試，確保品質
3）項目經理測試後也認為沒問題了，提交給甲方進行發版前的驗收測試（如果有必要的，也可讓甲方在階段7參與測試）

9、甲方確認可以發版，正式發版
在甲方進行驗收測試認為可以發版後，
1）測試經理，進禪道路徑「測試-版本」，修改已測試好的版本，設為「已完成」
2）技術經理把此次發版需要更新的代碼、資料庫SQL腳本打包出來
3）項目經理從禪道的項目-需求列表裡導出（複製出）此次發版關聯的需求為Excel文件，此文件就是提供給甲方的changelog文檔
4）項目經理向甲方提供changelog文檔，並讓甲方簽署上線確認書
5）技術經理把將要發版的文件小心謹慎地發布到生產伺服器上
6）項目經理在禪道「產品-發布」中設定與項目-版本相同的發布，備註好發版時間和發版內容，並把版本和發布一對一關聯起來
7）技術經理在發版第二天，在SVN上從Branch里導出一個Tag，名稱格式：V2.2.0_Release

10、版本維護階段
在發版之後，一般來說，還是會發現一些之前沒注意到的Bug需要修改，因此，在下一次大版本發版之前，需要繼續維護當前版本，具體做法如下：
1）技術經理從之前發版的Tag下的Release導出一個Branch，如：V2.2.0_Fixbug
2）測試經理根據客戶處反饋的情況，繼續發bug到禪道上，嚴重程度為1，版本號為V2.2.0
3）技術經理安排相關人員在V2.2.0_Fixbug分支下修改bug（一般來說，只安排專職負責舊版本維護的程序員去處理這些bug，最好是技術經理自己負責處理），這裡要注意SVN的許可權，此Fixbug分支只給具體修改的程序員分配讀寫許可權
4）測試經理安排做回歸測試
5）2、3、4步驟循環進行，直到認為可以發版了，則確定版本號，比如為：V2.2.1，並從V2.2.0_Fixbug導出一個Tag為V2.2.1_Release，由技術經理更新的生產伺服器上（發版前也要導出修改的bug清單給甲方確認）
以上2、3、4、5步驟迭代循環，直到停止維護此版本

11、停止維護老版本
在新版本即將發布前夕，一般是5天內，則停止老版本的維護
1）技術經理在告知相關程序員把本地的工作目錄switch到Trunk後，關閉svn上的老版本Branch的程序員讀寫許可權
2）項目經理關閉老版本的發布，禪道路徑「產品-發布」，設置此版本對應的發布為「停止維護」（這個步驟不能忘記，否則在bug裡邊選擇版本的時候，沒有被停止維護的發布對應的版本會一直顯示出來）

這裡要特別注意的是: 不是說這一次發版完成了才開始新的一次發版之旅，一般來說，在步驟2完成之後，項目經理就要開始和甲方一起溝通下一次發版的需求了，然後是技術經理從需求分配任務，開始新一次發版之旅。這就是螺旋狀上升的敏捷迭代開發之路。。。。。。。

PMP不會直接指導項目經理如何在項目進度和質量方面的具體操作，但能夠培養項目經理系統思考能力。有點像中國的哲學，只告訴你原則，更多是需要從實踐中體悟。
開卷有益，多讀、多實踐總會有收穫。

敏捷流程實質上很強調人的作用，正在實施好敏捷需要一個每個成員都精通技術，而且非常自律，能夠遵守開發紀律的團隊。但是如果有這樣一支團隊的話，實施哪種過程這會是關鍵嗎？應該使用哪種過程都不是問題，所以項目的成敗主要還是人的問題。
不過相對來說，PMP試圖把整個項目看成一條流水線，把項目中的「人」工具化。而敏捷過程更注重「人」的作用，關注項目中「人」的互動對項目的影響。從模型上來說，敏捷應該更貼近於現實情況。

社會科學比自然科學更有意思啊

嗯，PMP的核心就是我們可以學到一套思維方式。不僅僅是工作，在生活的各個方面，都可以借鑒，比如，如何避免與人相處的衝突問題，夫妻關係等等，呵呵，挺有意思的

項目前期和執行過程中做的細一些是好事，不然等到項目結尾或者審計的時候，就可能花費更多的時間去擦屁股。