使用敏捷方法的成功项目？

Question

我最近对敏捷方法很感兴趣，并且发现了大量处方和很多实践的细微描述。 不过，我记得我最好的项目是运行到完成峰值，然后是一些调试和最小化测试才能上线。

我一直在问自己，Flickr是否使用敏捷方法？ Facebook是否实行TDD？ Gmail是在25分钟的跨度中制作，然后是5分钟的白日梦吗？

换句话说，在我进一步倾听所有讲道并跳到手册之前，我有什么证据表明这是成功公司成功项目成功的方法？

当然，我问这个是因为我想阅读答案，而不是因为我想驳回一个论点。

Answer 1

一个相关的问题是，有多少非 -Agile（瀑布，“Big Design Up Front”等）项目成功了？根据我的经验，并不多。事实上，我刚刚推出了一个两阶段项目，其中第一阶段是传统的瀑布并且失败相当显着，但第二阶段本质上是迭代的并且产生了更好的结果（按时，缺陷少得多，最终结果更接近根据客户的实际需求而不是原始规格。

我几年来一直在进行敏捷开发，总的来说，它发现它优于其他选择。我注意到的一些事情：

1. 敏捷！=“没有过程”。敏捷就是拥有尽可能多的流程，并不断完善这一流程。

2. 敏捷需要纪律。您不仅必须拥有流程，还必须关注。

3. 敏捷不会让失败的项目成功。它可以帮助您识别项目是否早晚失败，并帮助您找出为什么失败。这是关于缩短反馈循环，以便你有机会在太晚之前重新开始。

Microsoft Research最近posted an article，他们根据这些经验评估了一些敏捷方法。这非常值得一读，可能会提供您正在寻找的一些信息。

Answer 2

在大多数大公司（例如IBM）中，方法并不总是相同的，敏捷或理性或瀑布。这取决于项目的大量历史以及当前人员和项目经理的经验。

如果您计划在某些事情上发展，那么在决定哪种方案最适合您的计划之前，最好先检查所有方面。

所以简短的回答是：这取决于。

Answer 3

以下是我的一个成功项目：http://www.sky.com

• 几个月后活了。
• 每周向网站后面的CMS和服务器提供新功能 - 部署通常每周一次。
• 所有极端编程学科都完成了。
• 每周向客户演示以进行每周迭代。

这是另一个敏捷项目（也严格使用XP），也取得了巨大成功：http://showbiz.sky.com/

我还参与了另外两个成功的XP项目：

• 银行业在纽约，伦敦，巴黎和东京的投资银行网站上清理和分发固定收益数据的系统。我相信整个项目在几年内只发生了一次生产事件。
• 移动数据为移动网络和手机制造商配置移动电话和PDA的系统。我们多年来逐步建立核心产品，并协调全球三个地点的工作。全部使用极端编程完成。客户是移动业务中最大的公司之一。我们的应用程序为其中一些客户提供了全球支持。

我真的不会回到原来的做事方式 - 赞助我上面提到的项目的客户也不会。

Answer 4

我的产品（Sophos Email Appliance）是使用敏捷方法开发的。 Joshua Kerievsky所支持的工业极限编程在最初几年的开发中得到了应用。最近，我开始将团队更多地转向看板，可视化工作流程并使用基于拉的调度而不是时间盒迭代。

Answer 5

  

换句话说，在我进一步倾听所有讲道并跳到手册之前，我有什么证据表明这是成功公司成功项目成功的方法？

empirical evidence大多数IT项目都没有成功（成功意味着按时，按预算和完全正常运行）。鉴于这一证据，似乎有理由怀疑确定性方法（瀑布）是否适合软件项目。

  

“精神错乱的定义是一遍又一遍地做同样的事情并期待不同的结果。” - Albert Einstein Rita Mae Brown ¹

如果确定性过程一次又一次地产生故障，我们可能不会将正确的过程应用于软件开发项目，而敏捷方法 则是替代方案。这些方法背后的理论是，大多数软件项目不是确定性的，它们是创造性的（如艺术中）和复杂的（由Ralph Stacey项目定义），我们无法预测一切。因此，我们应该使用自适应过程，而不是试图预测一切然后反对变化。这就是敏捷方法的意义所在。

现在，使用敏捷方法永远不会保证系统成功（并且有人声称反向是骗子），但他们会让你更好地控制风险。并且，如果您的项目必须失败，它至少会快速失败。

更新： ¹ 实际上，这个报价似乎被误解为阿尔伯特爱因斯坦。最早的已知事件和可能的起源引用Rita Mae Brown。

Answer 6

我相信Doublefine只使用Scrum制作了残酷的传奇。

Answer 7

据我所知，StackOverflow是一个使用敏捷实践和TDD构建的成功网站。