martes, octubre 20, 2015

Cálculo del SPI en un Proyecto Ágil

Una de las preguntas más frecuentes que se hacen quienes comienzan a trabajar en el mundo de la agilidad es, ¿cómo calculo el avance de la construcción de mi producto?, en este post quiero compartir como es posible hacerlo.

Vamos a comenzar con poner los equivalentes del método del valor ganado (1)(2) en un proyecto agil:

  • Valor :
    • funcionalidad puesta a disposición del cliente que le reemplaza una existente o le mejora su negocio,
    • Generalmente medida en puntos en proyectos ágiles, 
    • Las funcionalidades inicialmente construidas tienen mayor valor de negocio que las construidas al final debido a la priorización del backlog  (3). El valor de negocio es subjetivo y es dado por el Cliente y/o Product Owner en Scrum (3)
  • Punto: 
    • Percepción (debido a la incertidumbre) del esfuerzo requerido para construir una funcionalidad
    • Por lo general se usa la serie de fibonacci alterada para "tallar" (poner talla), estimar una funcionalidad (historia de usuario, caso de uso) a ser construida, La serie usada es 1,2,3,5,8,10,20
  • BAC 
    • Presupuesto a la terminación del proyecto. Budget at Completion
    • En ágil emplearemos como BAC la cantidad de puntos estimados del release
  • EV
    • Valor ganado del proyecto
    • En ágil emplearemos la cantidad de puntos en DONE (5) al momento de hacer la medición
  • PV
    • Valor planeado
    • En ágil emplearemos la cantidad de puntos  planeados en DONE al momento de hacer la medición.
    • El insumo de los puntos planeados en Done es proporcionado por la gráfica del Burn Up Release
  • Release Burn Up
    • Gráfica empleada en proyectos ágiles en la cual en el eje "x" se encuentran los Sprints, en el eje "y" los puntos acumulados. De igual forma se gráfica la cantidad de puntos estimados que tendrá el release (como techo del mismo) y en el tiempo se presentan los puntos acumulados sprint tras sprint, en aras de buscar una tendencia y un estimado para lograr el posible despliegue de una versión liberable.
  • SPI
    • Indice de desempeño del cronograma
    • Indica la proporción en la que se cumple el planeado a la fecha 
    • si es mayor que 1 se encuentra el proyecto adelantado vs el planeado
    • si es menor que 1 se encuentra el proyecto atrasado vs el planeado


Dado estos insumos los cálculos de los índices son:


  • Avance = EV / BAC = Puntos en Done al momento de la medición/ Puntos totales del  Release

  • SPI = EV / PV = Puntos en Done al momento de la medición / Puntos proyectados


Condiciones, Restricciones y Aclaraciones
Es importante aclarar que en un proyecto ágil pueden darse las siguientes condiciones:

  • Si se alcanza valor de negocio más temprano se puede parar la construcción de este release y comenzar el siguiente
  • Si existe una fecha límite se le puede ofrecer al cliente:
    • dado que el equipo tiene una velocidad (tasa a la cual produce software sprint tras sprint) que funcionalidades desea sacar del product backlog para cumplir la fecha impuesta
    • cuales funcionalidades cumplen el objetivo de negocio que quiere resolver con la solución
  • Dada la incertidumbre inherente al desarrollo de software (clic aquí), muchas veces se puede contestar:
    • esa capacidad de negocio la logramos aproximadamente entre el sprint 7 y 10, en función de la priorización del backlog





Espero haber aportado/ayudado a la solución de esta inquietud frecuente.



Saludos Ágiles


Jorge Abad






Post relacionados:

  1. EVM, CPI, SPI en AGILE / SCRUM - clic aquí -.
  2. Diferencia entre Valor de Negocio (Ágil) y Valor según el PMI - clic aquí -.
  3. Mi versión de : SCRUM EN POCAS PALABRAS / SCRUM RESUMIDO - clic aquí -.
  4. Planning poker  - clic aqui -.
  5. Una versión inicial de Definition of Done (Definición de Hecho / Terminado / Realizado) - clic aquí -.





2 comentarios:

  1. Sin indagar mucho sobre el detalle de los datos, me pregunto cómo se valora la "desviación" que se observa con respecto a lo planeado. Si bien ha un comportamiento de mejora "exponencial", uno podría concluir rápidamente que la brecha es difícil de justificar ante "la gerencia" o "los interesados". Me da curiosidad de cómo abordan este tipo de brechas; sobre todo al inicio, cuando no es tan evidente el proceso de mejoría.

    Al fin y al cabo, creo que debe ser un reto frecuente, sobre todo cuando se parte de una cultura de planeación basada en la predicción.

    Espero haber sido claro en mi duda.

    ResponderEliminar
  2. Hola Alejandro

    Pongamos varias bases

    1. tienes un equipo que esta enfocado en dar el mayor valor y hacer la mayor cantidad de alcance en periodos cortos
    2. tienes un product backlog priorizado
    3. estas enfocado en construir lo de mayor valor más rápido
    4. En ágil das rangos como respuesta, decis este alcance aproximadamente lo tenemos para los meses de julio y agosto en funcion de la cantidad de features requeridas. (no tiene sentido comprometerse con algo incierto, no es sensato)

    Bajo ese escenario hay varias cosas que pueden pasar:
    - El equipo se cuestiona sobre como lograr cubrir la brecha de lo pactado
    - El equipo ya sabe que entregó lo de mayor valor primero por lo tanto si a la fecha o rango de fecha no se cumple el cliente tiene algo para trabajar,
    - se le puede dar al cliente la prioridad de decir, señor a este paso con este equipo no se va a lograr la cantidad de funcionalidad deseada, cuales features o itemes de backlog va a sacar para que para la fecha limite se entregue un release satisfactorio.

    Obvio es necesario cambiar el chip de muchos.(clientes, proveedores, equipos). pero si tienes un equipo que produce 30 puntos por sprint y queres que la misma gente produzca mas, simplemente pones mas equipos o sacas alcance del compromiso, pues es más valioso lograr un objetivo de negocio que una cantidad "X" funcionalidades.

    saludos

    ResponderEliminar