震惊（手动狗头保命），敏捷开发团队居然不会选择协作工具。
大家好，我叫猫哥，猫哥已从事IT行业10年，先后在研发，项目管理，产品等岗位工作和学习。
相信各位IT大神在工作中，经常面临需求不明确，项目延期的问题。猫哥和你们一样经常被这些问题折磨，本身工作是一件愉悦的事，但是被这些问题搞的心烦意乱。
这么多年来，猫哥一直在寻找一款趁手的工具来提高工作效率。
猫哥按照项目管理的基本要求（目标明确，任务明确，分工明确，沟通流畅），前前后后试用用过很多款项目管理工具，比如coding，tapd，teambition, gitee等。
今天猫哥把这些项目协作软件做一个简单的说明介绍，方便大家选择合适的协作工具(这里比较的都是企业版)。
一、产品需求
从产品角度来说，我们更多的是关注需求描述，毕竟需求描述清楚了，才能避免反复的沟通。说到产品需求，我们除了描述需求外，还会关注需求的状态（需求所在的阶段），这样能够让我们及时了解产品需求当前的一个状态，也是为后续工作提供信息支撑。
我们从需求描述和需求状态两个标准为大家推荐：
Coding ⭐⭐⭐⭐⭐
每个需求有自己的状态（待评估，已评估，开发中，已发布，已关闭）以及关联的任务，可以切换到看板模式，很方便。这对于产品经理来说，很容易了解当前需求的进度，方便及时的去验证产品。
Tapd ⭐⭐⭐⭐
以树的形式管理需求，需求层次，状态分明，看着比较清晰。但是不能任务关联，这里有点不方便。在文档管理里面提供了word在线编辑和思维导图功能，这点很nice，猫哥很喜欢。
Teambition ⭐⭐⭐⭐
需求从收集，评估，已采纳，设计，开发，测试，未采纳一条龙服务，整体给人的感觉比较清晰，对需求进行一个聚合管理。也方便产品经理及时查阅，但是需要产品经理自行去和开发人员核对需求是否开发。
Gitee ⭐⭐⭐
它的需求管理与Coding和Teambition模式还不太一样，是以文档的形式呈现，对于爱用office套件写文档的同学来说简直就是福利。同时支持文档内容检索，左侧可以自定义树，对需求进行归类管理。唯一不好的是不能在线编辑office文档，这对提高工作效率是不友好的，所以猫哥给3颗星。
从需求和任务的关联，猫哥喜欢coding，不考虑需求和任务的关联，比较倾向选择Teambition
二、任务分配
猫哥混迹项目管理岗位多年，对任务分配很敏感，如果任务分配不好，那执行效率大大的打折扣，以至于项目延期。对于开发人员来说，任务一定要和需求关联，不然会花很多时间去找任务对应的需求文档，同时执行人员要了解当前任务的一个状态。
所以我们会从需求关联和任务状态去评判功能是否满足要求。
Coding ⭐⭐⭐⭐
任务可以通过引用的操作方式进行关联，可以在任务中快速的查看需求，这点很nice。任务状态简单明了（未开始，进行中，已关闭）。对于任务被指派人来说，只关注哪些是当前应该做的事情。如果任务被重新打开，可以在评论里面补充描述。猫哥给4星，因为任务详情用户视觉聚焦可以改进一下，建议重点突出标题，描述，子任务重点要素。
Tapd ⭐⭐⭐
以看板的方式呈现任务，并且可以根据实际协作情况，添加板块。功能和其他协作软件都差不多，比较中规中矩。标准看板不能查看详情，得在成员视图模式下，才能点开查看详情。作为初始使用者，需要摸索一下。
Teambition ⭐⭐⭐⭐
默认采用看板的方式，任务通过待处理，进行中，已完成三种方式来聚合，同样简单明了，适合大多数的应用办公场景，不局限于软件开发任务。点击空白区域关闭详情，这点细节做的挺不错。
Gitee ⭐⭐
Gitee进入任务面板以后，默认以列表呈现任务，多了一个安排时间，同一个任务可以由不同的人一起来完成（负责人和协作者），这点对于使用人员来说比较友好，也就是说我知道我该什么时候去完成我的任务，谁和我一起完成，我们项目开发过程中会经常遇到此类问题（两人一起完成一个任务）。
但是没有对附件进行关联，需要手动上传，同时任务列表状态没有文字描述，看起来很不友好，基于这两点，推荐2星。
任务管理大同小异，大部分软件都能满足使用要求，如何选择，看个人对用户体验要求标准，毕竟用户体验影响工作效率。
三、开发与运维
任务明确了，减少开发人员与需求人员之间的沟通时间成本，但是开发人员内部之间还存在很多细节工作。像代码托管，程序部署，前后端的沟通都会耗费大量的时间。对于开发人员来说，希望把更多的时间和精力放在编写代码上。
所以我们会从代码托管，程序部署，API文档管理来评判
Coding ⭐⭐⭐⭐⭐
基于git的代码托管功能完整，同时支持SVN管理。对分支管理，合并请求，对比提供了友好的操作。一键初始化git仓库，可快速使用。
Coding提供了持续集成和持续部署，大大的减少了运维成本，使开发人员无需再关注运维的工作，只需前期简单配置即可。
前端和后端关注的是API文档，可以快速的把openAPI ，postman，apiDoc的文档导入进来，进行统一规范化的管理。开启Mock api让前后端同时开发，减少开发联调时间。
Tapd ⭐⭐⭐
Tapd 同样提供git代码托管，一站式持续和交付。但是猫哥没有发现API文档管理功能，只能借助文档管理，实现记录api文档，但是不能在线调用接口测试，可使用其他工具进行补充。
Teambition ⭐⭐⭐
猫哥在官网上没有找到Teambition的代码托管功能介绍，后来在朋友的指点下，在一处隐蔽的地方 找到了代码托管功能：行云 。行云提供了git常见的一些功能，能满足用户的基本使用，但是对于初次使用的人来说不太友好，官网没有介绍，入口相对偏僻，所以推荐指数三颗星。
Gitee ⭐⭐⭐⭐
gitee同样提供持续集成，代码托管。唯一的特色是有代码质量分析和代码审查流程，对项目质量把控严格的公司，这点无疑是最好用的功能。
API的话，gitee需要手动创建接口文档并且手动编写，不能像coding提供全自动管理。
减少运维时间成本和API维护时间成本，让我们只关注代码。选择一款合适的工具，让我只想做一个快乐的码农，快快乐乐的敲代码，维护什么的工作，交给它吧。
四、测试
说到测试，我们不得不得说测试用例，很久以前我们用excel写测试用例，每次遇到文档更新，头疼的事就开始了“怎么我拿到的测试用例不是最新的？”，“为什么这个地方程序改了，测试用例文档还没有更新”，直到有一天遇到了coding，原来测试工作是这么的nice。
对于测试团队来说，更多的是关注测试流程完整整规范和快速创建缺陷清单
Coding ⭐⭐⭐⭐⭐
提供测试用例管理，用例评审，测试计划，测试报告，简直就是测试团队的神器。
这里有一个比较有特色的小功能：快速的创建缺陷并且自动关联当前测试用例，以任务的形式发送给解决者，减少了沟通时间。
Tapd ⭐⭐⭐⭐⭐
提供bug管理和测试用例，其中bug管理可以设置工作流，这样可以适应团队工作流程。
测试用例管理也满足日常开发需求，提供评审，快捷创建需求。
Teambition ⭐⭐⭐⭐
提供测试用例管理，但是没有用例评审，功能较为简单，并且不能够提供评审以及快速创建缺陷的功能，比较适合小型项目。
Gitee ⭐⭐
没有提供专门的测试用例管理，如果要使用，需要借助其他测试用例软件。只提供了缺陷跟踪任务，对于不需要写测试用例的团队来说，可以使用gitee提供的缺陷跟踪。
对有写测试用例要求的团队，推荐使用coding，Tapd，Teambition
总结
最后猫哥为大家介绍一下怎么薅羊毛
5人以内，推荐使用Coding，一站式服务，值得你拥有。
10人以内，并且不考虑持续集成和API文档管理的情况下，推荐使用 Tembition。
Tapd 标准版和专业版是免费的，企业版提供持续集成，并且收费
