¡Hola! Soy David, nuevo miembro de Sonicon systems. Espero que esta entrada de blog os sea útil para iniciaros un poco en este tipo de metodologías.

Después de la formación de SCRUM y KANBAN, en Sonicon nos hemos propuesto aplicar metodologías ágiles en algunos de los proyectos en los que estamos actualmente implicados.

Los principales valores de las metodologías ágiles son la mejora continua, el trabajo en equipo, la autogestión y la entrega frecuente de valor.

La adaptación al cambio es una de las principales características de las metodologías ágiles, gracias a su proceso iterativo. Además, te permiten marcar objetivos concretos a corto y a largo plazo, es decir, tener bien definido un ‘roadmap’.

Cuando aplicamos metodologías ágiles, la comunicación es fundamental. El uso de estas metodologías permite que el cliente, si lo desea, pueda implicarse en la planificación del proyecto a través de las reuniones que se hacen en las iteraciones. La participación del cliente en las reuniones tiene dos ventajas: en primer lugar, permite que los cambios que decida el cliente sean menos críticos; y por otro lado, le aporta tranquilidad.

photo.JPG

Los beneficios de las metodologías ágiles no implican que siempre convenga usarlas. Hay proyectos en los que estas metodologías pueden acarrear desventajas, como la falta de documentación o la falta de diseño. Lo que se habla en las reuniones no suele quedar por escrito, y eso hace imprescindible que no exista ambigüedad en la comunicación. Otra limitación para el uso de metodologías ágiles es el número de personas: para que una metodología sea útil debe haber un número mínimo y máximo de participantes. Una regla no escrita sería de 7 participantes más/menos 2.

SCRUM

Es un tipo de metodología ágil que resume unas prácticas de trabajo y define unos roles para los participantes.

Roles

Product Owner: Es el que define las historias de usuario. Es el encargado de comunicarse con los stakeholders para hacer el product backlog. Finalmente, reordena estas historias de usuario por prioridad.

Stakeholder: Personas o entidades que pueden ser afectados o afectar las actividades del proyecto. El equipo de IT pueden ser stakeholders.

Product Manager: Facilitador, es el que ayuda y guía al equipo de IT. Además, hace de mediador entre el cliente o el Product Owner y el equipo. Es recomendable que no esté en el equipo de IT.

Equipo de IT: Son las personas que desarrollan las historias de usuario.

Organización

Scrum se define como una metodología de trabajo por sprints. En un sprint, el equipo de IT y el Product Manager, recogen las historias de usuario hechas por el Product Owner. Tasan el tiempo que tardaran en realizar dichas tareas hasta ocupar todo el sprint. El sprint se define en 1,2,3 o 4 semanas normalmente.

Para las metodologias agiles en general, conviene usar una pizarra (dashboard) para tener un recurso visual de cómo va el proyecto. Hay 3 estados básicos (aunque pueden existir más):

  • To Do: tareas por hacer de la historia de usuario.
  • In Progress: tareas que se están realizando actualmente.
  • Done: Tareas hechas.

Cada día, se hace una reunión o ‘daily meeting’. Esta reunión no ha de durar más de 5 minutos. La realizan el equipo de IT y han de contestar a estas 3 preguntas: “¿Qué hiciste ayer?”, “¿En qué tuviste problemas?” y “¿Qué vas a hacer hoy?”. Así, esta metodología ayuda a la autogestión del equipo de IT.

Al finalizar el sprint, el equipo de IT debería (si no ha habido problemas) entregar las nuevas tareas realizadas (¡y testeadas!) para integrarlo en el producto ya existente. Así es como existe el incremento de valor en cada sprint.

Finalmente, se vuelve a empezar con otra reunión. El ‘Sprint review’ es una reunión para comentar aspectos del sprint realizado y planificar el siguiente sprint cogiendo tareas por hacer del product backlog.

KANBAN

Des de Sonicon hemos empezado a utilizar Kanban, es de las metodologías ágiles más sencillas, ya que no existen ni roles ni sprints.

La limitación de Kanban es que en cada estado del dashboard puede haber solo un número máximo de tareas al mismo tiempo (por ejemplo: solo puede haber tres tareas a la vez en el estado in progress).

Aplicaremos más esta metodología debido a que bastantes de nuestros proyectos son de mantenimiento y solución de incidencias, por lo que aplicar SCRUM u otra metodología con sprints no tendría sentido.

¡Espero que este post os haya servido de ayuda!

¡Un saludo!


Leave a Reply

Your email address will not be published. Required fields are marked *