问是否有可靠的证据证明实现敏捷方法的所有实践(例如Scrum)相对于其中一些实践的好处？

EN

这看起来有些迂腐，但是你不能把敏捷应用到字面上，它只是一系列的价值观和原则。你所指的可能有两个方面。首先，敏捷总括中有一些框架和方法，并且有一些非常有力的论据支持遵循这些框架和方法(首先)。第二，在许多行业中，都有一种对最佳实践和想法的痴迷，那就是说出你要做的事情，然后不管什么东西是好的(破坏者:事实并非如此)。

敏捷

框架

Scrum、XP、Kanban等都是预先打包的获得特定结果的方法。你不需要使用它们，但是它们是别人成功的捷径(或者说真的是成千上万的人)。问题是，如果你不按预期操作的话，你就会取消保修。想想看:我需要一个新的架子。我可以在我的车库里建一个架子，但这需要我买一堆工具，学习木工，练习和失败很多次。相反，我要去宜家买一个架子。现在，我把架子带回家，我想把它放在一起。我应该按照指示，还是直接把螺丝放进洞里，直到两个都用完为止？好吧，这是我的架子，所以我不需要遵循说明，但是如果我用不同的方式把它放在一起，把稳定支架扔进垃圾桶，因为它用的是一个平头螺丝，而我只有一个飞利浦的驱动器，我真的能抱怨当架子坏了吗？

我希望每一个使用scrum或XP的团队最终都会超越scrum或XP，保留能够工作的部分，并重新调整其他部分，以适应其独特的环境。但是，在你使用了开箱即用的选项并真正了解了为什么它会像它那样工作之后，你才会这样做。然后你定制。

最佳实践

借用cynefin中的一些措辞，最佳实践只适用于清晰、简单的问题。复杂的问题有一大堆“好的”实践，每个问题都会根据你的情况稍微好一些。如果你进入复杂的问题，只有紧急的实践。知识工作几乎完全是在复杂和复杂的空间中进行的，这意味着最佳实践并不真正适用。这意味着，任何做法都不应被视为显然是正确的做法。一切都准备好了。我不知道组织是如何痴迷于最佳实践的，但这确实是个问题。

现在，为了把这些联系在一起:如果我使用看板，我应该使用WIP限制。否则我就不用看板了。有摩托车引擎的护卫舰不是护卫舰。这是否否定了我关于最佳实践的说法？不是的。应对WIP限制的做法进行审查。但是，如果你以前从未使用过它，你就没有足够的知识来有效地评估它在你的上下文中的有效性。如果您尝试使用其中的一小部分，很难判断它是否不起作用，因为这是一个不合适的，或者因为您没有使用支持实践一起。因此，您可以完整地实践这些框架中的一个，以了解它们是如何和为什么工作的，然后开始挑战它们。

丹尼尔的回答在将敏捷作为一组价值和原则以及敏捷方法和框架的严格应用方面做得非常出色。然而，我想进一步讨论另一个问题--我们可以说敏捷是应用的灵活性和解释的自由吗？

敏捷的核心是适应性和对变化的响应。我不认为在解释价值观和原则方面有太多的自由。不过，还是有一些。敏捷软件开发宣言是在20年前编写的，建立在25年到30年的工作基础上(关于各种方法的工作比宣言早了几年，如果不是更早的话)。

适应性和响应性(敏捷性)的核心与所提供的产品和服务有关。然而，敏捷需要在流程中具有一定程度的灵活性。这反映在宣言本身--“我们正在通过做软件和帮助他人开发软件，找到更好的开发方法。”回顾和过程改进的实践是敏捷软件开发的任何价值和原则中唯一的实践。

但是，如果您查看像Scrum这样的框架，规则中可能会有一些僵化的地方，从而实现敏捷性。我认为很难说Scrum做对了并不能促进敏捷性。请注意，这并不意味着您必须遵循Scrum才能变得敏捷，而是意味着在敏捷软件开发价值观和原则的背景下实践Scrum可以促进敏捷性。然而，Scrum中有一些特定的不可变规则约束着团队。这些规则的存在并不会使Scrum变得不灵活。

敏捷最重要的方面是适应团队工作的环境--需求、技术、涉众。因为基本原则是通过交付软件来满足客户的需求，所以您可以有更严格的框架来支持产品或服务的适应性。然而，过多的僵化可能会使适应变得更具有挑战性。这是一种平衡行为。