敏捷没有死，也不可能被杀死
敏捷之死的传言被夸大了
thehosk.medium.com/?source=pos…
图片来自Pexels的Rachel Claire
没有什么神奇的公式或方法可以保证项目的成功
尽管有很多文章宣称敏捷已经死亡，但它几乎没有受到任何打击，关于敏捷死亡的传言被大大夸大了。
你不可能杀死一个项目方法论，敏捷项目永远存在。敏捷就像一个宗教，宗教不会死亡，它们会变得不那么流行，并逐渐消失。
你不能扼杀别人的信念，永远会有敏捷的信徒。如果你把敏捷打倒，它将变得比你想象的更强大。
一个新的项目交付来到了这里
敏捷作为一种新的方法开始，交付了一些成功的项目，得到了一些宣传。它是镇上新的项目方法，有一千多万篇文章和视频涌现出来，说敏捷是多么伟大。
互联网同意停止写关于敏捷的博文，如果开发人员同意在一些项目中使用它，开发人员就会接受这个协议，而不是再读一篇关于仆人式领导的博文或计算出一个冲刺的最佳周数。
敏捷变成了一种完全的崇拜，有了一种全新的语言，并给参赛者起了一些很酷的名字，比如Scrum master（宇宙的）、产品所有者和开发人员是代码园艺家。
需求是用户的故事，每个人都被告知要冲刺，每个人都必须在会议上站起来。敏捷宣言正确地指出，坐着开会是项目的一个大问题。
为了解决问题，Scrum团队在每个冲刺结束时都会召开回顾性会议，抱怨某个东西不工作，但却无法说服任何人去改变什么。
根据国际法，所有新项目都必须是敏捷的。我有一个很酷的头衔 "Scrum master"，但我发现我并不是一个主人，我是团队的仆人。Scrum主管没有任何权力，必须安排所有的敏捷仪式，如果团队没有像我们预测的那样交付很多故事点，就会受到指责。
尽管Scrum master的角色无权无势，但我很享受敏捷项目的透明度和诚实性。敏捷游戏的规则对每个人都很清楚。如果你在冲刺阶段增加了什么，就拿出同等价值的东西。
仪表盘和进度对每个人都是可见的，在敏捷项目中没有隐藏。
敏捷的泡沫
在敏捷爆炸中获利最多的是那些投资于便签公司的人，销售额同比增长了50%。
敏捷的高峰期到来了，满满的敏捷泡沫高高飘起，飞向天空。在泡沫的高度，思考被敏捷的故事点和站立所取代。思考停止的标志是客户坚持要做敏捷项目，而不管他们是否有人员、知识或项目是否适合敏捷。
敏捷最大的争议是故事点，不管别人怎么说，这些故事点实际上是天数，例如，1个故事点=1天。在世界各地的项目中，开发人员试图解释故事点不是天数，浪费了多年的时间。0.03%的客户相信这是真的。
摇摆不定的开始
敏捷项目适合一些项目，但每个项目都是敏捷的，甚至是那些不适合敏捷的项目。
客户坚持要做敏捷项目，但没有考虑到它所需要的时间、精力和快速决策的因素。敏捷项目的理想状态是需要解决方案以较小的篇幅交付，以实现快速上线。并非所有的解决方案都能很好地发挥作用，许多解决方案在上线前需要大量的核心功能，这是不敏捷的。
尽管敏捷项目被误用，我相信它们比瀑布项目更有效。敏捷项目能够快速创建功能，并从用户那里获得快速反馈。
敏捷泡沫破裂和变异
当世界末日来临的时候，仍然会有敏捷项目
大家都很震惊，没有什么神奇的公式可以让每个项目按时按预算交付。项目方法论是一种工具。它可以提供帮助，但关键是交付项目的人员和领导层的质量会产生差异。敏捷或任何其他项目方法论都不能保证项目的成功。
敏捷很少以最纯粹的形式实施，因为没有客户对没有项目的最后期限感到满意。敏捷有要求，需要多长时间就需要多长时间。一个未知的最后期限和预算的想法使许多听到这个疯狂想法的人感到恐慌。
大多数项目采取了一点瀑布式（前期需求收集），一点标准的项目规划，有一个高水平的时间表和预算。开发交付是敏捷的。
- 阶段
- 故事点
- 看板
- 冲刺回顾会
- 产品所有者和Scrum主管
- 冲刺演示
这些变化并没有直接投入生产，因为项目通常太大，无法将一小块孤独的功能直接投入生产。
敏捷并没有解决软件项目的主要问题，很难有多个团队从事相同或相关功能的工作。多个团队的复杂性需要高标准、出色的沟通和强有力的领导，并不是所有的开发者或IT专业人士都具备这些技能。
敏捷项目的一个关键要求是要有知识渊博的中小企业，被授权来决定。你需要把关键的中小企业从他们的工作中解放出来，加入到项目团队中，而且这些人需要与软件开发团队紧密合作。
这需要比许多公司意识到的更大的承诺和信任。敏捷项目的工作速度比客户员工习惯的工作速度要快，而且责任更大，需要快速做出决定。
总结
敏捷永远不会消亡，它的流行程度会降低，但总会有Scrum大师在地球上行走，交付项目。在软件开发中没有什么东西会消失，瀑布法仍然在使用，COBOL仍然在编写。
新的语言、工具、项目方法论会变得更加流行，并达到泡沫阶段，但最终人们会意识到没有什么神奇的公式或工具可以按时创建项目。
人是成功或失败的原因。项目方法论、技术和编程语言是用于创建软件的工具。
现在没有，将来也不会有交付项目的神奇公式。
总会有很多不同的项目方法论，人们会说新的方法论很好，旧的方法论已经死了。
