Agile Software Development - Prácticas y métodos

La totalidad de metodologías ágiles incluyen una relación de prácticas y técnicas que definen como deben generarse requerimientos, diseños, desarrollo, test y gestión de proyecto.

Una de las más recientes sería la de Jurgen  Appelo, 2009. Pueden existir tantas listas diferentes como organizaciones que implementen una metodología ágil. Por compartir una con vosotros, voy a extraer la propuesta de por Pirkka Rannikko en su Tesis.

Project Management

• Pequeñas entregas. Iteraciones cortas, que producen funcionalidades completas y con tareas no variables durante la ejecución del Sprint. 
• Planificación. Se trata del trabajo de creación, elección del siguiente Sprint, a partir del backlog, la lista priorizada y estimada de tareas. Elementos o conceptos requeridos:
• Product, Release y Sprint Backlog
• Sprint Burndow chart / Story Cards
• Ritmo sostenible. El trabajo debe ser realizado bajo un ritmo que sea sostenible indefinidamente. El equipo crea código mejor y de mayor calidad cuando se encuentran en situaciones "saludables", están motivados y disfrutan de su trabajo. La sobrecarga suele suponer un impacto inverso y causar problemas mayores
• Equipos auto-organizados. Durante el Sprint el equipo es responsable para lograr los objetivos del Sprint, y tienen la autoridad/responsabilidad para ejecutar ese trabajo y planificar para conseguirlo, no siendo responsabilidad del project manager dirigir al equipo, si no ayudar a cumplir los objetivos
• Retrospectiva. Reuniones realizadas después de cada Sprint, Entrega o Proyecto donde el equipo comparte sus experiencias y deciden posibles medidas de mejora 
• Meeting diario. Breve encuentro diario para que el equipo coordine su trabajo, el esfuerzo diario, revise el sprint y comparta bloqueos o problemas.

Research

•  On-site customer. Todo el equipo trabaja en una misma sala con representación por parte del cliente (product manager) que es quien trabaja con el equipo en los requisitos, y en la toma de decisiones sobre éstos. Esta presencia mejora la comunicación y reduce la necesidad de documentación. Elementos a generar:
• Story Cards
• User stories. Se trata de la herramienta de Ingeniería en los proyectos ágiles. Son descripciones cortas usadas para planificar y de recordatorio del alcance para analizar su completitud. Estas reflejan adicionalmente una estimación de esfuerzo.
  
• Story Cards

Design

• Simple Design. El objetivo es disponer de un diseño lo mínimo posible para posibilitar la entrega de funcionalidades según la necesidad del cliente. Simple no quiere decir incompleto, simplemente disponer de exclusivamente lo justo y necesario
• Metáforas.   Las metáforas dan soporte a la idea de disponer un diseño simple al proveer un marco de referencia de cómo el equipo debe pensar en el proceso y ayudar a la comunicación sobre el diseño

Programming

• Programación en parejas. Práctica en la que dos desarrolladores programan juntos, compartiendo un ordenador, alineado con aumentar la calidad del código y la comprensión del código. Uno de ellos desarrolla, mientras el otro revisa su código, ayuda a la solución de problemas, y periódicamente alternan sus roles
• Refactoring. El código, en un entorno ágil, es continuamente revisado y restructurado para conseguir diseños más simples y mejores que no alteren el comportamiento externo
• El código pertenece al equipo. El código pertenece a todo el equipo, toda pareja de desarrolladores puede modificar cualquier parte del código. Se trata de una responsabilidad colectiva que debe motivar la resolución de errores, las situaciones de cuello de botella dejan de existir
• Estándares de codificación. Los equipos pactan y siguen una relación de buenas prácticas de como escribir el código para mejorar su mantenibilidad y su lectura.

Testing

• Test-Driven Development (TDD). En TDD los test unitarios se escriben previamente al código. Y cuando disponemos de los test disponibles, y solo entonces, se escribe el código. Este enfoque ayuda a crear una relación comprensible de test y asegura un buen nivel de calidad de código.
• Integración Continua. Todo el código registrado en el control de versiones es automáticamente re-integrador y testeado en un entorno específico. Aplicando este ciclo conseguimos que los problemas se detecten cuando el equipo está creándolo, y elimina el trabajo manual y tedioso que supone una posterior integración manual
• Customer acceptance testing. Representación escrita de los criterios de aceptación por parte del cliente, que pueden llegar a ser automatizados por el equipo. Sirven para validar la coherencia entre lo especificado y lo desarrollado
• Sprint review. A la finalización de cada sprint, tiene lugar un meeting dónde se demuestran los avances a los promotores, con el objetivo de recibir feed-back, analizar el diseño y compartir decisiones futuras.

No la totalidad de estas prácticas son aplicadas siempre, como os podéis imaginar el desarrollo en parejas, pese a beneficioso, está muy poco extendido. También resulta complejo, y esto sí que es más preocupante, tener al cliente con el equipo. Por otra parte, los desarrollos son complejos y requieren de miembros multi-disciplinares ... experto en bd, experto en front-end, experto en back-end ... la responsabilidad colectiva puede existir, pero en realidad no podemos obviar situaciones de cuello de botella de difícil resolución mediante otros miembros del equipo, así como no entender parte del código como del experto que lo ha desarrollado. Otro punto preocupante de baja adopción es que los test conduzcan al desarrollo.

Existen igualmente estudios relativos a las medidas más efectivas, lideradas sin lugar a dudas por la Integración Continua, de manera diferencial por encima de los meetings diarios, el concepto de sprint plan, etc.

Intentaremos, aunque sea mencionar o hacer referencia a otros medios especializados, que hagan mención a qué herramientas (sí sí ... ya se que el principio de la programación ágil es dar prioridad al equipo y no a las herramientas, pero creo que puede ser interesante, sobretodo en el ámbito de la automatización requerida para la integración continua, algunas referencias de interés) como Bamboo, Continuum, etc. se utilizan para implementar un entorno de integración continua.

Por último, las prácticas, como ya he comentado con anterioridad, son personales para cada organización, para cada equipo, y además ... es algo vivo que debe madurar de la mano de la maduración del equipo. Es habitual iterar, modificar, adaptar durante un proyecto las reglas en función del progreso, o la nuevas necesidades del equipo.

Saludos,