目前针对产品研发管理的工具和平台大致可分为四类，但无论是哪一类，因为敏捷理念的火热，或多或少的能支持一些Scrum的需求，这也就造成了大家现在选择Scrum工具时更加迷惑。下面我们就简单聊聊这四类工具分别是什么，又适用于什么样的环境。
一、基础的scrum 工具
1、白板
白板是实施Scrum 最简单直接的方式，用于每天跟踪汇报，简明易懂。但是对Product Backlog支持明显不够，也没办法保留历史纪录，而历史记录对于回顾还是非常重要的，毕竟Scrum 的核心理念之一就是通过短期回顾,达到持续不断的改善。
2、Excel
Excel 相信很多团队也有尝试过，也有很多现成的模板可以用，但它主要问题是当成员比较多的时候，同时修改一个共享Excel文件，会相互冲突，不好同步；同时表格的整理需要花费比较多的时间，以及可视化管理功能并不满足等（如燃尽图）
除了最基础的工具，还有三类平台：
二、平台类Scrum 工具
平台类：钉钉，飞书
协作类：Worktile，Tower， Trello，Teambition，Asana，Basecamp等
研发类：PingCode，Jira，Tapd，Coding等
平台类，虽然通过插件的形式具备了部分Scrum的功能，但总体来说，基本是各种办公软件的大杂烩，用于 Scrum 太过于臃肿。在一定程度也存在下架风险，比如插件厂商与平台没谈好下架的情况在以往也并不少见。
协作类的软件的适用的范围比较广，一定程度也能满足了Scrum管理的需求。 但这些协作软件都有一个共同的特点——以项目的方式来满足Scrum管理需求，这样做当然能用，但体验不好（别问为什么，谁用谁知道）。
所以从易用性和操作体验、以及代码托管等开发工具之间数据打通等方面而言，平台类、协作类和专业的研发类工具来说有较大差距。
用一句废话来总结就是：无论是Scrum管理或者更广义一点来说研发管理需求来说，肯定是专业的研发类工更适合。
三、落地Scrum 需不需要工具？工具该如何选择？
如果团队在25人以下，由于规模小信息差不大，流程简单，很多事情拉个会议，使用一般的白板或者是在线文档就能满足需求，这个时候上工具有时候反而会给团队的效率造成阻碍。
但是当敏捷成为超过百人团队，或进行大型项目的主流开发方式时，这些自己临时组织起来的技术团队，或者是在跨团队之间，以及日常管理多个团队，如仅靠白板、电子表格和Wiki 等将难以满足需求。
要选择一个适合的工具，其实就是判断它能否满足我们的Scrum 管理需求。而作为一个Scrum工具，一定要考虑是否支持Scrum框架所必需的基本元素，如Product Backlog、Sprint Backlog、Bumdown Chart等。
这里根据Scrum方法论的管理流程列出来一些基本功能，以研发工具PingCode 举例：
四、Scrum管理工具的简单评测
为了避免口水战，我们这里仅从Scrum方法论出发，对比这些工具在功能匹配度上的一些不同（仅供参考，体验深度问题可能有一定程度出入）
从Scrum工具的功能层面角度可以看出，PingCode 这里做的是比较不错的，甚至是说完整支持了 Scrum 敏捷开发流程。
当然，功能数量只是表面，我们还做了更深入的测评，由于每个测评篇幅会过长，所以这里我们就以PingCode为例。
五、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管理工具中也是特别值得尝试的一个选择，当然，需求各有不同，我是以自身团队的经验来判断的，也仅供大家参考。