2023年04月 序号 功能名称 功能描述 阶段 相关文档 1 缺陷全生命周期管理 CodeArts Defect基于华为多年缺陷管理经验，打通缺陷过程监控链条，让团队在整个缺陷生命周期中进行有效的跟踪，提高缺陷管理的效率和准确性，保障高质量的产品交付。 商用 产品介绍 2 缺陷跨组织高效协同 大型产品开发会涉及到彼此依赖的多团队、多模块，其中一环存在缺陷，可能导致整体的失败。CodeArts Defect提供跨项目、跨团队的缺陷提单与跟踪，实现精确高效协同，加速缺陷闭环 。 商用 产品介绍 3 缺陷趋势分析与质量度量 CodeArts Defect提供华为特有的专业缺陷监控度量指标，让缺陷收敛情况清晰可见，帮助团队快速识别风险，准确掌握缺陷修复进度，洞察交付各环节短板，让整个产品质量360度清晰透明。 商用 产品介绍 4 缺陷修复过程可追溯 缺陷的发现和修复过程涉及大量测试和开发工作，CodeArts Defect从源头覆盖缺陷作业流中的所有数据，提供缺陷与用例、代码的端到端追溯能力，让缺陷从产生到闭环的每一步都有据可查。 商用 产品介绍 5 缺陷流程灵活自定义 CodeArts Defect提供了强大的自定义能力，通过可视化流程画布可灵活定制适合您团队的缺陷工作流，满足多项目、多团队的缺陷管理需求。 商用 产品介绍

2022年12月 序号 功能名称 功能描述 阶段 相关文档 1 内置IPD等多种研发模式 提供多种开箱即用的场景化需求模板，支持IPD研发、DevOps敏捷交付、精益看板等多种研发模式。 商用 产品介绍 2 端到端可追溯 需求开发过程中产生的设计文档、代码、用例、缺陷等有机串联，形成需求追溯关系网。 商用 产品介绍 3 基线管理和变更评审 实现版本基线-受控变更-变更评审-变更管理的过程化管理，确保产品研发“做正确的事”。 商用 产品介绍 4 高效跨项目协同 联结项目、人、工作项，提供无限组织层级、无限功能领域的网状跨项目协作管理能力。 商用 产品介绍 5 特性资产管理 提供产品全量特性管理，通过特性树更好管理产品特性，实现产品资产不丢失。 商用 产品介绍 6 客户原始需求管理 提供完整的客户需求采集、价值需求决策、交付与验收流程，让需求进展和动态对客户实时透明。 商用 产品介绍

2023年12月 序号 功能名称 功能描述 阶段 相关文档 1 【缺陷管理】增加「确认」环节和「关闭类型」 【缺陷管理】增加「确认」环节和「关闭类型」，更加贴合用户实际业务 商用 IPD系统设备类项目缺陷流程介绍 2 【导出增强】增加对富文本字段的导出 【导出增强】增加对富文本字段的导出，导出后仅保留基本文字信息 商用 在原始需求列表页中管理原始需求 3 【工作流管理】工作流新增版本管理 【工作流管理】工作流新增版本管理，允许用户自定义编辑多个版本，指定启动特定版本 商用 配置IPD系统设备类项目工作项的状态流 4 自动卷积开关配置 【自动卷积开关配置】支持状态卷积和代码提交相关的自动化规则 商用 配置IPD自运营/云服务类项目的状态卷积自动化规则 5 研发需求协同增强 【研发需求协同增强】支持对已下发的研发需求进行再下发/撤销等操作 商用 用户指南 6 评审管理增强 【评审管理增强】需求评审流程优化，支持单人通过、全部通过、专家表决模式；支持配置专家通过比例；支持跨项目的评审 商用 审批评审单 7 跨项目拆解需求 【跨项目拆解需求】支持原始需求跨项目拆解子需求 商用 原始需求相关操作 8 字段管理优化 【字段管理】增加字段隐藏设置功能模块 商用 配置原始需求的字段模板和描述模板 9 IPD需求模型提供流程流转次数统计 IPD需求模型提供流程流转次数统计，支持缺陷作业过程洞察：提供缺陷激活次数、测试不通过次数统计，直观查看缺陷作业中的异常动向，您也可以通过工作流-流转后置动作和自定义字段，实现您想要的任何工作项的任何流程流转次数统计 商用 用户指南 10 IPD需求模型提供原始需求的批量删除 IPD需求模型提供原始需求的批量删除：根据不同归属项目工作流的配置，提供对归属内部/提给外部原始需求的批量删除 商用 用户指南 11 任务管理优化 支持父子任务双向关联/取消关联，支持关联已有task作为子任务 商用 用户指南 12 评审优化 新建评审时支持填写计划开始时间和计划结束时间，并在用户待办中心中推送评审待办信息，为评审作业框定时间范围，提升评审效率 商用 新建评审单 13 关联项优化 提供关联工作项标签的展示与筛选，支持展示任务关联项的计划完成时间，方便需求管理者把控完成进度，提升多关联项作业场景下的操作体验 商用 用户指南 14 需求协同优化 支持查看上游需求详情，并推送待办消息 商用 在研发需求列表页中管理研发需求 15 模块设置优化 模块配置界面支持拖拽，调整子模块到其他父节点下 商用 添加IPD系统设备类项目工作项的模块类型 16 导出功能优化 支持导出符合筛选条件的工作项 商用 在原始需求列表页中管理原始需求 17 原始需求优化 支持提出项目成员在原始需求的任何阶段继续上传附件 商用 在原始需求详情页中管理原始需求

2024年07月 序号 功能名称 功能描述 阶段 相关文档 1 计划管理优化 计划管理增加里程碑、发布时间线 增加发布、迭代管理视角，支持看板、甘特模式查看需求 计划管理的PI更名为“发布” 商用 配置IPD系统设备类项目计划 2 E2E追溯优化 增加追溯图谱，以图谱形式展示追溯关系 商用 用户指南 3 缺陷支持跨项目协同 新增缺陷跨项目协同，支持给其它项目提交缺陷，并分类展示 商用 IPD系统设备类项目缺陷流程介绍 4 内置状态卷积规则 IPD系统设备类项目和IPD独立软件类项目内置了5类状态卷积规则，用户可以选择是否启用 商用 配置工作项的状态卷积自动化规则 5 系统特性和任务支持自定义工作流 系统特性和任务支持自定义工作流 商用 配置IPD系统设备类项目工作项的状态流 6 特性优化 特性更名为系统特性，特性树与系统特性页面归一，取消子特性 商用 在IPD系统设备类项目中管理系统特性

基线管理和变更评审 产品从规划到上市要经过复杂的研发过程，Req工具的IPD需求管理提供了基线评审和变更管理能力，实现版本基线-受控变更-变更评审-变更管理过程，让基线变更如门禁一样，达到阈值才能启动下一步，确保产品研发“做正确的事”。 支持将发布/迭代基线化，基线后，不能再修改当前发布/迭代的标题、描述、计划开始时间、计划完成时间、计划工作量，同时当前发布/迭代下的研发需求将会同步基线。 已基线需求若需变更，需通过变更评审。 基线管理与变更评审效果图如下： 图1 基线发布计划 图2 编辑基线锁定字段 父主题： 功能特性

项目级权限 通过需求管理创建的所有项目都支持基于本项目的权限设置，且每一个项目的权限设置相互独立。 在项目管理中，角色包含三大类：项目管理者（项目管理员、项目经理、测试经理、产品经理、系统工程师）、开发者（Commiter、开发人员、测试人员、参与者）、浏览者和运维经理。 项目管理员：项目的创建者。 项目经理：项目开发管理员。 测试经理：项目测试管理员。 产品经理：项目的需求分析管理者。 系统工程师：项目的架构分析管理者。 Commiter：参与项目开发的人员。 开发人员：参与项目开发的人员。 测试人员：参与项目测试的人员。 参与者：参与项目指定工作处理的人员。 浏览者：关注或浏览项目内容的成员。 运维经理：参与项目维护工作的成员。 表3 Scrum项目默认角色权限说明 模块 权限项 项目管理员 项目经理 产品经理 系统工程师 Committer 测试经理 开发人员 测试人员 运维经理 参与者 浏览者 项目基本信息 归档 Y Y N N N Y N N N N N 类型转换 Y N N N N N N N N N N 规划 新建 Y Y Y Y Y Y Y Y Y Y N 编辑 Y Y Y Y N Y N N N N N 删除 Y Y Y Y N Y N N N N N 工作项 新建（复制） Y Y Y Y Y Y Y Y Y Y N 编辑 Y Y Y Y N Y N Y N N N 删除 Y Y Y Y N Y N N N N N 导入 Y Y Y Y Y Y Y N Y Y N 导出 Y Y Y Y Y Y Y N Y Y N 归档/取消归档 Y Y Y Y N Y N N N N N 上传文件 Y Y Y Y N Y N N N N N 迭代 新建 Y Y Y N N Y N N N N N 编辑 Y Y Y N N Y N N N N N 删除 Y Y Y N N Y N N N N N 状态设置 Y Y N N N Y N N N N N 报表 新建报表 Y Y Y Y Y Y Y N Y Y N 编辑报表 Y Y N N N Y N N N N N 删除报表 Y Y N N N Y N N N N N 移动报表 Y Y N N N Y N N N N N 导出报表 Y Y N N Y Y Y N Y Y N 新建分类 Y Y Y Y Y Y Y N Y Y N 重命名分类 Y Y Y Y Y Y N N N N N 移动分类 Y Y N N N Y N N N N N 删除分类 Y Y N N N Y N N N N N 自定义 工作项自定义设置 Y Y Y Y N Y N N N N N 领域设置 Y Y Y Y N Y N N N N N 通知设置 Y Y N N N Y N N N N N 模块设置 Y Y Y Y N Y N N N N N 工时类型设置 Y Y N N N Y N N N N N 自动化设置 Y Y N N N Y N N N N N 文档 上传文档/创建目录 Y Y Y Y N Y Y Y Y Y N 编辑文档属性/重命名目录/移动目录 Y Y N N N Y N N N N N 删除文档/目录 Y Y N N N Y N N N N N 下载文档 Y Y Y Y N Y Y Y Y Y Y 预览文档 Y Y Y Y N Y Y Y Y Y Y 仪表盘 新建仪表盘 Y Y N N N Y N N N N N 编辑仪表盘 Y Y N N N Y N N N N N 删除仪表盘 Y Y N N N Y N N N N N 解锁仪表盘 Y Y N N N Y N N N N N 表4 看板项目默认角色权限说明 模块 权限项 项目管理员 项目经理 产品经理 系统工程师 Committer 测试经理 开发人员 测试人员 运维经理 参与者 浏览者 项目基本信息 归档 Y Y N N N Y N N N N N 类型转换 Y N N N N N N N N N N 工作项 新建（复制） Y Y Y Y Y Y Y Y Y Y N 编辑 Y Y Y Y N Y N N N N N 删除 Y Y Y Y N Y N N N N N 导入 Y Y Y Y Y Y Y Y Y Y N 导出 Y Y Y Y Y Y Y Y Y Y N 归档/取消归档 Y Y Y Y N Y N N N N N 上传文件 Y Y Y Y N Y N N N N N 迭代 新建 Y Y Y N N Y N N N N N 编辑 Y Y Y N N Y N N N N N 删除 Y Y Y N N Y N N N N N 状态设置 Y N N N N N N N N N N 报表 新建报表 Y Y Y Y Y Y Y Y Y Y N 编辑报表 Y Y N N N Y N N N N N 删除报表 Y Y N N N Y N N N N N 移动报表 Y Y N N N Y N N N N N 导出报表 Y Y N N Y Y Y Y Y Y N 新建分类 Y Y Y Y Y Y Y Y Y Y N 重命名分类 Y Y Y Y Y Y N N N N N 移动分类 Y Y N N N Y N N N N N 删除分类 Y Y N N N Y N N N N N 自定义 工作项自定义设置 Y Y Y Y N Y N N N N N 领域设置 Y Y Y Y N Y N N N N N 通知设置 Y Y N N N Y N N N N N 模块设置 Y Y Y Y N Y N N N N N 工时类型设置 Y N N N N N N N N N N 自动化设置 Y N N N N N N N N N N 文档 上传文档/创建目录 Y Y Y Y N Y Y Y Y Y N 编辑文档属性/重命名目录/移动目录 Y Y N N N Y N N N N N 删除文档/目录 Y Y N N N Y N N N N N 下载文档 Y Y Y Y N Y Y Y Y Y Y 预览文档 Y Y Y Y N Y Y Y Y Y Y

需求变更情况下的移动 不接受变更 当一个Sprint的Sprint Backlog和Sprint目标确认后，为了保持团队在很短的时间内，全力以赴的向着Sprint目标冲刺，一般情况下不接受PO提出的需求变更。在很短的周期内，PO是有责任负责整理好Sprint Backlog的，进一步说，PO至少应该整理好接下来1-3个Sprint需要做的Product Backlog，然后按优先级，挑选出最近一个Sprint的Product Backlog形成Sprint Backlog，因此经常性的需求变更建议团队不接受，另一方面也是一个好习惯的养成，促进PO对需求的把控能力。所以这种情况下，团队正常移动看板中的卡片就好。 拥抱变更 完全拒绝需求变更是不现实的，有的时候高优先级的需求一定要满足变更的要求。比如，有市场时效性的，本Sprint不能完成，不能抢占市场先机，但变更需要遵循“NO CHANGE”原则。接到需求变更后，首先不是直接接受或者拒绝，而是先对需求进行分析，分析对当前迭代的影响。一般分析结果为以下几种情况： 无价值需求 与PO沟通协商，对于无价值需求果断拒绝，看板中的卡片不做任何移动。至于这些无价值的需求怎么来的，情况比较多，这里不做讲解了。 变更少，影响小的需求 高优先级的，对Sprint影响小的需求变更，可以柔和接纳，但要评估工作量，做等价交换。简单说，就是把未做的优先级低的需求从看板中替换出来，移动到Product Backlog中，这也是Product Backlog Refinement的过程，然后看板中加入高优先级需求的卡片就好。如果是交换已经产生工作量的需求就需要分情况处理：一种是移回到Product Backlog列，这种情况多于以完成特性需求为目标，更符合敏捷。另外一种是移到Done列，这种情况多见于物理看板中对统计度量数据比较看中的团队，团队需要对工作量进行有效统计。第二种情况在有些电子看板中也可以灵活统计来满足团队需求，那么就可以直接移动到Product Backlog列。 变更多，影响很大的需求 高优先级的，对Sprint影响很大的需求变更，需要停止当前Sprint，重新规划新Sprint。这里的影响很大情况是指当前Sprint中的需求可能再做下去也没有价值，这时果断停止当前Sprint，另外一种情况也可能是变更的需求本身确实需要很大的工作量才能完成，也需要停止当前迭代。这时根据最新的Sprint Backlog布置看板中的卡片就好。

解决措施 需求管理服务使用 统一身份认证 服务（Identity and Access Management，简称 IAM ）管理整个租户下多项目的统一权限。在单个项目内，基于具体项目设置进行项目内的权限管理。需求管理的权限管理分为两种，分别是云服务级和项目级。 云服务级：服务级的权限通过统一身份认证服务设置。IAM是华为云提供权限管理的基础服务，无需付费即可使用，您只需要为您账号中的资源进行付费。 关于IAM的详细介绍，请参见IAM产品介绍。 云服务级权限详情请参见需求管理云服务级权限介绍。 项目级：项目级的权限通过需求管理服务设置。项目级权限详情请参见项目级权限。 更多关于成员的相关内容请参见管理CodeArts项目级权限。

问题分析 如何使用IAM来控制权限？ 通常一个IAM主账号下，可以创建多个软件开发项目。默认情况下，只有IAM主账号默认可以设置是否能允许子账号创建项目，只有IAM主账号能查看所有项目和成员等。在某些企业场景下，IAM主账号可以通过IAM的细粒度权限管理，设置部分子账号可以代替IAM主账号的设置权限。 项目成员的角色有哪些？ 通过项目管理创建的所有项目都支持基于本项目的权限设置，且每一个项目的权限设置相互独立。 在项目管理中，默认项目角色包含以下几大类： 项目管理员：项目的创建者。 项目经理：项目开发管理员。 测试经理：项目测试管理员。 产品经理：项目的需求分析管理者。 系统工程师：项目的架构分析管理者。 Committer：参与项目开发的人员。 开发人员：参与项目开发的人员。 测试人员：参与项目测试的人员。 参与者：参与项目指定工作处理的人员。 浏览者：关注或浏览项目内容的成员。 运维经理：参与项目维护工作的成员。 如何将成员添加到项目并分配角色？

了解更多：成员迟到的解决方案 对于经常有人迟到的现象，团队成员在回顾会议上可以认真分析原因，重新征求团队成员意见，为什么每日站会的开始时间一定是早晨九点，其它时间是否可以，是否有什么困难，团队成员共同找出问题原因并做出决定。 促进团队成员需要自觉按时到场的意识，尊重别人的意识。会议主持人要按照预先定的时间、地点开始会议，而不管是否还有人没到场。有人迟到不要重新讲解他们错过的开会内容，否则会传达可以迟到的信号。 对于迟到的人员要有一些惩罚措施，比如红包、做俯卧撑、全体下午茶等。惩罚措施和数量由团队成员事先共同商定。如果是红包，如何支配由团队共同决定。相比别人给你的规则，大家更愿意执行自己提出的规则，守自己的承诺。 如果说惩罚措施毫无约束力，那就把惩罚做到可视化。比如在白板中规划出一个特定区域，每迟到一次就把照片贴上去，次数累加。这个特定迟到的区域是迟到信息的扩大器，让更多的人看到。 对于经常迟到的人需要谈话，试着理解他有哪些问题，是否有真正的困难，关心团队成员，大家一起帮助解决困难。 如果迟到现象严重，可能不是团队能解决的问题了，可以试着从公司政策方面施压，严格执行公司的考勤制度，但其实不符合敏捷的自管理思想，不是真正解决问题的方法。 总结下解决迟到现象应该关注以下因素： 分析原因，关心成员，共同决定。 同一时间，同一地点，准时开会。 有人迟到，不重复同步信息。 建议小惩罚机制。 理解迟到原因，是否有困难。

解决措施 如何玩转站会？我们按照如下思路学习下。 图2 站会学习思路 理解站会价值 团队每天站着召开的短时间会议称之为每日站会。每日站会是团队对每天工作检视和调整，提前进行自组织。 通过站会团队每个人可以了解全局，知道发生了什么事情，实现冲刺目标的进展如何，对当天的工作是否需要修改计划，有什么问题或者障碍需要处理。每日站会是一个检视、同步、适应性制定每日计划的活动，以帮助自组织团队更好地完成工作。 有些团队认为每日站会是解决问题的，是传统意义上向项目经理汇报状态的会议，其实都是不准确的，或者说误解了它的核心意义和价值。 每日站会对于让团队成员每天集中精力在正确的任务上是十分有效的。因为团队成员在同伴面前当众作出承诺，所以一般不会推脱责任。给团队成员一种精神激励，要对每日的工作目标信守承诺。每日站会还可以保证Scrum Master和团队成员可以快速处理障碍，培养团队文化，让每个人意识到我们是“整个团队在一同战斗”，一些没有使用敏捷的组织有时候也同样采用每日站会。 归纳站会的价值和意义，以及误解： 图3 站会的价值、意义和误解 明确正确站会 正确的站会应该怎么开呢？我们一起学习下。 对于每天的工作，为了提前进行自组织，团队成员准时围绕着白板前站立（增加仪式感）。 图4 站会示意图 团队成员在站会上需要轮流发言，回答如下三个问题： 我昨天做了什么？（从上次站会到现在，我做了什么？） 今天计划做什么？（在下次站会之前，我会做什么？） 我遇到了哪些问题和障碍？（哪些问题和障碍阻止了我的工作或使我的工作放缓？） 这简单的三个问题可以促使团队成员每天都要检视自己的工作、制定自己的工作计划、获得清除障碍的帮助以及对团队做出承诺。如果团队按正确的方式开站会，进行得好的话，可以达到如下效果： 图5 站会目标 共济压力 健康的敏捷团队都会有共济压力。所有的团队成员都承诺要一起完成冲刺的工作。这就使得团队成员之间相互依赖并且对彼此负责。如果一个团队成员连续几天都做相同的事情，并且没有进展，显然缺乏前进的动力，而其它团队成员不能视而不见。因为他未完成的工作会变成其他成员的障碍。 细粒度的协作 在站立会中，团队成员的交流应该快速而且有重点。举例，当一个成员说完今天计划做什么后，另外一个成员可以会说：“哦，原来你今天计划做这个啊，这就意味着我要调整我的工作优先级，没关系，你按照你的计划做吧，我可以调整。很高兴你说了这些。”这种细粒度的协作使得团队成员知道他们之间如何及何时仰仗对方。一个敏捷团队应该追求高效、零等待，避免等待浪费。 聚集少数任务 在站会期间，团队中的每位成员都可以知道哪些工作正在进行，哪些工作已经完成。健康的团队应该关注事情的完成，也就是说任务不能一直处在进行中。在站会中，团队需要确认哪几个少数任务是当前的焦点，这样团队就可以尽快把焦点任务做完。换句话说，做完10件事，远比正在做100件事儿更有意义。 每日承诺 在站会上，团队成员需要对团队做出承诺。这样团队成员就知道敏捷交付什么成果并如何保证彼此负责。 提出障碍 其实在敏捷中任何时间都可以提出障碍，但是站会是一个黄金时刻，团队成员可以停下来认真思考“有什么事情阻碍了我或让我的工作放缓了”。 最佳实践和关键点 通过大量实践总结出一些能够帮助开好站会的关键点，也许这些关键点并不是全适用，所以还是要根据现实情况做出合适自己团队的选择和裁剪。这些关键点，我们称之为“站会18 key”。 站会18key按照人（People）、过程与方法（Procedures and methods）、工具与设备（Tools and equipment）划分，帮助大家记忆和学习。 图6 站会18key Key 1: 主持人 会议主持人（比如Scrum Master，也可以团队成员轮班，轮流感受下站会的节奏）确保会议的举行，并控制会议时间，团队成员进行简短有效的沟通。 Key 2: 两个比萨大小的团队 在《Scrum敏捷软件开发》一书中，作者麦克·科思提出了一个简单的方法用来辨别什么是合适的团队规模，那就是，如果两个比萨够整个团队成员吃的话，那么这个团队的规模比较适合。 因为两个比萨大小的团队跟家庭的规模相似，站立会的目标可以轻松达成。当团队是家庭规模大小时，人们头脑中就很容易追踪到团队中发生的事情。人们可以很容易地记住每个人每天的承诺，以及每个人对于其他成员或团队成果的责任。Scrum中也建议团队规模不要太大，一般为7-9人左右。 最后再强调一点，并不是要求团队一定要按以上18key进行开站会，18key只是在很多实践中总结出来的一些经验，曾经解决过很多问题。对于每个具体团队需要结合实际情况进行选择应用18key。 Key 3: 限制发言 团队外成员也可以参与，但没有发言权。在每日站会中，只有为了实现冲刺目标面全力投入的人应该发言，对于参与者，应该作为旁观者。 Key 4: 预留缓冲时间 建议开发团队在上班时间后的半小时或者1小时后开每日站会。这样可以给例行工作（如查看邮件）提供一些缓冲时间。晚点开会还可以给开发团队一点时间来检查前一天的工作（比如，前一天晚上开始运行的自动化测试工具所生成的缺陷报告）。 Key 5: 同时同地 每日站立会议应尽可能在同一时间、同一地点召开，建议在团队的可视化的任务板前面召开。同一时间和地点也可以有效帮助团队成员形成固有的节奏，不用浪费时间再找地点和确认当天的开会时间。 Key 6: 准时开始 所有的团队成员需自觉按时到场，会议主持人要按照预定的时间按时开始会议，而不管是否有人还没到。对于迟到的人员要有一些惩罚措施，比如缴纳罚金或做俯卧撑等。惩罚措施和数量由团队成员事先共同商定，如果是罚金，如何支配也由团队共同决定。如果团队成员就是不自觉按时到场怎么办？关于更多这方面的解决方案请参考下面的了解更多中的“了解更多：成员迟到的解决方案”。 Key 7: 站立开会 团队成员一定要站着开会，这也是会议的名字叫站立会议的原因。站着开会确实比坐着开会简明扼要，让人更想快一点结束会议，开始一天的工作。坐下容易使人放松，精神不集中，不易控制时间。 Key 8: 强调站会目的 经常强调站会目的，特别适合刚刚启用站会的团队。可以由Scrum Master来强调，如果没有Scrum Master也可以由其它Leader（轮职的主持人也可以）来强调。然后询问团队成员对站会的意见及得到的成果，几次以后，团队成员可能选择目标声明作为每天的度量，在每次站会之后，团队成员对自己的表现做出相应的评价，是一种强有力的自我管理工具。 Key 9: 聚焦三个问题 站会期间，团队成员就说那典型的三个问题（昨天…今天…障碍是…），其它事情不说。只讨论已完工和即将开始的工作，或者在这些工作中碰到的问题和障碍。目的不是向领导汇报工作，而是团队成员之间相互交流，以便共同了解项目情况和共同解决问题。 Key 10: 眼神支持 这是一个好玩的游戏：当一个人站在前面发言时，要求其他团队成员都直视发言人，并进行眼神交流。别让发言人抓到你在看别处。这个游戏帮助发言人的发言简洁，同时可以加强成员对发言人所讲内容的理解。这样可以帮助团队加速完善每日计划。 Key 11：严格时间盒 站会是开发团队的一个时间盒限定为 15 分钟的事件。 时间建议不要太久，对于5-9人的团队来讲15分钟的会议时间足够。 Key 12: 会后讨论 某位团队成员在发言期间，其他人员应认真倾听，如有疑问可简短确认，但不应做过多讨论。如果对某位成员的报告内容感兴趣或需要其他成员的帮助，任何人都可以在每日站立会议结束后即刻召集相关感兴趣的人员进行进一步的讨论。 Key 13: 问题风险跟踪 将站会成员遇到的问题和风险做概要的记录（不必详细，只要说明重点即可，不需要在记录上花费更多的时间），然后保留到知识库，或者方便大家跟踪的地方。此目的是确保这些问题和风险得到了闭环（例如，问题和风险可以会后按排专题讨论、跟踪，直到关闭）。 Key 14: 回顾改善 本身每日站会就是最小化的戴明环（PDCA），另外团队在回顾会议上时也可以对站会开的效果进行回顾，哪些地方做得好，哪些地方做得不好，有哪些改善点可以在下一轮迭代中改善等（站会只是回顾会议中一个回顾点，如果没有问题不用做专题回顾）。 Key 15: 发言棒 站会时可以利用一些小道具来保证会议不会超时。我会找一只笔或者一个娃娃（女生多的团队）作为发言棒仍给一位成员，让他拿着发言棒陈述完“三个问题”，然后将其交给下一位。我会找一只笔或者一个小物件作为发言棒仍给一位成员，让他拿着发言棒陈述完“三个问题”，然后将其交给下一位。没有拿发言棒的成员不允许发言。如果有人用时过长，就及时打断，并要求将发言棒传给下一个人。 Key 16: 冲刺待办列表 站会中，成员在发言时可以利用冲刺待办列表来检视当前工作项的完成状态。冲刺待办列表记录了团队成员工作的进展，需要每天更新并跟踪。电子化的冲刺待办列表更能很好的解决异地团队开站会思路不聚集的问题。发言人在讲那“三个问题”时，同步可以展示冲刺待办列表给团队。 CodeArts冲刺代办列表演示如下： 图7 CodeArts冲刺代办列表 Key17: 任务看板 在站会期间，通过任务板，团队中每一个人都可以知道哪些工作正在进行，哪些工作已经完成。团队关注事情的完成，一直处于进行中的任务为被发现，成为当前的焦点，这样团队就可以尽快把这些焦点问题解决掉。 Key 18: 燃尽图 燃尽图是将进展和剩余工作情况可视化的有力工具。一般竖轴表示剩余工作量（小时、故事点或工作项个数），横轴表示冲刺时间（一般单位为天）。 图8 燃尽图 开站会时，发言人可以利用燃尽图来做进展讲解。燃尽图让所有团队成员一眼就可以看出冲刺的状态，进展情况非常清楚，看出工作是否在按计划进行，状态是否良好。这些信息可以帮助团队确定是否可以完成预定数量的工作项，并在冲刺早期做出明智的决定。使用燃图易达成如下效果： 高可视性，直观展示进度情况和剩余工作。 快速识别风险。 帮助团队建立信息，了解自己的能力。 了解团队成员工作步调。 了解团队冲刺计划。 和任务墙能非常高效地匹配使用。 关于18key，并不是站立会议时要把所有18key都要执行一遍，这里的18key只是提供了一些参考实践和关键点，18key来源于大量的实践，也解决过团队站会的问题，所以大家在站会遇到了问题时，可以先想到这个18key，然后选择适合自己团队的key。举一个例子，这里有四个key是关于工具的，这些工具我们都要使用吗？不一定都要使用。敏捷宣言里提到“个体和互动高于流程和工具”，工具是为团队服务的，不是团队的负担，更不能被工具所绑架。所以团队一起选择适合的，才是正确的做法。

问题分析 关于站会的问题大致分为两种场景： 场景一：团队非常清楚应该开站会，认识到站会确实有一些价值，但是对于目前的站会状况不是很满意，如何玩转站会是团队关心的。对于这类的团队，问题的根源在于不是非常清楚站会的核心价值，以及不知道怎么样实践，团队更需要一些具体的措施来帮助他们更好的开站立会议。 场景二：团队在试着开站立会议，不知道站立会议有什么价值，好像开和没开没有什么区别。针对这种情况，是因为团队没有尝到站会的价值带来的好处，团队没有概念，同样缺乏最佳实践。 综上，不管是第一种还是第二种情况，都需要对站会的价值进一步理解，也就是为什么要开站会，它的意义是什么？然后，都需要明确正确的站会应该怎么样开？最后，都需要一些最佳实践和关键点来帮助团队开好站会。

背景 企业的一些项目团队每天都开站会，但是效果不理想，好像是形式化的内容，并没有起到什么实质的作用。比如，开完站会后，成员继续做着手头的工作，成员依然只关心自己的工作，其他人员的工作完全不了解，好像站会并没有带来什么效果。再比如，开站会本身也有很多问题：会议超时、成员迟到、成员注意力不集中等，具体常见问题如图1所示。 图1 站会常见问题 如何正确的开站会？站会的意义在哪里？可以不开站会吗？这些问题一直困惑着不少的团队。

问题分析 首先，相对于传统开发模式的指派开发任务，我们需要知道为什么在敏捷开发中是领取任务。在敏捷中，不管是敏捷宣言还是Scrum指南，都没有指派（assign）一词，而是使用了一个术语自组织，如下： 最佳的架构、需求和设计出自于自组织的团队（敏捷宣言12项原则）。 自组织团队自己选择以何种方式来完成工作，而不是由团队之外的人来指导（Scrum指南）。 开发团队是自组织的。没有人（即使是Scrum Master）有权告诉开发团队应该如何把产品待办列表变成潜在可发布的功能增量（Scrum指南）。 那么“自组织”是什么呢？ 从字面的意思来理解，自组织就是：安排分散的人或事物使其具有一定系统性或组成一个整体，而安排的人就是安排者自己。在敏捷开发中，自组织团队就是具备自我管理、自我驱动、自我学习等能力的敏捷开发团队本身，这样的团队一般具备如下特点： 团队成员自己“拉”工作，不是被动等待领导分配工作。 团队作为一个整体管理工作。 团队仍然需要辅导和指导，但不需要指挥和控制。 团队成员彼此沟通紧密，互通有无。 团队主动发现和提出问题并共同解决。 团队不断提高自己的技能，鼓励探索和创新。 更多关于自组织的相关内容不在本文的范围内，如感兴趣请参阅参考文档。 从敏捷宣言和Scrum指南关于任务的工作方式上来看，在我们践行敏捷的时候，主要发挥的是开发团队自身的主观能动性，开发团队由原来的控制性转变成了自组织性，而开发任务也就由原来的指派变为了领取。这样的好处是，领取任务就是发挥了人的主动性，而自主性是人们从事创造性和解决问题的动力之一，良好的自我组织能给团队和个人带来高绩效、出色的工作成果以及喜欢的工作环境。另外，每个人都是最了解自己的，也擅长为自己分配任务，相对于传统的指派开发任务所带来的易主观臆断、分配不当等更具有合理性。 然后，回到“计划会议认领任务的时候，有几个任务没人认领怎么办？”这个问题上。 在此之前需要先澄清的一个观点：在计划会议中，不一定非要全部领取完开发任务。在Scrum指南中指出“领取工作在Sprint计划会议和Sprint期间按需进行。”可以理解为，在每日Scrum站会上基于目标领取任务。另外，Mike Cohn也表示过，不建议在计划会议中领取开发任务，这样可能会导致目标由团队变为了个人，进而违背了敏捷的本意，降低了灵活性。 一般来说，开发任务没人认领的原因主要有： 开发任务的难度大：当开发任务比较难以解决，超出了团队大部分成员的能力时，团队成员可能会存在担心加班加点而不愿意认领。 开发任务超范围：当开发任务的内容超出团队成员所掌握的范围时，如开发不会测试，就可能会出现“我是想认领的，但能力有限”的情况。 担心受到他人指责：工作内容存在一定的挑战性，担心由于自己没有做好，导致团队目标没有达成而受到指责。 那么应该如何解决呢？

解决方案 在一个敏捷Scrum团队中，Scrum Master扮演着重要的角色，该角色一部分的作用就是要帮助团队成为自组织型团队，以便让团队能以积极的心态去面对冲刺的开发任务。此外，当出现任务没有人愿意认领的情况时，首先Scrum Master应该帮助团队弄清楚没有人认领的原因是什么再对症下药，下面基于分析中的三种情况分别给出解决措施。 开发任务难度大 对于开发任务难度大的情况，Scrum Master应该组织团队进行有效的任务分解，使用探针Spike技术，探索出解决措施以降低任务的难度，再由团队去认领；或者鼓励技术能力较一般的成员和技术大牛通过结对编程的方式来一同认领任务。 在华为云CodeArts中，可以对该类难度大的用户故事通过子工作项的方式进行拆分，同时在基本信息中通过设置处理人和抄送人的方式以记录结对编程的人员配对情况： 图1 Story内容介绍 除此以外，在每日Scrum站会的时候要留意和了解该开发任务的情况，进行风险评估，如有问题及时帮助协调解决。在回顾会议中，应对该类情况进行分析并能输出基于团队的一套标准工作方式方法，然后将解决方案记录在团队知识库中，华为云CodeArts提供了知识库的功能，可以为团队很好的整理和记录工作方式，如图2所示。 图2 任务认领说明 开发任务超范围 敏捷提倡的团队是跨职能团队，但是团队的跨职能并不意味着一个人能做所有的事情，我们希望的跨职能团队往往是由掌握多项技能的T型人才（每个成员在一个专业领域具有深度，而在其他领域具有广度）所组成的。首先需要Scrum Master能够和团队整理和维护成员技术矩阵，把个人技能掌握情况对团队公开（知道团队欠缺什么、知道可以和谁学等），然后定期组织技术分享等活动以帮助团队成员学习（主要以学习一项新的技术后的分享方式），这样可以在一定程度上提升成员在冲刺中愿意领取其他任务的热情。另外，还可以由专长成员和意愿成员组队，采用结对编程的方式领取任务，以实现个人技术的扩充。团队成员的T型能力建设，不仅仅能让团队领取任务的时候有更多的选择，也提供了成员的backup能力，减少无人认领的情况发生。此外，同样也需要Scrum Master留意日常评估风险和引导团队回顾该事项并维护团队知识库。 担心受到他人指责 工作内容存在一定的挑战性，担心由于自己没有做好，导致团队目标没有达成而受到指责。Scrum Master应该对团队贯彻以团队为整体的思想，并指导和强调Scrum的价值观，尊重团队的每一个成员的背景、经验，也包括开发任务的选择，还要鼓励成员能有勇气去选择和尝试。在实际的工作中，我们可以通过在墙上、白板等贴上标语（如“尊重他人”、“只有团队没有个人”等）的方式，让团队从思想意识方面发生转变，慢慢敢于去领取有挑战性的任务。此外，Scrum Master要充分保护好成员对有挑战工作认领的热情。如防止在回顾会议上出现指责和批斗的情况，回顾和总结永远应该聚焦的是做事的方式方法而不是对人的苛刻和指责。