软件产品需求管理工具哪个好？国内知名产品管理工具使用体验分享

像 PingCode 这类的敏捷开发管理工具它可以让团队成员在一个平台上规划、跟踪、执行和评估项目的各个阶段，从而提高透明度、沟通和反馈；还可以支持 Scrum 的核心实践，如产品待办事项、冲刺计划、每日站会、冲刺回顾和冲刺回顾。通过使用敏捷开发管理工具，Scrum团队可以更好地遵循敏捷原则和价值观，实现持续改进和客户满意。

下面我们将详细介绍 PingCode 能够帮助大家解决 Scrum 管理中的哪些问题，如何操作等。

一、10步开启Scrum项目管理

PingCode 项目管理支持标准且完善的 Scrum 开发流程，帮助产研团队：

• 快速建立标准化、规范化研发管理工作流程，有节奏的持续交付价值
• 轻松规划和应对需求变化，提高项目可预测性，降低风险
• 提升项目信息透明度，跨团队协作更顺畅，过程统计和改进有据可依

现在，是时候为您的团队顺利落地Scrum敏捷开发。通过以下10步，快速落地Scrum项目类型为您的企业团队开启小步快跑，更快响应和交付价值。

第一步：掌握Scrum敏捷开发管理流程

您过去可能已了解过 Scrum 敏捷开发框架流程「3355」，即3个核心角色，3个工件，5个关键事件和5个价值观。

• 3个核心角色：产品负责人（Product Owner）、敏捷教练 (Scrum Master)、研发团队 (Scrum Team)
• 3个工件：产品待办事项 (Product Backlog)、Sprint 待办事项 (Sprint Backlog)、潜在可交付产品增量 (Increment)
• 5个关键事件：冲刺 (Sprint)、Sprint 规划会 (Sprint Planning Meeting)、每日站会 (Sprint Daily Standup)、Sprint 评审会 (Sprint Review)、迭代回顾会 (Sprint Retrospective）
• 5个价值观：开放、尊重、勇气、专注、承诺

如果您还想了解更多 Scrum 敏捷开发管理核心内容和方法，可以访问《敏捷开发指南》

第二步：创建您的Scrum项目

如果您有创建项目的权限，那么您可以创建一个Scrum项目类型并添加您的团队成员，未来Scrum团队将在这里持续跟进和改善他们的工作：

• 进入 PingCode，选择「项目管理」模块；
• 在主界面中，选择「+ 新建项目」；
• 填写项目名称、项目标识和项目描述，选择「Scrum」项目类型；
• 选择项目成员，将对应的成员添加至项目；
• 完成创建。

第三步：项目个性化配置

在正式进行项目管理之前，为您的项目进行个性化配置来帮助您更好的适配业务流程。PingCode 为您提供高度的自定义能力，包括自定义工作项的工作流、属性、提醒与通知，自定义项目的组件和项目属性等来配置适合您的工作流程。

1. 开启本地配置

在项目管理过程中，由于不同项目内容可能各不相同，工作项类型的配置需求也各不相同。通过「开启本地配置」，便于您根据项目的业务场景配置工作项类型，让工作项自定义配置更灵活。您「开启本地配置」后支持项目内工作项自定义配置，当前项目将不再受全局配置的变更影响。

2. 自定义工作流配置

Scrum 项目管理为项目提供史诗、特性、用户故事、任务和缺陷不同的工作项类型。您可以为每个工作项类型都可以配置独有的状态和流转关系，实现工作流的自定义配置。您选择需要配置的工作项，如「任务」类型工作项，选择工作流配置，系统为您提供的状态有打开、进行中、开发完成、测试阶段、已完成和关闭，您可以根据实际的状态流转情况来新增、修改、删除和排序工作项状态，并且通过勾选复选框的方式，对该工作项类型的状态流转进行配置。

3. 自定义工作项属性

您可以为每个项目自定义不同工作项属性，通过配置工作项的新建和显示视图，帮助您记录工作项的详细信息。您选择需要配置的工作项，如「任务」类型工作项，选择属性与视图配置，您可以在工作项详情视图和新建视图中添加/创建各个类型的属性，包括单行文本、多行文本、数字、日期、下拉单选、下拉多选、单个成员和多个成员。您也可以编辑、移动位置和删除已有的属性。

4. 自定义工作项提醒与通知

您可以为每个项目自定义工作项提醒与通知，通过设置工作项的提醒时间规则，自动发送消息提醒，如设置所有进行中的「任务」类型工作项在截止时间前一天发送通知提醒对应的负责人。

您也可以通过设置工作项发生操作时，自动发送消息通知，如所有「任务」类型工作项在被删除时发送通知给该工作项的创建人。

您也可以通过设置工作项属性发生变更时，自动发送消息通知，如所有「任务」类型工作项的预估工时发生变更时发送通知给该工作项的关注人。

5. 项目组件配置

在您创建的 Scrum 项目中，进入更多设置，选择项目组件，来配置适合您业务流程的组件，系统为您提供以下组件，如概览、规划、需求、缺陷、迭代、版本、测试、页面、报表等，您可以根据实际需要进行开启/关闭。

6. 自定义项目属性

您可以在项目属性设置中，自定义项目的扩展属性，帮助您来记录项目的详细信息并展示在项目概览中。您可以添加/创建各个类型的属性，包括单行文本、多行文本、数字、日期、下拉单选、下拉多选、单个成员和多个成员。您也可以编辑、移动位置和移除已有的属性。

7. 配置项目模版

根据您的实际业务流程，您可以通过配置通用 Scrum 项目的管理模版，当您有新的 Scrum 项目时就可以复制该模版直接应用，避免多次重复配置操作，并且也方便您建立统一的标准来管理 Scrum 项目。当您配置好一个 Scrum 项目作为模版时，选择「复制项目」，填写项目名称、项目标识和项目描述，选择项目选择成员，该模版下的所有配置及工作项内容都会复制到新创建的 Scrum 项目中。

第四步：管理您的项目成员和角色

现在是时候把您的项目团队成员加进来了。PingCode 项目管理提供项目成员、角色、团队的管理，并能够对不同角色设置不同的权限，保障项目信息流畅流转的同时保障您的数据安全。

1. 项目成员管理

若项目中有新成员加入，您可以在项目成员管理界面添加新成员，新加入的成员系统默认配置权限为「普通成员」，当然您也可以在管理后台「设置默认角色」，同时支持批量进行成员角色设置。

2. 项目角色管理

如您需要为当前项目添加更多角色，可在 PingCode 管理后台进行角色维护，如添加产品经理、UI设计师、开发工程师等。在完成角色设置之后，就可以进入项目管理后台「权限配置」进一步完成角色权限的配置，目前已支持91项项目管理权限。

 

3. 项目团队管理

项目团队是一组为一个共同目标而工作的个体集合，您可以在 PingCode 管理后台构建您不同项目的项目团队，您可以按照产品划分团队，也可以按照项目划分团队。一般来说，Scrum 项目团队包含产品负责人(Product Owner)、敏捷教练（Scrum Master）、开发团队（Dev Team）,他们每位都把自己的技能带到团队。

• 产品负责人(Product Owner)：主要负责构建正确的产品，确定 Scrum 团队交付什么并解释为什么做这些工作
• 敏捷教练（Scrum Master）：主要负责帮助产品负责人和开发团队中的每个人理解和拥抱Scrum的价值观、原则和实践；
• 开发团队（Dev Team）：负责以正确的方式构建产品，执行具体工作任务。

到这里，您的项目和相关项目团队已建立完成。下面我们学习如何在 PingCode 中建立Scrum实施全流程。

第五步：梳理您的产品待办列表（Product Backlog）

Product Backlog 是一份涵盖产品中已知所需每项内容的有序列表，它是产品需求变动的唯一来源。产品负责人负责管理Product Backlog的内容、可用性和排序。Product Backlog列出所有的特性、功能、需求、增强和缺陷等对未来要发布的产品进行的更新。下面我们来看如果梳理您的Product Backlog。

1. 路线图规划

在形成产品待办列表前，需要进行路线图规划，确保项目团队持续关注战略方向和目标。路线图规划的频率基于产品特征、产品规模和复杂度以及产品推向市场的频率来决定。市场变化较快、响应要求高的产品，可以按照月度进行规划，对于企业级大型产品或解决方案可以按照季度进行规划。

您可以在Scrum项目管理「规划」组件中，规划工作项的开始和截止时间、优先级以及不同工作项间的关联关系，并可以按照不同工作项层级可视化呈现规划视图，帮助您直观地看到任务的进展情况，了解到什么时间有什么任务需要去做。

2. 收集并创建需求

项目开始前，如果您已经基于「PingCode 产品管理」完成了需求的收集、管理、优先级评审和排期，且已经将需求分发至某Scrum项目，那么您就可以在「需求」组件直接查看和管理相关需求。如果您想要了解如何使用 PingCode 产品管理，详见「PingCode 产品管理开箱指南」。

如果您没有使用PingCode产品管理模块，那么可以直接在「需求」组件中直接创建需求。当您的需求大量涌入的时候，发现手动创建效率低下，PingCode 为您提供了Excel文件批量导入能力。

3. 需求层级（Epic-Feature-User Story）

产品经理可以按照史诗-特性-用户故事的层级来分级管理和规划您的 Product Backlog，并初步确定需求优先级及业务价值。

• Epic：史诗，表示比较大的特性，开发周期一般是1-3月，用于产品路线图的规划。
• Feature：特性，表示相对小一些的特性，开发周期一般是1-3周，用于产品版本的规划。
• User Story：用户故事，表示最小的用户场景，开发周期一般是1-3天，用于迭代规划。

4. 梳理Product Backlog优先级

如果您已经基于「PingCode 产品管理」完成了需求优先级评审和排期，且已经将需求分发至某Scrum项目，那么您就可以直接查看和调整工作项优先级。如果您想要了解如何使用 PingCode 产品管理，详见「PingCode 产品管理开箱指南」。

如果您没有使用PingCode产品管理模块，那么您可以结合企业优先级评估标准，确定Product Backlog中工作项的优先级。

第六步：版本规划

在 Scrum 实践中，大部分团队都会忽视版本管理，迭代是针对Scrum团队的活动行为，而版本管理是针对产品的，它定义的是一个批量的概念，用于版本进度管理和交付风险管理；您可以在Scrum项目中创建版本并把它与迭代「关联」，或者只是单纯的设置某个工作项（如用户故事/缺陷）属于某个版本。

现实敏捷开发中，迭代管理和版本管理的关系比较复杂，一般会有以下三种对应关系：

• 1个迭代对应1个版本：理想状态下单一的小型研发团队使用 Scrum，单个团队负责单个系统，一个迭代发布一个版本；
• 1个迭代对应N个版本：同时负责多个系统的小团队，如负责底层基础框架建设，在一个迭代发布多个版本是常见的情况；
• N个迭代对应N个版本：在稍微大型一点的研发组织中，多个团队同时负责多个系统，并行进行多个迭代，需要发布多个版本。

第七步：迭代计划会议

1. 创建迭代

当您梳理完 Product Bcaklog，真正的迭代计划即将开始。在 PingCode Scrum 项目中创建您的第一个「迭代」，「迭代」对应 Scrum 中的 Sprint 概念。

在创建迭代的时候，您需要完善迭代名称、迭代开始和结束时间，以及迭代需要完成的目标。

Tips：「迭代」的开始和结束日期应与团队的日程安排一致。例如：

• 在星期一开始迭代，然后在下周的星期五早上结束。
• 一周的中间开始和结束他们的迭代。

同时，您也可以将迭代按照不同分组或类别划分，以便更好地管理不同类型的迭代，比如将迭代划分为「正常迭代」、「临时迭代」。

 

2. 确定迭代周期

迭代目标明确后，您即将进入迭代冲刺。一般来说，「迭代周期」是1至4周，由项目团队共同决定迭代周期的长度。一旦确定了「迭代」节奏，团队就要按照该节奏进行操作。在整个迭代过程中，需要由Scrum Master 确保团队在无外界干扰的情况下全力以赴的冲刺。建议在整个项目期间保持稳定的迭代周期，这会让团队遵循稳定的开发节奏，也有利于准确预估项目完工所需时间。

PingCode 建议「迭代周期」从两周开始，迭代周期太短会导致开发的功能较少且频繁的提示用户更新体验也不太好，迭代周期太长，团队没办法得到定期的反馈，且用户提出的需求长时间得不到解决可能导致用户流失风险。

3. 迭代计划会

迭代计划会是敏捷开发需要进行的会议之一，目的是为了规划当前迭代周期需要完成的工作（范围），在每个迭代周期开始之前或开始第一天召开。参加Sprint计划会议的人员一般包含产品负责人，Scrum Master以及团队所有成员。

• 产品负责人讲解用户故事

在迭代计划会上，产品负责人根据已经梳理好的Product Backlog，向大家讲解整体需求、场景或产品目标，并逐条按照用户故事优先级进行讲解，并确定用户故事的验收标准。

• 团队一起评估故事点

在产品负责人讲解用户故事后，敏捷教练引导开发团队完成用户故事的故事点估算。如果您不确定如何估算故事点，PingCode为您提供「敏捷估算器」小程序，辅助团队进行故事点估算。同时，围绕如何实现迭代目标，开发团队可以将用户故事进一步拆解为更小的任务，当然，您也可以在开始迭代后再进行拆解。

Tips：

什么是「敏捷估算」？

传统软件团队以具体时间给出估算：天、周、月。然而，许多敏捷团队已经过渡到「故事点」。

「故事点』对工作的相对困难程度进行评级，通常采用类似斐波那契数列的格式：0、0.5、1、2、3、5、8、13、20、40、100。

估算可帮助您根据您拥有的团队成员数量来衡量应该向下一个「迭代」添加多少工作。经过几次「迭代」后，您的团队会更好地确定每个「迭代」可以完成多少工作，这将有助于避免过度投入。

• 规划迭代工作项

完成故事点评估后，开发团队承诺当前迭代中完成一定故事点数的用户故事。然后，在 PingCode Scrum 项目管理当前迭代的规划中，将迭代计划会议上评估的工作项移入刚刚创建的 「迭代」 中，形成迭代待办列表（Sprint Backlog）。

在规划完成后，您还可以在概览页面查看当前迭代的基本信息，了解当前迭代规划的故事点和工作项数量。

第八步：开始迭代

1. 拆解子任务、指派人员

在 Scrum 项目执行过程中，需要将用户故事拆分成任务子工作项，来帮助研发工程师更好的进行代码编写。您根据已分发到的项目需求进行研发任务分解，将需求进行拆分成具体的研发任务，分配给相关负责人并完善任务的详细信息。

2. 对任务进行预估和登记工时

在项目开始落实之前，需要先对其所需工作时长进行预估。目的在于，首先，管理者或者您本身想要知道您负责项目所需要的工时，从而判断该项目值不值得执行；其次，管理者也可以通过工时预估，合理的调用资源；再者，在进行项目外包上，预估所需的时间，可以根据每人工时单价进行整体报价。最后，在项目落实时候，您也可以根据预估的工时，进行阶段性监督，促使项目稳步进行中。 这时您可以通过迭代的剩余工时统计及燃尽图直观把控任务情况。

您可以通过 PingCode 的「登记工时」为不同类型工作填写预估工时、登记工时，实际工时，能够在任务和缺陷层进行工时汇总统计，形成项目/团队工时统计视图可视化度量工作量。这样一来可以帮助团队更为有效地管理时间，掌握工作时间内的效率、效能和成果，从而提高项目成员的工作效率。

3. 工作项集成 CI/CD 工具

在代码编写过程中，您可以将工作项集成代码托管工具，如：GitHub、GitLab、Gitee等，在工作项详情页中可视化呈现代码分支数据、代码提交状态及代码拉取记录，帮助您获取上下游编码的进展情况，更全面的进行代码编写工作。

同时，您也可以将工作项集成 Jenkins 等持续集成工具，在工作项详情页中可视化呈现每个任务的进展状态，跟踪构建、部署进度，帮助您将构建、部署与项目和工作项整合到一起，打通项目管理和代码构建及部署。

如果您想了解如何与CI/CD工具集成对接，详见「 PingCode 集成对接 GitHub 」、「 PingCode 集成对接 GitLab 」、「 PingCode 集成对接 Gitee 」、「 PingCode 集成对接 Git 」、「 PingCode 集成对接 Jenkins 」。

4. 工作项关联测试

需求追溯和测试用例跟踪过程繁琐，需要耗费大量的时间和人力进行统计、汇总、整理发布，导致不能快速响应市场项目研发效率较低。为了解决这一问题，您可以打开「工作项」迅速定位到该工作项相关测试用例，根据所述测试用例和需求之间的关联关系，当您点击任意一个需求时，自动显示该条需求对应的所有测试用例，您也可以通过新建当前工作项的测试用例用来阐述该工作项的验收标准。

5. 工作项关联知识页面

在 Scrum 项目执行过程中，您可以将工作项与其相关一切知识页面进行关联，例如一个「撰写PRD文档」工作项，可以关联 PRD 文档页面，围绕工作项产生的设计文件、产品文档、测试用例文档、项目周报等都可以直接关联到工作项中，这样只要点进任务，就可以了解与之相关的一切。如果您想要了解如何使用 PingCode 知识管理，详见「PingCode 知识管理开箱指南」。

第九步：每日站会

1. 迭代故事板/任务板

迭代规划完成后，您就可以在故事板 / 任务板上看到已规划的用户故事或任务已分别放置在独立泳道中。故事板展示的是当前迭代中的用户故事或缺陷；任务板展示的是当前迭代中的任务或缺陷。

以故事板为例：

通过故事板展示团队当前正在处理的用户故事，帮助团队快速发现和处理障碍，集中精力进行目标冲刺。

故事板的每一列都代表工作流中的一个步骤，每个看板卡代表一个工作项。PingCode提供默认工作流，如果目前您所在团队的协作流程和默认的工作流有出入，可以根据需要自行配置列，以便从不同维度管理工作项。对于泳道里的工作项您可以自由拖拉拽，并通过PingCode 自动化配置相关规则，实现拖动工作项至对应栏自动更改工作项的状态。如果您想要了解如何使用 PingCode 自动化，详见「PingCode 自动化开箱指南」。

2. 跟踪迭代进度

在开发团队进行迭代冲刺时，需要及时跟踪当前迭代进度。对于敏捷团队来讲，燃尽图可以说的上是最有用的一种信息发射源。PingCode Scrum项目管理为您提供迭代概览，方便您查看当前迭代基本信息，并提供故事点、用户故事数、工时三种维度的燃尽图，直观了解迭代进度，确定是否符合理想线，识别当前迭代风险。

Tips：什么是燃尽图？

「燃尽图」显示了在迭代中要完成的实际和估计的工作量。燃尽图中的水平 x 轴表示时间，而垂直 y 轴通常表示故事点。

使用「燃尽图」追踪迭代剩余的总工作量，并预测实现「迭代目标」的可能性。通过在整个迭代过程中跟踪剩余工作，团队可以管理其进度并做出相应的响应。需要注意的异常情况：

• 团队在多次的「迭代」中提前完成了工作量，可能因为他们给「迭代」规划的工作量不足。
• 团队在多次的「迭代」中总是无法完成工作量，可能因为他们给「迭代」规划的工作量太多。
• 燃尽线在两个日期之间急剧下降，而不是更渐进的燃尽，可能因为工作拆解的粒度不够均匀。
• 燃尽线应该一直往下走，如果出现往上走的情况，那么可能是「产品负责人」在「迭代」中期增加了需求。

3. 监控工作项和故事点变更

一般而言，对一个成熟的 Scrum 团队，通过挑选合适的用户故事列表，能够有效均衡团队工作量在各成员之间的分布，通过合适的接口设计，解除任务间的高度耦合。但实际上，由于各种各样的原因，比如开发模式成熟度、管理层压力、team 前期选择的随意性、任务本身的不确定性、技术架构不清晰等，会导致迭代中故事点/工作项变更，容忍迭代期间的任务变更在某些情况下是合理的，因此在迭代进行过程中，您可以随时在变更模块查看迭代的故事点和工作项变更情况，方便及时了解迭代进行中的异常。

4. 统计工时

如果您想要针对单一项目核算项目成本，同时也想要知晓每个员工一段时间内投入每个项目的工时及总工时，或者通过收集成员工作内容为项目经理提供项目执行进展情况，为判断项目是否按时完成提供依据等。PingCode 的「工时统计」将为您带来这些信息，在工时汇总中，您可以按照工作项、项目、成员以及工作类别等四个维度进行统计分析。

5. 报表管理

使用 PingCode Scrum 项目管理后，您的产研团队完全可以不凭借经验感觉和有限的数据分析复盘，系统自动收集和统计项目团队在使用产品过程中所产生的数据，以可视化报表的形式，帮助项目团队全方面度量研发效能和作出研发决策，您可以在报表管理中能够看到项目内的项目、迭代、需求、缺陷等各个维度的统计报表，方便您的团队成员定期进行数据查看与分析。

第十步：迭代评审和回顾

1. 迭代评审会议

迭代快结束时，通常在迭代的最后一天，您可以召开迭代评审会议，迭代评审会议也叫做迭代演示会议，团队成员依次在该会议上展示他们在该「迭代」中完成的工作内容，产品经理根据需求和验收标准，验证增量完成情况。

当产品负责人验收工作成果时，可能会发现一些缺陷，而这个时候团队可以直接在该用户故事上直接创建「缺陷/Bug」，并确定Bug严重程度。此外，可以将此缺陷作为Product Backlog的输入，在下一次迭代计划会议上与其他一起评估优先级。

2. 迭代回顾会议

在评审会议结束后，您的团队成员一起召开迭代回顾会，迭代回顾会将整个迭代形成了闭环，并且基于会议上的成员之间的反馈可以帮助团队持续改进。使用PingCode您可以在迭代管理中开发迭代回顾板，通过做的好的/需要改进/改进计划三栏清晰的帮助您的团队成员更好的记录和追踪迭代回顾内容。

当您看到活动中的Sprint里面的任务板/故事板卡片都在「已完成」列时，一个完整的 Scrum 迭代过程就基本结束，这个Sprint的完成时间可能会提前也可能会延期（时间是根据任务量指标的结果）。

目前，您已经掌握了如何在PingCode Scrum项目管理中：

1. 使用「用户故事」构建「待办需求列表（Product Backlog）」；
2. 从「待办需求列表（Product Backlog）」中挑出「用户故事」来规划「迭代」；
3. 完成一个「迭代」的全流程。

这是进行 Scrum 流程的基础知识，只需要重复二到十的流程，就可以持续进行 Scrum 实践。同时您也可以根据团队本身的特殊性来进行微调。

二、向团队介绍 PingCode Scrum 项目管理工具

完成以上内容，相信您对 PingCode Scrum 管理已经有所了解，如果你想了解它是否适用于您的团队，那么我们建议您可以在团队中开启小范围试用，听听团队的声音再进行判断。