Extreme programming: Difference between revisions

Revision as of 21:21, 3 March 2003

Revision as of 11:53, 7 May 2003

Line 13:

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 can answer questions as soon as they arise.

#If communication is good, take it to extremes: Have a customer representative present in the project team;

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

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

Line 19:

#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 Programming 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.