建議先思考嚎朽，我們選擇開發(fā)管理的工具的標準是什么，然后拿這些標準作為尺子柬帕，去衡量各個開發(fā)管理工具哟忍。
粗略提供幾個思考點：（1）團隊規(guī)模（2）團隊成員對開發(fā)過程管理的理解、配合程度（3）產(chǎn)品/項目類型陷寝，質(zhì)量要求……如果團隊規(guī)模小锅很，項目要快速交付，或者互聯(lián)網(wǎng)產(chǎn)品凤跑，快速迭代實現(xiàn)功能優(yōu)先爆安，質(zhì)量不是考慮在第一位的，建議svn源代碼管理＋其余用黑白仔引、白板扔仓、卡紙、手寫文檔＋及時會議討論的形式做開發(fā)過程管理咖耘，不借助專門的開發(fā)過程管理工具翘簇。
不用工具勝過用工具。如果產(chǎn)品是質(zhì)量要求在先儿倒，例如目前開發(fā)的是產(chǎn)品某個核心版保、底層模塊，哪怕是5人的小團隊义桂，都建議使用開發(fā)過程管理工具找筝。因為這個時候，例如需求功能點與測試用例的對應關系慷吊，測試報告與測試用例的關系袖裕，bug與測試報告的關系，設計與功能點的關系溉瓶，代碼與設計的關系急鳄，這些都嚴格監(jiān)控谤民，這些對應關系手工非常難維護。質(zhì)量的漏洞不僅僅是因為寫代碼引發(fā)疾宏，例如张足，某個需求功能點，根本沒有對應的測試用例匹配把關坎藐，那么問題將是嚴重成——這個功能點是否有問題都不知道为牍，如果不借助管理工具，這個問題能輕易發(fā)現(xiàn)嗎岩馍？很難碉咆。在質(zhì)量要求為先的情況下，甚至一遍寫功能點實現(xiàn)代碼蛀恩，一邊寫測試單元測試用例疫铜，借助工具，可以讓代碼check in時自動觸發(fā)單元測試用例的執(zhí)行双谆，測試用例執(zhí)行通過的代碼才能提交成功壳咕。（如果提交的代碼沒有單元測試用例，那么也是提交失敗的顽馋。）……
當然谓厘，有些團隊成員整體素質(zhì)比較高，哪怕是要求快速迭代寸谜，實現(xiàn)功能優(yōu)先的產(chǎn)品開發(fā)庞呕，也能和開發(fā)管理工具配合得很好。無論是有工具程帕，還是沒有工具，共同點都是對開發(fā)過程管理的理解地啰、制定要求愁拭、執(zhí)行。所以應該避免只是從開發(fā)管理工具表面的某些功能點好不好用等用顯微鏡式觀察某幾個斑點的方式去選擇開發(fā)工具亏吝。
從兩年前稍用過的禪道看岭埠，需求管理支持不足的，之前沒有找到需求功能點如何與測試用例對應起來的操作蔚鸥，不支持需求功能點和代碼建立對應關系的惜论。如果項目的質(zhì)量要求比較高，禪道時支持不足的止喷。用得也不久馆类，如果寫錯了，請輕噴弹谁。
見過有些團隊用禪道乾巧，聲稱用敏捷句喜，但是不知道用戶故事，不知道用戶故事如何按格式簡練紀錄沟于，不知道測試用例咳胃，填得一團糟，根本沒有起到管理項目的作用旷太≌剐福混亂不是來自工具是否用了，在與團隊成員的知識供璧、技能存崖。
另外在團隊成員對開發(fā)過程管理的理解程度很低的情況下，不是考慮用哪個開發(fā)管理工具的問題嗜傅，而是先撇開開發(fā)管理工具金句，用紙質(zhì)文檔＋會議的方式管理起來先，對團隊成員做普及性培訓吕嘀。
相關文章：
互聯(lián)網(wǎng)產(chǎn)品的制作和協(xié)同的問題，那些跑的快的公司是怎么解決的偶房？
