正如标题所示，这篇文章是关于Scrum的两个不同方面。第一部分处理Scrum的不敏感，第二部分处理Scrum的脆弱。 　　

　　在详细介绍之前，简单声明：我在本文(以及一般博客)中提出的所有内容都是我的个人观点，不代表我的现任雇主、前任雇主以及任何未来雇主的观点。 　　

　　Scrum并不敏捷。 　　

　　我猜人们对这个标题的典型反应会是“这怎么可能？Scrum不敏捷？Scrum不就是第一个敏捷软件开发过程吗？”简而言之，Scrum自称是一个敏捷的过程，但不幸的是，Scrum离敏捷还很远。我来告诉你为什么。 　　

　　让我们快速浏览一下敏捷宣言。它说它重视“个人和互动，而不是过程和工具”。让我们快速看一下敏捷这个词的含义。根据牛津词典的解释，敏捷意味着“能够快速而轻松地行动”。敏捷一词被用来代表敏捷宣言中的高级思想，这并不是巧合。事实上，敏捷背后的一个主要思想是，在许多软件项目中，快速简单地移动是极其困难的。对于一个全新的项目来说并非如此，但是随着时间的推移，很多项目已经进入了根本无法实现可持续发展的境地。为了防止这种情况(以及其他问题)，敏捷宣言及其背后的原则提供了几个高层次的指导方针。这些指南不是明确定义的过程或工具，它们允许许多不同的实现。我怀疑这两个属性(高级和允许不同的实现)完全是故意的。总体目标不是提供一个万灵药，而是帮助同行避免软件开发中的许多陷阱。《敏捷宣言》的作者亲身经历了这些陷阱，而这些陷阱恰好属于这几类。 　　

　　现在让我们来看看https://www.scrum.org/resources/scrum-guide(由《敏捷宣言》的两位作者撰写)。与《敏捷宣言》和《敏捷原则》相比，这本指南似乎相当冗长。令人惊讶的是，整个指南一次都没有提到敏捷。我不确定历史上是否一直如此，但是如果《Scrum指南》的作者没有宣称Scrum是敏捷的，那么我们已经完成了这篇博文的第一部分。我觉得不是这样的，那我们继续。Scrum guide是一个包含“角色、事件、工件和将它们结合在一起的规则”的框架。换句话说，这是一个非常具体明确的过程。这听起来既不敏捷也不敏捷(记住：“个人与过程和工具之间的交互”)。但在这是非常讽刺和明显的。这就是整个 Scrum 运动应该停止的地方。,情况并非如此。相反，它让全世界越来越多的软件开发者感到沮丧。每当一个Scrum项目失败，并不是因为Scrum的潜在缺陷，而是因为Scrum没有被正确实现。这听起来像是本文第二部分的一个很好的过渡。 　　

　　Scrum是脆弱的。 　　

　　这部分很短。我觉得文字游戏(Scrum是敏捷/脆弱的)很有意思。此外，它完美地描述了Scrum真正困扰我的一件事。3360每当Scrum项目失败，都是因为Scrum没有被正确的实现。你可以阅读很多这样的项目。如果大量的智能软件开发人员不能正确地实现 Scrum，这意味着什么？这意味着整个框架是脆弱的。是反对使用Scrum的另一个主要论据。如果难以使用，那么什么是合适的框架呢？ 　　

　　嗯，看起来在昂贵的咨询和指导，以及培训和证书的帮助下，Scrum实际上可能提供了价值。但尚不清楚这对软件开发公司和辛勤工作的软件开发人员或那些在Scrum生态系统中或围绕Scrum生态系统提供服务的人是否有价值。 　　

　　个人观点 　　

　　最后，我想谈谈我个人对软件开发、敏捷和Scrum的看法。在我看来，高质量软件开发的一个非常重要的部分就是维护一个简单的优先级任务队列。权重是任务提供给客户/开发者的价值和实现任务的预计工作量的组合。有些开发者天生如此。对于不属于这种情况的团队和公司，Scrum提供了一个相当昂贵且低效的优先级队列实现。实话实说吧。软件开发是一项非常困难和复杂的工作。我们真的对这么多项目失败感到惊讶吗？这个领域还很年轻，我们需要学习的东西还很多。这是至关重要的：我们需要从过去的经历中学习，无论是失败还是成功的故事。在这里，我们都失败了。我们没有使用错误的流程，也没有以错误的方式实施正确的流程。我们只是陷入了一场激烈的竞争中，不能稍作休息，看看周围发生了什么，并从中吸取教训，甚至在我们的时代到来之前。我们的职责是从我们容易获得的许多资源中提取知识、经验和智慧：许多关于软件开发的书籍、文章和视频，最后但同样重要的是敏捷宣言。 　　

　　发福利~最近我把之前翻译的文章整理成了PDF。 　　

　　微信官方账号后台回复：002即可获得~ 　　

　　PDF的内容以后会不断更新，敬请期待！