Postmortem: estimaciones y creación del sprint backlog

Estamos cerrando el último proyecto, una aplicación de gestión de datos con múltiples perfiles que controlan el trabajo y la información introducida por los demás. Acaba de entrar en explotación con bastante éxito: ni un error en los cuatro primeros días de uso, fundamentales porque corresponden con una primera fase que tiene un plazo límite. A partir de ahora, mantenimiento correctivo y algo de evolutivo.
Es un buen momento para comenzar el postmortem y analizar los errores cometidos.

Hemos usado Scrum como metodología, y la conclusión es que nos ha aportado tan poco como cualquier otra metodología que hubiésemos usado, pero al menos no ha molestado. No creo que nos haya aportado un auténtico valor, pero creo que estamos en el buen camino. El gran reto que teníamos para el desarrollo del proyecto era el uso de una pila de desarrollo nueva para casi todos, y contra eso no hay metodología que valga.

El product backlog se hizo a partir de las reuniones de contacto con los usuarios y de los primeros documentos de prototipado y requisitos que nos pasaron. Hasta ahí, bien, no es un artefacto que tenga mayor complicación.

Para estimar el product backlog hicimos planning poker con el equipo, tras haber contado de qué iba el proyecto. A todas luces la estimación era muy optimista, y se cumplió aquello de que los técnicos son positivos y que los gestores son pesimistas. Sin que sirva de precedente, los gestores tenían razón. Sin embargo, creo que si el mismo equipo volviese a comenzar el proyecto sí cumpliría las estimaciones que salieron de esa reunión. La experiencia en la tecnología y una mejor gestión de los requisitos habrían hecho que se hubiese podido implementar en los tiempos dichos.

Creo que nuestro gran error desde el punto de vista de la metodología fue la creación del sprint backlog. Lo hizo una persona (yo, como Scrum Master). Gran equivocación. Lo debe hacer el equipo en conjunto. El equipo careció de una visión global del proyecto, lo cual no trajo más que problemas:

  • Se adquirieron tareas en el orden incorrecto.
  • No se sabía qué era común y qué no, así que era más difícil organizarse para la reutilización.
  • "Marchas atras" por mala comprensión de las tareas.
  • Funcionalmente se depende del criterio de una única persona.
  • La estimación de las tareas habría sido más acertada con un mejor conocimiento del problema.
  • ...
Ya en un plano más técnico, otra fuente de problemas iniciales fue la ausencia de un modelo de entidades del que partir. Se pretendió hacer de forma totalmente incremental, exprimiendo al máximo la generación del modelo de datos de Hibernate a partir de las clases. En los anteriores proyectos, como ya he comentado, se nos imponía que un analista crease el modelo de datos, y que eso se tomase como base para comenzar el desarrollo. El extremo contrario tampoco es útil:
  • No es una tarea trivial, y es poco tolerante a errores. No pasa nada si haces mal un campo en una pagina, pero un error en el modelo de entidades puede tener consecuencias bastante dramáticas. Hacerlo exige un conocimiento profundo de los requisitos.
  • Una equivocación de una persona puede tener un desagradable efecto de malentendidos de los requisitos en cadena.
  • No es fácil compartimentar inicialmente para que la gente pueda trabajar independientemente.
Para la próxima...
  • El product backlog lo hará el Scrum Master como esta vez, antes de la primera reunión (tampoco tiene sentido movilizar a más personas para él).
  • En el sprint meeting el sprint backlog se hará entre todos los miembros del equipo. En vez de llevar a la reunión el sprint backlog prefabricado, leerlo, y estimar a partir de esa lectura, se generará durante ella, y tras la creación de cada tarea se hará la estimación de la misma. Sí, nos llevará mucho más tiempo, pero no será perdido, sino invertido.
  • En caso de tratarse de una aplicación de gestión, probablemente durante el propio sprint planning se hará un modelo de entidades (entidades del sistema y su relación entre ellas, sin necesidad de entrar a nivel de propiedad). Algo muy básico, pero que permita tener un punto de arranque común y afianzar los requisitos. Eso sí, me mantengo en la opinión de que con Hibernate ya debemos trabajar en términos de entidades y no de tablas.

Posted by Juan Ignacio Sánchez Lara 10:10  

4 Comments:

  1. jcesarperez said...
    Hola Nacho.

    Muy, muy interesante y muy sincero por tu parte (como siempre).

    ¿Te puedo hacer unas preguntas? Espero que sí:

    1) ¿Usasteis una duración fija de sprint?
    2) ¿Cual fue la composición del equipo?
    3) ¿Cómo era el proceso de reparto de tareas? Por un lado dices que el spring backlog lo hacias tú, pero luego comentas que las tareas se acometian en orden incorrecto. ¿Cada uno elegia la siguiente tarea? ¿Lo "pactabais" en reuniones semanales (sprint meeting)?
    4) ¿Cual es tu conclusión respecto a cómo debe atacarse la definición del modelo de datos?

    Un par de cosillas. Creó que se te ha colado una 'n' en "El equipo careción (...)" y un 'hará' en "hará el Scrum Master hará".

    Un saludo.
    Joserra said...
    ¿no teneis un Product Owner?
    Joserra said...
    ¿no teneis un Product Owner? él es quien debe hacer las priorizaciones
    Nacho said...
    Perdón por el retraso, no estaba recibiendo alertas de nuevo comentario, y por problemas con spam tengo activada la moderación.

    @jcesarperez: gracias por el comentario. Lo de la sinceridad será producto de un nuevo artículo :) Te voy respondiendo:
    1) Sí. Flexibilizar eso es peligroso. Mejor quitar items que cambiar fechas. Mantiene el foco en generar algo usable (aunque no esté completo funcionalmente) en una fecha dada, lo cual creo que es fundamental.
    2) Desarrolladores con experiencia previa en tecnologías similares (Spring frente a Seam, por ejemplo), y un par de personas en adicionalmente en periodo de formación (con las que inicialmente no se contaba).
    3) Scrum ortodoxo: cuando acabes una tarea, toma la que prefieras hacer (por familiaridad, por practicidad... por lo que sea) de las más prioritarias (están ordenadas verticalmente por importancia del item correspondiente del product backlog). Dentro de cada fila (ya que todas tienen la misma prioridad) la elección debería venir dada por el sentido común :).
    4) La definición del modelo de datos es algo fundamental. Tradicionalmente era de lo que se partía para trabajar, y está claro que es por algo. Creo que el modelo de entidades debe hacerse inicialmente por todo el equipo: en una reunión inicial, se debe hacer en común el modelo de las entidades existentes en el sistema, las relaciones entre ellas, y los datos no triviales de cada una. Por ejemplo, si se detecta que se va a gestionar personas, meter en el diagrama la clase Persona, pero sin necesidad de parse a indicar que tiene un String nombre, String apellidos... pero igual sí algo que se infiere de los requisitos pero que no aparece nunca explícitamente (por ejemplo, un campo de "fecha de último acceso".
    Personalmente lo haría directamente en Java, pero también veo razonable hacer un diagrama.
    El hecho de hacerlo en común favorecerá la comprensión de los requisitos por todo el equipo, y resolverá (o propondrá) dudas iniciales importantes.
    No creo necesario indicar todos los datos porque alarga innecesariamente la reunión, y hace perder el foco: de la reunión debe salir un equipo que comprende el sistema, y un esquema del modelo de datos correcto. Si te paras en detalles como el tipo de cada campo o su longitud dejas de pensar en global.

    Gracias por indicar esos errores, ahora mismo los corrijo.

    @joserra: sí, lo tenemos, y es el que marcó las importancias de los items del product backlog, que no es exactamente lo mismo que marcar las priorizaciones. Por ejemplo, si dice que lo más importante es el item #2, lo más prioritario serán los items del sprint backlog que surgen de la "explosión" del item 2, pero entre ellos la prioridad es la misma, y el criterio a seguir para el orden de ejecución es otro.

Post a Comment