目前针对产品研发管理的工具和平台大致可分为三类，但无论是哪一类，因为敏捷理念的火热，或多或少的能支持一些Scrum的需求，这也就造成了大家现在选择Scrum工具时更加迷惑。下面就个人经验和观察，就Scrum理念对这些工具进分类和简单测评，希望能帮大家拨开云雾见天日。
文章可能较长，目录：
1、三类平台的简单区分
2、Scrum方法论具体的功能需求有哪些？
3、基于Scrum的功能需求，几家工具的简单评测
4、Scrum管理工具深入体验及推荐
一、三类平台的简单区分
1、平台类：钉钉，飞书
2、协作类：Worktile，Tower， Trello，Teambition，Asana，Basecamp等
3、研发类：PingCode，Ones，Jira，Tapd，Coding，禅道等
平台类，虽然通过插件的形式具备了部分Scrum的功能，但总体来说，基本是各种办公软件的大杂烩，用于 Scrum 太过于臃肿。在一定程度也存在下架风险，比如插件厂商与平台没谈好下架的情况在以往也并不少见。
协作类的软件的适用的范围比较广，一定程度也能满足了Scrum管理的需求。 但这些协作软件都有一个共同的特点——以项目的方式来满足Scrum管理需求，这样做当然能用，但体验不好（别问为什么，谁用谁知道）。
所以从易用性和操作体验、以及代码托管等开发工具之间数据打通等方面而言，平台类、协作类和专业的研发类工具PingCode，Ones，Jira，Tapd，Coding，禅道等来说有较大差距。
用一句废话来总结就是：无论是Scrum管理或者更广义一点来说研发管理需求来说，肯定是专业的研发类工更适合，这些专业的研发工具的测评我们在后面进行。
二、Scrum方法论具体的功能需求有哪些？如何评判一个Scrum管理工具的好坏?
在介绍Scrum工具之前，先和大家来分享一下Scrum管理包含哪些工作内容。
因为工具一定可以帮助解决工作内容的一部分甚至全部，而如何判断Scrum工具的好坏，其实就是判断工具能多大程度地实现我们Scrum管理的需求。下面我就从完整的敏捷流程工作内容来看，一个基本的敏捷管理工具应该包含的能力。
当然这里我们只是根据Scrum方法论的管理流程列出来一些基本功能。
这里以PingCode做对应案例
上面我们已经得出了一些基本的功能，如上面所讲，评估一款Scrum管理工具的优劣，也就是判断Scrum管理工具能多大程度地实现我们项目管理的需求，评估它所具备项目管理的功能的强弱。
三、Scrum管理工具的简单评测
为了避免口水战，我们这里仅从Scrum方法论出发，对比这些工具在功能匹配度上的一些不同（仅供参考，体验深度问题可能有一定程度出入）
从Scrum工具的功能层面角度可以看出，PingCode 这里做的是比较不错的，甚至是说完整支持了 Scrum 敏捷开发流程。
当然，功能数量只是表面，我们还做了更深入的测评。
四、Scrum管理工具的深入体验
目录：
Scrum角色管理
需求管理
规划
缺陷管理
迭代
跟踪迭代进度
迭代回顾
1、Scrum角色管理
Scrum 框架下有3种常见角色：产品负责人（Product Owner）、敏捷教练（Scrum Master） 团队成员（Scrum Team）
在体验中，PingCode 能以自定义项目角色和权限的方式对成员进行分组和权限管理。比如配置不同角色不同的管理和查看项目、工作项类型等权限，项目成员亦可拥有多个角色。
2、需求管理
按照Scrum的一般做法，迭代开始前，由产品负责人收集来自各方需要、期望和诉求，评定优先级，整理出产品 Backlog，通过会议评审形成 Sprint Backlog。
在体验中，PingCode是以史诗、特性、用户故事三级方式进行需求管理。可以通过自定义需求状态、补充各类属性字段，编写完整描述，上传相关产品文档等方式，形成完整的故事结构。 也可以利用「子工作项」进行复杂需求细化和拆解
当然，值得一提的是需求也可与用户反馈、研发任务、测试结果、Wiki的文档等工作项相关联，便于其它成员查找引用、追溯来源。
3、规划
无论是产品规划或者是制定产品的里程碑，产品路线图对于产品团队来说都是很需要的，我们来看看Pingcode的表现：
用一句话来形容就是：我们一眼就能看到未来三个月甚至一年要做哪些产品功能，而且能知道先做什么，再做什么，哪一个功能做完才能做另外一个功能。
是管理层特别喜欢的功能了
4、缺陷管理
这个模块很明确，就是列出我们开发过程中或者通过用户反馈提交的所有的缺陷，具备优先级等属性设置。
5、迭代
这是我们敏捷开发过程中用到的最核心的功能，也是支撑我们 Scrum 流程的灵魂。
就PingCode来说，在Sprint规划以及信息丰富度上，可圈可点。
这里我最想聊的是工作项（可能这不在Scrum管理之列），这是一个真正体现研发团队的价值的数据的能力。
比如下面的用户故事 ：该用户故事的负责人是谁，子任务如何拆分的，关联了哪些工作项，关联的测试用例是什么，开发过程中提交的开发数据和信息是怎样的，工时是怎么登记的，关联的 Wiki 页面是什么，都上传了哪些附件，评论中都讨论了哪些事情，该工作项的活动轨迹是什么，状态是怎么流转的等等。
6、跟踪迭代进度
迭代开始后，每日站立会议对迭代进行跟踪。各成员快速任务进度、今天的计划、遇到的困难等就成为常态，燃尽图在这里必不可少。
我们从下图也能看出，PingCode迭代概览、燃尽图基本具备，在直观反映各成员工作状况、当前迭代进度的健康程度上并没有啥毛病。
好家伙，还支持十多种报表
7、迭代回顾
在迭代完成后，团队成员对当前迭代所完成的工作成果进行演示复盘。
这个环节PingCode支持整个迭代情况概览，以及迭代回顾看板记录，基本能满足回顾复盘的需求。
并且在体验的过程中，我还发现，Pingcode不仅完全支持Scrum方法论，Kanban也是同样支持。
除以上讲的一些之外，我发现PingCode还具备版本、筛选器（全局搜索）、工时统计等一些在Scrum管理中比较好用的功能。但这里就偷个懒，不一一讲解。
就体验来看，PingCod在系列Scrum管理工具中也是特别值得尝试的一个选择，当然，需求各有不同，我是以自身团队的经验来判断的，也仅供大家参考。
附上文中工具链接：
原文地址：https://zhuanlan.zhihu.com/p/345626690
Q.E.D.