震惊(手动狗头保命),敏捷开发团队居然不会选择协作工具。

大家好,我叫猫哥,猫哥已从事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 标准版和专业版是免费的,企业版提供持续集成,并且收费

你可能感兴趣的:(震惊(手动狗头保命),敏捷开发团队居然不会选择协作工具。)