Content deleted Content added
m Criticism: Replace earlier 'and' with a comma in a list of critics |
Tassedethe (talk | contribs) No edit summary |
||
| (8 intermediate revisions by 7 users not shown) | |||
Line 6:
Other elements of extreme programming include programming [[Pair programming|in pairs]] or doing extensive [[code review]], [[unit testing]] of all code, [[You aren't gonna need it|not programming features until they are actually needed]], a flat management structure, code simplicity and clarity, expecting changes in the customer's requirements as time passes and the problem is better understood, and frequent communication with the customer and among programmers.<ref name="UPenn49">[http://www.cis.upenn.edu/~matuszek/cit591-2003/Lectures/49-design-patterns.ppt UPenn-Lectures-design-patterns "Design Patterns and Refactoring", University of Pennsylvania, 2003] {{Webarchive|url=https://web.archive.org/web/20100802073814/http://www.cis.upenn.edu/%7Ematuszek/cit591-2003/Lectures/49-design-patterns.ppt |date=August 2, 2010 }}.</ref><ref name="USFCA601">[http://www.cs.usfca.edu/~parrt/course/601/lectures/xp.html USFCA-edu-601-lecture Extreme Programming].
</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 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 42:
== 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 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 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> Boehm and Turner,<ref name="boehm2004">{{cite book| author2 = R. Turner| last = Boehm| first = B.| author-link = Barry Boehm| title = Balancing Agility and Discipline: A Guide for the Perplexed| year = 2004| publisher = Addison-Wesley| ___location = Boston, MA| isbn = 978-0-321-18612-6 | author2-link = Richard Turner (computer scientist)}}</ref> Matt Stephens and Doug Rosenberg.<ref name="stephens2004">{{cite book| author2 = Doug Rosenberg| last = Stephens| first = Matt| author-link = Matt Stephens (author)| url=http://www.drdobbs.com/the-irony-of-extreme-programming/184405651 |title=The irony of extreme programming| work = Dr. Dobb's| year = 2004| publisher = Dr Dobbs journal| ___location = MA}}</ref> Many of the criticisms, however, are believed by Agile practitioners to be misunderstandings of agile development.<ref name="sdmagazine1811">[http://www.sdmagazine.com/documents/s=1811/sdm0112h/0112h.htm sdmagazine] {{webarchive|url=https://web.archive.org/web/20060316100811/http://www.sdmagazine.com/documents/s%3D1811/sdm0112h/0112h.htm |date=March 16, 2006 }}</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 221:
* [[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.
| |||