敏捷开发

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时，代表了以下方法：极限编程（XP），Scrum，DSDM，自适应软件开发（ASD），水晶，特征驱动开发（FDD），语用编程。他们每个人都分享敏捷宣言的核心价值观，但采用略有不同的方法来实施。

相比之下，结对编程是工程实践（它是XP的一种实践，它将many practices捕获为不可分割的集合，但您可以使用它在XP之外）。而且，虽然我非常重视实践，但请记住，实践不是目的，它只是我写previously时的意思。 敏捷不是要进行结对编程，站立会议等。敏捷是关于最大化客户价值，同时最大限度地减少浪费，以提供最佳的投资回报率。敏捷是面向业务的，实践只是在给定环境中实现这一目标的一种方式。

Scrum和XP（一起使用）是目前最常用的。

Answer 2

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

所以，我迄今为止（最近5年）角色的经历：

1. 没有人使用结对编程，除非在恐慌情况下（零时间内的主要错误修复），管理者仍然根本不会接受这个想法 - 而且我正在谈论所有，这是一种耻辱，因为我非常喜欢它
2. 用户故事和用户选择下一个版本的套牌 - 除非用户真的真的买进，否则它们确实没有用，我还没有看到。我所在地区的用户总是说一切都是最重要的，他们不能没有任何东西。我个人只是改写一下“你认为我个人应该按照这些任务的顺序做什么？”。
3. 测试驱动的开发 - 这种情况很少发生，但很多单元测试都会被编写（尽管代码确实如此），所以接近错过imho
4. 持续集成 - 这在很大程度上依赖于团队，在过去的5年中，我的所有团队都拥有它，但它经常在被注意之前的几天/几周内失效（破坏构建）。很多人还是不买这个。
5. 经常重构 - 这实际上得到了一些认真的支持。重构是一项技能，如果你没有，可能是一个严重的问题。
6. 小版本 - 这（在我的工作中）通常是常态，尽管可能已经完成
7. 编码标准 - 是的
8. 集体代码所有权 - 责任仍然非常普遍，并且通常一个“坏”模块永远不会真正得到解决，因为制作它的编码器只是修复并修复它直到它“工作”。
9. 没有加时赛 - 几乎，但高度依赖于球队领先 - 我已经看到了在我的球队几英尺内发生的最糟糕的事情（死亡游行）......
10. 在发现错误时首先进行测试 - 这种情况发生在我的经验中。是一件非常好的事。

Answer 3

关于行业使用实践的最新实证数据：

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

1. 持续集成
2. 每日站立会议
3. 开发者TDD
4. 迭代计划
5. 代码重构
6. 回顾会议
7. 结对编程
8. 积极的利益相关者参与
9. 潜在可运送软件
10. Burndown Tracking

还有十大敏捷实践的图表：

• 被认为是最容易学习的。
• 被认为是最难学的。
• 最有可能被审判然后被抛弃。
• 人们想采用但还没有完成。


实践不是重点

我们不会为了这种做法而采取这种做法。如agile principles所述，敏捷实践遵循manifesto website。最敏捷的原则是：“通过早期和持续交付有价值的软件来满足客户”。 早期，连续和有价值是那里的关键词。如果一个团队不理解这些原则如何推动这些实践，那么就像@Guildencrantz所说的那样，他们冒着存货的风险，没有他们期望的魔术成功，宣称敏捷失败，并放弃它

在新项目上比在项目转换为敏捷方面更容易敏捷：

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

Answer 4

大多数经验丰富的开发人员从此成为项目经理或IT主管。那时，大约20年前，敏捷软件开发等方法甚至都不存在，他们能够生产和交付工作系统。

这些同样的人可能缺乏这些新方法所提出的实践知识，因此会对这些方法提出某种阻力。

我们不能粗暴对待他们，他们只能抵制他们不知道甚至不理解的变化，就像让我们说一个习惯于单向工作的客户，然后我们带来我们的新方法然后在一天之内改变这个顾客的习惯！这些抵抗发生是很正常的，它们是人类的行为。

此外，对于这些经验丰富的人中的一些人来说，他们并不只是没有得到成对的工作点，例如。就像他们一般不相信scrum会议一样，他们更喜欢以某种方式取得成功的老派方式，即每周1到2小时的会议。

对于那些负责编程资源预算的管理员来说，对于结对编程，可以看到程序员无所事事，而这个无所事事的程序员可以在另一部分代码上工作以提高生产率。你不能真的责备他们，因为他们的想法充满了意义。

与其他人相比，敏捷软件开发的一些建议更容易获得好处。虽然结对编程可能在实践中甚至不是每天的scrum会议上都知道真正的成功，但是根据我的经验，只要我们获得足够精确的软件草图，其要求和功能，就会开始编码，从不忘记客户自己给出的优先事项。然后，在开发迭代时更新UML分析。

根据我的经验，软件迭代开始取得越来越大的成功。

让时机一点，敏捷软件开发，例如测试驱动开发，在我所在的地区，仍然是新的东西。一旦他们将获得更多的从业者，我相信他们的实践经验会随之增长。

Answer 5

这取决于公司对公司。我在一家公司工作，所有TDD，所有配对，所有CI，所有的时间。如果你提交代码，团队并不害怕给你打电话，但是没有提交单元/ FitNesse测试，提交代码后不到一分钟，CI服务器运行整套测试，如果你的代码打破构建或者Amy的测试失败，灯光熄灭，你被标记为打破构建的那个。

这不是最常见的情况，但那里的是公司真正实践敏捷。

Answer 6

敏捷方法是敏捷开发的基础。

换句话说，eXtreme Programming，Scrum等基于敏捷原则的敏捷方法论。深入查看这些内容将回答您的问题。

至于敏捷本身，以及所有这些敏捷开发的共同点，请查看Wikipedia以获得一个很好的概述。

Answer 7

Thoughtworks是拥有敏捷开发权的公司之一。从Martin Fowler's网站直接阅读有关敏捷开发的更多信息。

Answer 8

在商业领域，我认为您通常会看到团队从不同的编程方法中学习他们喜欢的方面，并将它们结合到自己的实践中。他们可能会应用他们想要的任何术语，即使它不是100％准确。

在我们的团队中，我们应用每日站立和团队编程（大约一半的时间 - 取决于任务）。我们并不声称做敏捷。

Answer 9

• Scrum非常受欢迎（虽然它只是一种管理技术而非技术学科）
• 极端编程虽然很有用，但却不太受欢迎。 （我已经完成了许多商业XP项目 - 虽然很难找到想要做XP的团队。
• 测试驱动开发（TDD）是XP的一部分，虽然很多人都这样做（而且还有很多人说他们这样做了）。

许多人似乎误解了重构，结对编程和自组织团队的一般概念等概念......对于那些从瀑布中取得一定成功并且以这种方式得到根深蒂固的人来说，这些很难实现做事。让这些人尝试使用XP是一个问题。

Answer 10

正如其他人所说，敏捷是一个总括性术语，可以通过多种不同方式实施;据说敏捷目前的流行语状态导致许多公司试图实施敏捷实际上只是实施一套cargo cult-esque程序并期望敏捷的灵活性。

Answer 11

在我以前的公司里，经理们抓住了敏捷，就像他们解决所有问题一样。但它唯一能做的就是制造更多问题。

我们定期召开会议，称为“立式会议”（某种敏捷术语）。

我认为他们尝试了很多敏捷技术，但当时对我们来说效果并不好。