軟體專案管理工具對比----推進敏捷開發管理工具的使用
一、公司產品管理
2.1現狀
市場需求會導致產品的升級、產品子型號的誕生，如為中交公規院研發的A1P系列產品、針對不同量程的HCF700等等。按照公司現在的思路，產品有重大升級需求後由VP決定是否升級，然後通過會議通知組長和實際開發者、PM。之後產品升級的過程就被關進“小黑屋”，產品的開發進度可能只在組內流通，或者在某週週一的例會上被提及，核心研發人員才能得知這個產品的最新狀態。
產品需求沒有進行管理。有些從市場、銷售發聵回來的需求都被“以後改一下”擱置了。公司現在安排的“產品經理”可能還只是一個title，並沒有實際支配這個產品形態的權利，自己的意識形態裡還只是一個程式設計師，產品需求的事可能惰性的認為應該是上級分配給自己的，因此可能不會主動記錄產品需求。一個產品需求可能來自一個不經意間的靈感，可能來自實際使用者的真實反饋，可能來自同事的建議等等，因此不做記錄和評估，一些可能極大提升使用者體驗的需求就這樣被擱置了。
產品測試無法進行用例管理。產品測試過程無從得知。
產品釋出流程過於複雜。一個產品從提交測試到釋出需要準備的東西過多，並且流程不夠規範，稍有不慎就會遺漏東西，如果定製一款持續整合工具可很好的解決這個問題，並且能夠提高交付產品的質量。
全產品狀態的檢視。現在最新產品狀態只能通過seafile託管的定期人工合成的全產品狀態檔案進行檢視，體現的資訊少，並且可能由於溝通的問題造成錯誤。
2.2專案管理
因地制宜，制定符合xxxxx的工作流。公司產品研發使用的是瀑布式開發，但和現在盛行的Scrum有很多相似之處：制定需求、篩選需求、拆分任務、分配給產品經理（開發人員）、每週總結匯報、產品釋出後進行展示等
瞭解Scrum：
以人為核心、迭代、循序漸進的開發方法。
關鍵詞： 激情、速度、爭先恐後。
宣言：個體與互動、可工作的軟體、客戶協作、響應變化（對比過程與工具、面面具到的文件、合同談判、遵循計劃）。
二、禪道專案管理系統
3.1禪道能解決的問題
禪道專案管理軟體的主要管理思想基於國際流行的敏捷專案管理方法—Scrum。Scrum方法注重實效，操作性強，非常適合軟體研發專案的快速迭代開發。但它只規定了核心的管理框架，還有很多細節流程需要團隊自行擴充。禪道在遵循其管理方式基礎上，結合國內研發現狀，整合了
禪道專案管理軟體的主要功能列表：
1. 產品管理：包括產品、需求、計劃、釋出、路線圖等功能。
2. 專案管理：包括專案、任務、團隊、版本、燃盡圖等功能。
3. 質量管理：包括bug、測試用例、測試任務、測試結果等功能。
4. 文件管理：包括產品文件庫、專案文件庫、自定義文件庫等功能。
5. 事務管理：包括todo管理，我的任務、我的Bug、我的需求、我的專案等個人事務管理功能。
6. 組織管理：包括部門、使用者、分組、許可權等功能。
7. 統計功能：豐富的統計表。
8. 搜尋功能：強大的搜尋，幫助您找到相應的資料。
9. 擴充套件機制，幾乎可以對禪道的任何地方進行擴充套件。
10. api機制，所見皆API，方便與其他系統整合。
3.2為什麼不是redmine+testlink+外掛
根據51Testing2015年第九屆軟體測試現狀調查報告中關於測試管理工具分配的情況：
報告顯示，測試管理軟體中禪道佔據主導地位。禪道軟體的開源性質、商業化路線、敏捷開發方式使得禪道可以廣泛接受使用者的反饋、需求並實現快速迭代，這使得禪道的可靠性、易用性得到了保障。
騰訊移動品質中心對市面幾款常用的專案管理工具按照常用的管理模組劃分後進行對比：
報告顯示，即使redmine與testlink做功能互補，仍會缺少產品整個生命週期的部分功能。並且這種互補會造成功能的重複，內部邏輯流程不清晰。
根據實際使用體驗對兩款軟體的細節進行對比（5分制）
|
禪道 |
redmine+外掛 |
|
|
專案管理功能 |
5 |
3（專案、產品、需求、測試用例無法整合） |
|
bug管理功能 |
5 |
5 |
|
用例管理功能 |
5 |
3（需要testlink支援） |
|
需求管理功能 |
5 |
3（需要其他外掛） |
|
版本管理功能 |
5（專案版本、測試版本） |
5 |
|
文件管理功能 |
5 |
3（不支援分類） |
|
wiki |
0 |
5 |
|
專案論壇 |
0 |
5 |
|
專案關聯產品 |
5 |
5 |
|
專案關聯需求 |
5 |
2 |
|
專案關聯測試用例 |
5 |
2 |
|
桌面端軟體提醒 |
5 |
3（第三方個人外掛） |
|
移動端軟體 |
3（需要付費專業版） |
3（第三方個人外掛） |
|
用例不通過直接報bug |
5 |
5 |
|
郵件提醒 |
5（還可設定簡訊提醒） |
5（每次狀態更改，自己也會收到郵件、煩） |
|
領導審查專案進度 |
5 |
1（無進度提示、無法瞭解專案總體狀況 ） |
|
銷售、市場瞭解產品進展 |
5 |
1（無進度提示、無法瞭解專案總體狀況） |
|
報告 |
5 |
3（需要外掛支援，中文支援不好） |
|
報表統計圖 |
5 |
4（視覺化效果弱、統計專案少） |
|
研發檢視所屬自己的任務 |
5 |
5（mypage） |
|
介面友好 |
5 |
2 （無設計感、操作便攜性） |
|
學習難度 |
2（涉及角色比較多） |
4 |
|
技術支援服務 |
5 |
3 |
|
總分 |
100 |
80 |
通過這個表格對兩款軟體進行詳盡的對比，可見禪道在功能上要比redmine略勝一籌。併為以後加強產品管理提供了很大的空間。
在測試相關功能方面，列舉幾個禪道與redmine的差異之處：
首先在測試用例執行方面的對比如下。
|
禪道 |
|
|
|
禪道提供了豐富的二次開發介面，用例執行甚至可以觸發一個自動化測試指令碼對其進行測試。用例執行失敗後可以直接轉到bug對開發人員進行反饋。 |
|
redmine+testlink |
|
|
|
testlink也支援測試用例執行並轉bug，但是根據調研顯示支援的bug管理系統有：jira、bugzilla、mantis，並不支援redmine。 |
為了在文件中體現測試用例、bug的情況，對redmine和禪道的匯出功能進行對比：
|
禪道 |
|
|
|
支援 csv、xml、html（可自定義匯出欄位、編碼） html匯出可點選連結跳轉回禪道bug管理詳情介面，功能很人性化。 |
|
redmine |
|
|
|
redmine 支援 pdf、csv，（中文不友好） |
為了檢視產品測試迭代的狀況，要檢視bug的統計表，對bug統計表的對比如下：
|
禪道 |
|
|
|
禪道報表（視覺化效果一幕瞭然，統計專案更多） |
|
redmine+testlink |
|
|
|
用bug數量作為統計結果並不能反應產品bug的收斂情況。 |
對於產品經理、測試人員每天都要安排自己的工作內容，並且要跟蹤自己負責產品、專案的最新狀態，測試人員和開發人員要經常進行互動，因此每個人最好應該有個主頁記錄自己工作的完成情況。
|
禪道 |
|
|
|
高度自定義的設計，產品經理可以檢視還沒有立項的需求，研發、測試人員可以檢視bug的反饋。每個人都可以清晰地知道自己有哪些任務與沒有完成。 |
|
redmine |
|
|
|
Redmine只能檢視bug的反饋情況。 |
禪道在督促大家工作進度方面做的很好，每天早上一封郵件提醒，提醒還有哪些任務沒有完成、哪些bug沒有修復等等：
對於公司來說：研發、產品經理關注於任務、需求、bug狀態等資訊。QA測試人員關注於任務、用例、bug狀態等資訊。部門負責人可以安排任務並將其指派給產品經理、測試人員等。在禪道中每個人都可以自定義自己的todolist，這個功能有助於個人安排好自己的時間。
禪道中針對敏捷開發思想中的“任務”模組有時間跟蹤功能，這個功能加以利用後可以通過燃盡圖非常方便的瞭解專案當前的進展情況。
3.3使用禪道有哪些挑戰
由於大家現在習慣了使用redmine進行bug跟蹤管理，對於禪道的操作方法比較陌生，因此有一定的學習成本，但是我相信通過一兩次培訓加上一個專案的實踐完全可以掌握的。
技術總監應督促大家更新任務進度，必須嚴格執行，如果加以行政處罰、獎勵效果會更好。