項目中如下情景，是否似曾相識？
項目中的管理黑洞，始終看不到項目完成的盡頭
像呆伯特的經理那樣感覺良好？
還是項目一再延期，bug永遠也改不完？
好的想法、靈感沒有及時記錄，稍縱即逝
要是有一個在桌面上的任務管理平臺多好？
測試和研發的溝通還停留在口頭？或者紙質的記錄單上？
您需要缺陷跟蹤、軟件生命周期管理軟件
開發人員代碼提交說明不知所云
時間長了，連程序員自己也說不清為何而更改...
1. 提高項目的可視性
項目的可視性，是項目經理和高層經理關注的問題。提高可視性，能夠即使掌握項目進展，及早做出準確的決策。
項目目前的進展如何？
從路線圖可以看出該里程碑的完成度為 87%，尚有一個問題沒有解決。
每項目是如何推進的?
從時間線的界面，可以以天為單位查看發生的事件。還可以對事件進行篩選。
2. 改進項目工作流
企業的每個員工都是工作鏈條不可或缺的一環。順暢的工作流，每個人各司其職，高質量的產品源源不斷按照計劃產出。
很多企業/團隊的工作流尚不流暢：
任務、需求不能實現跟蹤。
任務、需求正在由誰完成？
任務、需求的變更是否已經向下傳達？
任務、需求是否已經完成？
任務、需求的實現是否已經通過檢測？
缺陷報告和修復通知還在用口口相傳的原始方式？或者高技術下的口口相傳 ── Excel 表單？
口口相傳，即使使用了Excel表單，也解決不了缺陷的追蹤問題
即難以準確記錄缺陷的生命周期（缺陷從發現、分配、修正到通過驗收）的流程中各個環節的實施過程
口口相傳，即使使用了Excel表單，也是低效率的溝通
低效率的溝通，浪費了寶貴的時間。人越多，產出卻不成正比？── 重看一遍《人月神化》
為什么不用管理軟件來改進工作流？
以 issue 的形式管理每個需求、任務和缺陷。一個 issue 記錄了整個需求或者缺陷的生命周期。
工作狀態的變更以郵件通知作為工具，通過相關人員。團隊成員成為工作流中互相促進的齒輪。
3. 高度的整合
統一的用戶管理和單點登錄整合
和其他的群英匯軟件產品一樣，實現了用戶管理的整合。單點登錄可以不用頻繁輸入用戶名/口令，即可安全登錄。
和代碼管理的整合：能夠不離開項目管理平臺，擁有代碼權限的人員可以瀏覽代碼和日志
參見: 這里...
和代碼管理的整合：開發人員可以不登錄任務管理平臺，直接提交代碼修改 需求/任務/缺陷 的狀態
參見: 這里...
和代碼管理的整合：代碼提交，可以自動獲取任務/缺陷列表，填寫提交說明
參見: 這里...
4. 工作更敏捷、開發人員更出色
敏捷是對于大多數研發團隊好的方法論和組織模式。將工作任務分解、細化，建立更小的迭代，進而獲得更快的用戶反饋和成果激勵。 軟件研發團隊要想實現敏捷，建立完善的任務管理和缺陷跟蹤必不可少。
出色的開發人員，選擇正確的工作模式。
錯誤：任務千頭萬緒，工作沒有主次，抱怨連連。
正確：的工作從設定計劃開始。
錯誤：好的想法，靈感沒有記錄下來，稍縱即逝。
正確：一旦發現問題，或有靈感，馬上在 redmine 中增加一條 issue 記錄。
錯誤：把版本控制系統當做備份系統，每天只做一次提交，提交當天所有改動。
正確：一次提交只干一件事，不要針對多個任務進行混合提交。
錯誤：不知如何寫代碼的提交說明？
正確：在提交說明用issue號指明問題的所在。在提交說明中著重寫解決方案或思路──為什么這么改。
