华为云用户手册

AppStage开发中心功能介绍 开发中心的主要功能如表1所示。 表1 开发中心功能介绍 主要功能 功能简介 团队管理 团队和成员管理，团队所属部门、关联服务等信息配置以及成员的新增、修改和删除。 版本管理 需求和业务规划，制定版本计划，跟踪交付任务，跟踪发布上线。 需求管理 需求管理流程覆盖需求的收集、分析、评审、排序、分发、实现、验证、确认的全过程。 代码管理 提供分布式代码管理和协同开发能力，包括代码托管、代码检查、代码审核、代码追溯、持续集成等功能。 流水线管理 将产品需求纳入流水线进行需求设计、开发、验证，最终通过软件包将实现的用户需求交付给下游。 缺陷管理 从缺陷的发现和提出，到分析定位、实施修复，再到测试和验收，最终导向缺陷的闭环。 知识库 知识库是面向开发团队的 知识管理 系统，支持知识全生命周期管理，帮助您完成智能、安全的知识作业，提供层级式的目录树、多人在线协同编辑等功能。 开发插件库 提供多种预置的开发插件，同时可以将自己需要的其他本地插件上传至开发插件库进行灵活管理，也可以为插件分类创建标签，便于快速筛选及查找。 效能管理 提供从需求、缺陷、代码、构建、测试、部署、发布到运营等研发各阶段作业数据的分析洞察能力。 父主题： AppStage开发中心简介

创建团队 在开发中心首页下方的“我的团队”区域，单击右侧“创建团队”。 在“创建团队”页面，设置团队相关参数，参数配置请参见表1。 表1 创建团队参数说明 参数名称 参数说明 团队名称 必填项，团队的命名。 团队归属部门 必填项，选择系统中已提前创建的部门。 关联服务 必填项，选择系统中已提前创建并发布的服务。 团队 LOG O 必填项，单击系统默认图片上的“点击修改”，可选择本地图片自定义LOGO图片。 团队简介（可选） 非必填项，团队空间的功能描述或其他备注信息。 单击“创建”。 在“我的团队”区域可查看到创建的团队的卡片。

管理关键风险 在“测试评估”页面选择“关键风险”页签，然后单击“新增”。 在“新增关键风险”页面，如图3所示，参数说明请参见表2。 图3 新增关键风险 表2 关键风险参数说明 参数名 参数说明 风险描述 风险问题的描述。 级别 区分三个级别：低、中、高 影响分析 风险问题的相关影响分析。 规避措施和计划 规避该风险问题的相关措施和计划。 单击“确定”。新增的关键风险显示在风险列表中。 （可选）在风险列表“操作”列单击“编辑”，在“编辑关键风险”页面可编辑风险问题的相关信息，参数说明可参见表2。 （可选）在风险列表“操作”列单击“删除”，在“删除风险”对话框确认删除的风险问题并单击“确定”，即可删除相应的风险问题。

管理单项测试结论 在“测试评估”页面选择“测试结论”页签，系统预置了四个测试类型：遗留DI值、功能评估、性能评估和安全评估。 单击“新增”，在“新增测试结论”页面，设置测试结论相关参数，如图2所示，参数说明请参见表1，设置完成后单击“确定”。 图2 编辑测试结论 表1 测试结论参数说明 参数名 参数说明 测试类型 输入测试类型。 测试结论 根据实际情况可设置为：通过、不通过或不涉及。 评估说明（可选） 测试评估的相关说明。 附件（可选） 单击“添加文件”，最多可上传一个附件文件辅助测试评估的说明，且只能上传ZIP、RAR、DOCX、DOC、XLS、XLSX格式文件，文件不能超过50MB。 说明： 用户需对自己上传文件的安全风险负责，开发中心不对用户自己上传的文件做任何处理。 添加文件后，如需变更文件，可光标移至文件，在文件右侧单击，将旧文件删除后，再单击“添加文件”重新上传新文件。 （可选）在测试结论列表操作列单击“编辑”，在“编辑测试结论”页面可编辑测试评估的相关信息，参数说明可参见表1。 （可选）在测试结论列表操作列单击“删除”，在“删除测试结论”对话框单击“确定”，可删除不需要的测试类型及其结论。 系统预置的四个测试类型（遗留DI值、功能评估、性能评估、安全评估）不可删除。

使用SSH协议在TortoiseGit客户端克隆代码 本节内容指导如何使用TortoiseGit客户端克隆 代码托管服务 的仓库到本地环境中。 下载并安装TortoiseGit客户端。 获取仓库地址。 在仓库主页中，单击“克隆/下载”按钮，获取SSH地址，通过这个地址，可以在本地计算机连接代码托管仓库。 您可在代码托管服务仓库列表中“仓库地址”下获取SSH地址。 进入您的本地仓库目录下，右键选择“Git克隆”菜单选项，如下图所示。 在弹出的窗口中将上述复制的SSH地址粘贴到URL输入框中，勾选“加载Putty密钥”并选择私钥文件，最后单击“确定”，如下图所示。 单击“确定”之后即开始克隆仓库，如果您是第一次克隆TortoiseGit客户端会询问您是否信任远程仓库，单击“是”即可。 克隆用时受仓库大小影响，克隆的动作如下图所示。

使用SSH协议在Git Bash客户端克隆代码 本节内容指导如何使用Git Bash客户端克隆代码托管服务的仓库到本地环境中。 下载并安装Git Bash客户端。 配置SSH密钥。 获取仓库地址。 在仓库主页中，单击“克隆/下载”按钮，获取SSH地址，通过这个地址，可以在本地计算机连接代码托管仓库。 如果您未配置SSH密钥，你可单击上图中“SSH密钥管理”链接进行配置，详情请参考SSH密钥。 您可在代码托管服务仓库列表中“仓库地址”下获取SSH地址。 打开Git Bash客户端。 在本地计算机上新建一个文件夹用于存放代码仓库，在空白处单击鼠标右键，打开Git Bash客户端。 克隆仓库时会自动初始化，无需执行init命令。 输入如下命令，克隆代码托管仓库。 git clone 仓库地址 命令中“仓库地址”即3中获取的SSH地址。 如果您是第一次克隆仓库，会询问您是否信任远程仓库，输入“yes”即可。 执行成功后，您会看到多出一个与您在代码托管服务新建的仓库同名的文件夹，并且其中有一个隐藏的.git文件夹，则说明克隆仓库成功。 此时您位于仓库上层目录，执行如下命令，进入仓库目录。 cd 仓库名称 进入仓库目录，可以看到此时Git默认为您定位到master分支。 客户端在git clone代码仓库时失败的原因排查： 确保您的网络可以访问代码托管服务。 请在git客户端使用如下测试命令验证网络连通性（其中“**********.com”为代码仓库地址）。 ssh -vT git@**********.com 如果返回内容含有“Could not resolve hostname **********.com: Name or service not known”，则您的网络被限制，无法访问代码托管服务，请求助您本地所属网络管理员。 请检查建立的SSH密钥配对关系，必要时重新生成密钥并到代码托管控制台进行配置。 只有开启IP白名单的机器才可以在Git客户端克隆。

为什么使用AppStage开发中心 开发中心提供全场景一站式作业平台，承载端到端研发作业流，提供涵盖软件研发全生命周期的研发工具链和研发管理服务。以团队为中心，深度集成第三方工具链能力，基于服务以及版本为维度提供从需求、设计、开发、测试、部署发布全场景一站式研发门户，实现精细化项目管理，掌握和处理项目全量信息，支撑研发角色统一在一站式门户协同工作，提升团队研发效率。 父主题： AppStage开发中心简介

应用场景 敏感数据识别 OBS中存储了大量的数据与文件，但无法准确获知这些OBS数据中是否包含敏感信息以及敏感数据所在的位置。 您可以使用DSC内置算法规则，或根据其行业特点自定义规则，对其存储在OBS中的数据进行整体扫描、分类、分级，并根据结果做进一步的安全防护，如利用OBS的访问控制和加密功能等。 异常检测和审计 DSC可检测敏感数据相关的访问、操作、管理等异常，并提供告警提示信息，用户可以对异常事件进行确认和处理。通常情况下，以下行为均被视为异常事件： 非法用户在未经授权的情况下对敏感数据进行了访问、下载。 合法用户对敏感数据进行了访问、下载、修改、权限更改、权限删除。 合法用户对敏感数据的桶进行权限更改、权限删除。 访问敏感数据的用户登录终端异常等情况。

背景信息 敏感数据主要包括个人隐私信息、密码、密钥、敏感图片等高价值数据，这些数据通常会以不同的格式存储在您的OBS桶中，一旦发生泄漏，会给企业带来重大的经济和名誉损失。 DSC在您完成数据源识别授权后，从您存储在OBS的海量数据中快速发现和定位敏感数据，对敏感数据分类分级并统一展示，同时追踪敏感数据的使用情况，并根据预先定义的安全策略，对数据进行保护和审计，以便您随时了解OBS数据资产的安全状态。

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

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

问题分析 首先，相对于传统开发模式的指派开发任务，需要知道为什么在敏捷开发中是领取任务。在敏捷中，不管是敏捷宣言还是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要充分保护好成员对有挑战工作认领的热情。如防止在回顾会议上出现指责和批斗的情况，回顾和总结永远应该聚焦的是做事的方式方法而不是对人的苛刻和指责。

总结 以上三种没有人认领任务的情况，是比较常见的。但在真正的实际项目中，每个公司或团队的情况都不尽相同，无法穷举所有，应具体情况具体分析。比如，一个刚刚转型的敏捷团队，在开发任务的领取上可能会更偏向于半指派半领取的方式。这就好比中国经济一样 “以市场经济为导向，适当进行宏观调控”。但不管这个“调控”的力度如何，都应该鼓励团队成员能积极主动地领取任务，并随着任务的进展情况灵活调整，及时做好风险把控，必要的时候需要其他渠道的协调帮助或相关领导的介入，以保证迭代的目标不受影响。

了解更多：迭代待办列表 迭代待办列表在CodeArts中称“迭代”，它是一组为当前迭代选出的产品待办列表项，同时加上交付产品增量和实现迭代目标的计划。 当新工作出现时，开发团队需要将其加入到迭代待办列表中去。随着工作的执行或完成，剩余的工作量被估算并更新。当计划中的某个部分失去开发意义，就可以将其移除。在迭代期间，只有开发团队可以改变迭代待办列表。迭代待办列表是高度可见的，是对开发团队计划在当前迭代内工作完成情况的实时反映，该列表由开发团队全权负责。 迭代待办列表在迭代计划会议中形成，其中开发团队不会被动分配任务而是由开发团队成员主动认领自己擅长和喜爱的任务。任务被分解为以小时为单位，建议任务不要超过16个小时。如果一个任务超过16个小时，那么它就应该被进一步分解。每项任务信息包括其负责人、工作量、承诺的完成时间及其在迭代中任意一天的剩余工作量，且仅开发团队有权改变其内容。

解决措施 针对以上问题的分析，建议这种情景下将Sprint的时间盒由一周改为两周。Sprint的时间过短，团队成员会忙于准备计划会议、评审会议及回顾会议，真正完成工作项的时间较少。对于突发事件的应对能力减弱，不利于形成团队稳定的节奏。Sprint的时间过长，失去了短时间盒的优势，失去了时间盒的意义。因此，如果团队在时间盒为一周的Sprint中经常不能完成Sprint目标，可以试着把时间盒调为两周。同时要注意优化用户故事的大小，提高四大事件的效率。 Sprint的时间盒由一周改为两周后影响因素会有所改善，具体如表2所示。 表2 影响Sprint目标因素表（二） 序号 影响因素 Sprint由一周改为两周后的相应缓解 1 探索性工作项多 有相对充分的缓冲时间应对学习、探求性工作以及突发情况。 2 工作领域不熟悉，需要学习成本 3 用户故事比较大 时间相对宽裕后，计划会议开得更充分，用户故事拆分为更小的故事，或者在每项用户故事下建Task。Sprint的目标可以按Task级别来平衡考量完成度。 4 PO完成标准高 时间相对宽裕后，理解PO完成标准更加充分，在计划会议上明确验收标准，包括AC（Acceptance Criteria） 和 DoD (Definition of Done)。 5 Sprint周期短 调整周期后，团队成员氛围更加好，每个Spring目标完成度得以改善，成员更加自信。 6 Sprint计划会议和Sprint回顾会议持续时间略长 时间相对宽裕后，每项会议质量有所提高，在合理的时间范围内可以高质量完成会议内容。 其情况Sprint的时间盒长度建议如下，您可根据团队现况选择适合的时间盒。

了解更多：时间盒 在Scrum框架中，工作在建议时间长度为一个月或者更短的迭代或循环中进行，这个迭代或者循环叫做冲刺。冲刺在一个时间盒（Time Box）内，也就是冲刺有固定的开始和结束时间。 时间盒的优点具体内容如下： 时间盒是设定WIP（work in process）数量限制的技术。WIP是已经开始但还没有完成的工作清单。开发团队只开发自己认为在一个冲刺内可以开始并按时完成的工作事项，因此时间盒是为每个冲刺设定WIP数量限制。 时间盒可以强制排列优先级。需要先执行高优先级的工作，时间盒可以强制团队按优先级排序执行小批量工作，这样团队的注意力可以更集中于快速完成高价值的工作。 时间盒可以展示进度。时间盒可以展示团队需要多少个时间盒才能完成大特性的进度，帮助团队准确知道为交付整个特性还需要做多少工作。 时间盒可以限定结束日期。每个冲刺中，时间盒限定了一个固定的结束日期，通过这种方式强制结束可能无休止的工作。 时间盒可以促进结束。冲刺有明确的最后期限，这个期限不允许修改，这可以激发Scrum团队成员全力以赴按时完成冲刺内的工作。如果没有时间盒的限制，Scrum团队成员就不会有完成工作的紧迫感存在。 时间盒可以增强预测性。团队可以不预测后续长时间段内可以完成的工作，但是预测下个冲刺内能够完成的工作是可以做到的。

问题分析 目前Sprint中存在的主要问题是Sprint目标完成不好，解决障碍，Sprint目标按承诺完成即可。 团队成员的工作内容中包含很多探索性工作项，对工作内容领域不熟悉，需要投入一些学习成本，导致工作项的实际完成用时要比正常多。每个用户故事的工作量也比较大，多数超过24小时。PO对工作项完成标准的要求非常高，评审严格，不合格的工作项在Sprint中经常返工。团队当前的Sprint时长为一周，并且四大事件按照Scrum框架执行，其中Sprint计划会议和Sprint回顾会议平均持续时长为2小时左右。 从分析中归纳影响Sprint目标完成的几个主要因素如表1所示。

什么是Epic、Feature、Story和Task？ Epic、Feature、Story和Task用来划分需求颗粒度的标签，可以看作需求占位符，分别代表需求颗粒度从大到小。每个层级的需求本身又承载着一些意义，在进行需求划分的时候可以进行参考。 Epic：史诗，是项目的愿景目标。通过Epic的落地达成，使公司可以获得相应的市场地位和回报，具有战略价值。通常需要数月完成。 Feature：可以带来价值的产品功能和特性。相比Epic，Feature更具体，更形象，客户可以感知，具有业务价值。通常需要数周，多个Sprint才能够完成。 Story：通常所说的用户故事，是User Story的简称。Story是从用户角度对产品功能的详细描述，承接Feature，并放入产品Backlog中，持续规划，滚动调整，始终让高优先级Story交付给客户，具有用户价值。Story要符合INVEST原则（Idependent、Negotiable、Valuable、Estimable、Small、Testable），通常需要数天，并在一个Sprint中完成。 Task：是团队成员要完成的具体任务。在Sprint计划会议上，将Story分配给成员，然后由成员分解为Task，并预估工时，通常在一天内完成。

如何灵活使用这些概念，让需求管理更为高效？ 为了加深对Epic、Feature、Story和Task的理解，本文对一个案例进行需求拆分，过程中会结合CodeArts需求管理服务进行展示。 案例： 某大型商超受互联网的冲击，营业额大幅下滑。 为了减少门店消费者流失，保有市场地位和份额，决定用6个月的时间建立自己的网上商城。 第一步：Epic确定和创建 根据前面的介绍，在进行需求确认的时候先看颗粒度，然后再考虑其承载意义。 此处需要考虑一个问题：一个产品是一个Epic吗？产品的每个业务模块是Epic还是Feature？ 产品通常具有战略意义，从这个角度看，产品适合作为一个Epic。但是不是所有的产品都适合，还要看产品是什么，它的颗粒度有多大。在本文的实例中，网上商城周期是6个月，目的是保有市场份额，从颗粒度和战略意义上，网上商城适合作为一个Epic。 每个业务模块具体是Epic还是Feature要分情况。比如：构建智慧城市是一个愿景目标，下面包括智慧交通、智慧政务、智慧社区等，这些每个业务模块都很大，用Epic进行需求占位合适一些。 在CodeArts创建一个Scrum项目，命名为“某大型商超网上商城”。进入“需求规划”界面，新建Epic： 图2 新建Epic 新建之后，单击进入到详细编辑界面。将描述信息填写完整，可以使用CodeArts提供的模板： 作为：对于这个Epic来说，用户角色是整个公司。 我想要：想要的结果就是建造网上商城。 以便于：目的是想要减少消费者流失，保有市场地位和份额。 同时在基本信息中设定这个Epic的起止时间、优先级、重要程度、预计工时等信息。这些信息对于团队理解产品、理解项目起到至关重要的作用，所以要进行详细填写。 图3 编写Epic 第二步：将Epic分解为Feature 客户要求在6个月内交付5个功能模块：促销管理、会员管理、订单管理、配送管理和客户端。团队的一个Sprint是2个星期，每个模块大概需要2-3个Sprint完成，从颗粒度和承载的意义，这5个模块适合作为Feature。 图4 Epic分解为Feature 创建之后，如需要填写详细信息，可以在详细页面进行编辑。界面信息项和前面Epic的相同，此处不再赘述。 第三步：Feature分解为Story 敏捷开发是渐进明细的，不要求所有需求在相同时间做到同样详细，只要求当前Sprint和未来的一个或两个Sprint的Story是详细的。将来Sprint的Story可以是一个大概的情况。进入到当前Sprint的Story要符合INVEST原则。开发团队要在Sprint结束时完成交付。 客户优先级中，会员管理Feature优先级高，会员管理这个Feature就要在需求梳理会议上详细分解为Story放入到产品Backlog中。经过分解后，需要包含和管理员相关的功能：积分管理、会员级别管理、用户分析、用户管理。这些具体的功能就可以作为Story。需要注意的是，分解出的Story要尽量在一个迭代内完成交付，如果无法完成就尝试继续分解。因为只有交付的Story才是有价值的，无法交付的Story对于当前Sprint来说就是浪费。分解后的Story如图5所示。 图5 Feature分解为Story 第四步：将Story划分为Task 在Sprint计划会议上，团队和PO要共同从产品Backlog中按照优先级顺序选择本次Sprint需要完成的Story，进入到冲刺Backlog中。团队成员认领后，将Story分解为Task，并进行估算。 此时面临一个问题：Story和Task如何区分？ Story聚焦价值，需要在Sprint中完成，要用数天的时间，要符合INVEST原则。Story的描述是一个名词，如积分管理这个Story的完整描述是：作为管理员，我能够进行会员的积分管理，以此来划分消费等级提供不同增值服务。 Task聚焦实现价值，通过过程性的任务来实现Story的功能。通常是1～8个小时。Task的描述是一个动作。如积分管理这个Story，功能的实现需要通过业务逻辑开发、积分规则设计和积分数据库设计这几个过程来完成，这些就是Task。如图6所示。 图6 Story分解为Task 这样，从Epic开始，到Task结束，完成了网上商城的需求拆分。

小结 使用Epic、Feature、Story、Task管理需求时，需要注意以下几个方面： 敏捷开发中需求是逐步细化的，遵循自上而下的方式去分解需求。 Epic和Feature都是颗粒度比较大的需求，是用户对于产品的期望和功能特性的描述。 分解为Story的时候，目前正在进行的Sprint需要分得更小更细，将来的Sprint需求（可能是3个及以上）就不需要那样细分。当进行到某个Sprint时，再进行分解，细分成一组更小、更细的条目。 Task是对当前Sprint的Story进行的分解。 所有这些粗略和详细的Story都放在产品Backlog中，整个列表要遵循DEEP（Detailed appropriately、Emergent、Estimated、Prioritized）原则，定期梳理和排序优化，保证高优先级的需求优先实现和交付。 在整个过程中需要和客户一直保持沟通合作，这样才能保证实现的功能是客户真正想要的。

具体操作方法 具体操作，可以按照事前、事中、事后各个阶段来采取不同的措施处理。 事中的处理 根据具体情况不同，在发现需求遗漏的当时，可以采取如下一些做法： 重要需求遗漏，不紧急：既然不紧急，按照常规做法增加进去即可，但如果经常出现遗漏，就要考虑是否是需求分析和规划的实践做法有问题，才会导致问题持续出现，这种情况，应强化需求结构化管理，从全局出发进行思考和规划，避免因为思考的片面化和局部性导致的遗漏。 重要需求遗漏，紧急：既然是又重要又紧急的需求，那么必然就得调整当前开发工作的顺序，把这个遗漏的重要紧急需求排进去，把工作安排下去；然后就要考虑从需求的优先级和需求的结构化管理两个方面入手复盘，并切实改进，避免类似情况再次发生。 需求遗漏：如果是不太重要的需求遗漏，按照常规做法处理即可；可以根据其紧急程度和影响，决定是否调整工作顺序让这个需求插队；如果这种情况反复出现，那建议可以考虑进行复盘，从需求结构化管理的角度进行分析，并商讨改进措施。 事后的处理 事后其实就是复盘，复盘的关键是要基于盘来推演和分析，这个盘就是事前制定的模型和规范。是有模型有规范，但执行出了问题？还是说这几个需求情况特殊，模型比较简单没有覆盖到这些特殊情况？还是说模型和规范都没问题，就是人员能力不足，导致判断偏差大？只有找到正确的根因，才能够真正有效的解决问题，所以不复盘则已，要复盘就务必要认真严格地进行复盘。 怎么复盘？复盘也是有方法，业界也有相关书籍可供参考借鉴。例如温伯格在《成为技术领导者》中提出的MOI模型就可以用作复盘的一种思路。 M：激励（Motivation），是不是人们没有动力去做这件事情？ O：组织（Organization），是不是无组织无纪律、一片混乱，人们不知道自己或别人该做什么？ I：想法或创意（Idea/Innovation），是不是缺少如何解决这些问题的点子或创意，不知道有什么办法解决这个问题？ 复盘时要注意，受限于能力、经验以及出问题次数多少的影响，可能无法得出一个准确的结论和必然有效的解决方案。此时，一方面需要秉持持续改进的心态，可以先落实当前已经比较明确的改进措施，后续再观察效果，持续复盘、持续改进即可。另一方面也可以先采取一些临时措施。 预留时间：比如，如果确实很难分析清楚为什么总是会遗漏需求，无法进行非常有针对性的处理时，也可以采取较为模糊应对的方式。可以拉取过去一段时间的工作记录，评估这段时间每个迭代的突发需求所消耗的工作量投入，可以取个平均值，然后在后续进行迭代工作安排的时候，固定的预留出一定量的时间，用于应对极有可能会出现的突发需求。 需求拆细：当出现突发需求，导致需要调整工作顺序时，很有可能会因为需求颗粒度大以至于腾挪余地有限，而难以避免突发需求带来的影响，因而还应该尽可能地采取拆细需求的方式，将颗粒度比较大的需求拆分为较小颗粒度的需求，可以增加调整需求工作顺序时的灵活性。 确定要预留多少时间，可以利用CodeArts的Epic-Feature-Story结构，把突发需求汇集在一起，便于统计。例如创建一个特殊的Epic“突发需求”，下一级是为每个迭代创建的Feature，用来承载各个迭代里面具体的那些突发需求（体现为Story），并做好工时的记录，迭代结束后，就可以来计算出现了多少个突发需求、投入了多少工作量了。 图1 规划迭代 也可以采用“模块”字段来辅助记录和统计突发需求的数据。例如，新建一个模块，取名“突发需求”，所有突发需求都标注为这个模块，那么后续就可以基于模块进行筛选或查看报表等方式来统计突发需求所消耗的工作量了。 图2 迭代内容 事前的处理 事前的处理放到最后来介绍，是因为已经出现了问题就需要在当时尽快处理，所以先介绍了事中的处理。但当处理完问题也完成了事后复盘，就需要考虑未来的事前，尽可能的避免问题发生。 简单来讲，事前的话，就是要做好需求的结构化管理和需求的优先级管理，以及做好相关规范的宣导、人员的分配和能力的培养，这样就能够有效的避免或减小突发需求带来的影响了。

避免重要需求遗漏的思路 避免重要需求遗漏，首先需要反问一句——为什么这些紧急重要的需求无法更早预见？同样的，需要了解： 具体是哪些外界原因？这些原因是否有共性，有的话，那就针对性处理。 增加的需求有无共性特点？有的话，可以针对性处理。 临时增加有多临时？是否有提高或改善响应能力的空间，如果可以更快调整和响应，使得这些临时需求产生不了什么影响，那么这个问题也就不再是问题了。 既然是常态，为何流程没有做出调整去应对？是调整过流程或工作方式，还是无法解决问题，还是说不知道该怎么调整流程或工作方式去适应？

改进优先级模型 市场在变化，用户在变化，产品在变化，优先级模型自然也必须跟随着发生变化。可以定期或不定期的安排对需求优先级模型进行复盘分析，找出可以改进或优化的点，并跟进落实。可以是定期开展，例如每个月进行一次复盘，把这个月所涉及的需求都拿出来审视，或者是其中有调整过优先级顺序或者出现过问题的需求拿出来审视均可；也可以是不定期，以问题驱动的方式，比如某天进行了大量需求优先级的调整，那么当天或第二天就可以临时召集一次复盘会议，分析为什么会发生这种情况。 复盘要有好的效果，就必须尽可能的复原问题发生当时的情况，所以前面提到的知识库记录就变得非常重要。复盘会议应提供尽可能多的相关信息以便参会人员了解情况，充分探讨。 复盘过程中，要定位出正确的根因，是模型本身设计有问题（例如要素和尺度），还是取值、加权有问题（比如某类需求的预计收入就是非常难估算），还是过程管理的问题（比如过早进行估算，因为缺乏必要信息，导致估算得出的优先级顺序不准确），并进行针对性地改进。

需求优先级管理四步走 需求优先级的管理，其实是为了帮助需求管理者确定先做哪个需求后做哪个需求，从而可以最大化回报、最小化风险或投入。要做好优先级管理，或者更直接来说是优先级顺序管理，需要做到如下四件事情： 确定优先级模型：优先级看起来像是一个简单直接的值，但实际上它是一个基于多种因素进行综合判断之后得出的一个值，这些因素和判断原则，就是优先级模型。 排定需求优先级顺序：将需求代入优先级模型进行计算，得出每个需求的优先级顺序。 调整需求优先级顺序。 改进优先级模型：如果经常发生需要调整需求优先级顺序的情况，那么应该对这些情况进行一定的复盘分析，如有必要，修正或改进当前的优先级模型，让它可以适应实际情况，以避免调整优先级顺序的情况反复发生；另外就是需求可能已经交付或发布上线，但是该功能的实际用量或价值不吻合预期，则需要反思对这些需求的分析和判断，究竟是分析判断有误还是优先级模型有误，并进行相应的调整。

确定优先级模型 成本收益分析就是最简单的一种优先级模型，重要/紧急的四象限也是一种优先级模型，Kano模型也是一种优先级模型，它们都可以确定需求的优先级顺序。模型可以简单也可以复杂，根据企业实际需要来确定即可。 务必切记优先级模型一开始不应过于复杂，那样会导致优先级管理的管理开销过高，喧宾夺主，反而影响了需求的开发和交付。如果较为简单的模型就可以满足需要，就应该首选使用较简单的模型。企业可以从简单开始，逐渐完善，不需要也不应该在一开始就追求过于复杂的模型。 简单可以体现在考虑的要素更少，比如成本收益分析只考虑两个要素，就比考虑更多要素的模型简单。 简单还可以体现在要素的取值范围更窄或精度要求更低，比如预计利润只要求评估高/中/低，就比要求以万元为单位评估预计利润更简单。

排定需求优先级顺序 比如成本收益分析，可以是把预期市场收入作为收益值，把预期研发投入作为成本值，计算差值，或计算ROI均可。假设需求A预计收益为10万元，研发投入按人天折算预计3万元，那么预计利润就是7万元，预计ROI是233%；需求B预计收益为5万元，研发投入折算预计4万元，那么预计利润1万元，预计ROI为25%。那么需求A的优先级顺序就要比需求B更靠前。这种相差悬殊的情况往往不难判断，假设还有需求C预计利润也是7万元、预计ROI是50%，以及需求D是预计利润1万元、预计ROI是500%。那么A、B、C、D这四个需求的具体顺序怎么排定呢？ 如果真的出现这种情况，那就更复杂一些了，需要考虑引入权重，然后计算出一个综合值，这个值按照某种规则（例如从大到小）排列出来就是最终的优先级顺序，比如： 需求名称 预计收入（万元） 预计成本（万元） 预计利润（万元） 利润权重 利润加权值 ROI（%） ROI权重 ROI加权值 综合值 优先级顺序 需求A 10 3 7 0.1 0.7 233% 1 2.33 3.03 2 需求B 5 4 1 0.1 0.1 25% 1 0.25 0.35 4 需求C 21 14 7 0.1 0.7 50% 1 0.5 1.2 3 需求D 2 1 1 0.1 0.1 500% 1 5.0 5.1 1 根据上述表格中所得出的结果，应该依序将需求D、需求A、需求C、需求B排入开发计划。优先级顺序，在CodeArts中，可以使用工作项的“优先级顺序”字段来实现，该字段取值范围1~100。 图2 Story工作项优先级顺序展示

为什么要进行需求结构化管理？ 并不是说任何情况下都需要进行软件项目需求的结构化管理。如果只是事务性质的管理需求，也就是有需求了能记录、能跟踪状态、实现之后不需要继续跟踪、也不需要维护需求与需求之间的关联，那么不需要思考需求结构化管理这个问题。这种情况下，不管是用CodeArts的Scrum项目模板还是看板项目模板，都可以管理好需求和软件项目。只有在需求较多、且需求之间存在关联，而且即便是已经实现的需求也需要进行一定的管理、维护的情况下，才需要去思考需求结构化管理的问题，此时，需要使用CodeArts提供的Scrum项目模板，因为里面有Epic-Feature-Story的需求结构，以及需求规划功能可以辅助团队进行需求的结构化管理。

以什么为依据进行需求结构化管理？ 需求结构化管理，应该以什么为脉络来建立这个结构呢？软件研发无非是分为项目型软件研发和产品型软件研发两种，项目通常来讲都是临时性的，或者说短期性的，而产品或者软件系统是长期性的，或者说会持续维护、更新其功能特性的。项目复项目，很可能通过持续地完善和刷新同一套软件产品或系统来达成项目目标，交付软件项目所要求的功能特性的。这就意味着，需求结构化管理，需要以产品或系统的功能特性的脉络为依据。而软件项目管理所需要关注的版本、客户、模块等信息，则可以通过需求的不同属性甚至标签等方式来实现。

使用CodeArts进行需求结构化管理的一种方式 接下来，介绍推荐的一种方式。 第一步：建立CodeArts项目 针对一个产品或系统，建立一个CodeArts项目，该产品或系统的所有需求，都在此CodeArts项目里面进行管理。 第二步：确立Epic-Feature-Story的需求结构 Epic要承载业务价值，即Epic需要是对企业本身是有意义的。 将产品或系统的业务模块作为Epic，比如用户中心、购物车、配送管理等，比如一家货运云商的油卡业务，就适合作为一个Epic，针对油卡的各种功能，就可以作为Feature展开。 Feature要承载用户价值，也即对于用户来说，是可以理解这个Feature，且认可其价值的，通常Feature也是用户可以直接感知、可以操作的。 针对前面业务模块的具体展开、拆开，就可以作为Feature，也可以简单理解为一个业务流程、用户流程；以前面用户中心为例，用户信息可以是一个Feature、我的订单可以是一个Feature、地址管理可以是一个Feature；或者以油卡为例，购买油卡、我的油卡等就可以作为不同的Feature。 Feature往往还是有些大有些复杂，那就需要拆成颗粒度更小的Story，用来承载一个具体的用户操作。 例如可以查看到所有订单、可以过滤订单、可以修改用户昵称、可以自定义头像等功能。 再往下一级的Task，就主要是为了分工协作，也即是说，如果Story可以包干到人，那么不再拆分Task也是可以的。 Task往往是关于工程师需要具体做的工作，也就跟业务价值、用户价值、用户单步操作都没有了什么关系，通常都是把Story按照具体的组件、模块进行拆分，例如前端、后台、数据库之类的，或者是按照工作流程分工来拆分，例如UCD、开发、测试、部署等。 如下图所示，各层级为： Epic：用户中心。 Feature：地址管理。 Story：用户可以新建地址。 Task：【Web端】页面入口及地址编辑表单、【数据库】用户地址数据表设计和实现。 图1 需求规划 第三步：通过工作项的属性，对于不同模块以及版本进行管理 工作项详情页面对应属性如图2所示： 模块：Web端。 发布版本号：1.0.1.2。 图2 属性示例 对于模块清单的维护，可以在工作项编辑状态，单击“模块”字段右侧的，即可在弹出窗口进行操作，可以添加、修改、删除模块。 图3 编辑模块 在工作项管理的Backlog视图下，通过“设置显示字段”增加“模块”字段后，既可以很方便地看到工作项相关的模块，也可以进行过滤。