Programación extrema
La programación extrema o eXtreme Programming (en adelante, XP) es una metodología de desarrollo de la ingeniería de software formulada por Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999).
Al igual que estos, la programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad. Los defensores de la XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos.
Se puede considerar la programación extrema como la adopción de las mejores metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinámica durante el ciclo de vida del software.
Historia
Kent Beck desarrolló una programación extrema durante su trabajo en el proyecto de nóminas para el Sistema de Compensación Integral de Chrysler (C3).[1] 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). Chrysler canceló el proyecto C3 en febrero de 2000, después de siete años, cuando Daimler-Benz adquirió la empresa. [2]
Muchas de las prácticas de la programación extrema existen desde hace 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 Mercury de la NASA, a principios de la década de 1960.[3] Para acortar el tiempo total de desarrollo, se desarrollaban algunos documentos de prueba formales (como para las pruebas de aceptación) en paralelo con (o poco antes) que el software estuviera listo para la prueba. Un grupo de prueba independiente de la NASA podía 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 al 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
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 preferido 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óminas de Chrysler como objeto de investigación, con Smalltalk como lenguaje y GemStone como capa de acceso a datos. Chrysler contrató a Kent Beck,[1] 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:
La primera vez que me pidieron que liderara 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, la WikiWikiWeb de Cunningham. Varios colaboradores discutieron y ampliaron las ideas, y resultaron algunas metodologías derivadas (véase desarrollo ágil de software).
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.
Valores
Los valores originales de la programación extrema son: simplicidad, comunicación, retroalimentación (feedback) y coraje. Un quinto valor, respeto, fue añadido en la segunda edición de Extreme Programming Explained. Los cinco valores se detallan a continuación:
Simplicidad
La simplicidad es la base de la programación extrema. Se simplifica el diseño para agilizar el desarrollo y facilitar el mantenimiento. Un diseño complejo del código junto a sucesivas modificaciones por parte de diferentes desarrolladores hacen que la complejidad aumente exponencialmente.
Para mantener la simplicidad es necesaria la refactorización del código, esta es la manera de mantener el código simple a medida que crece.
También se aplica la simplicidad en la documentación, de esta manera el código debe comentarse en su justa medida, intentando eso sí que el código esté autodocumentado. Para ello se deben elegir adecuadamente los nombres de las variables, métodos y clases. Los nombres largos no decrementan la eficiencia del código ni el tiempo de desarrollo gracias a las herramientas de autocompletado y refactorización que existen actualmente.
Aplicando la simplicidad junto con la autoría colectiva del código y la programación por parejas se asegura que cuanto más grande se haga el proyecto, todo el equipo conocerá más y mejor el sistema completo.
Comunicación
La comunicación se realiza de diferentes formas. Para los programadores el código comunica mejor cuanto más simple sea. Si el código es complejo hay que esforzarse para hacerlo legible. El código autodocumentado es más fiable que los comentarios ya que estos últimos pronto quedan desfasados con el código a medida que es modificado. Debe comentarse solo aquello que no va a variar, por ejemplo el objetivo de una clase o la funcionalidad de un método.
Las pruebas unitarias son otra forma de comunicación ya que describen el diseño de las clases y los métodos al mostrar ejemplos concretos de como utilizar su funcionalidad. Los programadores se comunican constantemente gracias a la programación por parejas. La comunicación con el cliente es fluida ya que el cliente forma parte del equipo de desarrollo. El cliente decide qué características tienen prioridad y siempre debe estar disponible para solucionar dudas.
Retroalimentación (feedback)
Al estar el cliente integrado en el proyecto, su opinión sobre el estado del proyecto se conoce en tiempo real.
Al realizarse ciclos muy cortos tras los cuales se muestran resultados, se minimiza el tener que rehacer partes que no cumplen con los requisitos y ayuda a los programadores a centrarse en lo que es más importante.
Considérense los problemas que derivan de tener ciclos muy largos. Meses de trabajo pueden tirarse por la borda debido a cambios en los criterios del cliente o malentendidos por parte del equipo de desarrollo. El código también es una fuente de retroalimentación gracias a las herramientas de desarrollo. Por ejemplo, las pruebas unitarias informan sobre el estado de salud del código. Ejecutar las pruebas unitarias frecuentemente permite descubrir fallos debidos a cambios recientes en el código.
Coraje o valentía
Muchas de las prácticas implican valentía. Una de ellas es siempre diseñar y programar para hoy y no para mañana. Esto es un esfuerzo para evitar empantanarse en el diseño y requerir demasiado tiempo y trabajo para implementar el resto del proyecto. La valentía le permite a los desarrolladores que se sientan cómodos con reconstruir su código cuando sea necesario. Esto significa revisar el sistema existente y modificarlo si con ello los cambios futuros se implementarán más fácilmente. Otro ejemplo de valentía es saber cuando desechar un código: valentía para quitar código fuente obsoleto, sin importar cuanto esfuerzo y tiempo se invirtió en crear ese código. Además, valentía significa persistencia: un programador puede permanecer sin avanzar en un problema complejo por un día entero, y luego lo resolverá rápidamente al día siguiente, solo si es persistente.
Respeto
El respeto se manifiesta de varias formas. Los miembros del equipo se respetan los unos a otros, porque los programadores no pueden realizar cambios que hacen que las pruebas existentes fallen o que demore el trabajo de sus compañeros. Los miembros respetan su trabajo porque siempre están luchando por la alta calidad en el producto y buscando el diseño óptimo o más eficiente para la solución a través de la refactorización del código. Los miembros del equipo respetan el trabajo del resto no haciendo menos a otros, una mejor autoestima en el equipo eleva su ritmo de producción.
Características fundamentales
Las características fundamentales del método son:
- Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras.
- Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba antes de la codificación. Véase, por ejemplo, las herramientas de prueba JUnit orientada a Java, DUnit orientada a Delphi, NUnit para la plataforma.NET o PHPUnit para PHP. Estas tres últimas inspiradas en JUnit, la cual, a su vez, se inspiró en SUnit, el primer framework orientado a realizar tests, realizado para el lenguaje de programación Smalltalk.
- Programación en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. La mayor calidad del código escrito de esta manera -el código es revisado y discutido mientras se escribe- es más importante que la posible pérdida de productividad inmediata.
- Frecuente integración del equipo de programación con el cliente o usuario. Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo.
- Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer entregas frecuentes.
- Refactorización del código, es decir, reescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorización no se ha introducido ningún fallo.
- Propiedad del código compartida: en vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles errores serán detectados.
- Simplicidad en el código: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá añadir funcionalidad si es necesario. La programación extrema apuesta que es más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo.
La simplicidad y la comunicación son extraordinariamente complementarias. Con más comunicación resulta más fácil identificar qué se debe y qué no se debe hacer. Cuanto más simple es el sistema, menos tendrá que comunicar sobre este, lo que lleva a una comunicación más completa, especialmente si se puede reducir el equipo de programadores.
Roles
Programador
Produce el código del sistema. Es la esencia del equipo.
Test developer
Produce el código de los test unitarios del sistema. Es uno de los roles más importantes.
Cliente
Escribe las historias de usuario y las pruebas funcionales para validar su implementación. Asigna la prioridad a las historias de usuario y decide cuáles se implementan en cada iteración centrándose en aportar el mayor valor de negocio.
Tester
Interpreta el pedido del cliente y ayuda al equipo de desarrollo a escribir las pruebas funcionales. Ejecuta pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para pruebas.
Tracker
Es el encargado de seguimiento. Proporciona realimentación al equipo. Debe verificar el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, comunicando los resultados para mejorar futuras estimaciones.
Entrenador (coach)
Responsable del proceso global. Guía a los miembros del equipo para seguir el proceso correctamente.
Consultor
Es un miembro externo del equipo con un conocimiento específico en algún tema necesario para el proyecto. Ayuda al equipo a resolver un problema específico. Además este tiene que investigar según los requerimientos.
Gestor (Big boss)
Es el dueño de la tienda y el vínculo entre clientes y programadores. Su labor esencial es la coordinación.
Véase también
Referencias
- ↑ Copeland, Lee (3 de diciembre de 2001). «Extreme Programming». Computerworld (en inglés). Consultado el 6 de octubre de 2020.
- Stephens, Matt, 1971- (2003). Extreme programming refactored : the case against XP. Apress. ISBN 1-59059-096-1. OCLC 52359427. Consultado el 6 de octubre de 2020.
- Larman, C.; Basili, V.R. (2003-06). «Iterative and incremental developments. a brief history». Computer 36 (6): 47-56. ISSN 0018-9162. doi:10.1109/mc.2003.1204375. Consultado el 6 de octubre de 2020.
Enlaces externos
- Sitio dedicado a la divulgación de la programación extrema (en inglés)
- Resumen de programación extrema