Extreme programming: Difference between revisions

Revision as of 17:08, 10 April 2021

Revision as of 01:29, 10 May 2021

Line 1:

{{short description|Software development methodology}}

{{Use mdydmy dates|date=NovemberMay 20182021}}

[[Image:Extreme Programming.svg|thumb|Planning and feedback loops in extreme programming]]

{{Software development process}}

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].</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=2019-03-26 March 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 21:

* Internally, [[object-oriented programming]] replaced [[procedural programming]] as the programming paradigm favored by some developers.

* Externally, the rise of the Internet and the [[dot-com boom]] emphasized speed-to-market and company growth as competitive [[business]] factors.

Rapidly changing requirements demanded shorter [[Product life cycle management |product life-cycles]], and often clashed with traditional methods of software development.

The Chrysler Comprehensive Compensation System (C3) started in order to determine the best way to use object technologies, using the payroll systems at Chrysler as the object of research, with [[Smalltalk]] as the language and [[Gemstone Database Management System| GemStone]] as the [[data access layer]]. Chrysler brought in [[Kent Beck]],<ref name=Cworld92/> a prominent Smalltalk practitioner, to do [[performance tuning]] on the system, but his role expanded as he noted several problems with the development process. He took this opportunity to propose and implement some changes in development practices -– based on his work with his frequent collaborator, [[Ward Cunningham]]. Beck describes the early conception of the methods:<ref>{{cite book|url= http://www.informit.com/articles/article.aspx?p=20972|title= Interview with Kent Beck and Martin Fowler|work= informit.com|date=2001-03-23 March 2001}}</ref>

{{quote|The first time I was asked to lead a team, I asked them to do a little bit of the things I thought were sensible, like testing and reviews. The second time there was a lot more on the line. I thought, "Damn the torpedoes, at least this will make a good article," [and] asked the team to crank up all the knobs to 10 on the things I thought were essential and leave out everything else.|author=|title=|source=}}

Line 40:

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 105:

The first version of rules for XP was published in 1999 by Don Wells<ref>{{cite web|url=http://www.extremeprogramming.org/rules.html|title=Extreme Programming Rules|work=extremeprogramming.org}}</ref> at the XP website. 29 rules are given in the categories of planning, managing, designing, coding, and testing. Planning, managing and designing are called out explicitly to counter claims that XP doesn't support those activities.

Another version of XP rules was proposed by Ken Auer<ref>[http://www.rolemodelsoftware.com/moreAboutUs/publications/rulesOfXp.php Ken Auer] {{webarchive|url=https://web.archive.org/web/20080920062925/http://www.rolemodelsoftware.com/moreAboutUs/publications/rulesOfXp.php |date=September 20, September 2008 }}</ref> in XP/Agile Universe 2003. He felt XP was defined by its rules, not its practices (which are subject to more variation and ambiguity). He defined two categories: "Rules of Engagement" which dictate the environment in which software development can take place effectively, and "Rules of Play" which define the minute-by-minute activities and rules within the framework of the Rules of Engagement.

Here are some of the rules (incomplete):

Line 166:

The practices in XP have been heavily debated.<ref name=Cworld92/> Proponents of extreme programming claim that by having the on-site customer<ref name=Cworld92/> request changes informally, the process becomes flexible, and saves the cost of formal overhead. Critics of XP claim this can lead to costly rework and project [[scope creep]] beyond what was previously agreed or funded.{{Citation needed|date=February 2020}}

Change-control boards are a sign that there are potential conflicts in project objectives and constraints between multiple users. XP's expedited methods are somewhat dependent on programmers being able to assume a unified client viewpoint so the programmer can concentrate on coding, rather than documentation of compromise objectives and constraints.<ref name="CarrollMorris2015">{{cite book|author1=John Carroll|author2=David Morris|title=Agile Project Management in easy steps, 2nd edition|url=https://books.google.com/books?id=oqFKCgAAQBAJ&pg=PT162|date=July 29, July 2015|publisher=In Easy Steps|isbn=978-1-84078-703-0|page=162}}</ref> This also applies when multiple programming organizations are involved, particularly organizations which compete for shares of projects.{{Citation needed|date=July 2008}}

Other potentially controversial aspects of extreme programming include:

Line 180:

[[ThoughtWorks]] has claimed reasonable success on distributed XP projects with up to sixty people.{{Citation needed|date=August 2009}}

In 2004, industrial extreme programming (IXP)<ref>{{cite web|url=http://www.cutter.com/content-and-analysis/resource-centers/agile-project-management/sample-our-research/apmr0502.html|title=Industrial XP: Making XP Work in Large Organizations -– Cutter Consortium|author=Cutter Consortium|work=cutter.com}}</ref> was introduced as an evolution of XP. It is intended to bring the ability to work in large and distributed teams. It now has 23 practices and flexible values.

=== Severability and responses ===

Line 190:

== 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> and 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| url=http://www.drdobbs.com/the-irony-of-extreme-programming/184405651 |title=The irony of extreme programming| 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, March 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 218:

* [[Pair programming]]

* [[Scrum (development)]]

* [[Software engineering]]

* [[Software craftsmanship]]

* [[Stand-up meeting]]