检测到您已登录华为云国际站账号,为了您更好的体验,建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
研发需求生命周期共有初始、分析、开发、测试、完成五个状态,完整的转状态流程图如图1所示。 图1 研发需求状态转换流程图 各状态下对应的操作如表1所示。 表1 研发需求状态转换操作说明 状态 流转说明 初始 新建研发需求时,状态默认为“初始”。 分析 处理完“初始”状态的研发需求后,将“状态”改为“分析”。
研发需求生命周期共有初始、分析、开发、测试、完成五个状态,完整的转状态流程图如图1所示。 图1 研发需求状态转换流程图 各状态下对应的操作如表1所示。 表1 研发需求状态转换操作说明 状态 流转说明 初始 新建研发需求时,状态默认为“初始”。 分析 处理完“初始”状态的研发需求后,将“状态”改为“分析”。
Scrum项目和看板项目。 如果从Scrum流程项目复制到看板协作类型项目: Epic/Feature/Story 转换为需求,Task 转换为任务,Bug 转换为缺陷; 项目内复制仅支持工作项基本信息、自定义字段和项目内附件的复制,跨项目复制仅支持工作项基本信息。 移出工作项
IPD系统设备类项目缺陷流程介绍 缺陷的全生命周期共有分析、修复、测试、验收、关闭五个状态。完整的转状态流程图如图1所示。 图1 缺陷状态转换流程图 各状态下对应的操作如表1所示。 表1 缺陷状态转换操作说明 状态 流转说明 -- 新建缺陷。 缺陷提出人默认为创建缺陷的人。 分析 提交缺陷后,状态变为“分析”。
对IPD系统设备类的智能手表研发项目进行基线评审管理 产品从规划到上市要经过复杂的研发过程,CodeArts Req提供了基线评审和变更管理能力,实现需求基线-受控变更-变更评审-变更管理的过程化管理,让基线变更如门禁一样,达到阈值才能启动下一步,确保产品研发“做正确的事” 某公司计划推出一款智能手表,涉及多部
对IPD系统设备类的智能手表研发项目进行基线评审管理 产品从规划到上市要经过复杂的研发过程,CodeArts Req提供了基线评审和变更管理能力,实现需求基线-受控变更-变更评审-变更管理的过程化管理,让基线变更如门禁一样,达到阈值才能启动下一步,确保产品研发“做正确的事” 某公司计划推出一款智能手表,涉及多部
IPD独立软件类项目缺陷流程介绍 缺陷的全生命周期共有分析、修复、测试、验收、关闭五个状态。完整的转状态流程图如图1所示。 图1 缺陷状态转换流程图 各状态下对应的操作如表1所示。 表1 缺陷状态转换操作说明 状态 流转说明 -- 新建缺陷。 缺陷提出人默认为创建缺陷的人。 分析 提交缺陷后,状态变为“分析”。
计费FAQ 旧版计费方式如何收费? 旧版本开通/关闭服务按需计费方式说明 已开通旧版本服务,能否转换为新版本计费?
使用看板项目对商城管理项目进行需求规划 方案概述 CodeArts Req提供的看板项目是一种业界流行的轻量、灵活和简单的团队协作方法,它将项目的需求、缺陷和任务可视,让每个人一目了然地掌握每项工作的状态,团队通过移动工作卡片的方式更新工作进展,及时暴露风险和问题。 用户可以创建
如何在软件项目需求变更频繁的情况下做好有效的需求管理和规划 概述 围绕项目需求变更频繁,如何做好有效的需求管理和规划,本文将从背景、问题分析、解决措施几个方面进行细致讲解。 背景 不管是项目型软件开发还是产品型软件开发,需求变更频繁都是影响研发效能的首要因素,在2019年中国De
String 变更对象关联的评审单Id created_by String 变更对象的创建人ID created_date String 变更对象创建时间 description String 变更对象描述信息 id String 变更对象Id issue_id String 变更对象关联的工作项Id
多种开箱即用的场景化需求模型和对象类型(需求/缺陷/任务等),可支撑IPD、DevOps、精益看板等多种研发模式,还包含跨项目协同、基线与变更管理、自定义报表、Wiki在线协作、文档管理等功能。 预置了五种项目模板:IPD-系统设备类模板、IPD-
在需求管理服务控制台页可查看到购买的套餐信息。 变更需求管理服务套餐规格 需求管理服务支持变更套餐规格,变更影响请参见变更配置后对计费的影响。 登录需求管理服务控制台。 找到需求管理服务套餐,单击“变更”。 根据需要选择变更商品、变更类型,勾选同意声明,单击“下一步:确认订单”。 若变更类型选择“续费变更”,则还需要选择续费时长。
在左侧导航选择“通知设置”,进入“通知设置”页面。 单击“工作项变更”右侧的工作项成员字段的选择框,可以根据需要配置工作项变更事件的通知对象。 工作项变更事件类型支持用户名下有工作项被创建、工作项被修改、工作项被删除、工作项被评论、成员加入/移出项目和用户角色变动。 工作项变更的通知方式有站内信和邮件。 图1 通知设置
String 变更对象关联的评审单Id created_by String 变更对象的创建人ID created_date String 变更对象创建时间 description String 变更对象描述信息 id String 变更对象Id issue_id String 变更对象关联的工作项Id
String 工作项完成的迭代,在Bug中为修复迭代 change_status 否 String 工作项变更状态 变更评审中——change-reviewing 已变更——changed 未变更-unchange或null no_break_reason 否 String 无需分解原因,need_break=no时有此字段
WorkitemStatus objects 操作历史 表6 WorkitemStatus 参数 参数类型 描述 id String 工作项状态变更记录的id,每次变更产生一条新的记录id 最小长度:1 最大长度:32 status status object 工作项的状态 表7 status 参数
IssueOperateResult 参数 参数类型 描述 id String 变更的工作项id operator String 工作项变更人id state String 工作项变更后生命周期状态 operate_time String 工作项变更时间 状态码: 400 表7 响应Body参数 参数 参数类型
原始需求生命周期默认共有提交、分析、确认、规划、实现、交付、验收、关闭这几个状态。 原始需求各状态下对应的默认操作如表1所示。 表1 原始需求状态转换操作说明 状态 流转说明 提交 新建原始需求时,保存后状态默认为“提交”。 需求提出人默认为创建需求的人。 分析 提交原始需求完成后,状态变为“分析”。
原始需求生命周期默认共有提交、分析、确认、规划、实现、交付、验收、关闭这几个状态。 原始需求各状态下对应的默认操作如表1所示。 表1 原始需求状态转换操作说明 状态 流转说明 提交 新建原始需求时,保存后状态默认为“提交”。 需求提出人默认为创建需求的人。 分析 提交原始需求完成后,状态变为“分析”。