开发者为什么讨厌敏捷？

前几天有人问我：“开发者为什么讨厌敏捷？” 在回答问题时，我认为值得写下来。 我可以想到三个原因，但是在我们找到它们之前……

首先，我认为并不是所有的“开发者都讨厌敏捷”。 或者更确切地说，我认为他们中的绝大多数人都不讨厌它-讨厌这个词很强烈。 当然可以，但是可以肯定吗？ 一揽子“所有开发者都讨厌”？ 没有。

我确实认为，敏捷化是一种时尚，而且很少有人能比敏捷社区本身做得更好。 不幸的是，就像许多时尚一样，它一开始就流行起来。 一旦开发人员A说“我讨厌敏捷”，开发人员B也会说很酷，开发人员C看到A和B都这样做了。

具有讽刺意味的是，敏捷是开发人员的产物。 最初，是像我这样的开发人员，他们看到经典的工作方式（写下客户想要的东西，进行设计，计划，编写代码等）并不能很好地发挥作用，但是注意到实际上大多数工作的方式（快速，代码foo…O foo不太正确，快速更改它）实际上更好。

我受到Jim McCathy的著作《软件开发的动力学》的启发。 Jim是一名开发人员，尽管已经开始管理其他开发人员。 正是那本书使我认为“替代方式是有效的”。

全世界的开发人员都在使用重型Craft.io修复Y2K时也发生了类似的见解。 这些编码器中的一些后来变得颇有名气：例如Kent Beck，Ward Cunningham和Martin Fowler。

而在第一号谎言中，为什么“开发人员讨厌敏捷”。

盗窃和强加。

早期，敏捷就是开发人员，尤其是XP。 就在10年前，编码人员会说：“我很乐意让我的（项目）经理来工作敏捷。 因此，我们开始着手使敏捷管理者变得友好，我们扩展了业务理由来说明为什么敏捷很出色，而管理者则理解了这一点。 现在，您听到开发人员说诸如“我的经理希望我敏捷地工作，但他不理解”或“我的经理希望我敏捷地工作但无济于事”之类的话。

最初，敏捷是自下而上的运动。 现在是自上而下的运动，变化是施加在人们身上，而不是要改变的人们。

那是错的。

更糟的是，许多实施变更的人经常无法理解他们实施的变更，或者不质疑自己的想法。 管理思想也需要改变-从软件开发入手。

原因1：敏捷现在是强制性的更改。

以我的经验，开发人员希望工作敏捷，因为真正的敏捷可以使他们（没有要求 ）完成高质量的工作。 如果组织不关注质量（这意味着他们的技术实践），那就是我们所称的技术卓越，那么敏捷将无法实现承诺的一半收益。 这意味着开发人员所做的工作引以为傲。

即“ XP的技术实践”，特别是：简单的设计，不懈的重构，测试驱动的开发（加上行为驱动的开发），结对编程以及诸如面对面的对话之类的东西，“故事是对话的占位符”。

我会特别指责Scrum和后来的看板，因为他们没有强制执行这些做法，这是我对Xanpan所做的 。 使敏捷被管理所接受的部分是消除了“极端”和“编程”这两个词 ，而淡化了高质量可能带来的差异。

没有这些实践，团队将更难以尽早交付产品，质量下降。 随着质量下降，在短时间内交付任何东西变得更加困难。 因此，对编码人员的需求更多，压力和紧张程度增加，这很不好玩。

原因2：缺乏技术质量的敏捷性会使开发人员的生活更糟。

我记得在剑桥与一些编码员会面时，几乎他们告诉我的第一件事是：“我们讨厌敏捷，我们的经理参加了Scrum课程，并坚持要这样做几个月。” 我很快发现他们没有做任何技术实践，因此他们承担了越来越多的技术责任 ，使自己的生活更加艰难。 一旦我解释说他们缺少技术实践，他们的态度就会改变。

现在到最后一个原因，也许是最大的原因……

敏捷工具集旨在帮助团队进行自我组织，旨在使问题清晰可见，以便对其进行解决和修复。 在正确态度的人的手中，这真是太好了。

团队不需要经理（尽管可能仍然有用）。

团队可以看到问题。

团队可以解决问题。

但是……态度错误的人所使用的工具完全相同，这是微观管理者的梦想。

哪些微管理人员不想让每个人每天早上9:00都提供状态报告？

谁不想看到所有工作分解成可以让NAMED个人负责的工作？

而且为什么他们不希望每当估算很高时就大张旗鼓地发出一个非常清晰的“那是不可接受的”信息呢？

可见性成为责备的工具。

我曾经帮助一家航空公司的团队建立了看板，而不是使用它来查看瓶颈，问题和寻找机会来改善有关的经理人员，而是使用它来指责，指责并证明什么都没有发生，因为别人没有做好他们的工作。

原因3：如果使用不当，相同的敏捷工具是非常有效的微管理工具。

翻译自: https://www.javacodegeeks.com/2017/05/devs-hate-agile.html