#Agiles2015: Charla ¿Cuando estará listo? Predictibilidad con #Kanban via @manuelcepeda

Esta es la descripción de la charla

Jefes y clientes siempre quieren saber cuándo algo estará listo, es obvio, ellos deben comprometerse con otras personas también y tenemos que ayudarlos al respecto.
Aprende los fundamentos más importantes para aumentar tu capacidad predictiva basado en métricas de flujo mediante Kanban y gana capital político cumpliendo lo que prometes.

Slides disponibles en http://www.slideshare.net/leansight/cuando-estar-listo-mtricas-y-forecasting-con-kanban

Cuando un cleinte pregunta “¿cuando estará listo?” … ¿a qué se refiere?

Se refiere cual es la tasa de papelitos que podemos terminar a tiempo, o realmente está preguntando ¿cuantos palos le tengo que pedir al banco para terminar este proyecto?

Visto desde un punto de vista frío, todo es un problema de números. Las empresas tienen un flujo de caja. Ese flujo de caja puede significar 20 palos mensuales para “hacer algo”. Supongamos que cada desarrollador cuesta un palo. Eso significa que puedo armar un equipo de 20 personas, incluyendo CPO (Certified Project Owner) y CSM (certified scrum master).

Entonces no tendríamos problema si el proyecto dura para siempre.

Pero si la empresa tiene que contratar 7 personas son 7 palos. Si el flujo de caja es de sólo 5 palos, le faltan 2 en un año son 24 palos. Suponiendo que no hay tasa de interés para hacer más fácil el asunto, si el proyecto se demora 3 años, son 76 palos, si el proyecto se acaba lo paga en 15 meses.

Entonces si llevanos 3 años y se ve que el proyecto va a demorar 3 años más… y el flujo de caja pasó de 5 palos mensuales a ser negativo… ¿qué hacemos?

Eso es lo que piensa el CEO. El flujo de caja no es seguro, si estamos desarrollando un sistema interno (que es el caso típico), esto no genera un nuevo flujo de caja… o sí, un flujo de caja negativo, pero no aporta valor al negocio, es sólo una manera de “tener control”… lo que es una manía de todas las empresas… Y uno piensa “entonces hagamos esto mismo que hace DHL con el tracking de los paquetes… ya que eso le gusta a los clientes… para que el cliente tenga una visión de lo que pasa internamente al interior de esta empresa”… Obviamente la respuesta es un rotundo NO.

Pero piénsalo. la tendencia hoy en día es a empresas transparentes que le entregan información al cliente cuando éste la necesita.

Eso probablemente entregue valor al cliente y el cliente nos prefiera.

Todas la ideas de Lean, Calidad Total, Toyota, etc. se basan siempre en el valor para el cliente.

Bueno y volviendo al tema de ¿cuándo estará listo?

Si seguimos Scrum esa pregunta no tiene sentido porque estamos haciendo iteraciones, podemos planificar una iteración, ¿qué significa estimar algo que no está planificado? ¿cómo podemos planificar algo que no está diseñado? (el diseño es lo que vamos a construir, no los requerimientos que son finalmente las funcionalidades, lo importante en este caso es el “como”).

Y ¿cómo vamos a diseñar requerimeintos que no entendemos? De hecho la mayor parte de los proyectos ni siquiera tiene los requerimientos escritos ni numerados.

No es que sea partidario de hacer BDUF, pero es imposible realmente tener una estimación total si no hemos resuelto lo anterior.

Lo que sí te peudo decir es que típicamente hay bugs:

  1. En los requerimientos. (El cliente no sabe lo que quiere)

  2. En el análisis (no lo entendimos).

  3. En el diseño (el diseño no resuelve el requerimiento o lo hace de manera pobre).

  4. En el desarrollo (código).

¿Cómo se resuelve lo anterior?

[4] Se crean unit tests y functional tests.

[3] Se hacen prototipos de los diseños y luego se incorporan en el proyecto como bibliotecas.

[2] Se hace “requirement scrubbing” y se hacen maquetas que se presentan al cliente.

[1] Se hace un “modelamiento de negocio”, y se presentan maquetas al cliente.

Las iteraciones resuelven las dudas de si lo estamos haciendo bien o mal. Esto necesariamente motiva a los cleintes a “decir la verdad”. De particular importancia es “no se aceptan comentarios durante el sprint”, porque si se permiten, el cliente te cambia los requerimientos completamente. De hecho me ha pasado que en una misma reunión de revisión de lo construido me han cambiado los requerimientos 2 veces, del tipo “construye un Excel”… “construye un Word”.

Está demás decir que eso no tiene el menor sentido, por eso es sumamente importante crear prototipos o maquetas rápidas o YAGNI totalmente fake que muestren las funcionalidades antes de ser construidas.

1 me gusta

En otras palabras no waterfall no tiene manera de saber cuándo estará listo.

Y al menos la agilidad tiene la ventaja de que las pruebas unitarias nos permiten no tener regresiones y de esa manera podemos tener mejor predictibilidad de lo que vamos diseñando…

Entonces ¿cuál es la cura para “no podemos estimar todo el proyecto”?

La respuesta es “dime las funcionalidades que te generarán más valor”, lo que automáticamente significa “más valor apra el cliente del cliente”… significa que el cleinte te va a preferir y o vas a tener más cleintes al mismo precio… o los mismos cleintes estarán dispuestos a pagar más…

Eso automáticamente es más flujo de caja. Pero por el mommento es sólo una idea en la cabeza de alguien, hay que probarlo y la respuesta a eso es Fail Fast.

Si lo pensamos bien, en el caso waterfall, el cleinte se hace prisionero del proyecto. No verás valor hasta el final… si no generamos valor a los desarrolladores nos da risa, porque estamos haciendo lo que nos piden, no tenemos ingerencia en la generación de valor, el problema es problema de otro, nunca nuestro…

En el caso de la agilidad, estamos directamente implicados en la generación de valor para el cliente… y para el cliente del cliente… nuestro nivel de importancia aumenta… y por eso nuestro trabajo será “fullfilling”…