---

Scrum 之前什么会造成混乱和挫折？答案可能让你惊讶！

要理解 Scrum 对工程实践和业务的影响，值得看看一个软件项目的一天。

我想简述采用框架之前的一个旧项目。

写这些文字前几天，我们与近 20 年前的老同事午餐。

Marcus 取得了 Scrum Master 认证 和 产品负责人认证 ，来自 International Scrum Institute™。他目前在敏捷项目管理软件领域的一家领先软件企业担任 Scrum Master。

现在支持成员遍布全球的敏捷团队。

午餐时，Marcus 承认分布式敏捷团队有许多常见挑战。他特别提到项目中的以下问题：

• 成员工作风格不同，
• 时区差异，
• 文化不契合，以及
• 语言限制。

尽管如此，他表示用敏捷 Scrum 开展软件项目，比 20 年前的方式更有趣、更高效、更充实。 相比过去不使用 Scrum 开发与交付流程的日子。

这位成就出色、经验丰富的经理、Scrum Master 和产品负责人，为框架提供了有力见证。

谢谢你，Marcus！

随后我们讲述一个采用 Scrum 前的项目。相信很多 Scrum Master 会认出自己认证前的类似经历。

1990 年代末，我们参与工程小组，基于智能卡构建 公钥基础设施。智能卡安全保护成员私钥，关联公钥和封装证书则公开分发，正如“公钥”的名称所示。

当时项目本身相当复杂，需要多个相互依赖的硬件与软件团队，进行大量 研究与开发（R&D） ，才能构建完整可用的软硬件系统。

请记住，当时还没用 最小可行产品（MVP） 概念来实验、创造、学习并再次实验。

没有 Scrum，创建包含众多软硬件要素的复杂基础设施，是真正挑战。

以下是 三个重大挫折 ，发生在队内既无 Scrum Master、也无持证人员的时候。