这一步所产出的其实就是传统软件开发过程中的软件规格说明书。软件规格说明书对于开发人员实现产品功能非常重要，是软件开发中不可缺少的部分。很多人认为敏捷开发不需要文档，其实这是个巨大的误解，但是敏捷开发中的文档确实和传统的需求文档有很多区别： 敏捷开发重视的是文档产生的过程，希望通过

查看更多 →

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

查看更多 →

取措施走出混乱。敏捷看似拥有很快的速度，但变化可以是循序渐进的，采用敏捷的新团队可以较慢的去实现一些新的实践，例如测试驱动开发等。 From:《敏捷软件测试：测试人员与敏捷团队的实践指南》 团队构成 敏捷项目团队是跨职能的，敏捷团队与传统的跨职能团队的区别就是敏捷是向整体团队运作

查看更多 →

质量管理 委外质检 委外到货后会将到货信息推送至系统中的通知消息中自动生成委外质检任务，质检员单击信息通知跳转到委外质检任务页面中。（或者可以单击需要扫描打印出来的包装二维码（批次信息），进行委外质检） 基本信息 单击消息通知的委外入库检的消息，进入到委外质检页面（或者单击工作台的委外入库检功能，进入委外质检页面）；

查看更多 →

质量管理 质量计划 质量检验 父主题： MBM Space界面使用指导

查看更多 →

质量管理 来料检验 功能概述：来料检验包括新增、编辑、查看详情、查询、删除、检验作业、变更记录、打印等功能。 操作人员：质检人员。 路径：质量管理→来料检验。 图1 来料检验 发货检验 功能概述：发货检验包括新增、编辑、查看详情、查询、删除、检验作业、变更记录、打印等功能。 操作人员：质检人员。

查看更多 →

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

查看更多 →

质量管理功能 检测模板 检测模板用于配置各个质量管理环节的质量检测模式。主要包含以下三方面内容： 场景：当前模板在来料检验、过程检验（细分为首检、末检、巡检、成品检验四种类型）、发货检验的哪些阶段使用。 产品/物料：当前模板针对是哪些物料或产品的检验。 项目内容：分别都需要检测哪

查看更多 →

关联ETL任务 关联任务调度支持数据质量任务关联多个数据开发任务。当数据开发任务运行一个周期后，数据质量任务会紧随其后对其产出的数据进行稽核，如稽核结果不达标，则会产生相应告警。如不达标的质量规则中包含强规则，则还会自动阻塞该数据开发任务的下游节点。 图14 关联ETL任务 质量监控报告

查看更多 →

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

查看更多 →

evOps是敏捷在运维侧的延伸”这一说法也不无道理。只是，敏捷与DevOps，都已经不再是原来的那个敏捷和DevOps了；世界变化太快，问题域发生了变化，解决方案域自然也要随之变化。 敏捷的好处是，有一个敏捷宣言，宣告其诞生。敏捷的缺点，也许也是因为有敏捷宣言。敏捷宣言并不应该被

查看更多 →

测试方法：敏捷开发对软件带来的最大影响便是测试了。传统的α（内部测试）、β（交付客户测试）、γ测试（优化处理）方式在采用敏捷开发后几乎不存在了，因为敏捷开发在开发周期内不断的进行测试工作，因此也就没有了在交付做α、β、γ测试时必须停止开发、冻结开发的时间浪费了。 父主题： 持续规划与设计

查看更多 →

DevOps敏捷测试之道 本文介绍企业在敏捷和DevOps的逐步转型过程中，测试如何应对挑战，如何有的放矢进行测试，建立适合产品自身发展阶段、产品特点的敏捷测试能力。 敏捷和DevOps 敏捷和DevOps转型始终是被业务目标和客户需求驱动的。市场竞争环境越来越激烈，新商业模式的

查看更多 →

们会面临一些自动化的开发工具，需要对接自动化平台，需要有一定的开发能力，这对测试人员的自身素质提出了更高的要求。而对开发人员来说，首先是质量意识不足，第二是对于大部分开发人员来说白盒测试用例会写，但是黑盒测试用例不会写。另一方面开发在转型的过程中往往忽视了敏捷价值观，他们的思想还

查看更多 →

提供行业质量管理Know-how知识：产品集成行业质量管理Know-how知识，赋能企业端到端从研发、工艺、供应链、生产、售后全业务流程质量管理，提升企业的质量管理能力和减少产品质量损失； 快速扩展，安全稳定：构建基于iDME元数据的标准化SaaS应用优势，元数据驱动，开发超过30

查看更多 →

应用场景 软件测试和质量管理 提高测试效率和覆盖率 支持不同规模团队敏捷测试流程，需求驱动的测试杜绝漏测、误测。 开发测试高效协作 需求、用例、缺陷双向追溯，不同角色及时高效协作。 多维度质量看板 多维度产品质量看板，全方位评估产品质量，保障产品高效验收。 持续自动化测试 支持接口自动化测试

查看更多 →

在对项目的需求进行简单的规划后，我们就要进入具体的开发环节。而在开发之前，当然需要对即将开展的工作进行计划。 那么，在敏捷的开发模式中，计划是如何制定的呢？ 让我们以CodeArts这个产品为例，一起来看看CodeArts作为一款产品是如何制定它的开发计划的。 两级项目计划 计划是演进的，试

查看更多 →

结合客户自身的业务及IT的特点（敏捷评估的结果），以及ThoughtWorks在金融领域的经验，补充建立敏捷类应用开发项目实施流程 传统开发模式：强调高度安全、稳定、可靠，适用于中后端核心系统的开发。 敏捷开发模式：强调响应、速度，兼顾稳定性，适用于前端客户交互体验相关系统或创新业务系统的开发。 图1 双模模型

查看更多 →

是使用物理看板更适合，两个到三个迭代后，团队自然对敏捷流程有了认识，一些敏捷的习惯已经养成。要引导团队的改善活动，看板从开始到稳定要经历过几次进化，最后达到团队理想的流程管理和最好的可视化状态。这个时候建议再引入电子看板，让敏捷习惯持续传承。 如果团队成员分散到多个地域，毫无疑问

查看更多 →

交付件 交付件模板 团队级敏捷导入 《项目组任命书》 《试点团队敏捷现状分析与成熟度评估》 《敏捷开发转型方案与路标设计》 《敏捷项目管理培训-课件》 《用户故事编写指南-课件》 《敏捷开发标准工作流》 《敏捷开发转型试点总结报告》 《项目组任命书》 《试点团队敏捷现状分析与成熟度评估》

查看更多 →

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

查看更多 →