关于项目管理:经典项目管理-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 种形式外，团队可在经典项目管理模式下实际更多合作形式。

团队评估

从概念、模型、到利用实际有了根本理解之后，在文末，咱们提供了一个精简的评估来进行麻利与经典项目管理模式的匹配举荐，您能够基于团队现状进行勾选心算一下，粗略的参考。

1 需要稳定性

需要稳固 0 分——需要不稳固 10 分

2 业务与 IT 互动性

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

3 我的项目影响

要害零碎关联度高 0 分——要害零碎关联度低 10 分

4 零碎模块化水平

零碎模块化水平低 0 分——零碎模块化水平高 10 分

5 环境开放度

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

得分 0～20，咱们更加举荐应用经典模式
得分 30～50，咱们更加举荐应用麻利模式

返回体验经典项目管理

参考文献：

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