Ajedrez - antoniomartel.com

Archivos por Etiqueta: ES

Regla del 80/20

¿Podemos ser más productivos? ¿Cómo podemos centrarnos en las tareas que nos harán más eficientes? Hace muchos años, aproximadamente un siglo, un tal Pareto comprobó de forma casual que sólo el 20% de las vainas que tenía plantadas en el campo producían el 80% de los guisantes de su cosecha y que el 80% restante producían tan solo el 20% restante de los guisantes. Curioso por esta relación comprobó también que podía aplicar esta regla a otros campos descubriendo, por ejemplo, que en su época el 20% de la población disponía del 80% de la riqueza y que tan solo quedaba un 20% de la riqueza total para el 80% más pobre de la población.

Este principio, basado en el conocimiento empírico, es usado desde entonces para mejorar la eficiencia y la  productividad en la economía, en la distribución comercial, en el marketing, en las ingenierías y, como no, también en el desarrollo de software.

Cuando comenzamos a desarrollar nuestro producto basándonos en una lista enorme de requisitos y funcionalidades a desarrollar, sabemos que sólo el 20% de esas funcionalidades serán usadas por el 80% de los usuarios y que una cantidad enorme del resto de las funcionalidades que desarrollemos sólo será usada en un 20% de las ocasiones.

Aplicando también este principio al tiempo de desarrollo podemos deducir que si tardásemos alrededor de 10 meses en la construcción de un producto, en tan solo 2 de esos meses conseguiríamos desarrollar el 80% de las funcionalidades requeridas y que, por tanto, nos llevaría unos 8 meses resolver el 20% de las funcionalidades más complejas y difíciles. Esto nos lleva a preguntarnos ¿serán usadas esas funcionalidades? ¿son realmente imprescindibles?

Si lográsemos identificar las funcionalidades más importantes y las mantuviésemos los más simple que nos fuera posible (otro principio: KISS) ¿no lograríamos quitarnos de encima 8 meses de trabajo y entregar un producto muy efectivo en tan solo 2 meses?

Ya sabemos que el 20% por ciento de nuestro esfuerzo producirá el 80% de los resultados ¿no sería bueno sentarnos por un momento para pensar a qué le vamos a dedicar nuestro tiempo? Merecerá la pena, seguro.

Si se puede medir, se puede mejorar

Hace unos días hablaba sobre métricas con unos entusiastas de las metodologías ágiles como yo. Comentábamos sobre la necesidad que tenemos todos de facilitar datos a la dirección de nuestra empresa sobre la marcha del proyecto o a nuestros clientes, que están realizando una inversión en nuestro producto y han puesto unas expectativas en él.

Todo esto me hizo recordar el clásico axioma de calidad atribuido a Peter F. Drucker y que dice algo así: «Lo que no se puede definir, no se puede medir, lo que no se puede medir no se puede mejorar, y lo que no se puede mejorar finalmente se deteriora» Hay muchas variaciones de esta frase y muchas versiones diferentes también sobre su autoría. Yo prefiero usarla desde un punto de vista más positivo diciendo «Si se puede medir, se puede mejorar»

Una métrica básica para el seguimiento del proyecto con SCRUM es la suma del trabajo que queda por hacer. Diariamente podemos sumar las estimaciones de las tareas que quedan por hacer en el sprint. Esto nos dará la cantidad total de trabajo restante para terminar la actual iteración (Release Burndown) Con un poco de suerte al día siguiente habremos conseguido terminar algunas tareas más y esta suma será algo más pequeña. Si lo representamos en una gráfica, ésta irá decreciendo hasta alcanzar el eje 0 (cuanta más pendiente tenga la gráfica más velocidad lleva el equipo) Lo mismo podremos hacer con toda la pila del producto si sumamos las estimaciones de todas las funcionalidades que quedan aún por hacer.

Otro gráfica útil y sencilla que podemos utilizar es la CFD (Cumulative Flow Diagram) con la que, tomando los datos del tablero Kanban donde reflejamos la marcha proyecto, vamos anotando cada semana cuantas tareas tenemos y en qué estado están. Si por ejemplo tenemos un tablero sencillo en el que sólo tenemos las tareas en tres estados, ToDo (Por hacer), In Progress y Done, la gráfica mostraría algo como esto:

Al principio del proyecto todas las funcionalidades estarán por hacer (en color azul) y al final del mismo todas habrán alcanzado habrán sido marcadas como realizadas (‘Done’, en color verde)

La representación no está escogida al azar. He observado en varios proyectos que la gráfica suele tomar esta forma característica. Una velocidad baja al principio (poca pendiente) cuando el equipo se está conjuntando, alta velocidad cuando se ha superado la fricción inicial (alta pendiente) y despacio nuevamente hacia el final del proyecto cuando se descubre que todas las tareas no se habían cerrado correctamente y quedan cosas por corregir (no se cumplió correctamente con la definición de ‘Done’)

Hay muchas otras métricas que pueden ser usadas, recomiendo posts interesantes en «5 métricas de desempeño para proyectos de desarrollo ágil y Scrum» y en «Métricas ágiles y cuadro de mandos integral para Scrum» En cualquier caso, uses las métricas que uses, asegúrate de que merece la pena el esfuerzo en registrar los datos y calcularlas. Más métricas no significan mejor gestión.

SCRUM but …

La guía de SCRUM en scrum.org define a este marco de trabajo como consistente en «Equipos SCRUM y sus roles, eventos, artefactos y reglas. Cada componente sirve para un propósito específico y es esencial para el éxito de SCRUM»

Sin embargo, en la práctica, no siempre nos ajustamos a una ejecución exacta de lo definido en esta guía. No tenemos tiempo para realizar todas las reuniones, cambiamos el plazo de un sprint, en definitiva, hacemos un SCRUM adaptado a los inconvenientes que van surgiendo.

Estas excusas que solemos poner para justificar nuestras modificaciones a la metodología tienen nombre propio, son las ‘SCRUMBut‘, o lo que es lo mismo: Sí, hago SCRUM pero …

Hace algunos años, en Nokia se definió un pequeño test, modificado posteriormente por Jeff Sutherland, para medir el grado de cumplimiento de las prácticas de SCRUM en los diferentes equipos con los que trabajaban: El SCRUM But … Test.

Cada práctica de SCRUM está pensada para resolver disfunciones comunes en muchos equipos de trabajo y que son muy difíciles de corregir. Después de todo, la propia guía dice que SCRUM es ‘Simple to understand’ pero ‘Extremely difficult to master’

He hecho un pequeño prezi sobre esto: Échale una vistazo en SCRUM but …

 

Teoría de las ventanas rotas

A finales de los años 60, un profesor universitario realizó un experimento psicológico. Dejó dos coches idénticos en dos barrios distintos: uno en un barrio conflictivo y pobre como el Bronx de Nueva York y otro en una zona rica y tranquila de California.

En poco tiempo el coche abandonado en el Bronx comenzó a ser desvalijado y perdió radio, llantas, espejo y todo lo que podía ser de valor. En cambio el coche abandonado en California permanecía tal y como lo dejaron.

El estudio no finalizaba ahí. Cuando el coche del barrio rico llevaba una semana intacto los investigadores le rompieron una ventana. Esto desencadenó en poco tiempo el mismo efecto que en el Bronx. El robo y el vandalismo dejaron pronto el coche en el mismo estado en ambos barrios.

Un coche con los cristales rotos transmite una idea de deterioro y despreocupación que contagia la idea de que vale todo. Cada nuevo acto de vandalismo rearfirmaba y multiplicaba esa idea convirtiéndose en una escalada imparable.

Una idea similar se explica en la formación a profesionales sanitarios. Si un paciente o un anciano se mancha o ensucia debe ser limpiado inmediatamente aunque se trate de sólo una pequeña mancha. Si permanece en ese estado, el propio paciente tendrá menos cuidado y precaución en no mancharse. Le da igual, ya está sucio. Comenzaría así a empeorar su higiene, su autoestima y su estado de salud general.

Los resultados de este estudio psicológico son aplicables a muchas situaciones de la vida cotidiana, desde el cuidado de nuestra casa al mantenimiento de nuestro coche pero también es aplicable a nuestro trabajo: Ya seas programador o jefe de proyecto, si permites subir a producción esa nueva versión sin las suficientes pruebas o si dejas tal y como está esa ‘deuda’ técnica en el código porque ahora hay ‘prisa’ se estará transmitiendo a todo el equipo de trabajo una sensación de que todo vale, de que ‘así es suficiente’ y de que la calidad podemos pasarla por alto. Antes o después el teléfono comenzará sonar con quejas de los usuarios y pronto veremos en el gestor de incidencias una enorme hilera de bugs reportados.

Así que ya sabes, si ves una ventana rota, arréglala cuanto antes.

Lecturas recomendadas: The broken window theory at the Coding Horror.

Estadísticas de uso de SCRUM (2013)

Hace unos años, cuando comencé a interesarme por SCRUM, solo unos pocos habían oído hablar de este marco de trabajo y la mayoría desconocía sus principios. Ahora en cambio, cada vez con más frecuencia, oigo a más y más profesionales hablar de SCRUM y otras técnicas Ágiles y veo que cada vez con más frecuencia es un requisito imprescindible en muchas ofertas de trabajo. Incluso compruebo que alguna administración pública comienza a exigirlo en sus pliegos de prescripciones técnicas demostrando en el texto que no lo ha puesto solo de oídas sino que lo conoce bien y sabe lo que quiere de él.

Por todo esto he sentido la curiosidad de medir hasta donde están llegando estas metodologías ágiles. De eso va este post. La técnica estadística y los medios usados quizás no sean los más exactos, pero pueden ayudarnos a tomar el pulso al mercado.

En primer lugar he buscado palabras clave como SCRUM, Agile, TDD o PMP en los principales portales de búsqueda de empleo españoles y europeos para permitir su comparación. Este es el resultado:

En los datos de esta tabla sería necesario tener en cuenta el total de vacantes que cada portal publica para conocer su proporción real al compararla con otro país pero Monster no publica estas cifras. Necesario comentar también que en los resultados de búsqueda de ‘Lean’ también se incluyen resultados para ‘Lean manufacturing’ o ‘Lean process improvement’ (Ágil en todo caso)

La conclusión más directa que saco de estas cifras es que debo estar más atento al ‘Lean Software Development’ en el futuro.

Por último he usado Google Trends para mostrar las búsquedas realizadas desde el año 2004 sobre ‘scrum -espn -rugby’ (para eliminar los resultados del deporte), ‘pmp’ y ‘rup’. Esta es la gráfica:

Es curioso observar el descenso en el número de búsquedas de Rational Unified Process y de PMP. En cambio SCRUM sube mucho desde esos años aunque no conserva la misma aceleración que tuvo entre los años 2007 y 2010.

Si te interesa saber más sobre la certificación, estimaciones, ventajas y desventajas de Scrum o cómo gestionar proyectos de forma ágil quizás te interese mi libro: Gestión práctica de proyectos con Scrum.

Si en cambio quieres poner a prueba tus conocimientos de Scrum haciendo un test en español antes de tomar el examen de scrum.org aquí tienes el Test no oficial de Scrum (aplicación realizada con Ruby on Rails y desplegada en Heroku).

Suscríbete