Content deleted Content added
m del unnecessary colon |
Tassedethe (talk | contribs) No edit summary |
||
| (14 intermediate revisions by 12 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 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 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 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.
| |||