I believe you will find most software developed for business systems follows iterative development cycles with a rough methodology similar to SCRUM even though most wouldn't have realized it.
The only times you will ever see a static methodology such as Waterfall would be in most likely a large government project that requires every single technical and business design document to be completed and approved before any type of software development begins.
Since you are willing to spend money, you could turn to a professional analyst firm like Gartner Research. They generate tons of reports and you might find something in their archives. Major corporations often cite studies by Gartner.
If that does not yield any results, you should do a search in research papers. Google Scholar might help you there.
If all else fails, and you have enough time on your hands, you could perform a small study yourself: Pick random companies and tell them you are doing research and that you would like to ask them a few questions.
There would be standards based on the results. If anywhere close to 50% of shops actually used Scrum or RUP or anything, there would be an applicable standards organization pounding out the details.
We'd all be told specifically what to do based on the results. Our lawyers and accountants would ask why we're using a methodology only used by 15% and not a methodology used by 28%. We'd have to contend with armchair generals quoting the results at us.
There would be products for sale based on the results. "Supporting the most popular methodology." "One of the most popular methodologies." "Trouble-tickets for the fastest growing methodology."
You'd see advertising that quoted the results and claiming specific quantitative benefits. "28% of organizations use our version of Scrum with improved on-time delivery."
Ever see any advertising or standards based on adoption of a methodology? Anything?
Such quantitative studies probably don't exist.
Also, a precondition for counting is definition. Can you define Scrum in a way that it's somehow different from XP? I doubt it.
I think this kind of data cannot possibly exist. It requires far more formality and standardization than are even remotely possible for something so complex as software development.
I don't think you will find reliable data on what you're looking for. I've been looking for that kind of figures for a few years and I haven't found them.
First of all, very few organisations tell you what method they are using. Some just don't use any. Some other don't know what they use, or what to call it. And some know what to call it, but won't disclose it for whatever reasons. Of the organisations that will tell you, which are (in my experience) a minority, there's a big assymetry in how they characterise what they tell you. The way in which your own question is worded illustrates this: most industry people (and many academics) today, when asked to list methodologies, think of waterfall, RUP, Scrum, XP, and a few other "trademarked" agile approaches. It is interesting, but they are perfectly capable of citing a number of agile approaches, the differences between which are usually much smaller than the differences between (almost forgotten) methods that are bunched together under "waterfall". Agile approaches are so heavily marketed and hyped that, like Coca-Cola or McDonald's, are so present in our daily lives.
Methodologies are often presented as either waterfall or agile. That is a terrible fallacy, fostered by the agile community. There are successful methodologies that do not qualify as waterfall and predate (and do not qualify as) agile. However, they seem to be ignored, and they rarely surface on surveys such as the one you demand in your question. Very rarely I find people in industry reporting to use methods such as Catalysis, OPEN/Metis or Fusion.
(Note: Don't misunderstand me; I appreciate the value and contributions of the agile movement. But I am no raving fan; I am a researcher who tries to make an objective assessment.)
In summary, I don't think you'll find a study with data that answers your question. But, in your search, I suggest you take into account these comments.
maybe not sound helpfull, but don't give to much to buzzwords. good programmer/software engineers with an sense/instinct what needs to be done you need. most of these proceses where invented because fearfull programmer sticked to closely to one of these pradigmes and the car went against the wall and some guy rightfully pointed out what they missed. but that can happen with most strategies if you don't see you situation in which you developing as a whole.
the more recently hyped methods like XP i don't see in you list. they work well even in smaller teams. :)
发布评论
评论（6）
我手头有一些文件可以帮助您进行研究。
组织结构对软件质量的影响：实证案例研究
Nachiappan Nagappan
微软研究院
美国华盛顿州雷德蒙德
microsoft.com 的 nachin
布伦丹·墨菲
微软研究院
英国剑桥
bmurphy 在 microsoft.com
维克多·R·巴西利
马里兰大学
美国马里兰州科利奇帕克
basili at cs.umd.edu
In Proceedings, International Conference on Software Engineering, 1999, Los Angeles, CA, pp. 85-95
拆分组织和集成代码：
康威定律重新审视
调试开发过程
管理人类 - 一位软件工程经理的尖酸刻薄的幽默故事
Couple of the documents I have on hand to help you on your research.
THE INFLUENCE OF ORGANIZATIONAL STRUCTURE ON SOFTWARE QUALITY: AN EMPIRICAL CASE STUDY
Nachiappan Nagappan
Microsoft Research
Redmond, WA, USA
nachin at microsoft.com
Brendan Murphy
Microsoft Research
Cambridge, UK
bmurphy at microsoft.com
Victor R. Basili
University of Maryland
College Park, MD, USA
basili at cs.umd.edu
In Proceedings, International Conference on Software Engineering, 1999, Los Angeles, CA, pp. 85-95
Splitting the Organization and Integrating the Code:
Conway's Law Revisited
Debugging the Development Process
Managing Humans - Biting and Humorous Tales of a Software Engineering Manager
我相信您会发现大多数为业务系统开发的软件都遵循迭代开发周期，采用类似于 SCRUM 的粗略方法，尽管大多数人都没有意识到这一点。
您唯一一次看到诸如瀑布之类的静态方法很可能是在大型政府项目中，该项目要求在任何类型的软件开发开始之前完成并批准每个技术和业务设计文档。
I believe you will find most software developed for business systems follows iterative development cycles with a rough methodology similar to SCRUM even though most wouldn't have realized it.
The only times you will ever see a static methodology such as Waterfall would be in most likely a large government project that requires every single technical and business design document to be completed and approved before any type of software development begins.
既然你愿意花钱，你可以去找专业的分析公司，比如 Gartner Research。他们生成大量报告，您可能会在他们的档案中找到一些东西。大公司经常引用 Gartner 的研究。
如果这没有产生任何结果，您应该在研究论文中进行搜索。谷歌学术可能会帮助你。
如果所有其他方法都失败了，并且您有足够的时间，您可以自己进行一项小型研究：随机选择公司并告诉他们您正在做研究并且您想问他们一些问题。
Since you are willing to spend money, you could turn to a professional analyst firm like Gartner Research. They generate tons of reports and you might find something in their archives. Major corporations often cite studies by Gartner.
If that does not yield any results, you should do a search in research papers. Google Scholar might help you there.
If all else fails, and you have enough time on your hands, you could perform a small study yourself: Pick random companies and tell them you are doing research and that you would like to ask them a few questions.
如果存在这样的事情...
就会有基于结果的标准。如果接近 50% 的商店实际上使用了 Scrum 或 RUP 或任何东西，就会有一个适用的标准组织来研究细节。
我们都会根据结果被具体告知要做什么。我们的律师和会计师会问为什么我们使用仅 15% 使用的方法而不是 28% 使用的方法。我们必须与纸上谈兵的将军们竞争，他们向我们引用结果。
根据结果将有产品出售。 “支持最流行的方法。” “最流行的方法之一。” “增长最快的方法的麻烦单。”
您会看到广告引用结果并声称具体的量化效益。 “28% 的组织使用我们的 Scrum 版本，提高了准时交付率。”
曾经见过任何基于采用某种方法的广告或标准吗？任何事物？
这样的定量研究可能不存在。
另外，计数的前提是定义。你能用一种与 XP 不同的方式来定义 Scrum 吗？我对此表示怀疑。
我认为这种数据不可能存在。它需要的正式性和标准化远远超过软件开发这样复杂的事情。
If such a thing existed...
There would be standards based on the results. If anywhere close to 50% of shops actually used Scrum or RUP or anything, there would be an applicable standards organization pounding out the details.
We'd all be told specifically what to do based on the results. Our lawyers and accountants would ask why we're using a methodology only used by 15% and not a methodology used by 28%. We'd have to contend with armchair generals quoting the results at us.
There would be products for sale based on the results. "Supporting the most popular methodology." "One of the most popular methodologies." "Trouble-tickets for the fastest growing methodology."
You'd see advertising that quoted the results and claiming specific quantitative benefits. "28% of organizations use our version of Scrum with improved on-time delivery."
Ever see any advertising or standards based on adoption of a methodology? Anything?
Such quantitative studies probably don't exist.
Also, a precondition for counting is definition. Can you define Scrum in a way that it's somehow different from XP? I doubt it.
I think this kind of data cannot possibly exist. It requires far more formality and standardization than are even remotely possible for something so complex as software development.
我认为您不会找到有关您正在寻找的内容的可靠数据。几年来我一直在寻找这类数字，但一直没有找到。
首先，很少有组织告诉你他们正在使用什么方法。有些人根本不使用任何东西。其他一些人不知道他们使用什么，或者如何称呼它。有些人知道该怎么称呼它，但出于某种原因不会透露。在那些会告诉你信息的组织中（根据我的经验），这些组织是少数，他们如何描述他们告诉你的内容存在很大的不对称性。您自己的问题的措辞方式说明了这一点：当今大多数行业人士（以及许多学者），当被要求列出方法时，会想到瀑布、RUP、Scrum、XP 和其他一些“商标“敏捷方法。这很有趣，但他们完全有能力引用许多敏捷方法，这些方法之间的差异通常比“瀑布”下聚集在一起的（几乎被遗忘的）方法之间的差异小得多。敏捷方法被大力宣传和宣传，就像可口可乐或麦当劳一样，存在于我们的日常生活中。
方法论通常表现为瀑布式或敏捷式。这是一个可怕的谬论，是由敏捷社区培育出来的。有些成功的方法并不符合瀑布式方法，并且早于（也不符合）敏捷方法。然而，它们似乎被忽视了，并且很少出现在诸如您在问题中所要求的调查中。我很少发现业内人士报告使用催化、OPEN/Metis 或 Fusion 等方法。
（注：不要误会我的意思；我很欣赏敏捷运动的价值和贡献。但我不是狂热的粉丝；我是一个试图做出客观评估的研究者。）
总而言之，我不认为你'将找到一项包含数据的研究来回答您的问题。但是，在您的搜索中，我建议您考虑这些评论。
祝你好运。 :-)
I don't think you will find reliable data on what you're looking for. I've been looking for that kind of figures for a few years and I haven't found them.
First of all, very few organisations tell you what method they are using. Some just don't use any. Some other don't know what they use, or what to call it. And some know what to call it, but won't disclose it for whatever reasons. Of the organisations that will tell you, which are (in my experience) a minority, there's a big assymetry in how they characterise what they tell you. The way in which your own question is worded illustrates this: most industry people (and many academics) today, when asked to list methodologies, think of waterfall, RUP, Scrum, XP, and a few other "trademarked" agile approaches. It is interesting, but they are perfectly capable of citing a number of agile approaches, the differences between which are usually much smaller than the differences between (almost forgotten) methods that are bunched together under "waterfall". Agile approaches are so heavily marketed and hyped that, like Coca-Cola or McDonald's, are so present in our daily lives.
Methodologies are often presented as either waterfall or agile. That is a terrible fallacy, fostered by the agile community. There are successful methodologies that do not qualify as waterfall and predate (and do not qualify as) agile. However, they seem to be ignored, and they rarely surface on surveys such as the one you demand in your question. Very rarely I find people in industry reporting to use methods such as Catalysis, OPEN/Metis or Fusion.
(Note: Don't misunderstand me; I appreciate the value and contributions of the agile movement. But I am no raving fan; I am a researcher who tries to make an objective assessment.)
In summary, I don't think you'll find a study with data that answers your question. But, in your search, I suggest you take into account these comments.
Good luck. :-)
也许听起来没有什么帮助，但不要过多关注流行语。优秀的程序员/软件工程师，具有您需要完成的任务的感觉/本能。大多数这些过程的发明是因为可怕的程序员严格遵守这些范式之一，而汽车撞到了墙上，一些人正确地指出了他们错过的东西。但如果你没有看到自己作为一个整体发展的情况，大多数策略都可能发生这种情况。
最近大肆宣传的方法（例如 XP）我在您的列表中没有看到。即使在较小的团队中，他们也能很好地工作。 :)
maybe not sound helpfull, but don't give to much to buzzwords. good programmer/software engineers with an sense/instinct what needs to be done you need. most of these proceses where invented because fearfull programmer sticked to closely to one of these pradigmes and the car went against the wall and some guy rightfully pointed out what they missed. but that can happen with most strategies if you don't see you situation in which you developing as a whole.
the more recently hyped methods like XP i don't see in you list. they work well even in smaller teams. :)