虽然，一个放之四海而皆准的方法是不存在的，但在更高的层面上，笔者仍然觉得这是可行的。也就是说，管理模型是一致的，但是其中采用的方法可能各有不同。最终目标是唯一的：打造一支可以快速适应变化的高质量团队，并输出高质量的产品！ 用户故事的主要问题 用户故事可以帮助开发团队从用户的角度来理解需求，

查看更多 →

质量管理 来料检验 发货检验 产成品检验 不良记录 父主题： 实施步骤

查看更多 →

产生的价值是千差万别的，有可能我们浪费精力跟踪得来的指标最终只代表了一些数字，除了评估之外不会产生其他附加的价值，对团队的进步也起不到一定的帮助。因此，选择合适的度量指标，获得较高的度量投资回报率对团队起到的帮助的很大的。 缺陷跟踪也是敏捷团队在项目转型过程中一个比较矛盾的地方，

查看更多 →

敏捷回顾 如何玩转每日站会 父主题： Scrum项目最佳实践

查看更多 →

质量管理 应用场景说明 业务流图 如何配置采集模板？ 如何配置审批流及匹配规则 如何创建质检任务？ 如何执行采集？ 如何评审质量检查单？ 如何创建质量检查问题？ 如何生成质检报告？

查看更多 →

质量管理 质量计划 质量检验

查看更多 →

为所有的敏捷开发方法都是广大开发人员在日常的工作中摸索出来的，针对某种特定场景适用的方法。也就是说，以下所列出的敏捷开发方法并不一定适用于你的团队或者你的问题，但是敏捷鼓励所有人按照自己的方式尝试任何的方法，只要这种方法遵循以上价值观和原则，那么它就是一种敏捷方法。 Scrum Kanban（看板方法）

查看更多 →

而DevOps的出现，是为了解决开发与运维之间的鸿沟。前端的敏捷的确是快了，却发现因为Dev与Ops之间的隔阂，无法真正的将价值持续的交付给客户。 开发侧很快，运维侧太稳，这个就是我们常说的开发与运维之间固有的、根因的冲突，即下图中的混乱之墙。开发（尤其是“敏捷”后），求的是快速响应变化；运维，求的是稳定

查看更多 →

数据质量管理 数据结构 数据导入 数据探索 父主题： 数据源管理

查看更多 →

数据质量概览大屏支持及时获悉不同统计周期内的错误告警数据量及环比、告警数量变换趋势及数据质量评分变化趋势、质量综合评分及不同质量指标的综合评分、按告警数量及指令分数对监控任务的排行等信息，从而整体地把握企业的数据质量现状及评估质量治理的重点。 图19 数据质量概览大屏 父主题： 数据开发与治理

查看更多 →

在这两个方面也有一些相应的实践，例如线上拨测，主动线上监控用户的一些行为，并从行为轨迹里面快速捕捉相应的问题，主动推送给相关的责任人，让他去关注并且解决。线上的过程可以通过一些测试手段，不断的反馈给真正的开发人员，让他知道当前产品的整体表现，开发人员就会快速的针对产品作出应对方案。

查看更多 →

观，他们的思想还停留在传统的开发思想，开发做开发的事，质量跟我无关。这些其实并不是技能的问题，更多的还是思想意识上的欠缺。除了人的意识之外，前面还提到了技能意识，流程意识，例如过度依赖黑盒功能测试，我们在流程里面对测试的保障就是依赖黑盒子，结果测试、前端的UI测试，认为做到这些就

查看更多 →

品是如何制定它的开发计划的。 两级项目计划 计划是演进的，试图在项目一开始制定“完备”的甚至是“完美”的计划是不现实的。做计划的目的之一是减少风险，但在信息最少的项目初期阶段做出最重要的决定是不切实际并且风险巨大的。 敏捷计划的模式是渐进式的，一开始只规划一个大的方向，并制定最近

查看更多 →

应用测试金字塔测试设计方式，在接口层次进行功能自动化测试。 和UI测试相比，接口测试开发成本低、运行时间短、运行稳定性高，可以实现快速准确的测试反馈。 持续集成自动化测试 应用持续集成方法，使用流水线实现构建、部署、测试，快速测试及时发现问题，避免带问题的制品进入下个环节或环境。 监控生产环境及第三方依赖API

查看更多 →

图2 支持敏捷开发模式的双模模式 一般来讲，组织在经历了最初敏捷尝试（包括相关专题）之后，通常都会面临敏捷实践的团队级向项目级扩展的问题，在团队级（通常是敏捷实践局限在开发团队内部）无法交付完整的业务价值，也使得敏捷所倡导的业务价值驱动交付较难得以实现。所以，成功的试点很自然会考虑进

查看更多 →

分解为Story的时候，目前正在进行的Sprint需要分的更小更细，将来的Sprint需求（可能是3个及以上）就不需要那样细分。当进行到某个Sprint时，再进行分解，细分成一组更小、更细的条目。 Task是对当前Sprint的Story进行的分解。 所有这些粗略和详细的Story都放在产

查看更多 →

成本低：几乎不需要成本，办公室允许粘贴的玻璃墙、白墙或者白板均可，再准备点便签和笔。 入门快：只要团队想好了怎么做，立刻可以做到工作的可视化，特别适合刚刚使用看板的入门级团队。 更改方便：对于看板的规划，只要有新的想法就可以灵活的变动和快速的实现。比如，列的变化、泳道的变化。同样，特别适合刚刚使用看板的入门级团队。

查看更多 →

《华为云CodeArts实践DevOps开发培训基础课件》 《CodeArts的代码托管操作手册》 《CodeArts代码检查操作手册》 《CodeArts编译构建模块的操作手册》 《CodeArts的测试计划操作手册》 《CodeArts部署模块的操作手册》 《CodeArts流水线模块的操作手册》 《DevOps工程师工作指南》

查看更多 →

AMM），这套成熟度模型能够测量团队不同维度的能力，包括： 需求管理：在软件开发过程中，需求是对客户价值的明确定义。最大化满足客户价值的软件开发过程依赖于实际用户参与开发和以即时制（JIT）为基础的价值排序。 快速响应：“敏捷”本意是具备快速响应客户需求变化的能力，响应的度量从速度和质量两个维度，需求的变更被高响应力淡化。

查看更多 →

《华为云CodeArts实践DevOps开发培训基础课件》 《CodeArts的代码托管操作手册》 《CodeArts代码检查操作手册》 《CodeArts编译构建模块的操作手册》 《CodeArts的测试计划操作手册》 《CodeArts部署模块的操作手册》 《CodeArts流水线模块的操作手册》 《DevOps工程师工作指南》

查看更多 →

crum。Scrum所定义的开发团队规模为5-9人，可以完整交付一个有价值的产品增量。按照Scrum指南的定义，Scrum团队包括了产品负责人、Scrum Master以及开发团队。团队级敏捷导入标准包，基于客户团队管理和软件生命周期模型的现状，结合华为云CodeArts产品，便

查看更多 →