敏捷被科学证明了吗?[闭门]

科学的阿利斯泰尔·科伯恩的作品给我留下了深刻的印象。听他的 here

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

scrum的某些方面有支持性的经验证据。 http://jeffsutherland.com/scrum/

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

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

不,这不是科学或其他证明。“证明”意味着:

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

另一方面,已经进行了实证研究,但结果没有定论。例如,罗伯特·格拉斯(Robert Glass)在他的书《软件创造力2.0》中展示了一些有趣的结果。

所以不,敏捷还没有被证明。甚至不接近。:-)

我会更进一步,我认为用这样的研究来研究“软件开发生产力”的问题是不可能的。这就是为什么我们有这么多证据 真正地 经验丰富的人告诉我们必须继续(不幸的是,每个人对各种方法都有不同的看法)。

原因很简单:人是完全不同的。让5人组成的团队参与一个为期几个月的项目(我猜,这比大多数研究所能做到的还要多;让我们看看有没有人资助几个月的开发时间),你肯定会得到完全不同的结果。问题是,这里没有办法区分许多不同的因素:

1. 个人程序员的能力。
3. 有使用工具的经验。
4. 作为团队领导者的人的能力(仅仅遵循一种方法是不够的。如果有人不知道如何管理团队,那么这种方法就不能很好地体现出来)。

可能还有更多的因素。

对我来说,瀑布的统计失败证明了这一点。 scientific management 应用于软件开发。敏捷,作为一种运动,仅仅是对这一经验证据的回答(例如,参见混沌报告)。

This paper

摘自摘要:

敏捷方法的ROI是原来的四倍 与昂贵的传统方法相比, 比便宜的便宜两倍, 最好的敏捷和传统 方法具有相同的ROI。

这 interview with Linda Rising on InfoQ 在某种程度上解决了你的问题。她谈到了安慰剂的有效性和我们对医学的信仰,以及这些东西如何与软件开发相关。基本上,敏捷社区中的我们是在给自己一颗“糖丸”吗?

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

我们引进了每一个可能的利益相关者,我们引进了客户,我们引进了用户,测试人员与开发人员合作。我们总是仔细检查那些糖丸。真的有用吗?你怎么认为?你对结果满意吗?这是唯一拯救我们的东西——敏捷本身。这是一系列的小实验。