在大学里我们讨论了敏捷编程，但也讨论了有多少敏捷方法没有在商业中使用，比如结对编程。
我想知道哪些方法属于敏捷编程（极限编程、结对编程）以及哪些方法是真正使用/你使用的。迭代和增量开发怎么样？
编辑：对于那些因为“主观和争论”而想要结束该问题的人。
这个问题是可以回答的，因为敏捷开发是一种定义好的表达方式。
http://en.wikipedia.org/wiki/Agile_software_development。
此外，更多用户对此问题感兴趣，关闭它并没有得到很好的考虑
At university we talked about agile programming, but also how many agile methods aren't used in business, like pair programming.
I would like to know which methods belong to agile programming (extreme programming, pair programming) and which are really used / do you use. What about iterative and incremental development?
edit: to those who wanted to close that Question because of "subjective and argumentative".
This question can be answered,because agile development is a defined expression.
http://en.wikipedia.org/wiki/Agile_software_development.
Further more many Users are interested in this Question, to close it isn't well considered
发布评论
评论（11）
敏捷开发本身并不是一种方法，它是一个总括术语，描述了几种敏捷方法（它们都属于迭代和增量开发 - IID - 系列）。
替代文本 http://img62.imageshack.us/img62/6374/dd997578teamprojagileum.png< /a>
在2001 年敏捷宣言的签署中，提出了以下方法：极限编程（ XP)、Scrum、DSDM、自适应软件开发 (ASD)、Crystal、功能驱动开发 (FDD)、实用编程。他们每个人都共享敏捷宣言的核心价值观，但实施方法略有不同。
相反，结对编程是一种工程实践（它是 XP 的实践之一，它捕获许多做法作为不可分割的集合，但您可以在 XP 之外使用它）。而且，虽然我非常重视实践，但请记住，实践不是目的，它们只是我写的一种手段 以前。 敏捷不是结对编程、站立会议等。敏捷是最大化客户价值，同时最小化浪费，以提供最佳的投资回报率。敏捷是面向业务的，实践只是在给定环境下实现这一目标的一种方式。
Scrum 和 XP（一起使用）是当今最常用的。
Agile development is not a methodology in itself, it's an umbrella term that describes several agile methodologies (that all belong to the Iterative and Incremental Development - IID - family).
alt text http://img62.imageshack.us/img62/6374/dd997578teamprojagileum.png
At the signing of the Agile Manifesto in 2001, the following methodologies were represented: eXtreme Programming (XP), Scrum, DSDM, Adaptive Software Development (ASD), Crystal, Feature-Driven Development (FDD), Pragmatic Programming. Each of them share the core values of the Agile Manifesto but implement them with a slightly different approach.
In contrast, pair programming is an engineering practice (it is one of the practices of XP which captures many practices as an indivisible set but you can use it outside of XP). And, while I value practices very much, just keep in mind that practices are not an end, they are just a mean as I wrote previously. Agile is not about doing pair programming, stand up meetings, etc. Agile is about maximizing the customer value while minimizing waste to provide the most optimal ROI. Agile is business oriented, practices are just a way to achieve this goal in a given context.
Scrum and XP (used together) are the most commonly used nowadays.
关于行业中使用的实践的一些最新经验数据：
我刚刚看到敏捷实践调查结果：2009 年 7 月。这是一个相当小的样本集 (123)，但它提供了一些有趣的视角。例如，前 10 名最有效的敏捷实践（根据受访者的报告）是：
还提供了前 10 名敏捷的图表实践：
实践不是重点
我们不会为了实践而实践。敏捷实践源于遵循敏捷原则，如宣言网站。敏捷的最高原则是：“通过尽早、持续地交付有价值的软件来满足客户”。 早期、持续和有价值是其中的关键词。如果一个团队不理解原则如何驱动实践，那么他们就会冒着成为货物崇拜者的风险，正如 @Guildencrantz 所说，没有获得他们期望的神奇成功，宣布敏捷失败，并放弃它。
在新项目上保持敏捷比将项目转换为敏捷更容易：
我手头没有很好的引用，但通常认为在 绿地项目，而不是转换棕地项目转向敏捷。原因之一是现有代码的编写方式通常很难添加自动化测试。 Michael Feathers 写了一本关于向遗留代码添加测试的书。
Some Recent Empirical Data About Practices in Use in Industry:
I just came across the Agile Practices Survey Results: July 2009. It's a fairly small sample set (123), but it offers some interesting perspective. For instance, the top 10 most effective agile agile practices (as reported by respondents) were:
There are also charts for top 10 agile practices that:
The Practices are Not the Point
We don't do the practices for the practices's sake. The agile practices come out of following the agile principles as explained on the manifesto website. The highest agile principle is: "to satisfy the customer through early and continuous delivery of valuable software". Early, continous, and valueable are the key words there. If a team doesn't understand the how the principles drive the practices, then they run the risk of being, as @Guildencrantz said, cargo-cult, not having the magic-bullet success that they expect, declaring agile a failure, and abandoning it.
It's Easier to be Agile on a New Project Than it is to Convert a Project to Agile:
I don't have a good citation at hand, but it's generally thought of as easier to be agile on greenfield projects than it is to convert a brownfield project to agile. One reason for that is that existing code is often written in a way that makes it hard to add automated tests. Michael Feathers wrote a whole book about adding tests to legacy code.
听起来你真的很想知道人们在现实世界中实际使用的是什么。有很多网站介绍什么是敏捷实践/方法，什么不是敏捷实践/方法。
所以，到目前为止，我在最近（过去 5 年）的角色中的经验是：
Sounds like you really want to know what people are actually using in the real world. There are plenty of sites about what is in and what is not an Agile practice/methodology.
So, my experience so far in my recent (last 5 years) roles:
大多数经验丰富的开发人员从此成为项目经理或 IT 总监。当时，大约 20 年前，敏捷软件开发等方法甚至还不存在，但它们能够生产和交付工作系统。
这些人可能缺乏对这些新方法论中提出的实践的了解，从而导致对提出这些方法的某种抵制。
因此我们不能对他们粗暴，他们只会抵制他们不知道甚至不理解的变化，就像我们说一个习惯于以一种方式工作的客户，然后我们用我们的新方法来改变这个客户的一天之内养成习惯！出现这些阻力是很正常的，这是人类的行为。
此外，对于一些更有经验的人来说，他们不仅不明白结对工作的意义，例如。就像他们通常不相信 Scrum 会议一样，他们更喜欢老式的方式，这种方式在某种程度上已经取得了成功，即每周持续 1 到 2 小时的会议。
对于那些负责编程资源预算的管理员来说，对于结对编程来说，付钱给一个无所事事的程序员，而这个无所事事的程序员可以处理代码的另一部分，以提高生产力。你也不能怪他们，因为他们的想法很有道理。
与其他建议相比，敏捷软件开发中的一些建议更容易受益。虽然结对编程在实践中可能不知道真正的成功，甚至每天的 scrum 会议也不知道，但根据我的经验，成功的标准是一旦我们获得了足够精确的软件草图、它的要求和功能就开始编码，而永远不会忘记客户自己给出的优先级。然后，在开发迭代时更新 UML 分析。
根据我的经验，软件迭代开始取得越来越成功。
慢慢来，敏捷软件开发，例如测试驱动开发，在我所在的地区仍然是新事物。我相信，一旦他们有了更多的练习者，他们的实践就会随之增长。
Most of experienced developers have become project managers since or IT directors. Back then, about 20 years ago, those methodologies such as Agile Software Development didn't even exist, and they were able to produce and to deliver working systems.
These same guys might lack the knowledge of such proposed practice from these new methodologies resulting of some sort of resistance against bringing forward those approach.
We cannot be rough at them for so, they only resist to changes they don'T know or even understand, just like let's say a customer who is used to work one way, and then we come with our new methods and then change this customer's habits within a day! It's quite normal that these resistances occur, they're human bahviours.
Furthermore, for some of these more experienced-guys, they don't just don't get the point of working in pair, for example. Just like they generally don't believe in scrum meetings, they prefer the old-school way, which has known its success in some way, of a meeting lasting from 1 to 2 hours a week.
As for administrators, those responsible for the budgets of programming resources, it is seen, as for pair programming, to pay a programmer doing nothing while this doing-nothing-programmer could work on another part of code to multiply productivity. You cannot really blame them neither, as what they think makes full of sense.
Some suggestions from the Agile Software Development are easier to get the benefit from in comparison to some others. While pair programming might not know a real success in practice, or even daily scrum meetings, what is a success though, in my experience, is beginning coding as soon as we get a precise enough sketch of the software, its requirements and features, never to forget the priorities given from the customer himself. Then, updating the UML analysis while developing for an iteration.
Software iterations, in my experience, begin a growing success.
Let it time, Agile Software Development, such as Test Driven Development, well in my region, are still new stuff. Once they will get more practitioners, their practiced practices will grow with it, I believe.
这取决于公司。我工作的公司一直都在做所有 TDD、所有配对、所有 CI。如果您提交代码，但没有提交单元/FitNesse 测试，团队并不害怕给您打电话，并且在您提交代码后不到一分钟，CI 服务器就会运行整套测试，并且如果您的代码破坏构建或艾米测试失败，灯熄灭，您被标记为破坏构建的人。
这不是最常见的情况，但确实有一些公司在实践敏捷。
It depends on company to company. I work for a company that does all TDD, all pairing, all CI, all the time. The team isn't afraid to call you on it if you submit code, but didn't submit unit/FitNesse tests, and less than a minute after you submit code, the CI server runs the whole suite of tests, and if your code breaks the build or Amy ofthe tests fail, lights go off and you're flagged as the one that broke the build.
It's not the most common situation, but there are companies out there that truly do practice Agile.
在商业中，我认为你通常会看到团队从不同的编程方法中汲取他们喜欢的方面，并将它们结合到自己的实践中。他们可能会使用他们想要的任何术语，即使它不是 100% 准确。
在我们的团队中，我们应用每日站立会议和团队编程（大约一半的时间 - 取决于任务）。但我们并不声称自己做到了敏捷。
In business I think you generally will see teams taking the aspects they like from different programming methodologies and combine them into their own practices. They they will probably apply whatever term they want to it even though it's not 100% accurate.
In our team we apply daily stand-ups and team programming (about half the time--depends on the task). We don't claim to do agile though.
敏捷方法论是敏捷开发的基础。
换句话说，极限编程，Scrum 等都是基于敏捷原则的敏捷方法论。深入检查这些将回答您的问题。
至于敏捷本身，以及所有这些类型的敏捷开发的共同点，请查看 Wikipedia 了解一个很好的概述。
The agile methodology is a basis for agile development.
In other words, eXtreme Programming, Scrum and so forth are agile methodologies based on agile principles. Checking out these in depth will answer your questions.
As for agile itself, and what all these types of agile development have in common check out Wikipedia for a nice overview.
Thoughtworks 是实施敏捷开发的公司之一。直接从 Martin Fowler 的 网站了解有关敏捷开发的更多信息。
Thoughtworks is one of the companies that have Agile Development in force. Read more about Agile development directly from Martin Fowler's website.
很多人似乎误解了重构、结对编程和自组织团队的一般概念等概念...对于那些从瀑布中获得一定成功并已根深蒂固的人来说，这些可能很困难让这些人尝试 XP 是一个问题。
Lots of people seem to misunderstand concepts like refactoring, pair programming and the general concept of self-organising teams... those can be difficult for people who've gotten a measure of success from waterfall and have gotten entrenched in that way of doing things. It is a problem getting those people to try XP.
正如其他人提到的，敏捷是一个总括术语，可以通过多种不同的方式实施；话虽这么说，敏捷当前的流行语状态导致许多公司尝试实施敏捷，但实际上只是实施了一组 货物崇拜式程序并期望敏捷的灵活性。
As others have mentioned agile is an umbrella term and can be implemented in a number of different ways; that being said agile's current buzzword status has lead to a lot of companies trying to implement agile who really just implement a set of cargo cult-esque procedures and expect agile's flexibility.
在我以前的公司，经理们抓住了敏捷，就像它是他们所有问题的答案一样。但它所做的唯一一件事就是制造了更多的问题。
我们定期举行会议，称为“站立会议”（某种敏捷术语）。
我认为他们尝试了很多敏捷技术，但当时对我们来说效果并不好。
In my previous company, the managers grabbed a hold of agile like it was the answer to all their problems. But the only thing it did was create a whole lot more problems.
We had very regular meetings that were called "standups" (some sort of agile term).
I think they tried a lot of agile techniques but it didn't really work well for us at the time.