Extreme Programming: valores, principios y prácticas.
Tiempo atrás en los años 90’s el auge del Internet impulsó un cambio en el desarrollo de software ya que el éxito de una empresa dependía (al igual que ahora) de la velocidad en que pudiera crecer y llevar productos al mercado, fue en este entorno que Kent Beck creó eXtreme Programming (XP) un conjunto de prácticas en las que los desarrolladores tienen como reto que ir más allá de sus capacidades mientras realizan estas prácticas (de ahí viene el “extremo” del título del marco).
Antes de comenzar y para obtener una mejor comprensión de estas prácticas, vamos a discutir primero los valores y principios de XP:
Comunicación: todos los integrantes de un equipo trabajan conjuntamente en cada etapa del proyecto.
Simplicidad: los desarrolladores se esfuerzan por escribir código simple trayendo más valor al producto, ya que ahorra tiempo y esfuerzos.
Retroalimentación: los miembros del equipo entregan software con frecuencia, obtener retroalimentación sobre él, y mejorar un producto de acuerdo con los nuevos requisitos.
Respeto: cada persona asignada a un proyecto contribuye a un objetivo común.
Coraje: los programadores evalúan objetivamente sus propios resultados sin excusas y siempre están dispuestos a responder a los cambios.
Estos valores representan la mentalidad de nuestro equipo, incentivando así a que como equipo se haga todo lo posible en el camino hacia el logro de un objetivo común. Los principios de XP derivan de estos valores y los reflejan de maneras más concretas.
La mayoría de los investigadores denotan 5 principios de XP como:
Retroalimentación rápida: los miembros del equipo entienden la retroalimentación dada y reaccionan de inmediato.
Simplicidad asumida: los desarrolladores deben centrarse en el trabajo que es importante en este momento (YAGNI = You Ain’t Gonna Need It y DRY = Don’t Repeat Yourself).
Cambios incrementales: pequeños cambios realizados a un producto funcionan mejor que los grandes hechos a la vez.
Aceptar el cambio: Si un cliente piensa que un producto necesita ser cambiado, nuestro equipo de desarrollo debe apoyar esta decisión y planear cómo implementar nuevos requisitos.
Trabajo de calidad: un equipo que trabaja bien hace un producto valioso y se siente orgulloso de ello.
Después de conocer los pilares principales de XP es el momento de aprender acerca de las prácticas que convierten a nuestro equipo de desarrollo de software en equipos de ensueño…
Prácticas de Extreme Programming
XP sugiere usar 12 prácticas mientras desarrollamos software. Como XP está definido por valores y principios, sus prácticas también los representan y pueden agruparse en cuatro grupos:
Feedback
Test-driven development: La calidad del software deriva de ciclos de desarrollo cortos que, a su vez, permiten recibir retroalimentación frecuente. Los equipos XP practican la técnica de desarrollo guiada por pruebas (TTD) que implica escribir una prueba unitaria automatizada antes del propio código. De acuerdo con este enfoque, cada pieza de código debe pasar la prueba para ser liberado. Así, los ingenieros de software por lo tanto se centran en escribir código capaz de lograr la función necesaria. Así es como TDD permite a los programadores usar retroalimentación prácticamente inmediata para producir software confiable. Puede obtener más información sobre cómo mejorar las pruebas de software en nuestro artículo dedicado.
The Planning Game: Esta es una reunión que se produce al principio de cada sprint. El equipo de desarrollo y el cliente se reúnen para discutir y aprobar las características de un producto. Al final del juego de planificación, los desarrolladores planean el próximo sprint y liberación, asignando tareas para cada uno de ellos.
On-site Customer: De acuerdo con XP, el cliente final debe participar plenamente en el desarrollo. El cliente debe estar presente todo el tiempo para responder a las preguntas del equipo y establecer prioridades.
Pair Programming: Esta práctica requiere que dos programadores trabajen conjuntamente en el mismo código. Mientras que el primer desarrollador se centra en la escritura, el otro revisa el código, sugiere mejoras, y corrige los errores en el camino. Este trabajo en equipo da como resultado software de alta calidad, un intercambio de conocimientos más rápido, pero lleva 15 a 60 por ciento más de tiempo. En este sentido, es más razonable tratar de programación par para proyectos a largo plazo.
Continual Process
Code Refactoring: La refactorización consiste en eliminar la redundancia, eliminar las funciones innecesarias, aumentar la coherencia del código y, al mismo tiempo, desacoplar elementos. Mantenga su código limpio y simple, así que usted puede entender fácilmente y modificarlo cuando sea necesario sería el Consejo de cualquier miembro del equipo de XP.
Continuous Integration: Los desarrolladores siempre mantienen el sistema totalmente integrado. Los programadores discuten qué partes del código pueden ser reutilizadas o compartidas y de esta manera ellos saben exactamente qué funcionalidad necesitan desarrollar. La política de código compartido ayuda a eliminar los problemas de integración.
Small Releases: Esta práctica sugiere lanzar la primera versión rápidamente y desarrollar más el producto haciendo actualizaciones pequeñas e incrementales. Las pequeñas versiones permiten a los desarrolladores recibir comentarios con frecuencia, detectar errores de forma prematura y supervisar el funcionamiento del producto en la producción.
Code Understanding
Simple Design: El mejor diseño para el software es el más simple que funciona. Si se encuentra alguna complejidad, debe eliminarse. El diseño correcto debe pasar todas las pruebas, no tener código duplicado, y contener el menor número posible de métodos y clases. También debe reflejar claramente la intención del programador.
Coding Standards: Un equipo debe tener conjuntos comunes de prácticas de codificación utilizando los mismos formatos y estilos para la redacción de código. La aplicación de estándares permite a todos los miembros del equipo leer, compartir y refactorizar el código con facilidad, rastrear quién trabajó en ciertas piezas de código, así como hacer que el aprendizaje sea más rápido para otros programadores. El código escrito de acuerdo con las mismas reglas fomenta la propiedad colectiva.
Collective Code Ownership: Esta práctica declara la responsabilidad de todo un equipo por el diseño de un sistema. Cada miembro del equipo puede revisar y actualizar el código. Los desarrolladores que tengan acceso al código no entrarán en una situación en la que no sepan el lugar adecuado para agregar una nueva función. La práctica ayuda a evitar la duplicación de código. La implementación de la propiedad colectiva del código alienta al equipo a cooperar más y a sentirse libre de aportar nuevas ideas.
System Metaphor: La metáfora del sistema representa un diseño simple que tiene un conjunto de ciertas cualidades. En primer lugar, un diseño y su estructura deben ser comprensibles para la gente nueva. Deberían poder empezar a trabajar en él sin pasar demasiado tiempo examinando las especificaciones. En segundo lugar, el nombramiento de las clases y los métodos debe ser coherente. Los desarrolladores deben apuntar a nombrar un objeto como si ya existiera, lo que hace comprensible el diseño general del sistema.
Programmer’s Work Conditions
40-Hour Week: Los proyectos de XP requieren que los desarrolladores trabajen rápido, sean eficientes y sostengan la calidad del producto. Para cumplir con estos requisitos, deben sentirse bien y descansados. Mantener el equilibrio entre el trabajo y la vida impide que los profesionales se quemen. En XP, el número óptimo de horas de trabajo no debe exceder las 45 horas a la semana. Un tiempo suplementario a la semana es posible sólo si no habrá ninguno la semana después.
Cuando Utilizar XP
Es importante asegurarse de que el tamaño, la estructura y la experiencia de una empresa, así como la base de conocimientos del personal permiten aplicar las prácticas de XP.
Desarrollo altamente adaptativo: XP fue diseñado para ayudar a los equipos de desarrollo a adaptarse a los requerimientos de cambio rápido.
Proyectos arriesgados: Los equipos que aplican las prácticas de XP tienen más probabilidades de evitar problemas relacionados con el trabajo en un nuevo sistema, especialmente cuando un propietario de un producto establece plazos estrictos para un proyecto.
Equipos pequeños: Las prácticas de XP son eficientes para equipos que no superan las 12 personas.
Pruebas automáticas: Otro factor que puede influir en la elección de XP es la capacidad de los desarrolladores para crear y ejecutar pruebas unitarias.
Participación del cliente disponible: XP requiere que los clientes, desarrolladores y gerentes trabajen codo a codo, asegúrese de que su cliente pueda pasar tiempo en la oficina hasta que finalice un proyecto.
Conclusión
Extreme Programming es un enfoque de desarrollo de software basado en valores de simplicidad, comunicación, retroalimentación y coraje.
Las empresas que construyen su flujo de trabajo en los principios y valores de XP crean una atmósfera competitiva pero motivacional dentro y entre equipos. Los programadores aprecian la entrada del proyecto de cada uno, entregan software rápidamente porque pueden distinguir las tareas relevantes de las innecesarias. Reaccionan rápidamente a la retroalimentación dándose cuenta de que es una crítica razonable dirigida a hacer un producto mejor.
Los equipos de XP no consideran cada desafío técnico como un problema, sino que lo piensan como una forma de desarrollar habilidades.