选择合适的协作模式
CODING 支持 Scrum 敏捷项目管理以及传统项目管理，那么研发团队应该如何根据自身需求及管理偏好，选择基于传统项目管理模式下的「经典项目管理」，或是基于 Scrum 的「Scrum 敏捷项目管理」？本文将从理念差异、常见的研发模型、适用场景、实践应用等角度来提供选型参考。
价值理念
首先来看看在理念方面，两者有何不同。项目管理的铁三角是围绕着范围、成本和时间展开的。传统项目管理的特点是强计划驱动，需求范围固定下来后才可分配人员和时间，并在项目推进过程中积极跟踪和控制风险。敏捷项目是价值驱动的，在敏捷项目管理中，先固定了成本与时间，需求在交付期间频繁细化，在固定的时间盒中优先交付高价值的需求。
传统项目管理和敏捷项目管理的背后，也是预定义过程和实验性过程的理念差异。预定义过程更注重计划，控制变化。实验性过程更加拥抱变化，通过快速实践获得反馈后调整前进。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 项目协同提供基于传统项目管理模式下的「经典项目管理」，以及基于 Scrum 的「Scrum 敏捷项目管理」。您的团队可以基于 CODING 实践瀑布开发、增量开发、Scrum 框架等多种研发模式。我们希望能够提供给更多组织与更多团队，多样化的项目管理解决方案，而不是一个锤子敲所有的钉子。
下图列出了在 CODING 项目协同中，「Scrum 敏捷项目管理」与「经典项目管理」模式的工作流对比：
经典项目管理
CODING 「经典项目管理」旨在解决传统项目管理的五大难题：
统一协同，不同阶段、职能信息在同一个平台汇总；
全局视图，计划页汇总项目进度，实时掌握多个迭代的进展与情况；
项目进度，计划、迭代概览等页面跟踪进度，过程透明、进度可控；
资源管理，计划页可随时查看成员任务、分配和协调人员；
质量管控，通过测试管理、缺陷管理等随时跟踪测试进度和缺陷修复进度。
除上述能力外，基于 CODING 的文件网盘以及 Wiki 知识库，团队还可以轻松管理传统项目管理过程中的文档，可随时通过 Web 直接访问与分享，文件历史可随时回溯文件历史版本；您还可以在需求、任务等事项中，通过引用功能一键定位到相关文档，省时省心。
前往进入经典项目管理模式详解，您的团队可以在此模式下实践多种协作方式。
Scrum 敏捷项目管理
CODING 「Scrum 敏捷项目管理」适用于迭代驱动型的团队。这类团队通过短周期的快速试验来暴露自身所面对的潜在问题，并不断检视与调整来持续改进产品、团队和工作环境，从而高效并创造性地交付最高价值的产品。
CODING 敏捷开发协同提供了以迭代与事项（迭代、史诗、用户故事、需求、缺陷、任务、子任务）为核心的任务协同工具。面临一个大型任务时，可以将其作为「史诗」进行编写，再具体至工作细节的需求、任务、缺陷管理等。敏捷协作的关键在于先快速发布一个有效但不完美的最简版本；每一次迭代都包含规划、设计、编码、测试、评估五个步骤。在这样不断改进产品，添加新功能的正向工作流内通过频繁的发布，以及跟踪对前一次迭代的反馈，最终接近较完善的产品形态。
前往进入 Scrum 敏捷项目管理模式详解，帮助您和您的团队快速入门敏捷研发，并通过标准化的流程和完整的信息统计成为企业实践敏捷研发的好工具。
选择协作模式
从概念、模型、到应用实践有了基本了解之后，在文末，我们提供了一个精简的评估来进行敏捷与经典项目管理模式的匹配推荐，您可以基于团队现状进行勾选心算一下。
需求稳定性
需求稳定 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·马丁 著 申健 何强 罗涛 译 《敏捷整洁之道》
- 2020 Scrum 指南
- Winston W. Royce
- Scrum——词条
2022-05-11最近更新在阅读中是否遇到以下问题？*
您希望我们如何改进？*
如果您希望得到回复，请留下您的邮箱地址。
