天天被死亡的敏捷
内容列表
本文由来
就我的记忆中来看，没有任何一项事物如同敏捷这般，天天被叫嚣着已经死亡的东西，还能焕发出如此大的活力。这不禁让我想起来当时做研发的时候，天天喊着PHP要死的那帮人，不知道他们现在是不是还在喊着同样的口号。我觉得“天天被死亡的敏捷”，也差不多会有同样的结果。
原本我对这个也觉得不屑一顾，没想到某曾经明文保存密码的网站，连续发了两篇翻译稿，意图来砸我饭碗，这就感觉应该稍微说两句关于敏捷这事儿。
还是那句──吐槽敏捷不是问题，但是请吐在点上，而不是一知半解来吐槽它。
敏捷为什么“要死了”
敏捷“要死了”这事儿还是比较好理解的，毕竟随着这几年的各大培训公司、咨询公司对敏捷过分的吹捧，导致不少人对其“路人转黑”也是正常的操作，再加上敏捷成功的案例的确是乏善可陈，在种种情况下，对敏捷的反感也是人之常情。
除此之外，敏捷自身也给了别人黑它的机会。敏捷表示自己只是一种“理念Mindset”而不是某种框架或者方法论，这让不少对敏捷掌握不到位的敏捷从业者感觉无从下手，从而陷入“要么无所适从”，要么“对某个框架（当前大部分是Scrum）直接照搬”的两极分化的局面，最终由于无法灵活应用，使得敏捷实施和落地非常不顺，进而对敏捷本身产生了极大的疑问，甚至直接得出“敏捷不可行”的结论。
与此同时当前敏捷社区中各种流派之间的互相鄙视，“真”、“假”敏捷之争依然存在，让人感觉这个圈子水太深，甚至让初学者无所适从，最终放弃。严格来说，这点也是上述“敏捷是一种理念”的衍生结果，但由于这种争论所产生的影响并不仅仅限于“怎么做”，而是到了“你们敏捷自己都这么乱，到底行不行”的程度，因此将其单独拎出来说。
种种场景加持下，唱衰敏捷是一种必然的结果。
但这不是问题的核心，敏捷之所以会被唱衰，在我看来更多还是因为两点：
- 落地、实施的困难
- 敏捷的边界在无限制扩大，这个名词开始德不配位
为何敏捷难实施
除了上面所说敏捷本身为一种Mindset之外，敏捷落地与实施的另一个问题在于：不同角色看待敏捷、对敏捷的期待是不同的。
对于管理层而言，谈到敏捷就会条件反射认为这是“快”的代名词，这些领导层寄希望于“用了敏捷，就可以大幅提升生产力、提升人员能效、降本增效”，因此对敏捷的期待会放在这些地方。一旦敏捷短时间内无法达到这些效果，对敏捷的支持、信任就会逐渐下降。
对研发人员而言，对敏捷的期待和预期会稍稍复杂一点。
不少研发人员对敏捷充满了幻想，认为敏捷宣言中的十二项原则告诉我们“保持稳定的持续工作节奏”，就可以让研发人员不用加班，朝九晚五➕️双休指日可待。因此对敏捷充满了期待，对其充满了赞美之词。然而这种情况终究只是幻觉，是否需要加班这个问题，并非敏捷可以以一己之力搞定，这与公司的企业文化、领导者管理水平以及产品发布节奏等有着极为重要的关联。因此“不加班”这种幻觉，很可能会被击碎。
而另一个极端是对敏捷充满了敌意，认为敏捷就是不断加活（中华田园敏捷，大家都懂）。此时敏捷仿佛变成了管理者或者PM对“工作量”的灵活处理，同时再加上有些企业对敏捷所需的配套设施不全，比如绩效考核、奖励机制，导致想要使用敏捷的团队，最终不得不按照之前传统管理方式所定义的流程、制度所规定的内容之外，还要加上敏捷特有的活动，比如站会、评审、回顾等内容，让团队反而承受了比之前更大的工作量。在这种情况下，对敏捷的唱衰也是势在必行，否则团队在这种双轨制同时实施的情况下，比较容易精神分裂，最终由于人性中“趋利避害”的本性，团队直接退回传统方式也是常态。
而对于敏捷教练而言，特别是一些没有经过严格训练、学习的敏捷教练（姑且这么称呼），会将敏捷看作一种万能药，认为企业的所有问题都可以通过敏捷来解决。这种敏捷教练不少人是来自于那些所谓的咨询公司，而这些咨询公司会有自己已经定义好的做法，比如有些咨询公司会以SAFe作为企业敏捷转型的框架，在为企业实施辅导的过程中，强行将其导入到现有组织中去。而这些已经预定义好的框架，不一定可以无缝嵌入现有组织的制度中去。这中间就产生了一个差距（GAP），如果敏捷教练不擅长去填这个GAP，最终的结果也就是可想而知。
如果这三种角色的看法都保持上述的样子，你就可以想象在一个企业中，这将是怎样的一种灾难。领导出钱了、员工出力了、敏捷教练出方案了，但从一开始就没有对齐，最终各方都不满意，敏捷之旅草草收场。
敏捷的边界到底扩大到什么程度了？
这个话题可能有点敏感，但是我依然想说两句我的看法。仅代表个人观点，如果不服，就是你对。
随着DevOps 流行之后，大家发现原来敏捷的边界是可以扩大的（这里有一个前提，敏捷和DevOps 本质是一件事情，这点得到了DevOps 之父的亲口承认），然后各种各样的对敏捷“重新解释”就开始雨后春笋般出现，其中又以“业务敏捷”为最杰出代表。
在业务敏捷中，关注的重点以及从过去敏捷所说的增量、迭代、适应性转成了更加接近于精益思想中的端到端交付，而“敏捷”变成了其中的一个手段，或者说修饰词。而快速交付在此时已经成为了主角。为了达到这个目的，每个业务敏捷负责人或者培训师、教练，都会使出不同的方法来推进。有些人致力于拉通业务与研发的信息互通，有些人努力让业务接受“小步失错”的精益创业的思想，也有人将目光集中到通过工具、流程、度量来反向要求团队提速。这里真正体现出了“八仙过海、各显神通”的特点。
原来这是一件好事儿，但是！！很多人会质疑──这跟敏捷有什么关系？这原本就是属于流程改造的做法，怎么经过你们说了一下，就成了敏捷的想法了？其他部门的配合、管理学的知识就这么被抹杀了，这怎能不招人嫉恨？
从这里就可以看出来，敏捷这些年在非常努力的扩大自己的边界，让自己的手脚涉足到企业中的每个角落并促成企业变革。这本身不是坏事，但是将一切都归功于“敏捷”思想，这里就有点给自己加戏的意思，甚至有点“先有敏捷后有天“的意思。毕竟发展多年的管理学思想在其中依然存在重要的位置，而促进变革这件事情的难度，更是远甚于”基于敏捷思想所构建的做法“在变革中的作用。将功劳全部归到敏捷上，难免让人感觉有“德不配位”的嫌疑。
因此当敏捷的边界开始扩大时，其他学科的、其他部门的人也就跳了出来，对“敏捷站C位”这事儿提出了质疑，反手又将敏捷给打了一顿。
看起来，敏捷好像已经进入一种里外不是人的状态了。
怎么破？我们还是要回归敏捷自身
这里借用Agile For Non-Software Teams 的一张图，来说一下敏捷到底是什么，只有明白了它是什么，才能更好的解决我们当前遇到的问题。
这张图中最大的创举就是将目的（绿色部分）、敏捷理念（紫色部分）和战术（蓝色部分）结合在了一起，让敏捷不再是空洞的“价值驱动”，也不再是老生常谈的“敏捷是一种理念”，更不是“某种具体的做法与实践”，而是这三个部分的有机结合，通过理念将价值与做法进行对齐与链接。
首先，绿色部分，即Purpose（目的）明确被提出来并放到了非常高的层面。这点看起来非常自然而然的事情，但是又有多少人真的会从这个角度出发？又有多少人上来就告知团队你们要使用Scrum或者Kanban，你们要导入TDD、你们要使用XXX工具？究其原因，还是因为切入点错了。不以具体目的为最终目标的敏捷，跟”谈恋爱不结婚“其实没有啥区别。最终就会落入“为了敏捷而敏捷”。
所以这是第一点，请所有敏捷从业者记住，你们要实施敏捷没问题，但是要搞明白到底是要解决什么问题，达到怎样的目的？如果这个做不到，基本上你的敏捷之旅就失败了一大半。不要去为了炫技、赶时髦等理由去使用敏捷，而是必须找到一个实际的目标作为切入点，否则敏捷存在的根基会受到挑战。
下面我们来看看蓝色部分，也就是Tactics战术部分。在这部分中，我们有很多的内容是集中在过程、工具、角色、实践、工件、会议上。这些部分都比较具体，而且我相信在你看到这句话的时候，你头脑里面的3355已经跳了出来，甚至有些人已经将结对编程、TDD、重构、编码规范放在了自己的嘴边，准备一展身手。此时的我真的很想给你鼓掌，为你的知识渊博感到赞叹。但在这之前，请你回答我一个问题──你准备把哪些实践、流程等用起来，你如何保证你用的东西，就是真正该用的东西呢？
有些人可能已经愣住了。这玩意还要保证？不是应该上去就将常见的框架用起来就行了？当然不是。我相信各位肯定经历过团队不愿意开站会、不愿意使用TDD、不愿意结对编程的情况，对吧？那么当遇到这个情况的时候，你会怎么思考这件事情呢？是真的团队不行？还是因为某些实践在当前不适用？
如果你曾经思考过，那么你一定就能明白敏捷理念在这当中所起的作用，也就是上图中紫色背景的部分，即理念Mindset。在这里，作者抛出了三个概念：
- Beliefs，信仰。这里本质是一种假设，也就是你没有验证，但是你相信为真的事情。我们经常的”团队具有主观能动性“、”大家都想表现出自己的能力“、”大家都希望可以在工作中践行自己的工作方法“等都属于此类；
- Values，价值观。价值观是你绝对不能放弃的和妥协的。领导常说的“质量是底限”、“双十一之前功能必须开发完成”等都属于此类；
- Principles，原则。这里的原则不等于敏捷软件开发宣言中的十二项宣言，而是一种帮助你做决定、决策和行动的指导意见。它是信仰与价值观综合之后的产物，当你徘徊在十字路口的时候，它就是你的指南针。比如当你相信“团队成员都为自己的交付物感到骄傲”且“双十一之前所有需求必须上线”时，结合现状（工作进度不及预期），你会选择何种做法解决当前遇到的问题？
此时你就会看到，理念Mindset 就很好的将目标Purpose和战术Tactics很好的结合在了一起。而通常我们都知道目标的角度会比较高，更大概率是领导层、业务层面关注的点；而战术的角度会比较低，通常会是执行层也就是团队所关注的点。而敏捷在这里就起到了承上启下的作用，在满足目标层的要求同时，也通过战术层展现了出来。这就是敏捷在组织实际的工作中，所应处的位置。如果做不到这点，组织就会陷入一种对敏捷“认知失调”的状态，从而对敏捷的产生不切实际的预期，最终导致敏捷在组织中的失败。
所以，读懂这张图，对拥有正确的敏捷认知具有极大的帮助，甚至可以成为正确应用敏捷的切入点。
敏捷会不会死
在回答这个问题之前，我们还是先回顾敏捷的理念层面。敏捷将自己说成Mindset，即理念这种做法，我认为是一种很投机取巧的办法，因为敏捷本身没有能力将所有的场景包含其中后，给出所谓的最佳实践（当然，这个词在敏捷中无法存在，否则持续改进就变成了空谈）或者良好实践（PMI 的常用说法），因此敏捷干脆不再从这个角度入手，而是告诉你这是理念，一切的做的内容都要靠你自己去领悟。
这原本是一件好事儿，它将决定权还给了执行敏捷的人（不论是叫他SM、敏捷教练还是项目经理都可以）。然而，麻烦来源于各种敏捷框架的出现，给了大家一个拆包即用的东西，并且在前期（注意，只是前期）会带来很好的效果。然后一些人开始宣称我们敏捷成功了、我们用Scrum 成功了、我们用XP成功了、我们用SAFe成功了。这些名词的风头改过了敏捷本身，时间久了，就会让后来者认为他们所说的这些框架就是敏捷本身，如果你不用这些框架，你就是不敏捷。久而久之，敏捷理念被遗忘，大家只有在装X或者考试的时候，才会认真的去将敏捷当做一种理念，才回去认真的学习宣言和它所自带的原则。在工作中，无脑的将各种框架奉为上宾、关注团队的技术动作而忽略团队所处环境，当环境稍有变化，自然就适应不能，最终导致整个组织回退，敏捷再次失败。
因此我的观点非常明确──“敏捷”这个词是否能够活下去并不重要，重要的是敏捷理念的存续。当你将“目的”放在第一步的时候，并根据实际情况（理念Mindset）得出你的原则（Principles），并且使用原则对你当前的工具箱进行筛选，选出符合你当前最实用的流程、工件、角色等内容，在现有的环境中解决问题，这才是我们该做的事情，而并非争论它到底是不是敏捷。这可能是当前最不重要的词，无论它是叫“敏捷”还是叫“企业变革”又有什么关系？如果你一开始就将敏捷与某些框架结合在一起，那么其实敏捷在一开始就已经死了，因为它忽视了敏捷的根本目的、忽视了情景，这种情况下敏捷是不可能成功的，充其量就是“导入XX框架，规范了我们的行为”。此时你所看到的好处，并非敏捷本身，而是规范给我们所带来的，真正敏捷骨子里那些东西，一点都没有被看到。这种敏捷不失败、这种敏捷不是“已死”，那么还能是什么？
那我们还要不要学习框架、工具
要的。
在上图的第三层，也就是蓝色背景部分都是我们日常学习过程中是最大的要点，如果缺乏这部分的知识，你连选用什么流程、工具、角色都不知道，何谈能够灵活应用？只有当你累积了足够多的工具到你的敏捷工具箱中之后，你才能结合你你要达成的目的，分析你所处的情景，进而正确的找到你所需要的工具。
留个尾巴
其实还有一些内容并没有在这里说，比如工程实践是否必须、敏捷教练的角色到底是什么、服务型领导到底意味着什么等等，这些都到了非常具体的层面，也就是上图的蓝色部分。后面有时间再慢慢说吧。
