微信公众号的江湖里有个说法，叫「三千字断头台」，也就是一篇文章不太会写超出了3000字，因为大部分人对一篇文章的阅读极限就是3000字（甚至更少），超了字之后大家读不完，今后也不太会去读了，最后导致看的人越来越少。
我自己也比较纠结，后来意识到一个问题，我写文章主要对内容负责，大家看不看根本就不是我所关心的问题，我的核心目标是把内容写好，所以也就释怀了，我只关注内容是否能够表述清楚、逻辑是否合理。
提前告知大家，今天的篇幅略长，主要是敏捷这个话题，涉及的面太广了。
掐指一算，自己从2000年左右第一次接触敏捷，至今已有10多年了。还记得那时第一次参加了一场为期2天的敏捷的培训，老师是个老外，中文讲得不错、很健谈，课上有概念、有游戏、也有很多学员之间的互动，整个体验还是不错的。在2天的培训最后结束时，老师让每位学员谈一下自己对敏捷的感受。我当时也是年轻（年少无知），我直接大声说出了自己的感受：「敏捷更适合存在于乌托邦的团队或公司里，不适合大规模推广」（现在看来肯定是啪啪打脸，因为当时我的认知水平，只能到此程度）。那时，我觉得敏捷中很多价值观、宣言、规则流程设立的太理想化了，曾经在瀑布式模式开发过的小伙伴应该清楚，现实世界是很复杂的、人性也是非常复杂的，各种奇奇怪怪的事情、人和人之间的矛盾、组织与流程之间的不协调、领导风格的多种多样，想找一个全部都认同敏捷文化、且不折不扣去执行的团队真的太难了！（现在行业中也依旧很难，但不代表没有）培训结束回到公司，领导问我培训参加过后，感觉如何。我不遗余力的给老板和团队讲，敏捷有多好，敏捷有多么高大上。原因不为别的，是因为他们不懂敏捷，我这么说更显得自己2天的培训时间没有白白花掉、酒店的自助餐没有白吃。说实话，当时的我其实只是想告诉自己的领导，选择让我去参加培训是一个多么明智的决定，而并非我对敏捷的理解有多么深刻。10多年过去了，随着时间的流逝，对人阅历、对事情的判断、对敏捷的认识，和当初有了不一样的理解和感悟。敏捷只是一个开发模式的工具而已，既不是长生不老药，也不是解决一切问题的办法，不用盲从，也不用鄙夷，如果你觉得合适，你就拿来用就好了。之前薛兆丰老师有一个说法，如何让一只鹦鹉成为经济学家呢？答案是：只需要让鹦鹉学会「需求」和「供给」两个关键词，这只鹦鹉也能成为经济学家。这个调楷一方面说明了「需求」和「供给」是经济学最核心的概念和逻辑；另一方面又说明了，看似简单的「需求」和「供给」概念，想要搞清楚并不是很容易。同样，对于敏捷，如果让我给出最核心的两个词让鹦鹉成为敏捷教练，我会选择「产品」和「团队」这两个词。产品这个关键词，可以衍生出敏捷中很多概念：产品思维、产品需求、产品迭代、产品价值等。面对产品需求不明确、能为用户创造哪些价值不知道、用户体验又要超过同行的产品，这已经超出了普通程序员在学校里面学习的计算机知识了。团队这个关键字，可以衍生出敏捷中很多概念：人性、角色、团队能力、团队沟通、团队承诺等。面对不同背景、学历、来自五湖四海、脾气秉性差异极大的同事们，能不能把这个团队服务好，已经远远超出了Scrum Master的知识领域了。朋友们可能会感到奇怪，我为什么没有提到敏捷的各种流程、各种会议、各种价值观、各种宣言？我的认知是，敏捷仅仅是个抽象工具而已，承载敏捷的核心无非就是：「产品」和「团队」，各种流程需要团队去执行、各种角色需要团队去胜任、各种能力需要团队所具备、各种沟通需要团队参与、各种宣言则需要团队去承诺。而团队的工作，就是把不确定的产品需求逐渐交付落地，帮用户弄清楚产品价值，交付最小可用产品（扔个石子探探路，摸索前进），在此基础上小步快跑、快速迭代（步子太大容易掉坑里，慢慢摸着石头过河）。所以，敏捷模式最适合的就是那种「还不确定、还不完善、还没想清楚的产品需求」，团队逐渐调整磨合、不断交付产品价值。曾经有一位朋友跟我这样讨论过敏捷，他觉得现在互联网这些公司之所以推行996工作模式，敏捷开发模式在背后起到了推波助澜的作用。他还举了很多例子，我取其中最有代表性的给大家分享一些。很实际，很多公司老板之所以用敏捷，就是为了产品早点上线，最终事情做不完，大家只能加班完成了。以前瀑布式开发模式，项目的开发周期可能是半年到一年左右，至少也有一个季度。从需求调研、立项、技术的选型、架构的设计、基础环境搭建这些都需要时间，包括项目的开发、测试、项目延期等等。而敏捷开发模式推崇一般2周一个迭代，在什么都不明确、什么都不知道的情况下，我们直接开始干，先做一个最小可交付的版本。敏捷的站会是要当着同事们的面，说清楚昨天认领的工作为什么没有完成，这让我这位朋友感觉很丢人。他说，以前在瀑布式开发模式的时候，3天内搞定1个模块的功能，妥妥的没问题，自己合理安排时间，哪怕下楼抽烟摸鱼也好、电脑里看看小说也好，时间可以自由安排，规定时间内自己搞定就好了。现在敏捷模式，任务要大家一起估点，估多了时间点可不行，大家都看着呢；每天要汇报昨天工作的进度，每天任务安排的紧紧的。他说，程序员也应该是一个知识管理、创造性类型的工作岗位，不应该是搬砖、执行类的岗位，我今天状态不好，就是不想写代码了，效率自然就低了；我明天状态奇佳，一小时顶五个小时的效率，效率自然就高了。（我则笑他，你一个码农，搬砖就好好搬，还跟我讲状态了……）听了以后我瞬间无语，试图跟他讨论一番。但转念一想，这也很正常。大家同样是读一本《百年孤独》经典名作，一百个读者就有一百个哈姆雷特，何况是敏捷呢？趁五一假期不能出门游玩的这几天，我整理了「用敏捷搞垮一个团队」的十个场景，希望让大家重新认知理解敏捷，是怎样瞬间搞垮一个团队的：如果你的团队目前符合1种情况，说明你们团队现在用敏捷用的挺不容易的。如果你的团队目前符合2种情况，说明你们团队现在过的并不如意。如果你的团队目前符合3种情况，说明你们团队已经开始反感敏捷模式了。如果你的团队目前符合3种以上的情况，我劝你早点跑路找下家。很多老板对敏捷的理解还停留在：「敏捷就是快」的概念上。之前10个人干的活，现在用了敏捷，5个人就干完了。记得有一位公司负责人跟我谈到敏捷，他的观点是：小学生都知道，敏捷就是快啊，效率提升、成本降低，老板们终于不用强制要求程序员加班了，只要大家敏捷起来就好了嘛。很多老板只看到了敏捷的好处，却没有看到敏捷开发模式的适用场景和缺点，在不是很懂的情况下贸然引入敏捷，将会给团队带来毁灭性的打击。网络上有很多妖魔化敏捷开发的段子，很多朋友对敏捷也是一知半解，在团队成员半懂似懂的情况下推行敏捷，得不到整个团队对敏捷的支持和认同，基本上是很难成功的。所以，在老板和团队都不了解敏捷的情况下去推行，你大胆放心的搞敏捷，你肯定能够成功的，因为你离搞垮整个团队不远了。也是很无奈的一点，软件研发部门的管理范畴仅限于研发，当你们的技术领导想推行敏捷时，公司内其他部门既不支持、也不懂敏捷、更谈不上认可敏捷，那这样的敏捷也只能在软件研发范围自嗨而已。尤其是业务方，他们只关心产品什么时候上线，不关心程序员今天开什么站会、写了几行代码、提了几个bug。这一点近些年有所好转，因为有的业务部门也开始敏捷了。（说明产品方也开始卷了）所以，仅软件研发部门敏捷，其他配合部门不敏捷，也是白忙活，假敏捷。在团队能力相对较弱的情况下贸然引入敏捷，对团队来说也是灭顶之灾。有人说，我们都是受过九年义务教育的人，能力上的差别有那么大吗？还灭顶之灾，不要忽悠我。虽然你们是受过九年义务教育的人，而我也只是比你们牛一点点，我读了10年（复读一年）。这里说的能力不单单指技术能力，通俗的讲，是团队的每一位成员有没有独当一面的能力。团队能力 = 每位成员的（技术能力 + 沟通能力 +需求理解能力+补位能力及意识等）请参考上文朋友公司内使用敏捷后所吐槽的2个感受：上线太快、工作完不成。问题的本质其实是因为个人能力较弱、无法适应敏捷的交付节奏而导致的。换句话说，你要玩敏捷，得团队里面得都是高手才行。俗话说，一位优秀的程序员的工作效率抵十位平庸的程序员（金庸小说里面一个乔峰顶几十个杂鱼）。国内很多软件团队是不具备这个要求的，贸然引入敏捷，只能是照猫画虎、东施效颦，搞垮一个团队轻轻松松。 上文说了，敏捷模式的优势在于，当你产品需求还不确定时，可以摸着石头过河，先交付最小可用产品，先让产品上线，然后我们快速迭代、小步快跑、慢慢优化。在这个过程中必然会有损耗、必然会犯错，因为团队接到的是一份不确定的产品需求（有时候甚至是一句话的需求）。在这种情况下，如果公司或团队文化是对犯错0容忍的文化，本身就与敏捷提倡的文化相违背。尤其涉及到上线失败等问题，更是很多企业不可容忍的高压线，毕竟站在公司的角度会有损失、会有人来承担责任、会有人受到惩罚，最后也只能是敏捷来背锅。大家都是成年人，职场如战场，如果做不好就要重罚。如果犯错不用受罚，做错了事不用道歉，LV每年出这么多包包干嘛用的？老板们喜欢新鲜方法，TDD、BDD，这些新鲜玩意国外的团队玩的很很溜，我们也必须试一试。我只能说，如果要这么做，用不痛不痒的边缘项目练手还差不多，随便你怎么玩。如果是公司的核心业务，那也就离作死不远了。TDD和BDD目前行业内还尚没有真实、靠谱的优秀实践项目，至少，从我的角度，目前能看到的就是这样一个现状。BDD很多敏捷教练到处宣讲的也只是实验室内的案例，个人认为就是一个被炒作的噱头而已，做不起来的。参加过BDD的培训你就会发现，敏捷教练给你传授的无非就是用cucumber写个given-when-then的框架，写几个订飞机票的demo、写个购物车下单的流程，这些都讲得通，但实际项目远比你这些复杂，远不是用cucumber整个BDD就弄明白的。就好比你是程序猿，写个hello world没问题，但这个玩意不足以应付真正的工作啊！TDD如果让测试工程师牵头来搞，测试工程师一年到头能写多少行代码、能设计多少个类图、画了多少个系统的架构设计，你叫测试工程师从业务场景的维度驱动开发工程师去做开发，这不是搞笑么？让测试工程师教开发工程师理解需求、写代码，让团队在开发和测试之间来回的返工，我们最好期待最后可以达到改1个Bug，需要优化整个架构的目标。 TDD如果让开发人员自己来搞，说白了，开发有能力把TDD整溜了，那么他不用TDD一样可以把代码写得很好，所以TDD这玩意不能雪中送炭，只能锦上添花。我们应该重视能够提高大家工作效率的工具和方法，而不是野蛮地用「加班」的方式来解决工作效率问题。前面吐槽了TDD和BDD，但并不代表整个行业没有好用的提效工具，恰恰相反有很多，这里堪比「好莱坞电影市场」一样琳琅满目，你能找到各种各样的提效小工具、小平台，网上大多数都已经有开源的了，即使没有，你根据自己的痛点也能够在公司内研发出来。根据茹炳晟老师的研发效能双流模型的分享，我列举一些大家不常见的提高工作效率工具插件，希望对大家有所帮助：混沌工程：ChaosToolkit、ChaosBlade除了上述，我在公司里也和同事们经常利用业余时间开发一些「提效」的工具，我写的书《敏捷测试高效实践 测试架构师成长记》里面就介绍了一款：能自动生成接口自动化测试脚本的工具。感兴趣的可以直接拖至文末扫二维码购买。再多说一句，前段时间某位大厂的开发领导跟我讨论技术时，聊到了自动化测试这块，这位技术团队的大神认为自动化测试是割韭菜的概念，统统要砍掉。（我是真心服了）那位大神在上线前，对着测试工程师说：「是时候展现测试工匠精神的时候了，我们从0造轮子，大家赶快用鼠标“点点点”，把所有功能都回归一遍」。我觉得这位所谓的「技术大神」内心是对技术是没有敬畏的，此时心疼他团队的测试工程师三秒钟。敏捷只是个抽象的工具、不是解决技术问题的手段。很多公司老板会说：「你们不是敏捷了嘛，怎么这个xxx问题都搞不定？」开发过程中遇到的各种技术问题，最终还是得靠技术能力去解决。所以，想要搞垮团队呢，大家遇到问题千万不要着急，要冷静，因为今天解决不了的问题，明天也解决不了。很多国内大公司都有这个通病，为了不让某位人才成为公司进步和发展的瓶颈，通常会把他的工作进行拆分、分解，由流程代替人才的稀缺性。而敏捷团队恰恰相反，敏捷团队的规模很小，敏捷的基础就是团队，敏捷是由人来参与的，重视团队中「人」比重视敏捷中的「流程」更有意义。如果你是某个团队的负责人，可以自己问自己2个方面的问题：1、有没有真正的尊重团队中的每一位成员，有没有充分让他们发挥自己的才能？有没有帮助他们成长、给予更多进步的机会？2、团队中的创新情况如何，可以落地吗？有没有造轮子？能不能真正解决团队中的痛点？作为团队的负责人，如果没有在团队身上花时间，能导致的结果只有：团队的核心人员不断流失，团队的普通成员没有工作想法，你说干什么他们就干什么。最终，使团队中的所有人统统躺平：岁月静好，现实安稳，KPI和OKR（还有Google刚刚宣布的GRAD）随缘吧，一切都是最好的安排。从敏捷中的价值观就可以看出来，敏捷开发模式是很在于「人」这个主体的，毕竟所有的敏捷活动都是由「人」来参与完成的，提高人才密度才是实现团队敏捷的正确姿势。什么？还需要敏捷教练？请一位敏捷教练的费用这么贵，我们自己学习学习，直接自己当教练就好了嘛。既省钱，还能学到东西， 一举两得。你还别说，我们程序猿都是绝顶聪明的人，我也不例外，虽然我只是绝顶而已。找一名真正的敏捷教练，能带给团队一种精神上、思想上的洗礼，这是和自学成材的敏捷教练最大的区别。很多要点、坑、优秀的实践、业内最近流行的工具等，这些知识都能从他们那里获取，这是自学成才的敏捷教练所不具备的。敏捷价值观里提倡的是：可以工作的软件要高于详尽的文档。并没有说就不要文档啊！不重视文档这件事，在项目前期还好，产品的业务逻辑大家脑子都记得很清楚。但随着时间推移，随着团队成员的离职、入职、借调和请假，随着讨论的更加深入……。文档较少，导致大家信息理解不一致，每个人对同一份需求都产生了自己的理解，有很多需求和设计都是自相矛盾的。导致沟通成本增大，犯错误的概率不断增大，最终也会搞垮一个团队。敏捷，就像“天上人间”里面的漂亮小姐姐，很多人都想占她的便宜，但没有一个真心想娶她回家。虽然本书是一本非常严肃的技术书籍，但是，处处却不乏创新。全书有22幅漫画贯穿全书，讲述了一位从校园毕业的「测试小工」如何逐渐成长为「测试架构师」的，这期间经历的磨难、焦虑和有趣的事，凭着主人公自身的付出和努力，终于成长为一名优秀的「测试架构师」。整个过程是非常有意思的，与其说这是一本技术书，不如说是一本「测试工程师的凡人修仙传」，生动搞笑的叙述风格贯穿整本书，让你在努力学习技术的同时，劳逸结合。
作者简介：就职于世界500强知名企业、国内某知名金融商业银行 担任 技术经理 一职。拥有16年以上的软件开发、测试和项目管理经验，畅销书《敏捷测试高效实践 测试架构师成长记》作者，精通于自动化测试、敏捷测试、探索测试和测试工具平台的开发设计研究。