华为云用户手册

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

排定需求优先级顺序 比如成本收益分析，可以是把预期市场收入作为收益值，把预期研发投入作为成本值，计算差值，或计算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工作项优先级顺序展示

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

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

方案架构 “凤凰商城”示例程序架构 “凤凰商城”示例程序的架构图如图2所示。 图2 凤凰商城技术架构图 示例程序由表1中的5个可以独立开发、测试和部署的微服务组件构成。 表1 凤凰商城微服务组件表 微服务组件 说明 Web用户端服务器（对应样例代码中的“Vote”功能） 业务逻辑：用户可以通过浏览器访问此服务的WebUI。当用户在特定商品上单击“Like”时，服务将用户所选择物品的记录保存在Redis缓存中。 技术栈：Python、Flask框架。 应用服务器：Gunicorn。 Web管理端服务器（对应样例代码中的“Result”功能） 业务逻辑：用户可以通过浏览器访问此服务的WebUI，会动态显示用户端UI上用户单击“Like”的统计数据，此数据来自PostgreSQL数据库。 技术栈：Node.js、express框架。 应用服务器：server.js。 后台订单批处理程序（对应样例代码中的“Worker”功能） 业务逻辑：此服务为后台进程，会监控Redis缓存中物品记录，并将新纪录取出并保存在PostgreSQL数据库中，以便管理端UI可以抽取数据进行统计显示。 技术栈：.net core或者Java（此服务提供两种技术栈实现了同样的功能，可根据需要修改配置选择其中一个作为运行时进程）。 订单缓存 业务逻辑：此服务作为用户端UI服务的数据持久化服务存在。 技术栈：Redis 订单数据库 业务逻辑：此服务作为管理端UI服务的数据源。 技术栈：PostgreSQL “DevOps全流程样例项目”构成 “DevOps全流程样例项目”是一个Scrum类型的模板项目，项目中预置了部分服务的使用模板。项目实践过程中涉及到的产品及服务如下表。 表2 实践涉及产品/服务列表 服务 说明 软件开发生产线 需求管理 预置3个已规划并已完成的迭代、项目的模块设置、以及若干统计报表。 代码托管 预置代码仓库“phoenix-sample”，存放项目示例代码，任务详情介绍请参见管理代码。 代码检查 预置4个任务，任务详情介绍请参见检查代码。 编译构建 预置5个任务，任务详情介绍请参见构建应用。 制品仓库 用于存储通过构建任务生成的软件包。 部署 预置3个应用，应用详情介绍请参见部署应用。 测试计划 功能测试用例库，预置十余个测试用例，任务详情介绍请参见管理项目测试。 流水线 预置5条流水线，流水线详情介绍请参见配置流水线。 说明： 购买专业版或企业版CodeArts套餐的用户，创建示例项目后可见5条流水线；购买体验版或基础版CodeArts套餐的用户，创建示例项目后只可见流水线“phoenix-workflow”，升级套餐至专业版或企业版后，需重新创建示例项目才可见5条流水线。 其它组件和服务 统一身份认证服务 用于管理账号。 容器镜像服务 用于存放构建任务生成的Docker镜像。 云容器引擎 用于软件包部署，与ECS部署属于两种不同的部署方式。 弹性云服务器 用于软件包部署，与CCE部署属于两种不同的部署方式。

背景信息 华为端到端（HE2E）DevOps实施框架，是结合了多年研发经验并集合了业界先进的实践所形成的一套可操作可落地的敏捷开发方法论，如图1所示。 图1 HE2E DevOps实施框架 规划和设计 步骤①和②是业务（或者是客户）与技术之间进行产品规划，梳理产品整体脉络，以及进行产品规划实施设计，并控制需求粒度与拆分的过程。 软件开发的本质是为了解决问题，提供用户价值的，而不仅是为了提供功能。影响地图就是用来鉴别用户需求是什么，深层的根因是什么。 用户故事就是目标和需求的载体，以用户的场景来讲故事，便于在客户、业务与开发之间进行信息的传递。在这个过程中，独立的需求条目的堆积，很容易导致只能看到各个需求条目，不能从整个解决方案思考需求。用户故事以用户使用的场景为主线，将大的阶段点，及其细分的活动，以树状的结构进行梳理和展现，既可以看到独立的需求条目，又能够看到整体需求场景。 计划和跟踪、迭代开发 步骤③~⑩是Scrum框架过程，是主要的管理实践。 Scrum定义了一个相对完整的敏捷过程管理的框架。在CodeArts中，将Scrum的框架与团队日常的开发活动，很好的融合起来。主要的过程产物包括产品故事列表、迭代故事列表、潜在可交付的产品增量、以及过程中产生的问题列表；核心的团队活动包括Sprint计划会议、团队每日站会、Sprint演示会议、Sprint回顾会议等会议、以及团队的日常更新。 同时，将Kanban方法与Scrum框架进行了结合，团队借鉴Kanban方法中的精益思想，可视化价值流，发现并解决阻塞与瓶颈，加速价值流交付，并加快反馈回路，持续进行改进。 持续交付 从步骤⑪开始，进入到工程实践，也就是通常说的CI/CD过程。 持续交付以代码配置管理为基础，除了传统意义的代码资产安全与管控、多人并行开发、版本与基线管理外，也体现了团队的协作与沟通。 代码检查（即静态扫描）、自动化的构建、各阶段的自动化测试、以及相应的自动化部署过程，都被有机的串联在流水线上。 除了代码检查、构建、测试、部署等动态的阶段与活动，还有制品管理，以及各级的环境管理，包括开发环境、测试环境、准生产环境，以及生产环境。 持续交付流水线就是将整个持续交付中，都有哪些阶段，分别运行在什么环境，每个阶段执行什么活动，准入与准出的质量门禁，以及每个阶段的输入与输出的制品进行管理。

测试缺陷 缺陷修复后，还需要测试人员进行测试，因此缺陷流转到测试环节后，测试人员将根据缺陷的描述、分析原因、修复方案，在缺陷发现环境中进行回归测试并输出测试报告。 测试人员回归验证缺陷确实已经修复的，可单击“测试通过”并填写测试报告。 图1 填写测试报告 回归测试不通过的，可单击“退回到修复”并填写测试报告，让修复责任人继续修复。 图2 填写缺陷退回到修复的原因 如果当前缺陷暂时无法继续回归验证，也可以单击“挂起”，终止作业。 图3 填写缺陷挂起原因 父主题： 模拟案例

问题分析 由于每家企业的情况不同，包括客户合作方式、人员能力水平、研发流程等各方面的差异，同样是需求变更频繁，所体现出来的具体症状却有所不同，导致问题发生的根因也可能不同，所应采取的措施也需要根据实际情况来选择。根据我们的观察以及与企业交流的经验发现，一般都体现为如下几种场景： 需求杂乱、经常变更，难以管理。 需求优先级的不断调整，打乱了开发计划。 需求遗漏。 接下来我们结合这些情况的部分实例来分析：

解决措施 综合前面几种参考情况经分析后得出了根因，基于这些根因，可以将所要解决的问题重新描述如下： 如何进行需求结构化管理？ 如何进行需求优先级管理？ 如何避免重要需求遗漏？ 如何进行需求结构化管理？ 首先，并不是说任何情况下都需要进行需求的结构化管理。只有在需求较多、且需求之间存在关联，而且即便是已经实现的需求也需要进行一定的管理、维护的情况下，才需要去思考需求结构化管理的问题，此时，团队需要使用CodeArts提供的Scrum项目模板，因为里面有Epic-Feature-Story的需求结构，以及需求规划功能可以辅助团队进行需求的结构化管理。那么团队应该以什么为脉络来建立这个结构呢？这就意味着，团队的需求结构化管理，需要以产品或系统的功能特性的脉络为依据。而软件项目管理所需要关注的版本、客户、模块等信息，则可以通过需求的不同属性甚至标签等方式来实现。 简单来说，可以通过如下三个步骤来完成： 针对产品或系统建立CodeArts项目。 确立Epic-Feature-Story的需求结构。 对不同模块以及版本的管理，可以通过工作项的属性来进行管理。 更多详情请参考如何进行需求结构化管理。

解决措施 如何玩转站会？我们按照如下思路学习下。 图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人左右。 最后再强调一点，并不是要求团队一定要按以上15key进行开站会，15key只是在很多实践中总结出来的一些经验，曾经解决过很多问题。对于每个具体团队需要结合实际情况进行选择应用15key。 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 站会常见问题 如何正确的开站会？站会的意义在哪里？可以不开站会吗？这些问题一直困惑着不少的团队。

项目经理创建项目 项目经理进入控制台，根据提示输入已注册的账号。 单击“立即使用”，进入软件开发生产线首页。 注册的企业或个人用户的管理员登录方式：选择“账号登录”。 普通用户（即管理员创建的用户）登录方式：选择“IAM用户登录”。 在软件开发生产线首页单击“新建项目”，项目类型选择“看板”。 设置看板项目信息，如图2所示。 图2 设置看板项目信息 单击“确定”完成看板项目的创建。 默认进入看板项目详情页面，并提示“项目创建成功, 邀请成员”。 图3 看板项目页面

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

问题分析 一个项目在从小到大的过程中，项目团队也势必扩张，面临新员工的加入。新员工对刚接触的项目不够熟悉，所以针对新员工的培养（培训）是非常有必要投入人员配置的。 项目发展过渡到平稳期的时候，可能会因为公司体质、薪资待遇、员工身心疲惫等原因，出现老员工的离职等情况，如果离职的老员工是核心骨干，就可能导致某些如业务无人知晓、关键技术断层等风险，在此期间，也包括老员工随着项目的延续，慢慢产生了对原来工作厌倦，或者因认知的提升以想要寻求一些新的工作内容，进而做了转型的打算。所以上述问题，如果没有得到较好的解决，将会影响到项目的进度和造成不必要的开销，甚至对于团队内部成长、自组织能力的发展建设也是不利的。 所以问题的关键，仍旧是新人的培养。

解决措施 一般来说，在针对新员工加入所带来的内耗、关键核心人员的离职风险、个人发展转型等情况的应对，可以从团队信息、工作方式以及知识管理三方面来通过建立信息管理库进行解决。 CodeArts是集华为研发实践、前沿研发理念、先进研发工具为一体的研发云平台（更多了解请见参考文档）。以CodeArts为例，在CodeArts中提供了知识库服务。知识库本身是一种以知识库文档为中心，共同创作为手段，依靠众人不断地更新修改为实现的多人协作的工具。我们可以通过知识库来管理和搭建项目或团队内的信息管理库，以达到有知识点可留存，有基本信息可查的目的，参考如下： 团队信息 用来记录项目团队的职能划分，职责担当等。当新人入职时，可以通过在知识库中的团队信息，了解团队的组织分工等。这样一方面可以让新员工对团队人员分工有所了解方便日后的交流，另一方面也能让具备较高能力的新员工根据团队组织分工现状提出改善意见等。 图1 团队信息 工作方式 团队需要制定团队内的工作方式，如对开发流程、代码的管理、需求的变更等，团队统一按照要求进行工作。当有新员工加入，可以通过知识库中的工作方式，了解相关流程等进而快速开展工作，同时也减轻了老员工在工作方式上对新员工的培训所带来的消耗。 图2 工作方式 知识管理 知识管理对于项目和团队是最重要的，大部分的产品都需要技术相关的输出整理，无论是基于现有项目进行维护，还是重构，开发新的应用，做知识整理都是不可或缺的。这种必要性在于，当新员工加入后，可以通过知识管理的学习了解项目所用技术框架，进而快速上手工作；当老员工离职，团队因有了知识库对技术、框架、业务等知识的相关管理，可以较好的应对离职所带来的没有backup、没有其他人懂某项技术、没有其他人知道某段业务逻辑等影响；当员工内部转岗或转变业务技术方向时，可以帮助其了解相关知识，有助于更好的帮助提升跨专业技能。 图3 知识管理 更多关于知识库的相关内容请参考需求管理用户指南-知识库。

背景 企业随着业务的扩张，需要新员工不断加入，经常会遇到这样的问题，其开发组长要对每一位新人交代相关的知识点、工作方式以及团队信息等，工作量在短期内激增。在一个项目中，随着时间推移、业务的扩张，项目中的核心成员，如项目经理、开发组长等往往都会面临如下几种情况和挑战： 新员工加入，需要诸多方面的培养（培训），以便能快速进入工作状态。 老员工的离职，导致项目中缺少能了解和掌握关键技术和业务的人员。 员工在工作了一段时间后，对自己的规划有了新的想法，从而想要转换工作方向。 那么，项目负责人应该如何应对这些事件呢？

修复缺陷 缺陷流转到修复阶段后，将由上一步指定的责任人进行修复。修复责任人将根据缺陷的描述、分析责任人提供的问题根因等信息，对缺陷进行排期修复。这里的排期就是前面所说的“修复PI/修复迭代”，修复责任人可以根据缺陷的严重程度、工作量大小等关键信息，将当前缺陷安排进修复计划中。 图1 修复缺陷 修复责任人完成修复作业并自测通过后，即可单击“提交到测试”并附上自己的修复方案，缺陷将流转到测试环节，由测试人员进行回归测试。 图2 填写缺陷修复方案 如果修复责任人认为问题根因定位不合理，也可以单击“退回到分析”并填写退回原因，将缺陷退回给上一步的分析责任人进行重新分析。 图3 填写缺陷退回到分析的原因 如果修复责任人认为该缺陷暂时无法修复，也可以单击“挂起”并填写挂起原因，暂时中止作业。 图4 挂起缺陷 图5 填写挂起原因 父主题： 模拟案例

为什么要进行需求结构化管理？ 并不是说任何情况下都需要进行软件项目需求的结构化管理。如果只是事务性质的管理需求，也就是有需求了能记录、能跟踪状态、实现之后不需要继续跟踪、也不需要维护需求与需求之间的关联，那么不需要思考需求结构化管理这个问题。这种情况下，不管是用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视图下，通过“设置显示字段”增加“模块”字段后，既可以很方便地看到工作项相关的模块，也可以进行过滤。

问题分析 首先，相对于传统开发模式的指派开发任务，我们需要知道为什么在敏捷开发中是领取任务。在敏捷中，不管是敏捷宣言还是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 Req打破了传统需求管理工具仅在研发阶段发挥作用的限制，将客户与市场需求也同步覆盖，提供了完整的客户需求采集、价值需求决策、交付与验收流程，让需求进展和动态客户实时透明，市场需求流动提速70%。 RR客户原始需求来自公司内部和外部的客户诉求，以客户视角描述的原始问题或者原始诉求，客户需求属于原始需求的一种类别。此类需求需要对应承接人分析后作出决定。RR客户原始需求的主要流程分为：提交、分析、规划、实现、交付、验收、关闭。 图1 原始需求状态转换流程图 父主题： 原始需求管理实践

分析原始需求 责任人在原始需求“分析”阶段定位诉求价值，分析决策后可选择“接纳”、“退回”或者“挂起”需求。 图1 分析原始需求 如果责任人分析后选择“接纳”需求，则必填对应的字段，明确需求后续的工作计划。 图2 接纳需求 如果责任人分析后选择“退回”需求，则必填对应的字段，分析不合理的因素。 图3 退回需求 当分析决策认为该需求处于非紧急状态，可选择“挂起”需求，并填写挂起原因，使需求进入挂起状态，暂时停止作业。 图4 挂起需求

我们如何灵活使用这些概念，让需求管理更为高效？ 为了加深对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）原则，定期梳理和排序优化，保证高优先级的需求优先实现和交付。 在整个过程中需要和客户一直保持沟通合作，这样才能保证我们实现的功能是客户真正想要的。

什么是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，并预估工时，通常在一天内完成。