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.

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.

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.

La ingeniería del software clásica diferencia dos áreas de requisitos: requisitos del sistema, y requisitos del software.

A los primeros los sitúa en el proceso de adquisición, haciendo por tanto al cliente responsable de definir cuál es su problema y qué funcionalidades tiene que aportar la solución.

No importa que sea gestión tradicional o ágil. Esta sigue siendo la responsabilidad del cliente, aunque por supuesto las formas son diferentes.

Ahí van: un modelo de contrato, una plantilla para especificaciones de "requisitos del sistema" conforme al estándar IEEE 1362, y otra para "especificaciones de requisitos del software" con el modelo IEEE 830.

Puede resultar útil el "kit completo" una plantilla, o algún párrafo para "copia-pega" en otros contratos.

En las metodologías ágiles es habitual desarrollar dos niveles de planificación:  una general, planificación de la versión, y otra más detallada, planificación de la iteración.

El objetivo de la planificación de la versión es calcular la dimensión del proyecto. Saber si estamos hablando de 10 o de 100, y tanto en Extreme Programming (Release planning) como en Scrum (estimación del product backlog) se realiza en una reunión en la que participa todo el equipo.

En ella el cliente, o el propietario de producto expone una a una las historias o funcionalidades que necesita y el equipo determina el tiempo que llevará su desarrollo.
Este proceso no es ajeno a los problemas típicos de dinámica de reuniones, y aunque tiene un guión concreto y conocido por todos los participantes, es habitual entrar en atascos de "parálisis por análisis", en los que los minutos van pasando sin que los participantes terminen de decidir entre las posibles soluciones para una determinada funcionalidad y fijen una estimación; y el moderador ve con impotencia cómo ha consumido ya 15 ó 20 minutos sin poder cerrar la primera funcionalidad, y la lista de las que aún están pendientes de valorar.

MoProSoft es la denominación del "Modelo de Procesos para la Industria del Software" desarrollado por la Asociación Mexicana para la Calidad en Ingeniería del Software (AMCIS) de la Universidad Autónoma de México (UNAM) por encargo de la Secretaría de Economía del mismo país.

Dicha Secretaría, dentro del Programa para el Desarrollo de la Industria del Software (PROSOFT ), que forma parte del Plan Nacional de Desarrollo 2001-2006, identificó como modelos referentes para la calidad en el desarrollo y mantenimiento de software: CMMI, ISO 15504, pero al analizarlos para su inclusión en el plan el comité designado no los consideró demasiado formalistas o pesados para la mayoría de las empresas mexicanas.
 

Incorporo esta presentación, junto con el resto de material de Navegapolis a los documentos del nuevo sitio Qualitatis (que mañana os presento, que hoy ya va siendo hora de dormir :-)

Es un "powerpoint" con la visión global de Scrum, que espero os pueda resultar útil.

• Visión global de Scrum .