Puntos clave para el éxito de un proyecto con Agile

Pizarra blanca con to-do list

Puntos clave para el éxito de un proyecto con Agile

Un proyecto Agile tiene muchas características que lo hacen especial para acometer con éxito grandes proyectos que, seguidos con el método tradicional de cascada, tienen muchas papeletas para acabar desviados.

Pero un proyecto Agile puede ser un desastre si no se eligen correctamente los miembros que componen el equipo. Por ejemplo, un equipo de desarrollo multidisciplinar es muy importante pero no tiene por que significar que todo el mundo sepa hacer de todo. Puede valer que entre todos los miembros del equipo se sepa cubrir todas las necesidades. Puede ser bueno que todos los miembros del equipo tengan una muy alta calidad y experiencia en las tecnologías aplicadas, pero antes que eso, será mucho más importante que todos y cada uno de los miembros del equipo tengan bien desarrollada la habilidad de trabajo en grupo.

Vamos a destacar un par de  buenas habilidades dentro de un proyecto Agile que, sin duda contribuirán a el correcto cumplimiento de lo comprometido en un sprint y de la calidad esperada de las tareas entregadas.

  • Un Product Owner con ganas y capacidad de sacrificio.
  • Un Scrum Master con habilidades de visión anticipada de necesidades.

Product Owner involucrado en crear buenas historias de usuario

El product owner es clave en un proyecto Agile . Sus maneras de planificarlo y seguirlo, pueden llevar el proyecto al éxito ó al fracaso. Como todo en la vida, la excelencia se obtiene con una equilibrada cantidad de calidad y tiempo de desempeño. Desarrollar unas buenas historias de usuario realmente útiles para el equipo de desarrollo, será determinante en la calidad que se repercutirá en las tareas a la primera entrega. Crear buenas historias dentro de un proyecto grande de larga duración, requiere de mucha dedicación de tiempo por parte del Product Owner. Su disponibilidad a este esfuerzo, es clave.

Historias de usuario

La metodología indica que las historias de usuario deben ser descripciones funcionales de  alto nivel. Estas tienen las siguientes premisas:

  • Debe ser sintetizada
  • Debe contestar a estas 3 preguntas:
    • ¿Quién se beneficia?
    • ¿Qué se quiere?
    • ¿Cuál es el beneficio?

Estas preguntas dan lugar a la redacción de la historia en la forma Como [rol de usuario], quiero [objetivo], para poder [beneficio].

Estas 3 preguntas garantizan una historia de usuario muy refinada y a alto nivel, si, pero ¿es suficiente para que el equipo de desarrollo tenga toda la información para  desarrollarla y entregarla con todo lo que se espera de ella?, tal vez, pero si el product owner refina las especificaciones, el ahorro de tiempo es considerable.

Se puede crear una historia de usuario que diga:

Descripción:

  1. Como usuario de la web
  2. Quiero poder ver el detalle de mis productos
  3. para realizar mis informes.

Pruebas de aceptación ó DoD (Definition of Done):

  1. Pantalla donde se  vea el detalle de los productos.

¿Es esta historia válida? Perfectamente, pero dejamos en manos del equipo de desarrollo muchas decisiones como:

  • Donde mostramos el acceso a ese detalle
  • Diseño de la pantalla de detalle
  • Campos de interés a mostrar en el detalle.
  • ¿Se puede acceder a cada registro para modificar?

Es perfectamente lícito redactar historias de usuario así, pero cuando se entregan las tareas en el sprint review, el product owner acometerá modificaciones con casi toda seguridad.

  • Estaría bien que pudiese acceder a cada registro para modificar
  • Sería deseable que los registros de los productos pendientes de pago saliesen en rojo.
  • Ayudaría que hubiese un botón de eliminar registro antes de que se ejecute el pago
  • Estaría bien que ese botón…

Este tipo de historias de usuario, harán con toda seguridad que en cada sprint review se caigan un buen porcentaje de tareas al siguiente sprint para modificarlas y ya estamos incurriendo en desviación.

Product owner y las historias de usuario

Un product owner entregado con la causa empleará muchas horas en redactar historias de usuario refinadas.

Una historia de usuario como la anterior podría contener información anexa como esta:

  • Diseño de la ventana (vale la foto de un boceto en papel)
  • Navegavilidad
  • Desde donde es accesible.
  • Concreción en la funcionalidad de cada elemento de la ventana

Complementando nuestra historia con estos datos, ahorraremos al equipo de desarrollo muchas dudas que en el mejor de los casos el product owner tiene que ir resolviendo durante el sprint incurriendo en un tiempo extra que pierde el equipo de desarrollo no estando centrado en las tareas y tiempo de distracción del product owner.

Por otro lado, solo un mal funcionamiento de nuestra ventana, haría que se cayese la tarea al siguiente sprint. La funcionalidad quedó muy clara.

Scrum Master con capacidad de anticipación

El scrum master tiene un papel crucial dentro de un proyecto Agile de gran envergadura.

Un Product Owner tiene que tener todo listo y disponble para poder introducir las tareas que necesita en cada sprint. Todas las tareas de un backlog están priorizadas por el product owner y para cuando este quiera introducirlas en los sprints, podemos encontrarnos con un sin fin de cosas que podrían entorpecer este objetivo:

  • Permisos
  • Creaciones de orígenes de datos
  • Reglas de firewall
  • Configuraciones en servidores

Todas estas cosas, son tareas de un facilitador ó scrum master, pero un buen facilitador es aquél que las ve venir y se anticipa. En su conexión con el producto owner, ve las historias de usuario de futuros sprints  y debe ser capaz de ver con antelación todas las cosas que estas necesitarán estar realizadas antes de comenzar la tarea. Es decir, debe tratar de resolver la mayor cantidad de puntos del DoR (Definition of Ready).

En las grandes compañías, la mayoría de estas tareas las acometen áreas con procesos administrativos que suelen alargarse en el tiempo. Un scrum master con capacidad de ver estas necesidades por adelantado, será crucial a la hora de que siempre esté todo disponible para que el product owner realice con éxito sus planificaciones.

Estos dos puntos favorecerán la concentración del equipo en la tarea que deban acometer. El primero les hará tener la tarea clara y el segundo contribuirá fuertemente a  que se cumplan las planificaciones. Dos puntos clave para nuestro proceso.