La planificación ágil parte de la idea de planificar en función de objetivos de negocio en lugar de tareas (a diferencia de la planificación tradicional), priorizando los que aportan más valor, y esperando a dar detalle a objetivos y tareas conforme se va acercando el momento de construcción de estos objetivos, cuando la indeterminación se va reduciendo, de manera que se amortiza el esfuerzo de planificar de manera detallada.

A continuación se muestran los conceptos comunes y las especificidades de cada uno de los planteamientos de planificación mencionados.

En este encuentro se utilizó un diagrama de prácticas ágiles para priorizarlas considerando su aplicación en el desarrollo de producto en su punto inicial (por ejemplo, en una startup).

La priorización de las prácticas difiere del caso tratado en el encuentro anterior, en que se evaluaron el uso de estas prácticas en el caso de un proyecto “corto”, de 3 meses, y sin evolución posterior. Los factores que más condicionan esta diferencia de priorización son la duración del proyecto y, por consiguiente, el grado de responsabilidad del equipo sobre su calidad técnica (la facilidad de mantenimiento/crecimiento del producto a posteriori).

Hacer clic en la imagen para ampliarla

A continuación se muestran las principales diferencias en la priorización de prácticas:

• El tipo de proyecto, respecto a si no va a tener evolución posterior, o bien si se trata del desarrollo de un producto.
• Su tamaño (esfuerzo necesario a realizar), su complejidad, el número de personas implicadas.
• El conocimiento de la tecnología y del dominio (tipo de negocio) por parte del equipo.
• El conocimiento del proceso de trabajo.
• El conocimiento entre los miembros del equipo, si han trabajado anteriormente juntos.
• El tipo de aspecto a mejorar dentro del proyecto (calidad, tiempos de entrega, productividad, etc.).

 

En este encuentro Alexis Roqué de <Undefined> explicó su ecosistema ágil. Se hizo hincapié en el ecosistema como soporte a la comunicación entre los actores que participan en un proyecto (incluyendo al cliente), en la necesidad de un jardinero del ecosistema (en función de su complejidad) y en lo interesante que puede ser disponer de un buen sistema de gestión y push de conocimiento a nivel de empresa. Finalmente se subrayó que un cambio en la manera de trabajar siempre implica formación, perseguir e ir mejorando.

En este encuentro se compartieron experiencias sobre los siguientes temas:

• Se debe tener sólo las métricas realmente necesarias.
• Deben estar “balanceadas”, para detectar si se está obteniendo unos resultados a costa de otros.
• Las métricas ágiles más importantes son: el valor que se va entregando el cliente y la velocidad de desarrollo.
• Las métricas se pueden ampliar cuando se quiere ver la evolución de un problema. Una vez solucionado, se dejan de recoger.
• Los criterios básicos de planificación de objetivos/requisitos de proyecto son el valor y el coste, a los que se puede añadir: riesgo, integraciones y madurez.
• La percepción del valor de los requisitos puede ir cambiando según avanza el proyecto. Esto se gestiona en la replanificación que se hace al inicio de cada iteración.

En este encuentro se compartieron experiencias sobre los siguientes temas:

• Gestión de dependencias entre objetivos de proyecto.
• Estimación del proyecto por parte de todo el equipo, utilizando días ideales o bien puntos de historia de usuario.
• Planning Poker para hacer una estimación inicial del proyecto rápida y fiable.
• Uso de la velocidad de desarrollo para ir proyectando el final del proyecto.
• Pruebas de concepto para realizar estimaciones.
• Estimación y planificación de iteración basada en compromiso.
• La estimación ágil ayuda a crear “conciencia de equipo”

Autor: Xavier Quesada Allue

Saber estimar y planificar es fundamental a la hora de encarar proyectos donde el producto necesita de un grado importante de creatividad y/o innovación, como por ejemplo los de desarrollo de software. En este artículo, presentamos algunos principios y prácticas introductorias para aprender a estimar y planificar un proyecto ágil.

Para planificar un proyecto desde la óptica ágil y crear la primera versión del backlog (lista de objetivos priorizados) se pueden utilizar los siguientes criterios de priorización:

• El valor para el cliente de cada objetivo o requisito de alto nivel.
• El esfuerzo estimado de desarrollo de los objetivos, proporcionado por el equipo.
• El riesgo asociado a cada objetivo (madurez de requisitos, riesgos tecnológicos, personas que participan, en línea con los factores de complejidad de los proyectos).

• Las dependencias e integraciones entre los proyectos, para asegurar que se traten de manera simultánea y en el momento adecuado.
• El riesgo asociado a estas dependencias e integraciones.

• Principios de Lean Software Development, a modo de ayuda cuando Scrum no proporciona una solución directa a un problema.
• Cómo gestionar historias de usuario que comparten implementación, haciendo énfasis en no perder el foco de que toda historia de usuario debería proporcionar algún valor al cliente.
• Empezar por las historias de usuario más claras y que aportan más valor, y así en el futuro evitar modificar código de requisitos actuales dudosos.
• La “generalización” del producto puede ser peligrosa para el negocio, no hay que olvidarse de obtener resultados a corto-medio plazo para el negocio
• Cómo poner las pruebas de concepto en el product backlog, siempre sin perder de vista que el tiempo para estas pruebas debe estar acotado (timebox) y que debe poder medirse el progreso de la prueba.
• El backlog como iceberg, en el cual los primeros objetivos son más pequeños, están más detallados, y los últimos son meros recordatorios de grandes objetivos a conseguir.

La lista de objetivos/requisitos priorizada representa la visión y expectativas del cliente respecto a los objetivos y entregas del producto o proyecto.