項目中如下情景，是否似曾相識？

項目中的管理黑洞，始終看不到項目完成的盡頭
像呆伯特的經(jīng)理那樣感覺良好？
還是項目一再延期，bug永遠也改不完？
好的想法、靈感沒有及時記錄，稍縱即逝
要是有一個在桌面上的任務管理平臺多好？
測試和研發(fā)的溝通還停留在口頭？或者紙質(zhì)的記錄單上？
您需要缺陷跟蹤、軟件生命周期管理軟件
開發(fā)人員代碼提交說明不知所云
時間長了，連程序員自己也說不清為何而更改...
1. 提高項目的可視性

　　項目的可視性，是項目經(jīng)理和高層經(jīng)理關(guān)注的問題。提高可視性，能夠即使掌握項目進展，及早做出準確的決策。

項目目前的進展如何？

　　從路線圖可以看出該里程碑的完成度為 87%，尚有一個問題沒有解決。

每項目是如何推進的?

　　從時間線的界面，可以以天為單位查看發(fā)生的事件。還可以對事件進行篩選。

2. 改進項目工作流

　　企業(yè)的每個員工都是工作鏈條不可或缺的一環(huán)。順暢的工作流，每個人各司其職，高質(zhì)量的產(chǎn)品源源不斷按照計劃產(chǎn)出。

很多企業(yè)/團隊的工作流尚不流暢：

任務、需求不能實現(xiàn)跟蹤。
任務、需求正在由誰完成？
任務、需求的變更是否已經(jīng)向下傳達？
任務、需求是否已經(jīng)完成？
任務、需求的實現(xiàn)是否已經(jīng)通過檢測？
缺陷報告和修復通知還在用口口相傳的原始方式？或者高技術(shù)下的口口相傳 ── Excel 表單？
口口相傳，即使使用了Excel表單，也解決不了缺陷的追蹤問題
即難以準確記錄缺陷的生命周期（缺陷從發(fā)現(xiàn)、分配、修正到通過驗收）的流程中各個環(huán)節(jié)的實施過程
口口相傳，即使使用了Excel表單，也是低效率的溝通
低效率的溝通，浪費了寶貴的時間。人越多，產(chǎn)出卻不成正比？── 重看一遍《人月神化》
為什么不用管理軟件來改進工作流？

　　以 issue 的形式管理每個需求、任務和缺陷。一個 issue 記錄了整個需求或者缺陷的生命周期。

　　工作狀態(tài)的變更以郵件通知作為工具，通過相關(guān)人員。團隊成員成為工作流中互相促進的齒輪。

3. 高度的整合

統(tǒng)一的用戶管理和單點登錄整合

　　和其他的群英匯軟件產(chǎn)品一樣，實現(xiàn)了用戶管理的整合。單點登錄可以不用頻繁輸入用戶名/口令，即可安全登錄。

和代碼管理的整合：能夠不離開項目管理平臺，擁有代碼權(quán)限的人員可以瀏覽代碼和日志

參見: 這里...

　　和代碼管理的整合：開發(fā)人員可以不登錄任務管理平臺，直接提交代碼修改 需求/任務/缺陷 的狀態(tài)

參見: 這里...

　　和代碼管理的整合：代碼提交，可以自動獲取任務/缺陷列表，填寫提交說明

參見: 這里...

4. 工作更敏捷、開發(fā)人員更出色

　　敏捷是對于大多數(shù)研發(fā)團隊好的方法論和組織模式。將工作任務分解、細化，建立更小的迭代，進而獲得更快的用戶反饋和成果激勵。 軟件研發(fā)團隊要想實現(xiàn)敏捷，建立完善的任務管理和缺陷跟蹤必不可少。

出色的開發(fā)人員，選擇正確的工作模式。

錯誤：任務千頭萬緒，工作沒有主次，抱怨連連。
正確：的工作從設(shè)定計劃開始。
錯誤：好的想法，靈感沒有記錄下來，稍縱即逝。
正確：一旦發(fā)現(xiàn)問題，或有靈感，馬上在 redmine 中增加一條 issue 記錄。
錯誤：把版本控制系統(tǒng)當做備份系統(tǒng)，每天只做一次提交，提交當天所有改動。
正確：一次提交只干一件事，不要針對多個任務進行混合提交。
錯誤：不知如何寫代碼的提交說明？
正確：在提交說明用issue號指明問題的所在。在提交說明中著重寫解決方案或思路──為什么這么改。