sábado, 2 de febrero de 2019

Estimaciones y planes en SCRUM


estimating-in-agile-and-scrum
El manifiesto ágil tiene entre sus principios dar “Respuesta ante el cambio sobre seguir un plan”, lo que quiere decir que por encima el plan está la flexibilidad para realizar cambios y adaptarse a las exigencias dinámicas del negocio, del mercado, de la tecnología, etc.

En Scrum la planificación se realiza al inicio de cada Sprint, sobre la base de un
Product Backlog  priorizado, que va evolucionando a lo largo del proyecto. El Sprint Planning se focaliza en establecer qué y cuánto trabajo incluir en el Sprint para lograr la meta acordada por el equipo, incluyendo cómo lograrlo.

El marco de trabajo iterativo de Scrum, comienza en el Sprint 1, con la existencia de un Product Backlog preliminar, ya que sus autores no referencian un Sprint 0. Independientemente de esto, antes de iterar para obtener los incrementos del producto, es necesaria una fase preliminar, que algunos llaman “Incepción“ (Inception), para conformar el equipo de Scrum, comprender una visión general del problema y de la solución de alto nivel compartida por todos los miembros del equipo, identificar e involucrar a los stakeholders, asegurar los recursos financieros, técnicos y logísticos necesarios, configurar los ambientes, generar el Product Backlog, desarrollar las historias de usuario prioritarias, y generar un Plan General de Entregas de alto nivel (Release Plan).

En los proyectos complejos, al comienzo poco se sabe sobre el producto y el desempeño del equipo, por lo que las estimaciones están sujetas a una gran incertidumbre, sobretodo en proyectos de software, donde el contexto es volátil, la tecnología cambia con rapidez, así como la dinámica del negocio y del mercado.

Las estimaciones en contextos inciertos hacen poco probable el cumplimiento de planes, a medida que avanza el proyecto aumenta el conocimiento y las estimaciones podrán ser más precisas. Las estimaciones iniciales son aproximaciones basadas en supuestos con incertidumbre que utilizan valores con orden de magnitud probable. Por ejemplo las Épicas (agrupaciones de historias de usuario de alto nivel), podrían estimarse con letras (S pequeña, M medio, L grande, XL muy grande), para las historias de usuario se suele utilizar una estimación relativa que asigna puntos basados en la secuencia de Fibonacci (0, 1, 2, 3, 5, 8, 13, …), así una historia de 2 puntos requiere el doble de esfuerzo de una de 1 punto, y una de 3 puntos el triple.

Una forma de asignar el puntaje a la historia, es con la técnica del Póker Planning, donde cada miembro del equipo recibe un lote de cartas con los valores de la serie de Fibonacci, el Product Owner explica la historia de usuario, cada persona selecciona una carta y todos a la vez presentan su selección. Las personas con los puntos más bajos y más altos explican por qué del puntaje asignado, el equipo discute y puede repetirse la jugada hasta llegar a un consenso.

Por otra parte, cada equipo de desarrollo tiene una Velocidad, que representa la cantidad de trabajo realizada en un Sprint, por ejemplo, una velocidad de 15 puntos indica que el equipo realiza 15 puntos de trabajo en cada Sprint. Para los primeros Sprint el equipo asigna una velocidad estimada, que se refina luego del tercero o cuarto Sprint con la velocidad real que ha tenido el equipo en estos primeros Sprint.

Sobre métricas y estrategias de seguimiento hablaremos en la próxima entrega.

Gracias por leerme.-

No hay comentarios:

Publicar un comentario

Gracias por tus comentarios :)