1. Scrum简介
Scrum基本组成结构见下图，以一组称之为Sprint的迭代周期组成，典型的迭代周期为1-2周或者最多一个自然月，产品的设计、开发、测试全部都在一个迭代内完成。
Scrum中存在三大角色，分别是Product Owner（简称PO）、Scrum Master（简称SM）和Development Team（简称DEV）。Product Owner的交集比较广泛，对内需要与SM和DEV有效协作，对外对接客户、用户以及各种内部干系人，所以Product Owner在具备领域知识的同时，还需要有较高的交际能力、决策能力和责任感；Scrum Master的责任包括团队教练、过程执行者、外部影响的屏障、团队障碍的移除者和引入变化的主导者，每一项都需要SM具备专业的技能、善于发现问题、耐心并善于协作，同时SM作为团队主要的协调者（Facilitator），合理把握职责的边界，很多时候需要对团队透明；Scrum中对开发团队要求较高，首先在团队成员构成上应确保跨职能，即团队包含交付一个产品所应具有的各种角色。团队内部成员之间能够进行透明化沟通，在具备对某一领域深度了解的同时还应有一定广度。
Scrum活动构成了整个Sprint的工作流程，从8-10中可以看出Scrum框架中一个Sprint包括计划、执行、评审和回顾四大活动。
（1）Sprint计划
Sprint采用两阶段会议方法确定开发计划，可以分别用What和How来概括这两个阶段的目的。阶段一根据优先级以及本次迭代能完成的团队工作量填充相应的PBI，该阶段由Product Owner主导。阶段二根据Product Backlog中的PBI（Product Backlog Item）展开讨论并确定实现方案，该阶段由整个开发团队主导，Product Owner负责解释领域问题。Sprint计划的产出就是Sprint Backlog，通过计划会议，面向业务的PBI转变为面向开发的Task。
（2）Sprint执行
Sprint执行过程中，输入是Sprint Backlog，而输出就是可以运行的交付产物，整个Scrum团队都会参与其中，可以结合极限编程中开发相关的工程实践加强技术执行力。在Sprint执行过程中，需要重点关注的就是避免将一个Scrum迭代演变成Water-Scrum-Fall式迭代。所谓Water-Scrum-Fall，指的就是在一个Sprint中依然采用类似分析、设计、编码、集成、测试的传统瀑布流程，导致在Sprint结束时，可能都还没有任何可以交付的产物（见下图）。
避免Water-Scrum-Fall现象的产生，一方面就需要不断同步开发信息并做相应调整，Daily Scrum通过经典的三个问题对每个人开展信息同步：我昨天做了什么？我今天将要做什么？有什么问题妨碍我取得进展？在回答这些问题时，一定要简洁，避免陷入细节讨论，所以Daily Scrum一般都会控制在较短时间内（一般15分钟），对于长时间的个人发言要及时调整以控制会议节奏。
（3）Sprint评审
Sprint评审流程上与极限编程中的迭代评审类似，对于演示的结果需要进行确认，通过迭代的功能是否满意、下一个Sprint是否可以继续这两个问题可以明确迭代的结果。
（4）Sprint回顾
在Scrum中，回顾（Retrospective）是单独一个流程节点，意味了每个Sprint必须完成回顾才能结束。回顾通过回顾会议展开工作，其效果就在于把Scrum团队中的想法全部收集起来，然后通过分类发掘，明确可以引入的变化以及丢弃当前不好的做法。回顾非常之重要，在下一节过程改进中还会有专门介绍。
2. Scrum中的管道管理
管道思想在Scrum中的体现主要在对Product Backlog的梳理（Grooming）上，如下图所示，当原始的粗粒度需求通过管道流向开发团队，这些需求被慢慢分解和精细化。当需求达到开发团队，即形成Spring Backlog时，需求应当处于可进行评估和直接开发的状态。
显然，管道的负载分析在上图中能发挥其作用，我们不希望出现管道两端不匹配的情况。如果原始需求梳理的速度跟不上开发团队的开发速度，管道将出现空置现象，开发团队也就无法规划和执行想一个Sprint；反之，如果把过多的已完成梳理的需求放到管道中，那么开发团队就无法按照正常节奏完成管道中的开发任务，从而导致任务的累积。管道空置和过度累积都是比较明显的浪费现象。
针对管道负载可能出现的问题，Product Owner日常工作的一大重点就在于梳理Product Backlog，通过收集、分析各项业务需求的优先级并确保Product Backlog中的PBI按照发布计划的时间安排由远到近进行从粗粒度到细粒度的演进。一般会按照优先级制定发布计划，并采用新增、删除、重新估算、提炼（Refine）等几种常见的Product Backlog梳理方法。
我们知道在管理中的开发任务分为硬性任务和软性任务两大类，在Scrum的Product Backlog中同样提供了类似的概念确保Sprint执行过程中的弹性化处理。如下图所示，在一个发布计划中，存在三种类型任务，即必须要有的任务（must have）、最好有的任务（nice to have）和不会有的任务（won’t have）。必须要有的任务类似与管道理论中的硬性任务，而最好有的任务相当于软件任务，在一定程度上舍弃部分最好有的任务不会影响到本次发布。
如果对文章感兴趣，可以关注我的微信公众号：程序员向架构师转型，或扫描下面的二维码。
我出版了《系统架构设计：程序员向架构师转型之路》、《向技术管理者转型：软件开发人员跨越行业、技术、管理的转型思维与实践》、《微服务设计原理与架构》、《微服务架构实战》等书籍，并翻译有《深入RabbitMQ》和《Spring5响应式编程实战》，欢迎交流。
