Content deleted Content added
Citation bot (talk | contribs) Added publisher. | Use this bot. Report bugs. | #UCB_CommandLine |
I added an extra goal of XP with good grammar Tags: Mobile edit Mobile web edit |
||
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]]). Collaboration is key to ensure that the code appears to be in unison.
{{TOC limit|3}}
| |||