本文共计4062字，阅读时长预计15分钟。
前言
在无数次电话面试的时候，面试官问：“如果你来做我们的敏捷教练，在一个没有敏捷基础的团队中，带敏捷转型你要怎么做?”
我说：我可能什么都不做，一定要做什么的话，那就做个被动者，用团队的错误，做正确的事。”
融入 | 别做团队的麻烦制造者
“我最近进入了一个团队，发现了不少问题，要如何让他们听我的？“
“我学了Scrum觉得有用，可团队都不太感兴趣，要怎么办?“
这是我最近在参加完一场敏捷分享会后，收到几个学员的提问。
团队的转型存在于各行各业中，近年来互联网行业为了应对市场的高速变化环境，敏捷转型成了一个热门词汇。那么，正如学员的提问，初入一个需要转型的老团队到底要先要做些什么？
与从零开始建立团队不同，作为一个要打破团队习惯的革命者，初入团队时既是革命者同时也是一个新人。不同人有不同的性格，所产生的气质和团队形成的氛围也都不同，后续适合的转型之路也会有不一样的差异。路有千万条，千万别走麻烦制造者这条。
什么是麻烦制造者？
寻找问题、寻找差异是人的本能，无论什么岗位，为了快速的体现个人价值，会用各种方式寻找团队中的问题再一条条列出，然后希望按照自己学到的知识在团队中进行大刀阔斧的改革，这就是常见的麻烦制造者。
所谓的麻烦制造者，往往为了找问题而提出问题，且不说目的是否正向纯粹，就改革而言，当一个带着问题来的项目经理、敏捷教练，在实践过程中必然会有一股无形的阻力，这个阻力正好来自原本需要他的对象——团队
为什么？
试想，在原本一个已经正常运行的团队中，如果因为你的出现而找出了一堆问题，那么对团队来说，显然这些问题唯一的源头是来自于你。当团队认为你就是问题的源头，那么产生的结果只有两种：“对抗”或“隐藏”
“对抗”或许比较容易化解，有很多方式可以解决对抗问题，哪怕是请客吃饭这样的“资本腐蚀”。而“隐藏”是可怕的，“隐藏”指的是隐藏问题，表现为：表面上认同你，但内心中处于不认可或抵触的状态，不理解新的方法同时也不表态，更不愿意告诉别人真实的想法。最终表现的一片祥和，似乎什么问题也没有。
但看不见，问题难道就不存在么？
所以在敏捷改革转型中最怕的不是一个有各种问题的团队。看似完好无缺没有任何问题的团队往往是敏捷教练或领导者最需要担心的。
形成 | 战斗前先统一战线
从正面的保护团队、建立信任的是转型的根基，也是敏捷教练的原则之一。
如何和在融入团队的初期中避免出现“对抗”或“隐藏”的情况呢？
在针对团队A转型过程中，第一个月我只做了两件事情，观察与帮助：
1. 观察团队中存在的问题，了解让成员们感觉到痛苦的事情
2. 在成员抱怨时，出现在身边去倾听和理解他们的抱怨，并且适度的提供帮助
七月中旬，笔者所在的研发团队经历了需求反应不及时，产品质量问题频发等事件，受到了来自业务方的压力。此时作为一个敏捷教练或是领导者，无法直接帮助参与实际研发工作，能做的便是保护团队。
如何保护团队？
在保护团队方面有很多方式：提团队挡住外部压力、消化业务方、上下级之间沟通上的负面情绪、为团队解决相关支持等等
总之，保护团队让团队有足够的安全感，便是建立信任关系的第一步。信任关系也无需太多花哨的技巧，你用心且认真的保护团队且为之努力，团队是能够感知到你的真诚，也能够真正的建立信任，战斗也就可以开始了。
改革 | 挖坑是一门艺术
问题并不会因为你一开始的“不作为”而消失，也不会因为出现了“事件”才有存在问题。问题的暴露恰好证明它一直存在，只是凑巧的被事件暴露了出来。
在进入团队A的第一周时，我参加了包含部门负责人（市场方面）、产品、研发团队的月计划会议。
会议中，产品按照市场提出的需求，洋洋洒洒列几十条，然后一条条解释需求，提出希望（必须）上线的时间。团队成员按照要求的时间点，一条条进行承诺。最终会议结束发现，一个月的时间要完成近两个月的开发量，总任务数的二分之一被列为最高优先级，预估达到月底上线的的任务也排在了最高优先级。
产品、运营、市场信心满满，开发团队一脸迷茫。
会议全程，我没有做出任何发言，哪怕我感知到了这场会议后存在的风险，有哪些问题，团队要经历哪些痛苦。有些“坑”，必须让团队自己跳下去。
牛顿的第一定律说到：“一切物体在没有受到力的作用的时候，运动状态不会发生改变”这一定律在人和团队身上通样适用。
一切的改变背后都需要一个绝对的动能
团队自己犯错、自己经历错误，再自己思考问题的一些列过程，就是一个很好的动能。也是认识问题的必要过程，这个过程我称之为：挖坑（当然，所谓的“坑”要可控、团队能够承受的范围内。明知道团队在制作炸弹，还在旁边抽烟围观是不可取的）
延期是意料之内的事
经过一个月痛苦的研发过程，“坑”如期而至，月末统计：
计划偏差：30%
需求完成率：60%
更新缺陷率：20% (注：每次更新出现BUG的概率)
到底是哪里出了问题，是什么导致了理想和现实的差距？每个人都陷入了反思：“是计划管理出现偏差？”、“是研发效能偏差？”...
这里我们再回顾一下月初的计划会大家做了哪些事情：
计划太过理想，月初就定好了整月、甚至下月的需求
研发团队估时不准确
优先级概念不清，一半的需求放到最高优先级
转变 | 如何把“瓜”给扭“甜”了
人性的特点：在相同条件下，对一个事物的绝对值估算的误差远大于具有参照物的相对估算
在问题出现后，应团队主动的要求，我和团队来了一场全新的计划会：
1.计划太理想。月初要做接下来一个整个月的规划，在面对时刻变化的市场需求下显然是不科学的，毕竟这不是盖房子。
那么我们就不做一个月的计划。开始建立需求池，市场提出的需求都收集下来，但我们只承诺第一周要做的任务。在开始第二周的工作前，需求池可由产品自由变动。（熟悉敏捷的同学可以看出，潜移默化中团队开始Scrum的迭代冲刺的模式）
2.无法准确的评估期限。原本团队评估模式是：事先安排好所有任务的负责人，再由负责人根据经验预估任务的工作量做出期限承诺。
“太美的承诺因为太年轻”
日常工作过程中，各种会议、BUG、活动、甚至一次下午茶的打断。都会影响到任务的完成时间，而任何一个不能完成的任务估时，其实都是一种不负责的表现。
敏捷中关于任务评估有两种方式，通过团队商议，这里我们用到了其中一种“故事点”以及”宽带德尔菲“技术：每个故事由产品讲解，所有开发人员各自进行估算后同时展示，差异部分进行讨论，最终得出所有人一致认可的估值。
同时，我们将需求由组长分配，改为成员认领，谁完成了自己的任务，可以立即领取新的任务，这样可以有效的消除任务等待的时间。
3.优先级概念不清。现实环境中所有需求，在产品、市场单独来看，它都是重要的，所以台州组出现的但其实在产品开发过程中一直存在80/20法则（俗称二八定律)，80%用户、价值存在于那20%的功能。
如何全部优先级的时效性？可视化、透明化的工作看板是一个选择
团队A原本使用的是在线敏捷管理工具Teambition，在线工具有它一定的先进性，例如信息、数据的保存，以及异地办公的支持。但实际使用情况仅是项管、研发团队内部使用其实是不足的。正如我们执行的“早会三件事”，信息的可视化、透明化、是为了团队能够更好的理解共同的进度、确保大家努力的方向是一致的，所以如果学习工具成本过高，那么我们就化繁为简，用最原始的方法——纸和笔。
就这样，我们开始使用了Srcum看板，把所有的任务按照：
“需求明确度*市场价值/故事点=优先级”的方式进行排序。最高优先级的任务一定是：独立、可估量、有价值、短小、可测试的（敏捷中的用户故事属性理论)。将研发过程、进度、目标贴在最显眼公开的地方，新增需求、BUG再用不同的便签区分。无论是集团总裁还是保洁阿姨都能看懂这个团队现在的工作情况。这便是“信息发射源”的最初用法。ACP培训,ACP认证,acp证书含金量,ACP是什么,圣略ACP考试培训,ACP题库,ACP历年考试真题及答案,ACP备考资料
体系 | 成功的标志是建立体系
一个好的方法，没有得到有效的执行，它就只是纸上的文字。
方法在执行中走了样、贯彻不到位，等等都是团队转型过程中会遇到的常见问题。
如何有效的执行？授人以鱼不如授人以渔
通过”挖坑“的事件，方法是团队主动和我共同约定而成的，所以在执行过程中，我唯一要做的就是监督提醒与引导。或许初期会去帮忙团队做一些工作，但一定是在一个限度以内。以至于经常和团队说的一句话：“哪天我一忙，这些事就要你们自己做了“
会议一定要领导者开吗？决策一定要领导者做吗？问题一定要领导者发现吗？
其实有时候团队自己做的比你更好
团队自我思考的养成，是革命者的终极目标，没有何一个方法、模式是最好的，好的改进需要团队自我持续思考，这也是一个体系建立成功的标志之一。故“以退为进”是要转型中可以适度使用的方式。
改变是一个长远而持续的过程
敏捷开发管理是一个不断迭代、优化产品来应对市场而提升最大价值的开发模式。而我们在帮助团队做转型时同样也是一个不断迭代、优化的过程。不同的团队有着不同的特点、习惯、问题甚至于价值观，所以在做转型过程中需要注意以下几点：
1. 要根据团队实际遇到的问题和选择合适的方法。现如今
“管理方法：PMP（瀑布式开发）、CMMI、Scrum、XP等等、
工具方面：Teambition、Jira、TAPD、钉钉等。
技术方面：特征驱动开发、测试驱动开发等”
在项目管理、团队管理中有着很多很多成熟的模型、工具、但切记没有任何一件东西是完美万能的，在团队转型过程中需要“逢山开路、遇水架桥”，裁剪和改进（如看板工作流）已经成熟的理论、工具、方法是一件很正常的事，正如我常说的：适合的才是最好的。
2. 保持倾听、最好最合适的方式往往来自于团队自我的思考与方式，很多时候管理者要做的只是点题，剩下的团队自己会告诉你。
3. 理论知识不在于记、而在于用。如前面说到的用户故事、看板工作流、敏捷迭代，都是在执行过程中实践反向印证了理论的合理性。
4. 问题总是一点一点、一次一次的浮现，团队无法一次进行全方位的改变，也无法一瞬间就把问题彻底改好，所以需要保持一些耐心，给团队适应的过程，只要持续的进步，相信“all is well”（一切终会变好）
附言
写下这篇的初衷是为了记录，最终受到了“开源精神”所影响，后续将陆续写关于”产品与团队管理方面”实战经验。在实践过程中你和团队或许都会遇到无法解决的问题，勿慌：“破万卷书，心中自有青竹”
路行千万里，共进之。
粤公网安备 44010602010970