Extreme programming: Difference between revisions

Revision as of 17:29, 8 January 2024

Revision as of 20:40, 23 January 2024

Line 39:

The high discipline required by the original practices often went by the wayside, causing some of these practices, such as those thought too rigid, to be deprecated or reduced, or even left unfinished, on individual sites. For example, the practice of end-of-day [[integration test]]s for a particular project could be changed to an end-of-week schedule, or simply reduced to testing on mutually agreed dates. Such a more relaxed schedule could avoid people feeling rushed to generate artificial stubs just to pass the end-of-day testing. A less-rigid schedule allows, instead, the development of complex features over a period of several days.

Meanwhile, other agile-development practices have not stood still, and {{as of | 2019 | lc = on}} XP continues to evolve, assimilating more lessons from experiences in the field, to use other practices. In the second edition of ''Extreme Programming Explained'' (November 2004), five years after the first edition, Beck added more [[value (disambiguation) | values]] and practices and differentiated between primary and corollary practices.

== Concept ==

Line 171:

* Requirements are defined incrementally, rather than trying to get them all in advance.

* Software developers are usually required to work in pairs.

* There is no [[big design up front]]. Most of the design activity takes place on the fly and incrementally, starting with <span id="SimplestThingThatCouldPossiblyWork"></span>"the simplest thing that could possibly work" and adding complexity only when it's required by failing tests. Critics characterize this as "[[debugging]] a system into appearance" and fear this will result in more re-design effort than only re-designing when requirements change.

* A [[customer representative]] is attached to the project. This role can become a single-point-of-failure for the project, and some people have found it to be a source of stress. Also, there is the danger of [[micro-management]] by a non-technical representative trying to dictate the use of technical software features and architecture.