1. 产品简介
  2. 快速开始
  3. 编写构建流程
  4. 配置构建计划
  5. 构建环境依赖包
  6. 构建制品
  7. 构建节点
  8. 管理构建计划
  9. 系统插件
  10. 自定义团队插件
  11. 最佳实践
  12. 常见问题
  13. 词汇表
项目协同 / 词汇表

词汇表

项目协同

「项目」是实践 CODING DevOps 的最小单位,可以将它当做最基础的项目进度可视化协调工具。「项目协同」功能模块是协调各个事项的调度中心,在这里可以将众多事项进行拆解与分配,比如将用户故事拆解出子工作项,将合并请求关联至事项,分配缺陷至相关责任人等等,通过合理的任务分配与处理机制实现无间协作。

经典项目管理

传统项目管理的特点是强计划驱动,围绕着需求、资源和时间展开,需求范围固定后才可分配人员和时间,并在项目推进过程中积极跟踪和控制风险。

「经典项目管理」便是 CODING 基于传统项目管理模式提供的管理方案,主要适用于使用传统项目管理方式的团队,帮助团队在同一平台汇总信息,统一协同,随时查看任务并分配与协调人员,及时跟踪测试进度和缺陷修复进度,实时掌握项目进度,过程透明可控。

Scrum 敏捷项目管理

敏捷项目是价值驱动的,在敏捷项目管理中,先固定了成本与时间,需求在交付期间频繁细化,在固定的时间盒中优先交付高价值的需求。敏捷项目管理中最常见的模型为 Scrum 框架,基于经验主义和精益思维,采纳了一种迭代和增量的方法来优化对未来的预测性并控制风险。

CODING 的「Scrum 敏捷项目管理」模式便是在此基础上,通过标准化的流程和完整的信息统计,帮助团队快速入门敏捷研发并创造价值。该模式主要适用于迭代驱动型的团队,通过短周期的快速试验来暴露自身所面对的潜在问题,并不断检视与调整来持续改进产品、团队和工作环境,从而高效并创造性地交付最高价值的产品。

在 CODING 中使用不同管理模式时,会涉及以下概念,可以结合实际使用流程来加深理解。

迭代

在敏捷模式下:指时间冲刺(Sprint),指团队完成一定数量工作所需的短暂、固定的周期。

在经典模式下:指某版本(Version)的生产过程,包括从需求分析到交付完成。

事项

「事项」是项目协同中的主体,例如史诗(Scrum 敏捷项目管理)、用户故事、需求、任务、缺陷等都可以被抽象为不同的「事项」类型。

事项属性

属性可以理解为事项的「描述信息」,用于快速说明此事项目前的状态、截止日期、处理人、优先级等信息,「事项属性」主要用于定制对应事项类型的字段,项目中各事项类型的属性均需要从属性列表中进行选择。

事项状态

「事项状态」是事项在生命周期内所处的状态,可在工作流配置页面配置不同状态间的流转。

例如需求中可设置「未开始」、「开发中」、「测试中」、「已完成」等状态;缺陷中可设置「处理中」、「待验证」、「拒绝」、「关闭」等状态。

史诗

「史诗」(Scrum 敏捷项目管理)是敏捷研发的纵轴,也是一个较大的功能或特性,可以将大型工作分解为多个较小的需求或任务。通常其需要分多次迭代才可完成。

需求类型

需求类型下分「用户故事」和「需求」两种类型,经典项目管理默认开启「需求」,Scrum 敏捷项目管理默认开启「用户故事」,可根据团队工作模式进行选择或同时开启。

在敏捷模式下:需求由产品负责人(Product Owner)创建,是最小交付单位,不可拆分为任务,但可以拆分为子工作项

在经典模式下:需求由产品经理创建,可拆分子需求,最后拆分成任务,比如前端页面任务、后端接口任务、测试任务等等。

  • 用户故事
    是敏捷框架中最小的工作单元,是从用户角度描述软件如何为其带来特定的价值。

  • 需求
    是指用户解决某一个问题或达到某一目标所需的软件功能。

任务

是指为实现某个目标或需求所进行的具体活动。

缺陷

是指软件不符合最初定义的业务需求的现象。

子工作项

子工作项用于敏捷模式,所有含有父事项的工作项统称为子工作项。因此,敏捷模式下的需求、任务、缺陷事项都可以向下分解为子工作项。

子需求 / 子任务

子需求 / 子任务用于经典模式。当需求需要继续向下分解以指导更加细致的活动时,可以将其分解为子需求或子任务;其中子需求可以继续向下分解。

子任务与任务同级,但会标记为“子事项”。

问题反馈 >
上一篇如何使用 CODING 进行瀑布流式研发
2022-05-07最近更新
感谢反馈有用
感谢反馈没用

在阅读中是否遇到以下问题?*

您希望我们如何改进?*

在线支持

工单咨询