Es frecuente apostar por un camino profesional: PMI, Scrum, Lean, CMMI... por ser el que las circunstancias nos han puesto delante como solución, y tirar así por él sin conocer cuál es su trayectoria en un mapa de situación general. De dónde viene y a dónde va; y sobre todo hacia dónde queremos ir por el tipo de empresa y proyectos  en los que trabajamos.

Hace un rato comentaba Angel: "... aún hay un gran desconocimiento sobre metodologías ágiles en entornos que podríamos llamar "tradicionales". Ocurre lo mismo con los que llevan años trabajando con Scrum u otras metodologías ágiles.."

Aunque las clases y los apuntes de introducción son menos amenos que los que entran directamente en harina mostrando cómo estimar un backlog, componer una pizarra kanban, etc.  he pasado a post los apuntes del que consideré curso necesario de introducción en la plataforma Scrum Manager, antes de tratar historias de usuario, reuniones, gráficos burn-down, etc. para partir desde el marco de situación de la agilidad, y desde la conveniencia de considerarla de forma global y flexible.
Para acostumbrarnos desde el principio a ser los artífices de nuestro marco de trabajo, y los que seleccionamos, adaptamos o diseñamos los procedimientos trabajamos.

Mapa de situación.

Escribir "lista definitiva", de "buenas prácticas...", y más, en un blog, puede sonar como los "requisitos definitivos" de un proyecto ágil: ¿Estos son? ¿No van a cambiar?

Este artículo es un backlog, o pila, si empleamos en nuestro idioma: una lista en continuo cambio, para ir completando y mejorando entre todos, vuelta tras vuelta.

CRITERIO DE CLASIFICACIÓN

Prácticas

Dicen "CÓMO" hacer las cosas: cómo describir y gestionar los requisitos (historias de usuario, elementos de backlog...), cómo estimarlos, cómo realizar las reuniones para validar con el cliente, cómo realizar el mantenimiento del código, las pruebas, la integración...

Este artículo explica tres prácticas ágiles de estimación y planificación:

• El gráfico burn-up o gráfico de producto, para mostrar en un vistazo el plan general de desarrollo del producto. A partir de la velocidad del equipo y las estimaciones previstas en la pila del producto, representa las fechas o sprints en los que se irá terminando cada versión.
• El gráfico burn-down o gráfico de avance, para monitorizar el ritmo de trabajo del sprint.
• La estimación de póker, para conducir reuniones con estimación de tareas por juicio de expertos: en su concepción original y para estimación sobre sucesiónd e Fibonacci.

Es un texto del curso de métricas ágiles de Open Knowledge de ScrumManager.

• Descargar artículo en formato PDF

Velocidad, trabajo y tiempo son las tres magnitudes que mide la gestión de proyectos ágil. Las tres componen la fórmula de la velocidad, definiéndola  como cantidad de trabajo realizada en por unidad de tiempo.

Según el producto, o incluso el momento de evolución en el que está, puede resultar más dinamizador para el equipo cambiar como criterio base de "time box" el sprint backlog, por el de "mínima funcionalidad integrable".
Gestionar estas "MFI" al estilo que el modelo de Producción de Toyota consideraría cada unidad Kanban.

Tiene la ventaja de seguir lo más cerca posible las prioridades del cliente. La versión del Just in Time de la programación. También tiene el riesgo de que el equipo pierda la visión general del producto, y el concepto de "objetivo del sprint". Para evitarlo se deben mantener tres niveles de zoom de los requisitos del proyecto: funcionalildades de producto, de versión y tareas; y es muy útil trabajar con pizarras Kanban:

La gestión ágil entrega de forma periódica y continua pequeñas partes del sistema completamente terminadas y operativas, por eso el cliente (propietario del producto, en terminología Scrum), decide qué le corre más prisa, según las necesidades de su negocio, y por tanto qué partes se deben programar antes; vamos, lo que Scrum llama "priorización del product backlog".

Pues bien, un criterio interesante para "priorizar el product backlog" puede ser obtener el mayor ROI posible, y cuanto antes. ¿A que sí? :-)

Si el desarrollo ágil puede entregar partes del sistema de forma temprana, merece la pena estudiar si también es posible comenzar el retorno de la inversión de forma anticipada.

Al tratar los requisitos en un proyecto ágil, me viene bien considerar que entre la visión del cliente, y las tareas de trabajo diarias, hay 3 niveles de "zoom"

El nivel es un punto de referencia sobre la forma de gestionar los requisitos, y las implicaciones o información que pueden suministrar en otros estratos.

Cuando el cliente no termina de tener claros algunos puntos o cuando la usabilidad es un valor clave del sistema, el prototipado en papel es una excelente técnica de trabajo; y como estos son factores habituales en los proyectos ágiles, es muy útil disponer en el inventario de recursos esta forma de prototipado ligero para echar mano de ella cuando se necesite.

"La parte más difícil en la construcción de sistemas de software es decidir precisamente qué construir" (Frederick P. Brooks Jr.)

El 60% de los problemas de los proyectos tienen su origen, directa o indirectamente en los requisitos; y los problemas de los requisitos surgen por alguna de estas razones:

1.- El cliente no tiene una visión clara de lo que quiere.
2.- El suministrador obtiene los requisitos superficialmente, quizá siguiendo un proceso, pero sin "sumergirse" en conocer el negocio del cliente y realizar desde ahí el análisis.
3.- Implicación y comunicación cliente-equipo de desarrollo. 

Esta podría ser una lista de comprobación con los principales factores que condicionan los resultados de la gestíón ágil de proyectos. Desde luego tenerlos todos es complicado, pero ¿quién dijo que la gestión ágil fuera fácil?

ADQUISICIÓN

• El propietario del producto tiene definida la visión de lo que necesita.
• El propietario del producto está comprometido y se implica con el equipo.
• El propietario del producto conoce los principios del desarrollo ágil.
• De forma previa, o incluido en el primer sprint, se realiza un análisis de adquisición.
• El modelo de adquisición del cliente permite un patrón de desarrollo ágil
• La prioridad para el negocio del cliente es el valor innovador, por encima del plan de un producto cerrado.

En la gestión predictiva, la "bola de cristal" con visión global de proyecto es el diagrama de Gantt. ¿Y en la gestión ágil?.
El modelo ortodoxo de Scrum trabaja con el Gráfico Burn-Down, pero es una bola de cristal que alumbra con "cortas": sólo al sprint actual.  Para vaticinar el proyecto "con largas", apuntando más lejos en la dirección de la visión del cliente, es muy útil el gráfico Burn-Up.
 

La tesis (ISO 12207, 15504, CMMI…) ha identificado y definido las cosas QUE hay que hacer.
La antítesis (XP, Scrum, FDD...) ha mostrado formas de trabajar que funcionan bien: CÓMO hacer determinados "qués".
Posiblemente la síntesis , la moraleja de ambos sea cuestionar los "POR QUÉs"

¿Qué hacer para que los proyectos de software salgan bien?

Sobre requisitos estables y detallados, poner fecha y precio a un contrato puede ser más o menos complicado, pero sólo se trata de calcular esfuerzo y planificar trabajo.

Hacer lo mismo con requisitos inestables y sin certeza de la forma final del producto no es cuestión de ciencia, sino de mancia.

¿Que cuál es el modelo de negocio?. No, no hay modelo de negocio. Es muy pronto para definirlo. No trabajamos con un modelo de negocio, sino con un modelo de valor.

En cierto modo a la estrategia de negocio le ocurre lo que a la gestión de proyectos. Nos hemos acostumbrado a un modelo predictivo:
 

Descripción general
En esta reunión, tomando como base las prioridades y necesidades de negocio del cliente, se determinan cuáles y cómo van a ser las funcionalidades que se van a aportar al producto durante el próximo sprint.

En realidad esta reunión consiste en dos: En la primera, que puede tener una duración de una a cuatro horas, se decide qué elementos de la pila del producto (product backlog) se van a desarrollar.