检测到您已登录华为云国际站账号,为了您更好的体验,建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
付过程中的缺陷趋势、严重程度和解决时间等各项数据进行深入分析。缺陷处理情况清晰可见,帮助团队快速识别和解决潜在的风险,准确掌握缺陷修复进度,识别交付各环节短板,让整个产品质量360度清晰透明。 缺陷度量视图默认展示如下信息: 缺陷概览统计:统计当前时刻全部、处理中、已完成、已超期、严重及以上的缺陷数量。
工作项单次数据量最大仅支持300个”。 原因分析 导入的工作项文件中存在有格式的多余空行或者已删除的工作项数据。已删除的工作项数据可能会被识别为空行。 处理方法 在工作项文件中删除之前超出300条数据量的空行后,再重新导入工作项数据。 在工作项文件中删除了几条工作项数据后,如果需
发现问题的版本 end_time Long 工作项结束时间 年-月-日 时:分:秒 done_ratio Integer 完成度 示例:0 '0%'(输入数字0代表完成度为0%的工作项), 10 '10%', 20 '20%' , 30 '30%', 40 '40%', 50 '50%'
一个完整的Scrum迭代流程大概涉及需求规划、迭代计划、迭代开发、敏捷回顾四个阶段,整体流程图如图1所示。 图1 Scrum迭代流程 本文将基于前期识别出来的常见问题,总结出Scrum流程中涉及的主要阶段的最佳实践。 父主题: Scrum项目最佳实践
'可靠性' 17, '网络安全' 18, '可维护性' 19, '其他DFX' 20, '可用性' done_ratio Integer 工作项完成度 end_time String 预计结束时间,年-月-日 expected_work_hours Double 预计工时 id Integer
最大值 20 默认取值:不涉及 done_ratios 否 Array of integers 参数解释:工作项完成度 约束限制:0 '0%'(输入数字0代表完成度为0%的工作项), 10 '10%', 20 '20%' , 30 '30%', 40 '40%', 50 '50%'
release_dev String 发布版本 find_release_dev String 发现发布版本 done_ratio Integer 工作项完成度 expected_work_hours Double 预计工时 actual_work_hours Double 实际工时 tracker
取值范围:最小值 14 最大值 20 默认取值:不涉及 done_ratio 否 Integer 参数解释:工作项完成度 约束限制:0 '0%'(输入数字0代表完成度为0%的工作项), 10 '10%', 20 '20%' , 30 '30%', 40 '40%', 50 '50%'
Bug发现版本号,即Bug发现的产品版本号。 说明: 只有Bug类型工作项才有“发现版本号”。 完成度 设置当前工作项的完成情况。取值为0%~100%。 说明: 父工作项(即工作项存在子工作项)的“完成度”不能手动修改,是根据子工作项设置的完成度自动更新。 故事点 对Story工作量的估算,根据实际情况填写。 附件
间轴来调整其开始和结束时间。 调整工作项的完成度 在甘特图右侧时间轴区域,鼠标移入目标工作项的时间轴上,拖拽时间轴上的可以调整工作项的完成度。 说明: 仅支持调整最底层叶子节点工作项的完成度,工作项下若存在子工作项则不可调整其完成度。 批量操作工作项 勾选目标工作项,可以对工作项进行如下操作:
CodeArts Defect提供华为特有的专业缺陷监控度量指标,让缺陷收敛情况清晰可见,帮助团队快速识别风险,准确掌握缺陷修复进度,洞察交付各环节短板,让整个产品质量360度清晰透明。 商用 产品介绍 4 缺陷修复过程可追溯 缺陷的发现和修复过程涉及大量测试和开发工作,CodeArts
工作项类型的图标,可以根据需要从系统提供的图标中进行选择; 工作项类型图标会展示在工作项页面中,即以此工作项类型新建的工作项标题左侧,用于快速识别不同的工作项类型。 图标颜色 工作项类型图标的颜色,可以根据需要从系统提供的颜色中进行选择。 所属工作项层级 工作项的所属工作项层级,每种
间轴来调整其开始和结束时间。 调整工作项的完成度 在甘特图右侧时间轴区域,鼠标移入目标工作项的时间轴上,拖拽时间轴上的可以调整工作项的完成度。 说明: 仅支持调整最底层叶子节点工作项的完成度,工作项下若存在子工作项则不可调整其完成度。 批量操作工作项 勾选目标工作项,可以对工作项进行如下操作:
事点。 故事点英文名称Story Point,故事点是一种基于敏捷的估算工作量的方法。 故事点综合了交付Story所要付出的努力、开发复杂度、风险,可以简单理解为开发所需要的成本。 斐波那契数列(1,1,2,3,5,8...)是故事点比较常用的计量单位,是一种相对估算法。 如3个
odeArts中完成了工作项的等价交换。 迭代回顾,识别改善点 迭代回顾是一个会议,目标是持续改进流程,根据开发团队的需要改进和制定流程,以提高士气,提高效率,提高工作产出速率。几个迭代下来,需要对这类突发工作进行度量分析,识别改善点,持续改善。虽然提倡响应变化高于遵循计划,但同
法用来辨别什么是合适的团队规模,那就是,如果两个比萨够整个团队成员吃的话,那么这个团队的规模比较适合。 因为两个比萨大小的团队跟家庭的规模相似,站立会的目标可以轻松达成。当团队是家庭规模大小时,人们头脑中就很容易追踪到团队中发生的事情。人们可以很容易地记住每个人每天的承诺,以及每
由于工作项的特殊性,用户故事普遍比较大,可以考虑拆分为更小的故事,或者在每项用户故事下建Task。Sprint的目标可以按Task级别来平衡考量完成度。 4 PO完成标准高 进一步理解PO完成标准,在计划会议上需要明确验收标准,包括AC(Acceptance Criteria) 和 DoD