Medir o no medir, ésa es la cuestión

En estos días estoy en un proyecto muy bonito ayudándoles a desarrollarlo con un enfoque ágil que luego puedan asumir como propio en otros proyectos. Es tan bonito que el nombre que hemos dado al proyecto de coaching es “Proyecto Bonito”. Un equipo como éste es toda una garantía de éxito: motivado, autoexigente, con muchas ganas de aprender y hacer las cosas mejor (ya las hacían bien, pero quieren hacerlas aún mejor). Este proyecto es tan bonito que incluso tenemos dueño de producto (dos: a falta de uno, dos). Son proxies del cliente, pero está plenamente justificado porque nuestro cliente está a muchos miles de kilómetros de distancia. Y está justificado el tener más de uno por eso de tener un respaldo durante las vacaciones… Yo, además, contento porque así es mucho más rico el backlog grooming que vamos haciendo. 🙂

Hay retos, claro, si no no sería tan bonito… Tenemos que lidiar con la dispersión geográfica de sus miembros, con las dichosas vacaciones (¡quién las habrá inventado! :-P) e incluso con retos técnicos como el uso de ExtJS. No son grandes retos, pero suficientes para sacar buenas conclusiones y no poner en riesgo ninguno de los objetivos, tanto el económico de tener éxito con el proyecto para nuestro cliente como el interno de interiorizar buenas prácticas ágiles y, además, tener cierto margen para ir obteniendo artefactos de arquitectura que luego puedan quedarse en la casa para abordar otros proyectos.

Pues bien, en este contexto nos van saliendo conversaciones interesantes que voy a intentar ir sacando en este blog poco a poco en la medida que pueda garantizar la debida confidencialidad. La primera de ellas que me gustaría sacar tiene que ver con la estimación de tareas.

Antes que nada:

¿Para qué estimamos las historias de usuario?

Yo no sé vosotros, pero a mi me gusta saber si el proyecto que tengo entre manos va bien, va mal, le queda mucho para acabar, seré capaz de entregar tal o cuál funcionalidad el mes que viene o dentro de tres meses… será mi pasado oscuro como jefe de proyecto o que es una pregunta muy normal cuando es tu responsabilidad manejar un presupuesto. Así que yo estimo historias y trato de responder a esas preguntas con un “si seguimos a este ritmo parece que sí” o “para ser posible tiene pinta de que tendríamos que hacer algo”. Otro día hablamos sobre cómo ayudo a responder a estas preguntas… 🙂

Pues bien, en la primera reunión de planificación surgió lo típico: estimar en horas las tareas.

Y llegamos a la siguiente pregunta (a la que yo realmente quería llegar hoy):

¿Para qué estimamos las tareas?

A mi, personalmente, lo que realmente me interesa es tener un medio de provocar conversaciones que nos permitan reducir las diferencias de expectativas e ideas preconcebidas entre los diferentes miembros del equipo y el dueño del producto a la hora de abordar la historia de usuario en su conjunto y cada una de las tareas en particular. Y consigo este efecto pidiendo que se estimen las tareas… y cuidando de facilitar esas conversaciones, por supuesto.

Así que, al final, yo llego a la conclusión de que no es relevante si la estimación la hacemos en horas, en puntos o en lo que sea. Lo relevante es que salgamos todos alineados y con una conversación lo más rica posible alrededor de cada historia de usuario en el tablón.

LA FOTO: Un guiño a los seguidores de Dr. Who. Ayer vi dos episodios seguidos con niño1 y he terminado hablando con él sobre el continuo espacio-tiempo. 🙂

  • Totalmente de acuerdo con la conclusión. Al principio yo era más del lado de estimar en puntos de historia, porque es lo que pone en algunos libros escritos por tíos relevantes y esas cosas. Pero en mi empresa preferían que lo hiciéramos en horas ideales.

    En fin, que al final es relativamente similar, como si quieres decir que estimamos en lechugas, la cuestión está en el número de lechugas que hacemos en cada iteración y saber aproximadamente cuantas lechugas faltan para acabar tal o cual tarea 😀

    Un saludo.

    P.D: buena suerte en el “proyecto bonito”, este tiene un nombre mucho más optimista desde luego 🙂

  • Me da que me va a gustar esta serie de artículos. Ya espero con ansia el que diga: “..la definitiva receta para hacer bien una historia de usuario, es: ………….”

    🙂

    • jmbeas

      Bueno, si quieres saberlo no tienes más que asistir a mi curso. ¿Organizamos uno en tu empresa? 🙂

  • No me gusta la estimación en horas porque estamos dando por supuesto que o sabemos quien la va a hacer o que todos tardamos lo mismo en hacerla.
    Por ejemplo, en el equipo en el que trabajo hay 2 personas que llevan varios años trabajando en el producto y estamos 2 que acabamos de llegar hace apenas 4 meses. Como te puedes imaginar, lo que tardan ellos y lo que tardamos nosotros en hacer una tarea no tiene nada que ver.

  • Lamentablemente hay que estimar. “Lo que no se mide no se gestiona”, reza un viejo proverbio del management. Necesitamos evaluar el progreso por eso es bueno establecer ciertos indicadores nos da igual el tipo necesitamos unos aceptados por todos.

    Estos son herramientas fundamentales en el proceso porque definen las variables clave para medir el progreso del proyecto hacia su objetivo.

    La planificación consiste en avanzar hacia un futuro incierto con paso firme y directo hacía un objetivo establecido. Esto provoca inevitablemente cambios de de orientación al igual que cuando enviamos el altlantis hacía la mir. Sabemos el destino pero no el camino.

    Nos permiten orientar a todos los stakeholders hacía el éxito del proyecto. ¿Cómo lo hacemos en cualquier otro caso?. Ideas…

    • jmbeas

      Je, je. No he dicho yo lo contrario respecto a la necesidad de medir (aunque a mí sí que me importa lo que medimos porque paso de medir por medir: eso es desperdicio). Y también de acuerdo en la utilidad para lograr el engagement de todos los que están relacionados con el proyecto. Justo es el tema que he dejado para otro artículo más adelante. Sin embargo, este artículo se refiere a estimar las tareas necesarias para desarrollar una historia de usuario. Todo ello dentro de un contexto de aplicación de metodologías ágiles, donde todo el trabajo de una historia de usuario no supera el timebox de la iteración. Así pues, creo que no nos contradecimos.