CODING将项目的开发生命周期可分为预测型（一）

　　CODING将项目的开发生命周期可分为预测型（一）

　　本文详细介绍了如何在CODING中选择合适的协作模式。

　　进入项目，登录编码控制台，点击【立即使用】，进入编码使用页面。点击页面右上角

　　，进入项目列表页面，点击项目图标进入目标项目。点击进入左侧菜单栏中的【项目协作】功能。

　　CODING支持Scrum敏捷项目管理和传统项目管理，那么研发团队应该如何根据自己的需求和管理偏好选择基于传统项目管理模式【经典项目管理】还是基于Scrum的【Scrum敏捷项目管理】 ]？本文将从概念差异、常见研发模式、适用场景、实际应用等方面为选择提供参考。

　　价值理念

　　我们先来看看两者在概念上的区别。项目管理的铁三角围绕着范围、成本和时间。传统项目管理的特点是计划驱动性强，只有在需求范围确定后才能分配人员和时间，在项目进展过程中主动跟踪和控制风险。敏捷项目是价值驱动的。在敏捷项目管理中，成本和时间首先是固定的，需求在交付过程中经常被细化，高价值的需求在固定的时间内首先交付。

　　在传统项目管理和敏捷项目管理的背后，还存在预定义过程和实验过程之间的概念差异。预定义流程更注重计划和控制变更。实验过程更多地拥抱变化，并在通过快速实践得到反馈后向前调整。 PMBOOK 将项目开发生命周期划分为预测（计划驱动）、自适应（敏捷）、迭代、增量或混合。

　　一个项目可能有上述一个或多个阶段，企业中不同的团队也可能使用一个或多个项目管理模型。例如，对于企业核心系统、外包项目、交付性强的项目，往往采用传统的项目管理方式。这些系统要么需要很少的需求变化，要么需要详细的项目计划和业务承诺；而对于互联网产品，他们的需求和用户往往不稳定，敏捷模式可以更快地获得市场反馈。在这种情况下，这是不可能的，也不适合长期细致的规划。

　　研发模式

　　了解了概念上的差异后，我们再来看看常见的研发模式。传统项目管理中最常见的模型是瀑布模型，而敏捷项目管理中最常见的模型是Scrum框架。

　　传统项目管理-瀑布模型

　　业界普遍认为瀑布模型是Winston Royce在1970年提出的，瀑布模型的核心思想是按照流程简化问题，将功能的实现与设计分开，方便协作瀑布模型将软件生命周期划分为六个基本活动：规划、需求分析、软件设计、程序编写、软件测试和运维，并规定了它们自上而下和互连的固定顺序，就像瀑布一样。逐渐下降。

　　此外，瀑布模型非常重视文档。前一阶段的输出是下一阶段的输入，文档是连接各个阶段的唯一信息。从瀑布模型的角度来看，在设计和文档不足的情况下，如果团队成员在项目完成之前离开，知识就会丢失，项目可能难以从损失中恢复。如果有可以正常使用的设计文档，新的团队成员甚至新的团队应该可以通过阅读文档来接管项目。

　　其实Royce最初提出这个模型的时候，并不是为了支持瀑布。相反，他指出瀑布模型可能有风险，因为瀑布模型在需求频繁变化的项目面前毫无价值。但也许意*敏*感*词*的产品，产品本身扎实稳定，技术简单易懂。

　　Royce 确实提出了瀑布模型的改进版本。他把原型设计和瀑布模型放在同一个位置，这个原型设计类似于敏捷中的一次迭代，通过一次迭代来验证项目的可执行性。从而降低风险。接下来，我们来看看迭代思维在Scrum中是如何被深度运用的。

　　敏捷项目管理-Scrum 框架

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

　　1986 年，Hirotaka Takeuchi 和 Ikujiro Nonaka 描述了一种新的整体方法。他们将这种新的整体方法与橄榄球进行了比较：跨职能团队在不同阶段完成整个过程。球队“整体向前，传球”。这种方法可以提高商业新产品开发的速度和灵活性。

　　经过千禧年的引用和演变，这个类比终于在 1995 年在奥斯汀的 OOPSLA '95（计算机协会 ACM 年会）上举行。Jeff Sutherland 和 Ken Schwab 共同发表了一篇论文并首次提出了 Scrum 的概念。在接下来的几年里，两人一起工作，将想法与经验和行业最佳实践相结合，形成了我们现在所知的 Scrum。 2020年，二人发布了最新版本的Scrum敏捷指南，感兴趣的读者可以继续在相关阅读中参考。

　　Sprint 是 Scrum 的核心，在这里将想法转化为价值。它们是固定持续时间的事件，持续 1 到 4 周。上一个 Sprint 结束后，下一个新的 Sprint 立即开始。实现产品目标所需的所有工作都在 Sprint 中进行，包括 Sprint 计划会议、每日站立会议、Sprint 审查会议和 Sprint 回顾会议。

　　Scrum 的生命力在于它在面对不断变化的市场时提供的“小步骤”想法。产研团队通过“脏手”快速获得对产品的反馈，从而对产品进行改进。为了保持紧密的迭代速度，Scrum框架要求项目管理过程中信息和流程的高度“透明”：透明使检查成为可能，频繁的“检查”可以快速发现项目中的问题；检查使适应 可以对发现的问题进行快速调整。 Scrum 实践使组织能够对变化做出响应。

　　实际应用

　　我们不认为传统的项目管理模式和敏捷的项目管理模式是完全相互排斥的。两者各有特点和适用场景，两个项目都有数字化需求。编码项目协作提供了基于传统项目管理模式的【经典项目管理】，以及基于Scrum的【Scrum敏捷项目管理】。您的团队可以基于编码实践瀑布开发、增量开发、Scrum 框架等研发模式。我们希望能够为更多组织和更多团队提供多样化的项目管理解决方案，而不是一锤定音。

　　下图列出了【Scrum Agile Project Management】和【Classic Project Management】在编码项目协作中的工作流程对比：

　　经典项目管理

　　CODING【经典项目管理】旨在解决传统项目管理的五个主要问题：

　　统一协调，不同阶段、功能信息汇总在同一平台上；

　　全局视图，计划页面汇总项目进度，实时掌握多次迭代的进度和情况；

　　项目进度、计划、迭代概览等页面跟踪进度，过程透明，进度可控；

　　资源管理，计划页面可随时查看成员任务、分配和协调人员；

　　质量控制，通过测试管理、缺陷管理等方式随时跟踪测试进度和缺陷修复进度

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

　　进入经典项目管理模式详解。您的团队可以在此模式下练习多种协作方式。

　　Scrum 敏捷项目管理

　　CODING [Scrum Agile Project Management] 适用于迭代驱动的团队。这种类型的团队通过短期快速测试暴露自己面临的潜在问题，并不断审查和调整以不断改进产品、团队和工作环境，从而高效、创造性地交付最高价值的产品。

　　CODING 敏捷开发协作提供了一个以迭代和事件（迭代、史诗、用户故事、需求、缺陷、任务和子任务）为中心的任务协作工具。面对大任务时，可以写成[epic]，然后具体到工作细节、任务、缺陷管理等需求。 敏捷协作的关键是快速发布一个有效但不完美的最小版本每次迭代包括五个步骤：计划、设计、编码、测试和评估。在这样一个不断改进产品和添加新功能的积极工作流程中，通过频繁发布，并跟踪对前一次迭代的反馈，最终产品正在接近更完整的产品形式。

　　进入Scrum敏捷项目管理模型详解，帮助您和您的团队快速上手敏捷研发，通过标准化流程和完整的信息统计，成为企业实践敏捷研发的好工具。

　　选择协作模式

　　在您对概念、模型和应用实践有了基本的了解后，在文章的最后，我们提供了一个简明的评估，以推荐匹配的敏捷和经典项目管理模型。您可以根据团队目前的情况进行检查和心理计算。

　　需求稳定

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

　　业务和 IT 交互

　　业务与IT交互难度为0分————业务与IT交互难度为10分。

　　项目影响

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

　　系统模块化程度

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

　　环境发展程度

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

　　测试结果

　　0-20分，我们更推荐经典模式；

　　分数为 30-50 时，我们建议更多地使用敏捷模式。

　　参考这篇文章：

　　吉姆·海史密斯。 “敏捷项目管理”项目管理学院。项目管理知识系统指南（PMBOK 指南）（第 6 版）作者：Robert C. Martin 沈建和强罗涛 译《敏捷和清洁之路》2020 Scrum 指南 Winston W. Royce