正如标题所示，这篇文章是关于 Scrum 的两个不同方面。第一部分涉及 Scrum 不敏捷，第二部分涉及 Scrum 脆弱。
在详细介绍之前，简短的免责声明：我在这篇文章（以及一般博客中）中提出的所有内容都是我个人观点，并不代表我现任雇主，我的前雇主和任何未来雇主的观点。
Scrum 是不敏捷的
我猜人们对这个标题的典型反应会是“这怎么可能？ Scrum 不是敏捷的？Scrum 不是第一个敏捷软件开发过程吗？” 简而言之，Scrum 声称是一个敏捷的过程，但令人遗憾的是，Scrum 离敏捷还很远。我会告诉你原因。
我们快速浏览敏捷宣言。它说它重视“个人和交互而不是过程和工具”。让我们快速了解一下敏捷这个词的含义。根据牛津词典，敏捷的意思是“能够快速、轻松地行动”。选择敏捷这个术语来代表敏捷宣言中的高级思想并不是一个巧合。事实上，敏捷背后的一个主要观点是，在许多软件项目中，快速而简单地移动是极其困难的。对于一个全新的项目来说，情况并非如此，但随着时间的推移，许多项目进入了一种根本不可能实现可持续发展的境地。为了防止这种情况(和其他问题)，敏捷宣言和敏捷宣言背后的原则提供了几个高级指南。这些指导方针不是特定定义良好的流程或工具，它们允许许多不同的实现。我怀疑这两个属性(高级的和允许不同的实现)都是完全有意的。总体目标不是提供灵丹妙药，而是帮助同行避免软件开发中的许多陷阱，敏捷宣言的作者亲身体验过这些陷阱，而这些陷阱恰好属于这些类别。
现在让我们来看看 Scrum指南 （由敏捷宣言的两位作者编写）。与敏捷宣言和敏捷原则相比，本指南似乎相当冗长。令人惊讶的是，整个指南一次都没有提到敏捷。我不确定历史上是否总是这样，但是如果 Scrum 指南的作者不声称 Scrum 是敏捷的，那么我们已经完成了这个博客文章的第一部分。我想情况并非如此，所以我们继续。 Scrum 指南是关于一个包含“角色、事件、工件和将它们绑定在一起的规则”的框架。换句话说，这是一个非常具体和明确的过程。这听起来既不敏捷，也不敏捷（记住：“个人和过程和工具之间的交互”）。这是非常讽刺和明显的。这就是整个 Scrum 运动应该停止的地方。但它没有，反而让世界各地越来越多的软件开发人员感到沮丧。每当一个 Scrum 项目失败，并不是因为 Scrum 潜在的缺陷，而是因为 Scrum 没有正确实现。这听起来是一个很好的过渡到这篇文章的第二部分。
Scrum是脆弱的
这部分很短。我认为 wordplay （Scrum being agile / fragile）很有趣，除此之外，它完美地描述了 Scrum 真正困扰我的一件事:每当 Scrum 项目失败时，都是因为 Scrum 没有得到正确的实现。你可以阅读大量这样的项目。如果大量的智能软件开发人员不能正确地实现 Scrum，这意味着什么?这意味着整个框架是脆弱的。这是反对使用 Scrum 的另一个主要论点。如果它很难使用，那么什么是适合的框架？
好吧，似乎在昂贵的咨询和指导，以及培训和证书的帮助下，Scrum 实际上可能提供价值。 但目前尚不清楚这对于软件开发公司以及辛勤工作的软件开发人员或那些在 Scrum 生态系统内部和周围提供服务的人来说是否有价值。
个人观点
最后，我想谈谈我个人对软件开发、敏捷和 Scrum 的看法。在我看来，高质量软件开发的一个非常重要的部分是维护一个简单的优先级任务队列。权重是任务为客户/开发人员提供的价值和实现该任务的估计工作量的组合。有些开发人员天生就会这样。对于不属于这种情况的团队和公司，Scrum 提供了一个相当昂贵和低效的优先队列实现。坦白的说吧。软件开发是一项非常困难和复杂的工作。这么多项目都失败了，我们真的感到惊讶吗?这个领域还很年轻，我们需要学习很多东西。这一点至关重要：我们需要从过去的经验中学习，不管是失败还是成功的故事。在这里，我们都失败了。我们没有使用错误的流程或以错误的方式实现正确的流程。我们只是陷入了一场激烈的竞争，无法短暂地休息一下，去看看周围发生的一切，从中学习，甚至是在我们这个时代之前。我们的职责是从我们很容易获得的许多资源中提取知识、经验和智慧：许多有关软件开发的书籍、文章和视频，最后但并非最不重要的是敏捷宣言。
原文：http://www.dennisweyland.net/blog/?p=43
译者：Queena
送福利啦~ 近期将之前已翻译文章，整理成PDF。
在公众号后台回复：002 即可领取哦~
后续也会不断更新PDF的内容，敬请期待！
