Principios y valores de Agile, por Jeff Sutherland
Jeff Sutherland inventó Scrum en 1993 y trabajó con Ken Schwaber para formalizar Scrum en OOPSLA'95. Juntos, extendieron y mejoraron Scrum en muchas empresas de software y ayudaron a escribir Agile Manifesto. Jeff revisa en su blog los orígenes y los procedimientos recomendados de Scrum en http://scrum.jeffsutherland.com. |
"Desarrollo ágil" es un término derivado del Manifiesto Ágil (Agile Manifesto), escrito en 2001 por un grupo que incluía: a los creadores de Scrum, Extreme Programming (XP), Dynamic Systems Development Method (DSDM) y Crystal; un representante de desarrollo controlado por características; y otros coordinadores diversos del pensamiento en la industria del software. El Manifiesto Ágil (Agile Manifesto) estableció un conjunto común de valores y principios dominantes para todas las metodologías ágiles individuales en el momento. Detalla cuatro valores básicos para habilitar equipos de alto rendimiento.
Los individuos y sus interacciones
Entregar software que funciona
Colaboración del cliente
Responder al cambio
Estos valores básicos se sustentan en 12 principios, que puede encontrar en el siguiente sitio web: Manifesto for Agile Software Development.
Estos valores no son sólo algo que los creadores del Manifiesto Ágil (Agile Manifesto) pensaban encomiar y, a continuación, olvidarse. Son valores que funcionan. Cada metodología ágil individual enfoca estos valores de una manera ligeramente diferente, pero todas estas metodologías tienen procesos y ejercicios concretos que fomentan uno o más de estos valores.
Individuos e interacciones
Los individuos e interacciones son esenciales para los equipos de alto rendimiento. Los estudios de "saturación de la comunicación" durante un proyecto mostraron que, cuando no existe ningún problema de comunicación, los equipos pueden rendir 50 veces más que el promedio del sector. Para facilitar la comunicación, los métodos ágiles confían en los ciclos de inspección y adaptación frecuentes. Estos ciclos pueden variar de cada pocos minutos con programación entre iguales, cada pocas horas con integración continua o todos los días con una reunión de puesta en marcha, hasta cada iteración con una revisión y retrospectiva.
No obstante, simplemente aumentar la frecuencia de los comentarios y la comunicación no es suficiente para eliminar los problemas de comunicación. Estos ciclos de inspección y adaptación solo funcionan bien cuando los miembros del equipo presentan varios comportamientos clave:
respeto por el valor de cada persona
veracidad en cada comunicación
transparencia de todos los datos, acciones y decisiones
confianza en que cada persona respaldará al equipo
compromiso con el equipo y los objetivos del equipo
Para fomentar estos tipos de comportamiento, la administración ágil debe proporcionar un entorno de apoyo, los entrenamientos del equipo deben facilitar su inclusión y los miembros del equipo deben mostrarlos. Sólo entonces podrán lograr los equipos todo su potencial.
Acercarse a estos tipos de comportamiento es más difícil de lo que puede parecer. La mayoría de los equipos evitan la verdad, la transparencia y la confianza debido a las normas culturales o las experiencias negativas pasadas de conflictos generados por comunicadores sinceros. Para combatir estas tendencias, la dirección y los miembros del equipo deben facilitar el conflicto positivo. Hacerlo no solo ayuda a crear un comportamiento productivo, también tiene varias ventajas más:
La mejora del proceso depende de que el equipo genere una lista de impedimentos o problemas en la organización, se enfrente a ellos directamente y, a continuación, los elimine sistemáticamente en orden de prioridad.
La innovación solo se produce con el intercambio libre de ideas conflictivas, un fenómeno estudiado y documentado por Takeuchi y Nonaka, los padrinos de Scrum.
Alinear al equipo hacia un objetivo común requiere que el equipo manifieste y resuelva las agendas conflictivas.
El compromiso de trabajar juntos sólo se consigue cuando las personas acuerdan los objetivos comunes y, a continuación, se esfuerzan por mejorar personalmente y como equipo.
Este último punto, sobre el compromiso, es especialmente importante. Sólo cuando los individuos y los equipos se comprometen, se sienten responsables para entregar un alto valor, que es la línea de base para los equipos de desarrollo de software. Las metodologías ágiles facilitan el compromiso animando a los equipos a extraer una lista de trabajo clasificada por orden de prioridad, administrar su propio trabajo y centrarse en mejorar sus prácticas de trabajo. Esta práctica es la base de la organización del equipo por sí mismo, que es la fuerza motriz para lograr resultados en un equipo ágil.
Para crear equipos de alto rendimiento, las metodologías ágiles valoran a los individuos y las interacciones sobre los procesos y herramientas. Hablando prácticamente, todas las metodologías ágiles buscan aumentar la comunicación y colaboración a través de los ciclos de inspección y adaptación frecuentes. Sin embargo, estos ciclos solo funcionan cuando los coordinadores ágiles fomentan el conflicto positivo que se necesita para generar una base sólida de verdad, transparencia, confianza, respeto y compromiso en sus equipos ágiles.
Software que funciona sobre la documentación completa
El software que funciona es una de las grandes diferencias que aporta el desarrollo ágil. Todas las metodologías ágiles que se representan en el Manifiesto Ágil (Agile Manifesto) subrayan la entrega al cliente de partes pequeñas de software que funciona a intervalos fijos.
Todos los equipos ágiles deben establecer lo que significa que digan "software que funciona", conocido con frecuencia como la definición de terminado. En un nivel alto, una parte de la funcionalidad se ha completado solo cuando sus características pasan todas las pruebas y pueden ser utilizadas por un usuario final. Como mínimo, los equipos deben ir más allá del nivel de la prueba unitaria y probar en el nivel del sistema. Los mejores equipos también incluyen pruebas de integración, rendimiento y aceptación del cliente en su definición de lo que significa haber terminado una parte de la funcionalidad.
Una compañía de CMMI nivel 5 ha mostrado, a través de datos extensos en muchos proyectos, que definir las pruebas de aceptación junto con la característica, implementar las características consecutivamente y en orden de prioridad, realizar las pruebas de aceptación en cada característica inmediatamente y corregir cualquier error identificado como prioridad máxima duplicará la velocidad de producción sistemáticamente y reducirá los defectos en un 40 por ciento. Esto procede de una compañía que ya tiene una de las tasas de defectos más bajas del mundo.
El Manifiesto Ágil (Agile Manifesto) recomienda que los equipos entreguen el software que funciona a intervalos establecidos. Acordar una definición de "terminado" es una de las maneras prácticas en que los equipos ágiles dan lugar al alto rendimiento y alta calidad que se necesitan para lograr este objetivo.
Colaboración del cliente sobre la negociación del contrato
Durante las dos últimas décadas, las tasas de éxito de los proyectos han aumentado a más del doble en todo el mundo. Esto se atribuye a los proyectos menores y las entregas frecuentes, que permiten al cliente proporcionar comentarios sobre el software que funciona a intervalos regulares. Los redactores del manifiesto sabían de qué estaban hablando cuando enfatizaron que conseguir la implicación del cliente en el proceso de desarrollo de software es esencial para el éxito.
Las metodologías ágiles fomentan este valor ya que un representante del cliente trabaja mano a mano con el equipo de desarrollo. Por ejemplo, el primer equipo de Scrum tenía miles de clientes. Dado que no era factible implicarlos a todos en el desarrollo del producto, seleccionaron a un representante del cliente, llamado propietario del producto, para representar no solo a todos los clientes en el campo respectivo, también la a administración, ventas, soporte técnico, servicios al cliente y otras partes interesadas. El propietario del producto era responsable de actualizar la lista de requisitos cada cuatro semanas a medida que el equipo liberaba el software que funciona, teniendo en cuenta la realidad actual y los comentarios reales de los clientes y partes interesadas. Esto permitía al cliente ayudar a dar forma al software que estaban creando.
El primer equipo de XP comenzó con un proyecto de TI interno. Pudieron tener a un usuario final de la compañía en su equipo para que trabajara con ellos a diario. Las consultorías y los equipos internos pueden encontrar a un usuario final que trabaje con el equipo todos los días aproximadamente el 10 por ciento del tiempo. Para el otro 90 por ciento del tiempo, deben designar a un representante. Este representante del cliente, a quien los equipos de XP llaman "el cliente", trabaja con los usuarios finales para proporcionar una lista clara, clasificada por orden de prioridad de las características que los desarrolladores de software deben implementar.
Colaborar con el cliente (o el representante del cliente) todos los días es uno de los motivos clave por los que los datos del sector muestran que los proyectos ágiles tienen más del doble de éxito que los proyectos tradicionales por término medio en todo el mundo. Las metodologías ágiles reconocen esto y, por tanto, han creado en sus equipos de desarrollo un lugar que es específicamente para el representante del cliente.
Responder al cambio sobre seguir un plan
Responder al cambio es esencial para crear un producto que agrade el cliente y proporcione valor comercial. Los datos del sector muestran que más del 60 por ciento de los requisitos de producto o de proyecto cambian durante el desarrollo de software. Incluso cuando los proyectos tradicionales finalizan a tiempo, según el presupuesto y con todas las características del plan, los clientes se sienten a menudo insatisfechos porque lo que encuentran no es exactamente lo que deseaban. " La "Ley de Humphrey" dice que los clientes nunca saben lo que desean hasta que ven el software que funciona. Si los clientes no ven el software que funciona hasta el fin de un proyecto, es demasiado tarde para incorporar sus comentarios. Las metodologías ágiles buscan los comentarios del cliente a lo largo del proyecto para que puedan incorporar comentarios y nueva información a medida que se desarrolla el producto.
Todas las metodologías ágiles tienen procesos integrados para cambiar sus planes a intervalos regulares en función de los comentarios del cliente o su representante. Sus planes están diseñados para entregar siempre primero el mayor valor comercial. Dado que el 80 por ciento del valor representa el 20 por ciento de las características, los proyectos ágiles bien realizados tienden a finalizar temprano, mientras que la mayoría de los proyectos tradicionales finalizan tarde. Como resultado, los clientes están más satisfechos y los desarrolladores de software disfrutan más de su trabajo. Las metodologías ágiles están basadas en el conocimiento de que para tener éxito, se debe planear para cambiar. Por eso han establecido procesos, como revisiones y retrospectivas, diseñados específicamente para desplazar las prioridades con regularidad en función de los comentarios del cliente y el valor comercial.
El desarrollo ágil es un marco incluyente y las metodologías son implementaciones
El desarrollo ágil no es una metodología en sí mismo. Es un término incluyente que describe varias metodologías ágiles. En la firma del Manifiesto Ágil (Agile Manifesto) de 2001, estas metodologías incluían el Scrum, XP, Crystal, FDD y DSDM. Desde entonces, también han emergido las prácticas eficientes como una valiosa metodología ágil y, por tanto, se han incluido bajo el paraguas del desarrollo ágil en la ilustración que se encuentra más adelante en este tema.
Cada metodología ágil tiene un enfoque ligeramente diferente para implementar los valores básicos del Manifiesto Ágil (Agile Manifesto), exactamente igual que muchos lenguajes de computación manifiestan las características principales de la programación orientada a objetos de maneras diferentes. Una encuesta reciente muestra que aproximadamente un 50 por ciento de quienes usan metodologías ágiles dicen que su equipo está haciendo Scrum. Otro 20 por ciento dice que están haciendo Scrum con los componentes XP. Un 12 por ciento adicional dice que están haciendo XP exclusivamente. Dado que más del 80 por ciento de las implementaciones ágiles en todo el mundo es Scrum o XP, MSF for Agile Software Development v5.0 se centra en los procesos y prácticas básicos de Scrum y XP.
.png "Marco incluyente de desarrollo ágil")
Scrum es un marco de trabajo para los procesos de desarrollo ágiles. No incluye prácticas de ingeniería concretas. A la inversa, XP se centra en las prácticas de ingeniería, pero no incluye ningún marco de trabajo dominante de procesos de desarrollo. Esto no significa que Scrum no recomiende ciertas prácticas de ingeniería ni que XP no tenga ningún proceso. Por ejemplo, el primer Scrum implementó todas las prácticas de ingeniería que ahora se conocen como XP. Sin embargo, el marco de trabajo de Scrum para el desarrollo de software se diseñó para hacer que un equipo empezara en dos o tres días, mientras que las prácticas de ingeniería suelen tardar muchos meses en implementarse. Por consiguiente, queda la pregunta de cuándo (y si se deben) implementar practicas concretas para cada equipo. Los creadores de Scrum, Jeff Sutherland y Ken Schwaber, recomiendan que los equipos de Scrum empiecen inmediatamente y creen una lista de impedimentos y un plan de mejora del proceso. Como las prácticas de ingeniería se identifican como impedimentos, los equipos deben recurrir a las prácticas de XP como una manera de mejorar. Los mejores equipos ejecutan Scrum complementado con prácticas de XP. Scrum ayuda a XP a escalar y XP ayuda Scrum a funcionar bien.
La siguiente tabla muestra cómo se pueden intercambiar las condiciones clave en Scrum y XP.
Scrum |
XP |
|---|---|
propietario del producto |
cliente |
scrummaster |
Instructor de XP |
equipo |
equipo |
sprint |
iteración |
reunión de planeación de sprint |
juego de planeación |