用敏捷搞垮团队的10种场景

今天，整理了「用敏捷搞垮一个团队」的十个场景，希望让大家重新认知理解敏捷，是怎样瞬间搞垮一个团队的：

1、老板和团队都不了解敏捷

相信我，这点非常致命。很多老板对敏捷的理解还停留在：「敏捷就是快」的概念上。之前10个人干的活，现在用了敏捷，5个人就干完了。

记得有一位公司负责人跟我谈到敏捷，他的观点是：小学生都知道，敏捷就是快啊，效率提升、成本降低，老板们终于不用强制要求程序员加班了，只要大家敏捷起来就好了嘛。很多老板只看到了敏捷的好处，却没有看到敏捷开发模式的适用场景和缺点，在不是很懂的情况下贸然引入敏捷，将会给团队带来毁灭性的打击。

网络上有很多妖魔化敏捷开发的段子，很多朋友对敏捷也是一知半解，在团队成员半懂似懂的情况下推行敏捷，得不到整个团队对敏捷的支持和认同，基本上是很难成功的。所以，在老板和团队都不了解敏捷的情况下去推行，你大胆放心的搞敏捷，你肯定能够成功的，因为你离搞垮整个团队不远了。

2、只有软件技术团队敏捷，其他人不敏捷

也是很无奈的一点，软件研发部门的管理范畴仅限于研发，当你们的技术领导想推行敏捷时，公司内其他部门既不支持、也不懂敏捷、更谈不上认可敏捷，那这样的敏捷也只能在软件研发范围自嗨而已。尤其是业务方，他们只关心产品什么时候上线，不关心程序员今天开什么站会、写了几行代码、提了几个bug。

这一点近些年有所好转，因为有的业务部门也开始敏捷了。(说明产品方也开始卷了)所以，仅软件研发部门敏捷，其他配合部门不敏捷，也是白忙活，假敏捷。

3、团队技术能力较弱

在团队能力相对较弱的情况下贸然引入敏捷，对团队来说也是灭顶之灾。

有人说，我们都是受过九年义务教育的人，能力上的差别有那么大吗?还灭顶之灾，不要忽悠我。虽然你们是受过九年义务教育的人，而我也只是比你们牛一点点，我读了10年(复读一年)。这里说的能力不单单指技术能力，通俗的讲，是团队的每一位成员有没有独当一面的能力。

团队能力 = 每位成员的(技术能力 + 沟通能力 +需求理解能力+补位能力及意识等)

问题的本质其实是因为个人能力较弱、无法适应敏捷的交付节奏而导致的。换句话说，你要玩敏捷，得团队里面得都是高手才行。项目经理圈子

俗话说，一位优秀的程序员的工作效率抵十位平庸的程序员(金庸小说里面一个乔峰顶几十个杂鱼)。国内很多软件团队是不具备这个要求的，贸然引入敏捷，只能是照猫画虎、东施效颦，搞垮一个团队轻轻松松。

4、公司制度文化对犯错0容忍

敏捷模式的优势在于，当你产品需求还不确定时，可以摸着石头过河，先交付最小可用产品，先让产品上线，然后我们快速迭代、小步快跑、慢慢优化。

在这个过程中必然会有损耗、必然会犯错，因为团队接到的是一份不确定的产品需求(有时候甚至是一句话的需求)。在这种情况下，如果公司或团队文化是对犯错0容忍的文化，本身就与敏捷提倡的文化相违背。尤其涉及到上线失败等问题，更是很多企业不可容忍的高压线，毕竟站在公司的角度会有损失、会有人来承担责任、会有人受到惩罚，最后也只能是敏捷来背锅。

大家都是成年人，职场如战场，如果做不好就要重罚。如果犯错不用受罚，做错了事不用道歉，LV每年出这么多包包干嘛用的?

5、错把「噱头概念」当成「提效法宝」

老板们喜欢新鲜方法，TDD、BDD，这些新鲜玩意国外的团队玩的很很溜，我们也必须试一试。我只能说，如果要这么做，用不痛不痒的边缘项目练手还差不多，随便你怎么玩。如果是公司的核心业务，那也就离作死不远了。

TDD和BDD目前行业内还尚没有真实、靠谱的优秀实践项目，至少，从我的角度，目前能看到的就是这样一个现状。

BDD很多敏捷教练到处宣讲的也只是实验室内的案例，个人认为就是一个被炒作的噱头而已，做不起来的。

参加过BDD的培训你就会发现，敏捷教练给你传授的无非就是用cucumber写个given-when-then的框架，写几个订飞机票的demo、写个购物车下单的流程，这些都讲得通，但实际项目远比你这些复杂，远不是用cucumber整个BDD就弄明白的。就好比你是程序猿，写个hello world没问题，但这个玩意不足以应付真正的工作啊!

再说TDD这玩意，号称是测试驱动开发。TDD如果让测试工程师牵头来搞，测试工程师一年到头能写多少行代码、能设计多少个类图、画了多少个系统的架构设计，你叫测试工程师从业务场景的维度驱动开发工程师去做开发，这不是搞笑么?让测试工程师教开发工程师理解需求、写代码，让团队在开发和测试之间来回的返工，我们最好期待最后可以达到改1个Bug，需要优化整个架构的目标。

TDD如果让开发人员自己来搞，说白了，开发有能力把TDD整溜了，那么他不用TDD一样可以把代码写得很好，所以TDD这玩意不能雪中送炭，只能锦上添花。

6、不重视提效工具项目管理者联盟

我们应该重视能够提高大家工作效率的工具和方法，而不是野蛮地用「加班」的方式来解决工作效率问题。

前面吐槽了TDD和BDD，但并不代表整个行业没有好用的提效工具，恰恰相反有很多，这里堪比「好莱坞电影市场」一样琳琅满目，你能找到各种各样的提效小工具、小平台，网上大多数都已经有开源的了，即使没有，你根据自己的痛点也能够在公司内研发出来。

7、试图用敏捷解决技术问题

敏捷只是个抽象的工具、不是解决技术问题的手段。很多公司老板会说：「你们不是敏捷了嘛，怎么这个xxx问题都搞不定?」
　　
开发过程中遇到的各种技术问题，最终还是得靠技术能力去解决。所以，想要搞垮团队呢，大家遇到问题千万不要着急，要冷静，因为今天解决不了的问题，明天也解决不了。

8、不重视「人」，重「流程」

很多国内大公司都有这个通病，为了不让某位人才成为公司进步和发展的瓶颈，通常会把他的工作进行拆分、分解，由流程代替人才的稀缺性。

而敏捷团队恰恰相反，敏捷团队的规模很小，敏捷的基础就是团队，敏捷是由人来参与的，重视团队中「人」比重视敏捷中的「流程」更有意义。如果你是某个团队的负责人，可以自己问自己2个方面的问题：

1）有没有真正的尊重团队中的每一位成员，有没有充分让他们发挥自己的才能?有没有帮助他们成长、给予更多进步的机会?
2）团队中的创新情况如何，可以落地吗?有没有造轮子?能不能真正解决团队中的痛点?

作为团队的负责人，如果没有在团队身上花时间，能导致的结果只有：团队的核心人员不断流失，团队的普通成员没有工作想法，你说干什么他们就干什么。

最终，使团队中的所有人统统躺平：岁月静好，现实安稳，KPI和OKR(还有Google刚刚宣布的GRAD)随缘吧，一切都是最好的安排。

从敏捷中的价值观就可以看出来，敏捷开发模式是很在于「人」这个主体的，毕竟所有的敏捷活动都是由「人」来参与完成的，提高人才密度才是实现团队敏捷的正确姿势。

9、没有请真正的敏捷教练

什么?还需要敏捷教练?请一位敏捷教练的费用这么贵，我们自己学习学习，直接自己当教练就好了嘛。既省钱，还能学到东西， 一举两得。

况且我的友商早就敏捷了，我们连抄作业都不会抄吗?你还别说，我们程序猿都是绝顶聪明的人，我也不例外，虽然我只是绝顶而已。找一名真正的敏捷教练，能带给团队一种精神上、思想上的洗礼，这是和自学成材的敏捷教练最大的区别。

很多要点、坑、优秀的实践、业内最近流行的工具等，这些知识都能从他们那里获取，这是自学成才的敏捷教练所不具备的。

10、既然敏捷了，还要什么文档

敏捷价值观里提倡的是：可以工作的软件要高于详尽的文档。并没有说就不要文档啊!不重视文档这件事，在项目前期还好，产品的业务逻辑大家脑子都记得很清楚。但随着时间推移，随着团队成员的离职、入职、借调和请假，随着讨论的更加深入……。

文档较少，导致大家信息理解不一致，每个人对同一份需求都产生了自己的理解，有很多需求和设计都是自相矛盾的。导致沟通成本增大，犯错误的概率不断增大，最终也会搞垮一个团队。

PMP的报考所需条件如下：报名考生必须具备35小时以上项目管理PMBOK学习或培训经历，并出示相关证书复印件。
1.具有学士学位或同等的大学学历或以上者，申请者在五大项目管理过程中至少具有4500小时的项目管理经验，并且，在申请之日前6年内，累计项目管理月数至少达36个月。（在计算项目管理月份时，所要求的36个月是不重叠的、单独的。）
2.不具有学士学位或同等大学学历或以上者，申请者在五大项目管理过程中至少具有7500小时的项目管理经验，并且，在申请之日前8年内，累计项目管理月数至少达60个月。

新版考纲将专注于以下三个新领域:

人 – 强调与有效领导项目团队相关的技能和活动；
过程 – 增强管理项目的技术领域；
业务环境 – 突出项目和组织战略之间的联系。
内容贯穿价值交付范围（包括预测、敏捷和混合的方法），分布在三个考试领域。新的PMP考试将继续使用《PMBOK指南-第六版》作为参考。

新版考试题目为180道题；
考试时间为230分钟；
题型将包括单选题和多选题，多选题将说明需选择几个正确选项。