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í -.

El tinto * / café (o té) del Scrum Master

Lograr un entendimiento profundo del rol de Scrum Master es algo que me ha costado tiempo, fallas, y experiencia.

Me gusta mucho el modelo de Angel Medinilla (@angel_m)
1. Scrum Dude
2. Scrum Mom
3. Scrum Master
4. Scrum Master Sensei
Ver más aquí - clic aquí - 


Esta es la hora que no se si estoy en el nivel 3 o si llegaré al cuarto nivel, pero mas allá de eso, he notado dentro de las grandes herramientas del Scrum Master en su papel de Coach del Product Owner y Coach del Scrum master:  Es el tinto* (o café - como le dicen en otras zonas- )

Como lo tuitie (o lancé un twit – no sé como rayos se escribe - ) hace unos días

No tiene sentido que el #ScrumMaster no sea cercano al equipo, debe estar en la misma área de trabajo.

— Jorge Hernán Abad L. (@jorge_abad) octubre 7, 2015

Para qué:

• Para ver y sentir las interacciones de su equipo
• Para notar como se teje el equipo
• Escuchar como se va construyendo o destruyendo la auto-organización en función de los eventos y conductas de los miembros. entorno, o de la organización
• Para dar feedback y feedforward, respetuoso y oportuno
• Gestionar y palpar los impedimentos
• Para evitar interrupciones al equipo

Y en ese sentir su equipo, el/la Scrum Master tiene una herramienta de valor incalculable, las “CONVERSACIONES” y esas conversaciones acompañadas de un tinto o un té son geniales y de gran aporte para el equipo..

A veces invito a cualquiera del equipo : “ven, vamos a tomarnos un tinto*”, y con la excusa del tinto, conversamos de:

• La familia
• El proyecto
• De mi
• Conciliamos puntos de vista
• Hablamos de puntos de vista diferentes
• Nos damos mutuo feedback acerca de cualquier circunstancia, o solo feedback unidireccional
• De todo

Y es allí donde – desde mi experiencia– siento que puedo influenciar al equipo hacia la mejora continua, de la misma manera que sucede en la retrospectiva (a veces talvez más), pues muchas veces se logran entendimiento profundo de ciertos eventos y logramos decifrarlos/desamarrarlos a la aroma de dos buenos tintos..

Aclaro, cualquiera de mi equipo se siente en la libertad de invitarme a tinto y conversar.


 –  Vení, nos tomamos un tinto*....


Saludos ágiles

Jorge Abad

---

Notas:

• Esta "revolucionaria técnica" : )    puede ser usada con té, y por gerentes de proyecto, líderes, team members y cualquiera que esté interesado en mejorar el resultado de su equipo de trabajo.
• * Tinto: Así se le dice a un pocillo de café negro en Colombia.

Ejemplos de Artefactos Empleados en Metodologías Ágiles / Scrum (Semestre 02 - 2015)

Hola a todos

Con mis alumnos de "Gestión de Proyectos Informáticos" del semestre 8 del pregrado Ingeniería de Sistemas de la Universidad Eafit - www.eafit.edu.co, realizamos durante el primer módulo la simulación de la gestión ágil de un proyecto de software, generando los siguientes entregables:

• Agile Inception
• Product Vision Board
• Visión
• Grupos de usuarios
• Necesidades
• Funcionalidades
• Beneficios
• Product Backlog  Board
• Técnica Personas
• Restricciones
• Lo que no nos deja dormir (Riesgos)
• Sería genial que pasara (Oportunidades)
• Prioridades (alcance, tiempo, costo, calidad, usabilidad, adaptabilidad, seguridad, etc)
• Incluido en el alcance
• Fuera del alcance
• Modelos /Diagramas
• Despliegue
• Procesos
• Mockups
• User Story Map / Construcción del Release Plan 
• Calculo del tiempo y costo de la construcción del producto,  empleando una hoja de cálculo de mi autoría (clic aquí para acceder a la hoja de cálculo y su explicación)
• Construcción del Product Backlog basado en requerimientos con historias de usuario
• Simulación de Scrum
• Simulación de tres sprints de scrum, durante una sesión de 3 horas, generando los siguientes entregables:
• Historias de usuario
• Bocetos asociados a las historias de usuario
• Gráfica de Burndown de cada Sprint
• Gráfica de Velocidad
• Gráfica de Release Burn Up
• Mejoras identificas cada sprint

En estos links encontrarán los cuatro proyectos con los entregables citados:

• Optitraffic Gestion -Sistema para apoyo de la movilidad de la ciudad-  link
• MetroTime -Sistema para conocer tiempos del metro y sistemas integrados- link
• Uber Bus App site -Sistema de información de movilidad pública- link
• Sismat -Sistema de Gestión de Matriculas de Colegios- link

Espero los disfruten y les ayude en sus proyectos.

Saludos ágiles

Jorge Abad

Empezar una Retrospectiva y la Directiva Principal de las Retrospectivas Ágiles

Empezar una retrospectiva ES UN RITUAL (por lo menos para mí lo es)

Te paras frente a un grupo  que acaba de salir de un Review (Ver en que consiste Scrum y sus distintas reuniones/ceremonias/conversaciones haciendo clic aquí), hay una serie de emociones:

• el equipo salió bien, 
• el equipo salió mal. 
• no tan bien como lo hubieran deseado 

Tienes tu taco de post-it en la mano -por lo general -  y estas ahí como su Scrum Master (1), su coach, ellos saben y esperan que acompañados por ti se encuentre la mejora, y que realices en la retrospectiva las labores de líder jardinero (8):

• se corten hojas y ramas
• se limpien otras
• se abonen algunas raíces
• se fumiguen algunas plagas 
• y se remueva la tierra 

Para que el equipo siga creciendo en el siguiente ciclo de forma constante, continua y saludable.

Y comienzas a hablarles... 

Todo esto es tensión y emoción es el momento donde agregas más valor tangible para el equipo.

Y es por eso que lo llamo RITO, pues debe ser visualizado, preparado para que los participantes reciban el efecto esperado.

Yo, por mi parte comienzo más o menos, con las siguientes palabras:

--

"Bueno señoras, señores, señoritas... muchachos..

por favor soltemos celulares, vamos a realizar bien esta reunión.

Terminó un sprint,  observo que nos fue de tal y tal forma 

• tantos puntos comprometidos, 
• tantos puntos logrados, 
• tuvimos tales y tales incidencias de calidad (mejoramos o disminuimos en calidad)
• el feedback del producto fue tal

Vamos a entrar en la retrospectiva y el objeto acá no es encontrar culpables, pero si es entender qué pasó, qué podemos entender para que en el siguiente ciclo corrijamos y mejoremos.. 

Recordemos los 4 acuerdos (7): ser impecable en las palabras, dar siempre lo mejor, no tomarse nada personal y no hacer suposiciones.

El derrotero que vamos a seguir es más o menos el siguiente

1. entender cómo se sienten después del sprint (armar el escenario)
2. cuales fueron los hechos que tuvimos en este sprint (recolectar datos)
• puntos
• bugs
• cumplimiento de compromisos
• cumplimiento (o no) de mejoras identificadas en retrospectivas pasadas   (en caso de que esta sea al menos la segunda retrospectiva)
3. entender que sucedió (generar un entendimiento profundo de lo que pasó)
4. proponer posibles pasos a seguir (decidir que hacer - empleando pensamiento divergente)
5. priorizar la mejora (pensamiento convergente - máximo 3 cosas a mejorar en el siguiente ciclo)
• mirar como llevar estas mejoras a acciones concretas, 
• ejemplo: no solo decir mejorar la comunicación sino como mejorarla, es decir ¿creando un grupo de whatsapp para X situaciones?
6. y cerrar la retro,

Vamos entonces a realizar la siguiente actividad...(por lo general tomo de aquí - clic acá - las que me gustan según el momento del equipo)(2)...

..." 

---

Unas veces digo más otras menos- según las circunstancias-  pero siempre comienzo mi retrospectivas con un pequeño discurso que "setea"/configura los ánimos, busca bajar los egos y disponer el espíritu para el proceso de mejora continua del equipo.

Este paso que yo hacia a mi modo - y que considero indispensable, siempre que se inicia una retrospectiva, ya sea con un equipo nuevo o no - , fue una sorpresa para mi encontrarlo corregido y aumentado por Tobias Mayer en su libro "Por un Scrum Popular" - clic aquí -, se le llama La Directiva Principal de las Retrospectivas (The Prime Directive) y existen muchas versiones:

• English: Regardless of what we discover, we must understand and truly believe that everyone does the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand.(4)
• Español:Independientemente de lo que descubramos, debemos entender y creer de verdad que todo el mundo hace el mejor trabajo que él o ella podría, dado lo que se sabía en ese momento, sus habilidades y capacidades, los recursos disponibles y la situación actual.(5)

(Esta es la versión inicial)

• English: We are emotional and vulnerable beings, subject to a continuous flow of influences from a myriad of sources. Sometimes we perform magnificently, other times we mess up. Mostly we are somewhere between these extremes. In this last period of work everyone did what they did, and likely had reasons for doing so. Accept what is. And now, what can we learn from our past actions and thinking that will inform and guide our future ones? We don’t always do our best. So let’s get real. (6)
• Español: Somos seres emocionales y vulnerables, sujeto a un flujo continuo de influencias de cantidad innumerable de fuentes. A veces nos desempeñamos magníficamente, otras veces nos equivocamos. Mayormente estamos en algún lugar entre estos dos extremos. En este último período de trabajo todos hicieron lo que hicieron, y probablemente tenían razones para hacerlo. Aceptemos lo que es. Y ahora, ¿qué podemos aprender de nuestras acciones pasadas y qué podemos pensar para orientarnos en el futuro? No siempre hacemos nuestro mejor esfuerzo. Así que seamos realistas (6)

(Propuesta por Tobias Mayer)

y si seguimos buscando, podemos encontrar varias polémicas al respecto

• Questioning the Retrospective Prime Directive - http://www.infoq.com/articles/retrospective-prime-directive

Pero más allá de eso, siempre comienzo mis retrospectivas (o retros como les digo) con un pequeño discurso, igual o no, - no importa -, es el momento de aprender y avanzar, de empujarnos a ser mejores y para esto las mentes y los corazones deben estar dispuestos y un bálsamo para el alma y el espíritu siempre es bienvenido.

Saludos ágiles y hasta la próxima

Jorge Abad

Notas, aclaraciones y referencias

(1) En español se podría decir: Maestro del Scrum, Amo del Scrum, Experto del Scrum 

(2) Generador de retrospectivas - Retromat: http://plans-for-retrospectives.com/index_es.html

(3) Tobias Mayer. Por un Scrum Popular - clic aquí - 

(4) http://retrospectivewiki.org/index.php?title=The_Prime_Directive

(5) http://www.benlinders.com/2015/retrospective-prime-directive-translations/

(6) Blog Tobias Mayer - https://agileanarchy.wordpress.com/2010/12/10/the-prime-defective/

(7) Los cuatro acuerdos - http://www.lecciones-aprendidas.info/2015/08/comenzando-con-un-equipo-en-scrum-parte.html

(8) El Líder Jardinero - http://verovera78.tumblr.com/post/78355581715/el-l%C3%ADder-jardinero

Errores de "Lesa Agilidad"

Hola a todos

Les comparto unos tweets y pensamientos sobre como fallamos al agilismo #LesaAgilidad

un abrazo

--

Error de Lesa Agilidad: "Voy a quedarme trabajando hasta las diez de la noche y también en el fin de semana para poder terminar todo"

— Ricardo Colusso (@rcolusso) septiembre 5, 2015

@jorge_abad @rcolusso @IngridAstiz yo siempre recomiendo a "quienes no tienen tiempo" de hacer una retrospectiva, ¡que hagan dos!

— Lucho Salazar (@luchosalazarc) septiembre 5, 2015

También"hacemos reuniones de sincronización de equipo (daily o stand-up meetings) sólo cuando podemos estar todos presentes" #LesaAgilidad

— Ricardo Colusso (@rcolusso) septiembre 5, 2015

@rcolusso @IngridAstiz @luchosalazarc #LesaAgilidad cuando inflo mis estimaciones en el planning para trabajar con "muy buena holgura"

— Jorge Hernán Abad L. (@jorge_abad) septiembre 5, 2015

@jorge_abad @rcolusso @luchosalazarc ejem... estoy trabajando fin de semana con la ilusión de poder terminar "todo"... ejem...

— Ingrid Astiz (@IngridAstiz) septiembre 5, 2015

#LesaAgilidad Cuando salgo antes del horario de oficina sin importarme el compromiso del sprint por que soy "autogestionado" @rcolusso

— Jorge Hernán Abad L. (@jorge_abad) septiembre 5, 2015

Ejecutando proyectos con equipos autogestionados

Ejecutando proyectos con equipos autogestionados from Jorge Hernán Abad Londoño

Típico de la gestión tradicional

Tipico de la gestión tradicional de proyectos de software //#Agile #Scrum #noestimates pic.twitter.com/VulCOUUiCF

— Jorge Hernán Abad L. (@jorge_abad) agosto 31, 2015