Content deleted Content added
m Undid revision 1022353117 by Tony1 (talk) Why on earth would you change the established date format? And why would you unlink something in the see also section. Just remove it!, date formats per MOS:DATEFORMAT by script |
m →History: Clean up |
||
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=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.
{{TOC limit|3}}
Line 12:
== History ==
[[Kent Beck]] developed extreme programming during his work on the [[Chrysler Comprehensive Compensation System]] (C3) payroll [[project]].<ref name=Cworld92/> Beck became the C3 [[Project management|project leader]] in March 1996. He began to refine the development methodology used in the project and wrote a book on the methodology (''Extreme Programming Explained'', published in October 1999).<ref name="Cworld92">[http://www.computerworld.com/article/2585634/app-development/extreme-programming.html Computerworld-appdev-92 "Extreme Programming", ''Computerworld'' (online), December 2001].
</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>▼
▲[[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>
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| Larman | 2003}} To shorten the total development time, some formal test documents (such as for [[acceptance testing]]) have been developed in parallel with (or shortly before) the software being ready for testing. A NASA independent test group can write the test procedures, based on formal requirements and logical limits, before programmers write the software and integrate it with the hardware. XP takes this concept to the extreme level, writing automated tests (sometimes inside software modules) which validate the operation of even small sections of software coding, rather than only testing the larger features.
| |||