问敏捷运动丢失了哪些好的实践，如果有的话？

EN

在5-10年的时间里，看看这些系统的可维护性是多么有趣，因为没有人写下为什么做出了一个特定的决定，所有相关的人都离开了。

我是不是遗漏了什么？

是的，我想了很多，但只有当你对软件开发过程感兴趣的时候。

我喜欢这样的解释：

每个项目都应该尽可能敏捷，但不能更敏捷。

并不是每个项目都可以是敏捷的。但我认为80%+可以。

我把敏捷看作是"car of the year“。它非常适合大多数人，但如果你需要/想要一些特殊的东西，例如能够以300公里/小时的速度行驶的汽车或能够运载20吨货物的汽车，你需要其他的东西。

也有很多情况下，一个人可能想要一些其他的东西，而不是“年度汽车”，这需要一本书来写下来:-)我推荐你Agility and Discipline Made Easy: Practices from OpenUP and RUP。在这本书中，你会发现许多“缺失的部分”，而且图文并茂。理解敏捷的关键是，敏捷性只是软件开发过程的一个(要求的)属性，有时无法实现。这本书描述了几个关键的开发原则(它们是RUP的基础)，并解释了在不同的采用级别上使用它们所导致的“仪式”和“迭代”级别。

示例

实践:自动化变更管理和变更传播

在您的项目中，您可能需要非常先进和严格的变更管理，并决定通过实现自定义或重新配置现有工具以及使用change and Control Board来“自动化变更管理和变更传播”。

效果:这很可能会增加你项目中的“仪式”级别。

(...)抛弃或遗漏了一大堆好的(非Scrum，非XP)实践。

Scrum不是规定性的，它由你来选择如何做事情。换句话说，没有任何东西会强迫你使用用户故事(例如，即使用户故事适用于许多团队，但没有共识)，所以如果你认为在你的环境中更适合使用(轻量级)用例，请随意使用。为了说明这一点，Jeff Sutherland报告说，他再也不会在PDA设备项目中使用用户故事了(在他目前的公司中，他们使用了某种“轻量级规范”)。同样的道理也适用于测试，使用任何适合你的工具。总而言之，如果您发现XP不够灵活，可以使用其他工具……并进行检查和调整。