背景目前，Scrum和看板已成为了帮助团队贯彻敏捷的重要方法，我们也能经常看到敏捷爱好者在关于二者在各类社区、场合的讨论。无论是交流分享还是企业的咨询实施，关于Scrum和看板的讨论就一直没有停歇过。那么，对于一个正准备实践敏捷的团队，到底应该如何选择呢？问题分析一般来说，客户会纠结Scrum和看板的选择问题，主要是因为不清楚Scrum和看板方法的区别，不知道哪种更适合目前的项目或团队，也不清楚Scrum和看板方法能应对哪些场景。首先，从Scrum和看板方法的比较来了解两者的不同，见下表：描述Scrum看板方法目的探讨未知，处理新的、复杂项目自我检讨、消除浪费、得到好的效能团队角色产品负责人，Scrum Master，开发团队没有指定的角色度量指标团队速率生产周期、WIP（在制品）多变性承诺在Sprint周期不发生改变变化随时可能发生交付周期固定的Sprint时间盒完成一项工作的时间表： Scrum和看板方法的特征比较如上表所示，Scrum和看板方法在不同方面特征有所不同，企业在选择使用Scrum和看板方法的时候，可以根据上表中二者的特征并结合不同的实际情况，做出选择，具体参考如下情况和详细解释：情况Scrum看板方法团队所做的项目VUCA、需要一定的可预测性√团队优先考虑客户需求的响应能力、经常应对紧急情况改变优先级√项目需要有固定的迭代交付时间（2到4周）√项目的初期探索迎合市场的阶段√团队规模较小（不足5人）或较大(9人以上)√表： Scrum和看板方法的选择情况1：团队所做的项目VUCA、需要一定的可预测性在VUCA（详见参考附录中的解释）的时代，很多团队做的是易变的、不确定的、复杂的、模糊的项目，如互联网项目。针对于这样的特性，团队如果需要在某特定的时间发布或推广产品，以达到一定的市场预期的话。团队一般会将需求进行拆分和细化，如 Epic、 Feature、 User Story 、Task后，制定发布计划。随着拆分为较小的需求后，团队可以通过检查每个Sprint的进度并进行调整，从而预测交付时间，进而确保整个项目成功交付，Scrum是首选的方式。情况2：团队优先考虑客户需求的响应能力、经常应对紧急情况改变优先级Scrum的价值观之一是，承诺在Sprint内对计划不做修改，如果团队经常会应对紧急情况或者修改任务的优先级，那么看板方法因其灵活的工作流程可以更好的适应。情况3：项目需要有固定的交付时间（2到4周）在Scrum中每个Sprint的时间长度是固定（2到4周），并且每个Sprint结束后会交付潜在可交付产品增量，如果项目需要有固定的交付时间（2到4周），那么Scrum是比较好的选择。情况4：项目的初期探索迎合市场阶段以市场为导向的产品，产品越年轻，使用Scrum方式就越可能受益。因为在开发全新产品，尝试实现PMF（产品市场契合）或努力保持产品增长时，通常面临许多未知因素以及大量不确定性和变化。要通过迭代不断的输出增量以获取市场的反馈，进而更快更好的迎合市场的需求，所以Scrum是比较好的选择。（详见参考附录中的Scrum适合你的项目吗？）情况5：团队规模较小（不足5人）或较大（9人以上）Scrum团队理想的规模是2个披萨团队，给出的建议是5到9人，如果团队不足5人，在人员方面可能无法发挥Scrum的最大功效或存在一定上的浪费，那么建议使用看板方法。（Scrum of Scrums 不在此FAQ讨论范围内。）解决措施目前很多企业和团队，都是通过工具在实践Scrum或看板方法，华为云的DevCloud也是基于敏捷思想设计的DevOps工具链（更多了解请见附件或官网），以DevCloud为例，在DevCloud中提供了更加鲜明化的Scrum项目和看板项目的选择，具体可以参考根因分析中针对不同情况选择不同的项目（详见，表： Scrum和看板方法的选择）从目的来说，Scrum主要是为了探讨未知，处理复杂（VUCA）项目从而提升效率，而处理和效率的字眼往往是和时间关联起来的，如要在一个什么样的时间得到什么样的结果，这也是要求了时间把控上或者说做计划的能力，当团队所做的项目为了这样的目的，那肯定是选用Scrum，哪怕团队的规模没有达到Scrum所推荐的5到9人，或者是团队要为估算所浪费的时间开销而苦恼，又或者说在一个Sprint中需求经常变更等情况。因为不管是人数的问题也好、还是估算的问题也好、又或是需求变更的问题都是可以通过团队在回顾中不断的分析、复盘、总结慢慢优化的，如估算问题，那就提高估算能力减少开销；如时间开销问题，可以通过熟练度的提升、形式的改变来较少开销。总之，只要核心是不变的或者说关注点是围绕Scrum目的就应选择Scrum项目，典型项目有：新的应用程序开发、品牌发展、营销活动、具有季度/定时发布时间表的大型企业等。相反，如果团队的关注点就是以优先响应需求的能力，需求是必须要随时跟进和变更的，项目的可预测性、产品市场的契合度等的优先级并没有成为超过响应能力的话，那么看板项目就是一种更好的选择，因为这正是看板方法的优势，让价值能够快速的流动起来，以更快的满足客户的需求，典型项目有：生产支持、补丁发布、UX设计、营销宣传材料、新闻稿等。所以，对Scrum项目和看板项目的选择上，一定参考的是客户认为最重要的关注的点是什么。以目的驱动做响应的选择。另外，在DevCloud的Scrum项目也提供了看板的视图，可以很好的在Scrum的项目中使用看板方法，进而让Scrum可以和看板有效的结合起来，发挥更强大的效能。在DevCloud中， Scrum项目是以Scrum框架为核心的，提供用于处理探讨未知，处理新的、复杂项目的项目类型。Scrum项目提供了类似思维导图的方式，用来整理需求做项目规划，并提供了Epic 、Feature 、Story、Task的四级需求划分，如下图。在Scrum项目中的迭代视图中，未规划工作项相当于 Scrum中的 Product Backlog，当前的迭代相当于Sprint Backlog，可以很好的结合Scrum中Product Backlog和Sprint Backlog两个工件，如下图。Scrum项目提供了通过切换卡片模式转为看板视图，以用来Scrum和看板有效的结合起来，如下图。更多操作和相关内容请见参考附录中DevCloud项目管理用户指南。在DevCloud中，看板项目是以看板方法为核心，为团队提供流程可视化、限制WIP， 加速价值流动，以更快的满足客户的需求，看板项目中提供了非常友好的可视化看板板，默认提供了，新建、进行中、测试中、已关闭等状态列，用来标示任务的状态，可以通过拖拽的方式来实现任务的价值流动。团队在使用看板项目时，还可以修改默认提供的列（修改列名等）和自定义列以实现项目或团队定制化需求。此外，看板项目还提供了很多过滤和显示的快捷和便利操作等。更多操作和相关内容请见参考附录中DevCloud项目管理用户指南。参考附录Scrum适合你的项目吗？DevCloud项目管理用户指南Scrum 指南2007版VUCA 维基百科

概述围绕项目需求变更频繁，如何做好有效的需求管理和规划，本文从背景、问题分析、解决措施、如何进行需求结构化管理？如何进行需求优先级管理？如何避免重要需求遗漏？几个方面进行了细致解答。全文字数：__2662 字__，预估阅读时间：___7 分钟__。全程干货。背景不管是项目型软件开发还是产品型软件开发，需求变更频繁都是影响研发效能的第一号因素，在2019年中国DevOps现状调查报告中也可以发现，超半数企业认为需求的频繁变更是阻碍软件按时交付的主要原因。解决或缓解需求变更频繁带来的影响，是势在必行的重要工作。联想阅读2019年中国DevOps行业现状报告：中国信息通信研究院、华为云DevCloud、南京大学联合发布    问题分析由于每家企业的情况不同，包括客户合作方式、人员能力水平、研发流程等各方面的差异，同样是需求变更频繁，所体现出来的具体症状却有所不同，导致问题发生的根因也可能不同，所应采取的措施也需要根据实际情况来选择。根据我们的观察以及与企业交流的经验发现，一般都体现为如下几种情况，接下来我们结合这些情况的部分实例来分析：第一种情况：需求杂乱、经常变更，难以管理；第二种情况：领导或客户时不时地要把某些需求提前，打乱了开发计划；第三种情况：做着做着发现有些需求遗漏了；【第一种情况】软件项目前期结构清楚，开发到后期，需求变化多而细，如何管理，如何规划。困扰我们的是前期需求不明确、不完善，导致后期需改动，需求需要发生变更。而使用DevCloud的项目管理的支持不够。我们发现出现这种情况，往往跟客户未能正确使用需求规划有一定关系，存在着需求层次划分不清晰、缺少规范机制等问题。例如，某客户规划一个用户登录功能，按照下图所示规划需求。用户会将其中管理员登录的Task放在第一个版本中发布，后期又增加了一个手机号登录的需求，设置成Task放在第二个版本中发布，这样一个Story里面存在多个不同版本（或迭代）发布的Task，不方便管理。由此我们可以将这个问题的根因定性为如何进行需求结构化管理的问题：没有区分跟随项目进展而持续产生的碎片化需求和系统/产品持续完善的功能特性；对DevCloud提供的Epic-Feature-Story的需求结构理解有误，未能正确使用；【第二种情况】软件项目进行过程中，领导需要提拉需求，在敏捷研发模式中该如何去操作？提拉需求的意思也就是要将某些需求的优先级提高，要求团队先实现它们，因而我们将此问题定性为需求优先级管理的问题。解决此问题，我们需要了解：为什么领导会要提拉需求？如果是合理的，那么我们就应该提升响应能力、优化工作安排流程，使得优先级调整对研发进展带来的影响最小化，且我们能够尽快地响应领导需要，先交付被提拉的需求；这种情况发生频率有多高？如果是经常发生，那就是一种常态，而且是一种不好的常态，那我们需要去思考是什么导致了这种常态发生，并考虑如何从流程、制度、协作模式或人员能力等方面去做调整，减少过程中提拉需求情况的发生；如果是偶尔发生，那就可以特事特办，为例外情况调整流程、制度反而会加重常态工作的负担，没有必要；需要提拉的需求有无共性特点？比如是否都跟某个客户有关，或者跟某个功能域（如退款）有关？如果能够找到共性，那我们就可以针对这些共性去思考针对性的解决方案。【第三种情况】由于外界原因经常会临时增加一些紧急需求，并且这是目前常态临时增加需求，首先是一个如何处理突发需求的问题；紧急需求，也就是说需要马上就做，而且是插队，那就不仅仅是紧急，肯定也是重要的需求，不然不需要插队先做，所以这还涉及到需求优先级管理的问题。但是当两种情况合在一起，我们需要将它定性为是重要需求遗漏的问题，反问一句就是 —— 为什么这些紧急重要的需求无法更早预见？同样的，我们需要了解：具体是哪些外界原因？这些原因是否有共性，有的话，那就针对性处理；增加的需求有无共性特点？有的话，可以针对性处理；临时增加有多临时？我们是否有提高或改善响应能力的空间，如果我们可以更快调整和响应，使得这些临时需求对我们产生不了什么影响，那么这个问题也就不再是问题了；既然是常态，为何我们的流程没有做出调整去应对？是调整过流程或工作方式，还是无法解决问题，还是说不知道该怎么调整流程或工作方式去适应？解决措施综上，前面几种参考情况经分析后得出了根因，基于这些根因，我们将所要解决的问题重新描述如下：如何进行需求结构化管理？如何进行需求优先级管理？如何避免重要需求遗漏？如何进行需求结构化管理？首先，并不是说任何情况下都需要进行需求的结构化管理。只有在需求较多、且需求之间存在关联，而且即便是已经实现的需求也需要进行一定的管理、维护的情况下，我们才需要去思考需求结构化管理的问题，此时，我们需要使用DevCloud提供的Scrum项目模板，因为里面有Epic-Feature-Story的需求结构，以及需求规划功能可以辅助我们进行需求的结构化管理。那么我们应该以什么为脉络来建立这个结构呢？这就意味着，我们的需求结构化管理，需要以产品或系统的功能特性的脉络为依据。而软件项目管理所需要关注的版本、客户、模块等信息，则可以通过需求的不同属性甚至标签等方式来实现。简单来说，可以通过如下三个步骤来完成：针对产品或系统建立DevCloud项目确立Epic-Feature-Story的需求结构对不同模块以及版本的管理，可以通过工作项的属性来进行管理联想阅读 【华为云 · 敏捷智库】如何进行需求结构化管理？如何进行需求优先级管理？需求优先级的管理，其实是为了帮助我们确定先做哪个需求后做哪个需求，从而可以最大化我们的回报、最小化我们的风险或投入。要做好优先级管理，或者更直接来说是优先级顺序管理，我们需要做到如下几件事情：确定优先级模型：需要考虑的因素以及因素的综合判断原则，比如Kano模型；排定需求优先级顺序：因素的具体量化和排序标准，例如成本收益法是按照收入还是按利润的多少来排序；调整需求优先级顺序；改进优先级模型：根据反馈调整模型或模型的落地实施细节，以提升效果；联想阅读【华为云 · 敏捷智库】如何进行需求优先级管理？    如何避免重要需求遗漏？根据重要需求遗漏的事前、事中、事后的不同时间点，我们可以采取不同的措施。参照八二原则，我们需要确保常态问题有对应的处理方式，软件项目成员按照既定方案进行处理即可，而特殊情况要有应急机制指导现场处理、事后再复盘总结。事中的处理：按照常规做法进行处理，或是特殊情况特殊处理，先解决眼下的问题；事后的处理：基于模型或思路进行复盘，并落实为新的常规做法或特殊情况处理方式；事前的处理：明确如何区分常规情况或特殊情况，并制定相应的处理方式或应急机制；联想阅读【华为云 · 敏捷智库】如何避免重要需求遗漏？参考附录相关文章敏捷联盟网站上的Epic术语解释：https://www.agilealliance.org/glossary/epic维基百科上的Kano模型词条：https://en.wikipedia.org/wiki/Kano_model相关书籍Mike Cohn：《用户故事实战》杰拉尔德·温伯格：《成为技术领导者》邱昭良：《复盘+：把经验转化为能力》

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

需求优先级管理四步走需求优先级的管理，其实是为了帮助我们确定先做哪个需求后做哪个需求，从而可以最大化我们的回报、最小化我们的风险或投入。要做好优先级管理，或者更直接来说是优先级顺序管理，我们需要做到如下几件事情：确定优先级模型：优先级看起来像是一个简单直接的值，但实际上它是一个基于多种因素进行综合判断之后得出的一个值，这些因素和判断原则，就是我们所说的优先级模型；排定需求优先级顺序：将需求代入优先级模型进行计算，得出每个需求的优先级顺序；调整需求优先级顺序；改进优先级模型：如果经常发生需要调整需求优先级顺序的情况，那么最好是对这些情况进行一定的复盘分析，如有必要，修正或改进当前的优先级模型，让它可以适应实际情况，以避免调整优先级顺序的情况反复发生；另外就是需求可能已经交付或发布上线，但是该功能的实际用量或价值不吻合预期，则需要反思我们对这些需求的分析和判断，究竟是分析判断有误还是优先级模型有误，并进行相应的调整；一，确定优先级模型成本收益分析就是最简单的一种优先级模型，重要/紧急的四象限也是一种优先级模型，Kano模型也是一种优先级模型，它们都可以帮助我们去确定需求的优先级顺序。模型可以简单也可以复杂，根据企业实际需要来确定即可。务必切记优先级模型不应追求完美，以避免模型过于复杂，导致优先级管理的管理开销过高，喧宾夺主，反而影响了需求的开发和交付。如果较为简单的模型就可以满足需要，就应该首选使用较简单的模型。企业可以从简单开始，逐渐完善，不需要也不应该在一开始就追求过于复杂的模型。简单可以体现在考虑的要素更少，比如成本收益分析只考虑两个要素，就比考虑更多要素的模型简单；简单还可以体现在要素的取值范围更窄或精度要求更低，比如预计利润只要求评估高/中/低，就比要求以万元为单位评估预计利润更简单；优先级模型确定后，可以进行存档管理，注意该模型宜供所有人或相关人员查阅学习，比如录入到DevCloud的Wiki知识管理系统就是一个很好的做法，如下图：二，排定需求优先级顺序比如成本收益分析，可以是把预期市场收入作为收益值，把预期研发投入作为成本值，计算差值，或计算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加权值综合值优先级顺序需求A10370.10.7233%12.333.032需求B5410.10.125%10.250.354需求C211470.10.750%10.51.23需求D2110.10.1500%15.05.11 根据上述表格中所得出的结果，我们就应该依序将需求D、需求A、需求C、需求B排入开发计划。优先级顺序，在DevCloud中，可以使用工作项的“优先级顺序”字段来实现，该字段取值范围1-100，如下图所示。三，调整需求优先级顺序调整顺序本身非常简单，只要在DevCloud中重新设定该需求的“优先级顺序”字段的值就可以。但重要的是，需要将优先级顺序调整这件事情记录下来，包括为什么要调整、具体如何调整的、调整背后的具体考虑等信息都记录下来，同样，建议记录在Wiki知识管理系统中。用于后续的复盘回顾中作为参考信息，比如每个Sprint/迭代结束时的回顾会议上拿出来进行探讨。四，改进优先级模型市场在变化，用户在变化，产品在变化，优先级模型自然也必须跟随着发生变化。我们可以定期或不定期的安排对需求优先级模型进行复盘分析，找出可以改进或优化的点，并跟进落实。可以是定期开展，例如每个月进行一次复盘，把这个月所涉及的需求都拿出来审视，或者是其中有调整过优先级顺序或者出现过问题的需求拿出来审视均可；也可以是不定期，以问题驱动的方式，比如某天进行了大量需求优先级的调整，那么当天或第二天就可以临时召集一次复盘会议，分析为什么会发生这种情况。复盘要有好的效果，就必须尽可能的复原问题发生当时的情况，所以前面提到的Wiki记录就变得非常重要。复盘会议应提供尽可能多的相关信息以便参会人员了解情况，充分探讨。复盘过程中，我们要定位出正确的根因，是模型本身设计有问题（例如要素和尺度），还是取值、加权有问题（比如某类需求的预计收入就是非常难估算），还是过程管理的问题（比如过早进行估算，因为缺乏必要信息，导致估算得出的优先级顺序不准确），并进行针对性地改进。参考附录相关文章维基百科上的Kano模型词条：https://en.wikipedia.org/wiki/Kano_model相关书籍杰拉尔德·温伯格：《成为技术领导者》邱昭良：《复盘+：把经验转化为能力》

为什么要进行需求结构化管理？首先，并不是说任何情况下都需要进行软件项目需求的结构化管理。如果只是事务性质的管理需求，也就是有需求了能记录、能跟踪状态、实现之后不需要继续跟踪、也不需要维护需求与需求之间的关联，那么不需要思考需求结构化管理这个问题。这种情况下，不管是用DevCloud的Scrum项目模板还是看板项目模板，都可以管理好需求和软件项目。只有在需求较多、且需求之间存在关联，而且即便是已经实现的需求也需要进行一定的管理、维护的情况下，我们才需要去思考需求结构化管理的问题，此时，我们需要使用DevCloud提供的Scrum项目模板，因为里面有Epic-Feature-Story的需求结构，以及需求规划功能可以辅助我们进行需求的结构化管理。以什么为依据进行需求结构化管理？需求结构化管理，应该以什么为脉络来建立这个结构呢？软件研发无非是分为项目型软件研发和产品型软件研发两种，项目通常来讲都是临时性的，或者说短期性的，而产品或者软件系统是长期性的，或者说我们会持续维护、更新其功能特性的。项目复项目，我们很可能通过持续地完善和刷新同一套软件产品或系统来达成项目目标，交付软件项目所要求的功能特性的。这就意味着，我们的需求结构化管理，需要以产品或系统的功能特性的脉络为依据。而软件项目管理所需要关注的版本、客户、模块等信息，则可以通过需求的不同属性甚至标签等方式来实现。使用DevCloud进行需求结构化管理的一种方式接下来，我们介绍推荐的一种方式。一、针对产品或系统建立DevCloud项目也即一个产品或系统，建立一个DevCloud项目，该产品或系统的所有需求，都在此DevCloud项目里面进行管理。二、确立Epic-Feature-Story的需求结构这个产品或系统的业务模块作为Epic，比如用户中心、购物车、配送管理等，比如一家货运云商，他们的油卡业务，就适合作为一个Epic，针对油卡的各种功能，就可以作为Feature展开；Epic要承载业务价值，也即Epic需要是对企业本身是有意义的；针对前面业务模块的具体展开、拆开，就可以作为Feature，也可以简单理解为一个业务流程、用户流程；以前面用户中心为例，用户信息可以是一个Feature、我的订单可以是一个Feature、地址管理可以是一个Feature；或者以油卡为例，购买油卡、我的油卡等就可以作为不同的Feature；Feature要承载用户价值，也即对于用户来说，是可以理解这个Feature，且认可其价值的，通常Feature也是用户可以直接感知、可以操作的；Feature往往还是有些大有些复杂，那就需要拆成颗粒度更小的Story，用来承载一个具体的用户操作，例如可以查看到所有订单、可以过滤订单、可以修改用户昵称、可以自定义头像等功能；再往下一级的Task，就主要是为了分工协作，也即是说，如果Story可以包干到人，那么不再拆分Task也是可以的；Task往往是关于工程师需要具体做的工作，也就跟业务价值、用户价值、用户单步操作都没有了什么关系，通常都是把Story按照具体的组件、模块进行拆分，例如前端、后台、数据库之类的，或者是按照工作流程分工来拆分，例如UCD、开发、测试、部署等；如下图所示，各层级为：Epic：用户中心Feature：地址管理Story：用户可以新建地址Task：【Web端】页面入口及地址编辑表单、【数据库】用户地址数据表设计和实现三、不同模块以及版本的管理可以通过工作项的属性来进行管理，如下图：模块：Web端发布版本号：1.0.1.2至于模块清单的维护，可以在工作项编辑状态，点击“模块”字段右侧的小齿轮图标，即可在弹出窗口进行操作，可以添加、修改、删除模块：在工作项管理的Backlog视图下，通过“设置显示字段”增加“模块”字段后，既可以很方便地看到工作项相关的模块，当然也可以进行过滤：参考附录相关文章敏捷联盟网站上的Epic术语解释：https://www.agilealliance.org/glossary/epic相关书籍Mike Cohn：《用户故事实战》

华为在网络全云化的基础上将AI技术引入到电信网络中，推出 iMaster NAIE 网络人工智能引擎。旨在结合电信领域应用场景，使能网络达到自动（业务自动部署，自动运行）、自愈（故障自动恢复）、自优（网络自我优化）和自治 （网络自我演进）的自动驾驶网络，提升整个网络的效率，降低 OPEX。本白皮书将结合电信网络智能化的市场趋势大背景，阐述华为在该领域的实践落地。包括华为自动驾驶网络 战略解读，iMaster NAIE 网络人工智能引擎（包括通信智能平台，AI 模型服务，部署方案）以及通信智能典型 应用场景探索。希望对与我们一起在通信网络智能化探索过程中的同仁有所帮助。