词汇表
项目协同
「项目」是实践 CODING DevOps 的最小单位，可以将它当做最基础的项目进度可视化协调工具。「项目协同」功能模块是协调各个事项的调度中心，在这里可以将众多事项进行拆解与分配，比如将用户故事拆解出子工作项，将合并请求关联至事项，分配缺陷至相关责任人等等，通过合理的任务分配与处理机制实现无间协作。
经典项目管理
传统项目管理的特点是强计划驱动，围绕着需求、资源和时间展开，需求范围固定后才可分配人员和时间，并在项目推进过程中积极跟踪和控制风险。
「经典项目管理」便是 CODING 基于传统项目管理模式提供的管理方案，主要适用于使用传统项目管理方式的团队，帮助团队在同一平台汇总信息，统一协同，随时查看任务并分配与协调人员，及时跟踪测试进度和缺陷修复进度，实时掌握项目进度，过程透明可控。
Scrum 敏捷项目管理
敏捷项目是价值驱动的，在敏捷项目管理中，先固定了成本与时间，需求在交付期间频繁细化，在固定的时间盒中优先交付高价值的需求。敏捷项目管理中最常见的模型为 Scrum 框架，基于经验主义和精益思维，采纳了一种迭代和增量的方法来优化对未来的预测性并控制风险。
CODING 的「Scrum 敏捷项目管理」模式便是在此基础上，通过标准化的流程和完整的信息统计，帮助团队快速入门敏捷研发并创造价值。该模式主要适用于迭代驱动型的团队，通过短周期的快速试验来暴露自身所面对的潜在问题，并不断检视与调整来持续改进产品、团队和工作环境，从而高效并创造性地交付最高价值的产品。
在 CODING 中使用不同管理模式时，会涉及以下概念，可以结合实际使用流程来加深理解。
迭代
在敏捷模式下：指时间冲刺（Sprint），指团队完成一定数量工作所需的短暂、固定的周期。
在经典模式下：指某版本（Version）的生产过程，包括从需求分析到交付完成。
事项
「事项」是项目协同中的主体，例如史诗（Scrum 敏捷项目管理）、用户故事、需求、任务、缺陷等都可以被抽象为不同的「事项」类型。
事项属性
属性可以理解为事项的「描述信息」，用于快速说明此事项目前的状态、截止日期、处理人、优先级等信息，「事项属性」主要用于定制对应事项类型的字段，项目中各事项类型的属性均需要从属性列表中进行选择。
事项状态
「事项状态」是事项在生命周期内所处的状态，可在工作流配置页面配置不同状态间的流转。
例如需求中可设置「未开始」、「开发中」、「测试中」、「已完成」等状态；缺陷中可设置「处理中」、「待验证」、「拒绝」、「关闭」等状态。
史诗
「史诗」（Scrum 敏捷项目管理）是敏捷研发的纵轴，也是一个较大的功能或特性，可以将大型工作分解为多个较小的需求或任务。通常其需要分多次迭代才可完成。
需求类型
需求类型下分「用户故事」和「需求」两种类型，经典项目管理默认开启「需求」，Scrum 敏捷项目管理默认开启「用户故事」，可根据团队工作模式进行选择或同时开启。
在敏捷模式下：需求由产品负责人（Product Owner）创建，是最小交付单位，不可拆分为任务，但可以拆分为子工作项。
在经典模式下：需求由产品经理创建，可拆分子需求，最后拆分成任务，比如前端页面任务、后端接口任务、测试任务等等。
用户故事
是敏捷框架中最小的工作单元，是从用户角度描述软件如何为其带来特定的价值。需求
是指用户解决某一个问题或达到某一目标所需的软件功能。
任务
是指为实现某个目标或需求所进行的具体活动。
缺陷
是指软件不符合最初定义的业务需求的现象。
子工作项
子工作项用于敏捷模式，所有含有父事项的工作项统称为子工作项。因此，敏捷模式下的需求、任务、缺陷事项都可以向下分解为子工作项。
子需求 / 子任务
子需求 / 子任务用于经典模式。当需求需要继续向下分解以指导更加细致的活动时，可以将其分解为子需求或子任务；其中子需求可以继续向下分解。
子任务与任务同级，但会标记为“子事项”。
2022-05-07最近更新在阅读中是否遇到以下问题？*
您希望我们如何改进？*
如果您希望得到回复，请留下您的邮箱地址。
