建议先思考，我们选择开发管理的工具的标准是什么，然后拿这些标准作为尺子，去衡量各个开发管理工具。
粗略提供几个思考点：（1）团队规模（2）团队成员对开发过程管理的理解、配合程度（3）产品/项目类型，质量要求……如果团队规模小，项目要快速交付，或者互联网产品，快速迭代实现功能优先，质量不是考虑在第一位的，建议svn源代码管理＋其余用黑白、白板、卡纸、手写文档＋及时会议讨论的形式做开发过程管理，不借助专门的开发过程管理工具。
不用工具胜过用工具。如果产品是质量要求在先，例如目前开发的是产品某个核心、底层模块，哪怕是5人的小团队，都建议使用开发过程管理工具。因为这个时候，例如需求功能点与测试用例的对应关系，测试报告与测试用例的关系，bug与测试报告的关系，设计与功能点的关系，代码与设计的关系，这些都严格监控，这些对应关系手工非常难维护。质量的漏洞不仅仅是因为写代码引发，例如，某个需求功能点，根本没有对应的测试用例匹配把关，那么问题将是严重成——这个功能点是否有问题都不知道，如果不借助管理工具，这个问题能轻易发现吗？很难。在质量要求为先的情况下，甚至一遍写功能点实现代码，一边写测试单元测试用例，借助工具，可以让代码check in时自动触发单元测试用例的执行，测试用例执行通过的代码才能提交成功。（如果提交的代码没有单元测试用例，那么也是提交失败的。）……
当然，有些团队成员整体素质比较高，哪怕是要求快速迭代，实现功能优先的产品开发，也能和开发管理工具配合得很好。无论是有工具，还是没有工具，共同点都是对开发过程管理的理解、制定要求、执行。所以应该避免只是从开发管理工具表面的某些功能点好不好用等用显微镜式观察某几个斑点的方式去选择开发工具。
从两年前稍用过的禅道看，需求管理支持不足的，之前没有找到需求功能点如何与测试用例对应起来的操作，不支持需求功能点和代码建立对应关系的。如果项目的质量要求比较高，禅道时支持不足的。用得也不久，如果写错了，请轻喷。
见过有些团队用禅道，声称用敏捷，但是不知道用户故事，不知道用户故事如何按格式简练纪录，不知道测试用例，填得一团糟，根本没有起到管理项目的作用。混乱不是来自工具是否用了，在与团队成员的知识、技能。
另外在团队成员对开发过程管理的理解程度很低的情况下，不是考虑用哪个开发管理工具的问题，而是先撇开开发管理工具，用纸质文档＋会议的方式管理起来先，对团队成员做普及性培训。
相关文章：
互联网产品的制作和协同的问题，那些跑的快的公司是怎么解决的？
