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

Question

最近我对敏捷方法很感兴趣，找到了很多方法的处方和对许多实践的详细描述。尽管如此，我仍然记得我最好的项目是从运行到完成的峰值，然后是一些调试和最少的测试，然后才能上线。

我一直在问自己，Flickr是否使用了敏捷方法？Facebook实践TDD吗？Gmail是不是在25分钟的时间跨度里，然后是5分钟的白日梦？

换句话说，在我进一步听完所有的说教并进入手册之前，我得到了什么证据来证明这是在一个成功的公司中成功项目的方法？

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

Answer 1

这是我的一个成功的项目：

在每周向内容管理服务器和站点背后的服务器提供一些months.

• Delivered新功能后，
• 上线了--通常每周部署一次。
• 完成了所有极限编程week演示，以便客户每周进行迭代。

这里有另一个敏捷项目(也是严格使用XP完成的)，也取得了巨大的成功：

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

• Banking用于在纽约、伦敦、巴黎和东京的投资银行站点中清理和分发固定收益数据的系统。我相信整个项目在几个years.
• Mobile Data的过程中只发生了一次生产事件，这是一个为移动网络和手机制造商配置手机和PDA的系统。我们在多年的时间里逐步构建了核心产品，并在世界各地的三个地点协调了工作。所有这些都是使用极限编程完成的。客户是移动业务中一些最大的公司。我们的应用程序为其中一些客户端提供了全球支持。

我真的不会再回到以前的做法了--赞助我上面提到的项目的客户也不会。

Answer 2

一个相关的问题是，有多少非敏捷项目(瀑布，“前期大设计”等)是成功的？根据我的经验，不是很多。事实上，我刚刚完成了一个两阶段的项目，其中第一阶段是传统的瀑布，失败了很多，但第二阶段本质上是迭代的，并产生了更好的结果(按时，缺陷少得多，最终结果比原始规范更接近客户的实际需求)。

我从事敏捷开发已经有几年了，总的来说，我发现它比其他方法更好。我注意到了几件事：

1. 敏捷!=“无进程”。敏捷是指只有你需要的过程，并不断地改进这个过程。
2. 敏捷需要纪律。你不仅要有一个过程，还要遵循它。
3. 敏捷不会把失败的项目变成成功的。它可以帮助您确定项目失败的时间越早越好，并帮助您找出失败的原因。这是关于缩短反馈循环，以便你有机会在为时已晚之前回到正轨。

微软研究院最近在posted an article中对一些敏捷方法进行了经验评估。它非常值得一读，可能会提供一些你正在寻找的信息。

Answer 3

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

如果你计划在某件事上进行开发，在决定哪件事最适合你的计划之前，最好对所有方面都进行检查。

因此，简短的答案是:视情况而定。