archivo

Archivos diarios: agosto 21, 2013

Una de las principales ventajas que tenemos si trabajamos con pilas de producto, además de tener un registro de todo lo que está pendiente por hacer (hasta el momento e independientemente de que se hagan todas o no, ya que seguirán apareciendo nuevas historias de usuario y otras se descartarán por la propia evolución del producto), es que el product owner o los responsables funcionales tienen todo un inventario de tareas que poder elegir, sobre las cuales deberán aplicar una prioridad, conociendo de antemano (puede ser pactado en función de las necesidades del sprint) cuál es la capacidad de trabajo máxima que se puede asumir en el sprint.

Independientemente de que después se afine el número de jornadas de cada historia, es fundamental (al menos lo pienso así) que cuando los usuarios están priorizando (o repriorizando) sepan cuánto peso va a tener cada una. De esta forma, tienes una lista de la compra (las historias de usuario), un presupuesto y se deberán quedar con lo que realmente les resulta más prioritario o más adecuado en este momento.

De esta forma los usuarios son conscientes realmente de la cantidad de trabajo que se puede asumir en un sprint y ellos mismos son responsables de elegir lo que se va a hacer.

Se requerirá algo de tiempo para que entren en la dinámica de los sprints y de que no deberían haber cambios mientras se está ejecutando, si bien, no debemos cerrar la puerta a excepciones debidamente justificados, aunque de esta manera perdamos pureza si aplicamos prácticas de Scrum (os recuerdo que las prácticas y metodologías son útiles pero no debemos olvidar que una de las bases del agilismo es la adaptación al cambio y a los contextos).

Cuando se piensa de manera distinta sobre un tema, si no existe un espíritu por las partes implicadas de llegar a un acuerdo común, no se conseguirá y finalmente prevalecerá al opinión del más fuerte, de lo que esté pactado o documentado con anterioridad o de lo que contractualmente esté establecido, que lo mismo no es lo que más interesa en este preciso momento,

Cuanto más se defiendan una serie de argumentos, si las otras partes siguen sin ceder nada, se recurrirá a la hipérbole de los mismos, como medida de choque para tratar de conseguir lo que por otros medios no es posible, cumpliéndose lo que Séneca comentó en su momento: “Una discusión prolongada es un laberinto en el que la verdad siempre se pierde”.

En la gestión de proyectos software sucede con frecuencia este tipo de situaciones y si no hay intención de llegar a acuerdos, el primer damnificado será el proyecto. Es razonable defender las posiciones de tu organización o de tu equipo pero no olvidemos que si el proyecto sale mal, todos perdemos por mucho que se salga victorioso de batallas puntuales que solo servirán para separar a los equipos en lugar de unirlos.

Me estoy encontrando con algunos proyectos en donde el seguimiento de una determinada metodología o de un conjunto de prácticas se antepone a lo que realmente se necesita.

Sprints de dos o tres semanas por tratar de seguir las recomendaciones de Scrum, trabajando sin historias de usuario sólidas, sin tiempo para refinar la pila de producto y sin tener todavía una perspectiva del proyecto.

Después pasa lo que pasa y hay que escuchar los comentarios de siempre: “los desarrollos ágiles no mejoran nada, incluso lo empeoran”, “se ha perdido mucho dinero en proyectos desarrollados con Scrum”, etc…, sin entrar a valorar si realmente las prácticas aplicadas se adaptaban a lo que necesitaba el proyecto y si la actitud ha sido realmente ágil.

El feedback es la clave, todos lo sabemos, pero para sacar verdadero provecho es necesario que se trabaje con intención, es decir, con una cierta base, tirando a dar. Si hay que tirar todo lo desarrollador en el sprint (y parte del trabajo generado en otros previas), se tira, pero que no lo sea por probar sistemáticamente a ver qué pasa.

Ya lo decía Séneca: “A los que corren en un laberinto, su misma velocidad los confunde”.