Extreme programming: Difference between revisions

Revision as of 22:08, 21 January 2003

Revision as of 21:21, 3 March 2003

Line 1:

[[pl:Programowanie ekstremalne]]

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

Fundamental characteristics of the method are:

Line 17:

#Simple code is more likely to work. Therefore, extreme programmers only write code to meet actual needs in the present project;

#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. The system is periodically, or immediately tested using all pre-existing automated tests to assure that it works. (See [[test-driven development]])

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

In general, Extreme programmingProgramming is believed to be useful for small teams under 10 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.

----

''The following text needs to be merged:''

Extreme programming, or "XP" takes certain simple practices that are known to improve software quality. Then, it takes these to logical extremes.

1. Requirements are addressed by having a customer on-site, available to the programmers. If this is not possible, the customer may describe use cases on cards, that are periodically photocopied for the engineering staff.

See also: [[Crystal Light Methods]]

Line 42 ⟶ 37:

A customer representative is attached to the project.

Programmers work in pairs.

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.