Ediciones ENI Editorial | líder en informática
El espíritu ágil
Introducción
Ahora que hemos cubierto el marco de Scrum, tenemos que ver la parte más difícil: adquirir el espíritu ágil.
Si alguien le explica las reglas del juego para jugar a fútbol, no le costará entenderlas, pero eso no significa que vaya a ser un excelente jugador. Probablemente necesitará años de práctica para llegar a ser muy bueno. Con Scrum, es incluso peor. Sus reglas son muy sencillas de entender, pero puede pasarse años practicando sin adquirir el arte de liderar proyectos ágiles. ¿Y eso por qué? Porque para sobresalir en Scrum o en cualquier otra metodología ágil, la excelencia no se obtiene con años de práctica, sino con el espíritu en el que se quiere practicar.
Quien habla de espíritu, habla de personalidad. Sabemos lo difícil que es para cada uno de nosotros cuestionarse y cambiar nuestros hábitos. La agilidad pondrá a prueba los hábitos de trabajo. Si usted descuida sus valores, sus normas de conducta y su forma de pensar, no tendrá el espíritu ágil para formar parte de un equipo ágil.
Aquí tiene una definición de lo que es la agilidad:
"La agilidad es la capacidad de una organización para proporcionar, de manera temprana y frecuente, servicios de calidad que impacten a los usuarios, mientras se adapta a tiempo a los cambios que puedan surgir...
El Manifiesto
1. Prioridad a la satisfacción del cliente
Este es el principio más importante de todos. Se hace todo lo posible para conseguirlo, en particular ofreciendo a los clientes funcionalidades de alto valor añadido con rapidez y regularidad.
2. Aceptar el cambio
Esto no significa que tengamos que ponerlo todo patas arriba a la menor petición. Sin embargo, aceptamos que los cambios son posibles y nos corresponde rectificar sin estrés. También conviene detectar los errores a tiempo para corregirlos lo antes posible.
3. Entregar frecuentemente versiones operativas del producto
No tiene elección, debe adoptar los sprints y desterrar los diagramas de Gantt.
Cada sprint debe culminar con una o varias entregas de funcionalidades desarrolladas y probadas.
4. Garantizar la máxima cooperación entre los desarrolladores y los responsables del negocio
El equipo, las partes interesadas y el cliente tienen que escucharse, hablar y trabajar juntos. ¡Háblense! ¡Háblense! Intercambien, hablen, preguntan... Hablen, hablen y hablen siempre sin límites. Háblense unos a otros con el máximo respeto.
5. Construir proyectos en torno a individuos motivados
Enviar de repente miembros de un equipo a otro puede romper la motivación. El espíritu de equipo es esencial. Proporcione al equipo todo el apoyo que necesite y confíe en él para alcanzar los objetivos fijados. Sobre todo, destierre la mentalidad de jefe; el equipo dará lo mejor de sí mismo si se autogestiona y se sumerge en las alegrías de la autonomía....
Los cuatro valores
En la práctica de la agilidad, reconocemos los valores de la derecha, pero damos prioridad a los de la izquierda:
1. Preferencia por los individuos y sus interacciones
Hay que hacer todo lo posible por simplificar los procesos y las herramientas para favorecer la comunicación directa entre las personas. Los procesos suelen ser engorrosos y esta pesadez administrativa es incompatible con el espíritu de adaptación al cambio que exige la agilidad. Si el proceso o las herramientas dirigen el desarrollo, dependeremos demasiado de ellos y el equipo será menos receptivo al cambio y tendrá menos probabilidades de satisfacer las necesidades del cliente. Una vez conocí un proceso en un banco que nos impedía empezar un nuevo proyecto hasta que hubiéramos recibido un número de proyecto creado por un sistema totalmente anticuado. Al cabo de quince días, seguíamos sin tener ese número y el trabajo atrasado se acumulaba. No tengo palabras para describir la frustración. La comunicación es un ejemplo perfecto de la diferencia entre la preferencia de los individuos y la de los procesos. Pongámonos de acuerdo en un número y empecemos el proyecto. La comunicación es una poderosa herramienta para tener una gran capacidad de respuesta.
Lo mismo se aplica a las herramientas. No es aceptable no poder avanzar correctamente porque una herramienta es demasiado compleja, demasiado inestable: pasar una hora depurando la herramienta de versionado de código cuando esa hora se podría haber dedicado a codificar no es rentable. El hecho de que no se haya alcanzado el objetivo del sprint porque se ha perdido el 30 % del tiempo en hacer estable la herramienta, tampoco es aceptable. Hay que hablar, hablar y hablar todavía más. Es esta comunicación cara a cara la que realmente nos permitirá avanzar; si una herramienta realmente nos molesta, se debe cambiar. Hoy en día tenemos mucho donde elegir, con muchas herramientas disponibles en el mercado. Una herramienta como Klaxoon es más que suficiente para construir una hoja de ruta, hacer Story Mapping, alimentar un backlog, los planes de release o los sprints. Cuanto más sencilla sea la herramienta y más visual sea para todos, más tiempo podrán dedicar los miembros del equipo a debatir entre ellos sobre...
El marco Scrum
Un proceso define una forma de trabajar, mientras que un marco de proceso simplemente define los límites. El marco de Scrum es ligero, impone muy poco:
-
un equipo con tres roles principales;
-
una Backlog que incluye el trabajo pendiente;
-
los sprints y sus ceremonias.
Con tan poco, hemos visto que se puede hacer cosas muy grandes. En Scrum, aplicamos sistemáticamente:
1- La transparencia
2- La inspección
3- La adaptación
En los campos complejos, no es posible prever lo que se obtendrá realmente al final: los pliegos de condiciones detallados y los planes detallados elaborados con antelación son, por tanto, inadecuados.
El enfoque empírico de Scrum se basa en ciclos cortos, los famosos sprints, y en retroalimentaciones frecuentes para avanzar hacia una solución desconocida al principio.
El empirismo en Scrum se denomina "inspección y adaptación".
He aquí los verdaderos cambios que aporta Scrum en comparación con los métodos antiguos:
inspección y adaptación mediante sprints nos centramos en las funciones que aportan valor ya no hay un jefe que diga qué hacer gestión visual y debate cara a cara¿La ventaja de todo esto? Una buena comprensión mutua de la solución a implementar para satisfacer al cliente que verá cómo...