logo标签列表

敏捷开发

agilemethodology
8
在大学里我们谈论了敏捷编程，但是也讨论了许多敏捷方法在商业上并没有被使用，比如配对编程。
我想知道哪些方法属于敏捷编程（极限编程，配对编程），哪些真正被使用/你使用过。迭代和增量式开发呢？
编辑：对于那些想要关闭这个问题的人因为“主观和有争议性”的人。 这个问题可以回答，因为敏捷开发是一个定义明确的表达。 http://en.wikipedia.org/wiki/Agile_software_development。 此外，许多用户对此问题感兴趣，关闭它并不考虑周全。
我也很好奇这个问题的答案，因为我也正在开发一个涉及传统瀑布模型的应用程序。问题是，随着我们的开发，变更会不断出现。我们将其视为CR（变更请求）并重新进行范围定义，而不仅仅是接受变更。这是否意味着我正在加入一些敏捷的元素？ - bragboy
显然，我的公司正在开始采用敏捷方法。 我想任何方法都比瀑布方法好。 - ExitToShell
1
@Bragaadeesh：即使在敏捷开发中，你也不能接受所有的变化。你要朝着当前（附近）的目标前进，并且只有在达到目标后才接受变化。如果当前的变化完全破坏了当前目标，你可能会放弃当前目标，或者如果该部分尚未实现并且是当前目标的目标，则可以实施-次要-更改。 - SF.
@ExitToShell 如果你尝试一些基于无政府主义的开发（“敏捷开发，由认为敏捷意味着管理者什么都不做的管理者实施”），你会很快改变你的想法。 - SF.
@Closers 你能否解释一下这个问题中的主观和争议是什么？这太荒谬了。 - Pascal Thivent
11个回答
9
敏捷开发本身不是一种方法论，而是一个涵盖多种敏捷方法的总称（所有这些方法都属于迭代和增量开发 - IID - 家族）。
在2001年敏捷宣言签署时，以下方法被代表：极限编程（XP）、Scrum、DSDM、自适应软件开发（ASD）、Crystal、特征驱动开发（FDD）、实用编程。它们都分享敏捷宣言的核心价值观，但采用略有不同的方法来实现它们。

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

相比之下，配对编程是一种工程实践（它是XP的众多实践之一，作为不可分割的整体捕捉到，但你也可以在XP之外使用它）。虽然我非常重视实践，但请记住，实践并不是终点，它们只是手段，就像我以前写过的那样previously。 敏捷不是关于做配对编程、站立会议等等。敏捷是关于最大化客户价值，同时最小化浪费，提供最优ROI。敏捷是业务导向的，实践只是在特定上下文中实现这个目标的一种方式。

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

8

行业中最近的一些实证数据：

我刚刚看到了敏捷实践调查结果：2009年7月。虽然样本集比较小（123），但它提供了一些有趣的观点。例如，根据受访者报告，最有效的10个敏捷实践是：

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

还有关于以下方面的前十个敏捷实践的图表：

  • 被认为最容易学习。
  • 被认为最难学习。
  • 最可能尝试后放弃。
  • 人们想采用但尚未采用的。


实践不是重点

我们不是为了实践而实践。敏捷实践来自遵循敏捷原则，如宣言网站所解释的那样。最高的敏捷原则是：“通过及早和持续地交付有价值的软件来满足客户。” “早期”，“持续”和“有价值”是关键字。如果一个团队不了解这些原则如何推动实践，那么他们就有被像@Guildencrantz说的那样：盲目模仿，没有他们预期的神奇成功，宣布敏捷失败并放弃它的风险。

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

我手头没有好的引文，但通常认为在绿色项目上实施敏捷比将棕色项目转换为敏捷更容易。其中一个原因是现有代码通常以使添加自动化测试变得困难的方式编写。Michael Feathers写了一整本关于将测试添加到遗留代码的书。

7
听起来你真的想知道人们在现实世界中究竟在使用什么。关于什么是敏捷实践/方法论，有很多网站提供了相关信息。
以下是我最近五年工作经验中的情况：
1. 除非在紧急情况下（需要在零时间内修复重大错误），否则没有人会使用结对编程，管理者根本不相信这个想法 - 我说的是完全不相信，这很遗憾，因为我很喜欢这个想法。 2. 用户故事和用户选择下一个版本的 deck - 这并不真正奏效，除非用户真的非常非常认可，在我的领域，用户总是说一切都非常重要，他们不能没有任何东西。我个人会重新表述为“依据你的意见，我应该按照什么顺序处理这些任务？”。 3. 测试驱动开发 - 很少发生这种情况，但是有很多单元测试被编写出来（在代码之后），因此接近错过机会（在我看来）。 4. 持续集成 - 这高度依赖于团队，在过去的5年中，我所在的所有团队都拥有它，但通常会间断（构建失败）数天/数周，然后才会得到关注。仍有很多人不相信这个想法。 5. 经常重构 - 这实际上获得了一些认同。重构是一项技能，如果你没有它，很可能会成为一个严重的问题。 6. 小型发布 - 在我的工作中，��通常是规范，虽然可能正在进行中。 7. 编码标准 - 是的。 8. 集体代码拥有权 - 责怪依然很普遍，经常出现“糟糕”的模块从未被修复的情况，因为编写它的程序员只是不断地修复它，直到它“能用”。 9. 不加班 - 几乎实现了，但高度依赖于团队领导 - 我看到过最糟糕的事情（死亡行军）就在我的团队几英尺外进行...... 10. 发现错误时首先进行测试 - 在我的经验中，这种情况确实发生了。这是一件非常好的事情。
1
虽然这是你的经历，听起来相当糟糕。特别是第1点和第3点。但并不是每个地方都是这样。 - Finglas
我欣赏你自己的经验。是的，并不是每个团队或开发者都坚持理想的敏捷哲学。他们有自由选择哪些实践并拒绝其他实践的权利。 - Chao
3
大多数经验丰富的开发人员已经成为项目经理或IT主管。20年前，像敏捷软件开发这样的方法论甚至都不存在，但他们能够生产和交付工作系统。
这些人可能缺乏对这些新方法论提出的实践知识，从而导致某种程度上的抵制。我们不能对他们粗暴相待，他们只是抵制他们不知道或甚至不理解的变化，就像一个习惯于以某种方式工作的客户一样，然后我们用我们的新方法来改变这个客户的习惯！这种抵制很正常，这是人类行为。
此外，对于一些经验更丰富的人来说，他们不仅不明白成对工作的重点所在，例如。就像他们通常不相信scrum会议一样，他们更喜欢老派的方式，即每周会议持续1到2小时，这种方式在某种程度上取得了成功。
至于管理员，也就是负责编程资源预算的人，对于成对编程来说，他们认为支付一个无所事事的程序员，而这个无所事事的程序员可以在代码的另一部分上工作，以增加生产力。你也不能真正责怪他们，因为他们的想法是有道理的。
敏捷软件开发提出的一些建议比其他一些更容易获得好处。虽然成对编程可能在实践中并没有真正取得成功，或者每日的scrum会议，但我的经验表明，在我们获得足够精确的软件草图、要求和功能后，尽快开始编码是成功的关键，永远不要忘记客户本身给出的优先级。然后，在开发迭代过程中更新UML分析。
在我的经验中，软件迭代开始取得了越来越多的成功。
让时间来证明，敏捷软件开发，如测试驱动开发，在我所在的地区仍然是新的东西。一旦他们拥有更多的从业者，他们的实践将随之增长，我相信。
第一个Scrum实现是在1993年由Easel Corporation运行的。 - Pascal Thivent
是的，在美国。但例如，一些公司仍在使用旧的AS400或VAX，因此比1993年更老。一旦一种方法在公司内运作，就很难放弃它去尝试另一种被认为更有前途的新方法。人们会怀疑。一旦某事有效，为什么要改变它呢？如果没有出现问题，就不要修复它。这就是全部。 - Will Marcouiller
有些人甚至不会注意到什么东西已经坏了。他们只会认为失败的痛苦是“正常”的 - 因为他们从未见过一个正确、工作良好的版本是什么样子... - Dafydd Rees
3
这取决于公司的情况。我所在的公司全部采用测试驱动开发（TDD）、配对编程、持续集成（CI）等技术。团队不会让你提交代码，但没有提交单元测试或FitNesse测试的情况下就通过了。你提交代码后不到一分钟，CI服务器就会运行整套测试，如果你的代码破坏了构建或任何测试失败，灯光将闪烁并标记你是破坏构建的人。
虽然这不是最常见的情况，但确实有公司真正实践敏捷开发。
我现在在我的第二家公司，他们的敏捷开发实践方式与你描述的非常接近。我认为最重要的是要记住宣言中的理念。所有其他的东西只是帮助你达到这些目标的工具而已。如果任何敏捷“实践”成为了阻碍，那么你需要重新考虑它们。 - Matt
1

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

换句话说，极限编程、Scrum等都是基于敏捷原则的敏捷方法论。深入了解这些内容将会回答你的问题。

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

1

Thoughtworks是实行敏捷开发的公司之一。你可以直接从Martin Fowler的网站上了解更多关于敏捷开发的内容。

1
在商业领域，我认为通常会看到团队从不同的编程方法中选择他们喜欢的方面，并将它们结合到自己的实践中。然后他们可能会使用任何他们想要的术语，即使它不是100％准确。
在我们的团队中，我们每天进行站立会议和团队编程（大约占一半时间-取决于任务）。虽然我们不声称自己是敏捷的。
1
  • Scrum非常流行（尽管它只是一种管理技术而不是技术学科）
  • 极限编程不太流行，但确实有应用。（我做过很多商业XP项目-虽然很难找到想要做XP的团队。）
  • 测试驱动开发（TDD）是XP的一部分，尽管许多人这样做（还有更多人说他们这样做...）

许多人似乎误解了重构、配对编程和自组织团队的概念...这些对于那些从瀑布式开发中获得成功并已经根深蒂固的人来说可能很困难。让这些人尝试XP是一个问题。

1

正如其他人所提到的，敏捷是一个大伞词，可以以多种不同的方式实施；尽管如此，敏捷当前的流行状态导致许多公司试图实施敏捷，但实际上只是实施了一套类似于货柜崇拜的程序，并期望敏捷的灵活性。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接