Malinterpretando la velocidad
- Detalles
- Publicado: Jueves, 16 Julio 2009 10:00
- Escrito por Leonardo De Seta
La velocidad es un concepto ágil muy importante que le sirve a los equipos para poder comprometerse al trabajo de una iteración. Sin embargo, una vez entendido el concepto, hay que tener cuidado en no usarlo para motivos equivocados, y evitar al máximo cometer algunos errores básicos.
En este artículo vamos a ver 3 anti-patrones sobre el concepto de velocidad; comprenderlos y evitarlos nos ayudará a mejorar nuestro proceso de desarrollo.
Hay 2 partes de Scrum que suelen quedar olvidadas al momento de implementar esta metodología ágil. Como Scrum es un marco de trabajo minimalista, sólo con lo mínimo para mantener a un equipo fuera del caos, pueden surgir problemas cuando falta una pieza de Scrum. Las 2 partes que comunmente quedan afuera son: 
Uno de los primeros temas que suele aparecer en cualquier discusión sobre Ágil es "¿Qué tanto se puede escalar Ágil?". A veces se pregunta de forma explícita, pero a menudo se parte del supuesto de que Ágil no puede escalar muy bien. Cuando me encontré con Ágil por primera vez, mi primera impresión fue que Ágil no escalaba más allá de equipos chicos, digamos de 12 personas.
Serge Beaumont, capacitador ágil junto a Jeff Sutherland, nos cuenta que hace ya medio año agregó algo llamado "el modelo dinámico de Scrum". La característica esencial es el concepto de PREPARADO (a no confundir con la Definición de Terminado). La idea es que un equipo necesita estar en una situación estable y conocido para poder trabajar bien. Hay muchos equipos que pierden el tiempo porque el Dueño del Producto no pudo darles un objetivo claro. El estado PREPARADO es el objetivo hacia donde trabajar. Pero, ¿qué es exactamente este estado, y cómo lo logramos?
Ya les comenté algunas veces que en el equipo donde trabajo estamos utilizando 
Después de algunos buenos años de adopción y evangelización ágil, tengo el orgulloso de decir que tengo muy pocas certezas sobre el tema (porque la magia es inspeccionar y adaptar el conocimiento continuamente). Sin embargo, una de esas pocas certezas es: si sos perezoso, ni pienses en implementar metodologías ágiles.
Cada tanto surge la interesante pregunta de cómo hacer la "gestión de recursos" en una organización que está adoptando Ágil. "¿Cómo podemos planificar a una persona el 100% en un único equipo cuando tenemos tantos proyectos para hacer?". El tema es que esta es la pregunta equivocada. En vez de responder a la pregunta de cómo gestionar los recursos, es preferible hacerse la pregunta correcta: "¿Cómo puedo no gestionar los recursos? ¿Cómo puedo evitarlo por completo, o al menos minimizarlo?".
¿Preferimos una mentira (ilusión) para apoyar el inicio del proyecto, o deseamos realmente tener entregas de software con valor en el inicio del mismo? Esta pregunta debe ser la guía principal cuando nos preguntan sobre plazos para un proyecto, sobre todo si asumimos con conciencia la incertidumbre, la imprevisibilidad y la intangilibidad que es el desarrollo de software. O sea, la respuesta a la pregunta depende de enfocar todo a la forma de trabajo y principalmente a los resultados generados por el proyecto.
Quiero intentar explicar aquí que en la práctica no existe una idea matadora para todos los problemas, y si podemos evidenciar que la incertidumbre nuestra de cada día, es clave para nuestra evolución y aprendizaje incluso si esto ocurre en pequeños pasos.
Tradicionalmente los proyectos de software son estimados usando períodos de tiempo como unidad de medida. "Esta funcionalidad llevará 5 días para ser completada" o "Esta tarea me tomará 2 horas." Los procesos ágiles en general han adoptado otra forma de estimación de actividades y alguna confusión se ha creado en torno a esta cuestión.
¿Ven esta pila de dinero a la izquierda? Representa tan sólo una pequeña fracción de la cantidad de dinero que tu organización está desperdiciando por no poder gestionar correctamente el alcance de los proyectos. Y no me refiero a los retrasos ocasionados por requerimientos crecientes. Estoy hablando de algo completamente diferente. Algo mucho más fundamental y facil de obtener cuando una organización realmente se compromete con todo lo que Ágil tiene para ofrecer. Para mi éste es uno de los beneficios más importantes de la agilidad, pero hay muy pocas organizaciones que lo hacen bien.