| Desarrollo de software |
|---|
La programación extrema ( XP ) es una metodología de desarrollo de software que tiene como objetivo mejorar la calidad del software y la capacidad de respuesta a los requisitos cambiantes del cliente. Como un tipo de desarrollo de software ágil , [1] [2] [3] aboga por "lanzamientos" frecuentes en ciclos de desarrollo cortos, lo que tiene como objetivo mejorar la productividad e introducir puntos de control en los que se pueden adoptar nuevos requisitos del cliente.
Otros elementos de la programación extrema incluyen: programar en pares o hacer una revisión extensa del código , pruebas unitarias de todo el código, no programar funciones hasta que sean realmente necesarias , una estructura de administración plana, simplicidad y claridad del código, esperando cambios en los requisitos del cliente a medida que pasa el tiempo y el problema se comprende mejor, y la comunicación frecuente con el cliente y entre los programadores. [2] [3] [4] La metodología toma su nombre de la idea de que los elementos beneficiosos de las prácticas tradicionales de ingeniería de software se llevan a niveles "extremos". Como ejemplo, revisiones de códigose consideran una práctica beneficiosa; llevado al extremo, el código se puede revisar continuamente (es decir, la práctica de la programación por pares ).
Historia [ editar ]
Kent Beck desarrolló una programación extrema durante su trabajo en el proyecto de nómina Chrysler Comprehensive Compensation System (C3) . [5] Beck se convirtió en el líder del proyecto C3 en marzo de 1996. Comenzó a refinar la metodología de desarrollo utilizada en el proyecto y escribió un libro sobre la metodología ( Extreme Programming Explained , publicado en octubre de 1999). [5] Chrysler canceló el proyecto C3 en febrero de 2000, después de siete años, cuando Daimler-Benz adquirió la empresa. [6]
Muchas prácticas de programación extrema han existido durante algún tiempo; la metodología lleva las " mejores prácticas " a niveles extremos. Por ejemplo, la "práctica del desarrollo de la prueba primero, la planificación y la escritura de pruebas antes de cada microincremento" se utilizó ya en el Proyecto Mercurio de la NASA , a principios de la década de 1960. [7] Para acortar el tiempo total de desarrollo, algunos documentos de prueba formales (como las pruebas de aceptación) se han desarrollado en paralelo con (o poco antes) que el software esté listo para ser probado. Un grupo de prueba independiente de la NASA puede escribir los procedimientos de prueba, basados en requisitos formales y límites lógicos, antes de que los programadores escriban el software y lo integren con el hardware. XP lleva este concepto a un nivel extremo, escribiendo pruebas automatizadas (a veces dentro de módulos de software) que validan el funcionamiento de incluso pequeñas secciones de codificación de software, en lugar de solo probar las funciones más grandes.
Orígenes [ editar ]
Dos influencias importantes dieron forma al desarrollo de software en la década de 1990:
- Internamente, la programación orientada a objetos reemplazó a la programación procedimental como el paradigma de programación favorecido por algunos desarrolladores.
- Externamente, el auge de Internet y el auge de las puntocom enfatizaron la velocidad de comercialización y el crecimiento de la empresa como factores comerciales competitivos .
Los requisitos rápidamente cambiantes exigían ciclos de vida más cortos del producto y , a menudo, chocaban con los métodos tradicionales de desarrollo de software.
El Sistema de Compensación Integral de Chrysler (C3) se inició con el fin de determinar la mejor manera de utilizar las tecnologías de objetos, utilizando los sistemas de nómina de Chrysler como objeto de investigación, con Smalltalk como lenguaje y GemStone como capa de acceso a los datos . Chrysler contrató a Kent Beck , [5] un destacado practicante de Smalltalk, para ajustar el rendimiento del sistema, pero su función se amplió cuando notó varios problemas con el proceso de desarrollo. Aprovechó esta oportunidad para proponer e implementar algunos cambios en las prácticas de desarrollo, basándose en su trabajo con su colaborador habitual, Ward Cunningham . Beck describe la concepción temprana de los métodos:[8]
La primera vez que me pidieron que dirigiera un equipo, les pedí que hicieran algunas de las cosas que pensaba que eran sensatas, como pruebas y revisiones. La segunda vez había mucho más en juego. Pensé: "Al diablo con los torpedos, al menos esto será un buen artículo", [y] le pedí al equipo que subiera todas las perillas a 10 en las cosas que pensaba que eran esenciales y omitiera todo lo demás.
Beck invitó a Ron Jeffries al proyecto para ayudar a desarrollar y perfeccionar estos métodos. A partir de entonces, Jeffries actuó como entrenador para inculcar las prácticas como hábitos en el equipo C3.
La información sobre los principios y las prácticas detrás de XP se difundió al resto del mundo a través de discusiones en la wiki original , WikiWikiWeb de Cunningham . Varios colaboradores discutieron y ampliaron las ideas, y resultaron algunas metodologías derivadas (ver desarrollo de software ágil ). Además, los conceptos de XP han sido explicados [¿ por quién? ] , durante varios años, utilizando un mapa del sistema de hipertexto en el sitio web de XP en http://www.extremeprogramming.org alrededor de 1999.
Beck editó una serie de libros sobre XP, comenzando con su propio Extreme Programming Explained (1999, ISBN 0-201-61641-6 ), difundiendo sus ideas a una audiencia mucho más amplia. Los autores de la serie pasaron por varios aspectos relacionados con XP y sus prácticas. La serie incluyó un libro crítico de las prácticas.
Estado actual [ editar ]
XP generó un interés significativo entre las comunidades de software a fines de la década de 1990 y principios de la de 2000, al ver la adopción en varios entornos radicalmente diferentes de sus orígenes.
La alta disciplina requerida por las prácticas originales a menudo se quedó en el camino, lo que provocó que algunas de estas prácticas, como las que se consideraban demasiado rígidas, fueran desaprobadas o reducidas, o incluso dejadas sin terminar, en sitios individuales. Por ejemplo, la práctica de las pruebas de integración al final del día para un proyecto en particular podría cambiarse a un programa de fin de semana, o simplemente reducirse a pruebas en fechas mutuamente acordadas. Un horario tan relajado podría evitar que las personas se sientan apresuradas a generar talones artificiales solo para pasar la prueba del final del día. Un programa menos rígido permite, en cambio, el desarrollo de funciones complejas durante un período de varios días.
Mientras tanto, otras prácticas de desarrollo ágil no se han detenido y, a partir de 2019, [update]XP continúa evolucionando, asimilando más lecciones de las experiencias en el campo, para utilizar otras prácticas. En la segunda edición de Extreme Programming Explained (noviembre de 2004), cinco años después de la primera edición, Beck agregó más valores y prácticas y distinguió entre prácticas primarias y secundarias.
Concepto [ editar ]
Objetivos [ editar ]
Extreme Programming Explained describe la programación extrema como una disciplina de desarrollo de software que organiza a las personas para producir software de mayor calidad de manera más productiva.
XP intenta reducir el costo de los cambios en los requisitos al tener varios ciclos de desarrollo cortos, en lugar de uno largo. En esta doctrina, los cambios son un aspecto natural, ineludible y deseable de los proyectos de desarrollo de software, y deben planificarse, en lugar de intentar definir un conjunto estable de requisitos.
La programación extrema también introduce una serie de valores, principios y prácticas básicos además del marco de programación ágil.
Actividades [ editar ]
XP describe cuatro actividades básicas que se realizan dentro del proceso de desarrollo de software: codificación, prueba, escucha y diseño. Cada una de esas actividades se describe a continuación.
Codificación [ editar ]
Los defensores de XP argumentan que el único producto verdaderamente importante del proceso de desarrollo del sistema es el código: instrucciones de software que una computadora puede interpretar. Sin código, no hay producto que funcione.
La codificación se puede utilizar para encontrar la solución más adecuada. La codificación también puede ayudar a comunicar pensamientos sobre problemas de programación. Un programador que se enfrente a un problema de programación complejo, o que tenga dificultades para explicar la solución a otros programadores, podría codificarlo de una manera simplificada y usar el código para demostrar lo que significan. El código, dicen los defensores de esta posición, es siempre claro y conciso y no se puede interpretar de más de una manera. Otros programadores pueden dar su opinión sobre este código codificando también sus pensamientos.
Probando [ editar ]
Las pruebas son fundamentales para la programación extrema. [9] El enfoque de la programación extrema es que si una pequeña prueba puede eliminar algunas fallas, muchas pruebas pueden eliminar muchas más fallas.
- Las pruebas unitarias determinan si una característica determinada funciona según lo previsto. Los programadores escriben tantas pruebas automatizadas como pueden pensar que podrían "romper" el código; si todas las pruebas se ejecutan correctamente, la codificación está completa. Cada fragmento de código que se escribe se prueba antes de pasar a la siguiente función.
- Las pruebas de aceptación verifican que los requisitos entendidos por los programadores satisfacen los requisitos reales del cliente.
Las pruebas de integración de todo el sistema se alentaron, inicialmente, como una actividad diaria al final del día, para la detección temprana de interfaces incompatibles, para volver a conectarse antes de que las secciones separadas divergieran ampliamente de la funcionalidad coherente. Sin embargo, las pruebas de integración en todo el sistema se han reducido a semanalmente o con menos frecuencia, según la estabilidad de las interfaces generales del sistema. [ cita requerida ]
Escuchando [ editar ]
Los programadores deben escuchar lo que los clientes necesitan que haga el sistema, qué " lógica empresarial " se necesita. Deben comprender estas necesidades lo suficientemente bien como para dar retroalimentación al cliente sobre los aspectos técnicos de cómo el problema podría resolverse o no. La comunicación entre el cliente y el programador se aborda en mayor profundidad en el juego de planificación .
Diseñando [ editar ]
From the point of view of simplicity, of course one could say that system development doesn't 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 many dependencies within a system; this means that changing one part of the system will not affect other parts of the system.[citation needed]
Values[edit]
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[edit]
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[edit]
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 aren't gonna need it" (YAGNI) approach.[10] 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[edit]
Within extreme programming, feedback relates to different dimensions of the system development:
- Feedback from the system: by writing unit tests,[5] 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.[5] To quote Kent Beck, "Optimism is an occupational hazard of programming. Feedback is the treatment."[11]
Courage[edit]
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.[5] 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[edit]
The respect value includes respect for others as well as self-respect. Programmers should never commit changes that break compilation, that make existing unit-tests 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[edit]
The first version of rules for XP was published in 1999 by Don Wells[12] 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[13] 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):
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
Principles[edit]
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[edit]
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 developer's 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 developer's changes cause a failure in some other portion of the system that the developer knows little or nothing about, the automated all-unit-test 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 unit-test 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[edit]
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[edit]
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 customer's requirements have changed dramatically, programmers are to embrace this and plan the new requirements for the next iteration.
Practices[edit]
Extreme programming has been described as having 12 practices, grouped into four areas:
Fine-scale feedback[edit]
- Pair programming[5]
- Planning game
- Test-driven development
- Whole team
Continuous process[edit]
- Continuous integration
- Refactoring or design improvement[5]
- Small releases
[edit]
- Coding standards
- Collective code ownership[5]
- Simple design[5]
- System metaphor
Programmer welfare[edit]
- Sustainable pace
Controversial aspects[edit]
The practices in XP have been heavily debated.[5] Proponents of extreme programming claim that by having the on-site customer[5] 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]
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.[14] This also applies when multiple programming organizations are involved, particularly organizations which compete for shares of projects.[citation needed]
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 it's required by failing tests. Critics compare this to "debugging a system into appearance" and fear this will result in more re-design effort than only re-designing when requirements change.
- 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.
Critics have noted several potential drawbacks,[5] including problems with unstable requirements, no documented compromises of user conflicts, and a lack of an overall design specification or document.
Scalability[edit]
ThoughtWorks has claimed reasonable success on distributed XP projects with up to sixty people.[citation needed]
In 2004, industrial extreme programming (IXP)[15] 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[edit]
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.[6] 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 methodology; example: Project Lifecycles: Waterfall, Rapid Application Development (RAD), 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.[16]
Criticism[edit]
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[17] and Boehm and Turner,[18] Matt Stephens and Doug Rosenberg.[19] Many of the criticisms, however, are believed by Agile practitioners to be misunderstandings of agile development.[20]
In particular, extreme programming has been reviewed and critiqued by Matt Stephens's and Doug Rosenberg's Extreme Programming Refactored.[6]
Criticisms include:
- a methodology is only as effective as the people involved, Agile does not solve this[citation needed]
- often used as a means to bleed money from customers through lack of defining a deliverable product[citation needed]
- lack of structure and necessary documentation[citation needed]
- only works with senior-level developers[citation needed]
- incorporates insufficient software design[citation needed]
- requires meetings at frequent intervals at enormous expense to customers[citation needed]
- requires too much cultural change to adopt[citation needed]
- can lead to more difficult contractual negotiations[citation needed]
- 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.[citation needed]
- 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 scope/requirements[citation needed]
- can increase the risk of scope creep due to the lack of detailed requirements documentation[citation needed]
- Agile is feature-driven; non-functional quality attributes are hard to represent as user stories.[citation needed]
See also[edit]
- 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
- Stand-up meeting
- Timeboxing
References[edit]
- ^ "Human Centred Technology Workshop 2006 ", 2006, PDF, Human Centred Technology Workshop 2006
- ^ a b UPenn-Lectures-design-patterns "Design Patterns and Refactoring", University of Pennsylvania, 2003.
- ^ a b USFCA-edu-601-lecture Extreme Programming.
- ^ "Manifesto for Agile Software Development". Agilemanifesto.org. 2001. Retrieved March 26, 2019.
- ^ a b c d e f g h i j k l m Computerworld-appdev-92 "Extreme Programming", Computerworld (online), December 2001.
- ^ a b c Rosenberg, Doug; Stephens, Matt (2003). Extreme Programming Refactored: The Case Against XP. Apress. ISBN 978-1-59059-096-6.
- ^ Larman 2003.
- ^ Interview with Kent Beck and Martin Fowler. informit.com. March 23, 2001.
- ^ Lisa Crispin; Tip House (2003). Testing Extreme Programming. ISBN 9780321113559.
- ^ "Everyone's a Programmer" by Clair Tristram. Technology Review, November 2003. p. 39.
- ^ Beck, K. (1999). Extreme Programming Explained: Embrace Change. Addison-Wesley. ISBN 978-0-321-27865-4.
- ^ "Extreme Programming Rules". extremeprogramming.org.
- ^ Ken Auer Archived September 20, 2008, at the Wayback Machine
- ^ John Carroll; David Morris (July 29, 2015). Agile Project Management in easy steps, 2nd edition. In Easy Steps. p. 162. ISBN 978-1-84078-703-0.
- ^ Cutter Consortium. "Industrial XP: Making XP Work in Large Organizations - Cutter Consortium". cutter.com.
- ^ Extreme Programming (XP) Six Sigma CMMI.
- ^ McBreen, P. (2003). Questioning Extreme Programming. Boston, MA: Addison-Wesley. ISBN 978-0-201-84457-3.
- ^ Boehm, B.; R. Turner (2004). Balancing Agility and Discipline: A Guide for the Perplexed. Boston, MA: Addison-Wesley. ISBN 978-0-321-18612-6.
- ^ Stephens, Matt; Doug Rosenberg (2004). The irony of extreme programming. MA: Dr Dobbs journal.
- ^ sdmagazine Archived March 16, 2006, at the Wayback Machine
Further reading[edit]
- Ken Auer and Roy Miller. Extreme Programming Applied: Playing To Win, Addison–Wesley.
- Ken Auer; Ron Jeffries; Jeff Canna; Glen B. Alleman; Lisa Crispin; Janet Gregory (2002). "Are Testers eXtinct? How Can Testers Contribute to XP Teams?". Extreme Programming and Agile Methods — XP/Agile Universe 2002. Lecture Notes in Computer Science. 2418. Springer-Verlag. p. 287. doi:10.1007/3-540-45672-4_50. ISBN 978-3-540-44024-6.
- Kent Beck: Extreme Programming Explained: Embrace Change, Addison–Wesley.
- Kent Beck and Martin Fowler: Planning Extreme Programming, Addison–Wesley.
- Kent Beck and Cynthia Andres. Extreme Programming Explained: Embrace Change, Second Edition, Addison–Wesley.
- Alistair Cockburn: Agile Software Development, Addison–Wesley.
- Martin Fowler: Refactoring: Improving the Design of Existing Code, Addison–Wesley.
- Harvey Herela (2005). Case Study: The Chrysler Comprehensive Compensation System. Galen Lab, U.C. Irvine.
- Jim Highsmith. Agile Software Development Ecosystems, Addison–Wesley.
- Ron Jeffries, Ann Anderson and Chet Hendrickson (2000), Extreme Programming Installed, Addison–Wesley.
- Craig Larman & V. Basili (2003). "Iterative and Incremental Development: A Brief History", Computer (IEEE Computer Society) 36 (6): 47–56.
- 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.
External links[edit]
 | Wikimedia Commons has media related to Extreme programming. |
 | Wikiquote has quotations related to: Extreme programming |
- Extreme Programming
- A gentle introduction
- Industrial eXtreme Programming
- Problems and Solutions to XP implementation
- Using an Agile Software Process with Offshore Development – ThoughtWorks' experiences with implementing XP in large distributed projects
| vteSoftware engineering | |||||||
|---|---|---|---|---|---|---|---|
| Fields |
| ||||||
| Concepts |
| ||||||
| Orientations |
| ||||||
| Models |
| ||||||
| Softwareengineers |
| ||||||
| Related fields |
| ||||||
| |||||||
Category
Commons