"Scrum is simple，but it's not easy。"这是参加CSM认证培训课上Vernon大师介绍Scrum框架前说的一句话，当时因为刚接触敏捷不久，对Scrum也只限于皮毛的理论知识，对大师的这句话并没有太多感受。后续随着公司一年多的Scrum+XP的落地实践，在公司内部负责敏捷推广，给各个团队培训敏捷基础知识，同时在几个团队中担任ScrumMaster，对这句话的感越来越深。

因为在公司每个月都会新员工做敏捷培训，对于框架中的内容已经很熟悉，但每每遇到落地实践的问题，都会重翻这本经典之作对应的章节，而对于Scrum框架这个章节都会必看，带着问题重读，对框架中各块内容有更深的理解。

这也是为什么我会选择"Scrum框架"这一章节的原因。

Scrum框架总览：

首先，Scrum不是一个类似ISO9000或者CMMI L3之类的标准过程，也不能保证团队有条不紊的按照步骤一步步执行后，就能在指定时间和预算内产出让客户满意的高质量产品。相反，在一定时期内Scrum有可能会让高层感觉团队依旧很"慢"。因为，Scrum是一个用于组织和管理工作的框架。

*Scrum价值观：

价值观是整个框架的基石，就好比建造高楼大厦的地基，虽然不属于建筑的组成部分，但它对保证建筑物的坚固耐久具有非常重要的作用。不理解或者不认可价值观，后续的各项活动也就不会深入理解其中的目的或者价值，会做的越来越形式化。

在Scrum联盟的各项认证培训，以及在大部分资料中，对于Scrum价值观是五大项“承诺、专注、公开、尊重、勇气”。但本书提到了八大价值观，稍有差别。对此也曾有过困惑，百度了很多资料，后来在一篇《Scrum价值观问题溯源》的简书中看到Bob对此问题询问原书作者后的答复“书中的几项是作者自己添加的，他认为非常重要的价值观”。追本溯源，两者“专注、开放、尊重、勇气”是完全一样的，差别在于“承诺”和“诚实、信任、授权、合作”这些词条。在实际的落地实践中，真实感受到“承诺”完全可以贯穿这四项词条：“承诺”是PO和开发团队相互给予对方的，在过程中通过紧密“合作”来促进承诺的达成。团队基于团队的平均速率“诚实”地向PO承诺下一个Sprint目标，PO在过程中充分“信任”团队可以交付高质量产品增量，并且承诺不会干扰团队。对于SM来说，不再是以往的管理者的角色，而是一个教练，在过程中充分发挥教导作用，帮助团队制定合适的、有团队特色的Scrum方式，给予团队充分“授权”，而不是像传统项目经理那样去分配任务或者发号施令。

Scrum价值观推崇以人为中心，与众多企业文化也是相符的，但真正让公司从上至下做到理解和落地还是需要下很大功夫的。否则，将会变成墙上文化，随之Scrum各种实践也会有形无神。

*Scrum角色：

PO、SM、开发团队，三个角色在工作中相互影响、相互依靠，在过程中相互磨合，“相爱相杀”的感觉，逐渐形成有机整体。

-PO：明确WHAT？（要开发什么？以什么顺序开发？）-引导团队做正确的事情

关于PO这个角色多说一句：我们公司有产品经理、产品助理等岗位，但是在团队内往往会把岗位与角色混淆，很多开发同学会说团队内有2个、3个、甚至于5个PO，个人认为这是比较严重的概念错误，一是SM要自省团队为什么会有这样的概念错误？二是承担PO角色的同学要自省真的承担起相关职责了吗？PO在团队内是唯一有权决定要构建哪些特性并以何种顺序来构建的人。如果有N个PO存在，那对于开发团队来说也是一种痛苦，不知道该听谁的。。。

-SM：指导团队在通用Scrum框架上建立并遵循自己的过程。

通过自己的个人影响力来领导团队，在团队中承担培训、引导、辅导、启发、协调等作用，属于“服务式领导”。避免通过权力来命令或者控制，否则违反了Scrum基本价值观。

-开发团队：确定HOW？（如何交付PO要求的产品）

跨职能、自组织团队，7±2的规模（两个披萨原则），如果团队人数过多，沟通渠道会很多，那么各种沟通和会议的效率会大大降低。

我们的做法：在公司刚开始推行敏捷的时候，要求每个团队都创建一份“团队工作协议”，全员签名后贴在各自的白板上。虽然建立是带着半强迫的性质，但每个团队所公示出来的内容实际是团队问责的明确声明，对于团队自组织管理起到了一定的推动作用。例如，站会迟到是最常见的一些问题，在工作协议中对此会有团队共同商定的“处罚”办法。起初，工作协议中的内容不会很多，随着冲刺的进行，发现问题、解决问题、回顾总结，工作协议会越来越充实，这也充分体现了团队的持续提升。当团队中有新的同学加入，工作协议也是让新人快速了解团队文化的方式之一，更快融入团队之中。

公司这一年多的敏捷落地实践，对于技术团队来说经历了很大的考验：从职能转变的角度，团队更加扁平化，取消了项目经理的头衔，一些人员因为转变不了思维被迫离职。其次，敏捷转型对于大家的工作方式、沟通方式也是一个很大的转变，公司采购了JIRA、WIKI作为日常工具，使工作协作更加透明化、可视化。

*Scrum活动：

各项活动的详细内容不在这里赘述，只是分享一些自己的感受。

每个冲刺期间，这些活动都是必须执行的，并且一环扣着一环。在转型期初，很多团队成员抱怨会议太多，占用了太多时间，经过几次调研，发现大家对于这些活动或者会议的叫法各有不同，例如：“冲刺规划”在一些团队成为“迭代计划”，一些团队成为“迭代启动”。其实，会议目的都是相同的，但在大家都一知半解的情况下会认为有多个会议，太浪费时间了。为了让各团队在这方面达成一致，我们将各项活动统一了名称，并且梳理了会议目的、召开时间、参加人员、输入、输出等内容，公示在WIKI中，让各团队的SM将相关内容在团队内宣导。经过一段时间，会议太多的这种反馈就不存在了。

随着各项活动的不断进行，问题又来了，大家又反馈“这些会议太形式化了，不开这些会难道项目一定做不好吗？”答案当然是否定的。实际上，在框架概览中也已提到，Scrum不能保证团队有条不紊的按照步骤一步步执行后，就能在指定时间和预算内产出让客户满意的高质量产品。经过一些沟通，出现这种问题反馈是由于大家把这些活动仅仅当成了去开了个会，缺少“仪式感”。《小王子》中对于仪式感有句经典的话：“仪式感，就是使某一天与其他日子不同，使某一时刻与其他时刻不同。”（关于仪式感的重要性，推荐大家一篇简书（http://www.jianshu.com/p/1f21b68925c5））随后，在公司内的各种培训或者分享中，我把这部分内容都称之为“Scrum仪式”，把仪式感深入人心。

问题在实践过程中不断出现，解决了一个又会冒出了新的问题，我们要做的不是逃避问题，而是去观察问题背后的根因到底是什么，找到根因，抽丝剥茧，总会找到最合适的解决方案。

*Scrum工件：

-产品列表：由产品负责人管理、不断演进的一个动态列表；具有DEEP的特点；其中每一个条目称为PBI，包括功能性需求、非功能性需求、技术改进点、待解决的问题等；

-冲刺列表：在冲刺规划期间，产品负责人和开发团队对冲刺目标达成一致后，开发团队一般会继续将每个需要完成的特性再细分为一组子任务。这组任务与对应的PBI共同组成了冲刺列表。由开发团队管理和维护，产品负责人没有权利自行添加PBI或者子任务。

原则上，在一个冲刺期间不允许改变范围内的目标。但是，有时候业务需求使我们无法完全遵从这个原则。通常，我们在各个团队中采取的做法是：产品负责人首先阐明变更的必要性，一切基于价值评估来说话，团队认可价值后再与团队协商是否采用“需求置换”，或者团队接受这个冲刺加班完成。无论是什么结果，产品负责人都不能威胁团队必须要做。

-潜在可交付的产品增量：这里最关键的是团队内有一致同意的DOD（完成的定义），基于其中的内容来判断是否冲刺内所有东西都做完了。

“潜在可交付”并不意味着构建出的东西必须实际交付，交付是产品负责人的业务决策，基于发布计划来确定。

同样，随着时间推移，团队DOD内容会不断修改完善 。

关于燃尽图：CSM认证培训课上Vernon大师介绍，早期时燃尽图是Scrum工件之一，但是当图形燃到0点时，并不意味着可以交付出有价值的产品，所以“潜在可交付的产品增量”替代其成为Scrum工件。

那么，燃尽图是不是就不再重要，可以不再关注呢？非也。个人认为，燃尽图在冲刺过程中是需要团队成员共同关注的。无论是手绘还是通过工具来展示，都是冲刺过程中可视化进度的表达方式，能帮助团队判断冲刺目标是否可达成的风险概率。

总结：

"Scrum is simple，but it's not easy。"

理论的内容总是很简单，但是真正做起来，会遇到各种各样的问题，“见招拆招”，总能找到的合适的解决方法。关键是坚持。