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!!


martes, 16 de noviembre de 2010

ScrumMaster: ¿Parte o no del equipo?

Me ha parecido, en el último Agile Open de Barcelona escuchar en varias ocasiones frases similares a esta. En algunas sesiones, en los pasillos e incluso en alguna de las cenas he oído comentarios y opiniones dándole vueltas a esa idea. De entrada,creo que sería interesante re-formular la cuestión, ya que creo que lo que se intenta debatir no es si el ScrumMaster debe estar o no en el equipo (por supuesto!!) sino si además de sus funciones cómo ScrumMaster, debe también tener otras funciones dentro del equipo (desarrollo, testing, usabilidad...). La pregunta que yo lanzo es ¿ScrumMaster full-time o part-time?

Antes de dar mi opinión, veamos lo que dice el propio Jeff Sutherland sobre el rol en cuestión:

"The ScrumMaster helps the product group learn and apply Scrum to achieve business value. The ScrumMaster does whatever is in their power to help the team be successful. The ScrumMaster is not the manager of the team or a project manager; instead, the ScrumMaster serves the team, protects them from outside interference, and educates and guides the Product Owner and the team in the skillful use of Scrum. The ScrumMaster makes sure everyone on the team (including the Product Owner, and those in management) understands and follows the practices of Scrum, and they help lead the organization through the often difficult change required to achieve success with agile development. Since Scrum makes visible many impediments and threats to the team’s and Product Owner’s effectiveness, it is important to have an engaged ScrumMaster working energetically to help resolve those issues, or the team or Product Owner will find it difficult to succeed. Scrum teams should have a dedicated full-time ScrumMaster, although a smaller team might have a team member play this role (carrying a lighter load of regular work when they do so). Great ScrumMasters can come from any background or discipline: Engineering, Design, Testing, Product Management, Project Management, or Quality Management."

Leyendo el párrafo anterior, la respuesta a la pregunta sería: Depende!! Si puedes permitírtelo, ten un ScrumMaster full-time, sino puedes porque tú equipo o organización es demasiado pequeño, usa a un miembro del equipo a modo part-time (aunque eso sí, aligerando su carga de trabajo en otras responsabilidades). Ahora bien, ¿porqué sería interesante tener un ScrumMaster full-time?

La responsabilidad del ScrumMaster es, entre otras cosas, encargarse del proceso (sí, ya se lo que pone en el Manifiesto Ágil, pero no se me ocurre otra manera de expresarlo!!) El equipo debe "hacer" algo (un producto, un proyecto...) utilizando eso proceso y el ScrumMaster debe encargarse de observar cómo lo hacen, ver como el equipo avanza, e intentar ayudarles a mejorar. Sería algo así cómo si el equipo fuera dando pequeños saltos hacia un punto mientras el ScrumMaster observa cada uno de esos saltos e intenta que el equipo aprenda a saltar mejor cada vez. Pero para que esta observación sea efectiva, es necesaria cierta neutralidad.Se debe poder mirar el proceso con un poco de perspectiva para poder obtener información objetiva sobre el mismo. Si el ScrumMaster es parte del equipo, puede perder la perspectiva, su visión puede quedar sesgada ya que su foco se está centrando también en producir (multitasking?) y la mejora continua necesaria en todo equipo Scrum es probable que sea menor.

Esto seria lo ideal, pero, cómo hemos leído en la definición de Jeff Sutherland, es posible que en equipos o organizaciones demasiado pequeñas un ScrumMaster no tenga suficiente volumen de trabajo para ejercer ese trabajo full-time. Además, muchas organizaciones dedicadas al desarrollo de software seguramente no estén aún preparadas para tener a una persona "que no produce" (nótese la ironía) a tiempo completo.

¿Entonces que hacemos? Scrum es una metodología de inspección y adaptación. Empecemos con lo que tenemos, y mantengamos la visión ideal del ScrumMaster full-time en el horizonte y, aunque es posible que nunca se llegue a completar, intentemos trabajar en esa dirección. ¿Cómo? Que varios equipos compartan SM, haciendo que el ScrumMaster sea una persona de otro equipo... o con otras opciones mucho mas creativas que las que se me ocurren ahora mismo a mi.

Como nota final, apuntar que aún más importante que decidir si el ScrumMaster es full-time o no, es escoger al candidato correcto. ¿Y quien es el candidato correcto? Pues sencillamente aquel que tiene los skills necesarios! Os remito a un interesante artículo de Xavier Albaladejo sobre el tema: "El buen gestor de un equipo ágil".

¿Que opináis? ¿Debería ser el ScrumMaster un rol full-time?¿O mejor un miembro del equipo?¿Puede llegar a trabajar sin ScrumMaster un equipo?

Espero vuestras opiniones! Un saludo!





domingo, 14 de noviembre de 2010

Se acabó el AOS 2010!

Ha finalizado el Agile Open Spain 2010. Ha sido mi primera asistencia a un evento en formato Open Space y las sensaciones han sido inmejorables. Mas allá de la calidad de las sesiones a las que he asistido (que difícil ha sido elegir entre las numerosas propuestas de los asistentes), con lo que me quedo es con las ganas y la energía que que han mostrado todos los asistentes que han hecho el esfuerzo de acercarse a Barcelona desde diferentes lugares de España, Europa e incluso algunos del otro lado del charco, para compartir con todos sus opiniones y experiencias en esto que llamamos Agilismo. A lo largo de los casi dos días del evento, he tenido el placer de escuchar, charlar y discutir ideas y opiniones con mucha gente, algunas con verdaderos expertos en metodologías ágiles y otras con gente que se acercaban por primera vez a ellas, pero todas han sido igual de enriquecedoras.

Sesiones técnicas, sesiones sobre gestión de proyectos (o Project Support cómo prefiere llamarlo Alan Cyment...) e incluso sesiones que podríamos considerar algo así cómo teórico-filosóficas... :P de todas ellas me llevo cosas para reflexionar e intentar mejorar tanto a nivel profesional cómo personal. Más adelante intentaré concretar alguna de estas ideas en siguientes posts.

Espero que este evento sea un punto y seguido que ayude a la comunidad Agil Española a seguir creciendo y consolidándose, utilizando para ello, quizás, algunos de las propuestas surgidas en la Retrospectiva del evento (facilitada de manera magistral por Ariel Ber a quién desde aquí doy las gracias por su colaboración y ayuda durante todo el evento), cómo por ejemplo la realización de eventos Open Spaces a escala local, la realización de eventos temáticos o sobretodo la propuesta estrella de la noche: fomentar el agilismo entre las mujeres!!

Cómo punto final, dar las gracias a todos los que han hecho posible este evento: los patrocinadores del evento (en especial al patrocinador oro Plain Concepts), a la gente de la organización, a la asociación agile-spain y sobre todo, y aquí me repito, a la gente que ha hecho el esfuerzo de acercarse al evento, ya que sin la gente no hubiera sido posible realizarlo!

Os dejo una foto de la configuración de la agenda, totalmente autoogenerada entre todos los que asistimos al evento!



Un saludo, y espero volver a coincidir con muchos de los que habéis estado en el AOS (no pongo nombres porque seguro que me dejo a gente) y sobretodo espero ver a mucha gente nueva en próximos eventos. Para empezar en el xp2011 en Madrid!!


lunes, 1 de noviembre de 2010

VAN sobre integración contínua

Muy buenas a todos,

el pasado viernes tube el placer de participar en la VAN sobre integración contínua que organizó Altnet hispano. La VAN estubo muy interesante, tanto por la explicación general como por las demostraciones de las diferentes herramientas que se hicieron.

Aquí os dejo el video de la VAN.


Unable to display content. Adobe Flash is required.