Hoy me gustaría hablar del marco de trabajo SCRUM para la organización de equipos de desarrollo de software. A mí personalmente en la gestión de equipos de trabajo siempre me han gustado los métodos ágiles. ¿Pero qué es un método ágil de desarrollo?

El desarrollo ágil de software son métodos de ingeniería del software basados en el desarrollo iterativo e incremental, donde los requerimientos y soluciones evolucionan mediante la colaboración de grupos auto-organizados y multidisciplinarios. Nos permite centrarnos en ofrecer el más alto valor de negocio en el menor tiempo. Existen muchos métodos de desarrollo ágil (hoy nos centramos en SCRUM). El software desarrollado se organiza en unidades de tiempo llamadas iteraciones (en el método SCRUM son “sprint”), las cuales deben durar de dos semanas a un mes. Esto nos permite rápidamente y en repetidas ocasiones inspeccionar el software real de trabajo y decidir si liberarlo o seguir mejorándolo. Cada iteración del ciclo de vida incluye: planificación, análisis de requerimientos, diseño, codificación, revisión y documentación. La meta es tener una versión testada y sin errores al final de cada iteración. Al final de cada iteración el equipo vuelve a evaluar las prioridades del proyecto.

Una introducción al método SCRUM sería la dada por Hirotaka Takeuchi y Ikujiro Nonaka, “The New New Product Development Game”, Harvard Business Review, Enero 1986, en la cual decían “Un enfoque de ‘carrera de relevos’ en el desarrollo de productos … puede entrar en conflicto con los objetivos de máxima velocidad y flexibilidad. En su lugar, un enfoque holístico o estilo ‘rugby’ – donde un equipo intenta ir a la distancia como una unidad, pasando la pelota hacia adelante y hacia atrás -pueden servir mejor a los actuales requisitos competitivos”.

Para entender mejor está metodología de trabajo vamos a hablar de los roles de las personas implicadas en el proyecto ya sea tanto de forma directa como de forma indirecta. También hablaremos de las reuniones necesarias para el correcto avance del proyecto y por último de la documentación necesaria para la realización del seguimiento.

En la organización de los proyectos de desarrollo de software con el método SCRUM se pueden identificar los siguientes roles o perfiles:

Product Owner suele ser la voz del cliente que puede ser interno o externo a la organización. Persona que se reúne con el cliente en la toma de requisitos:

• Define las funcionalidades del producto.
• Decide sobre las fechas y contenidos de las releases.
• Es responsable por la rentabilidad del producto (ROI).
• Prioriza funcionalidades de acuerdo al valor del mercado/negocio.
• Ajusta funcionalidades y prioridades en cada iteración si es necesario.
• Acepta o rechaza los resultados del trabajo del equipo.
• Participar en la reunión de planificación de iteración, proponiendo los requisitos más prioritarios a desarrollar, respondiendo a las dudas del equipo y detallando los requisitos que el equipo se comprometer a hacer.
• Estar disponible durante el curso de la iteración para responder a las preguntas que puedan aparecer.
• No cambiar los requisitos que se están desarrollando en una iteración, una vez está iniciada.
• Participar en la reunión de demostración de la iteración, revisando los requisitos completados.

Scrum Master es la persona que se encarga de gestionar el método Scrum en la organización:

• Representa a la gestión del proyecto.
• Responsable de promover los valores y prácticas de Scrum.
• Se asegura de que el equipo es completamente funcional y productivo.
• Permite la estrecha cooperación en todos los roles y funciones.
• Escudo del equipo de interferencias externas.

Team es el equipo de trabajo que se encarga de sacar adelante el Sprint:

• Típicamente de 5 a 9 personas.
• Multi-funcional:
  • Programadores, testers, analistas, diseñadores, etc.
• Los miembros deben ser full-time
  • Puede haber excepciones (Ej.: Infraestructura, SCM, etc.)
• Los equipos son auto-organizados y multidisciplinarios.
• Solo puede haber cambio de miembros entre los diferentes sprints.

Para la planificación y seguimiento de los proyectos con SCRUM se realizan las siguientes reuniones:

Sprint Planning es la reunión de planificación del Sprint. Las características son las siguientes:

Daily Scrum es la reunión diaria sobre el estado del proyecto en cada Sprint:

• La reunión comienza puntualmente a su hora. A menudo hay castigos (acordados por el equipo) para quien llegue tarde.
• Reunión diaria de no más de 15 minutos.
• Todos los asistentes deben mantenerse de pie (esto ayuda a mantener la reunión corta).
• La reunión debe ocurrir en la misma ubicación y a la misma hora todos los días.
• No es una reunión para solucionar problemas.
• Todo el mundo está invitado.
• Sólo los miembros del equipo, ScrumMaster y Product Owner, pueden hablar.
• Ayuda a evitar otras reuniones innecesarias.
• No es para dar un status report al Scrum Master.
• Se trata de compromisos delante del equipo.
• Todos los miembros del equipo responden tres preguntas:
  • ¿Qué hiciste ayer?
  • ¿Qué vas a hacer hoy?
  • ¿Hay algún obstáculo que te impida avanzar?

Sprint Review (reunión de revisión del Sprint) es una reunión que se realiza al final de cada Sprint para revisar si el trabajo fue completado o no:

• El equipo presenta lo realizado durante el sprint.
• Normalmente adopta la forma de una demo de las nuevas características o la arquitectura subyacente.
• Reunión Informal
• Máximo 4 horas.
• No usar diapositivas.
• Todo el equipo participa.
• Se invita a todo el mundo.

Sprint Retrospective Después de cada sprint, se lleva a cabo una retrospectiva del sprint, en la cual todos los miembros del equipo dejan sus impresiones sobre el sprint recién superado. El propósito de la retrospectiva es realizar una mejora continua del proceso. Esta reunión tiene un tiempo fijo de cuatro horas.

En esta metodología de trabajo se genera la siguiente documentación:

Product BackLog es un documento a partir del cual se realiza el Sprint planning:

• Descripción de los requisitos.
• Una lista de todos los trabajos deseados en el proyecto.
• Priorizada por el Product Owner.
• Repriorizada al comienzo de cada Sprint.

Sprint BackLog documento generado a partir de la reunión del Sprint planning:

• Los individuos eligen las tareas.
• El trabajo nunca es asignado.
• La estimación del trabajo restante es actualizada diariamente.
• Cualquier miembro del equipo puede añadir, borrar o cambiar el Sprint Backlog.
• Si el trabajo no está claro, definir un tema del Sprint Backlog con una mayor cantidad de tiempo y subdividirla luego.
• Actualizar el trabajo restante a medida que se va avanzando.

Burn Down Charts es una gráfica mostrada públicamente que mide la cantidad de requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint:

• Dibuja una línea de todos los puntos de los sprints completados.
• La línea normalmente será descendente hasta llegar al eje horizontal que es donde se termina el proyecto.
• Si se añaden requisitos la línea será ascendente en algunos momentos.

Esto es en líneas generales el frame work de SCRUM para la organización de proyectos de desarrollo de software. Espero que pueda ser útil para alguien como primer contacto con dicha metodología.