“¡Casi lo tengo!” Esta es una frase muy habitual cuando estamos desarrollando software. Muchas veces sentimos que estamos acabando una tarea, que ya la tenemos al 90% y que estamos a punto de terminar. Sin embargo, cuando abordamos ese 10% restante… nos acaba llevando más tiempo que el otro 90%. ¿Por qué ocurre eso?.
El Síndrome del 90% es algo habitual en entornos complejos. El motivo es que hay más cosas desconocidas que conocidas, lo que provoca que no tengamos control total sobre lo que hacemos. Generalmente trabajamos por partes dejando para el final la integración de todas ellas y las pruebas pertinentes. Cuando esto ocurre, vemos que las partes no encajan exactamente como pensamos y por eso tardamos tanto en cerrar completamente una tarea.
Realmente no hay una manera de evitar esta situación. Lo que hay que hacer es cambiar el paradigma de cómo realizar el seguimiento. Un ejemplo de esto es el burndown chart. Este artefacto es muy utilizado en Scrum (pero no obligatorio) que trata de dar transparencia de la desviación entre el trabajo realizado y el que se habría tenido que hacer en un estado ideal por parte de todo el equipo en el Sprint actual. Imaginemos la siguiente situación (un equipo con varias personas):
- Desarrollador: “creo que esto va a durar 24 horas (3 días).
- Termina el primer día “quita 8 horas que ya he trabajado”
- Termina el segundo día “quitame otras 8 horas”
- Termina el tercer día “quitame 8 horas… y añademe otras 16”
- ¿Cómo? Y eso ¿Por qué?
- “Se me ha complicado la tarea… ahora me quedan dos días más”.
¡No lo sabe! Ayer parecía que quedaba 1 día y hoy ya quedan 2 más… y si pasado mañana no has terminado vas a decir otra cifra ¡Nos lo estamos inventando!
Hacer seguimiento de nuestro trabajo en base al % de avance no funciona. Nos guste o no, estamos re-estimando diariamente y frustrándonos constantemente por no completar las tareas. De hecho, hasta el Project Management Institute recomienda que no hagamos seguimiento por tanto por ciento porque no ayudará a tener control.
¿Qué alternativa tenemos? En Scrum preferimos utilizar la regla 0-100. La regla 0-100 consiste en que solo se contabiliza un trabajo una vez finalizado (100%). Si algo está medio-hecho se contabiliza como 0% (aunque nos quede muy poquito). De esta manera evitamos engañarnos con que algo va a estar.
Aquí aparecen riesgos. Si todo el trabajo que vamos a abordar durante el Sprint dura varios días, durante ese periodo parecerá que no hemos avanzado nada. Hay que cambiar el chip. No medimos horas trabajadas, medimos cosas terminadas y entregadas. Si en tu planificación tienen trabajos de varios días durante esos días, no has entregado nada. El equipo está trabajando pero no ha terminado nada, lo que significa que el valor entregado es cero.
Imagina que eres camionero y te encomiendan llevar un camión de grano de Madrid a Alicante. Entonces dices, “como voy por Albacete, podemos decir que ya he hecho el 50%”. No es cierto, no has entregado nada. Mientras estás en Albacete no se puede hacer pan en Alicante. En el tramo que te falta podrías pinchar, tener un accidente o un atasco. Y lo peor de todo es que no lo sabes. Solo podrás hacer pan (y mucho) cuando el camión llegue y en ese momento contabilizaremos la carga. Por tanto, en ese momento habrá valor para el cliente, que es lo que realmente importa.
La mejor estrategia es dividir el trabajo en partes pequeñas. Esto nos puede dar predictibilidad sobre nuestro trabajo y a muchas personas les sirve como motivador (os dejo un post de nuestro compañero José sobre ello) al ir cerrando pequeñas partes del trabajo (short term wins). Esta alternativa tiene muchos otros beneficios, pero nos puede ayudar a mitigar la situación y acelerar nuestros ciclos de aprendizaje.
Otra parte crítica de Scrum es el Definition of Done que precisamente se refiere a cuando de verdad algo es entregado. El DoD nos marca todo lo que hay que hacer para considerar que hemos acabado. Todo lo que no cumpla ese DoD se considera no terminado y por tanto no se demuestra por parte del equipo en la Review, no se contabiliza a efectos de velocidad, no existe y lo peor de todo ¡ningún usuario pagará por eso!.
En definitiva, medir el valor del trabajo terminado es la única manera de ser realmente transparentes y honestos con nosotros.
Como bien decía Tobias Mayer “más vale 10 tareas Done que 30 tareas Doing”.
Tabla de contenido
Entradas relacionadas
«enséñame Scrum bien… Y ya lo adapto yo»0 (0)
Hace varios años desarrollé un método para el sindrome del 90%
bit.ly/SYNDROME90