用户故事驱动的敏捷开发之二——怎样讲用户故事？讲故事的过程通过3个步骤进行：找线索>画主线>规格化。找线索：画出故事的主角          用户不知道从哪里开始讲故事，这是我们会遇到的第一个问题。     其实这时候用户的内心感觉就如同看完一部电影以后走出电影院，试图给没有看过这个电影的朋友讲述。想一想在这个场景下你会如何开始？比如，如果你想给你的朋友讲述大话西游这部电影，那么讲故事的方式通常是：“孙悟空在500年前……然后紫霞仙子……”我们总会从某个角色的角度开始讲述一个故事。其实让用户讲故事的方式也一样，我们首先要引导用户说出这个故事里都有谁。一部电影是多个角色的故事线交织的结果，一个产品也是一样。有了这些角色，我们就有了可以抽取故事的线索。           这里我们可以借助2个工具来协助找线索：影响地图和用户画像。（关于影响地图和用户故事地图的概念和使用方法，不在这里多做赘述。）     你会发现，当团队开始整理不同的类型的用户的时候，他们已经开始自然的讲述故事，因为要把一个角色说清楚，你就必须考虑他要做的事情，故事自然就出来了。但是在这个阶段，我们切记不要过于发散，明确我们的目的是整理用户画像，只要不同用户类型间的边界清晰了，就可以结束，不要为细节纠缠。另外，在后续的过程中我们也会发现可能有些角色还需要添加进去，那么就到时候说。     最终将我们整理出的每个用户类型用一张即时贴粘在白板的最左侧（如下图），通常我们可以按照距离最终用户的远近来摆放这些即时贴，同时对每个角色进行编号，以便后续可以很容易的进行引用。画主线：使用影响地图画出故事主线       有了故事的主角，讲故事就相对容易了。在这个阶段，我们希望能够帮助团队尽量将故事的每一个步骤的都想清楚，通过在看板上进行可视化，我们就可以达到这个目的。这里， 我们可以使用如下图所示的简化版的影响地图。     标准的影响地图上有4个列，分别是WHY、WHO、HOW和WHAT，这种结构在进行比较大和模糊的目标讨论的时候，如战略规划，会很好用，因为HOW和WHAT比较容易区分；但是用在讨论用户故事的步骤时候，其实HOW和WHAT区别不大，如果坚持使用规范的影响地图会让团队感到迷惑。所以，我建议将HOW/WHAT合并。具体来说：    WHY：我们这个用户故事是什么？为什么我们要做这个故事？    WHO：这个故事里面都有哪些角色？    HOW/WHAT：这些用户为了完成这个故事，需要做些什么，怎样操作？      上图中是一个标准的“新用户注册”的用户故事，大家一定都非常熟悉。基本上这个故事就是浏览者通过登录>注册>填写信息>验证邮件提交注册\管理员审核\成为已注册用户后首次登录>完善资料。但通过卡片的方式将每个步骤放入白板后你会发现，整个团队可以很好的聚焦到很细节的问题上，同时又对整个故事具备全局观。如果不借助这种可视化方式，那么团队可能很容易丢失当前讨论的主线，从一个细节延展开到其他的部分去了。注意这里对每个用户故事进行了ID标注，同样也是为了后续可以容易进行引用。      你可能会问，那我用思维导图一类的工具不是更好么？电子化工具的好处是对信息的保存和分享方便，但是在团队讨论中，我们更加重视团队讨论的氛围、聚焦和整体效率，如果使用电子化工具，就无法让每个人都可以同时对这张图进行操作，而必须由一个人操作，其他人很容易走神，如果工具不熟练还会耽误时间。所以看上去白板貌似是可以淘汰的工具，但是对于团队讨论来说，它的效率高于任何的电子化工具。      如下图所示的一次用户故事讨论，可以看到大家都聚集在白板周围，整个讨论都是站立进行，任何人都可以随时发表意见，用手指着某个即时贴就可以开始说：“这个”步骤怎样怎样。如果没有可视化工具，或者使用电子化工具，希望每个人都可以用“这个”来聚焦所有人的注意力是很困难的，你可能需要解释“这个”到底是什么，又或者需要在电子工具中鼠标来点，如果操作者不是讲解者，那会更加麻烦。细节决定效率！规格化：使用用户故事地图进行功能分析       有了故事主线，我们就可以进行下一步的功能细化，这一步所产出的其实就是传统软件开发过程中的软件规格说明书。软件规格说明书对于开发人员实现产品功能非常重要，是软件开发中不可缺少的部分。很多人认为敏捷开发不需要文档，其实这是个巨大的误解，但是敏捷开发中的文档确实和传统的需求文档有很多区别：敏捷开发重视的是文档产生的过程，希望通过透明化的过程和集体讨论来确保内容的完整性，以及信息在过程中的传递。对于文档本身的格式没有具体的要求，只要确保讨论中的内容都被记录就可以。敏捷开发中的文档并不是用来传递需求的主体，人才是传递需求的主体。敏捷开发的文档是一份活的文档，所以我们更希望通过系统来记录需求，而不是传统的word或者excel等静态文档来记录。这些文档的作用是帮助团队成员来回忆和讲述，同时也作为过程追踪的手段。传统软件开发中往往有2份项目计划：一份列出需求并在需求上进行估算以便推导出预算；另外一份是时间和资源计划，这份计划又往往是按照阶段来进行规划的。敏捷开发只有一份项目计划，就是按照用户故事来组织时间、资源和各个阶段的跟踪，这其实就是用户故事驱动的敏捷开发的含义。      规格化的过程，我们可以使用用户故事地图的方式来进行，团队一起根据故事主线中的每个步骤进行讨论，分析出在产品的特定区域（模块）中的功能点，并使用技术人员容易理解的方式来描述这部分的功能。整个过程就是从将需求从用户角度的描述转换到技术实现角度描述的过程。在这个过程中你会发现一些在故事主线中看不到的技术细节。      这个过程中，我们希望综合考虑架构和测试的输入，这两个角色需要从自己的角度确保每个故事的分解都满足架构的要求，并且是可以进行测试的。由于每个用户故事都会穿越多个功能区域，架构师必须协助团队确保架构的扩展性、复用性以及性能等要求。对于测试来说，要确保每个用户故事都是可测试的，才能确保后续的测试计划和用例可以配合团队的开发过程，并按照故事逐个交付给用户。     如下图所示，将以上用户登录这个故事分解为功能点，展示在用户故事地图上，这是标准的用户故事地图格式：最上面2层是产品的功能区域（模块）。每个模块下面的功能点，来自于用户故事中的某个步骤的分析每个功能点的即时贴上标注出用户故事的ID，这样便于我们比对影像地图找到对应的功能点。一些在影响地图中没有明确列出的内容在这张图上被显示出来，比如后台管理和系统功能部分的内容。

用户故事驱动的敏捷开发敏捷开发现在已经不是新鲜事物了，从各种渠道都可以听到不同的团队实施敏捷的胜果，听的时候觉得很美，可是实际行动时就会发现那都是“别人家”的团队，结合自己的情况就会发现诸多问题。即使是仍然打算一试，也经常会不知如何开始。因此，我们希望能够找到一个可以遵循的敏捷项目管理模型。虽然，一个放之四海而皆准的方法是不存在的，但在更高的层面上，笔者仍然觉得这是可行的。也就是说，管理模型是一致的，但是其中采用的方法可能各有不同。最终目标是唯一的：打造一支可以快速适应变化的高质量团队，并输出高质量的产品！用户故事的主要问题用户故事可以帮助开发团队从用户的角度来理解需求，同时在交付的过程中按照用户可用的场景进行交付，确保开发团队可以持续的交付用户关心的功能。但是在实际开发中，团队往往不知道如何入手。如何用好用户故事，需要解决几个关键问题：如何产生用户故事，让用户将故事讲清楚？如何将用户故事的内容原汁原味的传递给开发团队？如何将用户故事中的内容转换为开发功能点，识别与其他功能点的依赖，形成详细的产品规格？如何在使用用户故事进行增量开发的过程中保持架构的稳定性，同时驱动架构的优化和演进？如何在开发过程中按照故事进行交付，协同开发、测试、架构以及UI/UE等团队？如何使用各种开发工具和平台，借助如任务跟踪、分支计划、持续集成、持续发布、自动化测试等工具让开发过程变得更加高效？用户故事的需求整理方式与传统需求的整理方式有很大的不同。传统软件开发中，我们依赖用户需求、技术需求、规格说明书等工具，试图使用规范的文档来解决需求收集和传递的问题。在这个过程中，我们将用户的需求转换成技术可以理解并可实施的规格。对于已经习惯了这种方式的人来说，要转换成使用用户故事的方式需要比较大的思维方式转变，大家往往遇到的疑问也是，难道使用用户故事就不需要规格了吗？其实不然，首先我们要了解用户故事到底是什么。用户故事是什么？很多人认为既然我们使用用户故事来替代传统需求，那么用户故事就是记录需求的方式了。其实不然，用户故事不是用来编写需求的，而是用来讨论和跟踪的。   1、使用用户故事的目的是让用户可以自然的讲述需求，这样才能确保信息的真实性。因为任何软件产品都是为了帮助用户完成某种任务，也可以说任何的软件产品或者系统都是通过交互来解决问题的，而交互的双方可能是人和系统，可能是系统和系统，也可能是模块和模块。这样理解的话，任何的需求其实都是某个个体（人、系统或者模块）在和其他个体进行交互的过程中，通过我们希望的行为方式，达到我们想要实现的目的。用户故事的3个关键点：人、过程和目的，可以帮助我们将这个行为方式讲清楚。在讲故事这个过程中，我们应该专注于故事主线，而不是如何实现。   2、一旦用户讲清楚了故事，下一步我们需要产生相应的可开发的功能点，这里我们需要专注于如何实现。一般来说，我们很难通过一个功能点来满足一个用户故事，而必须要不同的功能点配合完成。但是我们仍然必须确保讨论的范围仅仅围绕当前的故事，这时候技术人员非常容易发散，会考虑一些和当前功能点相关，但是和当前故事不相关的内容。例如：这个功能可能以后还要用到的，所以我们还要这样这样等等。这时，用户故事可以起到控制讨论范围的作用。你可能会觉得，技术人员的角度是对的，因为可扩展、可复用等是软件设计的基本原则。但是我们应该从发展的角度来看待这些问题，假设我们可以预见的其他用户故事确实会影响这个功能点，那么这样考虑是可以的，但是应该到讨论那个用户故事的时候再去考虑；如果我们没有其他可以预见的故事会影响这个功能点，那么这些所谓的扩展性复用性设计就是浪费，因为你不知道是否会需要这个功能。   3、讨论清楚了功能点，进入开发阶段以后，用户故事是控制技术团队开发进度和交付进度的引线，也就是我们应该按照故事一个一个的进行开发测试和交付。这样才能确保我们交付的永远和用户预期一致，所有的开发、测试投入都是可以产生用户认可的价值的。这个时候用户故事起到了跟踪和驱动开发过程的作用。通过以上分析，我们可以看到用户故事如何编写并不重要，重要的是它所驱动的过程，通过这个过程，我们可以把用户和技术团队紧密结合，并让大家产生对交付内容的统一认识。所以，用户故事是一种沟通工具，而不是编写工具或者需求模板！故事讲给谁？在真正开始将故事之前，我们首先要确保正确的人都参与进来。对于规划一款产品来说，你至少需要：最终用户代表、产品经理（或类似Scrum中的PO）、项目经理（或类似Scrum中的ScrumMaster）、团队中的技术骨干（那些对实现的业务很熟悉，对所要使用的技术或者系统很熟悉的技术人员）。技术骨干又可以分成架构、开发和测试三个不同技能的人。这样看来，你至少需要6个人参与这个讲故事的过程（除非有些人可以互相替代）。故事是讲给这里面每个人听的，同时也希望每个人都能够在讲故事的时候有所输入，而不仅仅是在听故事。最终用户代表：这些人一般会作为讲故事的主角，因为他们是最了解故事的人。但是最终用户代表只能用用户的角度来描述故事，这里会缺失很多技术细节。当他们开始讲故事的时候，技术人员就需要补充这些细节，将那些从用户角度看上去可能很简单的故事后面所涉及到的复杂度暴露出来。产品经理和项目经理：这两名成员基本起到协调人的作用，一般产品经理（PO）偏向用户，项目经理（ScrumMaster）偏向团队。我们希望他们的这种倾向性能够在讨论过程中体现出来，将故事的优先级、重要程度、实现难度等问题进行归纳总结，形成我们的项目计划。同时，这个故事讨论的过程一般都是以会议形式进行，这2个人应该作为会议的组织者（主持人）出现，引导团队高效的完成讨论过程。技术骨干：首先技术人员要明确自己也是主角，而不仅仅是旁听。很多人都有这样的体会，明明很简单的一个功能，为啥做起来会那么慢？这里面有2个原因：第一个是用户自己没有把这个所谓的“简单”功能想明白；第二个是一个对用户“简单”的功能，对于技术来说恐怕没有那么简单，但这个信息一般很难跟用户讲明白，所以很多技术就倾向于不说或者说的很少，结果就是双方对于难度的认知不一致。技术骨干参与这个讲故事的过程的目的，主要就是为了帮助用户从技术实现的角度理解故事，同时自己也能够将技术实现的思路想明白。

Scrum的22个基础知识点以下的22个基础知识点基本上涵盖了Scrum所涉及的内容，如果您能够正确理解所有知识点，那么您已经具备了作为一名Scrum Master的基本素质；当然，作为一名合格的Scrum Master，更重要的是经验，因为Scrum Master更多的需要和人打交道，很多实际问题的处理方式是必须在实践中才能体会的，有些还很微妙。也许您对这些知识点的理解不尽相同，这没有关系，同样的框架和方法由于应用的环境与对象的不同，所使用的方法和理解也不一定一样，这也正是Scrum的特色之一，它帮助你找到最适合你的方式。Scrum并不是你需要严格执行的流程，而是帮助你找到适合自己的流程的框架。01 实施Scrum框架的好处降低变更对系统造成的风险。提高ROI（投入产出比）。帮助我们持续改进。持续快速的发布可用的软件产品。所有人对真实可用的软件产品都有明确的认识，并在迭代过程中不停的改进。在DevCloud中可以对创建的项目类型进行选择，DevCloud提供了两种模板的项目类型：Scrum模板和看板模板。02 Scrum的组织结构Scrum的组织结构可以根据不同的项目稍作调整，一般来说，它采用2-4周的迭代周期，并包含以下角色：Scrum MasterProduct Owner开发团队03 Scrum Master的主要职责帮助团队铲除一切阻碍，让团队可以顺利完成冲刺目标。帮助团队最大化生产力。使用技术手段帮助团队变得更加高效，比如：引入自动化脚本，单元测试，持续集成等敏捷实践。协助团队和PO更好的进行协作。保证Scrum实践的正确推行。04 Scrum过程中都使用哪些工件？Scrum所使用的工件很简单，主要包括：Sprint待办列表 Sprint Backlog产品待办列表 Product Backlog增量 Increment05 什么是产品待办列表？在团队获取可用的Sprint待办列表sprint backlog之前，PO需要使用另外一个列表来管理新特性、变更请求、功能改进和缺陷等内容，并对他们进行优先级排序，这就是产品待办列表（Product Backlog）。这些内容在得到了PO和团队的认可后会交付给团队进行开发，就变成了sprint backlog，这个过程可能很复杂（比如包含多层分解、涉及多个子产品/组件、多个团队协作），也可能很简单；转换成sprint backlog的过程一般还包括了任务分解和工期估算的工作内容。在DevCloud中，可以通过“工作 > 迭代 > 未计划 > 工作”查看产品待办列表。06 什么是增量？增量（Increment）指在一个冲刺内完成的产品待办工作项的数量。在每一个冲刺结束时，所有的增量必须处于完成状态。这里的完成必须是可以用的、可部署的，无论PO是否决定进行新的生产部署。07 什么是用户故事？在Scrum中，用户故事是一个工具。通常用户故事是一个短小的、一般用一句话可以说明的特性或者功能以及场景的描述。通过用户故事，我们让用户可以自然的讲述需求，并可以通过用户故事讨论和跟踪需求。在DevCloud中针对每一个需求都可以编写相应的用户故事，对需求的场景进行记录。08 什么是故事点？在Scrum中使用用户故事（情景）作为描述一个产品特性的方式，同时使用“故事点”作为这个产品特性大小的定量估算单位，故事点的大小标识了一个产品特性的开发难度和所需要的投入（小时/人天等）。但我们一般不使用直接的小时或人天等时间单位来表示这个值，而是使用斐波纳奇数列中的数值来标识不同特性的相对大小，这样做的好处时我们可以屏蔽直接使用时间单位所造成的主观差异，更快更准确的进行评估（因为在没有进行实际开发之前是很难直接估算时间，但是不同特性的相对大小是比较容易评估的）。最终，我们可以使用数据分析手段在故事点单位和时间单位之间建立换算关系，帮助我们掌控项目进度。在DevCloud中，可以通过需求的“详细信息”页面中编辑分配给它的故事点。09 什么是Scrum扑克？Scrum 扑克（计划扑克）是一种进行量化估算的方法和工具。在团队进行规划的过程中需要对工作量（故事点）、商业价值等进行量化评估，为了达到“评估结果是团队的集体决策结果”的目的，Scrum中发明了这种方法和附带的工具（一种扑克），在扑克上使用斐波纳奇数列标识每张扑克，在进行规划的时候每个成员按照自己理解出牌，并由数值最大和最小的两名成员进行解释，大家进行讨论后得出最终的数值估计。斐波纳奇数列的特性决定了每个数字之间的差异会越来越大，这对于我们进行相对值评估非常有效。10 什么是Scrum冲刺？Scrum项目采用一个接一个的“冲刺”完成开发工作。冲刺是一个可重复的，标准化的工作循环单元，在这个单元中采用了Scrum的各种方法，并随时准备进行评审和改进。11 最佳的冲刺周期是多长，这个周期对工作方式有怎样的影响？Scrum采用2-4周的冲刺周期。一般来说，大多数团队采用2周的周期，这主要是因为2周的冲刺让团队更加容易和接近现实的进行规划并完成手头的工作。同时，2周的长度也给予Product Owner足够的时间来调整优先级，并给团队和业务需求之间提供足够的缓冲，让他们可以专注于现有需求的开发。12 Sprint计划会议上一般需要做哪些工作？在Sprint计划会议上，一般需要完成以下工作：团队针对当前冲刺需要完成的待办工作项进行分析，并给出工期估算。将产品待办工作分解为任务。如果经过估算，冲刺中仍然有剩余工作量可用，则按照优先级从产品待办工作中继续拿取需求放入冲刺。对于需求描述中的不清晰内容与PO进行沟通、澄清。13 冲刺回顾会议的作用冲刺回顾会议（Sprint Retrospective）为团队提供了总结和改进的方式，在每个冲刺结束后大家一起总结在这个冲刺中的改进和不足，并一同商讨应对措施，进行持续改进。14 Scrum中的冲刺和迭代有什么区别？迭代（Iteration）是一个通用词汇，表达的是开发过程中的某个循环过程的单元。这个单元可以是开发人员编写代码时的编写、编译、调试、重构，也可以是一个开发周期的规划、开发、测试、回归、发布。也就是说，这个单元可大可小，都可以使用迭代来进行描述。冲刺（Sprint）特指在Scrum中的某个产品开发周期，是一个2-4周的规划、开发、测试、回归和发布过程。15 燃尽图可以说明什么问题？燃尽图一般用来跟踪一个冲刺的进度状态。团队把燃尽图作为预测指标来使用，可以直观得看到当前进度是快还是慢。一般团队需要在Daily Scrum的最后查看燃尽图的最新状态，并根据情况采取措施。16 燃尽图应该包含哪些元素？燃尽图应该包括工作日作为横轴，工作量作为纵轴，最佳曲线，真实工作进度曲线。17 什么是团队速率？团队速率（Velocity）是一个团队在一个冲刺内能够完成的需求量。需求量的单位一般使用工作量或者商业价值衡量。工作量使用“故事点”来代表，商业价值一般也作为产品待办工作的评估指标之一。速率标识一个团队完成工作的速度，是评估团队效率的重要指标。18 什么是Sashimi和Impediments？Sashimi的原意是“生鱼片”，在Scrum中是团队用来表达“完成”的一种说法。不同团队对于“完成”的定义可以是不一样的，但在一个团队内必须统一，在Scrum中一个团队需要定义不同级别的“完成规范”来统一这个概念。“完成规范”可以是任务级别的，团队级别的或者产品特定级别的。Impediments的意思是“障碍”，是团队在向着“完成规范”所定义的状态努力过程中遇到的阻碍。一般来说，Scrum Master需要作为消除障碍的主要负责人。19 什么是 Daily Scrum？Daily Scrum 是一个简短的团队会议，由团队的所有成员在每天固定的时间和地点进行，会议上每个成员需要回答3个问题：你昨天做了什么？今天计划做什么？是否遇到了障碍，需要其他人的帮助？Daily Scrum 不是一个汇报会议，因为所有的参与者都必须抱着平等的心态参加，你所回答的3个问题是说给所有人听的，所有人的3个问题也都是说给你听的。Daily Scrum一般由Scrum Master进行协调和组织，但Scrum Master并不对成员所描述的业务特性/任务内容进行评价，而只关注会议本身是否高效。Daily Scrum必须站立进行，所有有很多人称之为Daliy stand-up，站立的目的是为了让会议高效并让每个人都集中精力，放下手头的工作。20 什么是Scrum of Scrum？一般在大型团队中很常见，就是每天的Daily Scrum后，团队负责人还会参加更多的会议进行团队间的沟通和进一步的规划。21 Scrum的不足对于目标不够清晰的项目，Scrum Master比较难以把控。Daily Scrum在开始阶段会让团队感受比较大的压力，并占用一定的工作时间。对于团队成员的技术水平、协作水平有较高要求。Scrum中对于变更的容忍度非常高，但这也会让项目干系人感受比较大的不安。会暴露非常多的问题，如果组织对于变化的接受度不高，会有很大的组织性冲击。会引发很多变革的发生，一定程度造成混乱的局面。22 在什么情况下Scrum并不适用？Scrum模式并不适用于所有的团队，特别当团队规模很大（几十上百上千）的时候，我们无法在整个团队范围内实施Scrum，而必须将团队分割成5-10人的小团队，并在团队间进行Scrum of Scrum 的实施。Scrum也不适合跨部门、跨职能的协作，如果团队成员分散于不同的地理位置或者不同的部门，我们需要首先在组织结构上进行调整，至少需要合并开发和测试部门，组成按照特性或产品领导的团队，同时从其他不同部门抽调人员组成团队。

敏捷项目管理敏捷开发中如何制定项目计划？在对项目的需求进行简单的规划后，我们就要进入具体的开发环节。而在开发之前，当然需要对即将开展的工作进行计划。那么，在敏捷的开发模式中，计划是如何制定的呢？让我们以DevCloud这个产品为例，一起来看看DevCloud作为一款产品是如何制定它的开发计划的。两级项目计划计划是演进的，试图在项目一开始制定“完备”的甚至是“完美”的计划是不现实的。做计划的目的之一是减少风险，但在信息最少的项目初期阶段做出最重要的决定是不切实际并且风险巨大的。敏捷计划的模式是渐进式的，一开始只规划一个大的方向，并制定最近1-2个迭代需要构建什么以及何时完成的计划。随着项目的进展，新特性不断的增加并交付给客户，团队不断的获取有关产品、技术、市场、用户相关的信息，新的迭代计划也在不断的演进，但依然是经济并且现实的只规划最近的1-2个迭代。在此过程中，通过不断的交付价值与沟通反馈，建立团队内部彼此之间以及团队与客户之间的沟通、信任与信心。在DevCloud中，计划是分为两级的，第一级是大的发布计划，以月度、季度、年度为粒度，我们称之为路标；第二级是具体的迭代计划，以周或双周为粒度，这是团队开发及交付的节奏和心跳。针对Product Backlog进行分层，近期要做的拆分到Story级别，例如2-3个迭代内的；中期要做的拆分到Feature级别，例如3个月之内的；长期待定的就留成Epic，例如3个月以上的。产品发布计划DevCloud整体是一个DevOps平台，包括敏捷项目管理、代码托管、流水线、代码检查、编译构建、部署、云测、发布等多个服务，每个服务每周固定都会有一个上线版本，特殊情况可以做到按天的发布周期。在此情况下，将相关的新功能放在一个发布计划中依然是有必要的，发布计划就是产品的Roadmap路线图，在华为我们称之为路标。我们会以年为单位制定大的路标进行对齐，同时拆分到每个季度，路标代表我们产品演进的方向和关注的重点，是中长期的目标。目标一定会发生变化，所以路标会定期进行调整，体现了我们对市场变化的判断以及对客户反馈的响应。目前在版本历程中，我们以双周为单位定期发布产品的Release Notes。Release Notes很重要，是产品新特性的发布公告，是一种事后的告知方式。还有一种事先的预告，即Release Plan产品路标，可以让客户有所预期甚至提前获得反馈。计划是一个承诺，是一个目标，计划的目的是为了更好的响应变化；制定计划很重要，但盲目遵循计划就没必要了；更重要的是做计划的过程，而不是计划本身。敏捷也好，DevOps也好，都是为了应对快速的市场变化，以及更好的响应需求的变化。产品的发布计划也是如此，没必要盲目依从，也不会100%都达成（这种情况只能说明目标太没野心了），路标需要定期检查与调整；路标的发布同时也是一种获取反馈的机制，客户可以提出反馈意见，例如对在规划发布的一个功能非常喜欢或是非常不喜欢，都可以通过意见反馈系统进行反馈，产品会基于反馈信息进行判断进而调整发布计划。迭代计划一个发布由多个迭代组成，每一个迭代都要有具体的目标，迭代过程需要度量迭代速率，团队要根据自己的速率以及工程能力确定迭代长度。DevCloud目前的迭代长度为一周，由于设计与开发的依赖关系，所以我们的设计迭代与开发迭代会有一个错位，UCD设计会超前一周完成低保证及高保真设计，随后开发会进行前后端的开发工作。在迭代计划会议上，产品经理PD对高优先级需求进行串讲，团队提出问题，并充实或调整产品Backlog的优先级，进而设定Sprint目标。根据团队速率，选择进行Sprint Backlog填充。以目前一周的迭代长度而言，这一过程大概会进行1-2小时.使用Scrum项目模板管理制定迭代计划，并进行迭代开发通过DevCloud提供的迭代管理，可以帮助您快速的制定迭代计划、管理和追踪相关工作进度。迭代创建以及管理单击“工作 > 迭代”，进入迭代管理视图。  当前视图列出了所有的迭代，包含过去的3个迭代，接下来我们创建一个新的迭代作为当前迭代。2、单击“新建迭代”，输入迭代名称“迭代04”。设置迭代日期：开始日期为本周一，结束日期为下周五。单击“新建”按钮。 说明： 请按照实际情况修改项目迭代时间。系统会根据设置的时间周期自动将“迭代04”显示在“当前迭代”列表。3、按照同样的方式，创建“迭代05”，并设置开始时间与结束时间为下一个迭代周期。系统根据设置的时间周期自动将“迭代05”显示在 “将来迭代”列表。

敏捷项目管理规划项目并管理需求项目情景   刚刚接到业务部门的最后通牒，要求月底必须上线 【门店网络查询功能】，可以在凤凰商城中查询各个门店的相关信息。   应该如何对此功能模块进行规划呢？   首先让我们看看在敏捷的项目中，应该如何进行项目规划以及需求的制定。如何拆分需求   需求通常以“Epic-Feature-Story”进行层级拆分：   战略、功能、需求、任务等的在具体项目中很难进行归类，也可以简单的按月、周、日、小时为单位进行判断，通常一个Epic可能会跨多个Release交付，Feature跨多个Sprint，Story需要在一个Sprint中完成，而Task通常是更短小以小时至多以天计。Independent 独立的Neogociable 可讨论的Valuable 对客户/用户有价值的Estimatable 可估计的Small 小的Testable 可测试的。Epic通常是公司重要战略举措或者巨大的需求，例如“凤凰商城”对于“无极限零部件公司”是一个与企业生存攸关的关键战略措施，就是一个Epic。Feature通常是在Epic之下，对用户有价值的功能，用户可以通过使用特性满足他们的需求。比如“凤凰商城”的 “门店网络查询功能”，特性通常会通过多个迭代持续交付。Story通常是对一个功能进行用户场景细分，并且能在一个迭代内完成。Story通常需要满足INVEST原则：Story又可以继续拆成Task。Task是实现层面的，例如准备环境，准备测试用例等，都可以是完成Story的细分任务。Task无需遵循INVEST原则。        战略、功能、需求、任务等的在具体项目中很难进行归类，也可以简单的按月、周、日、小时为单位进行判断，通常一个Epic可能会跨多个Release交付，Feature跨多个Sprint，Story需要在一个Sprint中完成，而Task通常是更短小以小时至多以天计。使用Scrum项目模板进行项目规划，并管理Epic和Feature在DevCloud中，可以使用提供的“需求规划”功能以思维导图的模式完成需求从“Epic > Feature > Story > Task”的创建以及管理。需求规划打开凤凰商城项目，单击“工作 > 需求规划”，项目规划视图以树形结构列出了需求从“Epic > Feature > Story > Task”的逐级关系。      2、创建新的Feature， 在凤凰商城Epic上单击“**子主题”。输入标题“门店网络”，回车保存。            3、按照同样的方式，完成Story“作为用户应该可以查看、查询所有门店网络”的创建。项目规划折叠    为了更清晰的展示规划视图，不同用户角色可以根据实际需求，展开/折叠对应级别的列表。   例如，某用户角色只关心 Feature级别的列表，单击“Feature”旁边的完成折叠。        折叠后如下图所示：导出项目规划    DevCloud还支持将项目规划导出到Excel，以“条目化”的方式查看以及管理。    单击页面右上角“导出”。导出后的表格如下图所示：需求描述：以用户故事来描述需求维基百科上说，用户故事的目的在于以更快的速度、更少的消耗来应对现实世界需求的快速变化。在DevCloud，我们以用户故事的形式来记录需求。华为以往也用需求规格说明书以及用例的形式，但这样的方式非常乏味、容易出错、编写耗时，而且说真心话没人愿意去读。采用用户故事的好处在于：用户故事强调对话而不是书面沟通。故事更容易被客户和开发人员理解。用户故事大小适中，适合做迭代计划。用户故事鼓励重要的事情先做。鼓励推迟决策，延迟考虑细节。支持随需求而变的开发。用户故事将重点从以往的文档转换到了更实用的对话。面面俱到的文档看上去固然很美，但费时费力而且还没人去看。用户故事取而代之，以通过与客户沟通来获取需求，通过与用户协作来澄清需求，通过频繁的发布来确认需求。用户故事通常按照如下的格式来表达：As a <Role>, I want to <Activity>, so that <Business Value>.作为一个<角色>，我想要<活动>，以便于<商业价值>。三段式的用户故事，核心是从用户角度出发描述问题，站在用户的立场思考问题。好的用户故事讨论的是为谁做和为什么做，而不仅仅是做什么。作为Who，我想要What，以便于Why。有了Who、Why、What的信息，How就变得呼之欲出了。以往我们上来就写需求的，往往注意到的是What（干什么），却忽略了Who（为谁做）以及Why（为什么做）。而Who-Why-How-What的逻辑模式，恰好也是影响地图的结构。有关影响地图，请阅读文章《影响地图》。DevCloud需求编辑操作在DevCloud中，我们可以通过工作项管理模块，进入每一个工作项中，单独编辑该工作项的详细信息，并可对工作项进行详细的用户故事内容描述。单击“工作 > Backlog”，打开Story“作为用户应该可以查看、查询所有门店网络”。     2、修改Story描述信息、开始日期、结束日期、预计工时、优先级、重要程度字段信息，单击“保存”按钮完成修改。此外，DevCloud支持工作项模板，在“设置->项目设置”中，可以看到如何将用户故事的三段式预置在Story的工作项模板中，也可以根据需要自行定义描述信息。同时，DevCloud也遵循3C原则。卡片是用户故事的展现形式，用户可以切换到迭代视图的卡片模式，通过拖动卡片完成状态更新。

敏捷项目管理组建Scrum团队本文将以一个示例项目为对象，介绍如何进行敏捷项目管理，示例项目背景如下：凤凰商城示例项目介绍【凤凰商城】示例项目是耗时数月所开发的汽车零部件配件电子商城。项目采用 Scrum模式 进行迭代开发，每个迭代周期为“两周”，前3个迭代已经完成“凤凰商城1.0” 版本的开发，当前正在进行 “迭代4” 的规划。在开始项目规划之前，我们首先要组建团队，并确定团队的运作模式。而在这个客户需求不断变化，交付周期不断压缩的时代，敏捷开发模式无疑是各个开发团队的首选。DevCloud提供了多种项目管理模式，其中就有基于Scrum框架的项目类型。因此，我们将以Scrum框架为例，并在此简单对Scrum进行介绍。Scrum的定义  Scrum（名词）：Scrum是一个框架，在此框架中人们可以解决复杂的自适应难题，同时也能高效并创造性地交付可能最高价值的产品。Scrum是：自上世纪90年代初以来，它就已经被应用于管理复杂产品的工作上。 Scrum并不是一种过程、技术或决定性方法，而是一个框架，在此框架中您可以使用各种不同的过程和技术。 Scrum让您的产品管理和工作技术的相对成效更加清晰地显现出来，以便您可以持续改进产品、团队和工作环境。Scrum框架由Scrum团队以及与之相关的角色、事件、工件和规则组成。框架中的每个部分都有其特定的目的，其对于Scrum的成功与使用是至关重要的。Scrum的规则把角色、事件和工件组织在一起，管理它们之间的关系和交互。轻量的易于理解的难以精通的Scrum团队在开始介绍Scrum的组织架构之前，让我们先看一个小故事。一天，一头猪和一只鸡在路上散步。鸡对猪说：“嗨，我们合伙开一家餐馆怎么样？”猪回头看了一下鸡说：“好主意，那你准备给餐馆起什么名字呢？”鸡想了想说：“叫‘火腿和鸡蛋’怎么样？”“那可不行。”猪说：“我把自己全搭进去了，而你只是参与而已。”  这则故事应用在敏捷开发中，用来说明不同角色的职责。在Scrum过程中，“猪”是在Scrum过程中全身投入项目的各种角色，他们在项目中承担实际工作；鸡”并不是实际Scrum过程中全身投入的一部分，但是必须考虑他们。Scrum团队由一名产品负责人、开发团队和一名Scrum Master组成。Scrum团队是跨职能的自组织团队。自组织团队自己选择如何以最好的方式完成工作，而不是由团队之外的人来指导。跨职能团队拥有完成工作所需的全部技能，不需要依赖团队之外的人。以上关于Scrum概念以及团队角色职责部分内容描述，摘自《2017 Scrum Guide》。关于Scrum的更多详细信息，以及管理实践方法，可参考《Scrum Guide》。使用DevCloud添加项目成员，并配置成员角色简单了解Scrum框架以后，我们就可以开始组建项目团队了。在DevCloud中，每个项目中有多个项目成员，但由于每个成员在项目中担任的职责不同，需要通过成员角色给予区分，并在操作权限上做出相应的体现。单击“设置 > 基本信息”。项目的基本信息列出了项目名称，项目描述，项目类型，创建时间，创建人。项目描述可以根据情况进行修改。  单击“成员管理”，可以添加新的用户到这个项目中。  DevCloud提供以下两种添加用户的方式：添加方式说明添加成员添加本企业租户下的成员，如果成员不存在可以为其创建子用户。通过链接邀请邀请非本企业租户下的成员。添加进项目中的成员，可以点击成员信息右侧的操作按钮，对成员角色进行编辑。  项目角色一共有6种，分别对应不同的操作权限，项目管理人员可以根据项目实际情况对成员角色进行分配。  

什么是敏捷敏捷软件开发（Agile software development），又称敏捷开发，是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发过程中人的作用。敏捷宣言“敏捷”一词来源于2001年初美国犹他州雪鸟滑雪圣地的一次敏捷方法发起者和实践者（他们发起组成了敏捷联盟）的聚会。雪鸟会议共同起草了《敏捷软件开发宣言》，其中最重要的部分就是对一些与会者一致同意的软件开发价值观的表述。价值观也就是说，尽管右项有其价值，我们更重视左项的价值。个体和互动 高于 流程和工具工作的软件 高于 详尽的文档客户合作 高于 合同谈判响应变化 高于 遵循计划原则敏捷宣言中还包括以下原则：对我们而言，最重要的是通过尽早和不断交付有价值的软件满足客户需要。我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞争优势。经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好。业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。可以工作的软件是进度的主要度量标准。敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。对卓越技术与良好设计的不断追求将有助于提高敏捷性。简单------尽可能减少工作量的艺术至关重要。最好的架构、需求和设计都源自自我组织的团队。每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。敏捷开发方法除了《敏捷软件开发宣言》内所提到的价值观和原则以外，敏捷开发并没有一个完整的方法列表，因为所有的敏捷开发方法都是广大开发人员在日常的工作中摸索出来的，针对某种特定场景适用的方法。也就是说，以下所列出的敏捷开发方法并不一定适用于你的团队或者你的问题，但是敏捷鼓励所有人按照自己的方式尝试任何的方法，只要这种方法遵循以上价值观和原则，那么它就是一种敏捷方法。Scrum看板方法 Kanban敏捷建模 Agile Modeling特性驱动开发 Feature-driven development（FDD）测试驱动开发 Test-driven development（TDD）极限编程 eXtreme Programming（XP）精益开发 Lean Development微软解决方案框架敏捷版 Microsoft Solution Framework (MSF) for Agile敏捷数据方法 Agile Data Method自适应软件开发 Adaptive Software Development（ASD）Six Sigma水晶方法 Crystal行为驱动开发 Behavior-driven development（BDD）动态系统开发方法 Dynamic Systems Development Method（BSDM）探索性测试 Exploratory Testing以下是《2019年中国DevOps现状报告》中，针对国内各种敏捷开发方法的调研结果。其中显示，在所有敏捷方法中，Scrum、看板方法、自定义混合模式是最受企业欢迎的前三种敏捷开发方法，占比分别为45.41%、41.23%、31.46%。来源：云计算开源产业联盟以下是由CollabNet VersionOne发布的《第13届年度敏捷状态报告》中，敏捷方法应用状况的调研结果。其中显示，Scrum和Scrum/XP混合（64%）仍然是受访者组织使用的最常见的敏捷方法。来源：CollabNet VersionOne/13th-annual-state-of-agile-report为什么敏捷开发可以帮到你？误解：敏捷开发是为了快速交付？敏捷开发不是一种为了快速交付而出现的方法，它之所以比较快则是因为避开了许多浪费的处理方式。那么，敏捷改善了些什么？前置时间：传统开发法依循计划、分析、设计、程序开发、测试再进行修改整合后发布的步骤进行，是一种顺序性的开发模式，当前一个步骤用掉越多时间时，后面步骤的前置时间就会越长，而形成时间上越多的浪费。反观敏捷开发，实行的是一种务实的做法，当收集到足够一次迭代开发的需求时即向下一个步骤前进，尽量缩短前置时间的浪费，然后将"分析、设计、开发与测试"形成一个开发步骤，减少了步骤与步骤之间的衔接时间。首次发布：敏捷开发采用迭代的开发方式，每个循环都会有一个潜在可发布版本用来展示开发成果，这种展示给了客户进行回馈和改进的机会，让客户体会开发成果的作法同时也给予了客户决定开发方向的绝对主权。需求过程：敏捷开发不作完整的需求分析（因为计划总是赶不上变化的），当需求的搜集量和内容质量已经达到一定要求，已经足够一个开发周期的工作量时就可以开始开发工作。测试方法：敏捷开发对软件带来的最大影响便是测试了。传统的α（内部测试）、β（交付客户测试）、γ测试（优化处理）方式在采用敏捷开发后几乎不存在了，因为敏捷开发在开发周期内不断的进行测试工作，因此也就没有了在交付做α、β、γ测试时必须停止开发、冻结开发的时间浪费了。

7月26日，敏捷江湖桃花岛来到了海风阵阵的半岛城市——大连！第三期的华山论剑大连线下活动，就在风景如海的星海湾广场游艇码头旁的微来餐厅举行。 本次线下活动为了最大程度保证用户体验采取了邀请制，参会用户来自大连本地的企业家，敏捷圈内的专业人士以及桃花岛群内的积极成员。而本次活动的主讲专家更是堪称豪华阵容：华为云DevCloud首席布道师 刘恒曾任京东首席敏捷创新教练、北大光华管理学院特邀讲师 王立杰IBM敏捷教练 14年IT工作背景 管婷婷管理3.0认证引导师&Co-owner Scrum联盟CSP，CSM，CSPO 侯伯薇华为云DevCloud敏捷专家、资深过程改善顾问 黄隽以下为活动视频实录part4：

7月26日，敏捷江湖桃花岛来到了海风阵阵的半岛城市——大连！第三期的华山论剑大连线下活动，就在风景如海的星海湾广场游艇码头旁的微来餐厅举行。 本次线下活动为了最大程度保证用户体验采取了邀请制，参会用户来自大连本地的企业家，敏捷圈内的专业人士以及桃花岛群内的积极成员。而本次活动的主讲专家更是堪称豪华阵容：华为云DevCloud首席布道师 刘恒曾任京东首席敏捷创新教练、北大光华管理学院特邀讲师 王立杰IBM敏捷教练 14年IT工作背景 管婷婷管理3.0认证引导师&Co-owner Scrum联盟CSP，CSM，CSPO 侯伯薇华为云DevCloud敏捷专家、资深过程改善顾问 黄隽以下为活动视频实录part3：

7月26日，敏捷江湖桃花岛来到了海风阵阵的半岛城市——大连！第三期的华山论剑大连线下活动，就在风景如海的星海湾广场游艇码头旁的微来餐厅举行。 本次线下活动为了最大程度保证用户体验采取了邀请制，参会用户来自大连本地的企业家，敏捷圈内的专业人士以及桃花岛群内的积极成员。而本次活动的主讲专家更是堪称豪华阵容：华为云DevCloud首席布道师 刘恒曾任京东首席敏捷创新教练、北大光华管理学院特邀讲师 王立杰IBM敏捷教练 14年IT工作背景 管婷婷管理3.0认证引导师&Co-owner Scrum联盟CSP，CSM，CSPO 侯伯薇华为云DevCloud敏捷专家、资深过程改善顾问 黄隽以下为活动视频实录part2：

敏捷江湖桃花岛之华山论剑第二期女神管婷婷来了！带来众多敏捷团队的痛点——绩效评估的内容分享主题：敏捷团队绩效评估原则主播嘉宾：管婷婷14年IT工作背景。领导团队敏捷转型，解决团队合作、激励问题，提升生产力和工作效率。以下为活动视频实录part4：

敏捷江湖桃花岛之华山论剑第二期女神管婷婷来了！带来众多敏捷团队的痛点——绩效评估的内容分享主题：敏捷团队绩效评估原则主播嘉宾：管婷婷14年IT工作背景。领导团队敏捷转型，解决团队合作、激励问题，提升生产力和工作效率。以下为活动视频实录part3：

敏捷江湖桃花岛之华山论剑第二期女神管婷婷来了！带来众多敏捷团队的痛点——绩效评估的内容分享主题：敏捷团队绩效评估原则主播嘉宾：管婷婷14年IT工作背景。领导团队敏捷转型，解决团队合作、激励问题，提升生产力和工作效率。以下为活动视频实录part2：

敏捷江湖桃花岛之华山论剑第二期女神管婷婷来了！带来众多敏捷团队的痛点——绩效评估的内容分享主题：敏捷团队绩效评估原则主播嘉宾：管婷婷14年IT工作背景。领导团队敏捷转型，解决团队合作、激励问题，提升生产力和工作效率。以下为活动视频实录part1：

7月26日，敏捷江湖桃花岛来到了海风阵阵的半岛城市——大连！第三期的华山论剑大连线下活动，就在风景如海的星海湾广场游艇码头旁的微来餐厅举行。 本次线下活动为了最大程度保证用户体验采取了邀请制，参会用户来自大连本地的企业家，敏捷圈内的专业人士以及桃花岛群内的积极成员。而本次活动的主讲专家更是堪称豪华阵容：华为云DevCloud首席布道师 刘恒曾任京东首席敏捷创新教练、北大光华管理学院特邀讲师 王立杰IBM敏捷教练 14年IT工作背景 管婷婷管理3.0认证引导师&Co-owner Scrum联盟CSP，CSM，CSPO 侯伯薇华为云DevCloud敏捷专家、资深过程改善顾问 黄隽以下为活动视频实录part1：