总结：近几年有哪些不错的 scrum 工具

目前针对产品研发管理的工具和平台大致可分为三类，但无论是哪一类，因为敏捷理念的火热，或多或少的能支持一些 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 管理工具能多大程度地实现我们项目管理的需求，评估它所具备项目管理的功能的强弱。

并且在体验的过程中，我还发现，Pingcode 不仅完全支持 Scrum 方法论，Kanban 也是同样支持。

三、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 管理中比较好用的功能。但这里就偷个懒，不一一讲解。

就体验来看，PingCod在系列 Scrum 管理工具中也是特别值得尝试的一个选择，当然，需求各有不同，我是以自身团队的经验来判断的，也仅供大家参考。

附上链接：PingCode