Gestión de proyectos en SCRUM

¿Cómo funciona?

En la práctica, esto significa que todo el proceso se optimiza constantemente y se adapta a las necesidades del equipo y el producto durante todo el periodo de trabajo en el proyecto. Responsabilidad de la gestión desarrollo de productos se reparte entre el propietario del producto (PO) y el equipo de diseño. El PO es la persona responsable de tomar las decisiones relacionadas con la dirección del desarrollo del producto y tiene una "visión" holística de en qué se va a convertir el producto. La gestión de tareas se basa en el tablero Kanban (junto con el sprint funcionalidad denominada tablero SCRUM). Cada participante en el proceso puede añadir tareas al backlog, pero el PO es el responsable de establecer las prioridades. El equipo del proyecto se encarga de "transformar" las ideas del OP en tareas concretas y de planificar su ejecución.

Desarrollo del ciclo

El proceso se divide en iteraciones (sprints). Como parte de un sprint de aproximadamente 2 semanas de duración, el equipo del proyecto implementa y prueba la parte de la funcionalidad previamente planificada.

El sprint comienza con la "planificación", en la que el equipo discute y prepara las tareas que han sido previamente preparadas y establecidas por el PO en la parte superior del backlog. A continuación, se estima la dificultad de estas tareas y se les asignan puntos en función de la dificultad. Con una composición del equipo y unas condiciones de trabajo relativamente constantes, el número de puntos realizados en cada sprint es repetible y permite planificar el trabajo futuro. Al final de la reunión de planificación, se seleccionan las tareas con un número total de puntos que deben completarse en un sprint, y comienza un nuevo sprint.

A mitad del sprint tiene lugar el grooming. Se trata de una reunión en la que el OP presenta al equipo nuevas expectativas e ideas, mientras que el equipo del proyecto las analiza, las desglosa en tareas más pequeñas y presenta posibles sugerencias al OP. Al planificar las tareas futuras, el OP consulta con analistas, usuarios, UX y diseñadores gráficos. Análisis adicionales (mercado investigación y ciencia de datos) suelen ser necesarios en esta fase. Sólo después de analizar y formular las denominadas Historias de Usuario, la OP publicará esas Historias en un backlog. La Historia de Usuario debe contener información sobre lo que el PO espera de una determinada tarea o grupo de tareas y sobre los criterios que deben utilizarse para reconocer si la tarea se ha completado.

Durante el sprint, se celebran diariamente las llamadas "Daily standup meeting". En estas reuniones, cada desarrollador cuenta al resto del equipo lo que ha estado haciendo durante el último día y, posiblemente, informa de cualquier problema o bloqueo que impida seguir trabajando. Gracias a este intercambio del estado actual, es posible detectar mucho más rápido los posibles conflictos entre varias tareas y evitar la situación en la que el desarrollador se atasca en un problema y no puede avanzar en él. El supuesto del standup diario debe ser lo más breve posible, pero cumpliendo su función al mismo tiempo. La fórmula permanente de la reunión anima al equipo a que sea breve.

Durante el sprint, las tareas se desplazan en el tablero SCRUM en función de su estado actual. La elección de las columnas suele corresponder al sistema de trabajo de las empresas o del equipo y está asociada al sistema de control de versiones y a la frecuencia de los lanzamientos. En nuestro caso es la siguiente:

• Por hacer: tareas pendientes
• En curso - tareas en curso
• Código revisión - tareas en espera de ser revisadas por otro desarrollador
• Preparadas: tareas comprobadas y aceptadas por los desarrolladores
• En fase: tareas ubicadas en una instancia de puesta en fase y a la espera de la aprobación del pedido.
• Aceptadas - tareas aceptadas por el PO
• Hecho - tareas listas ubicadas en la instancia de producción

Después del sprint, tiene lugar una retrospectiva. Se trata de una reunión dedicada a la optimización del trabajo. Todo el equipo debate qué ha ido bien en el último sprint y qué hay que mejorar. También se suele hacer referencia a la retrospectiva anterior y se comprueba si se han podido poner en práctica todas las ideas para mejorar el trabajo. Los problemas que se debaten en la retrospectiva pueden ser de todo tipo, desde herramientas de desarrollo, pasando por la presión, la dificultad de las tareas, hasta problemas de comunicación (tanto entre los desarrolladores y el equipo como con el PO).

Responsabilidades del SCRUM master

La persona responsable del correcto desarrollo del proceso SCRUM es el SCRUM master. Suele ser la función más incomprensible del equipo. El SCRUM master no tiene poder de decisión. Las decisiones las toman conjuntamente el equipo y el PO, mientras que el papel del SCRUM master es eliminar los obstáculos en el buen desarrollo del proceso.

Entre las funciones del maestro SCRUM se incluyen las siguientes:

• Realización de reuniones SCRUM, incluidas las de planificación, preparación, reunión diaria y retrospectiva.
• Garantizar que las tareas del tablero SCRUM son preparadas regularmente por el equipo y priorizadas por el PO.
• Funcionar como enlace entre el equipo y el PO; por lo tanto, a menudo es el SCRUM master quien tiene un papel difícil a la hora de traducir el lenguaje de los programadores al lenguaje empresarial, y viceversa. Esto se debe al hecho de que, en nuestra empresa, el SCRUM master es un desarrollador, por lo tanto, una persona técnica. El marco general del trabajo del SCRUM master no lo requiere.
• Impedir que el equipo se salga del tema y vigilar el orden del día de las reuniones
• Cuidar el ambiente en el equipo, principalmente en las reuniones.
• Resolver conflictos si surgen.

Lea también:

• Buenas prácticas de Codest para la creación de software. Nuestro enfoque del recorrido del cliente
• Buenas prácticas de Codest para la creación de software: GitFlow
• Buenas prácticas de Codest para la creación de software. ¿Cómo llevamos a cabo el análisis de requisitos?