Project management 软件开发方法学研究

我花了几个小时寻找关于软件开发方法（如瀑布、RUP或Scrum）的最新数据，但找不到任何有用的信息。有人知道这样的调查吗？相应的文件不需要免费提供，但作为一件理所当然的事，我将不胜感激

多谢各位！

---

Seb

既然你愿意花钱，你可以找一家像这样的专业分析公司。他们会生成大量的报告，你可能会在他们的档案中找到一些东西。大公司经常引用Gartner的研究

如果没有任何结果，你应该在研究论文中搜索。谷歌学者可能会在这方面帮助你

---

如果其他方法都失败了，而且你手头有足够的时间，你可以自己做一个小研究：随机挑选一些公司，告诉他们你正在做研究，你想问他们几个问题。

听起来可能没什么帮助，但不要给流行语太多东西。优秀的程序员/软件工程师，对你需要做的事情有感觉/直觉。大多数这些程序的发明是因为fearfull程序员紧紧地粘在其中一个pradigmes上，汽车撞到了墙上，一些人正确地指出了他们错过了什么。但如果你看不到你作为一个整体发展的情况，大多数策略都可能发生这种情况

---

最近被大肆宣传的方法，比如XP，我在你的列表中没有看到。即使在较小的团队中，他们也能很好地工作。：）

我手头有两份文件可以帮助你进行研究

组织结构对软件质量的影响：一个实证案例研究

纳奇亚潘-纳加潘
微软研究部
美国华盛顿州雷德蒙德
微软网站上的nachin

布伦丹·墨菲
微软研究部
英国剑桥
bmurphy位于microsoft.com

维克多·R·巴西里
马里兰大学BR> 美国马里兰州大学公园
巴西理工大学教育学院

---

《软件工程国际会议记录》，1999年，加利福尼亚州洛杉矶，第85-95页

拆分组织并集成代码： 康威定律再探

---

调试开发过程

---

---

管理人——关于软件工程经理的尖刻而幽默的故事

我相信你会发现，大多数为业务系统开发的软件都遵循迭代开发周期，采用类似于SCRUM的粗略方法，即使大多数人都没有意识到这一点

---

只有在大型政府项目中，你才会看到瀑布式的静态方法论，它要求在任何类型的软件开发开始之前完成并批准每一个技术和业务设计文档。

如果存在这种情况

将有基于结果的标准。如果有近50%的商店实际使用了Scrum或RUP或其他任何东西，那么就会有一个适用的标准组织来处理细节

根据结果，我们都会被明确告知该做什么。我们的律师和会计师会问，为什么我们使用的方法只有15%，而不是28%。我们将不得不面对纸上谈兵的将军们向我们引用结果

根据结果将有产品出售。“支持最流行的方法。”“最流行的方法之一。”“增长最快的方法的故障单。”

你会看到一些广告，其中引用了结果，并声称具体的数量效益。“28%的组织使用我们的Scrum版本，并改进了准时交付。”

是否见过任何基于采用方法论的广告或标准？有什么事吗

这样的定量研究可能并不存在

此外，计数的先决条件是定义。你能用一种与XP不同的方式来定义Scrum吗？我对此表示怀疑

---

我认为这种数据不可能存在。它需要更多的形式化和标准化，远比软件开发这样复杂的事情所需要的要多得多

我认为你找不到可靠的数据。我已经找了几年这样的数据，但我没有找到

首先，很少有组织告诉你他们使用的是什么方法。有些人根本不用。有些人不知道他们用什么，或者叫什么。有些人知道该怎么称呼它，但不管出于什么原因都不会透露。根据我的经验，在那些会告诉你的组织中，他们只是少数，在如何描述他们告诉你的内容方面存在很大的不对称。您自己的问题的措辞方式说明了这一点：今天，当被要求列出方法论时，大多数业界人士（以及许多学者）都会想到瀑布法、RUP、Scrum、XP和其他一些“有商标的”敏捷方法。这很有趣，但他们完全能够引用许多敏捷方法，它们之间的差异通常比在“瀑布”下聚集在一起的方法（几乎被遗忘）之间的差异要小得多。敏捷方法被大量地推销和宣传，就像可口可乐或麦当劳一样，在我们的日常生活中随处可见

方法论通常以瀑布或敏捷的形式呈现。这是一个可怕的谬论，由敏捷社区所培育。有一些成功的方法论不符合瀑布式和早于（也不符合）敏捷的条件。然而，他们似乎被忽视了，而且他们很少出现在调查中，比如你在问题中要求的调查。我发现在行业报告中很少有人使用催化、开放/Metis或Fusion等方法

（注意：不要误解我的意思；我很欣赏敏捷运动的价值和贡献。但我不是狂热的粉丝；我是一个