Scrum 被高估了

大多数公司都遵循某种类型的 Scrum 流程。通常这包括 2 或 3 周的冲刺。在每个冲刺结束时，会演示变更，进行回顾，并整理待办事项。在每个冲刺期间，会记录任务完成时间，这使得管理层能够预测项目何时完成。

我参与过的许多 Scrum 项目都强调”承诺”任务或”承担责任”。在冲刺结束时，许多工程师要为未完成的任务承担责任。冲刺速度是另一个被反复强调的概念。我们必须保持我们的速度！这就像创建软件是一场比赛，但事实并非如此。如果工程师要对某个指标负责，他们就会为了这个指标而优化，这不是你想要的。

Scrum 为团队创建了一个易于理解的框架，并为管理层提供了预测未来的工具。实践过瀑布模型的团队发现 Scrum 很容易理解。

Scrum 的许多实践都是不必要的。例如，大多数问题跟踪软件都允许管理者运行关于工单完成频率的报告。有了这些信息，管理者能够推断速度，而不是将速度融入流程并将其作为重点。承担责任是一种虚假的做法，我们自然而然地会这样做，明确提出这一点是侮辱性的。在我参与的所有项目中，每个工程师都有应用程序中属于他们的一块区域。

改进软件交付的其他方法：

• 如果你需要每周部署，就安排它们。部署准备好的内容。
• 保持待办事项的整理；这样工程师就永远不会没有工作。
• 在我看来，回顾是最重要的非开发活动。没有它，你就没有机会成为一个更好、更高效的组织。
• 自动化，自动化，自动化
• 承诺一系列功能是荒谬的。对任务进行排序，完成你能完成的。为”任务 A”为什么没有完成而烦恼是浪费时间。很明显，任务要么太大，要么承担了更高优先级的工作。
• 演示是浪费时间的，除非客户关心并提供反馈。
• 每日会议可能需要也可能不需要。我更喜欢每隔几天开会。

归根结底，这是关于以最有效的方式为客户提供价值。