敏捷开发

Question

在大学里，我们谈到了敏捷编程，但也谈到了有多少敏捷方法没有在商业中使用，比如结对编程。

我想知道哪些方法属于敏捷编程(极限编程，结对编程)，哪些方法是真正使用的/你们使用的。那么迭代和增量开发呢？

编辑:致那些因为“主观和争辩”而想要结束这个问题的人。这个问题是可以回答的，因为敏捷开发是一个定义好的表达。http://en.wikipedia.org/wiki/Agile_software_development。此外，许多用户对这个问题感兴趣，关闭它并没有经过深思熟虑

Answer 1

敏捷开发本身并不是一种方法论，它是一个总括的术语，描述了几种敏捷方法论(它们都属于迭代和增量开发- IID家族)。

alt text http://img62.imageshack.us/img62/6374/dd997578teamprojagileum.png

在Agile Manifesto in 2001的签署上，代表了以下方法论: eXtreme编程(XP)，Scrum，DSDM，自适应软件开发，水晶，特征驱动开发，实用编程。他们中的每一个都共享敏捷宣言的核心价值，但实现它们的方法略有不同。

相比之下，结对编程是一种工程实践(它是XP的实践之一，它将many practices捕获为一个不可分的集合，但您可以在XP之外使用它)。而且，虽然我非常重视实践，但请记住，实践并不是目的，在我写previously时，它们只是一种手段。敏捷不是关于进行结对编程，站立会议等。敏捷是关于最大化客户价值，同时最小化浪费，以提供最优的ROI。敏捷是面向业务的，实践只是在给定的上下文中实现这一目标的一种方式。

Scrum和XP (一起使用)是当今最常用的。

Answer 2

听起来你真的很想知道人们在现实世界中实际使用的是什么。有很多关于敏捷实践/方法中的内容和不是的内容的站点。

因此，到目前为止，我在最近(最近5年)的角色中的经验是：

1. 没有人使用结对编程，除非在恐慌的情况下(在零时间内修复了主要的错误)，经理们仍然根本不相信这个想法-我说的是根本，这是一种遗憾，因为我很喜欢它。
2. 用户故事和用户选择下一版本的卡片组-除非用户真的真的相信，否则不会真正起作用，这我还没有看到。我所在地区的用户总是说，一切都是最重要的，他们离不开任何东西。我个人只是重新表述为“在你的opinion?".
3. Test驱动的开发中，我个人应该按照什么样的顺序来处理这些任务--很少会发生这种情况，但会编写很多单元测试(在代码完成之后)，所以几乎没有imho
4. Continuous集成-这高度依赖于团队，在过去的5年里，我所有的团队都有它，但在它引起注意之前，它经常会失效几天/几周。许多人仍然不经常购买this.
5. Refactoring -这实际上是一些认真的购买。重构是一项技能，如果你没有，这很可能是一个严肃的problem.
6. Small版本--这(在我的工作中)通常是规范的，尽管可能已经完成了yes
7. Collective代码所有权-
8. 编码标准-责任仍然非常普遍，而且通常一个“糟糕”的模块永远不会得到真正的修复，因为生成它的程序员只是不断地修复它，直到它“工作”。
9. 没有超时-几乎。但是高度依赖团队领导--当我发现bug的时候，我已经看到最糟糕的事情(死亡行军)发生在离我的team...
10. Tests只有几英尺远的地方--在我的经验中会发生这种情况。是一件非常好的事情。

Answer 3

关于在行业中使用的实践的一些最新经验数据：

我刚刚遇到了Agile Practices Survey Results: July 2009。这是一个相当小的样本集(123)，但它提供了一些有趣的观点。例如，最有效的10个敏捷实践(根据受访者的报告)是：

可发货Meeting

• Developer跟踪计划<>G222<

1. >G222<

><

1. ><
2. >G222<>G222<
   1. >G222<

   >

   1. Stand Up Participation
      1. Potentially TDD Tracking
      2. Stand Up TDD
      3. Iteration
      4. code Tracking Refactoring
      5. Retrospectives
      6. Pair Programming
      7. Active Participation
      8. Potentially Shippable Software
      9. Burndown Tracking

还有排名前十的敏捷实践的图表：

• 被认为是最容易学习的。
• 被认为是最难学的。
• 最有可能被尝试，然后

想要采用，但还没有开始。

实践不是重点

我们不是为了实践而做实践。敏捷实践源于遵循manifesto website上解释的agile principles。最高的敏捷原则是：“通过早期和持续交付有价值的软件来满足客户”。早期、持续和有价值是那里的关键词。如果一个团队不理解这些原则是如何驱动实践的，那么他们就有可能像@Guildencrantz所说的那样，成为货物狂热的信徒，没有他们期望的神奇子弹般的成功，宣布敏捷是失败的，然后放弃它。

在新项目中保持敏捷比将项目转换为敏捷要容易得多：

我手头没有一个很好的引用，但人们通常认为在greenfield projects上实现敏捷比将brownfield project转换为敏捷更容易。其中一个原因是，现有代码通常以一种难以添加自动化测试的方式编写。Michael Feathers写了一整本关于向遗留代码添加测试的书。