检测到您已登录华为云国际站账号,为了您更好的体验,建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
缺陷流程灵活自定义 不同的产品、团队和研发场景,对缺陷的作业过程要求也不尽相同。为了适应不同的业务流程和管理需求,CodeArts Defect提供了强大的自定义能力,通过可视化流程画布可灵活定制适合您团队的缺陷工作流,满足多项目、多团队的缺陷管理需求,提高缺陷管理的效率和准确性,助力产品质量和用户体验的提升。
图解需求管理(CodeArts Req)
业务分析人员和测试人员的角色。 同时,需求责任人还要在版本、迭代和Backlog层面都能够持续做出良好的经济决策,管理经济效益。为了统一叫法、便于理解,后面需求责任人都由产品经理充当(类似Scrum框架中的产品负责人)。 产品经理的主要职责总结如下图所示: 图2 产品经理主要职责
需求高效跨项目协同 大型产品开发往往涉及到数千人大兵团规模作战,协作关系与项目运作沟通成本呈指数级上升,基于华为公司跨部门团队理念与实践,Req联结项目、人、工作项,提供无限组织层级、无限功能领域的网状跨项目协作管理能力,实现立体高效协同,加速信息流转。 支持将研发需求下发至下游项目
端到端可追溯 产品研发过程越晚发现风险,修复成本就越高、影响越大,有些风险甚至对企业构成致命的打击,Req打通需求过程数据孤岛,将需求开发过程中产生的设计文档、代码、用例、缺陷等有机串联,形成追溯关系网,让风险提前预警、拦截,问题实时可视,保障研发过程高质量。 端到端可追溯效果图如下:
团队知识空间 在团队知识空间页面可以开始构建团队知识库,沉淀团队知识资产、文档编写、团队事务管理、流程和产品说明书等内容。 团队知识空间分为“我参与的”、“我收藏的”和“全部团队”。 新建团队 新建团队Wiki 在团队Wiki新建文档 在团队Wiki新建表格 新建团队文件库 在团队文件库上传文件
缺陷全生命周期管理 和软件开发生命周期一样,缺陷也是由一系列的阶段和活动组成的,即缺陷同样具有生命周期。缺陷定位越精确,修复成本就越低、影响越小。CodeArts Defect打通缺陷过程监控链条,从缺陷的发现和提出,到开发人员的分析定位、实施修复,再到测试人员的测试和验收,层层把关,
知识库是一个专业的云端知识库,是协同云文档理念下的一款创新产品。愿景成为每个人都爱不释手的知识书写工具,成为人们进行知识创作、沉淀和交流的平台。 提供在线文档创作和文件托管: 在线文档支持富文本和Markdown语法编辑。 文件托管支持如Office等文档的上传和预览。 在线文档支持多人协同编辑,提供
缺陷修复过程可追溯 缺陷的发现和修复过程涉及大量测试和开发工作,CodeArts Defect从源头覆盖缺陷作业流中的所有数据,提供缺陷与用例、代码的端到端追溯能力,让缺陷从产生到闭环的每一步都有据可查。 缺陷支持关联工作项、Wiki、测试计划、测试用例、代码提交记录、代码分支等
服务提供了线上的统计分析功能,不仅提供预置的推荐实践报表,同时支持自定义报表。 支持项目级、企业级自定制仪表盘和自定义报表,提供专业的敏捷精益数据报表,准确掌握项目进度和质量。 在管理项目的过程中支持数据可视化管理,对每次迭代开发进行回顾,总结出下个迭代可以改进的方向。 项目提供
IPD系统设备类项目需求管理流程介绍 IPD系统设备类项目是面向系统设备类产品开发场景的IPD需求管理方法,通过结构化流程、强大的跨项目协作能力来对大型产品开发进行高质高效的管理,主要包含原始需求、系统特性、研发需求、任务、缺陷等内容,任务和缺陷是在需求实现过程中产生的活动和发现的问题。 图1 IPD系统设备类项目
如何开好迭代计划会议 布道师和产品经理,线下交流、布道、技术沙龙。 如何开好站立会议 布道师和产品经理,线下交流、布道、技术沙龙。 如何开好敏捷回顾会议 布道师和产品经理,线下交流、布道、技术沙龙。 智能客服 您好!我是有问必答知识渊博的智能问答机器人,有问题欢迎随时求助哦! 社区求助
的敏捷开发方法论:HE2E DevOps实施框架。 图1 HE2E DevOps实施框架 规划和设计 步骤①和②是业务(或者是客户)与技术之间进行产品规划,梳理产品整体脉络,以及进行产品规划实施设计,并控制需求粒度与拆分的过程。 软件开发的本质是为了解决问题,提供用户价值的,而不
如何在软件项目需求变更频繁的情况下做好有效的需求管理和规划 概述 围绕项目需求变更频繁,如何做好有效的需求管理和规划,本文将从背景、问题分析、解决措施几个方面进行细致讲解。 背景 不管是项目型软件开发还是产品型软件开发,需求变更频繁都是影响研发效能的首要因素,在2019年中国De
系统特性是产品包需求或服务支撑“客户问题(PB)”所具备的重大能力。 产品包需求:由产品经理/规划代表规划出来的、完整一致的、成系列的一组正式需求。 原则上系统特性是产品包的主要卖点(销售亮点)集合,每条系统特性都是满足客户特定商业价值诉求的端到端解决方案。其中,有一部分系统特性是可以通过License控制单独销售。
新员工加入,需要诸多方面的培养(培训),以便能快速进入工作状态。 老员工的离职,导致项目中缺少能了解和掌握关键技术和业务的人员。 员工在工作了一段时间后,对自己的规划有了新的想法,从而想要转换工作方向。 那么,项目负责人应该如何应对这些事件呢? 问题分析 一个项目在从小到大的过
战略举措(Epic) 产品的愿景目标,通过Epic的定义和实现,使产品团队能够把握产品发展方向,并最终获取相应的商业回报。在具体交付中,Epic通常面向产品投资方或决策层,用来组织和呈现特性细节。 特性(FE) 特性是产品包需求或服务支撑“客户问题(PB)”所具备的重大能力。 产品包需求:由
时间盒。 一周到两周 新产品研发团队,产品具有时效性的特点,业务需求迎合市场随时调整,灵活多变,快速响应业务需求,经常性的自检。 两周 团队节奏相对稳定,故事点较大,不好拆分,需要更多的时间评审和返工修正。 三周到四周 节奏稳定,团队稳定,需求稳定,团队有固定的节奏,浪费较少。 了解更多:时间盒
为了减少门店消费者流失,保有市场地位和份额,决定用6个月的时间建立自己的网上商城。 第一步:Epic确定和创建 根据前面的介绍,在进行需求确认的时候先看颗粒度,然后再考虑其承载意义。 此处需要考虑一个问题:一个产品是一个Epic吗?产品的每个业务模块是Epic还是Feature? 产品通常具有战略意义
进。 企业通过对Epic的发现、定义、投资、管理和落地达成,使得企业的战略投资主题得以落地,并获得相应的市场地位和回报。 Epic的粒度比较大,需要分解为Feature,并通过Feature继续分解细化为Story来完成最终的开发和交付。 Epic通常持续数月(months),需要多个迭代才能完成最终的交付。