感谢我老婆，大周六自己在家带孩子，让我参加了一整天的敏捷Scrum Master 培训。我想如果这个培训是工作日在公司内部，大家是否还有如此的积极热情呢？今天只达到预期人数的一半，参与程度却非常高，结束之后大家都围着杜伟忠教练不断问问题。我切实的感觉到这些人真的是公司内愿意学习新知识，对敏捷，对改进有极大热情的人。我想无论是培训还是其他交流活动，想甄别出南郭先生还是真正热情的粉丝，选择周末举办是个不错的办法。

      抛开现实，在敏捷实践的活动中，我们可以组成自组织的小团队，频繁沟通、持续改进。但是真正讨论到敏捷落地，有些人一声叹息说“理想与现实还是有差距的”，也有些人觉得“有心问鼎，无力回天”，还有一大部分人抱着乐观而又被动的心态想着“总有人来帮助我们做出改变的”…

      世界的大环境都是一直在改变的，又何况我们所处在的小环境，面对变革，要么被淘汰，要么被改变。被动改变是痛苦的，想主动改变却又觉得无从下手干着急是更痛苦的。反正都要痛那么一下子，就好比打针，我们预期到针要扎在哪个屁股上，会事先做好心理准备的。所以我想可以先来分析下敏捷转型会扎到我们个人和组织的哪些痛处？

持续学习之痛

      组织中一部分人已经习惯了现有的工作方式，虽然有问题，但是凭着个人的经验也能够处理的游刃有余。

      作为开发，每天要应付很多的各种来源的任务，有的是产品经理和开发经理定的，有的是总监拍的。已经习惯了领导驱动的工作方式，也已经逐渐摸索出了一套“上有政策，下有对策”的应对措施。我已经习惯于通过google来解决问题，偏偏现在只能用百度，就忍了。你还要让我学习“重构”、学习“测试驱动开发”，学习“实例化需求”，学习“持续集成”？我只想说“我是写代码的，干嘛要管你们那么多事情”。

      作为测试，隔三差五的上线个小需求啥的，等待部署环境一个小时，等待数据同步三个小时，抓紧在午夜十二点之前完成十来个用例的线上验证，好回家睡觉。我上班不能学习吧，我要点页面，我要找开发，找产品，下班我还要加班啊，什么时间来学习呢？

我已经好久不碰代码了，自动化测试我怎么学的会呢？测试最牛逼的还是手动测试，专家都这么说了。

      作为产品，我都忙得找不着北了，我不主动去找开发人家也不搭理我，我天天要开会、要沟通，要写PRD，还要天天被测试缠着确认各种需求问题。我一直希望深入的掌握业务，可是我TMD也就是个公司业务方的代言人，就是你们天天说的“二道贩子需求”。别给我提什么Product owner是决定一个产品成败的关键所在，我只想着老老实实把领导关注的业务都给实现喽，敏捷啊，是你们研发自己的事情。

组织架构之痛

      组织结构是职能部门横向划分的，产品经理属于产品部门、开发属于开发部门、测试属于测试部门、项目经理属于项目管理部。每个部门的团队都要实现各自不同的价值，这样难免会出现“各扫门前雪”的情况。如果要敏捷，倡导跨职能的团队，原来独立职能团队积累的一些经验需要打破重来，原来的经理们需要重新找到自己的位置。这都是不容易的。

      首先从测试部门说起，目前测试团队的价值体现在什么地方？常常团队中认为发现足够多的Bug，编写足够多的测试用例，及时得反馈问题，这样就够了。可是真是这样吗？每每开发完成了提交测试，后期又出现项目周期延误，大家或多或少的心里嘀咕“测试时间这么拖这么长，能力不行吗？”有时线上出了问题，开发熬夜改bug到凌晨3点，他也会抱怨一句“这个问题怎么测试没发现？”。测试肯定觉得很冤，我们Bug和用例的数据都在那呢，最后处理问题的结果可能是开发测试各打五十大板了事。如果要敏捷转型，追求全能型工程师，测试部门独立存在的必要性就很小了，敏捷团队中的每个人无论是开发、产品、还是测试都会参与到测试中去，打破了对测试工程师自身的局限以及这个title的局限。面对组织架构的重构，测试部门及团队成员必须浴火重生，在提升业务能力和技术能力的同时才能体现出自身的价值。

       目前的开发部门，负责前台页面的不管后台Server的问题，负责单独模块开发的不负责公共部分问题的修改，开发主管一般作为Product owner来掌控项目。这样看起来，专业化、精细化的分工是能够把职责划分得更清晰，可是确常常会出现接力失误，导致接力棒掉在地上的情况。有些划分不清的区域，谁也不愿意也没有责任去主动承担。开发主管以小组成员利益的角度出发，在平衡客户需求和团队诉求时是非常困难的。可是，如果转型，必然需要调整组织结构，要重新打破旧有的平衡，已经到嘴边的“蛋糕”也需要重新分配。

      产品上面已经吐槽了，这里就说说项目管理部门。尴尬的项目经理没有考核项目成员的权利，却要承担着项目质量控制、进度控制、风险控制的责任，需要协调产品、研发、测试各个部门。可以不断的反馈问题，推动起来却重重阻碍。出现问题汇报领导，项目组成员觉得你爱打小报告，若是不汇报，出现问题，又要承担没有及时反馈的责任。因此只能说这个战场比拼的是情商和个人魅力，这样才能够顺利周旋于多个角色之间。那么，转型敏捷后，项目经理要面临什么样的角色转换呢？Scrum master 还是 product owner，还是重新开始写代码，成为一名团队成员呢？

渺小的个人VS强大的影响力

      渴望改进的人，绝不是消极的，抱怨是无解的。敏捷的思想是要相信团队，无论是自己所在的小团队，还是公司这个大团体。还要相信个体的力量，通过不断学习提高自己的能力，发挥“日拱一卒”的精神，抱着一颗同理心，帮助他人，与团队内外的成员共同进步，去建立自己的影响力。做好心理和技能的准备，不断的实践尝试，一步一步实现改进的愿望。

      说起来是这个道理，可是有人会说了，我作为一个普通员工，我甚至只是一个测试工程师，处于项目流程的下游，我感觉自己什么也做不了。即使领导支持敏捷了，我们作为测试，不会直接的交付产品，我们也无法单独敏捷啊。或者作为一名开发工程师，或者产品经理，个人都是没法一下子去推动敏捷改进的。还有人说，那就等吧，你不用操那么多心，你所想的迟早有一天公司都会帮你实现的。。。

      不只是我们自己相信，敏捷思想是经过验证的能够提高交付价值，提高团队效率的有效工具。因此，我们要相信好的东西，大家是没有理由不喜欢的。就好比美味的螃蟹，大家不去吃，是因为不知道它的美味，不同的人看到的是不用的角度，有的人只看到了张牙舞爪的钳子，有的人只看到了硬硬的壳子，在没有品尝到美味的蟹肉和蟹黄之前，大家都不可能欣然接受，更何谈去主动参与，积极推动呢？

      杜伟忠教练也给我们分享过一个实例，原来他还没做敏捷教练，是热心敏捷的爱好者。他的办法就是鼓励身边的同事或领导和他一起去参加敏捷的社区或者交流分享活动，让大家逐渐都感受到敏捷的魅力，大家都觉得好了，自然推动起来就没什么阻力了。这只是一种影响他人的方法。我们也可以从自身做起，不断学习，去掌握敏捷的精髓，提炼出真正提高生产力对团队有益的实践，先小范围应用到实际工作中，身边的人自然会看到你做的一切，自然会感受到敏捷的力量。

      这是互联网的时代，按照互联网思维，每个人都是一个节点，通过建立连接可以发挥无穷的影响力，方法就是不断的 学习、实践、沟通、分享 ，循环往复…

[如需转载，请标明出处并保持文章完整性]