互联网时代，商业环境急剧变化，客户要求越来越高，竞争对手不断涌现，企业所处理的问题越来越易变、不确定、复杂、模糊。传统管理模式不再有效，敏捷管理模式应运而生。全球市值四大的苹果、微软、亚马逊、Facebook 都不约而同地采用了不同形式的敏捷。敏捷帮助企业在复杂多变的商业环境中快速交付价值，实现企业目标。
企业需要产品竞争力、技术竞争力，还需要工作方式的竞争力。敏捷的工作方式通过敏捷的价值观、原则和实践，来指导和激励个人、领导者和组织，从而创建高效、可持续的工作场所。
本文给大家介绍的就是敏捷管理的核心思想 Scrum。我们力求把方法论介绍到可操作的程度。从方便理解和记忆的角度，Scrum 方法论可以被概括为 3355。
PO（产品负责人）
SM（Scrum Master）
团队成员。
Product Backlog（产品列表）
Sprint Backlog（迭代列表）
Product Increment（产品增量）
Product Backlog Grooming （产品列表精化）
Sprint Planning（迭代计划会）
Daily Stand（每日站会）
Spring Review （迭代评审会）
Sprint Retrospective（迭代回顾会）
勇气，承诺，专注，开放，尊重。
Scrum 由上述四种要素及背后的规则粘合起来。
3 个角色各有担当又通力合作。3 个简单的物件统摄产品层面与迭代层面的交付物。5 个会议贯通产品层面与迭代层面的计划与执行活动。5 个价值观作为方法论的一部分，体现了 Scrum 以价值观为方法论的特色。
Scrum Master 的职责最难讲得清楚。有一个思路是参照卡诺模型。日本教授把产品需求分为三类：
必备型需求：这类需求没有满足，客户不会购买这个产品。
多多益善型需求：这类需求的实现程度与客户付钱的愿望呈线性关系。
喜出望外型需求：这类需求是区别于竞争产品的分水岭，客户愿意付出溢价。
按照这个思路，我们可以把 Scrum Master 的职责分为三类：
必备型职责：协助管理 Scrum 的 3 个物件和 5 个会议。
多多益善型职责：与各方沟通和协调问题解决。
喜出望外型职责：系统思考，发现流程和团队工作中的改善点，并推动改善。
管好产品列表。理解了什么是好的产品列表，也就理解了产品负责人的职责。后面会讲产品列表。
与传统团队职责不太一样的主要有两点：
跨职能：个人不一定是全能的，但团队要是全能的，具备把产品列表变成产品增量的全部技能。团队成员之间，不受角色和头衔的制约，只要具备能力，每个人都可以认领所有任务。
自组织：团队自行决定自己的工作方式，只要团队有共识。原则上是全员参与估算和计划，全员进行项目进度的监控和调整。
在现实的团队中，有专职人员，也可能有浮动人员，不管是专职人员还是浮动人员，几个共同的基础是：自动化与及时化，每个人都做好本职工作，彼此之间良好配合；每个人都理解团队的产品目标和迭代目标；每个人都了解团队的工作方式和节拍。
浮动人员的类别
一类浮动人员，例如架构师和设计师，有全局影响，但又不是全职参与。有两种变通的参与方式，一是跟专职人员一样，参加 Scrum 会议，二是在团队中指定他的影子，与他密切协作保证他能及时贡献到团队的目标。
二类浮动人员，如固定在两个团队之间共享的测试人员。
减少共享的人数，尽量把测试人员固定在其中一个团队；
由有能力多任务的资深人员在两个团队之间浮动领任务，以缓解对其他人员的共享需要；
在极端情况下，才让（1）中的人员也在两个团队之间浮动。
三类浮动人员，如在一段时间之内有部分时间花在该 Scrum 团队的人员。与一类浮动人员相比，这类人员的全局影响相对小，更多是因为技能或资源问题而导致的安排。其变通的参与方式与一类浮动人员类似。
四类浮动人员，如尚不能独立工作的新员工。变通的方法是由其导师协助领取任务。
在 Scrum Master 的引导和辅导下理解 Scrum 框架，特别是从事情角度的严密的 PDCA 循环，和从人的角度的紧密合作。
以严密的纪律性使 Scrum 能良好运转，达成业务上的目标，并收获高效快乐的团队。
在纪律的支撑之下，技术上精益求精，更好地发挥创造性，包括在技术领域，并适当参与产品探索领域。
梳理
计划
执行
每日检查和适应
迭代检查和适应（评审与回顾）
自组织：自组织不能来自命令与控制，而是简单规则支持下的群游。
跨职能团队：多样性，跨职能，不同背景，不同的思考角度，造就更好的产出，更快更好的解决方案、更棒的创新。
一专多能
火枪手精神（互助）
宽带宽沟通（沟通带宽递减：面对面 > 电话 > 即时消息 > 邮件）
透明
团队大小 5~9 人
专注与承诺
可持续步伐
长期稳定的团队
产品列表（Product Backlog）是产品列表项（Product Backlog Item，简称 PBI）的列表。PBI 包括特性、故障、技术工作和知识学习。
好的产品列表要满足 DEEP 原则：
Detailed Appropriately 细节得当。越是马上要做的 PBI，越是要有足够的细节。很久以后才做的，可以粗略一点。
Emergent 涌现式的。PBI 可以根据实际情况随时插入。
Estimated 有估算的。同样是近期要做的 PBI，估算要较精细，可以采用费波纳契序列的故事点估算，即 1，2，3，5，8 …对于远期要做的 PBI，估算可以粗略，可以采用粗略的T恤尺寸估算，即 XS，S，M，L，XL 等。
Prioritized 排好优先级的。近期要发布版本中的 PBI 的优先级要明确排列，中期的可粗略排列，远期的可不必排列。
迭代列表由从产品列表中选出当前迭代要完成的 PBI，及由 PBI 分解产生的任务构成。对于任务的估算，可以采用天或小时估算，也可以不估算。采用哪种方式，以团队能够做出靠谱的迭代承诺，以及在迭代工作的每一天方便监测趋势为标准。
产品增量是一个迭代结束时，输出的用户可用的新功能。产品增量要达到潜在可交付状态，即如果用户需要，可以快速部署给用户使用。
5 个价值观的落实与否，是 Scrum 团队形成的重要标志。
对于 5 个价值观的运用，可以由团队一起讨论，每个价值观分别意味着什么，并进而把价值观转化为可执行的团队规范。利用迭代回顾会议，审视团队规范的执行情况。
对于 5 个会议，主要讲述每个会议的目的、流程和辅助物。
目的：准备好。准备好的意思是，经过精化，PBI 达到可估算可计划和可执行的状态。开发人员可以对之进行开发工作了。
流程：
主要是围绕 DEEP 标准
细节得当。产品负责人讲解每个 PBI，达到团队成员理解需求的程度。
涌现式。在精化的过程中，根据产品负责人与团队的互动，可能会产生新的 PBI。
估算。在产品负责人讲完每个 PBI 时，团队可以用估算纸牌进行估算。通过纸牌对话，也可以保证每位团队成员都理解了需求。
优先级。优先级主要由产品负责人排列，但团队的估算和实现的难易程度，也会影响产品负责人重新考虑优先级的排列。
辅助物件：
为了保证产品列表精化达到准备好的标准，可以制定一个叫做准备好的定义（Definition of Ready，简称 DoR）的检查列表。DoR 列表示例如下：
业务价值清晰。
团队了解需求细节，能够做出是否能完成的决定。
依赖被清楚地识别和管理，没有妨碍完成 PBI 的依赖。
团队具备完成 PBI 的技能。
PBI 被估算，并且足够小，能够装到一个迭代里。
验收标准清晰和可测试。
性能指标清晰和可测试。
团队知道在完成后如何演示。
目的：在计划会结束时，给出靠谱的迭代承诺。
流程：
产品负责人建议迭代目标和要完成的 PBI。
团队把 PBI 分解成任务。
团队决定是在计划会上就把所有任务分配到个人，还是在迭代过程中动态分配。分配的方式是团队成员认领。要不要分配的标准是，团队是否能对迭代计划进行承诺。
评估计划的工作量与团队容量是否平衡。
从迭代计划中提炼出迭代目标，把 PBI 粘合在一起，把团队团结在一起。
团队对迭代目标和计划进行承诺。
辅助物件：
为了对完成有统一的标准，需要完成的定义（Definition of Done，简称 DoD）检查列表。DoD 检查列表示例如下：
设计有评审。
代码完成，包括：代码有重构，代码符合标准，有注释，有签入，有评审。
用户文档更新。
测试完成，包括：单元测试，集成测试，回归测试，平台测试，语言测试等。
零已知故障。
验收测试完成。
部署到生产环境。
可以用 A1 纸和便利贴辅助计划会议：
Scrum 的两个要点是：人的有效参与，做事的有效轨道。这个计划会的设计，是以有效的轨道辅助人的主动参与。
贴出一张 A1 大白纸。
左边第一列是故事，由 PO 用同一种颜色的便利贴书写和表达。字要大，用白板笔写，保证不用站得很近也能看清楚。故障，新特性或任何要交付的事情统称故事。
故事右边，用另一种颜色的便利贴列出任务。任务是为完成故事所要做的事，由团队书写。可以写上任务的执行人与估算。
整个会议，一次围绕一个焦点，即当前讨论的故事。以故事为单位流动起来。
PO 的注意事项：清晰讲述。随着会议的焦点流动，把故事讲得让团队明白。
SM 的注意事项：适度引导。控制焦点与流动，一个故事充分讨论完并分解成任务，再进行下一个。保持紧凑的节奏和整体时间盒。
团队注意事项：主动参与。一是对故事不清楚的主动提问，而是主动参与任务分解、估算、认领。
全部故事讨论完和分解成任务后，统计每人工作量，看工作量与容量是否平衡，个人之间工作是否能置换以达到每个人的工作相对均衡。
最后是团队决定是否能对迭代计划和目标承诺。
目的：围绕目标同步进度，掌握对于完成目标的趋势。
流程：
准时开始。每天固定时间和地点。
每人回答三个问题：为了帮助团队达到迭代目标，昨天完成了什么，今天打算完成什么，遇到了什么障碍。
总结趋势和风险。
15 分钟之内结束。
站会中细颗粒度的协作：
利用站会，促进细颗粒度协作。
故事和任务拉动按优先级进行。
需要协作的任务，其所有者勇于发起协作请求。
被请求者以协作的任务先于本人可独立承担的任务进行。
在回顾会议中明确讨论该模式，并贯彻。
模式可以由任何一人发现。
关于站会中的发散讨论：
站会中发散讨论的度以全部团队成员觉得爽为标准。
15 分钟时间盒不必严格遵守。
Scrum Master 需要对站会之后团队成员的日程有了解，以便判断站会延长一点是否产生影响。
Scrum Master 可以观察对于发散讨论是否全部或大部分团队成员沉浸其中，如果是，暂不打断。
如果出现较多分神现象，打断讨论，并提议会后安排讨论。
或者根据站会的剩余时间，询问团队，这种发散的讨论是否会影响团队成员的后续日程。
按以上原则，打断可以由任何一人提出。
在回顾会议明确探讨这种情景中的模式。
目的：了解过去一个迭代完成了什么，并对下一步做出预测。
流程：
产品负责人邀请客户和干系人参与。
团队总结过去一个迭代的成就和克服的挑战。
团队演示完成的产品，获得反馈。
产品负责人分享来自用户和市场的信息，预测调整发布计划，预测下一迭代的内容。
目的：团队建设，发掘和计划改善。
流程：
基调：真诚和有效。排除顾虑，真诚表达。提出有效的问题，落实有效的方案。
白板上写两个栏目：感谢，改善。
每人（包括 PO 和 Scrum Master）用 Post It 写出要感谢的人，每张 Post It 写一个，数量不限。写完贴在白板。
每人（包括 PO 和 Scrum Master）用 Post It 写一个最痛的改善点，只写一个就好。写完贴出来。
Scrum Master 无需太多发言，只需起一个指针的作用。先从感谢的纸条开始，一张一张拿出来问是谁写的，写的人面向要感谢的人表达感谢，不能太空洞，要谈一下感谢的内容。
然后转向改善栏目，Scrum Master 同样不要多说话，一张一张拿起纸条，让写的人讲，其他人可以参与讨论，这个环节焦点放在问题澄清，而不是解决方案，Scrum Master 对这一点要有一定把控。
每张纸条讲完后，所有人当场举手或竖大拇指，表达的是认为这个问题是否要尽快即在下一迭代解决。
全部问题澄清后，全体针对要解决的问题，讨论方案。Scrum Master 关注一下讨论的流动情况，既不要太乱，也不要冷场。极端情况下，可以点名让大家逐一发言，但尽量不用这一招。
产生的方案，形成改善 Backlog。Scrum Master 要跟踪起来，可以在日常或站会中跟踪落实情况。
Scrum Master 要观察团队互动中的交互情况，如果有分歧点，就是改善点。比如说在 Demo 中，PO 对验收标准的理解与团队不一致。这就是需要改善的地方。改善的讨论和进行，可以在日常与相关人员讨论，也可以放到回顾会议。
除了团队的回顾会议，还可以有一对一的回顾会议：
一对一 Retrospective 是对团队 Retrospective 的鼓励和驯化。是为了帮助打磨团队 Retrospective。
一对一 Retrospective 是对团队 Retrospective 的补充。即使团队 Retrospective 已经搞得很好了，也还需要一对一 Retrospective。
一对一 Retrospective 可以由 Scrum Master 发起，也可以由任何人向任何人发起。
一对一 Retrospective 的目的，是加强人与人之间的连接，传递改善的信念，和计划和执行改善。
一对一 Retrospective 的边界，是围绕改善的基调，就与团队项目工作相关的事进行讨论。
一对一 Retrospective 的框架，可以包含探询交流对象对工作方式的反馈、探询痛点和关注的问题，和以 Scrum 实践和角色要求为基准、以观察到的行为为依据向交流对象提供的反馈。还可以包含不同团队之间的经验传递、桥梁和延展。
如果希望痛点和问题的探询更封闭一点，可以分解为几个角度：就团队项目工作的上下文而言，您的目标和期望的理想状态是什么？与现状的差距是什么？流程上有什么问题，或有什么妨碍理想状态的达到？团队合作方面呢？团队工作绩效和质量呢？任何其他方面？
这个框架的运用要灵活。人的主动参与重于规则。如果人能主动参与改善事项的发掘、计划和行动，框架就可以放下。
Scrum Master 日常有力的观察是 Retrospective 的重要输入。
各个角色的普适标准：专业、尊重、坚持。
改变的第一原则：一切改变基于自愿。改善的用意是改善系统，不是改变个人。
即日起至 3 月 9 日，专栏《图解敏捷教练和 ScrumMaster》限时特惠！订阅专栏，掌握敏捷管理核心知识，揭秘敏捷教练！
