La Definición de Preparado
- Detalles
- Publicado: Lunes, 06 Julio 2009 12:20
- Escrito por Leonardo De Seta
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.
La forma más común para que los equipos entreguen productos más rápido es reduciendo el alcance de cada producto. Sin embargo, esto no puede hacerse de manera arbitraria. Hay motivos de negocio reales para cada una de los requerimientos que se piden (¡o al menos eso esperamos!). 
Una característica clave de los equipos que hacen Programación en Parejas es que su nivel de comunicación es mucho más alto que los equipos que trabajan en forma individual. Y es ahí donde podremos encontrar el verdadero motivo en aplicar esta técnica.
Recientemente, 