UML已死？其实是敏捷惹的祸？
从Google趋势来看UML没有增长，是否意味着已经死亡，UML（以及RUP，AOSD和Essence）的创建者之一Ivar Jacobson回答了这个问题：
(认为UML已死)这不完全正确，毫无疑问，这是早期的敏捷方法抛弃了架构，导致了对UML兴趣大幅下降。
而现代规模敏捷方法包括作为目标的架构路线图，这是多个团队的努力目标。团队学习的东西越来越多。而改变一个sprint接着一个sprint地改变，架构只能以某种方式表达了，这样，轻量的UML被采用，这样的UML被由多种工具支持。
我同意20年前使用UML方式没有这么聪明，太多无用的图表，在软件开发领域任何时尚的事情都会发生，但是，如果以更聪明方式使用UML，真的有助于团队了解他们的开发方向。
关于UML死亡的谣言都是假的。
其他人的观点收集：
UML是一种记录软件的方式。不是唯一或最好的。它在过去非常有用，TODAY用于教授OOP和DB。您不需要正式的大学UML。只有上下文理解的基本知识。
确实，UML被那些没有编程的“老板”所喜爱，但它并不一定是坏事。PD。当UML的创建者讨论你时，它会让你思考你的观点有多远。
敏捷抛弃架构和UML完全是胡说八道。我从1998年开始使用eXtreme编程，因为@ martinfowler的影响而阅读UML Distilled 。我们在白板上进行了大量的架构和设计讨论，当然我们使用的是UML。
我确实认为，目前缺乏架构思维，前期设计，文档，UML，建模等，直接归因于敏捷宣言的广泛误解和误用。
设计和架构讨论绝不意味着使用UML。房间里的每个人都能理解的任何视觉方法都很好。
UML在很大程度上由于与慢速方法的关联而被废弃。但它在项目中非常有用。
我完全赞同Ivar。它不是关于工具或标准，而是关于我们可以给予它们的用途。UML仍然是那些了解其使用，优点和缺点并知道如何使用它们进行有效沟通的人手中的有用替代品。
UML不会死，文档对于项目很重要，另一件事是开发人员在没有任何规划，分析和设计的情况下编写代码，您可以在其中找到项目的缺陷或优势
UML可以说是我们每天使用的原始语言，甚至是潜意识里的。
如果没有UML，许多人可能更难理解软件架构的基本概念。UML并非无用。但是，你需要整容。敏捷方法在开发的某些部分需要更坚实的基础。UML必须作为支持
框架仍然使用POO中的许多设计和架构模式，用UML解释。我认为这种语言存在的部分原因归功于上述内容。用UML描述设计模式的部分对我来说似乎很重要。
在考虑架构时，我会考虑业务流程。Uml和bpmn或archimate模型非常有用。
这句话对我来说没有意义，因为UML是一种语言，而不是一种方法。它可以很好地用于临时讨论。XP中的任何内容都不会阻止您保留和维护生成的图表，如果它们对将来的参考有用的话。
我1996年才从大学毕业。我当然也看到了许多重要的前期设计。我要说的是，许多团队非常明确地告诉我他们不做*任何*前期设计......“因为敏捷”。
@ martinfowler : 设计死了吗？描述了敏捷和前期规划之间对设计（架构）的不同态度，我认为它仍然具有相关性。
我当时加入的团队既没有听说过XP，也没有听说过UML或者前期设计。混乱的大泥球是常态。无论哪种方式，它都不是放弃架构的敏捷方法，而是懒惰/未受过教育的开发人员。
一些团队明确地告诉我他们做*没有*正面设计。最近一个团队说，“当我们得到要求时，我们才开始编码，因为我们正在关注极限编程”。
架构和设计被视为不必要的开销。管理层认为，开发人员可以轻松替补架构师并跳入直接编码是有效的。
“缺乏前期设计”是XP中的故意。如果做得恰当，TDD / BDD会随着时间的推移而改进设计。同样，缺乏外部技术文档，UML，建模等，在XP中是有意的，而且最敏捷。它不是良好的设计或架构所必需的。
敏捷宣言说，“在综合文档上运行软件”和“也就是说，虽然基于文档的项目有价值，但我们更重视运行的项目。”
敏捷宣言说，“综合文档”是有价值的。不是“你不需要写任何文档”或“你永远不应该写任何外部技术文档。” （并且它表示在编写和交付工作软件方面有*更多*。）
UML通常会在软件团队中触发VOM。SCRUM也是如此。