我们是如何使用 PingCode Flow 的?

作者： 徐子岩 Shaun Xu

研发自动化产品 PingCode Flow 已经上线将近半年的时间。在这期间，我们很高兴的看到越来越多的研发团队试用、接受并喜欢上这款产品。从目前的后台监控数据看，我们的客户在 PingCode Flow 中共创建了将近 2500 条规则，平均每天执行规则近 3500 次。如果我们做一个简单的计算，假设自动执行的一条规则相当于原先 30 秒的手工操作，那么这就意味着，每天 PingCode Flow 帮客户节省了将近 30 个小时的工作量。

随着对 PingCode Flow 的认可度逐步提高，我们在和客户沟通的时候也发现，大家对于如何在自己的团队中创建合适的规则存在着一些困难。虽然 PingCode Flow 内置了将近 30 个模板，涵盖了从软件开发、项目管理，到 DevOps、团队管理等诸多领域，但是一个真实的研发团队如何使用 PingCode Flow，哪些规则适合，以及如何调整规则的具体步骤，对于客户来说还是有一些难度。

因此，我们希望通过这篇文章，分享一下我们 PingCode 研发团队自己在使用哪些规则，为什么使用，以及带来的效果和收益。希望能够给读者提供一些思路和借鉴。

接下来，我将会分为研发管理、高效沟通、DevOps 和人员管理四个方面，介绍我们正在使用的部分规则。

研发管理

研发管理包含了研发团队在日常开发过程中的一些流程和要求。之前为了规范团队，我们需要制定详细的开发手册，为新加入的员工进行培训；在日常工作中，研发组长还要随时检查并提醒团队成员遵守。除此之外，在规范和流程有更新的时候，还需要同步到手册中，培训并时刻提醒成员新的要求。所有的这些工作都极大地占用了一线管理者和团队成员的时间和精力。接下来，我将介绍几个与研发管理相关的规则。

无人负责的工作项变为「进行中」后自动设置负责人

我们希望在研发过程中，每一项工作都有一个明确的负责人。这样不仅能够明确责任，同时也能客观的展示出目前工作的进展状况，成员的工作负荷以及团队的人员配置是否合理。但是，无论是由于成员的粗心，还是因为项目紧任务重，经常会出现工作项被设置为「进行中」了，但是并没有同时领取负责人。为此，我们创建了这个规则。

首先，规则在工作项状态被设置为「进行中」后触发。

随后，判断当前工作项的负责人是不是处在未设置状态。

最后，将工作项的负责人设置为规则的触发者，也就是最开始变更了工作项状态的那个成员。

通过如此简单的三个步骤，我们就完美的解决了「团队成员忘记设置负责人」这个问题。无需员工手册，也无需培训。

自动设置工作项所属迭代

与上一个场景类似，在敏捷开发的过程中，我们不可避免的在进行中的迭代内临时加入一些新的用户故事或缺陷。这些工作项可能是临时创建的，或者从需求池调整来的。那么在团队成员开始工作的时候，需要确保它的迭代属性被设置到当前迭代中，否则就会导致 Scrum Master 无法准确了解当前迭代的工作内容，在 Sprint Review 会议中很有可能漏掉这个工作。

因此我们创建了这个规则，在工作项状态被设置为「进行中」后，检查其迭代属性是否为空。

如果为空的话，就将这个工作项加入到所属项目的当前迭代中。

高效沟通

在考察研发团队工作效率的时候，我们往往将关注点都放在了研发流程和规范上。诚然，流程和规范是提高研发效能的主要途径，但是团队内以及团队间的沟通协作是否高效，也大大影响了研发人员的工作效率。而且，沟通的成本不仅仅体现在沟通所需的时间本身，它还包含了由于沟通不及时不正确导致的等待、错误和返工问题。而这些时间上的耗损往往没有得到足够的重视。

PingCode 研发团队目前 8 个开发小组，组内的沟通自不必说，各个小组之间的沟通，研发团队与运维团队的沟通，以及产研与营销的线的沟通都非常的频繁。如何能够及时、快速且正确的同步工作进度、结果，这不仅影响产研的效率，也影响着客户满意度和公司营收。

下面的几个规则就是结合我们自身的需求，重点解决团队内以及跨团队的沟通问题。

通知被阻塞的工作项

这个规则应该是自上线以来，团队成员反馈最为有用的规则之一了。它要解决的场景非常简单。研发过程中，不可避免的有任务间的历来关系，也就是说，某些任务必须等待其它任务的完成后才能开始。具体的，可以通过 PingCode Agile 中对于工作项的「阻塞」和「被阻塞」关联关系来展。

当一个工作项状态发生变化，特别是已经完成后，需要通知到被阻塞的工作项负责人，让他们尽快开始后续的任务。之前我们团队的要求是，当团队成员完成一个工作项后，要检查一下有没有被阻塞的其它工作项。如果有的话，需要通知（口头或者发评论）到对应的负责人。但是在大家紧张工作的时候，总会无意间忘记通知，或者漏掉了某个负责人，导致开发时间无故被浪费。开发组长和 Scrum Master 还需要定期检查跟进状态，非常费时费力。

针对这个问题，我们创建了如下的一条规则。当工作项状态变化后，PingCode Flow 会自动检查所有被其阻塞的工作项。

然后，向这些工作项发送一条评论，告知负责人和关注者，阻塞的工作项状态已经发生变化了。

启用了这条规则后，团队成员无需手动提醒后续任务的负责人，团队管理者也不用花时间每天检查相关的进度。团队的协作和沟通都会自动的、及时的，并且准确无误的执行。

自动为客户提交的缺陷和需求设置产品负责人关注

在 PingCode 研发团队，我们非常重视最终客户和用户的使用反馈，包括缺陷、产品建议和产品需求。一般的，客户的声音会优先传递给我们的客户成功部门，再由客户成功部门加工整理，在名为「PingCode Bugs」的项目里创建工作项进行跟踪。

之前，客户成功同事创建工作项时，需要根据对应的子产品，设置上对应的产品负责人为关注者。但是有的时候会忘记设置，有的时候会设置到错误的产品经理。这就造成了客户的诉求无法及时反馈，影响我们最终的客户满意度。而接下来介绍的这个规则，就是为了解决此问题而创建的。

首先，当 「PingCode Bugs 项目」中有缺陷或用户故事被创建时，会触发这个规则。

然后，我们针对这个工作项标题进行判断。当包含某个子产品名字的时候，就设置这个子产品的产品负责人为关注者。比如当标题包含「Agile」，就会加入「PingCode Agile」的产品负责人；包含「Wiki」就加入「PingCode Wiki」的产品负责人。以此类推。

DevOps

研发团队在流程化之外，还有大量的工程化工作，也就是我们常说的 DevOps 相关的工作。依赖于 PingCode Flow 对外部系统的支持，我们团队将敏捷开发与代码托管、流水线结合在一起，实现了研发自动化工作流。这里限于篇幅的关系，我们仅以 Code Review 和持续构建为例，简单介绍一下 PingCode Flow 如何支持 DevOps。

基于 GitHub Pull Request 的 Code Review

Code Review 是每一个追求质量的研发团队必不可少的工作。但是，如何高效的执行是每个团队面临的一大挑战。一方面，大家都认同 Code Review 的重要性，另一方面，又担心 Code Review 会不会给开发工作增添大量的时间，又或让 Code Review 流于形式。我们 PingCode 研发线在 2019 年就已经实现了全员的强制 Code Review 制度，任何产品代码都必须经过至少一名组员评审才能被合并到主开发分支。

但是，在具体实践过程中，流程确实很繁琐。

1. 工程师在 PingCode Agile 上领取某个用户故事，设置负责人。

2. 在 GitHub 上面按照工作项编号创建对应的开发分支。

3. 返回 PingCode Agile，设置工作项状态为「进行中」，开发、测试、提交代码。

4. 在 GitHub 上基于分支创建 Pull Request。

5. 在 Worktile 的对应群组中提醒相关人员进行 Pull Request Review。

6. 评审人员收到 Worktile 消息后，进入 GitHub 进行评审。

7. 评审完毕后，评审人在 Worktile 上通知工作项负责人评审通过，可以合并。

8. 负责人收到 Worktile 消息后，进入 GitHub 合并分支。

9. 负责人返回 PingCode Agile，将工作项设置为「已完成」。

可以看到，为了完成一个 Code Review 流程，工程师和评审人需要频繁的在代码托管平台（GitHub）、敏捷工具（PingCode）和 IM 工具（Worktile）上切换，效率极其低下。正因为如此，我们分析了整个流程后，找到了一些可以自动化执行的点，创建了几个规则配合使用，最终简化流程。

创建 GitHub Branch 后自动开始工作项

首先我们解决的是在开始工作时，GitHub Branch 和 PingCode Agile 工作项的联动问题。工程师在 GitHub 上创建的分支后，PingCode Flow 会自动提取分支名称中的编号信息，找到对应的工作项。

然后，为工作项添加一条评论，提示对应的分支已经创建完毕。

同时，将工作项的状态从「打开」变为「进行中」。

创建 GitHub Pull Request 后通知评审人

接下来，我们着手改进 Code Review 中负责人和评审人的沟通问题。我们希望在 GitHub Pull Request 被创建后，能够自动通知对应的评审人。首先，在 GitHub Pull Request 被创建后触发一条规则。

接下来，从 GitHub Pull Request 的标题和源分支名中提取对应的工作项。

最后，通过 Pull Request 里面标题提取需要的评审人，发送评论，提醒他们有一个 Code Review 需要评审。

这样，当有 Pull Request 被创建时，评审人就会收到相应的提醒，点击链接就可以直接跳转的 GitHub Pull Request 页面进行评审工作了。

自动发送 GitHub Pull Request Review 状态变更信息

在上一步中，评审人看到 Code Review 通知后，点击链接完成评审。当 Pull Request Review 的状态由 Pending 变为 Approved、或者 Reject 后，通过这条规则就可以自动提醒 Pull Request 的作者（也就是对应工作项的负责人），及时的修改 Code Review 发现的问题，或者合并已经评审通过的代码。

收到的通知消息是这样的。

合并 GitHub Pull Request 后自动完成工作项

最后，当负责人会 GitHub 上合并当前 Pull Request 时，我们希望对应的工作项能够自动设置为「已完成」。当 GitHub Pull Request 的状态变为「Merged」后，会触发这条规则。

其次，与之前的规则类似，通过 Pull Request 名或者源分支名提取到对应的工作项。

最后，在给工作项发送评论的同时，如果将状态由「Code Review」设置为「已完成」。

这样，我们通过上述四个规则，简化了研发团队在 Code Review 过程中的操作流程，使沟通更加的顺畅，同时让工作项的状态能够及时反映真实的开发状态。

相比于之前，简化后的流程是这样的。

1. 工程师在 PingCode Agile 上领取某个用户故事，设置负责人。

2. 在 GitHub 上面按照工作项编号创建对应的开发分支，开发、测试、提交代码。PingCode Flow 自动设置工作项为「进行中」，

3. 在 GitHub 上基于分支创建 Pull Request。PingCode Flow 自动提醒评审人。

4. 评审人员收到提醒后，进入 GitHub 进行评审。评审结果会自动通知工作项负责人。

5. 负责人收到评审结果的通知后，进入 GitHub 合并分支。PingCode Flow 自动设置工作项为「已完成」。

通知项目成员 Jenkins 的构建结果

PingCode 研发线使用 Jenkins 作为持续集成和持续部署工具，利用 Jenkins 上定义的上百条流水线，我们实现了从代码提交到单元测试、集成测试、灰度发布以及 Alpha、Beta、RC、Product 四个环境的自动部署能力。

为了实现 DevOps 第二工作法，我们需要将持续集成和持续部署的结果实时的反馈给开发团队。这可以通过 PingCode Flow 中的 Jenkins 连接器去实现。

具体的，通过 Jenkins 连接器中的「变更 Jenkins 构建状态」触发器来获取 Jenkins Job 的构建结果。当一个 Job 状态发生变化了（无论是成功还是失败），就会触发这条规则。并且，运维组的同事会将此触发器的 Webhook 地址配置到对应的 Jenkins Job 上。

然后，针对 Jenkins 上配置的流水线，我们找到对应的 PingCode Agile 项目。以当前规则为例，运维组配置了 PingCode Flow CI 这条流水线，因此我们接下来直接获取 Flow 这个项目。

最后，将 Jenkins 构建结果通过 PingCode 通知发送给项目成员。

这样当流水线执行完毕后，项目成员都会收到如下的消息。

这样，当流水线执行出现异常，或者构建失败时，所有成员都会第一时间收到通知并进行处理。最大限度了保证了 DevOps 工作流的顺畅。

人员管理

随着研发团队的扩大，一个项目组在平时工作中需要访问的资源也会变多。以我们 PingCode 研发线为例，项目成员需要访问对应子产品的需求、工作项和迭代信息，也就是 PingCode Agile 中的项目；子产品的文档，也就是 PingCode Wiki 的知识库。整个研发线成员还需要能够访问一些公共的项目和知识库，譬如用于收集缺陷和客户需求的项目，研发管理相关的知识库等。在别的团队，可能研发和测试工程师还要能够访问对应的测试库。

每当团队迎来以为新成员的时候，团队的负责人需要将其加入到上述的项目、测试库、知识库中。虽然每次的操作时间可能不会太久，但是却是一个繁琐的工作，而且一旦有错漏，会造成新成员无法在第一时间获得信息，甚至对团队和组织的正规性产生怀疑。

我们 PingCode 研发线也受困于上述的问题很久。但是随着 PingCode Flow 的上线，终于可以使用一条规则来完成上面所有的操作。

新成员自动加入项目、知识库等

首先通过「成员加入用户组」这个触发器来启动规则。每当新成员加入我们研发部，HR 同事会设置其在 PingCode 中的用户组，就会触发这个规则。

随后我们通过多个分支，来分别处理成员被加入到不同用户组后，添加到不同项目和知识库的操作。首先是所有组员都会访问的资源，也就是当成员被加入到「研发组」这个大用户组后，会加入到研发线共有的项目和知识库。

然后我们针对不同的子产品组，创建不同的分支。判断成员所在的用户组，加入到对应的项目和知识库中。比如下面是 PingCode Flow 组和运维组新成员加入的时候。

以上就是我们 PingCode 研发团队自己在使用的部分自动化规则。除此之外，我们还有很多其它的规则来辅助日常的开发工作。

譬如

• 在工作项设置为「已完成」后通知设计师和产品经理进行验收。

• 运维组创建用户故事时自动设置关注人。

• 进行中的迭代内加入新的用户故事时通知 Scrum Master。

• 同步关联关系为「重复」的工作项状态。

• ……

其实这些规则并不是我们一次性设计并投入使用的。从 PingCode Flow 内测开始时的几条规则，随着团队成员的不断适应，以及我们逐步发掘可能的场景，才发展到目前将近 30 条规则。因此我们建议，研发自动化的引入一定要循序渐进，遵循

1. 发现问题

2. 定位原因

3. 设计规则

4. 小范围试验

5. 收集反馈

6. 调整规则

7. 大范围使用

这样的逻辑。让团队成员尽快感受到自动化的好处，逐步适应这样的规则，进而提出自己的想法和需求，不断迭代，最终提高工作效率，提升研发效能。