Saludos Amigos!

Muchas veces me he preguntado cuál es el mejor proceso o forma de organizar a nuestro equipo de desarrollo de Software. Púes bien, en esta oportunidad quiero presentarles un nuevo modelo que acabo de conocer. Scrum, una Metodología Ágil de Gestión de Trabajo. Con los conocimiento que voy adquiriendo en clases, cada vez me siento más convencido de la importancia de aplicar esta Metodología Ágil! La simplicidad para explicar y entender el proceso fué uno de los factores por el cuál se ha logrado mi aceptación.

Veamos un poco de que trata el proceso.

El proceso de Scrum

Esta gráfica resumen bastante bien el proceso de Scrum.

El Product Backlog

Es la lista de historias de usuario que se van a incluir en el producto. No es necesario que todas las historias estén escritas antes de comenzar un desarrollo, basta con escribir al principio las más importantes, a tener algo con lo que empezar. El product backlog es una lista viva según avanza el proyecto se van incluyendo nuevas historias, esto es parte importante del espiritu de una metodología ágil, no hay que dedicar excesivo tiempo a un análisis inicial desgranando hasta la ultima funcionalidad imaginable del sistema, la idea es empezar pronto con las tareas más importantes, las que si o si tienen que hacerse como parte del producto, y posteriormente a través del feedback que recibamos del cliente y los distintos stakeholders del proyecto ir añadiendo/modificando/eliminando items de esta lista.

El sprint backlog y la planificación de sprint

Una vez que tenemos un product backlog con algunas historias se realiza la planificación del Sprint. En esta planificación tomamos las historias que estimamos se van a poder desarrollar dentro de un Sprint y con estas se construye el Sprint backlog. Cuando pasan al sprint backlog estas historias se subdividen en tareas , si por ejemplo tenemos una historia tipo Presentar informes de estadisticas de uso de la aplicación, la podríamos dividir en varias tareas como:

• Diseñar y crear tabla en la bd para almacenamiento de estadísticas.
• Crear clase para acceso a tabla de datos estadísticos.
• Pintar información de estadísticas en el gui mediante un gráfico de barras

La Reunión diaria de Scrum

A diario se realiza una reunión de Scrum, el famoso daily scrum. Todo el equipo tiene que participar en esta reunión que no debería durar mucho más de 15 minutos. En esta reunión cada miembro del equipo tiene que responder a 3 preguntas simples:

• ¿Que hiciste ayer?
• ¿Que vas ha hacer hoy?
• ¿Tienes algún impedimento para seguir avanzando en tu tarea?

Una vez terminada esta reunión se intentan resolver los impedimentos que se han encontrado y se actualiza la gráfica de burndown con el avance que se haya producido. Una cosa muy importante es que el tiempo no se mide en cuando llevamos trabajado, que en realidad es irrelevante, sino en cuanto falta para terminar que es lo que realmente importa. Con esto tenemos una re estimación diaria que nos permite saber en cada momento cual es el estado del proyecto, lo bueno de esto es que con datos actualizados se pueden tomar decisiones y corregir situaciones y problemas desde el momento en el que se presentan. La idea es no vivir en un engaño durante, por ejemplo, los dos primeros meses del proyecto y pegarse la bofetada justo al final, luego vienen las prisas, los sudores fríos y las llamadas al telepizza a las 10 de la noche en la oficina, y en muchas ocasiones por temas que se podian haber evitado de contar con la información necesaria en su momento.

Fin del Sprint: Demo y Retrospectiva

Una vez terminado un sprint llega el día fatídico de la demo de sprint, ese día es el que toca enseñar a todos lo interesados en el proyecto el avance que se ha producido, y claro para poder enseñárselo a alguien hay que tener un producto terminado al final de cada sprint. El resultado de cada sprint debe ser un software funcional, que sólo incluya las historias acordadas para el sprint, pero que funcione!, es decir, no vale aquello de: «si, si la historia X esta terminada pero hasta que no tengamos también la Y y la Z no te la puedo enseñar». El objetivo es ir construyendo versiones perfectamente funcionales en las que poco a poco se vayan añadiendo características, pero es fundamental que estas versiones sean funcionales para poder enseñarlas y recibir el feedback de los interesados, que en definitiva es lo que nos va a guiar para los sucesivos pasos que se den en el proyecto.

Después de sudar la gota gorda en la demo viene el momento de la utocritica, la retrospectiva del sprint, en esta reunión se tratan de poner sobre la mesa todas aquellas cosas que no han funcionado durante el sprint, el objetivo es que todo el mundo de su visión y para el siguiente sprint se intenten resolver estos problemas, algunos ejemplos:

• Planificamos mal porque no tenemos en cuenta el tiempo que se lleva hacer la documentación.
• Hay que revisar la política de control de versiones porque perdemos muchos tiempo resolviendo conflictos.
• Tenemos que preparar mejor las demos para que se entienda el funcionamiento del Software.

La idea es que estos problemas no se perpetúen y se les trate de poner remedio para ir mejorando continuamente nuestra forma de trabajo.

Una vez terminada la retrospectiva ya os lo podéis imaginar, pues a volver otra vez desde el principio!, se realiza la planificación del siguiente sprint y así sucesivamente mientras los clientes paguen :P.

Roles Principales

Product Owner: Es típicamente alguien que desempeña un rol en Marketing o un «key user» en desarrollos internos. S encarga de priorizar el Product Backlog.

Scrum Master: Es el responsable de asegurar que el Scrum Team se conduzca bajo los valores y prácticas de Scrum. También proteje al equipo asegurando que no se sobre compromentan en lo que puedan llevar a cabo durante unSprint. Además facilita el Dialy Scrum y se encarga de resolver los problemas que son planteados por el por el equipo durante la reunión. El rol de Scrum Master es típicamente cubierto por un Product Manager o un Technical Team Leader pero puede ser cualquiera.

Scrum Team: No incluye ninguno de los roles tradicionales de la ingeniería del software como programadores, diseñadores, testers o arquitectos. Cada integrante trabaja en conjunto para completar las tareas que fueron comprometidas en conjunto para ser desarrolladas durante el Sprint. El equipo desarrolla una profunda forma de camaradería y un sentimiento de «estamos todos juntos en ésto». El número típico de integrantes de un Scrum Team va desde 6 a 10 personas, pero esta cantidad puede escalarse haciendo lo que se llama «Scrums de Scrums».

Te invito a que puedas participar y aportar con tus conocimientos a la Comunidad Scrum Bolivia.

Saludos y hasta pronto!