原文地址：
https://medium.com/columbus-e...
翻译君：CODING 敏杰小王子
“敏捷已死”，人们一直这么说，但紧接着他们又说：“我们只是开个玩笑”。其实这些人真正想表达的是你实践敏捷的方式已经过时并且愚不可及，而“真正的”敏捷未死，只不过大家实践敏捷的方式是错误的。因此，我认为理论上的敏捷是“真正的”敏捷。
最近我在网上也搜集到了很多古老的辩解：“但是有问题的是 Water-Scrum-Fall，而不是宣言当中的敏捷。” 紧接着 Bob Marshall 直言不讳道：“这位同学请你闭嘴吧，敏捷宣言就是老调重弹。”他还说了一些我不得不同意的观点，我思考了一下，下面就是我思考的结论。
阅读参考：
Water-Scrum-fall
https://www.infoq.cn/article/...
这里有一个对你的测验：敏捷宣言的第一句是什么？不许偷看。不记得了的话，我来告诉你：“我们正在探索开发软件更好的方式……”就此打住，注意到了吗，它说的是“开发软件”，并没有说到“倾斜你的组织”、“偿还转型债务”、“用这种命令和控制废话切断它”、“专注于结果并且在发现领域的工作”、“修复你的中世纪预算系统”，或任何其它人们试图掩盖的更多有价值的东西。但问题是，当人们说敏捷属于整个组织时，它就是修正主义的历史，这是不诚实的。
在宣言开始的部分是：“我们正在发现……”，它并没有说：“我们已从非常……获得……”。你不觉得我们从 2001 年开始意识到，大多数大型组织仍然停留在 1987 年。与流行的看法相反，下面的照片实际上并非来自 Snowbird 签署的宣言，我们是不是可以终于停止伪装的敏捷了呢？
宣言有它的目标，但它不会让你直接到达你要去的地方，所以我们需要学习。我们的知识是有保质期的，有时不像我们预想的那么长。我们身边总有些同事（通常是领导者）声称他们“没有时间学习”，而你知道他们只是对自己的认知过于自信。所以找一个丰富的书单，关注一些优质的博客，这是一个开始：如果你还没有阅读《Sense ＆ Respond》、《精益企业》、《A Seat at the Table》以及《Everyone Is a Change Agent》，我建议你花时间学一学，也建议你的领导也读一读。
译者注：
《Sense & Respond》探讨了企业必须如何发展意识和应对战略，以利用这个网络化时代的机遇。
《A Seat at the Table》诠释了传统的 CIO 角色是如何与软件开发的敏捷方法相冲突的，探讨了在敏捷环境中 IT 领导人应该是什么样的。
《Everyone Is a Change Agent》介绍了在组织中如何进行变更以及推动变动。
开始阅读 John Cutler，Melissa Perri，Bob Marshall，Allen Holub，Laura Klein，Erika Hall，Neil Killick 以及由他们延伸开来的帖子。他们都相互认同（或与我认同）吗？不 —— 但他们很聪明，他们也会让你更聪明。阅读，并且鼓励他人。Fast Company 表示，CEO 平均每年阅读 60 本书，你的领导读过几本书？并且他们平时都在读些什么呢？（HBR 的文章，Gartner 的报道，以及 Maeve Binchy 的小说都不算数）让我们面对现实吧，如果你的领导者还在试图通过第六感意会 Scrum，那么你们的组织就会卡在 80 年代和 90 年代无法动弹。
所以让我们达成共识，敏捷并不是研发管理的银弹，团队要做到持续学习。需要说明的是：敏捷一直关注的都是本地优化，为系统带来的收益其实微乎其微。敏捷其实意味着把软件研发团队放到了显微镜下，仅从很多细节的角度去解读研发团队，很多时候这样是不公平的，而且这其实一点都不能提升组织的敏捷程度。有趣的是，Ken Schwaber 想过撤销瀑布流式开发方式带来的伤害，然而敏捷从来没有为企业或者组织提供一个整体可行的替代方案。这其中也有实践和理论存在差距的原因，在实践中我们需要务实，这也导致敏捷在实践中经常名存实亡，这似乎也是整个敏捷运动本身存在的问题。无论如何，还有更重要的事情可以学习，包括但不限于 DevOps、Lean UX、精益创业、Design Thinking 等等。
你可能会好奇为什么 Lean UX 会在这个列表上，因为 Lean UX 注重最后的结果。如果你不知道想要创建什么样的改变，那么你将不知道该如何转变。如果没有明确的改变信号，那么你首先就不能真正“敏捷”，毕竟改变才是敏捷最关注的。也有人说敏捷主要需要即时观察和调整，但是我看到大部分敏捷团队都仅仅停留在机械地往已有工作中增加一些水泥，在 Jira 和 Rally 里倒腾，就像他们之前在其他地方建造砖墙一样。
敏捷本质上倾向于掩盖核心问题，这是一种系统性的，双向都缺乏垂直信任。事情在敏捷教练离开后会变得更糟糕，管理层和研发团队由于屁股决定脑袋，双方的沟通变成了鸡同鸭讲。研发团队会觉得管理层根本什么都不懂，然而管理层们却在关注任务的精细程度、deadlines 和效率，忽略了很多时候 deadline 和工时预估都是拍脑门定的，其实毫无用处。
那你猜猜哪边会赢呢？两个阵营有两个截然不同的视角，但有一个阵营得接受另一个阵营的绩效评估。如果说研发团队就像是在盲人摸象，并讨论大象到底是什么样的，那管理层就像是盲象踩人，并一致认为人就是扁的。唯一的出路就是认识到管理体系其实也是团队的一部分，别老搞那些本地的细节优化，而是要意识到信任才是第一要素。所以不要仅仅把研发团队放到显微镜下面看，而其他人都躲在小黑屋里不知道在做什么。
再者，在尝试敏捷的时候，必须停止像对待工厂工人一样对待研发团队。我们不是在制造塑料餐具，我们是在创建新的软件，我们需要停止像开一个披萨店一样的管理方式，那种一直使用同一种配方来做披萨的方式是不适用的，我们是在设计新的配方，是具有创新性的工作，而不仅仅是按部就班那么简单。忽视这份工作的创造性将会导致大量浪费：没人用的功能和无法带来结果的代码。这也暴露了敏捷的另一个深层缺陷，它假设可以像对待小白鼠一样对待用户：“hey，你现在就用这个没什么用的功能吧，先用着我们后面会改进的“ ，然后用户就头也不回地走了，未来的产品改进就成了无意义的浪费。
有人会说敏捷也可以作为创造性工作的工作方式，但是就像我刚刚说的，理论和实践是有鸿沟的。如果你真的想为团队做一些创造性的工作，想想你跟敏捷团队的经历，你是会被团队认可并帮助团队更加精进，还是经常被领导询问 “能否展示你做这个事情的意义”？就像 Alan Cooper 说的那样，当你经常被要求证明自己的价值时，你要清楚他们是在告诉你，当下的环境是不认可你的价值的。请注意，管理者要求个人贡献者证明自己的价值 —— 但不会问他的代码中有多少实际上会产生的正向结果。换句话说，他们仍然专注于人而不是工作本身，他们可能仍然专注于成本，而不是实际产出的价值。
所以如果你在一个敏捷团队中想做一些创造性的工作，下次被问到如何展示你的价值的时候，试着反问他如下问题：你知道项目延迟的成本是多少么？你使用哪些维度来测算？这个项目想实现哪些实质性的成果？项目中到底哪些资源和代码转化成了实际的成果？如果他们回答不清，可以继续问如果有更快、更便宜的方式来学习构建，而不是机械性的输出代码，你们是否有兴趣学习？你们现在的流水线效率如何？一天要花多少时间参加各种会议？如果有思维训练和团建活动能在更短的时间内推动更好的决策，你们是否会感兴趣？因为我不会只告诉你我有多重要 —— 我会教你在每件事上创造更多的价值。
这要求的是另外一种思维，形式上更加关注战略层面。就像 Austion Govella 说的那样，敏捷和瀑布流的方式都过于关注构建，而不关注结果评估。如果你所在的组织无法正确的评估产出，你可能需要挪挪窝了。如果他们只是每天埋头苦干，成批的输出代码，仅仅关注成本，那他们仅仅是一个输出功能的工厂而已，假装只是在创造塑料餐具而不是生产，他们也无法理解你的哪些行为能为团队带来更多增益。因为真正的价值是由研发工作中创造的选择来决定的，而这些选择则是由日常工作的持续学习和探索产生的。你能选择的东西越多则工作弹性越大，相应就会有更多种方法来创造价值。这个项目到底是想达到什么目标？有没有寻找 3 到 5 种新的方法来实现这个目标？这些都需要通过更长期的规划来推动更好的决策。当只有一种选择时只能埋头苦干，两种选择是两难，但第三种选择的出现代表着可以正视利弊，团队才会真正前进。
而且这也是有理论支持的，你是否听过必要多样性理论（Law of Requisite Variety）：在一个系统中，拥有最多选择的那个组件将能决定整个系统的走向。领导者试图将系统控制在最顶层，同时敏捷团队却试图将价值推向更靠近实际用户和客户，摆脱这种内战的方法是要让人们在各个层面都能拥有选择。出路并不是寻求敏捷 VS 瀑布流的结果，而是一种明智的由上到下的瀑布流性战略方针，和由下到上的经验驱动战术相辅相成的管理方式。
所以人们应该在意结果，而不仅仅是产出量；更注重战略上的布局而不是一个个规划出来的里程碑。研发团队应该成为真正被信任的产品团队而不仅仅是被当作一个项目团队来看待。给予研发团队以下自主性，让他们敢于去探索达成目标的最佳途径。
最后总结一下，虽然吐槽了这么多，是否就意味着敏捷已经开始没落了呢？其实不然，这仅仅是我对现在各个组织或企业在实践敏捷时出现的一些问题的观察，再说如果没有敏捷运动，那我今天在这里所说的大部分结论也都失去了意义。所以我也不希望敏捷就这么没落，我仅仅是希望作为敏捷的实践者，我们能更敢于直面其中的问题。