PingCode与Jira敏捷开发项目管理能力对比
敏捷开发是一种以拥抱用户需求为核心、采用不断迭代的方式进行的软件开发模式，依靠自组织的跨职能小团队，在短周期内通过快速、频繁的迭代，迅速的获取反馈，进而不断的完善产品，给用户带来更大的价值。
虽然敏捷诞生只有20年的时间，但却帮助了许多企业取得了成功，在这期间也涌现出来各种敏捷方法论和思想体系，最常用的两种敏捷实践分别为 Scrum 和 Kanban，采用合适的敏捷开发工具能够帮助团队更好的逻辑敏捷实践。
本文我们就来对比一下国产化的智能研发管理工具PingCode和海外产品Jira在敏捷开发方面的支持差异。
1. 敏捷实践支持
一套合适的敏捷开发工具，可以使得每个团队独立自主工作，并与企业中的其他团队协作，每个团队都可以采用适合他们的敏捷实践，并对工具进行个性化的配置。
从整体来看，在敏捷实践的支持方面，PingCode和Jira都支持Scrum和Kanban两种敏捷实践，这也是当前研发团队采用最多的敏捷实践。
PingCode 中创建项目可以选择Scrum和Kanban两种项目类型：
Jira 中创建项目时可以选择Kanban、Scrum和Bug Tracking三种项目类型：
2. Scrum 支持对比
在敏捷开发流程 Scrum 标准定义中，有两个关键性的产物：Product Backlog 和 Sprint Backlog，以及四个关键的时间：计划会议、每日立会、评审会议和回顾会议。
下面我们来考察一下 PingCode 和 Jira 这两个敏捷开发工具在 Scrum 这些关键性活动中的支持。
2.1 路线图规划
在一个 Scrum 类型的项目中，PingCode 和 Jira 都支持通过甘特图可视化的方式进行路线图的规划，以便很方便的查看每个工作项的开始/截止时间。但是由于二者在需求管理逻辑上的不同，导致路线图的规划方式也有细微的差别。
PingCode 中的 Scrum 项目内置采用Epic / Feature / User Story 三级需求管理：
- Epic：史诗，表示比较大的特性，开发周期一般是1-3月
- Feature：特性，表示相对小一些的特性，开发周期一般是1-3周
- User Story：用户故事，表示最小的用户场景，开发周期一般是1-3天
因而你可以在 PingCode 中的路线图上对这三级工作项进行可视化的规划；Jira 中的 Scrum 项目默认提供的是 Epic / User Story 两级需求管理。
Jira 中的Roadmap可以对 Epic 和 User Story 进行规划：
2.2 Product Backlog 管理
在 Scrum 开发中，Product Backlog作为一个具有优先级的需求列表，包括了所有预知的需要完成的产品工作，如产品规划的需求、用户提出的改进、技术升级优化等。
PingCode 中包括需求和缺陷两类 Product Backlog，在一个特定的项目中使用两个独立的组件展示：
Jira 中具有一个单独的 Backlog 组件，所有的待办事项都在此列表中展示：
2.3 Sprint Backlog 规划
在一个Scrum迭代开始前的计划会议上，团队成员会一起从Product Backlog中根据确定的优先级，挑选出当前迭代需要完成的工作项，并对这些工作项进行故事点估算，并进行任务拆解。从而形成Sprint Backlog，对于Sprint Backlog的规划是Scrum迭代中计划会议的一个重要的工具。
在PingCode迭代中，有独立的规划功能，可以非常方便的从需求、缺陷列表中挑选合适的工作项，进行迭代规划。
在Jira中的Sprint Backlog规划与Product Backlog管理在同一个页面，在做迭代规划时不够直观。
2.4 任务板/故事墙支持
任务板是以开发者的视角查看当前迭代中待办事项的进展情况，而故事墙则以产品经理的视觉查看当前迭代中用户故事的进展情况，任务板/故事墙都是Scrum开发中的重要工具，在每日立会中可以方便的通过任务板/故事墙回顾前一天的工作完成情况。
PingCode中原生支持任务板和故事墙，可以方便团队成员通过不同维度关注迭代进展。
在Jira中迭代的默认展示是看板，并不会明确区分任务板和故事墙，所有的用户故事和开发任务在同一个看板中展现，不利于团队成员从不同视角查看迭代进展。
2.5 迭代回顾板
迭代结束时召开评审会议，在评审会议上每个人基于产品向团度其他成员展示自己在这个迭代中所完成的成果，团队成员可以针对完成的事项提一些建议和反馈。
在评审会议结束后，团队成员会一起召开迭代回顾会，迭代回顾会是 Scrum 实践中的最后一环，也是最重要的一环，迭代回顾会将整个迭代形成了闭环，并且基于会议上的成员之间的反馈可以帮助团队持续改进。
在 PingCode 中则在迭代管理中开发了迭代回顾板，通过做的好的/需要改进/改进计划三栏清晰的帮助团队成员更好的记录和追踪迭代回顾内容；
而在 Jira 中迭代回顾会议只能通过 Confluence 中的Wiki页面来记录，这样的方式导致迭代回顾会的记录与实际工作中的迭代产生脱节，不利于回溯。
2.6 版本管理
在敏捷开发 Scrum 实践中，大部分团队都会忽视版本管理，迭代是针对 Scrum 团队的活动行为，而版本管理是针对产品的，它定义的是一个批量的概念，用于版本进度管理和交付风险管理，明确在一个版本中的最终交付物。
严格意义上说，迭代管理和版本管理是敏捷开发中的两个并行的管理单元，因为在 Scrum 标准中并不强调版本管理的概念，导致很多团队不重视版本管理，最终导致转型敏捷的失败。
现实敏捷开发中，迭代管理和版本管理的关系比较复杂，颇有剪不断理还乱的趋势：
- 1个迭代对应1个版本：理想状态下单一的小型研发团队使用 Scrum，单个团队负责单个系统，一个迭代发布一个版本。
- 1个迭代对应N个版本：同时负责多个系统的小团队，如负责底层基础框架建设，在一个迭代发布多个版本是常见的情况。
- N个迭代对应N个版本：在稍微大型一点的研发组织中，多个团队同时负责多个系统，并行进行多个迭代，需要发布多个版本。
正因为迭代管理和版本管理之间这种复杂的对应关系，在 PingCode 中迭代和版本之间是可以实现N:N的映射关系，即把这种关联权交到研发团队的手上，由开发团队和产品团队自行决定到底如何映射。
另外 PingCode 版本中还允许开发团队自由灵活的定义版本发布的阶段或者发布的环境，如Alpha、Beta、RC、Live等。
Jira 中则直接放弃了解决迭代和版本管理之间的映射关系，只提供一个 Release 的概念供研发和产品团队使用，让工作项和版本之间建立联系，并不直接提供迭代和版本之间建立连接，对于版本的阶段追踪只有 Realeased 和 Unreleased 两种。
2.7 Scrum 支持汇总
在下表中我们对 PingCode 和 Jira 在敏捷开发 Scrum 上的支持，做一个简单的汇总：
3. Kanban 支持对比
Kanban 方法作为另一种敏捷开发实践，一个团队采用Kanban方法来管理是否能够成功，取决于使用Kanban后能否为你的团队带来以下几点改进：
- 帮助团队可视化整个链条的价值流动
- 帮助团队识别价值流动中的风险点
- 帮助团队度量价值流动中的各种浪费，并加以消除
这就要求团队在采用的开发工具上是否具备这些能力，能够帮助团队达到上述目的。
下面我们对PingCode和Jira在看板的支持能力上加以对比：
3.1 可视化看板
看板是一个具备约束条件，使用拉动方式来改变工作任务状态的流程可视化系统，选择一个功能完备的可视化看板系统，能让团队在推行Kanban 方法作为敏捷开发实践时，起到事半功倍的效果。
PingCode中的看板，支持根据团队业务需要在看板上显示不同的工作项类型，同时可以自定义看板栏，在工作项状态和看板栏之间配置对应关系，同时可以定义某个看板栏拆分为Doing/Done两个子栏，在同一个项目中可以同时创建多个看板，便于根据业务场景的不同，或者团队角色的不同定义多个看板，并针对每个看板的需要进行个性化的配置。
Jira 中的看板也是支持定义看板栏，但无法定义栏和状态之间的对应关系，默认每个工作项状态都有一个看板栏与之对应，同时每个看板栏无法再拆分为Doing/Done子栏。每个项目中只支持默认提供的一个看板，无法根据业务场景不同，定义多个不同的看板。
3.2 WIP Limit支持
在敏捷开发中，WIP限制决定了每种情况下的工作流中可以存续的最大工作量。限制进行中的工作数量可以更容易辨识团队工作流中的无效工作。在情况变得更糟前，一个团队在持续交付通道中的瓶颈是非常容易辨别的。
WIP Limit 旨在让团队专注于在开始新工作之前完成项目，虽然一开始具有反直观性，但许多团队发现 WIP Limit 可以极大的帮助他们提高工作效率并提高软件质量。
PingCode和Jira中都支持对于每个栏定义WIP Limit，当超过最大限制时看板栏的背景色将会高亮显示，WIP Limit 对栏中允许的工作项数量设置软约束，实际上并不会阻止将更多工作项移动到栏中并超出限制。
下图是PingCode中的WIP Limit显示：
下图是Jira中的WIP Limit显示：
3.3 多泳道支持
看板可以帮助天对在工作流从定义移动到完成时可视化工作流，而泳道还可以可视化支持不同服务级别类的工作项状态，如可以创建一个泳道来表示支持跟踪需求的其他任何维度， 例如可以创建三个泳道（"加速"、"标准"和"Parked"）来跟踪当前阻止的高优先级工作项、标准工作项和一般工作项。
在PingCode中支持团队根据自己的实际业务场景需要，自定义不同的泳道，泳道的命名和用途完全由开发团队自行决定，可以更好的帮助团队实践Kanban方法，在设置泳道后，可以将工作项拖动到泳道中，还可以在泳道中重新排序。
Jira 中并不支持团队自定义泳道，只可以通过系统提供的两种方式划分泳道：即通过工作项负责人和工作项类型进行分泳道展示。这样的泳道本质上只是工作项的另一种分组展示形式，并不能为团队实践Kanban方法带来很大的帮助，团队无法根据自身的业务场景进行自定义泳道。
3.4 完成定义支持
完成定义可以使团队在从一个阶段到下一个阶段时更新工作项状态时，有助于团队成员就完成的含义达成一致的共识。 通过为每个看板列指定完成定义的条件，帮助团队明确完成的概念，完成定义有助于确定在将工作项移动到下游阶段之前要完成的基本任务。
此外还可以帮助团队实现核心看板原则之一： 使进程和策略明确。
PingCode 中原生支持对于看板列的完成定义：
在确定后完成的定义后，团队成员可以在看板中直观的看到完成定义：
Jira 看板中并不支持完成定义，团队成员只能通过其他手段就完成的定义进行共识。
3.5 流程自动化
在可视化看板中，流程自动化可以极大程度上减少团队成员手工操作的时间，根据确定好的业务规则进行一些自动化的工作。
PingCode 中对于可视化看板系统的流程自动化支持通过两个方面支持：
- 一是PingCode中有独立的流程自动化的产品Flow，通过在规则中配置相应的触发器、条件和动作，可以非常轻松的实现流程自动化；
- 二是采用看板中的轻量级触发器实现流程自动化。
PingCode 看板中内置的轻量级触发器：
Jira 中的流程自动化通过内置的Automation功能实现：
3.6 Kanban 支持汇总
在下表中我们对 PingCode 和 Jira 在敏捷开发 Kanban 上的支持，做一个简单的汇总：
4. 总结
我们从敏捷开发的Scrum和Kanban的功能支持完整性方面，分别对比了国产化研发管理工具PingCode和海外对标产品Jira，从功能支持的完整性方面看，PingCode支持的更加完善和标准化，不管你的团队是采用Scrum还是Kanban，都可以使用PingCode进行非常方便的管理。
最后简单说一下两款产品在非功能性方面的差异：
- 子产品之间的互通性：PingCode 中所有的子产品都是构建在统一的数据模型，最大程度上实现了各个子产品之间的数据互通与关联，与用户故事与测试用例之间连接，团队目标和具体工作项之间连接，Wiki页面和工作项之间连接。Jira各个产品之间更加独立，都是作为单独的产品使用，各产品之间的数据互通性并不好。
- 产品的易用性：PingCode 作为国产化的新一代智能化研发管理工具，从产品构建之初就十分重要产品的用户体验，整个PingCode的子产品矩阵都构建于统一的用户体验之上，符合国内研发团队的使用习惯。Jira 因为发展历史比较长，背负很大的历史包袱，再加上非常繁杂的配置工作，产品的易用性相对较差。
2、查看 PingCode 与Jira 价格对比
