对于选择使用敏捷开发的程序员而言，Scrum应该是其熟知的工具之一。Scrum是一个用于开发和维护复杂产品的框架，是一个增量的、迭代的开发过程。其凭借实效的功能特性吸引了不少开发者的注意，但就在此时，本文作者DennisWeyland提出了完全不同的见解，其认为Scrum不仅不敏捷，另而且还尤为脆弱。
作者
DennisWeyland
译者
谭开朗，责编
屠敏
以下为译文：
本文是论述Scrum两个方面的内容。一方面是关于Scrum的不敏捷性，另一方面是关于Scrum的脆弱性。
在展开论述之前，我先声明一下：本文所展开的均属于我个人观点，并不代表我任一雇主公司的立场。
Scrum的不敏捷性
我猜大家对这个标题的一贯反应会是“这怎么可能，Scrum不敏捷吗？Scrum不是敏捷软件开发的首要流程吗？”简而言之，Scrum自称是一个敏捷开发的过程，但可悲的现实是，Scrum离敏捷开发还很远。让我来说明原因。
我们先快速了解一下敏捷宣言。敏捷宣言强调“个体和交互比过程和工具更加有效”。我们再快速了解一下敏捷这个词的含义。牛津词典解释道，敏捷的意思是“能够快速、轻松地行动”。选择敏捷这个术语来代表敏捷宣言中的高级思想并不是一个巧合。事实上，敏捷背后的一个主要观点是，在许多软件项目中，快速而轻便地实现变更是极其困难的。对于一个全新的项目来说，情况并非如此，但随着时间的推移，许多项目进入了一种根本不可能实现可持续发展的境地。为了防止这种情况(和其他问题)的发生，敏捷宣言和敏捷宣言背后的原则提出了几条高级指导方针。这些指导方针不是特地定义好的流程或工具，它们支持不同的实现方式。我怀疑这两个属性(高级的且支持不同的实现方式)都是刻意为之的。它的整体目标不是提供一个有效的武器，而是帮助同行避免软件开发中的许多陷阱，而这些陷阱都是敏捷宣言的作者所亲身经历过的。
现在，我们再来看看Scrum指南(由敏捷宣言的两位作者撰写)。与敏捷宣言和敏捷原则相比，这Scrum指南似乎相当冗长。令人惊讶的是，整个指南一次也没有提到敏捷。我不确定是否长久以来都是这种情况，但是如果Scrum指南的作者没有说Scrum是敏捷的，那么我们已经完成了这篇博客文章的 部分。先忽略这种情况，我们继续探究。Scrum指南是指包含“角色、事件、工件以及将它们绑定起来的规则”的一个框架。换句话说，这是一个明确且十分具体的过程。这听起来一点都不敏捷(别忘了:“个体和交互比过程和工具更加有效”)。这相当的讽刺和明显。这就是应该废弃Scrum的原因。但它并没有被废弃，而是让世界各地越来越多的软件开发人员感到失望。当Scrum项目失败时，并不是因为Scrum的潜在缺陷，而是因为Scrum没有得到正确的展现。这自然而然地过渡到本文的第二部分内容。
Scrum的脆弱性
这部分内容很短。我觉得文字游戏(Scrum是敏捷的/脆弱的)很有趣，除此之外，它完美诠释了Scrum真正困扰我的一件事：每当Scrum项目失败时，都是因为Scrum没有得到正确的展现。我们可以查阅到大量的相关项目。如果大多智能软件开发人员都不能正确地实现Scrum，这意味着什么？意味着整个框架是脆弱的。这是反对使用Scrum的另一个主要论点。如果框架这么难用，那么它有什么使用意义呢？
可能在费用高昂的咨询和指导下，或有培训及证书，Scrum实际上有它的可取之处。但是，对于开发软件的公司和辛勤工作的软件开发人员，以及那些在Scrum生态系统中或围绕Scrum生态系统提供服务的公司来说，它的价值还有待商榷。
个人的观点
，我想谈谈我个人对软件开发、敏捷开发和Scrum的看法。在我看来，高质量软件开发的一个非常重要的部分是保持简单的优先级任务队列。其权重是衡量该项目为客户/开发人员带来的价值和完成该项目的预估工作量。对于一些开发人员来说，这很常规思路。对于不属于这种情况的团队和公司，Scrum提供了一个相当昂贵又低效的优先队列实现方式。
坦诚说来，软件开发是一项非常困难和复杂的工作。面对诸多失败的项目，我们真的还会感到惊讶吗？这个领域还很年轻，我们需要学习很多东西。这一点至关重要：不管是失败还是成功的项目，我们都要从中吸取经验教训。整体说来，我们都失败了。我们没有使用错误的流程或以曲解正确的流程，我们只是陷入了一场激烈的竞争，我们无法停下来去看看周围发生的一切，无法从中学习，甚至无法看到历史。我们有责任从轻而易举获得的众多资源中提取知识、经验和智慧:关于软件开发的许多书籍、文章、视频以及敏捷宣言。
原文：