I don't think it's possible to "prove" such a thing.
I'll go even further, and say that I don't think it's really possible to study the issue of "Software Development productivity" with such a study. Which is mainly why all the evidence we ever really have to go on is what experienced people tell us (and unfortunately, each one has a different view on various methodologies).
There's a simple reason for this: people are completely different. Sit down a team of 5 people for a project of a few months (which is more, I'm guessing, than most studies ever manage; let's see anyone finance a few months of developer time), and you're bound to get completely different results. The problem is, there is no way to sepearate the many different factors here:
Ability of the individual programmers.
Dedication/effort put in by the programmers.
Experience with the tools.
The ability of whoever is acting as the team leader (just following a methodology isn't enough. If someone doesn't know how to manage a team, the methodology won't really be well represented).
And there are probably many more factors.
So what I'm trying to say is, don't believe studies that have "proven" that one methodology/tool/anything works better than others. They're almost impossible to do.
What is proven to me is the statistical failure of waterfall i.e. scientific management applied to software development. Agile, as a movement, is just an answer to this empirical evidence (see for example the CHAOS reports).
This interview with Linda Rising on InfoQ addresses your question to some extent. She talks about the effectiveness of placebos and our beliefs in medicine and how these same things might relate to Software Development. Basically, are we in the Agile community giving our selves a "Sugar Pill"?
Interview Excerpt
Science is about experiments, about holding an idea for a short period of time and testing it and then examining the results of that test to find out whether or not the hypothesis holds up. That's really what Agile is about. Agile is about small experiments. I now believe that everything we do, not just software development, but our lives should be a series of small experiments.
We bring in every possible stakeholder, we bring in customers, we bring in users, testers work with developers. We are always examining carefully those sugar pills. Does it really work? What do you think? Are you happy with the results? That's the only thing that saves us - Agile itself. This series of small experiments.
This paper analyzes the return on investment (ROI) of Agile vs Traditional methods. It's based on actual results from published studies.
From the abstract:
Agile Methods ROI was four times more than expensive Traditional Methods, two times less than inexpensive ones, and the best Agile and Traditional Methods had equal ROI.
No, it's not scientifically or otherwise proven. To "prove" it would mean either:
To demonstrate its validity from an analytical point of view.
To show that it works in practice and then infer its validity
An analytical approach is unfeasible, since we are dealing with people here rather than simple systems. You cannot formalise teams and organisations.
Empirical studies, on the other hand, have been conducted, but the outcomes are unconclusive. Robert Glass shows some interesting results in his book Software Creativity 2.0, for example.
Scientific? Well, I'm very impressed of Alistair Cockburn work. Listen to him here
Alistair Cockburn had been a hardware designer and researcher for 16 years when IBM asked him to write a methodology for object-oriented projects. He's spent the last decade studying and writing about software development and learned that some of the most successful projects have the simplest processes. In 2001 he and 16 other software-development heavyweights met to discuss so-called lightweight methodologies, and one result was the Agile Software Development Manifesto, which includes four value statements: individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; and responding to change over following a plan.
Laurie Williams from NCSU published a lot of really interesting studies on the effectiveness of pair programming, and then started dealing with more facets of agile.
Certain aspects of scrum have supporting empirical evidence. Quite a number of empirical studies of different part of scrum have been done. I've heard Jeff Sutherland ( http://jeffsutherland.com/scrum/ the inventor of scrum) mention lots of specific studies and observations in his talks.
Agile in general is just an umbrella term designed to keep different political groups moderately happy. Don't expect to see an experiment prove anything general about all of "agile". It's too vague to be useful.
发布评论
评论（8）
我认为不可能“证明”这样的事情。
我会更进一步说，我认为通过这样的研究来研究“软件开发生产力”问题真的不可能。 这主要就是为什么我们真正必须继续使用的所有证据都是经验丰富的人告诉我们的（不幸的是，每个人对各种方法都有不同的看法）。
原因很简单：人与人之间是完全不同的。 让一个 5 人的团队坐下来完成一个为期几个月的项目（我猜，这比大多数研究所管理的时间还要长；让我们看看有人愿意花几个月的开发时间），你一定会完全得到不同的结果。 问题是，无法区分这里的许多不同因素：
可能还有更多因素。
所以我想说的是，不要相信“证明”一种方法/工具/任何东西比其他方法更有效的研究。 它们几乎是不可能做到的。
I don't think it's possible to "prove" such a thing.
I'll go even further, and say that I don't think it's really possible to study the issue of "Software Development productivity" with such a study. Which is mainly why all the evidence we ever really have to go on is what experienced people tell us (and unfortunately, each one has a different view on various methodologies).
There's a simple reason for this: people are completely different. Sit down a team of 5 people for a project of a few months (which is more, I'm guessing, than most studies ever manage; let's see anyone finance a few months of developer time), and you're bound to get completely different results. The problem is, there is no way to sepearate the many different factors here:
And there are probably many more factors.
So what I'm trying to say is, don't believe studies that have "proven" that one methodology/tool/anything works better than others. They're almost impossible to do.
向我证明的是瀑布式统计失败，即科学管理应用于软件开发。 敏捷作为一种运动，只是对这一经验证据的回答（例如参见 CHAOS 报告）。
What is proven to me is the statistical failure of waterfall i.e. scientific management applied to software development. Agile, as a movement, is just an answer to this empirical evidence (see for example the CHAOS reports).
InfoQ 上 Linda Rising 的采访在一定程度上解决了您的问题。 她谈论了安慰剂的有效性和我们对医学的信念，以及这些相同的事情如何与软件开发相关。 基本上，敏捷社区中的我们是否给自己开了一颗“糖丸”？
采访摘录
This interview with Linda Rising on InfoQ addresses your question to some extent. She talks about the effectiveness of placebos and our beliefs in medicine and how these same things might relate to Software Development. Basically, are we in the Agile community giving our selves a "Sugar Pill"?
Interview Excerpt
本文分析了敏捷方法与传统方法的投资回报率 (ROI)。 它基于已发表研究的实际结果。
摘要：
This paper analyzes the return on investment (ROI) of Agile vs Traditional methods. It's based on actual results from published studies.
From the abstract:
不，这没有经过科学或其他方式证明。 “证明”它意味着：
分析方法是不可行的，因为我们在这里面对的是人而不是简单的系统。 你无法将团队和组织正规化。
另一方面，已经进行了实证研究，但结果尚无定论。 例如，罗伯特·格拉斯 (Robert Glass) 在他的《软件创造力 2.0》一书中展示了一些有趣的结果。
所以不，敏捷尚未得到证实。 差远了。 :-)
No, it's not scientifically or otherwise proven. To "prove" it would mean either:
An analytical approach is unfeasible, since we are dealing with people here rather than simple systems. You cannot formalise teams and organisations.
Empirical studies, on the other hand, have been conducted, but the outcomes are unconclusive. Robert Glass shows some interesting results in his book Software Creativity 2.0, for example.
So no, agile is not proven. Not even close. :-)
科学吗？ 嗯，阿利斯泰尔·科伯恩的作品给我留下了深刻的印象。 此处听听他的讲话
Scientific? Well, I'm very impressed of Alistair Cockburn work. Listen to him here
来自 NCSU 的 Laurie Williams 发表了许多关于结对编程有效性的非常有趣的研究，然后开始处理敏捷的更多方面。
Laurie Williams from NCSU published a lot of really interesting studies on the effectiveness of pair programming, and then started dealing with more facets of agile.
Scrum 的某些方面有支持性的经验证据。已经对 Scrum 的不同部分进行了大量的实证研究。 我听 Jeff Sutherland（http://jeffsutherland.com/scrum/ Scrum 的发明者）提到过很多在他的演讲中提出了具体的研究和观察。
一般来说，敏捷只是一个总称，旨在让不同的政治团体保持适度的满意。 不要期望看到实验证明所有“敏捷”的一般性内容。 它太模糊了，没有什么用处。
Certain aspects of scrum have supporting empirical evidence. Quite a number of empirical studies of different part of scrum have been done. I've heard Jeff Sutherland ( http://jeffsutherland.com/scrum/ the inventor of scrum) mention lots of specific studies and observations in his talks.
Agile in general is just an umbrella term designed to keep different political groups moderately happy. Don't expect to see an experiment prove anything general about all of "agile". It's too vague to be useful.