Extreme Programming (XP) es un marco de desarrollo de software ágil que tiene como objetivo producir software de mayor calidad y una mayor calidad de vida para el equipo de desarrollo. XP es el más específico de los marcos ágiles con respecto a las prácticas de ingeniería apropiadas para el desarrollo de software.
Cuando sea aplicable
Las características generales donde XP es apropiado fueron descritas por Don Wells en www.extremeprogramming.org :
- Requisitos de software que cambian dinámicamente
- Riesgos causados por proyectos de tiempo fijo usando nueva tecnología
- Equipo de desarrollo extendido pequeño y ubicado en el mismo lugar
- La tecnología que está utilizando permite pruebas unitarias y funcionales automatizadas
Debido a la especificidad de XP en lo que respecta a su conjunto completo de prácticas de ingeniería de software, existen varias situaciones en las que es posible que no desee practicar XP por completo. La publicación Cuando XP no es apropiado en C2 Wiki es probablemente un buen lugar para comenzar a encontrar ejemplos en los que es posible que no desee usar XP.
Si bien no puede usar todo el marco XP en muchas situaciones, eso no debería impedirle usar tantas prácticas como sea posible dado su contexto.
Valores
Los cinco valores de XP son la comunicación, la sencillez, la retroalimentación, el coraje y el respeto, y se describen con más detalle a continuación.
Comunicación
El desarrollo de software es inherentemente un deporte de equipo que se basa en la comunicación para transferir conocimientos de un miembro del equipo a todos los demás en el equipo. XP enfatiza la importancia del tipo apropiado de comunicación: discusión cara a cara con la ayuda de una pizarra blanca u otro mecanismo de dibujo.
Sencillez
Simplicidad significa «¿qué es lo más simple que funcionará?» El propósito de esto es evitar el desperdicio y hacer solo las cosas absolutamente necesarias, como mantener el diseño del sistema lo más simple posible para que sea más fácil de mantener, respaldar y revisar. La simplicidad también significa abordar solo los requisitos que conoce; no intentes predecir el futuro.
Retroalimentación
A través de comentarios constantes sobre sus esfuerzos anteriores, los equipos pueden identificar áreas de mejora y revisar sus prácticas. La retroalimentación también es compatible con el diseño simple. Su equipo crea algo, recopila comentarios sobre su diseño e implementación, y luego ajusta su producto en el futuro.
Coraje
Kent Beck definió el coraje como “una acción eficaz frente al miedo” (Explicación de la programación extrema, pág. 20). Esta definición muestra una preferencia por la acción basada en otros principios para que los resultados no sean perjudiciales para el equipo. Necesita coraje para plantear cuestiones organizativas que reducen la eficacia de su equipo. Necesitas coraje para dejar de hacer algo que no funciona y probar otra cosa. Necesita coraje para aceptar y actuar sobre la retroalimentación, incluso cuando es difícil de aceptar.
Respeto
Los miembros de su equipo deben respetarse unos a otros para poder comunicarse entre sí, proporcionar y aceptar comentarios que honren su relación y trabajar juntos para identificar diseños y soluciones simples.
Prácticas
El núcleo de XP es el conjunto interconectado de prácticas de desarrollo de software que se enumeran a continuación. Si bien es posible realizar estas prácticas de forma aislada, muchos equipos han descubierto que algunas prácticas refuerzan a las demás y deben realizarse en conjunto para eliminar por completo los riesgos que a menudo enfrenta en el desarrollo de software.
Las Prácticas XP han cambiado un poco desde que se introdujeron inicialmente. Las doce prácticas originales se enumeran a continuación.
- El juego de planificación
- Pequeños lanzamientos
- Metáfora
- Diseño simple
- Pruebas
- refactorización
- Programación en pareja
- Propiedad colectiva
- Integración continua
- semana de 40 horas
- Cliente en el sitio
- Estándar de codificación
A continuación se encuentran las descripciones de las prácticas tal como se describen en la segunda edición de Extreme Programming Explained Embrace Change. Estas descripciones incluyen mejoras basadas en las experiencias de muchos que practican la programación extrema y reflejan un conjunto de prácticas más prácticas.
Sentarse juntos
Dado que la comunicación es uno de los cinco valores de XP, y la mayoría de las personas está de acuerdo en que la conversación cara a cara es la mejor forma de comunicación, haga que su equipo se siente en el mismo espacio sin barreras para la comunicación, como las paredes de los cubículos.
Todo el equipo
Un grupo interfuncional de personas con los roles necesarios para un producto forman un solo equipo. Esto significa que las personas con una necesidad, así como todas las personas que desempeñan algún papel en la satisfacción de esa necesidad, trabajan juntas a diario para lograr un resultado específico.
Espacio de trabajo informativo
Configure el espacio de su equipo para facilitar la comunicación cara a cara, permita que las personas tengan algo de privacidad cuando la necesiten y haga que el trabajo del equipo sea transparente entre ellos y para las partes interesadas fuera del equipo. Utilice Radiadores de información para comunicar activamente información actualizada.
Trabajo Energizado
Eres más efectivo en el desarrollo de software y en todo el trabajo de conocimiento cuando estás concentrado y libre de distracciones.
El trabajo energizado significa tomar medidas para asegurarse de que sea capaz física y mentalmente de entrar en un estado de concentración. Esto significa que no trabaje demasiado usted mismo (ni permita que otros lo hagan demasiado). También significa mantenerse saludable y mostrar respeto a sus compañeros de equipo para mantenerlos saludables.
Programación en pareja
Programación en pareja significa que todo el software de producción es desarrollado por dos personas sentadas en la misma máquina. La idea detrás de esta práctica es que dos cerebros y cuatro ojos son mejores que un cerebro y dos ojos. Efectivamente, obtiene una revisión continua del código y una respuesta más rápida a los problemas persistentes que pueden detener a una persona en seco.
Los equipos que han utilizado la programación en pares han descubierto que mejora la calidad y en realidad no toma el doble de tiempo porque pueden resolver los problemas más rápido y se concentran más en la tarea en cuestión, creando así menos código para lograr lo mismo.
Cuentos
Describa lo que el producto debería hacer en términos significativos para los clientes y usuarios. Estas historias pretenden ser descripciones breves de las cosas que los usuarios quieren poder hacer con el producto que se puede usar para planificar y servir como recordatorios para conversaciones más detalladas cuando el equipo se dedique a realizar esa historia en particular.
Ciclo Semanal
El Ciclo Semanal es sinónimo de una iteración . En el caso de XP, el equipo se reúne el primer día de la semana para reflexionar sobre el progreso hasta la fecha, el cliente elige las historias que le gustaría entregar esa semana y el equipo determina cómo abordará esas historias. El objetivo para el final de la semana es tener funciones probadas en ejecución que realicen las historias seleccionadas.
La intención detrás del período de entrega en caja de tiempo es producir algo para mostrar al cliente para recibir comentarios.
Ciclo Trimestral
El Ciclo Trimestral es sinónimo de lanzamiento. El propósito es mantener el trabajo detallado de cada ciclo semanal en el contexto del proyecto general. El cliente establece el plan general para el equipo en términos de las características deseadas dentro de un área en particular, lo que brinda al equipo una vista del bosque mientras están en los árboles y también ayuda al cliente a trabajar con otras partes interesadas que pueden necesito alguna idea de cuándo estarán disponibles las funciones.
Recuerde que cuando planifique un ciclo trimestral, la información sobre cualquier historia en particular se encuentra en un nivel relativamente alto, el orden de entrega de la historia dentro de un ciclo trimestral puede cambiar y las historias incluidas en el ciclo trimestral pueden cambiar. Si puede revisar el plan semanalmente después de cada ciclo semanal, puede mantener a todos informados tan pronto como esos cambios sean evidentes para minimizar las sorpresas.
Flojo
La idea detrás de la holgura en términos de XP es agregar algunas tareas o historias de baja prioridad en sus ciclos semanales y trimestrales que se pueden eliminar si el equipo se atrasa en tareas o historias más importantes. Dicho de otra manera, tenga en cuenta la variabilidad inherente en las estimaciones para asegurarse de tener una buena oportunidad de cumplir con sus pronósticos.
Construcción de diez minutos
El objetivo con Ten-Minute Build es construir automáticamente todo el sistema y ejecutar todas las pruebas en diez minutos. Los fundadores de XP sugirieron un marco de tiempo de 10 minutos porque si un equipo tiene una compilación que lleva más tiempo, es menos probable que se ejecute con frecuencia, lo que introduce más tiempo entre errores.
Esta práctica alienta a su equipo a automatizar su proceso de compilación para que sea más probable que lo haga de manera regular y que use ese proceso de compilación automatizado para ejecutar todas sus pruebas.
Esta práctica apoya la práctica de la Integración Continua y está respaldada por la práctica de Test First Development .
Integración continua
La integración continua es una práctica en la que los cambios de código se prueban inmediatamente cuando se agregan a una base de código más grande. El beneficio de esta práctica es que puede detectar y solucionar problemas de integración antes.
La mayoría de los equipos temen el paso de integración de código debido al descubrimiento inherente de conflictos y problemas que resultan. La mayoría de los equipos adoptan el enfoque «Si duele, evítelo el mayor tiempo posible».
Los practicantes de XP sugieren “si te duele, hazlo más a menudo”.
El razonamiento detrás de ese enfoque es que si experimenta problemas cada vez que integra el código, y le lleva un tiempo encontrar dónde están los problemas, tal vez debería integrarlos más a menudo para que, si hay problemas, sean mucho más fáciles de encontrar porque hay hay menos cambios incorporados en la compilación.
Esta práctica requiere algo de disciplina adicional y depende en gran medida de Ten Minute Build y Test First Development.
Programación de prueba primero
En lugar de seguir el camino normal de:
desarrollar código -> escribir pruebas -> ejecutar pruebas
La práctica de la Programación Test-First sigue el camino de:
Escribir prueba automatizada fallida -> Ejecutar prueba fallida -> desarrollar código para hacer que la prueba pase -> ejecutar prueba -> repetir
Al igual que con la integración continua, la programación Test-First reduce el ciclo de comentarios para que los desarrolladores identifiquen y resuelvan problemas, lo que reduce la cantidad de errores que se introducen en la producción.
Diseño Incremental
La práctica del diseño incremental sugiere que haga un poco de trabajo por adelantado para comprender la perspectiva de amplitud adecuada del diseño del sistema y luego profundice en los detalles de un aspecto particular de ese diseño cuando entregue características específicas. Este enfoque reduce el costo de los cambios y le permite tomar decisiones de diseño cuando sea necesario en función de la información más actualizada disponible.
La práctica de Refactorización se incluyó originalmente entre los 12 principales, pero se incorporó a la práctica de Diseño Incremental. La refactorización es una excelente práctica para mantener el diseño simple, y uno de los usos más recomendados de la refactorización es eliminar la duplicación de procesos.
Poles
Aunque la programación extrema especifica prácticas particulares que debe seguir su equipo, en realidad no establece roles específicos para las personas de su equipo.
Dependiendo de la fuente que lea, no hay orientación o hay una descripción de cómo se comportan los roles que normalmente se encuentran en proyectos más tradicionales en proyectos de programación extrema. Aquí hay cuatro roles más comunes asociados con la programación extrema:
El cliente
El rol de Cliente es responsable de tomar todas las decisiones comerciales relacionadas con el proyecto, incluidas:
- ¿Qué debe hacer el sistema (qué características se incluyen y qué logran)?
- ¿Cómo sabemos cuándo el sistema está terminado (cuáles son nuestros criterios de aceptación)?
- ¿Cuánto tenemos que gastar (cuál es la financiación disponible, cuál es el caso de negocio)?
- ¿Qué debemos hacer a continuación (en qué orden entregamos estas funciones)?
Se espera que el Cliente XP participe activamente en el proyecto e idealmente se convierta en parte del equipo.
Se supone que el cliente de XP es una sola persona; sin embargo, la experiencia ha demostrado que una sola persona no puede proporcionar adecuadamente toda la información comercial relacionada con un proyecto. Su equipo debe asegurarse de obtener una imagen completa de la perspectiva comercial, pero tener algunos medios para lidiar con los conflictos en esa información para que pueda obtener una dirección clara.
El desarrollador
Debido a que XP no tiene mucha necesidad de definición de roles, todos los miembros del equipo (con la excepción del cliente y un par de roles secundarios que se enumeran a continuación) se etiquetan como desarrolladores. Los desarrolladores son responsables de realizar las historias identificadas por el Cliente. Debido a que diferentes proyectos requieren una combinación diferente de habilidades, y debido a que el método XP se basa en un equipo multifuncional que brinda la combinación adecuada de habilidades, los creadores de XP no sintieron la necesidad de una mayor definición de funciones.
El rastreador
Algunos equipos pueden tener un rastreador como parte de su equipo. Este suele ser uno de los desarrolladores que dedica parte de su tiempo cada semana a desempeñar este papel adicional. El objetivo principal de este rol es realizar un seguimiento de las métricas relevantes que el equipo considera necesarias para realizar un seguimiento de su progreso e identificar áreas de mejora. Las métricas clave que su equipo puede rastrear incluyen la velocidad, los motivos de los cambios en la velocidad, la cantidad de horas extra trabajadas y las pruebas aprobadas y reprobadas.
Este no es un rol obligatorio para su equipo y, por lo general, solo se establece si su equipo determina una verdadera necesidad de realizar un seguimiento de varias métricas.
El entrenador
Si su equipo recién está comenzando a aplicar XP, puede que le resulte útil incluir un Entrenador en su equipo. Por lo general, es un consultor externo o alguien de otra parte de su organización que ha usado XP antes y está incluido en su equipo para ayudar a guiar a los otros miembros del equipo en las Prácticas XP y ayudar a su equipo a mantener su autodisciplina.
El valor principal del entrenador es que ya lo han pasado antes y pueden ayudar a su equipo a evitar los errores que cometen la mayoría de los equipos nuevos.
Ciclo vital
Para describir XP en términos de un ciclo de vida, probablemente sea más apropiado revisar el concepto de ciclo semanal y ciclo trimestral.
Primero, comience describiendo los resultados deseados del proyecto haciendo que los clientes definan un conjunto de historias. A medida que se crean estas historias, el equipo estima el tamaño de cada historia. Esta estimación del tamaño, junto con el beneficio relativo estimado por el cliente, puede proporcionar una indicación del valor relativo que el cliente puede usar para determinar la prioridad de las historias.
Si el equipo identifica algunas historias que no pueden estimar porque no entienden todas las consideraciones técnicas involucradas, pueden introducir un pico para realizar una investigación enfocada en esa historia en particular o en un aspecto común de varias historias. Los picos son marcos de tiempo breves y limitados en el tiempo que se reservan con el fin de investigar un aspecto particular del proyecto. Los picos pueden ocurrir antes de que comiencen las iteraciones regulares o junto con las iteraciones en curso.
Luego, todo el equipo se reúne para crear un plan de lanzamiento que todos consideren razonable. Este plan de lanzamiento es un primer paso en las historias que se entregarán en un trimestre o lanzamiento en particular. Las historias entregadas deben basarse en el valor que brindan y las consideraciones sobre cómo las diversas historias se apoyan entre sí.
Luego, el equipo se lanza a una serie de ciclos semanales. Al comienzo de cada ciclo semanal, el equipo (incluido el cliente) se reúne para decidir qué historias se realizarán durante esa semana. Luego, el equipo divide esas historias en tareas que se completarán dentro de esa semana.
Al final de la semana, el equipo y el cliente revisan el progreso hasta la fecha y el cliente puede decidir si el proyecto debe continuar o si se ha entregado suficiente valor.
Orígenes
XP se usó por primera vez en el programa Chrysler Comprehensive Compensation (C3) que se inició a mediados de los 90 y cambió a un proyecto XP cuando Kent Beck se incorporó al proyecto para mejorar el rendimiento del sistema. Terminó agregando a un par de personas más, incluido Ron Jeffries, al equipo y cambiando la forma en que el equipo abordaba el desarrollo. Este proyecto ayudó a enfocar la metodología XP y los varios libros escritos por personas que participaron en el proyecto ayudaron a difundir el conocimiento y la adaptación de este enfoque.
Contribuciones primarias
La principal contribución de XP al mundo del desarrollo de software es una colección interdependiente de prácticas de ingeniería que los equipos pueden usar para ser más efectivos y producir código de mayor calidad. Muchos equipos que adoptan Agile comienzan usando un marco diferente y cuando identifican la necesidad de prácticas de ingeniería más disciplinadas, adoptan varias, si no todas, las prácticas de ingeniería propugnadas por XP.
Una contribución adicional e igualmente importante de XP es el enfoque en la excelencia en la práctica. El método prescribe un pequeño número de prácticas absolutamente esenciales y anima a los equipos a realizar esas prácticas lo mejor que puedan, casi al extremo. De aquí viene el nombre. No porque las prácticas en sí mismas sean necesariamente radicales (aunque algunos consideran que algunas de ellas están bastante alejadas), sino que los equipos se enfocan continuamente en mejorar continuamente su capacidad para realizar esas pocas prácticas.
