软件研发过程中，项目管理工具应该如何选择？

本文作者：极狐GitLab 资深解决方案架构师 尹学峰

许多企业依旧在用老旧的方式，如Excel离线表格进行项目管理。表格无法简介的呈现出项目的任务分解、完成进度、任务类别等多种项目管理过程中必备的要求，更无法实现与企业员工的日常即时通信系统的打通。往往导致项目管理与项目实际情况相去甚远。

为此，诞生了许多专业的项目管理软件。不同行业类型、不同的技术水平适用于不同的项目管理软件。

不同行业的倾向性

通用型传统行业

建议使用Jira、Ones、PingCode、禅道、Redmine、TAPD、Polarion等工具。其中Jira是目前较为主流的项目管理工具，用户基础众多，遗憾的是，Jira目前在国内没有技术支持团队，选用Jira需要承担较大的运维风险。而后者皆为国产的商业化项目管理软件，可以很好的替代Jira。这几款工具的典型视图如下：

图示：Jira典型视图

图示：Ones典型视图

图示：PingCode典型视图

图示：禅道典型视图

图示：TAPD典型视图

通用型高新技术行业

如果企业内项目管理人员大部分具有开发背景，且项目分解后的工作内容主要为由程序员进行代码编写工作完成的话，那么建议使用极狐GitLab进行项目管理。项目管理与代码开发在同一个平台完成，进而可以直观、零延迟地反应项目真实进度。下面对如何使用极狐GitLab进行项目管理加以阐述：

极狐GitLab支持敏捷开发管理体系，它用群组、子群组和项目来分别对应项目、子项目和代码仓，通过epic、子 epic 和 issue 来对应原始需求的任务、子任务和具体开发工作，这是项目管理的第一步。

图示：极狐GitLab的敏捷开发管理体系

产品经理创建原始需求后，和研发人员一起细化需求，并基于 invest 原则拆分需求。首先明确所有需求，撰写具体的 user story。(注：参考epic实例 Browser-based scanner for DAST )

图示：史诗Epic 原始需求拆分与规划

撰写完成后，如果大家有其他意见，可以以评论的方式写在该 issue 下，然后进行讨论，直到需求明确。极狐GitLab 以 issue 驱动，即无论是开发的任务、开发的需求还是 bug 缺陷，一律都用 issue 进行管理。

图示：议题Issue 用户故事与人员指派

撰写完成后，如果大家有其他意见，可以以评论的方式写在该 issue 下，然后进行讨论，直到需求明确。极狐GitLab 以 issue 驱动，即无论是开发的任务、开发的需求还是 bug 缺陷，一律都用 issue 进行管理。

图示：议题Issue 用户故事与人员指派

随着组织发展，issue 会越来越多，极狐GitLab 以一种灵活的自定义方式去打上不同的 Label，来区分不同 issue。Lable 是多级式的，第一级是一个 type，它决定了该 issue 是一个 bug、功能还是 QA 等。当打上第一级 Label 后，还需要打上第二级甚至第三级，比如说这个 bug 是性能问题、安全问题，还是来自一个手机端等等，可以自由精准地定义 issue。

图示：标记Label 区分议题类型

有了 Label 区分还不够，对研发人员来说，需要一个视角去看这些 issue。研发团队可以通过看板的方式进行 issue 管理，看板其实就是不同视角的视图。企业内，研发团队、测试团队还有产品团队都应该有属于自己的看板。产品团队关心的是任务的分配，所以有一张以研发工程师为视角的看板，比如张三在做需求A，李四在做需求B，这些都有一张看板；此外还有一张工作流看板，展示需求进行到什么阶段。对于测试人员来说，只需要看到相关 bug，不需要管在做什么，当然也可能会看一下看板，可以根据不同团队的职责进行划分。

图示：看板Board 自定义议题视图

如果用户不清楚 issue 的提交方式，会导致 issue 管理困难。例如：

• 当用户提交 issue 后，没有分配人员来跟进，那它就被搁置了；
• 或者用户不清楚该打上什么样的标记，是 bug 还是功能，导致 issue 分类混乱。

使用triage 机器人可以轻松解决这些问题。当用户提交了一个 issue 后，这个行为被机器人捕获到，它会立即在这个 issue 下添加一条评论，并且发邮件告知创建人应该打上 type。当用户打上 type 后，机器人又会随机从测试人员中选择一位，把他加到这个 issue 的指派人里，跟进这个 issue。通过这种方式可以很好地把 issue 管理起来。

图示：机器人Triage 自动处理Issue/MR

在项目之初和完成之后，可以使用里程碑来对项目进行规划和回顾。以下图极狐GitLab 15.1 的燃尽图为例：

图示：里程碑Milestone 迭代规划与回顾

不过，这个燃尽图并不是理想的燃尽图，因为它并不贴合参考线。在整个迭代周期的第一周，研发人员开始处理需求的时候，会发现有些需求描述得不是很清楚，导致评估内容增加，或者说有一些新的需求会引进来，所以这个曲线在第一周的时候甚至有点上扬。前两周集中进行开发，这时并没有开始大规模测试，所以曲线比较平缓。两周后，主要功能都完成测试，开始介入大规模测试，这时又会发现一些 bug，所以曲线又有一些向上的波动。两、三周之后，这个曲线开始急剧下降。

汽车行业

当然，如果是汽车行业关注V模型，可以考虑MappingSpace这样的行业化工具，其针对汽车行业独创性的开发了很多行业化的工具，方便企业以更优雅的方式工作同时，也可以更方便的通过特定的行业认证。

图示：MappingSpace对V模型的支持示意

更多请阅读MappingSpace官方文档。

图示：MappingSpace对V模型的支持实际效果

总结

项目管理工具的使用并无绝对的排他性，在某些场景下搭配使用可以起到更好的效果。比如极狐GitLab的项目管理工具不能够满足一些特定的需求时，或者当参与项目管理的人员种非技术人员和程序员人数占比旗鼓相当时，此时面临的选择会有多种：

• ❌ 迁就非技术人员。仅仅使用与代码管理孤立的项目管理工具(注：下图中蓝色部分)，会导致项目管理和代码管理的严重割裂，即，项目管理视图下无法直接提现代码开发的工作进度。
• ❌ 迁就程序员。仅仅使用极狐GitLab作为项目管理工具(注：下图中橙色部分)，非技术人员使用门槛相对较高，甚至产生排斥心理。
• ✅ 各取所长，互补共生。把项目管理中的不涉及代码开发工作的宏观需求放在独立的项目管理工具中，而与代码开发强相关的技术需求，则由极狐GitLab管理。

图示：典型的代码强相关开发过程记录

非技术人员无需知道技术实现细节，一般程序员也无需了解宏观的非技术内容。二者之间建立沟通的桥梁则由技术主管负责：

• 根据橙色完成状态及时更新蓝色状态。
• 根绝蓝色新需求，分解并创建技术实现。

图示：项目管理工具的互补共生

当然，第三方项目管理工具如Jira也可以与极狐GitLab集成。集成完成后，只要Commit Message或者MR Description中包含对应的Jira Issue ID，下图所示即为MKP-2，则会自动在Jira侧建立超链接。从而实现需求与开发过程的之间的映射。

图示：极狐GitLab与Jira集成效果