Ajedrez - antoniomartel.com

Archivos de Categoría: Blog

Ventajas y desventajas de SCRUM (I)

domingo, 26 mayo 2013 17:51
antoniomartel
0 Comentarios

Si estás considerando SCRUM como método de trabajo pero no sabes muy bien de qué va todo esto. Has oído a un montón de gente hablándote de las bondades de este sistema pero ¿cuántas tecnologías y técnicas no han aparecido rápidamente y desaparecido a mayor velocidad aún? Todas prometían ser revolucionarias así que cuando oímos tanto bombo sobre alguna arqueamos una ceja en actitud crítica.

Hace algunas semanas publiqué un prezi en el que explicaba las ventajas y inconvenientes de implantar SCRUM en una organización. Las comentaré ahora en esta entrada, esta vez con palabras en lugar de imágenes, comenzando por sus inconvenientes (trataré de ser parcial, pero no lo prometo)

El equipo puede estar tentado de tomar el camino más corto

Cuando cada dos semanas hay cosas que entregar, en las últimas entregas no se completaron todas las funcionalidades previstas y la velocidad del equipo no predice que vayamos a terminar en plazo tenemos un problema: puede surgir la tentación de resolver las tareas pendientes de cualquier manera y dejar ‘deudas’ técnicas en el trabajo. Aparentemente todo va bien, más funcionalidades hechas, empezamos otras nuevas y el cliente está contento porque se están cumpliendo los plazos.

Pero siempre que se deja un borrón ahí atrás puedo asegurarte que volverás a tropezar con él. Si nuevas cosas han sido construidas sobre este borrón, la ‘deuda’ comenzará a multiplicarse. Antes o después tendrás que parar todo y devolver la deuda comprometida (con intereses de demora) El proyecto no termina de cerrarse cuando parecía que ya quedaba poco por acabar: la gráfica burndown parece tener una asíntota horizontal en 0 (lo siento, deformación profesional/educacional, Cálculo I)

¿Necesitas con mucha antelación fechas exactas de entrega?

Esta es una de las críticas más habituales a SCRUM. En cierta forma es lógico, al inicio del proyecto no puedes predecir cuando lo vas a acabar si estás facilitando que lo que se va a construir cambie y varíe en el tiempo. ¿Se prefiere un producto que se sabe con certeza que va a finalizar en 10 meses pero que está construido sobre las ideas y opiniones que se tenían cuando se comenzó? Quizás se prefiera un producto que podría acabar en el plazo similar pero que hemos podido evolucionar hacia nuestras necesidades reales y que hemos podido usar y probar antes de la entrega final.

¡Stress!

No nos podemos pasar la vida esprintando. Hacemos una entrega y ya nos comprometemos para la siguiente que está solo a un par de semanas vista. Luego otra y otra. Si tenemos que recorrer muchos kilómetros así comenzaremos con un rápido sprint para llegar a la primera meta pero llegaremos caminando a la última, eso con suerte.

¿El equipo es autoorganizado?

Una de los principios de SCRUM es que el equipo debe tomar sus propias decisiones y autogestionarse. Además, se requiere que no haya miembros especializados en tareas concretas como análisis, tests, diseño, documentación, etc. sino que todos los integrantes del equipo sepan hacer de todo y puedan intercambiarse entre sí. ¿Siempre contamos con un equipo así? ¿Qué pasa si no lo tenemos?
Desde luego es un problema pero ¿no lo sería también con cualquier otra forma de trabajo? ¿Hay alguna que permita llevar proyectos a buen puerto con equipos con poca experiencia?
En otra entrada hablaré sobre las ventajas de SCRUM (seguro que no es tan popular)

Si te ha gustado este post, puedes encontrar más contenidos que expliquen Scrum de forma práctica y desde su base en mi libro en Amazon Curso práctico de Scrum: Algo más que teoría.

Libro en Amazon: Curso práctico de Scrum: Algo más que teoría
Libro en Amazon: Curso práctico de Scrum – Algo mas que teoría

Regla del 80/20

domingo, 19 mayo 2013 17:55
antoniomartel
0 Comentarios

¿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

domingo, 12 mayo 2013 19:27
antoniomartel
0 Comentarios

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 …

domingo, 05 mayo 2013 20:03
antoniomartel
0 Comentarios

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

domingo, 28 abril 2013 16:55
antoniomartel
2 Comentarios

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.

Suscríbete

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Más información
Privacidad