Content deleted Content added
No edit summary Tag: Reverted |
Tassedethe (talk | contribs) No edit summary |
||
| (28 intermediate revisions by 24 users not shown) | |||
Line 3:
[[Image:Extreme Programming.svg|thumb|Planning and feedback loops in extreme programming]]
{{Software development process}}
'''
Other elements of extreme programming include
</ref><ref name="MASD">{{cite web|url=http://agilemanifesto.org |title=Manifesto for Agile Software Development |year=2001 |publisher=Agilemanifesto.org |access-date=March 26, 2019}}</ref> The methodology takes its name from the idea that the beneficial elements of traditional software engineering practices are taken to "extreme" levels. As an example, [[code review]]s are considered a beneficial practice; taken to the extreme, code can be reviewed ''continuously'' (i.e. the practice of [[pair programming]]).
{{TOC limit|3}}
Line 14:
</ref> [[Chrysler]] cancelled the C3 project in February 2000, after seven years, when [[Daimler-Benz]] acquired the company.<ref name="SR">{{cite book | last1 = Rosenberg | first1 = Doug | last2 = Stephens | first2 = Matt | title = Extreme Programming Refactored: The Case Against XP | year = 2003 | publisher = Apress | isbn = 978-1-59059-096-6 | url-access = registration | url = https://archive.org/details/extremeprogrammi00matt }}</ref> [[Ward Cunningham]] was another major influence on XP.
Many extreme-programming practices have been around for some time; the methodology takes "[[best practices]]" to extreme levels. For example, the "practice of test-first development, planning and writing tests before each micro-increment" was used as early as NASA's [[Project Mercury]], in the early 1960s.{{sfn|
=== Origins ===
Line 30:
Beck invited [[Ron Jeffries]] to the project to help develop and refine these methods. Jeffries thereafter acted as a coach to instill the practices as habits in the C3 team.
Information about the principles and practices behind XP disseminated to the wider world through discussions on the original [[wiki]], Cunningham's [[WikiWikiWeb]]. Various contributors discussed and expanded upon the ideas, and some spin-off methodologies resulted (see [[agile software development]]). Also, XP concepts have been explained
Beck edited a series of books on XP, beginning with his own ''Extreme Programming Explained'' (1999, {{ISBN |0-201-61641-6}}), spreading his ideas to a much larger audience. Authors in the series went through various aspects attending XP and its practices. The series included a book critical of the practices.
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
== Concept ==
{{More citations needed section|date=February 2025}}
=== Goals ===
''Extreme Programming Explained'' describes extreme programming as a software-development discipline that organizes people to produce higher-quality software more productively.
Line 49:
In this doctrine, changes are a natural, inescapable and desirable aspect of software-development projects, and should be planned for, instead of attempting to define a stable set of requirements.
Extreme programming also introduces a number of basic values, principles and practices on top of the agile
=== Activities ===
Line 62:
{{main|Test-driven development}}
Testing is central to extreme programming.<ref>{{cite book |title=Testing Extreme Programming|author1= Lisa Crispin |author2 = Tip House|isbn=9780321113559|date=2003|publisher= Addison-Wesley Professional }}</ref> Extreme programming's approach is that if a little testing can eliminate a few flaws, a lot of testing can eliminate many more flaws.
* [[Unit test]]s determine whether a given feature works as intended. Programmers write as many automated tests as they can think of that might "break" the code; if all tests run successfully, then the coding is complete. Every piece of code that is written is tested before moving on to the next feature.
* [[Acceptance test]]s verify that the requirements as understood by the programmers satisfy the customer's actual requirements.
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 [[
* 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.
Line 182:
=== Severability and responses ===
In 2003, [[Matt Stephens (author)|Matt Stephens]] and Doug Rosenberg published ''Extreme Programming Refactored: The Case Against XP'', which questioned the value of the XP process and suggested ways in which it could be improved.<ref name=SR/> This triggered a lengthy debate in articles, Internet newsgroups, and web-site chat areas. The core argument of the book is that XP's practices are interdependent but that few practical organizations are willing/able to adopt all the practices; therefore the entire process fails. The book also makes other criticisms, and it draws a likeness of XP's "collective ownership" model to socialism in a negative manner.
Certain aspects of XP have changed since the publication of ''Extreme Programming Refactored''; in particular, XP now accommodates modifications to the practices as long as the required objectives are still met. XP also uses increasingly generic terms for processes. Some argue that these changes invalidate previous criticisms; others claim that this is simply watering the process down.
Other authors have tried to reconcile XP with the older methodologies in order to form a unified methodology. Some of these XP sought to replace, such as the [[Waterfall model|waterfall methodology]]; example
== Criticism ==
Extreme programming's initial buzz and controversial tenets, such as [[pair programming]] and [[continuous design]], have attracted particular criticisms, such as the ones coming from McBreen,<ref name="mcbreen">{{cite book| last = McBreen| first = P.| title = Questioning Extreme Programming| year = 2003| publisher = Addison-Wesley| ___location = Boston, MA| isbn = 978-0-201-84457-3 }}</ref>
In particular, extreme programming has been reviewed and critiqued by Matt Stephens's and Doug Rosenberg's ''Extreme Programming Refactored''.<ref name=SR/>
Line 212:
== Further reading ==
* [[Ken Auer]] and Roy Miller. ''Extreme Programming Applied: Playing To Win'', Addison–Wesley.
* {{cite book |chapter=Are Testers eXtinct? How Can Testers Contribute to XP Teams? |author=Ken Auer|author2=Ron Jeffries |author3=Jeff Canna |author4=Glen B. Alleman |author5=Lisa Crispin |author6=Janet Gregory |title=Extreme Programming and Agile Methods — XP/Agile Universe 2002|volume=2418|pages=287|publisher=Springer-Verlag |year=2002 |doi=10.1007/3-540-45672-4_50|author2-link=Ron Jeffries|series=Lecture Notes in Computer Science|isbn=978-3-540-44024-6 }}
* [[Kent Beck]]: ''Extreme Programming Explained: Embrace Change'', Addison–Wesley. First edition, 1999. Second edition, with Cynthia Andres, 2004.
* [[Kent Beck]] and [[Martin Fowler (software engineer)|Martin Fowler]]: ''Planning Extreme Programming'', Addison–Wesley.
Line 220:
* [[Jim Highsmith]]. ''Agile Software Development Ecosystems'', Addison–Wesley.
* [[Ron Jeffries]], Ann Anderson and Chet Hendrickson (2000), ''Extreme Programming Installed'', Addison–Wesley.
* {{cite journal |last1=Larman |first1=C. |author-link1=Craig Larman |last2=Basili |first2=V.R. |title=Iterative and incremental developments. a brief history |url=https://www.craiglarman.com/wiki/downloads/misc/history-of-iterative-larman-and-basili-ieee-computer.pdf |journal=Computer |date=June 2003 |volume=36 |issue=6 |pages=47–56 |doi=10.1109/MC.2003.1204375}}
* [[Matt Stephens (author)|Matt Stephens]] and Doug Rosenberg (2003). ''Extreme Programming Refactored: The Case Against XP'', Apress.
* Waldner, JB. (2008). "Nanocomputers and Swarm Intelligence". In: ISTE, 225–256.
| |||