El cambio hacia la agilidad
Gestión regular de las expectativas del cliente y del ROI, time to market, flexibilidad frente a cambios, riesgos menores, productividad, calidad y equipo motivado.
Agilidad es mayor satisfacción para todos los que participan en un proyecto, clientes y trabajadores. Agilidad es innovación y productividad.
Cultura de empresa basada en trabajo en equipo, colaboración, delegación, creatividad y mejora continua. Disponibilidad del cliente para la dirección de los resultados del proyecto. Relaciones basadas en ganar-ganar y transparencia. Facilidad para realizar cambios.
Cláusulas que especifican la relación entre cliente y proveedor en un proyecto ágil, incluyendo la Creación de la lista de objetivos priorizada (Product Backlog), los Cambios de requisitos y la Finalización anticipada del contrato.
Cambio cultural y de valores. Respeto y reconocimiento a quien es válido. Las metodologías ágiles “aplanan” la jerarquía de la empresa. Factorías de software jerárquicas. La universidad enseña “waterfall”. La mayor parte de los recursos están en inglés. Poco conocimiento de metodologías en general en las empresas, y menos si son “nuevas”.
Scrum es un conjunto de prácticas especialmente combinadas para dar soporte a la creación de productos innovadores y enfocar el trabajo del equipo en producir valor directo para el cliente final. El uso regular de estas prácticas (entregas frecuentes priorizadas por valor, potenciación del equipo de trabajo, mejora continua de producto y de proceso, etc.) permite que los cambios dentro de un proyecto sean aceptados de manera natural y proporciona al cliente margen para flexibilidad e innovación así como productividad y calidad.
Fundamentos
Situaciones en las que se utiliza Scrum y breve introducción al proceso.
Los orígenes de Scrum están en un estudio sobre equipos superproductivos que desarrollaban productos novedosos a partir de requisitos muy generales. También se listan algunas grandes empresas que utilizan Scrum.
Planificación en bloques temporales, al final de cada cual se entrega producto final para reducir riesgos, gestionar las expectativas del cliente, aprender sobre el producto, permitir cambios a corto plazo y reducir el time-to-market.
La complejidad de un proyecto depende de factores como los requisitos, las tecnologías y las personas implicadas. Las metodologías tradicionales se apoyan en planificación inicial detallada (y desarrollo en cascada) mientras que las ágiles inspeccionan de manera regular el producto final que se está desarrolando.
El cliente reprioriza los requisitos cada iteración, según su valor en ese momento y su coste estimado de desarrollo. Puede llegar a un punto en que no valga la pena desarrollar los requisitos restantes, dado el poco retorno de inversión (ROI) que tienen.
Todas las actividades de Scrum son timeboxed, tienen un tiempo máximo para conseguir unos objetivos. De esta manera se favorece la priorización de objetivos y tareas y se fuerza la toma de decisiones. Con ello se fomenta la productividad y el aprendizaje del tiempo necesario para realizar una tarea.
En todo proyecto existen 3 variables relacionadas: el alcance, el tiempo y los recursos. Para mantener unos objetivos de calidad determinados, cualquier modificación en una de las 3 variables implica la modificación de alguna de las otras dos.
Personas
El gestor de proyecto pasa a ser un facilitador que vela por que se cumpla el proceso de Scrum, quita impedimentos, protege al equipo y facilita las reuniones para que tanto el equipo como el cliente colaboren y se obtengan las máximas sinergias.
El buen gestor confía en su equipo y lo potencia; ayuda a que avance, promueve la comunicación y la confianza entre el equipo y con el cliente; tolera errores y no busca culpables, sino mejorar el proceso de trabajo; practica con el ejemplo.
Es el representante de todos los interesados en el proyecto, con autoridad para tomar decisiones. Define los objetivos del producto o proyecto y dirige los resultados del proyecto maximizando su ROI, para lo cual participa en las reuniones de planificación de iteración y de demostración.
Desarrolla el producto y tiene un objetivo común, dado que adquiere un compromiso en cada iteración. Es un equipo autoorganizado y multidisciplinar, idealmente de entre 5 y 9 personas a tiempo completo, en una misma localización física y trabajando en un único proyecto.
El equipo selecciona los objetivos/requisitos que se compromete a desarrollar en cada iteración. Se autogestiona para identificar tareas, estimar esfuerzos y autoasignarse tareas. Al finalizar cada iteración demuestra los objetivos completados y analiza las mejoras a realizar en su modo de trabajar.
Los skills en un equipo ágil se pueden agrupar según estén relacionados con la orientación a producir valor para el receptor final del producto, con la capacidad de trabajar en equipo o con la capacidad de mejorar.
El equipo participa con el cliente en la creación de la lista de objetivos/requisitos priorizada del producto o proyecto, proporciona la estimación de su esfuerzo y pregunta al cliente los detalles en la reunión de planificación de la iteración.
Planificación del producto o proyecto
Lista de objetivos/requisitos priorizada según el valor que aportan al cliente, su coste estimado de desarrollo (en función de la “definición de completado”) y los riesgos asociados. Está dividida en iteraciones de duración fija (2 o 4 semanas) y entregas.
La gestión de proyectos ágiles es una actividad adaptativa en vez de predictiva, debido a que el desarrollo de software es una actividad de creación y transmutación de conocimiento. Es conveniente producir valor en lotes pequeños y de manera incremental. El Product Backlog se puede expresar como historias de usuario ("user stories") y calcular su tamaño relativo (puntos de historia) mediante planning poker. Mediante la velocidad del equipo se puede estimar cuando acabará el proyecto.
El equipo realiza la estimación de proyecto. Para ello utiliza días ideales o bien puntos de historia de usuario, mediante una técnica rápida y fiable: planning poker. Mediante la velocidad de desarrollo (que en el inicio es más inestable) se puede ir proyectando cuando finaliza el proyecto. La estimación ágil ayuda a crear “conciencia de equipo”.
Replanificación del producto o proyecto
Para cada nuevo objetivo/requisito se hace una identificación inicial de sus condiciones de completitud, se re-estiman los costes de desarrollo para completar los objetivos/requisitos siguientes y se reprioriza la lista de objetivos/requisitos.
Todos los objetivos (o historias de usuario) deben proporcionar valor al cliente. La “generalización” del producto puede ser peligrosa para el negocio. Pruebas de concepto en el Product Backlog. El Product Backlog como iceberg.
La priorización de prácticas ágiles puede depender de diferentes factores: si el proyecto va a tener evolución posterior, su tamaño, el conocimiento de la tecnología, si el equipo ha trabajado junto anteriormente, qué aspecto se quiere mejorar, etc. El artículo incluye un diagrama de prácticas y una priorización considerando un proyecto sin evolución posterior y de corta duración.
Las tarjetas permiten planificar de forma ágil utilizando los criterios de valor, esfuerzo y riesgo para cada objetivo, así como las dependencias e integraciones entre distintos proyectos.
Planificación de la iteración
Plan que elabora el equipo para completar los objetivos/requisitos seleccionados para la iteración. Se suele gestiona en forma de tablero de tareas (Scrum Taskboard).
Reunión en que el cliente define la meta de la iteración, el equipo selecciona de los requisitos más prioritarios que se compromete a completar y planifica las tareas.
Durante la ejecución
En un máximo de 15 minutos todos los miembros del equipo responden a las preguntas: ¿Qué he hecho? ¿Qué voy a hacer? ¿Qué impedimentos tengo?. En esta reunión no se resuelven problemas.
Recomendaciones: minimizar el número de requisitos en que el equipo trabaja simultáneamente y no cambiar los objetivos/requisitos de la iteración. Terminación anormal de la iteración.
Muestran la velocidad a la que se está completando los objetivos/requisitos. Permite extrapolar si el equipo podrá completar el trabajo en el tiempo estimado.
Métricas
La métrica más importante es el valor que se está dando al cliente. En ciertas ocasiones puede ser necesario complementarla con otras de métricas creando un cuadro de mandos integral ágil.
Tener sólo las métricas realmente necesarias (valor, velocidad, etc.). Deben estar “balanceadas”. Criterios de planificación de objetivos: valor, coste, riesgo, integraciones y madurez. La percepción del valor cambian según avanza el proyecto.
Cómo calcular la velocidad y el factor de foco iniciales y finales, así como el % de error de estimación, considerando también las tareas no planificadas.
Inspección y adaptación
En un máximo de 15 minutos todos los miembros del equipo responden a las preguntas: ¿Qué he hecho? ¿Qué voy a hacer? ¿Qué impedimentos tengo?. En esta reunión no se resuelven problemas.
Reunión en que el equipo presenta al cliente los requisitos completados en la iteración, en forma de incremento de producto preparado para ser entregado con el mínimo esfuerzo.
¿Es valioso parar el desarrollo durante algunos días completos antes de la demostración y dedicarlos a estabilizar el producto para que sea susceptible de ser entregado al cliente?
Reunión en que el equipo analiza cómo ha sido su manera de trabajar durante la iteración: qué cosas han funcionado bien, cuales hay que mejorar, qué ha aprendido.
Cómo llevar a cabo las actividades típicas de una retrospectiva: puesta en escena, identificación de problemas, descubrimiento de causas, plan de acción y conclusiones de la reunión.
En lugar de tratar sólo los temas que fueron bien y mal, se puede hacer una retrospectiva según lo que hay que empezar a hacer, lo que hay que seguir haciendo, lo que hay que hacer más, lo que hay que hacer menos y lo que hay que parar de hacer.
Explicación de la retrospectiva Express y del concepto de “shortlists” de los resultados de las actividades típicas (identificación de problemas, causas y soluciones).
Calidad
Agilidad es mayor satisfacción para todos los que participan en un proyecto, clientes y trabajadores. Agilidad es innovación y productividad.
Calidad es cumplir con las expectativas del cliente y del equipo, que el producto tenga un comportamiento correcto (funcional y no funcional) y que sea evolucionable. Scrum es certificable en CMMI nivel 3. El papel de Q/A es evitar que se produzcan errores.
Ingeniería
Deuda técnica vs perfeccionismo. Integración continua en entornos multiequipo. Aprovechamiento de los nightly builds para métricas de calidad y pruebas de stress. El valor aportado al cliente mediante prácticas de ingeniería ágiles.
Experiencias y ejemplos
En este proyecto CMMI nivel 2 nos ha servido para uniformizar criterios sobre la gestión de los proyectos, pero no especifica nada sobre las metodologías de desarrollo o gestión del equipo, ni del proceso concreto de creación de software. Las metodologías ágiles se centran en personas e interacciones así como la eficiencia del equipo.
La nueva propietaria de la casa de campo se dio un paseo por los jardines. Algunas partes estaban en muy mal estado. Llamó a su capataz y le dijo lo preocupada que estaba: se había comprometido con su circulo de negocios a dar una recepción en un mes, y tenía serias dudas de si eso sería posible.
Este juego permite que los participantes simulen el proceso de Scrum y puedan compararlo con el desarrollo tradicional (en cascada/waterfall), comprobando cuáles son los principales beneficios de Scrum, especialmente los referidos a retorno anticipado de inversión, alineamiento con las expectativas del cliente, flexibilidad y adaptación.
Comunidades, webs, blogs, cursos, libros y podcasts.
- Todas las páginas de esta web se van mejorando de manera regular.
- Si quieres ver los artículos según su fecha de publicación, pulsa aquí.
- Si sólo quieres ver el proceso de Scrum identificando actividades, roles y artefactos, pulsa aquí.
- Si quieres contribuir con un artículo, pulsa aquí.