「声动派」，专注互联网价值传播，为你分享大连接时代的一切！
本文大约 3600字 阅读需要 9分钟
⽬标读者
新晋ScrumMaster或者对Scrum转型有兴趣的相关⼈员。
本⽂内容
笔者结合⾃⾝经验，抛砖引⽟，提供经验供读者在Scrum转型初期参考，也欢迎读者提出观点与笔者进⾏探讨。
前置⼯作 - 搞定上级
如果你⾝处⼀个不使⽤敏捷⽅法进⾏软件开发的公司，那么在进⾏敏捷转型之前，最最重要的⼀个任务就是搞定你的上级，做好他（她）的“教育⼯作”。只有上级认可了敏捷的价值、⽀持我们ScrumMaster的⼯作，那么我们才能在以后的⼯作中如鱼得⽔。
⾄于如何搞定上级，那就是“⼋仙过海各显神通”的事情了，针对不同的情况和不同的⼈有各种各样的做法。ScrumMaster是⼀个很考验软技能的职位，我们可以根据领导的性格、做事原则等等⽅⾯⼊⼿，因材施教，站在他（她）的⾓度让他（她）对敏捷转型“⼼动”起来。
举个例⼦：如果你的领导是⼀个很严谨并且做事很循规蹈矩的⼈，那么我们可以收集数据制作ppt向他（她）说明敏捷的价值，对公司和组织的好处，以及我们进⾏敏捷转型的⽬标、执⾏的计划还有具体的步骤。
组建Scrum团队
⼈们在⼀起可以做出单独⼀个⼈所不能做出的事业；智慧 + 双⼿ + ⼒量结合在⼀起，⼏乎是万能的。 —— 美 • 韦伯斯特
虽然学过Scrum的读者们都知道，Scrum团队应该是⼀个跨职能的团队，它应该包括可以对产品进⾏持续开发和交付的成员（这包括需求分析、设计、开发、测试、运维等等）。
笔者认为真正理想的Scrum团队除了是跨职能的之外，还应该是⼀个本地的、使⽤同⼀间办公室的团队（local cross-functional team in one room)。
笔者就曾经尝试带过分布式的团队，当时成员分布在各⾃的办公室（因为公司是按照部门来安排座位的），有⼀次团队的成员甚⾄分布在两个不同时区的国家。这样组建团队的缺点也显⽽易见：成员们⽆法及时沟通和协作，导致⽆法交付更多的价值。
⾄于为什么要强调“使⽤同⼀间办公室”呢？如果在隔壁不就⼏步路也就能找到⼈吗，⼀样可以及时沟通呀。笔者通过⾃⼰的实践告诉⼤家，把团队组织在同⼀间办公室是有道理的，它有以下好处：
1. ⽅便做⾯对⾯的沟通，降低沟通成本；
2. 有利于营造组织⽂化和氛围；
3. 增强团队凝聚⼒；
4. 为开发团队的能⼒拓展创造条件（可以更⽅便地从其他同事那⾥学习技能）。
如果你的团队还不是按照这样的标准来组建的话，那么快⾏动起来吧。
控制Scrum团队成员的数量
在敏捷项⽬管理中，团队⼈数应该在5~9⼈⽐较理想，这是⼀个很容易做到但是又往往被忽略的准则。当产品越做越⼤的时候，会有越来越多的⼈投⼊到产品的开发当中，可能稍不留神你的团队就能轻易突破理想规模。作为ScrumMaster需要意识到这个问题，留意团队规模在多⼤的时候效率最⾼，从⽽进⾏⼈数的调整。如果你的团队已经过于庞⼤了，那么把它拆分为若⼲个⼩团队吧，我们还可以通过Scrum-of-Scrums的⽅式对团队进⾏管理。
Scrum转型与实践难在哪⾥
在笔者看来，进⾏Scrum转型的最⼤障碍在于，如何让成员改变固有的软件开发⽅式，对敏捷开发的价值有正确的认识，从⽽愿意⿎起勇⽓迈出舒适区做出改变。
⼀些Scrum⽼鸟也说到，Scrum理论学习起来并不难，难的是怎么应⽤，怎么建⽴起敏捷的⽂化。俗语说得好，冰冻三尺⾮⼀⽇之寒。如果想要改变成员的习惯，也不能太急于求成。有很多新晋的ScrumMaster学习了新的技能之后就迫不及待地强⾏推⼴，例如⾃动化测试、持续集成等，强迫开发⼈员⼀定要严格执⾏，得到的结果往往是成员们埋怨增加了⼯作量，⼤家怨声载道，从⽽得出Scrum不适合团队的结论，⽽Scrum的转型也就不了了之。
Tips 1：不可急躁、循序渐进
作为ScrumMaster，要能耐得住寂寞。罗马不是⼀天建成的，商鞅变法还进⾏了两次呢，敏捷转型也得慢慢来。
在这⾥跟读者分享⼀个ScrumMaster作为Change Agent推进测试驱动开发（TDD）的例⼦：
⼩张刚成为ScrumMaster不久，她还是⼀个即将毕业的研究⽣，在公司实习，被分配到公司的⼀个⼿机底层feature的研发团队担任ScrumMaster做敏捷转型。这个部门的成员都是公司元⽼级的程序员，他们彼此之间都很熟悉，⼤都使⽤C++进⾏开发，⽽且经验丰富。⼩张发现这个团队技术实⼒挺强，但是⼤家对软件代码质量并不是很看重，所以她想让团队使⽤TDD的⽅式进⾏开发，进⽽改善代码质量问题。于是⼩张跟团队提议学习并应⽤TDD，结果可想⽽知，遭到了⼤家的拒绝，原因是现在的开发任务都很赶了，没有时间学习TDD，使⽤TDD会增加⼯作量等等。
如果你是⼩张，应该怎么做来推进团队学习并使⽤TDD呢？
⼩张没有硬性强制团队从⼀开始就要使⽤TDD，⽽且她是实习⽣，很难能指挥得动团队⾥的元⽼们。但是她充分地发挥了她的软技能成功地让团队应⽤了TDD，她是怎么做的呢？
⼩张找到团队⾥⾯最资深的⼀名⼯程师，这名⼯程师喜欢挑战难题，我们暂且把他叫做⼩李。
⼩张对⼩李说：听⼤家都说您是C++的⼤⽜，相当的厉害！（请各位脑补⼩张的崇拜脸）我现在在做毕业设计，内容是“TDD在C++的应⽤实践”，您能帮帮我吗？
⼩李⼼想：都把我说得那么厉害了，⽽且还是个妹⼦，不帮也说不过去吧。
⼩李说：好的，那跟我说说吧。
…（此处省略n万字）
⼩张成功地把⾃⼰的劣势（实习ScrumMaster、需要写TDD的论⽂（当然这个论⽂可能是个幌⼦））转换成了优势，找到⼀个契机让⼩李帮助⾃⼰，从⽽⼩李开始学习并应⽤了TDD，甚⾄愿意分配业余时间研究TDD在C++的最佳实践。通过⼩李的实践，他变得⽀持⼩张的⼯作，觉得在团队推⾏TDD是有必要的。于是在接下来的迭代⾥，⼤家看到⼩李在使⽤TDD后代码质量的提⾼，也都纷纷开始学习TDD并应⽤到⼯作中。⼩张达到了推⾏TDD的⽬的。
对于新晋ScrumMaster可以学学⼩张的软技能技巧，先找突破口，先做到从0到1，从⽆到有，再逐步扩散。
Tips 2：攻⼼为上
上⾯的例⼦⾥，⼩张应⽤了软技能成功地在团队推⾏了TDD。但试想⼀下，如果她没有事先对⼩李有所了解（喜欢挑战难题）⽽找⼩李，⽽是找了其他不适当的⼈，推动TDD的事情还能完成吗？答案可能是否定的。
作为ScrumMaster，除了要对Scrum的知识熟烂于⼼之外，还需要花⼼思了解团队成员的性格、知道他们喜欢的沟通⽅式、做事的⽅式等等。如果团队中有⽐较外向、富有冒险精神的成员，那么我们ScrumMaster在推进新技术或组织Scrum活动的时候，可以先从这些成员⼊⼿，给团队树⽴榜样，有所成绩之后再带动整个团队；如果团队的成员性格谨慎、做事严谨，那么可以使⽤实验的结果、具体数据和这些成员沟通，因为使⽤这些更容易说服他们。
这⾥推荐ScrumMaster学习⼀些⼼理学的知识，例如可以阅读学习乐嘉的《性格⾊彩》，给团队的成员们找到他们对应的颜⾊。
Tips 3：做好团队的镜⼦
Scrum团队应该是⼀个能⾃我进化⾃我改善的团队。要想团队吸取教训做改善，必须要让团队充分体验到不进⾏改善的坏处，进⽽发⾃内⼼地去做改善。
ScrumMaster在Scrum活动的时候切记不能跳出来过多⼲预团队的⾏为，即使团队的⾏为是错的，我们应该让团队感受到切⾝之痛，否则容易“好了伤疤忘了疼”。
在Scrum刚开始的若⼲个迭代的，ScrumMaster甚⾄可以加速迭代的失败，从⽽让团队认识到⽬前存在的问题。ScrumMaster在迭代中要起的作⽤就如同⼀⾯镜⼦，如实地记录团队在迭代中的⼼路历程，在冲刺回顾的时候让团队来“照照镜⼦”，来发现⾃⼰哪⾥是美丽的，哪⾥是丑陋的，从⽽让团队⾃⼰提议改善的⽬标与⽅案。
这⾥强烈推荐两篇⽂章：《⼀⾯镜⼦的使命》和它的后续⽂章《ScrumMaster窘境之“你只是⼀⾯镜⼦”》。
Tips 4：持续学习与交流
可以在我们所处区域寻找敏捷的社区（如果有线下的资源最好）、参加敏捷相关的沙龙、关注⼀些公众号或专栏进⾏学习。可以学习社区⾥⼤⽜们的经验，同时分享⾃⼰的⼀些⼼得。尤其是对于新晋ScrumMaster⽽⾔，刚开始执⾏理论实践时，⼀定会遇到很多问题。在社区⾥可以把我们遇到的问题请教前辈们，利⽤集体的智慧来解决问题。
这⾥推荐⼀些Scrum公众号：Scrum中⽂⽹、思特沃克
结语
以上为本次笔者本次与⼤家分享的⼀些经验，以后笔者还会继续在⾃⼰的⼯作中总结经验和⼤家分享，也希望⼤家在本⽂留⾔分享你的经验和看法，供笔者和其他读者参考学习，谢谢！
*本文著作权归作者所有，转载请联系作者获得授权。
