华为云用户手册

导入特性树 访问CodeArts Req服务首页。 在项目主页，选择“特性树”。 单击“导入特性树”，弹出“导入”窗口。 图3 导入特性树 单击“下载导入模版”链接。导入模板文件显示在页面右上方，可保存到本地填写数据。模板文件命名规则：项目名称+“-”+模块名称（如特性）+导入模板。 填写“特性树-导入模板”页签中的字段。参数填写规则请参见模板文件中“导入说明”页签。 通过拖拽或单击图标，选择一个需要导入的文件。 单击“导入”，导入成功。 在特性树列表中可以查看到导入的特性集。

源端和目标端实例规格检查 检查源端和目标端RocketMQ实例的规格是否匹配。 原因：源端和目标端RocketMQ实例的节点数量不一致，请检查源端实例和目标端实例的规格信息。 解决方案：检查配置专享版事件流作业的第二步，即“源和目标对象配置”页面中配置的源端和目标端RocketMQ实例的节点数量是否一致，若不一致，请修改源端或者目标端实例，使二者保持一致。 检查源端和目标端RocketMQ实例的规格是否匹配。 原因：源端和目标端RocketMQ实例的实例类型不一致，请检查源端实例和目标端实例的规格信息。 解决方案：检查配置专享版事件流作业的第二步，即“源和目标对象配置”页面中配置的源端和目标端RocketMQ实例的类型是否一致，要求都是集群或者都是单机，若不一致，请修改源端或者目标端实例，使二者保持一致。

源端和目标端实例版本检查 检查源端和目标端RocketMQ实例的版本是否符合要求，当前要求RocketMQ实例版本在5.x和4.8.0中，版本不在匹配名单中则提示告警。 原因一：源端RocketMQ实例版本不支持，请选择符合要求的实例。 解决方式：返回配置专享版事件流作业的第二步，即“源和目标对象配置”页面，重新选择符合实例版本要求的实例作为源端实例。 原因二：目标端RocketMQ实例版本不支持，请选择符合要求的实例。 解决方式：返回配置专享版事件流作业的第二步，即“源和目标对象配置”页面，重新选择符合实例版本要求的实例作为目标端实例。 检查源端和目标端RocketMQ实例的版本是否一致，版本不一致则提示告警。 原因：源端实例和目标端实例的版本不一致，请检查源端实例和目标端实例的版本。 解决方式：检查配置专享版事件流作业的第二步，即“源和目标对象配置”页面中配置的源端和目标端RocketMQ实例的版本是否一致，若不一致，请修改源端或者目标端实例，使二者保持一致。

目标端连通性检查 检查事件流作业所在运行时机器是否能正常连接到目标端RocketMQ实例。 原因一：无法连接目标端RocketMQ实例，请检查网络配置是否正确。 解决方案： 进入RocketMQ的控制台页面，检查目标端实例状态是否正常。 检查事件流集群创建页面中配置的vpc和子网是否与目标端RocketMQ实例网络畅通。 原因二：无法连接目标端RocketMQ实例，请检查填写的实例信息是否正确。 解决方案： 进入RocketMQ的控制台页面，检查目标端实例状态是否正常。 检查事件流集群创建页面中配置的vpc和子网是否与目标端RocketMQ实例网络畅通。 检查配置专享版事件流作业的第二步，即“源和目标对象配置”页面中配置的目标端RocketMQ实例的用户名和密码是否正确。

源端连通性检查 检查事件流作业所在运行时机器是否能正常连接到源端RocketMQ实例。 原因一：无法连接源端RocketMQ实例，请检查网络配置是否正确。 解决方案： 进入RocketMQ的控制台页面，检查源端实例状态是否正常。 检查事件流集群创建页面中配置的vpc和子网是否与源端RocketMQ实例网络畅通。 原因二：无法连接源端RocketMQ实例，请检查填写的实例信息是否正确。 解决方案： 进入RocketMQ的控制台页面，检查源端实例状态是否正常。 检查事件流集群创建页面中配置的vpc和子网是否与源端实例网络畅通。 检查配置专享版事件流作业的第二步，即“源和目标对象配置”页面中配置的源端RocketMQ实例的用户名和密码是否正确。

RocketMQ采集函数错误码 错误码 错误码说明 运维说明 操作建议 200 心跳成功 设置事件流状态为RUNNING，清除告警。 正常提示。 601 未知致命异常 设置事件流状态为ERROR，上报告警，自动重启事件流。 建议联系华为工程师处理。 602 网络异常 502 消费者不存在 401 目标端投递认证失败 主动刷新token，设置事件流状态为ERROR，自动重启事件流。 等待自动恢复。 600 升级中 无动作。 采集函数正在升级，等待升级即可。 403 目标函数被禁用 设置事件流状态为ERROR，上报告警。 检查函数是否正常。 516 topic不存在 检查topic。 510 开启ACL的rocketMq认证失败 其他未识别错误码 检查用户密码是否发生变化，确认无误请联系华为工程师处理。 父主题： 管理事件流

事件流预检查 当前仅支持华南-广州。 预检查是创建事件流作业流程中的一环，用来检查用户填写的配置信息是否符合要求。预检查包含多个检查项，详情请参考表1，且每项检查独立执行，检查结果分成功、失败和告警三种类型。 表1 检查项目介绍 项目 内容 源端和目标端实例版本检查 检查源端实例和目标端实例的版本是否匹配。 源端连通性检查 检查作业所在运行时机器是否能正常连接到源端实例。 目标端连通性检查 检查作业所在运行时机器是否能正常连接到目标端实例。 源端和目标端实例规格检查 检查源端实例和目标端实例的规格是否匹配。 对于预检查结果是告警或者失败的事件流作业，都不会阻塞事件流作业的创建流程，检查结果仅做提示用。 Kafka预检查 RocketMQ预检查 父主题： 事件流

目标端连通性检查 检查事件流作业所在运行时机器是否能正常连接到目标端Kafka实例。 原因一：无法连接目标端Kafka实例，请检查网络配置是否正确。 解决方案： 进入Kafka的控制台页面，检查目标端实例状态是否正常。 检查事件流集群创建页面中配置的vpc和子网是否与目标端Kafka实例网络畅通。 原因二：无法连接目标端Kafka实例，请检查填写的实例信息是否正确。 解决方案： 进入Kafka的控制台页面，检查目标端实例状态是否正常。 检查事件流集群创建页面中配置的vpc和子网是否与目标端Kafka实例网络畅通。 检查配置专享版事件流作业的第二步，即“源和目标对象配置”页面中配置的目标端Kafka实例的用户名和密码是否正确。

源端连通性检查 检查事件流作业所在运行时机器是否能正常连接到源端Kafka实例。 原因一：无法连接到源端Kafka实例，请检查网络配置是否正确。 解决方案： 进入Kafka的控制台页面，检查源端实例状态是否正常。 检查事件流集群创建页面中配置的vpc和子网是否与源端Kafka实例网络畅通。 原因二：无法连接源端Kafka实例，请检查填写的实例信息是否正确。 解决方案： 进入Kafka的控制台页面，检查源端实例状态是否正常。 检查事件流集群创建页面中配置的vpc和子网是否与源端Kafka实例网络畅通。 检查配置专享版事件流作业的第二步，即“源和目标对象配置”页面中配置的源端Kafka实例的用户名和密码是否正确。

源端和目标端实例版本检查 检查源端和目标端实例的版本是否符合要求，当前要求Kafka实例版本在 3.x和2.7 中，版本不在匹配名单中则提示告警。 原因一：源端Kafka实例版本不支持，请选择符合要求的实例。 解决方式：返回配置专享版事件流作业的第二步，即“源和目标对象配置”页面，重新选择符合实例版本要求的实例作为源端实例。 原因二：目标端Kafka实例版本不支持，请选择符合要求的实例。 解决方式：返回配置专享版事件流作业的第二步，即“源和目标对象配置”页面，重新选择符合实例版本要求的实例作为目标端实例。 检查源端和目标端Kafka实例的版本是否一致，版本不一致则提示告警。 原因：源端实例和目标端实例的版本不一致，请检查源端实例和目标端实例的版本。 解决方式：检查配置专享版事件流作业的第二步，即“源和目标对象配置”页面中源端和目标端Kafka实例版本是否一致，若不一致，请修改源端或者目标端实例，使二者保持一致。否则，版本不一致可能会存在兼容性和性能风险。

操作步骤 登录事件网格控制台。 在左侧导航栏选择“事件流”，进入“事件流”页面。 单击“创建事件流”。 在弹窗中输入事件流名称和描述，单击“确定”，完成事件流名称和描述信息输入。 配置事件源。 单击“事件源”，右侧弹出“事件源”弹窗。 选择事件源提供方。 设置事件源参数。 完成后单击“下一步”。 配置规则。 单击“规则”，右侧弹出“规则”弹窗。 配置规则模式内容。 完成后单击“下一步”。 配置事件目标。 单击“事件目标”，右侧弹出“事件目标”弹窗。 选择目标服务。 设置事件目标参数。 完成后单击“确定”。 单击“保存”，完成事件流的创建。 事件流创建成功后，状态默认为“停用”。

如何给多个用户开通账号使用CodeArts Req服务？ 例如，有20个人需要使用需求管理服务，管理员可以通过“ 统一身份认证 服务 IAM ”创建20个子账号，详细操作请参见 创建IAM用户。 若项目管理员希望将这20个子账号加入至已有CodeArts项目中，则可参见添加本企业IAM用户为CodeArts项目成员进行操作。 操作完成后，子账号通过IAM用户登录CodeArts访问需求管理服务即可，详细操作请参见IAM用户登录。 父主题： 成员管理

处理方法 在工作项文件中删除之前超出300条数据量的空行后，再重新导入工作项数据。 在工作项文件中删除了几条工作项数据后，如果需要再补充到300条，则建议执行如下操作： 直接导入删除数据后的工作项文件。 检查导入成功的工作项条数是否跟工作项文件中的一致。 如果一致，未统计删除的几条工作项，则可在另一份工作项文件中填写需要增加的工作项数据后再导入。 如果不一致，统计了删除的几条工作项，则需要在需求管理服务中删除同等条数的工作项数据后，再重新导入一份工作项文件。

前提条件 已注册华为云并实名认证，如果还没有华为账号，请参考以下步骤创建。 打开华为云网站。 单击“注册”，根据提示信息完成注册。 注册成功后，系统会自动跳转至您的个人信息界面。 参考实名认证完成个人或企业账号实名认证。 已购买CodeArts专业版套餐或已购买CodeArts Req专业版套餐。 已购买CodeArts专业版套餐，如果还没有购买，可参考购买CodeArts套餐。 已购买CodeArts Req专业版套餐，如果还没有购买，可参考购买CodeArts Req服务。

前提条件 已注册华为云并实名认证，如果还没有华为账号，请参考以下步骤创建。 打开华为云网站。 单击“注册”，根据提示信息完成注册。 注册成功后，系统会自动跳转至您的个人信息界面。 参考实名认证完成个人或企业账号实名认证。 已购买CodeArts体验版套餐或已购买CodeArts Req基础版套餐。 已购买CodeArts体验版套餐，如果还没有购买，可参考购买CodeArts套餐。 已购买CodeArts Req基础版套餐，如果还没有购买，可参考购买CodeArts Req服务。

CodeArts Req入门实践 表1 CodeArts Req常用最佳实践 实践 描述 对IPD系统设备类项目的智能手表研发项目进行原始需求管理 成功产品的核心特征是满足客户需求。CodeArts Req打破了传统需求管理工具仅在研发阶段发挥作用的限制，将客户与市场需求也同步覆盖，提供了完整的客户需求采集、价值需求决策、交付与验收流程，让需求进展和动态客户实时透明，市场需求流动提速70%。 在CodeArts Req的原始需求管理中，用户可以将客户诉求提交至目标组织，目标组织对需求进行决策、分析、交付及后续验收流程全程实时透明化，可以加速客户诉求的交付速率，提升产品在市场上的竞争力。 对IPD系统设备类项目的智能手表研发项目进行缺陷管理 在整个产品生命周期管理中，缺陷管理是非常关键的一环。无论是硬件系统还是软件开发，都难免遇到不计其数的缺陷，如果缺陷管理不善，产品质量势必大打折扣。华为基于多年沉淀的质量运营管理经验，打造出一套行之有效的缺陷管理优秀实践，为团队提供统一、高效、风险可视的缺陷跟踪平台，确保每一个缺陷都被高质高效闭环。 某公司计划推出一款智能手表，研发周期较长，研发过程涉及多个部门、多团队的协作，如何保证缺陷在多个组织间的流转、最终达到有效闭环呢？下面请跟随我们，一起遍历整个缺陷生命周期管理实践。 对IPD系统设备类的智能手表研发项目进行基线评审管理 产品从规划到上市要经过复杂的研发过程，CodeArts Req提供了基线评审和变更管理能力，实现需求基线-受控变更-变更评审-变更管理的过程化管理，让基线变更如门禁一样，达到阈值才能启动下一步，确保产品研发“做正确的事” 某公司计划推出一款智能手表，涉及多部门、多团队的协作，且已经过前期的多轮需求沟通与澄清，将研发需求分配到各产研团队。为保障产品如期保质交付，需要确保不同研发生产团队都忠实执行任务，按照既定的需求进行研发落地。这时就需要对需求进行基线管控，基线后的需求不允许随意更改。下面我们以该公司为例，介绍如何实施需求基线管控。 对看板项目的商城管理项目进行需求规划 CodeArts Req提供的看板项目是一种业界流行的轻量、灵活和简单的团队协作方法，它将项目的需求、缺陷和任务可视，让每个人一目了然地掌握每项工作的状态，团队通过移动工作卡片的方式更新工作进展，及时暴露风险和问题。 用户可以创建看板项目对项目进行需求规划，通过新建工作项、分配工作项、处理工作项等来实现项目的需求规划与交付。

需求变更情况下的移动 不接受变更 当一个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布置看板中的卡片就好。

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

解决措施 如何玩转站会？按照如下思路学习下。 图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 站会常见问题 如何正确的开站会？站会的意义在哪里？可以不开站会吗？这些问题一直困惑着不少的团队。

审计 云审计 服务（Cloud Trace Service， CTS ），是华为 云安全 解决方案中专业的日志审计服务，提供对各种云资源操作记录的收集、存储和查询功能，可用于支撑安全分析、合规审计、资源跟踪和问题定位等常见应用场景。用户开通云审计服务并创建和配置追踪器后，CTS可记录CodeArts Artifact的管理事件和数据事件用于审计。 CTS的详细介绍和开通配置方法，请参见CTS快速入门。 父主题： 安全

数据保护技术 CodeArts Artifact通过多种数据保护手段和特性，保证通过CodeArts Artifact的数据安全可靠。 数据保护手段 简要说明 传输加密（HTTPS） CodeArts Artifact使用HTTPS传输协议，保证数据传输的安全性。 个人数据保护 CodeArts Artifact通过记录操作日志等方法防止个人数据泄露，保证您的个人数据安全。 隐私数据保护 涉及到用户的仓库密码信息需要存储时，CodeArts Artifact提供敏感 数据加密 存储。 父主题： 安全

权限管理 CodeArts Artifact包含两个部分，软件发布库和私有依赖库。 软件发布库权限管理：软件发布库的权限可以实现项目下各角色权限分配自定义，具体操作请参考权限设置。 私有依赖库权限管理：私有库的权限由用户角色和仓库角色共同决定，用户角色本质为IAM权限，IAM权限获取需要管理员创建IAM用户后，将其加入用户组，并给用户组授予策略或角色，用户组中的用户也相应的获得对应的权限；仓库角色可以由拥有tenant administrator用户角色的用户进行分配，详细操作请参见管理私有依赖库中的管理用户权限章节，更细粒度权限管理请参见管理私有依赖库中的管理用户权限章节后的权限列表。

责任共担 华为云秉承“将公司对网络和业务安全性保障的责任置于公司的商业利益之上”。针对层出不穷的云安全挑战和无孔不入的云安全威胁与攻击，华为云在遵从法律法规业界标准的基础上，以安全生态圈为护城河，依托华为独有的软硬件优势，构建面向不同区域和行业的完善云服务安全保障体系。 安全性是华为云与您的共同责任，如图1所示。 华为云：负责云服务自身的安全，提供安全的云。华为云的安全责任在于保障其所提供的 IaaS、PaaS 和 SaaS 各类各项云服务自身的安全，涵盖华为云数据中心的物理环境设施和运行其上的基础服务、平台服务、应用服务等。这不仅包括华为云基础设施和各项云服务技术的安全功能和性能本身，也包括运维运营安全，以及更广义的安全合规遵从。 租户：负责云服务内部的安全，安全地使用云。 华为云租户的安全责任在于对使用的 IaaS、PaaS 和 SaaS 类各项云服务内部的安全以及对租户定制配置进行安全有效的管理，包括但不限于虚拟网络、 虚拟主机 和访客虚拟机的操作系统，虚拟防火墙、API 网关和高级安全服务，各项云服务，租户数据，以及身份账号和密钥管理等方面的安全配置。 《华为云安全白皮书》详细介绍华为云安全性的构建思路与措施，包括云安全战略、责任共担模型、合规与隐私、安全组织与人员、基础设施安全、租户服务与租户安全、工程安全、运维运营安全、生态安全。 图1 华为云安全责任共担模型 父主题： 安全

提供自研、安全、极致性能的制品仓，保障业务连续性不中断 CodeArts Artifact制品仓库，基于云原生架构自研，解决外界不可控因素导致业务连续性问题。在安全上华为云CodeArts Artifact提供多维度、细粒度的权限控制，支持企业内不同角色对制品仓库访问控制的诉求。制品仓库存储采用物理隔离存储方式，减少恶意盗取制品风险，同时提供记录用户操作功能，保证操作可追溯；在可靠性上华为云CodeArts Artifact支持双AZ容灾和跨地域容灾、API限流与降级、服务依赖和隔离、实现服务故障自探测，实现99.99%的SLA保证；在极致性能上CodeArts Artifact提供热点文件缓存加速，增量上传下载，大小文件充分利用缓存加速优势，极速传输，提升用户构建速度，突破底层存储带宽限制，实现同地域高速并发传输，对比开源同类产品5X倍的上传和10X倍的下载性能提升。

支持开源合规分析和漏洞检测，让高危致命问题无处遁逃 华为云CodeArts Artifact制品仓库提供基于软件包的成分分析能力，通过特征匹配的方式，分析软件包中的开源软件及版本，并通过漏洞库匹配的方式进行开源漏洞排查。实时同步NVD、CNVD、CNNVD等常见漏洞库漏洞数据，覆盖主流编程语言(C/C++、Java、Go、Python、JavaScript等)，覆盖语种持续增加，提供全面、直观的风险汇总信息。在服务上线之前能够实时感知开源高危风险，建立起防御体系，并且及时修复问题，避免不可估量的损失。

无缝连接第三方仓库，提供统一聚合仓地址，极大提升用户体验和下载性能 针对用户同时使用多个镜像源或制品库的场景，CodeArts Artifact提供仓库聚合能力，允许灵活组合多个代理仓，提供统一制品仓库入口，解决用户找不到制品包的痛点和简化客户配置。 CodeArts Artifact新增自定义代理仓功能，允许用户创建自定义代理仓库来代理开源社区仓库和三方依赖仓库，通过代理仓下载文件后支持将对应文件缓存到制品仓库，解决用户三方依赖下载慢痛点，实现下载三方依赖和本地仓库一样的极致体验。

按文件名和checksum搜索，亿级制品包秒级查询与精准定位 华为云CodeArts Artifact具备强大的搜索能力，依托于数据引擎检索能力，支持内部研发近百亿制品文件的多维度的快速搜索。 当前覆盖Maven、npm、Go、PyPI、RPM、Debian、Conan、NuGet多种制品类型，用户可以通过文件名称或HASH信息（MD5、SHA1、SHA256、SHA512等四种类型），实现秒级检索定位。 以此为基础，CodeArts Artifact也演进出上亿级别的元数据和SBOM的高效关联查询，以便对制品文件进行快速溯源，对比开源同类产品搜索性能提升20X倍。

支持10+种仓库类型，充分满足用户各种使用场景 华为云CodeArts Artifact制品仓库支持 Generic、Maven、npm、Go、NuGet、PyPI、Conan、Debian、RPM主流制品仓库类型，满足嵌入式、WEB应用、移动应用等开发场景所需，可以与本地各构建、部署工具和云上的持续集成、持续部署无缝结合。华为云CodeArts Artifact也提供制品和元数据的完整性校验能力，支持细粒度控制和按版本的细粒度包锁定权限，保障发布软件测试完整性，全面看护企业制品安全。