引言
小编最近在按照Evelyn老师推荐的书单一本本的研读，这篇开始，将梳理《Scrum敏捷软件开发》这本书的“知识点”，希望对小伙伴们有一些帮助。其实小编一开始看到这本书时，觉得是一本很基础的讲授敏捷（Scrum）基础的书籍（小编这次对封面产生了认知偏差），后来经同窗好友[台]Edward推荐，开始研读，然后深感自己“以貌取人”的错误。
无论是团队还是组织向Scrum或其他敏捷方法转型时都是比较困难的。而且比许多企业预期的要困难的多。获得敏捷带来的所有回报而必须进行的变革是意义深远的，这些变革不仅要求开发人员也要求企业中其他的成员进行大量的付出。工程实践只是一方面，观念的改变确实完全不同的另一个方面。
有些发起敏捷转型的管理层认为，只给开发人员提供培训和支持就足够了。他们没有考虑到Scrum对销售人员、销售部门甚至财务部门的工作带来的影响。如果这些地方没有改变，组织惰性会把整个公司重新带回原点。
“愿意改变是一种优势，即使意味着某个时间会使公司的某个部分陷入混乱。”
那么我们应该如何做呢？
01敏捷转型到底是自下而上还是自上而下？
上图摘录自 Scrum@Scale PPT
前一段时间，我学了Scrum@Scaled Practitioner课程，其中提到了一个观点，叫做 Agile Bubbles（敏捷小泡泡），也就是说，在落地规模化Scrum变革时，可以先组织落地实施一个小团队的Scrum。当一个Team的Scrum做好了以后，它会吸引其他的团队，然后进行规模化的实施，即建立EAT团队 和 EMS团队。在Mike Cohn这本《Scrum 敏捷软件开发》中却不这样认为。Mike Cohn认为成功的组织变革不能完全是自上而下或自下而上。同样，在《拥抱变革：从优秀走向卓越的48个组织转型模式（Fearless Change ：Patterns for Introducing New Ider）》中也同样有写到“我们相信引入变革的最佳方式是自下而上的，同时需要管理层在适当的时候基于支持，包括基层和更高层的。”书中还写到“人们其实没有那么反对变革，他们反对的是被强行改变，如果人们在变革引入中起到一定的作用，会更好地面对处理变革。”自下而上的参与是有必要的，因为团队成员才是工作的主体，他们才知道如何使Scrum在企业内变得更有效。但是一个组织尝试向Scrum转型，如果没有公司高层的支持，他们会遇到基层无法克服的阻力。这常常发生在一个Scrum过程开始影响初始团队的工作的时候。作为应对，中层管理者可能会保护自己的部门而剔除Scrum带来的变化。移除这些类型的障碍和困难，就需要自上而下的支持。
02Scrum的好处
图片摘自：《Scrum Shortcuts without Cutting Corners:Agile Tactics,Tools,&Tips（Scrum捷径 敏捷策略、工具与技巧）》
现在越来越多的企业和团队都开始落地敏捷或规模化的敏捷，再讨论敏捷能带来什么好处，显得有些落伍了，但是有些要点还是要提一下。“Scrum 是一个让我们关注于在最短时间内交付高质量商业价值的敏捷框架。（Cohn 2007）” 重点在于交付价值。举个例子，有时我们盲目的在追求发布次数（发布频率），有时我们会说，我们的系统能做到每周（月）发布一个版本，而这个发布次数（频率）和我们企业的Outcome真的有关吗？再比如我们做的是星巴克App的团队，我们真的需要每周（月）Update一次吗？
03ADAPT模型
图片来自《Scrum – A Pocket Guide - 2nd edition》
上图为The House Of Scrum，其中右边的支柱代表了Adapt模型，它是指成功、持续实施Scrum必备的五个活动：1、意识（Awareness）：当前的过程已不能实现可接受的结果。2、渴望（Desire）：把实施Scrum作为一种方法来解决当前的问题。3、能力（Ability）：有能力成功实施Scrum。4、推广（Promotion）：通过分享经验来推广Scrum，从而能让我们记住并能让他人看到我们的成功。5、传递（Transfer）：把实施Scrum带来的影响扩大到整个公司。这五个活动，意识、愿望、能力、推广以及传递，使用英文的首字母缩写为ADAPT。意识、愿望和能力是相互重叠的，而推广和传递在整个转型过程中会重复出现。在开始转型之后，这个循环还会随着改进持续下去。
（备注：ADAPT的五个活动是以ADKAR模型为基础。ADKAR是一个通用的变革模型，包括意识（Awareness）、渴望（Desire）、知识（Knowledge）、能力（Ability）以及巩固（Reinforcement）。）
如果把实施Scrum完全视为开发组织的事情，势必有害无益。要保持持续的长久的成功，必须将Scrum实施的影响传达到其他部门，包括销售、营销、运营、人力资源以及后勤部门。这些部门并不需要使用Scrum，也并不需要销售人员绘制燃尽图或后勤部门赵凯每日站会。但是，除非这些群体在如何与敏捷开发团队协作方面做一些小但很重要的变化，否则，他们将必定会影响开发团队的敏捷能力。再次强调，请切记，开发团队只靠自己是不能够永久保持敏捷的。如果Scrum效应无法传递到其他部门，这些部门的“组织惯性”最终会使转型所做的所有努力化为灰烬。我并不是说该组织的其他部门需要开始使用Scrum。而是该组织的其他部门至少必须变得可以兼容Scurm。
04没有“银弹”
敏捷不是“银弹”，“敏捷”本身是形容词，在敏捷开发中是指能适应变化而作出改变，而且有持续学习的特质，你不能指望使用“Scrum”或“敏捷”来解决你团队或组织中的所有问题。而且大野耐一（Taiichi Ohno），丰田生产体系概念的创导人，写道“有一些事情称之为标准工作，但是标准是在不断变化的。相反，如果你认为这些标准工作对你来说已经是最好的，那么一切都结束了。……如果我们把一些事情作为最好的可能方法，那么对于精益[持续改善]的动力就消失了。”尽管团队成员应该不断地与其他团队成员分享新发现的理想工作方式，但他们应该抵制那些鼓励将这些内容变成一套最佳实践的做法。
然而我们在做敏捷转型时，首先遇到的问题就是我们要选择什么样的团队、我们是大张旗鼓的做敏捷，还是悄无声息的“偷偷摸摸做”以及什么样的项目，下面我们将为大家解答这几个主要的问题。
⊙小团队试点还是全面转型？
⊙公开行动还是悄无声息？
⊙企业转型社区（ETC）
⊙试点项目
01小团队试点，还是全面转型？
Start-small or All-in？
按照惯例，向Scrum或者任何一个敏捷过程转型，长期以来最通常的建议是以一个试点项目作为开始，从中吸取教训，然后再企业范围内推广。这个方法就是我们经常使用的小团队试点（start-small）模式。小团队试点有许多不同的做法，取决于企业转型的规模及其对转型速度的要求，小团队试点应用方式也取决于企业如何规避转型风险及其不确定性。一个普遍的做法是在一到三个团队参与试点项目结束后立即开始全面转型。虽然小项目试点模式比较受欢迎，但它不是万能的，全面转型（all-in）也有它所能带来的好处。
选择小团队试点的原因具有以下优势：
· 小团队试点成本低；
· 几乎可以确保早期的成功；
· 小团队试点规避了全面转型的巨大风险；
· 小团队试点压力更小；
· 小团队试点能在不发生企业变革的情况下进行。
相比小团队试点模式，全面转型也有自己的优势：
· 全面转型可以减少阻力；
· 全面转型避免了因Scrum和传统团队一起工作而导致的问题；
· 全面转型可以使转型更快的结束。
那么何时选择全面转型，何时选择小团队试点呢？
当公司领导不愿意完全承诺实施Scrum时，请选择小团队试点。即使是一次小规模的成功，也足以说服怀疑论者。当失败有巨大代价时，请选择小团队试点。但是如果时间是关键因素的话，请采用全面转型。虽然全面转型更加昂贵，但花的时间少。如果没有足够经验丰富的Scrum Master来指导团队，请不要使用全面转型。Scrum Master来自企业的外部或内部，在短期内无关紧要，但记住，最终你要让所有的Scrum Master都是内部的员工。
02公开行动还是悄无声息？
无论采用哪个方式来实施Scrum，都请记住，选择这个模式只是在转型时需要做出的众多决定中的第一个。接下来，需要决定是否公开宣布Scrum转型。
如果决定公开敏捷，团队和组织就要广泛宣传他们正在实施Scrum。根据不同范围和过渡的重要性，公布的范围可以从小吃店告诉其他团队我们正在做Scrum，上升到全国媒体发布。公开展示敏捷，不论宣传的范围怎么样，团队要努力告诉其他人敏捷正在进行中。公开敏捷是没有退路的。公开敏捷是一个强有力的声明，组织不仅要开始转型，并且要取得成功。
与公开敏捷相反的做法是悄悄转型，在悄悄转型的过程中，直到项目结束，也只有团队成员直到他们在使用Scrum。
选择公开展示敏捷的原因：
· 所有人都知道你在做敏捷，所以你更容易坚持下去。
· 公开展示建立了工作的目标愿景。
· 公开操作是对承诺的坚定声明。
· 公开展示可以争取到企业的支持。
· 明确目标，然后实现，这样更具有说服力。
而选择悄悄行动的原因：
· 有机会在别人反对之前取得进展。
· 悄悄转型避免了额外的压力。
· 如果项目失败，则可以调整使用Scrum的方式，重新尝试，直到弄明白自己如何取得成功之后，再告诉其他人。
· 如果没有人知道你使用Scrum，就不会有人阻止你。
其实，企业更愿意公开展示敏捷，享受成功的转型。当你对Scrum充满信心，并且对转型做出承诺时，请选择公开转型。同样，如果你预计会有一些阻碍，但是你想快速战胜他们的时候，强烈建议考虑公开转型。相反，如果你只是想对完整的Scrum或其中的一部分做实验，则可以选择相对隐蔽的方式。如果你没有在行政上有影响力声张“我们在实施Scrum”或者这样做会带来非常多的障碍，请悄悄开始。
03企业转型社区（ETC）
Enterprise Transition Community
发起、鼓励与支持企业引入和改进Scrum的小组被称为企业转型社区或ETC（Enterprise Transition Community）。ETC不是通过强行实施企业变革，而是通过指导实施变革的小组，为成功实施Scrum排除障碍，为变革创造活力与激情来做到的。
我认为，ETC“类似”于Scrum@Scale中的EAT（Executive Action Team）团队，ETC也应该是一个“Scrum团队”或是具有“Scrum团队”的特点。ETC的成员通常不超过12人，他们来自于Scrum转型的最高级别成员。ETC Sprint的长度取决于ETC成员，不过通常二周最为适宜。
实施敏捷或实施任何重大的变革，都需要管理层真诚的支持。事情得到解决之前道路是崎岖不平的，尽管有任何问题或失败，但管理层的支持都能让变革之路坚持下来。发起人只是支票簿式的参与，是Scrum实施失败的最可能的原因。
进而，有一点至关重要，发起人通过参与 ETC 来展现他对转型工作的承诺。
ETC是一个工作小组，而不是决策委员会。所以，当企业实现Scrum转型并进入持续改善阶段后，ETC就应该解散了。而ETC最重要的职责之一是围绕Scrum实施而创造的活力。ETC需要点燃为成功实施Scrum而工作的人的热情。
ETC需要做到以下几点：
· 清楚表达背景；（ETC不只是勾勒出企业敏捷的前景。他既要帮助雇员懂得变革的必要性，也要培养他们变革的愿景。）
· 鼓励对话；
· 提供资源；
· 设置合适的目标；（ETC负责为转型设置合适的目标，并做好沟通。随着企业的改进，这些目标可能（而且应该是）随着时间而变化。）
· 人人参与；（ETC确保转型的尝试不会局限于一个小组。在受影响的小组中，要鼓励广泛的参与。）
· 预料和处理人们的问题；（ETC要尽可能预计哪些小组或个人极为抵触Scrum所带来的变化，并积极和他们一起解决问题。）
· 预计和消除障碍；（ETC成员负责消除实施Scrum的过程中横亘在企业前的任何障碍。）
· 鼓励对实践和原则的同时关注。
04试点项目
Pilot project
“选择合适的项目是最为关键、最富有挑战性的任务。我们需要某个真正的项目，人们无法因为某个特别原因就解散该项目，但是又不想该项目充满所有可能面临的挑战——太多挑战会影响它的成功。”
理想试点项目的四个属性如上图所示：
· 持续时间：最好选择持续时间为企业内项目普通持续时间一半左右的项目，一般这个周期为3-4个月。
· 规模：如果有可能，请选择只有一个团队的项目作为开始，并且保持团队成员都坐在一起。
· 重要性：应该选择重要性高的项目，不重要的项目无法得到公司其他人必要的关注。
· 发起人的保证：拥有一名来自商业并且能够有时间和意愿与团队一起工作的人是很关键的。在团队需要推动改变那些不易改变的业务流程、部门或个体时，积极投入的商业发起人是很有帮助的。
文章来源：殃殃的书屋王殃殃