martes, 23 de noviembre de 2010

Diseño Ágil

El presente post está basado en las conclusiones e ideas que surgieron en la sesión del mismo nombre (Diseño Ágil) en el reciente Agile Open Spain 2010 de Barcelona. La sesión, egoístamente propuesta por mi (:P), tenía cómo objetivo el determinar aquellas técnicas o maneras de diseño que mejor pueden funcionar en equipos que trabajan de manera ágil, ya sea con Scrum o con cualquier otra metodología, aunque al final el tema se desvió un poco y se acabó hablando de algunas otras cosas, aunque todas ellas muy interesantes!

Se empezó hablando de la necesidad de eliminar los grandes diseños y arquitecturas iniciales para poder tener una mejor respuesta ante cambios en los requisitos o las necesidades del cliente, y para evitar el sobrediseño, algo que suele suceder muy a menudo. En su lugar se apuesta mas por un micro diseño o arquitectura inicial a alto nivel que permita a las personas que van a trabajar en el proyecto hacerse una idea general del mismo: los diferentes subsistemas que intervienen, como se relacionan entre ellos, etc. pero sin entrar en demasiados detalles. Este micro-diseño se realizaría en el Sprint 0, antes de empezar con el desarrollo de las diferentes funcionalidades del sistema.

A partir de aquí se empezaron a enumerar las diferentes técnicas que utiliza la gente desde el punto de vista del desarrollo para garantizar un buen diseño, por ejemplo:
La conversación, fue derivando entonces hacia la documentación, posicionándose la mayoría de la gente en que la mejor documentación es el propio código (o incluso los tests unitarios), y que documentar exhaustivamente los diseños puede tener un coste elevado, aunque también se aceptó que en ocasiones puede ser interesante que algunos diseños se documenten (por ejemplo con UML) de manera que todo el mundo pueda acceder a ellos, eso si, siempre y cuando esta documentación sea consistente con el código y no esté desincronizada. Una manera de conseguir esto, era tener una tarea en cada Product BackIog Item (o historia de usuario) del Backlog dedicada a ello.

El siguiente foco importante de discusión y comentarios, fue el decidir el momento adecuado de realizar el diseño y análisis técnico de cada historia de usuario. El consenso fue que el diseño de cada historia se debía realizar durante el proceso de estimación y división en tareas de esa historia, en la reunión de planificación de Sprint, momento en el cual el Product Owner está disponible para explicar la historia y aclarar cualquier posible duda que pueda surgir.

Se habló también de como integrar a los desarrolladores juniors o la gente nueva en el proceso de diseño, de manera que sus diseños no afecten o comprometan la calidad del trabajo de todo el equipo. Casi todo el mundo nombró Pair-Programming como la solución a este posible problema, y alguien habló que en su empresa utilizaban un sistema de mentoring, en el cual un desarrollador senior se "hacía cargo" de un junior, de manera que le supervisaba el trabajo, desarrollaban juntos, etc. durante un tiempo y éste último no empezaba a trabajar para un cliente hasta que llevaba un tiempo y ya sabía cómo debía de programar (tanto a nivel de calidad cómo de estilo, estándares, etc)

Hacía el final se empezó a hablar de que hacer con los requisitos no funcionales: seguridad, rendimiento, etc. Aquí hubo un poco más de discordia, ya que había gente que abogaba por intentar optimizar desde el principio y otras personas que preferían desarrollar sin tener muy en cuenta estos parámetros y después optimizar en función de las necesidades del cliente. Aunque casi todo el mundo opinaba que ahora la tendencia es desarrollar pensando mas en la mantenibilidad y en la escalabilidad que no en la optimización del detalle.

Cómo último punto, se trataron las revisiones de código., que todo el mundo consideró cómo necesarias. Enumero algunos de los métodos expuestos (además de Pair-Programming cómo revisión continua):
  • En una empresa utilizan una herramienta online (un plugin de JIRA creo) donde se registran posibles mejoras en un código que hace un "moderador". Posteriormente el moderador y la persona que ha realizado el código lo miran juntos y se buscan posibles soluciones y mejoras.
  • En otros lugares realizan sesiones de revisión, donde se junta todo el equipo y se realiza la revisión de un código.
  • En otra empresa de manera periódica hacen una reducción de código de cada proyecto, de manera que se intenta una especie de gran refactorización con todas las modificaciones hechas desde la última vez.
Seguro que salieron muchas mas ideas interesantes que me olvido o que no apunté en su momento, pero fue una sesión muy fructífera y muy entretenida debido al alto nivel de los asistentes y alto porcentaje de gente que participó con opiniones y ideas en la charla!

Espero que alguna de estas técnicas puedan servir de ayuda a equipos que estén intentado trabajar con metodologías ágiles, y si alguien tiene alguna idea o sugerencia sobre el tema, adelante!! Explicadnos cómo realizáis diseño vuestros diseños ágiles!!

Un saludo!!


No hay comentarios: