agile - 敏捷是否经过科学证明？

Question

是否有任何科学研究将敏捷与其他软件开发方法进行了比较？我认为敏捷是一种很好的工作方式，但它有什么科学依据吗？

我正在寻找类似的东西，除了这项研究只涉及 TDD。有没有关于敏捷的研究？

我问这个是因为我遇到了一个敏捷狂热者，他声称敏捷工作方式比所有其他工作方式产生的软件更好。他提出这是一个事实，我不认为这是事实。

Answer 1

科学的？嗯，我对 Alistair Cockburn 的工作印象深刻。在这里听他说

当 IBM 要求他为面向对象项目编写方法论时，Alistair Cockburn 已经做了 16 年的硬件设计师和研究人员。在过去的十年里，他一直在研究和撰写有关软件开发的文章，并了解到一些最成功的项目都有最简单的流程。2001 年，他和其他 16 位软件开发重量级人物开会讨论所谓的轻量级方法，其中一个成果是敏捷软件开发宣言，其中包括四个价值声明：个人和交互优于流程和工具；工作软件优于综合文档；合同谈判中的客户协作；并响应变化而不是遵循计划。

Answer 2

Scrum 的某些方面有支持性的经验证据。已经对 Scrum 的不同部分进行了大量的实证研究。我听说 Jeff Sutherland（http://jeffsutherland.com/scrum/ scrum 的发明者）在他的演讲中提到了很多具体的研究和观察。

一般来说，敏捷只是一个总称，旨在让不同的政治团体保持适度的快乐。不要期望看到实验证明所有“敏捷”的一般性。它太模糊了，没有用。

Answer 3

来自 NCSU 的 Laurie Williams发表了很多关于结对编程有效性的非常有趣的研究，然后开始处理敏捷的更多方面。

Answer 4

本文分析了敏捷与传统方法的投资回报率 (ROI)。它基于已发表研究的实际结果。

从摘要：

敏捷方法的投资回报率是昂贵的传统方法的四倍，比廉价的方法低两倍，最好的敏捷方法和传统方法的投资回报率相同。

Answer 5

不，它没有经过科学或其他方式的证明。要“证明”它意味着：

• 从分析的角度证明其有效性。
• 证明它在实践中有效，然后推断其有效性

分析方法是不可行的，因为我们在这里处理的是人而不是简单的系统。你不能将团队和组织正式化。

另一方面，已经进行了实证研究，但结果尚无定论。例如，Robert Glass 在他的《软件创意 2.0》一书中展示了一些有趣的结果。

所以不，敏捷没有得到证明。差远了。:-)

Answer 6

我认为不可能“证明”这样的事情。

我会更进一步，并说我认为通过这样的研究来研究“软件开发生产力”问题是不可能的。这主要是为什么我们所有的证据真的必须继续的所有证据都是有经验的人告诉我们的（不幸的是，每个人对各种方法都有不同的看法）。

原因很简单：人与人是完全不同的。坐下一个由 5 人组成的团队进行几个月的项目（我猜，这比大多数研究所能管理的要多；让我们看看有人资助几个月的开发时间），你一定会完全得到不同的结果。问题是，这里没有办法区分许多不同的因素：

1. 个人程序员的能力。
2. 程序员的奉献精神/努力。
3. 使用工具的经验。
4. 担任团队领导者的能力（仅仅遵循一种方法是不够的。如果有人不知道如何管理团队，那么方法就不会真正得到很好的体现）。

而且可能还有更多的因素。

所以我想说的是，不要相信那些“证明”一种方法/工具/任何东西比其他方法更好的研究。他们几乎不可能做到。

Answer 7

向我证明的是瀑布的统计失败，即应用于软件开发的科学管理。敏捷，作为一种运动，只是对这一经验证据的一种回答（例如参见 CHAOS 报告）。

Answer 8

InfoQ 对 Linda Rising的采访在一定程度上解决了你的问题。她谈到了安慰剂的有效性和我们对医学的信念，以及这些相同的事情如何与软件开发相关。基本上，我们在敏捷社区中是否给自己一个“糖丸”？

采访摘录

科学是关于实验的，关于在短时间内持有一个想法并对其进行测试，然后检查该测试的结果以找出该假设是否成立。这就是敏捷的真正意义所在。敏捷是关于小实验。我现在相信我们所做的一切，不仅仅是软件开发，我们的生活应该是一系列的小实验。

我们引入每一个可能的利益相关者，我们引入客户，我们引入用户，测试人员与开发人员一起工作。我们一直在仔细检查那些糖丸。它真的有效吗？你怎么看？你对结果满意吗？那是唯一能拯救我们的东西——敏捷本身。这一系列的小实验。