Ajedrez - antoniomartel.com

Archivos por Etiqueta: entropía

Dudas sobre Scrum

Un lector de este blog me preguntaba hace ya algún tiempo algunas dudas que le surgían en el uso de Scrum en sus proyectos. Algunas de ellas pueden ser bastante comunes a otros equipos de Scrum o que yo mismo he tenido cuando intentaba aplicar Scrum. Aquí les pongo algunas de estas respuestas (sería la solución que yo aplicaría en los tipos de aplicaciones que conozco pero puede que no sea el mismo tipo de proyecto/equipo/producto/etc.).

¿Qué pasa cuando una historia de usuario requiere análisis que debe ser desarrollado en el propio sprint?¿el resto del equipo que no analiza se pone con otras historias de usuario del Sprint Backlog?
La historia de usuario es ya parte del análisis y debería estar bien definida y concretada cuando se va a comenzar un sprint. Es cierto que en ocasiones, cuando el equipo de trabajo comienza a realizar la tarea puede encontrarse con dudas o puntos que no tienen claro. Debería bastar con una llamada al Cliente o una breve reunión para resolverlo.
Es un punto complejo éste. Es cierto que es habitual que el desarrollo pisa al análisis y llegue la hora de desarrollar funcionalidades que aún no están bien analizadas. Para esto es bueno mantener reuniones frecuentes con el cliente para ir avanzando y concretando tareas previstas para más adelante de forma que a la hora de planificar el sprint éstas funcionalidades estén listas para comenzar. Si aún así el desarrollo sigue encontrando tareas que aún no están bien descritas quizás deba dedicarse una parte mayor del equipo a analizar y concretar estas tareas en lugar de a desarrollar.
¿Qué ocurre con un equipo que mezcla seniors y juniors con grandes diferencias salariales?¿van a empujar todos con la misma intensidad? 
Bueno, en principio, se supone que la diferencia salarial corresponde a su nivel de experiencia y saber hacer en su trabajo por lo que los junior cobran menos. Conocen aún poco sobre la tecnología o el producto y que, a medida que van aprendiendo y adquiriendo experiencia esta diferencia se acorta o desaparece.
Si algún miembro del equipo entiende que no cobra a razón de lo que está aportando es cierto que puede perder el ánimo o las ganas de trabajar. Aquí entramos en un asunto de recursos humanos en lugar de Scrum pero yo le aconsejaría que comente con sus responsables el trabajo que ha realizado y lo que ha podido aportar y vea con ellos si tienen la misma percepción sobre esto y consideran que en algún momento puede hacerse una revisión de su salario.
¿Qué ocurre cuando el Team auto-gestionado tiene que tomar una decisión técnica?¿vale igual el voto de un senior que el de un junior?
Yo no pondría valor a los votos del equipo de trabajo. A veces la mejor idea puede venir del que lleva menos tiempo en el trabajo, aunque lo habitual sea que los senior sean los que más aporten en la discusión que llevará a la decisión técnica que finalmente se tome.
Algo que he utilizado a veces es escribir en una pizarra las ventajas e inconvenientes de cada solución. A veces, nada más terminar de escribir esos pros y contras todos nos damos cuenta de cuál es la solución que más conviene ahora. Otras veces esto no está tan claro y hay que apostar por una aunque no haya consenso.

Cuidado si la opción por la que se apuesta es siempre la de ‘hay que hacerlo así ahora porque no tenemos tiempo‘. Es verdad que a veces es la solución que se debe tomar ante una urgencia. Explícale bien al equipo de trabajo el por qué de esta decisión en estos momentos pero explícale también al Cliente que ahí ha quedado un asunto por resolver que deberá ser programado para un próximo sprint si no queremos que esa deuda técnica nos acumule más errores pronto. Si no hacemos esto, con los años, el proyecto se nos puede convertir en uno de esos proyectos en los que todo el equipo de trabajo está resolviendo bugs y no nos queda tiempo para desarrollar nuevas funcionalidades.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

 

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.

Suscríbete