检测到您已登录华为云国际站账号,为了您更好的体验,建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
目跨地域协作,对产品质量要求高,流程强管控、决策点多,交付周期2~6个月不等,例如:通信设备、汽车、ERP软件、网管软件等。 使用IPD-系统设备类或IPD-传统软件类需求模型管理项目,基于跨项目协同、基线变更评审、端到端可追溯等能力,持续推动企业内部的高效协作和业务发展。 独立软件开发商(ISV)
"984407816014831616", "file_size" : "79234", "file_name" : "IPD系统设备-缺陷-导入模板.xlsx", "modified_by" : { "id" : "a360371833bf4c558f796fd707b44daf"
源自华为IPD需求管理理念和实践,提供多种开箱即用的场景化需求模板,支持IPD研发、DevOps敏捷交付、精益看板等多种研发模式: IPD-系统设备类 IPD-独立软件类 IPD-自运营软件/云服务类 Scrum 看板 多场景多角色的数据分析 提供面向项目经理的自定义统计报表,多个维度对比分析。
操作成员需拥有迭代的“状态设置”权限。 删除迭代 单击迭代卡片右上角下的“删除迭代”,可删除当前迭代。 删除后不可恢复。 迭代删除后,系统自动将该迭代下全部工作项移入至“未规划的工作项”中。 操作成员需拥有迭代的“删除”权限。 规划迭代 可以勾选未规划的工作项或其他迭代下的工作项,拖拽将其规划至目标迭代中。
字段创建时间 modified_by String 字段最后更新人显示名 definition_type String 字段级别 1,2,3为系统字段,4为租户字段,5为项目字段 field_type_name String 字段类型名称 required Boolean 字段在工作
视图左上方“搜索框”,输入框可输入标题或编号进行快速过滤。 视图右上方“过滤”,滑窗上方输入框可输入标题或编号进行快速过滤。 系统默认过滤器过滤:单击“过滤”后,选择默认过滤条件过滤: 图2 系统默认过滤器 个人过滤器过滤:可供当前用户长期使用。 创建个人过滤器 单击视图右上方“过滤”后,单击个人过滤器处的“创建”,显示“创建过滤器”。
估。 抄送人 被抄送的项目内成员。抄送完成后,抄送人会收到消息通知。 项目成员信息可在添加CodeArts项目成员中增加。 单击“确定”,系统会自动跳转到任务主页,并在主页右上角给出“新建Task成功”的提示。 在任务列表可查看到新建的任务,该任务状态显示为“初始”。 图2 任务列表页
原始需求的优先级,包含低、中、高三个等级。 默认为“中”。 抄送人 项目组内其他成员。 项目成员信息可在添加CodeArts项目成员中增加。 单击“提交”,系统会自动跳转到原始需求主页,并在主页右上角给出“提交需求成功”的提示。 单击“保存”,返回原始需求列表页面,该需求状态显示为“提交”。 单击“取消”,可取消该原始需求的创建。
看板 “看板Kanban”的核心概念,用户对工作项一系列操作的基础,一个项目可以创建最多5个看板。 “看板Kanban”的概念源于丰田精益生产系统,轻量、灵活和简单的团队协作方法。 看板协作是一种业界流行的轻量、灵活和简单的团队协作方法,它将项目的需求、缺陷和任务可视。 让每个人一目
面向全场景的一站式集成开发环境,提供一站式的分布式应用开发平台,支持分布式多端开发、分布式多端调测、多端模拟仿真,提供全方位的质量与安全保障。 IPD项目 IPD-系统设备示例项目 针对嵌入式软件场景,其特点为软件持续迭代,硬件平台也在持续演进,比如通信设备、汽车、家电、消费电子等涉及到软硬件复杂产品。 IPD-独立软件示例项目
缺陷现象描述。建议从用户视角描述。 错误码。错误码可以辅助分析定位代码问题。 环境信息,是开发环境,测试环境还是现网环境。 软件栈信息,包括对应的操作系统及其版本,数据库及其版本等等。 缺陷是否可以复现,复现的步骤。 缺陷描述模板举例: 【故障现象描述】 【F12查看错误码】 【环境信息】
Task是对当前Sprint的Story进行的分解。 所有这些粗略和详细的Story都放在产品Backlog中,整个列表要遵循DEEP(Detailed appropriately、Emergent、Estimated、Prioritized)原则,定期梳理和排序优化,保证高优先级的需求优先实现和交付。
列表变成潜在可发布的功能增量(Scrum指南)。 那么“自组织”是什么呢? 从字面的意思来理解,自组织就是:安排分散的人或事物使其具有一定系统性或组成一个整体,而安排的人就是安排者自己。在敏捷开发中,自组织团队就是具备自我管理、自我驱动、自我学习等能力的敏捷开发团队本身,这样的团队一般具备如下特点:
定的规则,也就是管理好工作项的规则。 上表中的场景二是很多开发团队中经常遇见过的,也是本文着重描述术的情况。从根本解决工作项优先级的问题,系统地学习怎么样应对需求变更才是根本。 对于场景二的解决方案思路如下: 由于管理好工作项是解决问题的核心,因此在形成工作项之前,需要解决谁对工