Ahmad Nassri

你将 Scrum 与敏捷混淆了。

敏捷是一种方法论，带有宣言 + 原则。

Scrum 是一种流程，专注于角色、任务和交付工作的步骤。

从这个意义上说，开放式开发方法是一种方法论，我们将与社区的帮助一起发展它、修改它、改进它，然后围绕它创建流程。

很抱歉回复晚了，尽管你是第一个评论者 :)

希望这能出现在你的新闻订阅中，把你带到这里，为讨论增加价值和思考，并帮助我们改进工作流程和流程 :)

我不应该将其标记为“代码质量”，而应该简单地标记为“质量”。

这适用于设计、代码、用户体验和商业价值。你希望在所有这些方面都提供质量。

测试也是如此。测试你的设计，测试你的代码，测试你的用户体验，最重要的是测试你的商业模式！

Scrum 和敏捷的最大失败之处在于“关注客户价值”的虚假承诺，而实际上很少帮助实现该价值。

客户通常不是专家（这没关系），但被当作专家对待，因此在大多数情况下被小心翼翼地对待。他们没有完全了解幕后真正的工作，而是通过两层脚注来委派：Scrum Master（通常是项目经理）和产品负责人（通常是产品经理）。

客户永远不会真正看到或理解用户体验的复杂性、设计选择或开发挑战。为了时间和成本，你最终会创建不断增长且从未真正解决的技术债务，因为你想专注于“客户价值”，这意味着在尽可能短的时间内交付他们要求的功能，而不考虑成本。

同样重要的是要记住，敏捷和 Scrum 针对的是服务行业，而不是产品构建者。从它们的起源和历史到它们所依赖的措辞，例如“客户”，它从根本上对产品构建有不同的看法，并且在软件的创建者（开发人员、设计师等）与软件的实际用户（通常是客户的客户）之间引入了深刻的隔离。

> “你可能见过很多敏捷教练。听起来大多数都很糟糕。这可能让你对敏捷感到厌恶。”

事实恰恰相反，与敏捷和教练有很多愉快和有益的经验。尽管如此，它仍然达不到上述原因。

似乎这是对任何敏捷教练或长期饮用 Scrum 酷爱饮料的人的默认反应：“你只是没有做对”。

老实说，这不是进行讨论和提供价值的方式。让我们详细讨论缺少什么，什么是好的，什么是坏的，并进行全面的改进。

毕竟，敏捷/Scrum 的核心是通过迭代过程持续改进。我根本看不到 Scrum 或敏捷本身得到改进或重新审视，而是像最初发布宣言的原始网站一样保持静态，那是过去时代的遗迹，完全体现在其发布的过时网站上。

n