为什么这么多程序员讨厌敏捷?

与程序员交谈时,经常会注意到一定的不满或看到他们的眼神就提到敏捷。 您是否想过为什么?
甚至在敏捷开发思想或与敏捷相关的实践和方法方面,其自动否定的原因是什么? 它们命名为导致方法失败的事物是否可能根本不是敏捷实践,而是被误解和滥用的敏捷价值观?

团队可能感觉像是Scrum Master或Agile Coach的典当。
很容易看到这种感觉是如何产生的。 管理层倾向于聘请独立的敏捷顾问或聘请Scrum Master来监督团队中敏捷方法的实施和执行。
事实是,这是一个外部人,在团队和“ 敏捷因素 ”之间造成了障碍,从而导致我们和他们分离。
他们可能还会感到受微观管理并且受到过多的控制,尤其是如果每次日常站立会议都以谈论最近所做的事情结束而结束时,这绝对不是日常站立会议的预定目的。

时间压力过大也会造成伤害-团队认为他们需要定期交付项目,而不是在准备就绪并进行测试时交付-这种面向时间的方法可能会导致质量下降。
经常有报道说,这些sprint太短了,甚至没有时间在编写代码之前甚至没有收集完整的文档,更不用说在完成代码后仔细查看了。 因此,如果在高时间压力下工作还不够,那么开发人员还需要应对知道这一点,他们只有一招可以解决问题。

您的程序员很可能讨厌敏捷,只是因为您使他们以错误的方式这样做。 但是也有可能您做对了,是您的团队普遍不喜欢这个想法。 在这种情况下-剩下要做的就是等待它在团队中成长-或替换团队。

使用敏捷的人们正在决定要做什么,在产品的外观和功能上拥有发言权,并从整体上获得对项目的大量控制。 这可能值得您向员工说明。
请记住,…程序员本身已将敏捷视为编程方法。
–不是项目经理。
难道就是,设计的敏捷与最近使用的敏捷之间的主要区别在于,它已经更多地成为了项目管理领域,而不是程序员的领域? 如果是这样,唯一的解决方案可能是将其从PM中收回!

在理解为什么有些人不热衷于敏捷的原因的同时,有一种看待敏捷的方法使大多数争论都失败了:这是时代标志
事实是,无论您选择哪种方法,在当今时代,仍然都需要解决不断变化的客户需求,从而满足利益相关者对迭代结果进行控制的需求。
换句话说,不管您想称呼它如何,您都将在进行某种形式的敏捷开发。

还有一件事:任何故事的不愉快的一面自然都会大声尖叫。 您将无法想象有多少开发人员发现敏捷是一种可行的方法,并且看不到其中有什么可怒的。 但总是有很多话要说,这是不愉快的吗?
因此:尝试一下,对其进行自定义(是的,《敏捷宣言》只提到了一些关键准则,没有一个提到Scrum,冲刺或日常站立法), 然后才确定您在栅栏的哪一边。 谢谢!

最初是为 看板工具 编写的 博客