El Manifiesto Ágil cumple 25 años. Es buen momento para releerlo.
Agile nació para escapar de la burocracia. En muchas empresas acabó convertido en reuniones diarias interminables, ceremonias sin propósito y velocidad usada como indicador de rendimiento. Aquí puedes redescubrir qué significa trabajar con agilidad y encontrar herramientas para llevarlo a la práctica.
Snowbird, Utah · febrero de 2001
Estamos descubriendo formas mejores de desarrollar software, tanto por nuestra propia experiencia como ayudando a otras personas. A partir de este trabajo hemos aprendido a valorar:We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
A pocos proyectos les falta una herramienta. A muchos les falta una conversación. Un buen proceso facilita que las personas se hablen.
Jira se convierte en la única fuente de verdad y hablar con alguien se considera una distracción. Nadie puede cambiar el proceso porque «así lo decidió la oficina de proyectos».
Para ver cuánto se ha avanzado, dale a alguien algo que pueda usar. La documentación tiene valor cuando ayuda a desarrollar o mantener el producto.
«Somos ágiles, así que no documentamos nada». O el extremo contrario: cuarenta páginas de requisitos previos antes de escribir una línea de código.
Un contrato hace falta, pero no sustituye el trabajo de descubrir juntos qué necesita el cliente. La colaboración crea confianza; el contrato fija los acuerdos.
El Product Owner nunca ha conocido a un cliente. En la revisión del Sprint, la dirección mira diapositivas y los usuarios se quedan fuera.
Un plan es una hipótesis. Los usuarios, la tecnología y el mercado cambian más deprisa que un calendario anual. Planificamos a menudo para aprender y corregir el rumbo.
La planificación trimestral deja el alcance cerrado. «¿Un cambio? Anótalo en el backlog y ya lo veremos en el tercer trimestre».
Aunque reconocemos el valor de los elementos de la derecha, valoramos más los de la izquierda.That is, while there is value in the items on the right, we value the items on the left more.
Kent Beck · Mike Beedle · Arie van Bennekum · Alistair Cockburn · Ward Cunningham · Martin Fowler · James Grenning · Jim Highsmith · Andrew Hunt · Ron Jeffries · Jon Kern · Brian Marick · Robert C. Martin · Steve Mellor · Ken Schwaber · Jeff Sutherland · Dave Thomas
© 2001, los autores citados. Esta declaración puede copiarse libremente en cualquier formato si se reproduce íntegra y se incluye este aviso. La redacción que lees aquí es una adaptación. Puedes consultar la traducción oficial en agilemanifesto.org.
Abre un valor para ver qué significa y cómo puede desvirtuarse. Pasa el puntero por la balanza para ver cómo cambia el equilibrio.
Qué es Agile
Agile reúne valores y principios. Cuando desarrollamos un producto, no podemos preverlo todo. Avanzamos en pasos pequeños, enseñamos resultados pronto y aprendemos de quienes lo usan.
Scrum, Kanban, la programación extrema y Lean son formas de llevar esos valores a la práctica. Celebrar cada reunión de Scrum no garantiza agilidad; también se puede trabajar con agilidad sin usar Scrum.
En cascada el cliente recibe el valor al final, siempre que los requisitos iniciales sigan siendo válidos. En el enfoque ágil recibe entregas parciales y puede orientar la siguiente.
Los doce principios del Manifiesto
Cada tarjeta resume un principio y muestra cómo puede perderse en la práctica. Pulsa para darle la vuelta.
Los orígenes de Agile
Agile no apareció de repente en 2001. Lo precedieron tres décadas de frustración con procesos pesados y de experimentos para encontrar alternativas más ligeras.
Winston Royce publica un artículo sobre la gestión de grandes proyectos. Su diagrama en cascada se convierte en modelo para la industria, aunque el propio Royce advierte del riesgo de hacerlo todo de una sola pasada y recomienda iterar.
En «The New New Product Development Game», publicado en Harvard Business Review, Hirotaka Takeuchi e Ikujiro Nonaka describen equipos pequeños que avanzan con el balón juntos, como en el rugby, en lugar de pasarse el testigo por etapas.
Aparecen RAD, DSDM, Crystal y el desarrollo guiado por funcionalidades. Comparten los ciclos cortos, la cercanía al cliente y menos trámites. Entonces se conocían como «métodos ligeros».
Ken Schwaber y Jeff Sutherland presentan Scrum como marco para desarrollar productos complejos. Se apoya en el empirismo: transparencia, inspección y adaptación.
Kent Beck publica «Extreme Programming Explained». La programación en pareja, el desarrollo guiado por pruebas, la integración continua y las entregas pequeñas hacen de la disciplina técnica una base de la agilidad.
En febrero, diecisiete profesionales se reúnen en una estación de esquí. Discrepan sobre los métodos, pero coinciden en los valores. De allí sale una página: el Manifiesto Ágil. Pocos meses después nace la Agile Alliance.
David J. Anderson aplica principios lean y sistemas de reposición según la demanda en equipos de Microsoft y, más tarde, de Corbis. En 2010 publica «Kanban». El foco está en el flujo y en limitar el trabajo en curso.
Schwaber y Sutherland publican la primera Guía Scrum. La edición de 2020 tiene unas trece páginas. Da más peso al objetivo del producto y habla de «Developers» en lugar de un equipo de desarrollo separado.
El marco ágil más extendido
Scrum deja margen a propósito: propone una estructura mínima y el equipo toma las demás decisiones. Elige un evento para conocer su objetivo, su duración y un error habitual.
Elige un evento
Cada evento Scrum ofrece una ocasión para inspeccionar y adaptar. Si una reunión nunca cambia ninguna decisión, es fácil que se convierta en un ritual.
Todo el equipo Scrum
Duración máxima hasta 8 h para un Sprint de un mes
Acordamos para qué sirve este Sprint, qué podemos terminar y cómo vamos a trabajar para alcanzar su objetivo.
Los desarrolladores
Duración máxima 15 minutos
Los desarrolladores revisan el progreso hacia el objetivo del Sprint y adaptan su plan para el día siguiente.
El periodo que contiene los demás eventos
Duración máxima duración fija, como máximo un mes
El Sprint marca el ritmo al que las ideas se convierten en valor. Es un pequeño experimento que acaba con un incremento utilizable.
Equipo Scrum y partes interesadas
Duración máxima hasta 4 h
Examinamos juntos el resultado del Sprint y decidimos qué hacer después. Es una sesión de trabajo en la que las personas interesadas participan.
Equipo Scrum
Duración máxima hasta 3 h
Buscamos maneras de mejorar la calidad y la eficacia. Revisamos cómo colaboramos, los procesos, las herramientas y la definición de terminado.
Desarrolladores y Product Owner
Duración máxima actividad continua; no es un evento formal
Dividimos y aclaramos elementos del backlog del producto para poder seleccionarlos en futuros Sprints.
Maximiza el valor del producto. Gestiona el backlog del producto y decide su orden.
No es alguien que toma nota de requisitos sin poder decidir.
Responde por la eficacia del equipo. Enseña, acompaña, ayuda a eliminar impedimentos y explica el empirismo en la organización.
No es la jefatura del proyecto, quien convoca las reuniones ni quien administra Jira.
Crean un incremento utilizable en cada Sprint. Planifican su propio trabajo y se responsabilizan de la calidad.
No son «recursos» destinados a ejecutar tickets asignados.
Basado en la Guía Scrum de 2020, de Ken Schwaber y Jeff Sutherland: scrumguides.org.
Kanban
Kanban parte de cómo trabajas hoy. No exige cambiar roles ni añadir reuniones. Para que el trabajo fluya, un buen punto de partida es limitar el trabajo en curso (WIP).
La ley de Little relaciona los promedios: tiempo de ciclo = trabajo en curso ÷ tasa de finalización. Si quieres acortar los plazos, prueba a tener menos tareas abiertas a la vez.
⚠️ Cuello de botella: demasiado trabajo en curso forma una cola y retrasa cada elemento.
Si terminas la misma cantidad de trabajo por semana, pasar de doce tareas en curso a cuatro reduce el tiempo de ciclo a un tercio.
Agile en la práctica
Administración pública
Tras años de problemas con la contratación tradicional, el FBI asumió el desarrollo de su sistema de gestión de casos. Un equipo pequeño lo completó en ciclos cortos. Entró en servicio en 2012.
Las iteraciones cortas y un equipo pequeño pueden rescatar un proyecto que ha agotado su presupuesto.
Sector público
El servicio digital del Gobierno británico creó un portal único para los servicios públicos. Pasó del descubrimiento a las fases alfa, beta y de servicio activo y publicó sus principios en un manual abierto.
En una institución también se puede empezar por lo que necesita el usuario.
Ingeniería
Un equipo de voluntarios desarrolló un coche de bajo consumo en Sprints de una semana. El diseño modular permitía intercambiar piezas igual que se intercambian los componentes de software.
Las iteraciones y el diseño modular también funcionan con productos físicos.
Fuera de la informática
El equipo muestra sus campañas en un tablero, limita cuántas mantiene abiertas y mide el tiempo entre la idea y el lanzamiento. Reduce los cambios de contexto y termina antes.
Para empezar con Kanban, muestra el trabajo, limita lo que está en curso y mide el flujo.
Vida cotidiana
En vez de cerrar todo el plan de antemano, se reforma primero el baño, que es lo que más falta hace. Lo que se aprende ayuda a acometer la cocina. Cada etapa deja algo que ya se puede usar.
Entregar algo útil en cada paso también tiene sentido fuera del trabajo.
Tu equipo
Los cambios pequeños, las pruebas automáticas, la integración continua y una definición de terminado útil reducen el riesgo de desplegar y acortan la espera para recibir opiniones.
La excelencia técnica puede aportar más agilidad que añadir otra reunión.
Cuestionario rápido
1/8Ser ágil significa no documentar nada.
El Manifiesto da más valor al software que funciona que a la documentación exhaustiva. Preferir una cosa no elimina la otra: documentamos lo que resulta útil.
2/8Agile y Scrum son lo mismo.
Agile reúne valores y principios. Scrum, Kanban, XP y Lean son formas distintas de ponerlos en práctica. Se puede trabajar con agilidad sin usar Scrum, y usar Scrum sin ser ágil.
3/8El Manifiesto Ágil no menciona las reuniones diarias, los Sprints ni los puntos de historia.
Ni una palabra. Son prácticas y herramientas. El Manifiesto contiene cuatro valores y doce principios.
4/8La velocidad sirve para comparar equipos.
Los puntos de historia son relativos a cada equipo. Comparar velocidades solo invita a inflar las estimaciones.
5/8El Scrum diario es para los desarrolladores, no para rendir cuentas a su responsable.
La Guía Scrum explica que los desarrolladores usan el Daily para adaptar el trabajo de las próximas 24 horas al objetivo del Sprint.
6/8Cuando se trabaja con agilidad no se planifica.
Se planifica mucho, con mayor frecuencia y en tramos más pequeños. El plan cambia a medida que aprendemos.
7/8El equipo tiene derecho a cambiar su forma de trabajar.
Para eso sirve la retrospectiva. Un proceso que nadie puede cambiar difícilmente será ágil.
8/8Los puntos de historia se inventaron para medir la productividad individual.
Sirven para conversar sobre la complejidad y elaborar previsiones. Ron Jeffries, a quien suele atribuirse parte de su origen, ha lamentado públicamente algunos de sus usos actuales.
Colección
Una sudadera, una gorra, una taza y una pegatina con el logotipo de Make Agile Great Again. La tienda abrirá próximamente.
Ver la colección