敏捷开发

Question

在大学里,我们谈到了敏捷编程,但也讨论了在业务中没有使用多少敏捷方法,比如结对编程.

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

编辑:由于"主观和议论"而想要关闭该问题的人.这个问题可以回答,因为敏捷开发是一种定义的表达. http://en.wikipedia.org/wiki/Agile_software_development.更多的用户对此问题感兴趣,关闭它并没有得到很好的考虑

Answer 1

敏捷开发本身并不是一种方法论,它是一个描述几种敏捷方法的总称,它们都属于迭代和增量开发 - IID系列.

替代文字http://img62.imageshack.us/img62/6374/dd997578teamprojagileum.png

在2001年签署敏捷宣言时,代表了以下方法:极限编程(XP),Scrum,DSDM,自适应软件开发(ASD),水晶,特征驱动开发(FDD),语用编程.他们每个人都拥有敏捷宣言的核心价值观,但他们采用略有不同的方法来实施.

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

Scrum和XP(一起使用)是目前最常用的.

Answer 2

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

所以,我迄今为止(最近5年)角色的经历:

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

Answer 3

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

我刚刚看到了敏捷实践调查结果:2009年7月.这是一个相当小的样本集(123),但它提供了一些有趣的视角.例如,前10个最有效的敏捷敏捷实践(由受访者报告)是:

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

还有前10个敏捷实践的图表:

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

实践不是重点

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

在新项目上实现敏捷比将项目转换为敏捷更容易:

我手边没有很好的引用,但一般认为在绿地项目上比在将棕色地带项目转换为敏捷方面更敏捷.其中一个原因是现有代码通常以难以添加自动化测试的方式编写.Michael Feathers写了一本关于为遗留代码添加测试的书.

Answer 4

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

换句话说，极限编程、Scrum等都是基于敏捷原则的敏捷方法论。深入检查这些将回答您的问题。

至于敏捷本身，以及所有这些类型的敏捷开发的共同点，请查看维基百科以获得很好的概述。