Extreme programming: Difference between revisions

Revision as of 01:42, 13 August 2003

Revision as of 13:40, 13 August 2003

Line 1:

[[es:programación extrema]] [[fr:EXtreme Programming]] [[pl:Programowanie ekstremalne]]

'''Extreme Programming''' (XP) is a method in or approach to [[software engineering]], formulated by [[Kent Beck]], who[[Ward Cunningham]], and [[Ron Jeffries]]. [[Kent Beck]] wrote the first book on the topic, "Extreme Programming Explained: Embrace Change" (ISBN 0201616416). It is onethe most popular of several [[agile processes]].

Fundamental characteristics of the method are:

Line 7:

*continuous, often repeated automated [[unit test]], [[regression testing]]. See [[JUnit]].

*[[pair programming]]

*user interaction in the programming team ([[Onsite Customer]])

*fixing all known [[computer bug|bugs]] before adding functionality

*[[refactoring]]

*sharingshared code ownership

*simplicity

*feedback

These characteristics are only derivatives of principles that are known to be good, and are taken into extreme:

#Interaction between developers and customers is good. Therefore, an XP team is supposed to have a customer on site, who specifies and prioritises work for the team, and who can answer questions as soon as they arise.

#If learning is good, take it to extremes: Reduce the length of development and feedback cycles. Test early;

#Simple code is more likely to work. Therefore, extreme programmers only write code to meet actual needs inat the present time in a project;, and go to some lengths to reduce complexity and duplication in their code.

#If simple code is good, re-write code when it becomes complex;

#Code reviews are good. Therefore XP programmers work in pairs, sharing one screen and keyboard (which also improves communication) so that all code is reviewed as it is written;

#Testing code is good. Therefore, in XP, test are written before the code is written. The code is considered complete when it passes the tests (but then it needs refactoring to remove complexity). The system is periodically, or immediately tested using all pre-existing automated tests to assure that it works. (See [[test-driven development]])

In general, Extreme Programming is believed to be useful for small teams under 1012 persons. Some think it can be useful for larger teams while some consider the [[Rational Unified Process|RUP]] process is more appropriate in that case. However, XP has been demonstrated successfully on a team of over a hundred developers. It's not that XP doesn't scale, just that few people have tried to scale it, and XPers refust to speculate on this facet of the process.

==Controversial Aspects==

Line 26 ⟶ 27:

* A customer representative is attached to the project

* Programmers work in pairs

* [[test-driven development]]

Most of the design activity takes place on the fly and incrementally,

starting with "the simplest thing that could possibly work" and adding

complexity only when it's required by failing tests. Unit-testing is a design discipline.

''See also:'' [[Crystal Light Methods]] from [[Alistair Cockburn]]

==References & External Links==

Line 37 ⟶ 39:

*[[Ward Cunningham]]'s website, http://www.c2.com/cgi/wiki?ExtremeProgramming - For more information on this and related topics

* [http://www.nidelven-it.no/articles/extreme_programming Client oriented introduction to XP]

* [[Ron Jeffries]] web-mag http://www.xprogramming.com