经典项目管理 OR 敏捷项目管理，我该怎么选？

CODING 项目协同近期为支持传统项目管理推出了「经典项目管理」。至此，CODING 已全面支持敏捷项目管理以及传统项目管理。那么问题来了，「经典项目管理」和「敏捷项目管理」，我该怎么选呢？本文将从理念差异、常见的研发模型、适用场景、实践应用等角度来提供选型参考。

价值理念

首先来看看在理念方面，两者有何不同。项目管理的铁三角是围绕着范围、成本和时间展开的。传统项目管理的特点是强计划驱动，需求范围固定下来后才可分配人员和时间，并在项目推进过程中积极跟踪和控制风险。敏捷项目是价值驱动的，在敏捷项目管理中，先固定了成本与时间，需求在交付期间频繁细化，在固定的时间盒中优先交付高价值的需求。

传统项目管理和敏捷项目管理的背后，也是预定义过程和实验性过程的理念差异。预定义过程更注重计划，控制变化。实验性过程更加拥抱变化，通过快速实践获得反馈后调整前进。PMBOOK 将项目的开发生命周期可分为预测型（计划驱动型）、适应型（敏捷型）、迭代型、增量型或混合型。

一个项目可能具备上述一个或者多个阶段，在一家企业当中的不同团队可能使用着一到多种项目管理模式。比如对于企业核心系统、外包式项目、交付性质强的项目会以传统项目管理的方式进行，这些系统要么需求变化少，要么需要详细的项目计划和业务承诺。针对互联网产品，其需求和用户往往都不稳定，采用敏捷模式可以更快地获得市场反馈，这种情况下无法也不适合进行长期细致的计划。

研发模型

了解理念差异之后，我们来看看常见的研发模型。在传统项目管理当中最常见的模型为瀑布模型，敏捷项目管理中最常见的模型为 Scrum 框架。

瀑布模型

业界普遍认为瀑布模型是由温斯顿·罗伊斯（Winston Royce）于 1970 年提出的。瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，以便于协作。瀑布模型将软件生命周期分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

另外，瀑布模型非常强调文档，前一个阶段的输出就是下一个阶段的输入，文档是各阶段衔接的唯一信息。从瀑布模型角度出发，在设计和记录不充分的情况下，如果团队成员在项目完成之前离开，知识就会丢失，项目可能很难从损失中恢复过来。如果存在可以正常使用的设计文档，新团队成员甚至是全新团队都应该能够通过阅读文档来接手项目。

其实 Royce 最早提出这个模型时，并不是为了力挺瀑布。恰恰相反，他指出了瀑布模型可能会存在较大风险，因为在面对经常变化需求的项目时，瀑布模型毫无价值。

但也许意外往往也暗含着某种必然性，瀑布模型提供了一种结构化、易于理解的阶段线性流程；它还在开发过程中提供了易于识别的里程碑。由于这个原因，瀑布模型被用作许多软件工程课本和课程中开发模型的开始示例。截止目前它依然是软件开发企业使用的重要开发模型之一，瀑布模型可适用于要求和范围固定的产品，产品本身牢固稳定且技术易于理解的项目。

Royce 真正提出的是改良版瀑布模型，他将原型设计放到了和瀑布模型并重的地位，而这个原型设计就类似于敏捷当中的一次迭代，通过一次迭代来验证项目的可执行性，从而降低风险。接下来我们来看看迭代思想是如何在 Scrum 当中被深刻使用的。

Scrum 框架

Scrum 是一个解决复杂多变问题的框架。基于经验主义和精益思维，采纳了一种迭代和增量的方法来优化对未来的预测性并控制风险，帮助团队和组织创造价值。

1986 年竹内弘高和野中郁次郎阐述了一种新的整体性的方法，他们将这种新的整体方法与英式橄榄球相类比：由一个跨职能团队在不同的阶段完成整个过程，团队“作为一个整体前进，把球传来传去”。该方法能够提高商业新产品开发的速度和灵活性。

这一类比在经历了若干年的引用与演进之后，终于在 1995 年的在奥斯汀举办的 OOPSLA '95 （计算机协会 ACM 的一个年度性会议），杰夫·萨瑟兰和肯·施瓦伯联合发表了论文首次提出了 Scrum 概念。二人在接下来的几年里合作，将理念结合经验、业界最佳实践，形成我们现在所知的 Scrum。2020 年二人发布了最新版 Scrum 敏捷指南，感兴趣的读者可在相关阅读中继续查阅。

Sprint 是 Scrum 的核心，在这里创意转化为价值。它们是固定时长的事件，为期 1～4 周。前一个 Sprint 结束后，下一个新的 Sprint 紧接着立即开始。实现产品目标所需的所有工作都发生在 Sprint 内，包括 Sprint 计划会议、每日站会、Sprint 评审会议和 Sprint 回顾会议。

Scrum 的生命力在于面对多变的市场时，它提供的小步快跑思路。产研团队通过“把手弄脏”来得到产品的快速反馈，从而改进产品。为了能够保持紧凑的迭代节奏，Scrum 框架对项目管理过程当中的信息和流程的“透明度”要求很高。透明使检视成为可能，经常性的“检视”可以快速发现项目中存在的问题。检视使适应成为可能，针对发现的问题，可以快速的调整。Scrum 实践可以让组织拥有应对变化的能力。

实践应用

我们并不认为传统项目管理模式和敏捷项目管理模式是全然互斥的关系，两者是有着各自的特点和适用的场景，并且两种项目都有数字化的诉求。CODING 项目协同，除了敏捷管理模式，近期推出了经典管理模式。您可以基于 CODING 实践瀑布开发、增量开发、Scrum 框架等多种研发模式。我们希望能够提供给更多组织与更多团队，多样化的项目管理解决方案，而不是一个锤子敲所有的钉子。

下图中列出了在 CODING 项目协同中，敏捷项目管理模式与经典项目管理模式的工作流对比：

CODING 近期推出的经典项目管理，旨在解决传统项目管理的五大难题：

统一协同，不同阶段、职能信息在同一个平台汇总；
全局视图，计划页汇总项目进度，实时掌握多个迭代的进展与情况；
项目进度，计划、迭代概览等页面跟踪进度，过程透明、进度可控；
资源管理，计划页可随时查看成员任务、分配和协调人员；
质量管控，通过测试管理、缺陷管理等随时跟踪测试进度和缺陷修复进度。

除上述能力外，基于 CODING 的文件网盘以及Wiki 知识库，团队还可以轻松管理传统项目管理过程中的文档，可随时通过 Web 直接访问与分享，文件历史可随时回溯文件历史版本；您还可以在需求、任务等事项中，通过引用功能一键定位到相关文档，省时省心。

经典项目管理模式的使用方式非常灵活，以下两个例子可实践大瀑布模式和小瀑布模式：

大瀑布

将项目定义为有开始和结束时间的软件开发项目。使用迭代将项目划分为 6 个阶段：规划、需求分析、软件设计、程序编码、软件测试和运行维护。按时间先后顺序依次完成。每个阶段完成后输出的文档（需求文档、设计文档、测试文档等）可录入到文件网盘以及 Wiki 中。完成最后一个迭代表明整个项目的完成。

小瀑布

在小瀑布的使用场景中，每一个需求有 6 个状态：定义、设计、实现、测试、运行、维护。设置需求的工作流，只有邻接状态才可流转，不允许跳跃。对应这 6 个状态，将需求分别分解成 6 个阶段的任务。在每个阶段的任务都完成后，需求进入到下一个状态。

以下图的“用户管理”的需求为例，目前需求分析、设计两个阶段相关的任务都已全部完成，正在处理编码实现相关的任务，后续阶段测试、运行、维护的任务都处于未开始阶段。

除了以上 2 种方式外，团队可在经典项目管理模式下实践更多协作方式。

团队评估

从概念、模型、到应用实践有了基本了解之后，在文末，我们提供了一个精简的评估来进行敏捷与经典项目管理模式的匹配推荐，您可以基于团队现状进行勾选心算一下，粗略的参考。

需求稳定性

需求稳定 0 分——需求不稳定 10 分

业务与 IT 互动性

业务与 IT 互动难度高 0 分——业务与 IT 互动难度低 10 分

项目影响

关键系统关联度高 0 分——关键系统关联度低 10 分

系统模块化程度

系统模块化程度低 0 分——系统模块化程度高 10 分

环境开放度

环境开放度低 0 分——环境开放度高 10 分

得分 0～20，我们更加推荐使用经典模式

得分 30～50，我们更加推荐使用敏捷模式

前往体验经典项目管理

参考文献：

Jim Highsmith. "Agile Project Management”
Project Management institute. 项目管理知识体系指南（PMBOK 指南）（第 6 版）
罗伯特·C·马丁著申健何强罗涛译《敏捷整洁之道》
https://zh-chs.scrumguides.guru/
https://en.wikipedia.org/wiki/Winston_W._Royce
https://zh.wikipedia.org/wiki/Scrum#cite_ref-1