PingCode是如何做敏捷开发项目管理的？

《第十五次敏捷状态报告》显示：自疫情发生以来，采用敏捷的软件开发团队有显著增长，从2020年的37%增加到了2021年的84%。除此以外，从敏捷状态调查的早期开始，敏捷管理工具支持一直是决定敏捷成功的关键因素。下面我们就来介绍敏捷开发工具 PingCode 是如何管理敏捷的。

1. Scrum 简介

Scrum一个是用于开发和维护复杂产品的框架，特别是对于那些有着清晰 Roadmap 的特性开发团队，以便于按照固定的节奏提交价值增量，Scrum更加有完整的套路。

完整的Scrum框架包括：3个角色、3个工件、5个活动和5个价值观：

3个角色：Scrum Master、Product Owner、Team
3个工件：Product Backlog、Sprint Backblog、Increment
5个活动：Sprint、Sprint planning meeting、Daily standup meeting、Sprint review、Retrospective meeting
5个价值观：专注、勇气、公开、承诺、尊重

本文将通过实际测评体验研发管理榜评分较高的敏捷项目管理工具 PingCode 对 Scrum 框架的支持，以及项目管理全过程。（官网地址）

2. 敏捷开发项目实施的全流程

为了让大家更好的理解，我们将按照一个标准Scrum流程为大家介绍说明：

2.1 产品目标（愿景）管理

该环节痛点：很多研发团队成员只知道低头做事，完全不知道自己要打造什么样的产品，整个团队无法形成合力；

一个新项目往往是由愿景开始，愿景也可以认为是目标。

虽然敏捷开发凭借其在产品交付速度、质量、风控等方面的显著优势，逐渐在软件开发模式中占据主流，但大量问题仍然阻碍着企业的敏捷实践。其中，研发团队及其所在公司过于看重技术和流程，未能建立“上下同欲”的目标感，就是研发团队经常面临的问题之一。

在 PingCode 有一款专门为目标管理服务的子产品（Goals），它能够帮助项目团队进行目标管理，具体介绍如下：

建立上下同欲的目标感：基于公开透明、层层对齐的团队目标和个人目标，每个成员都有机会融入进企业的整体战略中，提升成员的内驱力；
建立可视化的目标管理过程并与研发工作数据连接：Goals 不仅可实时查看目标进度，目标还支持添加关联多个项目的工作项，并查看项目研发进度，从而定位给目标进度带来风险的具体项目；

目标管理同样是很大的话题，详细介绍就不在这里展开。

2.2 需求代办列表管理

该环节痛点：很多团队经常面临需求描述、需求优先级及排期问题；

在产品愿景确定之后，团队将进行市场调研等活动，并根据愿景、需求调研逐步构建需求代办列表——需求池管理；

在需求收集和需求管理的过程中，产研团队经常会遭遇两类问题：

需求描述的问题：需求信息不清晰、不完整；
需求的优先级及排期问题：什么样的功能能对用户产生最大的价值，这是需求管理中最重要的问题；

而以上问题你都能在 PingCode 找到比较好的解决方案：

获取清晰完整的需求信息，还原用户场景：为了帮助产研团队更好的用户洞察，PingCode 为用户提供了统一的需求、缺陷和建议反馈通道，其中就包括Web Portal、小程序、邮件、Webhook等渠道。产研团队可以根据需求自定义工单页面，以及与需求提交人直接沟通，尽可能的完善需求信息。在需求收集后，团队可以按照史诗/特性/用户故事分级管理需求。
基于数据洞察实现科学的需求优先级评审排期：PingCode 能够帮助团队整合工作量、价值、投票数、信心指数、影响程度，以及其他客户自定义的维度等信息。在评审过程中，团队将综合各维度信息确定每个需求的权重分数，需求经过评审之后通过计算的权重分数确定需求排期，以实现科学的优先级管理。

2.3 产品路线规划

过去产品总监没有固定的工具进行产品规划，或者使用Excel，细化调整费时费力，且与研发其他环节的工具割裂；

根据产品代办列表和产品部门的细化，产品愿景的实现路径慢慢清晰起来，并因此形成较为清晰的产品路线图规划。

产品路线图是产品需求在时间轴上的总体视图，它是产品需求与其完成时间的概览，可以使用产品路线图来对需求进行分类、排定优先级，然后确定发布时间表。产品路线图宏观的展示了产品的发展方向以及开发团队何时实现目标。

有效的路线图不仅是一个强调产品发布和功能的时间表：它是一个动态的文档，产品负责人会在项目进行过程中根据实际情况不断更新，所以在创建产品路线图的初期，对需求、工作量、优先级、完成时间的估算不要求也无法很精确，这些内容都是随着项目进行不断细化调整的。

而在过去很多团队都没有专业的工具进行产品规划，或者使用Excel，无论是细化调整还是内部外部的共享都费时费力，且与研发其他环节的工具割裂；

PingCode Ship 是一款专门为产品管理而打造的子产品，使用它能够有效避免以上的问题，比如能够根据你需求的评审排期结果自动生成产品路线图，并选择性同步给需求提出方以及内部团队，反馈需求进度。

除此以外，也不会像Excel那样存在多个版本的问题，而且PingCode 8 个子产品、研发管理各环节都是相互打通。

2.4 迭代计划

过去很多敏捷团队可能都面临着开发计划频繁变动，经常有临时任务插队，团队成员的工作状态被频繁打破等问题；

根据路线图，产研团队将需要规划项目/产品版本及发布范围。

然而在很多敏捷团队，可能都遭遇过迭代计划频繁变动，经常有临时任务插队，团队成员的工作状态被频繁打破等问题；

从实践角度来说，解决这些问题需要团队在迭代前有着清晰的规划，并确定迭代时间和目标，将需求拆解的足够细，与业务方达成协议，在迭代后根据准确的度量来发现问题持续改进；

而从工具的角度来看，PingCode Project 则更有助于以上实践方法的落地，比如：

在迭代开始前，团队可以将已梳理完成且优先级高的用户故事规划到迭代看板内，并规划出项目/产品版本及发布范围，让发布更有计划；

在迭代会议，则能够帮助产研团队更好的确定迭代时间和目标，细化用户故事为更小的开发任务，提供敏捷估算器辅助估算故事点，规划形成Sprint Backlog，填写预估工时。（燃尽图我们将在下面讲到）

2.5 开始迭代

过去产研团队在各个开发环节的工具中频繁切换，且低价值、重复性、手动性任务团队浪费较多时间；

在开始迭代后，如何解决各环节工具中频繁切换，让团队有更多的时间专注在有价值的任务成为很多团队提升效能不可回避的问题。

开发关联：PingCode 除本身覆盖项目管理全生命周期的能力外，还通过应用市场与其他工具集成，所以迭代过程中的代码、持续集成、测试用例、缺陷、文档等，都可关联对应需求，信息在需求页面均可统一获取；

自动化能力：如果迭代过程中，某个需求下的子任务都完成了，PingCode Flow 将自动改变该需求的状态，类似的场景还有很多，就比如自动创建分支、自动配置页面权限等等；PingCode 提供了非常多的自动化规则模板，同时用户也可以自行创建。

工时统计：除此以外，PingCode 也支持团队在迭代过程中填写、统计预估工时、实际工时，形成项目/团队工时统计视图；

2.6 每日站会

该环节痛点：在以往，敏捷团队可能更多是使用Excel定时统计需求进度，费时费力还容易出错。

每日站会核心是围绕以下三个问题展开：

昨天我做了什么事情帮助开发团队达成Sprint目标？
今天我要做什么帮助开发团队达成Sprint目标？
是否有任何障碍在阻碍我或开发团队达成Sprint目标？

但每日站会不是任务指派的会议，也不是报告的会议，而是为了沟通状态、减少其他会议、发现开发过程中需要移除的障碍、促进快速地做决策、提高开发团队的持续改、优化开发团队达成Sprint目标的可能性。

以往这一环节，团队可能更多是使用 Excel 定时统计需求进度，但这种方式费时费力还容易出错。

在 PingCode ，团队可以通过任务板/故事板，查看每个成员正在处理的任务，确认迭代范围变化情况，快速掌握团队进展。

除此以外，团队还可以通过迭代概览、迭代燃气图等统计报表，查看当前迭代进度，识别迭代风险。

2.7 迭代评审

迭代评审会议在 Sprint 快结束时举行，这个事件是让开发团队展示他们在Sprint中取得的成就，根据DoD“完成的定义”和验收标准，验证增量。

所以，当任务负责人演示工作成果时，可能会提出一些缺陷，而这个时候团队可以直接在用户故事上直接创建缺陷/Bug，并确定Bug紧急度。

2.8 迭代回顾

该环节痛点：以往可能缺乏可靠的研发数据作为持续改进的基础；

回顾会议专注于团队和团队的流程，它一般围绕以下三个问题展开：

我们在上一个Sprint中哪里做得好？
上一个Sprint我们哪里做得不够好？
我们的改进计划是什么？

使用 PingCode 后，产研团队完全可以不凭借经验感觉和有限的数据分析复盘，因为 PingCode 不仅每个Scrum 项目内有针对该项目的报表。

还具备专门为效能度量而打造的子产品Insight，提供自动采集效能数据能力和体系化效能指标体系，能够帮助敏捷团队基于准确数据进行持续改进。

除此以外，在迭代回顾会召开过程中，团队还可以借助 PingCode 将“当前迭代做的好、不好及需要改进的计划”，记录进迭代回顾板，做到持续跟进。

至此，一个完整的 Scrum 迭代过程就基本结束。

通过对敏捷框架的逐一盘点，敏捷项目管理各环节痛点的对应，大家也能基本了解PingCode 这款工具对敏捷开发项目管理的支持程度，是否能满足自己需求。当然这些也仅是我们团队的测评，是否满足其他团队，还需大家亲自体验。