A related question is, how many non-Agile (Waterfall, "Big Design Up Front", etc) projects are successful? In my experience, not many. In fact, I just rolled off a two-phase project in which the first phase was traditional Waterfall and failed pretty significantly, but the second phase was iterative in nature and yielded substantially better results (on time, far fewer defects, end result was closer to client's actual needs than the original spec).
I've been doing Agile development for a few years now and, overall, have found it to be superior to the alternative. A few things I've noticed:
Agile != "no process". Agile is about having only as much process as you need and continually refining that process.
Agile requires discipline. You not only have to have a process, you have to follow it.
Agile won't turn a failing project into a success. It can help you identify that the project is failing sooner rather than later, and help you figure out why it's failing. It's about shortening the feedback loop so that you have a chance to get back on course before it's too late.
Microsoft Research recently posted an article in which they empirically evaluate some Agile methods. It's well worth a read and might provide some of the information you're looking for.
Delivered new functionality to the CMS and servers behind the site weekly - with deployments typically every week or so.
All done with all the extreme programming disciplines.
Weekly demos to the customer to go with the weekly iterations.
Here's another agile project (also done strictly with XP), also a big success: http://showbiz.sky.com/
I've also worked on two other successful XP projects:
Banking A system for cleaning up and distributing fixed income data across investment bank sites in NY, London, Paris and Tokyo. I believe the whole project only had one production incident over the course of a few years.
Mobile Data A system for configuring mobile phones and PDAs for mobile networks and handset manufacturers. We built the core product incrementally over a number of years and co-ordinated the work over three sites across the world. All done using extreme programming. Customers were some of the largest companies in the mobile business. Our apps provided global support for some of these clients.
I really wouldn't go back to the old way of doing things - and neither would the customers that sponsored the projects I've mentioned above.
In most of the big companies (IBM for instance), the methodology is not always the same, Agile or Rational or Waterfall. That depends in a lot of the history of the projects and the experience of the current People and Project Managers.
If you plan to develop on something is always good to check on all the sides before deciding what suits best for your plan.
My product (the Sophos Email Appliance) is developed using agile methods. Industrial Extreme Programming, as espoused by Joshua Kerievsky, was used for the first several years of development. Recently I have started to move the team more towards Kanban, visualizing work flow and using pull-based scheduling instead of time-boxed iterations.
更新：1 实际上，这句话似乎被错误地归因于阿尔伯特·爱因斯坦。已知最早的事件和可能的起源，引用了Rita Mae Brown。
In other words, before I listen further to all the preaching and jump into the manuals, what evidence do I get that this is the way to be successful in a successful project in a successful company?
There is empirical evidence that most IT projects are not successful (where success means on time, on budget and fully functional here). Given this evidence, it seems reasonable to wonder if a deterministic approach (the waterfall) is well suited for software projects.
"The definition of insanity is doing the same thing over and over and expecting different results." --Albert EinsteinRita Mae Brown1
If a deterministic process produces failures over and over, we are likely not applying the right process for software development projects and Agile methods are an alternative. The theory behind these methods is that most software projects are not deterministic, they are creative (like in art) and complex (as defined by Ralph Stacey) projects and we can't predict everything. So, instead of trying to predict everything and then fighting against change, we should use an adaptive process. And this is what Agile methods are about.
Now, using an Agile method will never guarantee systematic success (and someone claiming the inverse is a liar) but they'll give you better control over the risks. And, if your project has to fail, it will at least fail fast.
Update:1 Actually, this quotation seems to be misattributed to Albert Einstein. The earliest known occurrence, and probable origin, cites to Rita Mae Brown.
发布评论
评论（7）
一个相关的问题是，有多少非敏捷（瀑布式、“预先进行大设计”等）项目是成功的？以我的经验来看，并不多。事实上，我刚刚推出了一个两阶段项目，其中第一阶段是传统的瀑布式项目，失败相当严重，但第二阶段本质上是迭代的，并产生了更好的结果（准时，缺陷少得多，最终结果更接近）以满足客户的实际需求而不是原始规格）。
我从事敏捷开发已经有几年了，总的来说，我发现它优于其他方法。我注意到了一些事情：
敏捷！=“无流程”。敏捷就是只拥有您需要的流程，并不断完善该流程。
敏捷需要纪律。您不仅需要拥有流程，还必须遵循它。
敏捷不会将失败的项目变成成功。它可以帮助您尽早发现项目失败，并帮助您找出失败的原因。这是关于缩短反馈循环，以便您有机会在为时已晚之前回到正轨。
微软研究院最近发表了一篇文章，其中他们根据经验进行了研究评估一些敏捷方法。它非常值得一读，并且可能会提供您正在寻找的一些信息。
A related question is, how many non-Agile (Waterfall, "Big Design Up Front", etc) projects are successful? In my experience, not many. In fact, I just rolled off a two-phase project in which the first phase was traditional Waterfall and failed pretty significantly, but the second phase was iterative in nature and yielded substantially better results (on time, far fewer defects, end result was closer to client's actual needs than the original spec).
I've been doing Agile development for a few years now and, overall, have found it to be superior to the alternative. A few things I've noticed:
Agile != "no process". Agile is about having only as much process as you need and continually refining that process.
Agile requires discipline. You not only have to have a process, you have to follow it.
Agile won't turn a failing project into a success. It can help you identify that the project is failing sooner rather than later, and help you figure out why it's failing. It's about shortening the feedback loop so that you have a chance to get back on course before it's too late.
Microsoft Research recently posted an article in which they empirically evaluate some Agile methods. It's well worth a read and might provide some of the information you're looking for.
这是我的一个成功项目：http://www.sky.com
这是另一个敏捷项目（也严格使用 XP 完成），也取得了巨大成功：http://showbiz.sky .com/
我还参与了另外两个成功的 XP 项目：
我真的不会回到旧的做事方式 - 赞助我上面提到的项目的客户也不会。
Here's a successful project of mine: http://www.sky.com
Here's another agile project (also done strictly with XP), also a big success: http://showbiz.sky.com/
I've also worked on two other successful XP projects:
I really wouldn't go back to the old way of doing things - and neither would the customers that sponsored the projects I've mentioned above.
在大多数大公司（例如 IBM）中，方法并不总是相同的，敏捷、理性或瀑布。这很大程度上取决于项目的历史以及当前人员和项目经理的经验。
如果您计划开发某项内容，那么在决定什么最适合您的计划之前，最好先检查各个方面。
所以简短的答案是：这取决于。
In most of the big companies (IBM for instance), the methodology is not always the same, Agile or Rational or Waterfall. That depends in a lot of the history of the projects and the experience of the current People and Project Managers.
If you plan to develop on something is always good to check on all the sides before deciding what suits best for your plan.
So the short answer is: It depends.
我的产品（Sophos Email Appliance）是使用敏捷方法开发。 Joshua Kerievsky 所倡导的工业极限编程被用于开发的最初几年。最近，我开始让团队更多地转向看板，可视化工作流程并使用基于拉动的调度而不是时间盒迭代。
My product (the Sophos Email Appliance) is developed using agile methods. Industrial Extreme Programming, as espoused by Joshua Kerievsky, was used for the first several years of development. Recently I have started to move the team more towards Kanban, visualizing work flow and using pull-based scheduling instead of time-boxed iterations.
经验证据表明大多数 IT 项目都不成功（成功意味着按时、符合预算且功能齐全）。鉴于这一证据，我们有理由怀疑确定性方法（瀑布）是否非常适合软件项目。
如果确定性过程一次又一次地产生失败，我们很可能没有为软件开发项目和敏捷方法应用正确的过程是一种替代方案。这些方法背后的理论是，大多数软件项目都不是确定性的，它们具有创造性（如艺术）且复杂（如Ralph Stacey) 项目，我们无法预测一切。因此，我们不应该尝试预测一切，然后与变化作斗争，而应该使用适应性过程。这就是敏捷方法的意义所在。
现在，使用敏捷方法永远无法保证系统的成功（有人声称相反的方法是骗子），但它们会让您更好地控制风险。而且，如果你的项目必须失败，它至少会很快失败。
更新： 1 实际上，这句话似乎被错误地归因于阿尔伯特·爱因斯坦。已知最早的事件和可能的起源，引用了Rita Mae Brown。
There is empirical evidence that most IT projects are not successful (where success means on time, on budget and fully functional here). Given this evidence, it seems reasonable to wonder if a deterministic approach (the waterfall) is well suited for software projects.
If a deterministic process produces failures over and over, we are likely not applying the right process for software development projects and Agile methods are an alternative. The theory behind these methods is that most software projects are not deterministic, they are creative (like in art) and complex (as defined by Ralph Stacey) projects and we can't predict everything. So, instead of trying to predict everything and then fighting against change, we should use an adaptive process. And this is what Agile methods are about.
Now, using an Agile method will never guarantee systematic success (and someone claiming the inverse is a liar) but they'll give you better control over the risks. And, if your project has to fail, it will at least fail fast.
Update: 1 Actually, this quotation seems to be misattributed to Albert Einstein. The earliest known occurrence, and probable origin, cites to Rita Mae Brown.
我相信 Doublefine 刚刚使用 Scrum 制作了《Brutal Legend》。
I believe Doublefine just produced Brutal Legend using Scrum.
据我了解，StackOverflow 是一个通过敏捷实践和 TDD 构建的成功网站。
From what I understand StackOverflow is a successful website built with agile practices and TDD.