¿Cuánto es mucho?

Hay historias que son un punto… y hay quien no sabe contar historias.

Estimar o no estimar...

Estimar es un acto reflejo. Lo hacemos continuamente en nuestra vida diaria: cuando miramos una prenda de ropa en una tienda y pensamos si será de nuestra talla, cuando vamos a cruzar la calle, se aproxima un coche y calculamos si nos da tiempo a pasar al otro lado, cuando pedimos la cuenta en un bar.

Nos pasa lo mismo cuando tenemos un marrón sobre la mesa del curro; pero si nos sentamos con el resto del equipo y nos piden que hagamos explícita nuestra estimación nos cuesta “enseñar nuestras cartas”.

Todos los profesionales que nos hemos visto involucrados, de una u otra forma, en tareas de dirección de proyectos conocemos la metáfora del tradicional “triángulo de hierro”, en el que tiempo, coste y alcance pugnan entre sí para no comprometer la “calidad” del proyecto (o, mejor dicho, del producto del mismo).

Alrededor de ese triángulo nos hemos movido para intentar estirarlo desde todos sus vértices, estimando generalmente tiempos y costes frente a un alcance cerrado; mientras que la adopción de metodologías y marcos de trabajo ágiles ha hecho que cerremos costes y tiempos para intentar jugar con el alcance y que hablemos de un “triángulo invertido”.

Plan-Do-Check-Adjust

Efectivamente, la extensa adopción de las metodologías ágiles para la gestión de los proyectos de ingeniería software ha hecho que se disminuya el habitual “horizonte de sucesos” de la tradicional planificación predictiva para promover el uso de ciclos PDCA (Plan-Do-Check-Adjust) de mejora y aprendizaje continuos más cortos e iterativos como base para un desarrollo incremental y la entrega continua de valor al cliente.

En Scrum, el marco de trabajo más extendido con diferencia, cada uno de esos ciclos (iteraciones o sprints) comienza con un ejercicio de planificación, que se realiza en equipo y que se desarrolla alrededor de la definición y estimación de una serie de elementos (ítems) que conforman el ‘Backlog’ de la iteración que comienza.

Tal ejercicio se apoya en la adopción de una medida relativa, los puntos de historia (Story Points, SP) que, a priori, no deberían estar asociados de forma directa ni explícita a medida física alguna -de tiempo, por ejemplo.

A lo largo de la historia reciente de las metodologías ágiles hemos podido conocer multitud de argumentos sobre por qué sí usar puntos de historia… y por qué no hacerlo. Hay quien propone utilizar agrupaciones cualitativas antes de pasar a un ejercicio cuantitativo con puntos de historia; y hay quien propone utilizar diferentes métricas según el nivel de planificación en el que nos encontremos: Portfolio, Producto o Iteración.

Nuestro habitual ejercicio de estimación se acostumbra a realizar mediante alguna variante de ‘Planning Poker’ (online, con cartas simulando naipes físicos o con una App móvil). Acostumbramos a utilizar una serie de Fibonacci modificada (1, 2, 3, 5, 8, 13, 20, 40, 100) y suele empezar por elegir una historia que sea nuestro uno (1). A veces, en lugar de las cartas o la aplicación en el móvil, usamos una variante con los dedos de una mano, o utilizamos mapas de afinidad para agrupar historias por tallas de camisetas o por tamaños de botellas de vino; hay quien lo hace sin negociación ni conversación explícita, en modo ‘silent sizing’ que se apoyan en el uso de agrupaciones y la distribución de las historias entre los miembros del equipo para un reparto en dos vueltas… y también hay adeptos del ya vetusto movimiento #NoEstimates.

Y tú, ¿Cómo lo haces para saber cuánto es mucho? ¿Eres de los que no estima? ¿Juegas al póker?

e-Fumérides

El día a día en la Red da para mucho; pero mi día, como el tuyo solo tiene 24 horas. Si bien dormir está sobrevalorado, sabemos que tu tiempo es extremadamente valioso, de tal manera que hemos dedicado parte del nuestro a destilar algunas de las claves de una variedad de conceptos, tendencias, ideas o noticias que conforman la realidad tecnológica y socioeconómica de nuestro entorno empresarial. Huelga decir que las opiniones vertidas en estos breves artículos, así como las responsabilidades que de ellas se deriven, pertenecen, exclusivamente, a su autor.