extreme programming planning and feedback loops in extreme programming software development core activities processes requirements design engineering construction testing debugging deployment maintenance paradigms and models agile cleanroom incremental prototyping spiral v model waterfall methodologies and frameworks asd devops dad dsdm fdd iid kanban lean sd less mdd msf psp rad rup safe scrum semat tsp up xp supporting disciplines configuration management documentation software quality assurance sqa project management user experience practices atdd bdd cco ci cd ddd pp standup tdd tools compiler debugger profiler gui designer modeling ide build automation release automation infrastructure as code testing standards and bodies of knowledge babok cmmi ieee standards iso 9001 isoiec standards pmbok swebok itil glossaries artificial intelligence computer science electrical and electronics engineering vte extreme programming xp is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements as a type of agile software development it advocates frequent releases in short development cycles which is intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted other elements of extreme programming include programming in pairs or doing extensive code review unit testing of all code avoiding programming of features until they are actually needed a flat management structure code simplicity and clarity expecting changes in the customers requirements as time passes and the problem is better understood and frequent communication with the customer and among programmers 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 reviews are considered a beneficial practice taken to the extreme code can be reviewed continuously ie the practice of pair programming history extreme programming was created by kent beck during his work on the chrysler comprehensive compensation system c3 payroll project chrysler cancelled the c3 project in february 2000 after seven years when the company was acquired by daimlerbenz many extreme programming practices have been around for some time the methodology takes best practices to extreme levels for example the practice of testfirst development planning and writing tests before each microincrement was used as early as nasas project mercury in the early 1960s to shorten the total development time some formal test documents such as for acceptance testing have been developed in parallel or shortly before the software is ready for testing a nasa independent test group can write the test procedures based on formal requirements and logical limits before the software has been written and integrated with the hardware in xp this concept is taken to the extreme level by writing automated tests perhaps inside of software modules which validate the operation of even small sections of software coding rather than only testing the larger features origins software development in the 1990s was shaped by two major influences internally objectoriented programming replaced procedural programming as the programming paradigm favored by some in the industry externally the rise of the internet and the dotcom boom emphasized speedtomarket and company growth as competitive business factors rapidly changing requirements demanded shorter product lifecycles and were often incompatible with traditional methods of software development the chrysler comprehensive compensation system c3 was 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 as the data access layer they brought in kent beck 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 asked the team to crank up all the knobs to 10 on the things i thought were essential and leave out everything else 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 was disseminated to the wider world through discussions on the original wiki cunninghams wikiwikiweb various contributors discussed and expanded upon the ideas and some spinoff methodologies resulted see agile software development also xp concepts have been explained for several years using a hypertext system map on the xp website at httpwwwextremeprogrammingorg circa 1999 beck edited a series of books on xp beginning with his own extreme programming explained 1999 isbn0201616416 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 that was critical of the practices current state xp generated significant interest among software communities in the late 1990s and early 2000s seeing adoption in a number of environments radically different from its origins 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 endofday integration tests for a particular project could be changed to an endofweek schedule or simply reduced to mutually agreed dates such a more relaxed schedule could avoid people feeling rushed to generate artificial stubs just to pass the endofday testing a lessrigid schedule allows instead for some complex features to be more fully developed over a severalday period meanwhile other agile development practices have not stood still and xp is still evolving 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 values and practices and differentiated between primary and corollary practices the theory of sustainable software development explains why extreme programming teams can thrive inspite of team disruptions concept goals extreme programming explained describes extreme programming as a softwaredevelopment discipline that organizes people to produce higherquality software more productively xp attempts to reduce the cost of changes in requirements by having multiple short development cycles rather than a long one in this doctrine changes are a natural inescapable and desirable aspect of softwaredevelopment projects and should be planned for instead of attempting to define a stable set of requirements extreme programming also introduces a number of basic values principles and practices on top of the agile programming framework activities xp describes four basic activities that are performed within the software development process coding testing listening and designing each of those activities is described below coding the advocates of xp argue that the only truly important product of the system development process is code software instructions that a computer can interpret without code there is no working product coding can also be used to figure out the most suitable solution coding can also help to communicate thoughts about programming problems a programmer dealing with a complex programming problem or finding it hard to explain the solution to fellow programmers might code it in a simplified manner and use the code to demonstrate what he or she means code say the proponents of this position is always clear and concise and cannot be interpreted in more than one way other programmers can give feedback on this code by also coding their thoughts testing testdriven development extreme programmings approach is that if a little testing can eliminate a few flaws a lot of testing can eliminate many more flaws unit tests 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 tests verify that the requirements as understood by the programmers satisfy the customers actual requirements systemwide integration testing was encouraged initially as a daily endofday activity for early detection of incompatible interfaces to reconnect before the separate sections diverged widely from coherent functionality however systemwide integration testing has been reduced to weekly or less often depending on the stability of the overall interfaces in the system listening programmers must listen to what the customers need the system to do what business logic is needed they must understand these needs well enough to give the customer feedback about the technical aspects of how the problem might be solved or cannot be solved communication between the customer and programmer is further addressed in the planning game designing from the point of view of simplicity of course one could say that system development doesnt need more than coding testing and listening if those activities are performed well the result should always be a system that works in practice this will not work one can come a long way without designing but at a given time one will get stuck the system becomes too complex and the dependencies within the system cease to be clear one can avoid this by creating a design structure that organizes the logic in the system good design will avoid lots of dependencies within a system this means that changing one part of the system will not affect other parts of the system values extreme programming initially recognized four values in 1999 communication simplicity feedback and courage a new value respect was added in the second edition of extreme programming explained those five values are described below communication building software systems requires communicating system requirements to the developers of the system in formal software development methodologies this task is accomplished through documentation extreme programming techniques can be viewed as methods for rapidly building and disseminating institutional knowledge among members of a development team the goal is to give all developers a shared view of the system which matches the view held by the users of the system to this end extreme programming favors simple designs common metaphors collaboration of users and programmers frequent verbal communication and feedback simplicity extreme programming encourages starting with the simplest solution extra functionality can then be added later the difference between this approach and more conventional system development methods is the focus on designing and coding for the needs of today instead of those of tomorrow next week or next month this is sometimes summed up as the you arent gonna need it yagni approach proponents of xp acknowledge the disadvantage that this can sometimes entail more effort tomorrow to change the system their claim is that this is more than compensated for by the advantage of not investing in possible future requirements that might change before they become relevant coding and designing for uncertain future requirements implies the risk of spending resources on something that might not be needed while perhaps delaying crucial features related to the communication value simplicity in design and coding should improve the quality of communication a simple design with very simple code could be easily understood by most programmers in the team feedback within extreme programming feedback relates to different dimensions of the system development feedback from the system by writing unit tests or running periodic integration tests the programmers have direct feedback from the state of the system after implementing changes feedback from the customer the functional tests aka acceptance tests are written by the customer and the testers they will get concrete feedback about the current state of their system this review is planned once in every two or three weeks so the customer can easily steer the development feedback from the team when customers come up with new requirements in the planning game the team directly gives an estimation of the time that it will take to implement feedback is closely related to communication and simplicity flaws in the system are easily communicated by writing a unit test that proves a certain piece of code will break the direct feedback from the system tells programmers to recode this part a customer is able to test the system periodically according to the functional requirements known as user stories courage several practices embody courage one is the commandment to always design and code for today and not for tomorrow this is an effort to avoid getting bogged down in design and requiring a lot of effort to implement anything else courage enables developers to feel comfortable with refactoring their code when necessary this means reviewing the existing system and modifying it so that future changes can be implemented more easily another example of courage is knowing when to throw code away courage to remove source code that is obsolete no matter how much effort was used to create that source code also courage means persistence a programmer might be stuck on a complex problem for an entire day then solve the problem quickly the next day but only if they are persistent respect the respect value includes respect for others as well as selfrespect programmers should never commit changes that break compilation that make existing unittests fail or that otherwise delay the work of their peers members respect their own work by always striving for high quality and seeking for the best design for the solution at hand through refactoring adopting the four earlier values leads to respect gained from others in the team nobody on the team should feel unappreciated or ignored this ensures a high level of motivation and encourages loyalty toward the team and toward the goal of the project this value is dependent upon the other values and is oriented toward teamwork rules the first version of rules for xp was published in 1999 by don wells 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 doesnt support those activities another version of xp rules was proposed by ken auer in xpagile 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 minutebyminute activities and rules within the framework of the rules of engagement principles the principles that form the basis of xp are based on the values just described and are intended to foster decisions in a system development project the principles are intended to be more concrete than the values and more easily translated to guidance in a practical situation feedback extreme programming sees feedback as most useful if it is done frequently and promptly it stresses that minimal delay between an action and its feedback is critical to learning and making changes unlike traditional system development methods contact with the customer occurs in more frequent iterations the customer has clear insight into the system that is being developed and can give feedback and steer the development as needed with frequent feedback from the customer a mistaken design decision made by the developer will be noticed and corrected quickly before the developer spends much time implementing it unit tests contribute to the rapid feedback principle when writing code running the unit test provides direct feedback as to how the system reacts to the changes made this includes running not only the unit tests that test the developers code but running in addition all unit tests against all the software using an automated process that can be initiated by a single command that way if the developers changes cause a failure in some other portion of the system that the developer knows little or nothing about the automated allunittest suite will reveal the failure immediately alerting the developer of the incompatibility of their change with other parts of the system and the necessity of removing or modifying their change under traditional development practices the absence of an automated comprehensive unittest suite meant that such a code change assumed harmless by the developer would have been left in place appearing only during integration testing or worse only in production and determining which code change caused the problem among all the changes made by all the developers during the weeks or even months previous to integration testing was a formidable task assuming simplicity this is about treating every problem as if its solution were extremely simple traditional system development methods say to plan for the future and to code for reusability extreme programming rejects these ideas the advocates of extreme programming say that making big changes all at once does not work extreme programming applies incremental changes for example a system might have small releases every three weeks when many little steps are made the customer has more control over the development process and the system that is being developed embracing change the principle of embracing change is about not working against changes but embracing them for instance if at one of the iterative meetings it appears that the customers requirements have changed dramatically programmers are to embrace this and plan the new requirements for the next iteration practices further information extreme programming practices extreme programming has been described as having 12 practices grouped into four areas finescale feedback pair programming planning game testdriven development extreme programming practices continuous process continuous integration refactoring or design improvement small releases shared understanding coding standards collective code ownership simple design system metaphor programmer welfare sustainable pace coding the customer is always available code the unit test first only one pair integrates code at a time leave optimization until last no overtime testing all code must have unit tests all code must pass all unit tests before it can be released when a bug is found tests are created before the bug is addressed a bug is not an error in logic it is a test that was not written acceptance tests are run often and the results are published controversial aspects the practices in xp have been heavily debated 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 changecontrol boards are a sign that there are potential conflicts in project objectives and constraints between multiple users xps 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 other potentially controversial aspects of extreme programming include requirements are expressed as automated acceptance tests rather than specification documents 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 big design up front most of the design activity takes place on the fly and incrementally starting with the simplest thing that could possibly work and adding complexity only when its required by failing tests critics compare this to debugging a system into appearance and fear this will result in more redesign effort than only redesigning when requirements change a customer representative is attached to the project this role can become a singlepointoffailure for the project and some people have found it to be a source of stress also there is the danger of micromanagement by a nontechnical representative trying to dictate the use of technical software features and architecture dependence upon all other aspects of xp xp is like a ring of poisonous snakes daisychained together all it takes is for one of them to wriggle loose and youve got a very angry poisonous snake heading your way critics have noted several potential drawbacks including problems with unstable requirements no documented compromises of user conflicts and a lack of an overall design specification or document scalability thoughtworks has claimed reasonable success on distributed xp projects with up to sixty people in 2004 industrial extreme programming ixp 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 in 2003 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 this triggered a lengthy debate in articles internet newsgroups and website chat areas the core argument of the book is that xps practices are interdependent but that few practical organizations are willingable to adopt all the practices therefore the entire process fails the book also makes other criticisms and it draws a likeness of xps 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 methodology example project lifecycles waterfall rapid application development and all that jpmorgan chase co tried combining xp with the computer programming methods of capability maturity model integration cmmi and six sigma they found that the three systems reinforced each other well leading to better development and did not mutually contradict criticism extreme programmings initial buzz and controversial tenets such as pair programming and continuous design have attracted particular criticisms such as the ones coming from mcbreen in particular extreme programming has been reviewed and critiqued by matt stephenss and doug rosenbergs extreme programming refactored criticisms include a methodology is only as effective as the people involved agile does not solve this often used as a means to bleed money from customers through lack of defining a deliverable product lack of structure and necessary documentation only works with seniorlevel developers incorporates insufficient software design requires meetings at frequent intervals at enormous expense to customers requires too much cultural change to adopt can lead to more difficult contractual negotiations can be very inefficient if the requirements for one area of code change through various iterations the same programming may need to be done several times over whereas if a plan were there to be followed a single area of code is expected to be written once impossible to develop realistic estimates of work effort needed to provide a quote because at the beginning of the project no one knows the entire scoperequirements can increase the risk of scope creep due to the lack of detailed requirements documentation agile is featuredriven nonfunctional quality attributes are hard to represent as user stories agile software development continuous obsolescence extreme manufacturing extreme project management extreme programming practices kaizen list of software development philosophies pair programming scrum development software engineering software craftsmanship standup meeting timeboxing ken auer and roy miller extreme programming applied playing to win addisonwesley ken auer ron jeffries jeff canna glen b alleman lisa crispin janet gregory 2002 are testers extinct how can testers contribute to xp teams springerverlag kent beck extreme programming explained embrace change addisonwesley kent beck and martin fowler planning extreme programming addisonwesley kent beck and cynthia andres extreme programming explained embrace change second edition addisonwesley alistair cockburn agile software development addisonwesley martin fowler refactoring improving the design of existing code addisonwesley harvey herela 2005 case study the chrysler comprehensive compensation system galen lab uc irvine jim highsmith agile software development ecosystems addisonwesley ron jeffries ann anderson and chet hendrickson 2000 extreme programming installed addisonwesley craig larman v basili 2003 iterative and incremental development a brief history computer ieee computer society 36 6 4756 matt stephens and doug rosenberg 2003 extreme programming refactored the case against xp apress waldner jb 2008 nanocomputers and swarm intelligence in iste 225256 wikimedia commons has media related to extreme programming wikiquote has quotations related to extreme programming extreme programming a gentle introduction industrial extreme programming xp magazine problems and solutions to xp implementation using an agile software process with offshore development thoughtworks experiences with implementing xp in large distributed projects vtesoftware engineeringfields computer programming requirements engineering software deployment software design software maintenance software testing systems analysis formal methods concepts data modeling enterprise architecture functional specification modeling language orthogonality programming paradigm software software archaeology software architecture software configuration management software development methodology software development process software quality software quality assurance software verification and validation structured analysis orientations agile aspectoriented object orientation ontology service orientation sdlc modelsdevelopmental agile eup executable uml incremental model iterative model prototype model rad up scrum spiral model vmodel waterfall model xp other spice cmmi data model er model function model information model metamodeling object model systems model view model languages idef uml usl sysml softwareengineers victor basili kent beck grady booch fred brooks barry boehm peter chen danese cooper ward cunningham tom demarco edsger w dijkstra delores m etter martin fowler adele goldstine margaret hamilton c a r hoare lois haibt mary jean harrold grace hopper watts humphrey michael a jackson ivar jacobson alan kay nancy leveson stephen j mellor bertrand meyer david parnas trygve reenskaug winston w royce james rumbaugh mary shaw peri tarr elaine weyuker niklaus wirth edward yourdon related fields computer science computer engineering project management risk management systems engineering category commons authority control bne xx550562 bnf cb144400247 data gnd 46184995 lccn sh99004731 