Clean Agile

Vamos con el libro "Clean Agile, Vuelta a las raíces", de Robert C. Martin, conocido en el mundillo como "Uncle Bob". Narra sus opiniones particulares sobre Agile, cómo ha degenerado y cómo se puede recuperar. Sin duda, un libro muy recomendable para aquellos que se estén iniciando en Agile o para los que quieran recuperar la esencia de Agile. Realmente a mi me ha gustado mucho, e incluso ahora, preparando el resumen y releyéndolo, me sigue pareciendo una gran cantidad de verdades útiles a las que sacar mucho provecho y reconducir las situaciones que estamos viviendo actualmente con Agile y las supuestas transformaciones Agile.

También muy recomendable su libro de Clean Code, del que ya hablé. 

Casi cuando se inicia el desarrollo de software en los 50 todo funcionaba, equipos pequeños haciendo cosas pequeñas vieron que funcionaba mejor. Pero degenera en los 70 cuando se cambia la mentalidad de hacer grandes cosas con grandes equipos. Pero podemos hacer grandes cosas con la colaboración de muchos equipos pequeños haciendo muchas cosas pequeñas. En 2001 surge el manifiesto ágil, que quiere volver a recordar los años 50. Ahora Agile se ha malentendido o mal usado y este libro es para retomar conciencia del 2001 y los 50

Capítulo 1. Introducción a Agile 

En 2001 nace el manifiesto ágil, al reunirse 17 profesionales del desarrollo de software para hablar de la mala situación que pasaba y cómo poder mejorarla. Combinaron las mejores ideas de los marcos de trabajo existentes (muchos creados por ellos mismos) para unificarlos en el manifiesto. Lo asombroso aquí es como 17 mentes distintas colaboraron y llegaron a un acuerdo. 

En waterfall damos estimaciones de las distintas fases casi a ojo (si dices lo contrario enséñanos cómo). En cada fase preparamos la siguiente fase, y la solemos finalizar según la estimación inicial, cuando no se nos complica nada. El análisis es una fase feliz, de reuniones y pensamientos. En la fase de diseño creamos el plan para la implementación. Durante este tiempo surgen nuevos requisitos, cambian algunos o se eliminan otros, y ese reanálisis se camufla durante esta fase claro. Entramos en la fase de implementación, donde obtendremos el producto final. Ya ha pasado mucho tiempo invertido en las pasadas fases, pero nuevos requisitos siguen apareciendo, cambios sobre los existentes u otros que sobran, lo que nos obliga a reanalizar y rediseñar. Vamos tarde ya, nos damos cuenta de que no llegaremos a la fecha del hito, y se lo contamos a los stakeholders muy próxima a esa fecha, demasiado tarde se enteran, ¿no?. Entramos después en la fase de enfados, horas extra, desmotivaciones, etc. 

Waterfall funciona muchas veces, pero presenta estos problemas. Hay otras que funcionan mejor. Hacer planes más pequeños. 

Al autor no le gusta usar sprint, porque parece que hay que hacerlo lo más rápido posible. Define al proyecto como una maratón. Prefiere también iteraciones de una semana porque en 2 puede ir muchas cosas mal, otros prefieren 2 porque piensan que en 1 no lograrán tener lo suficiente hecho. 

Muchos piensan que Agile es entregar más rápido. No, es sobre conocimiento o valor lo más pronto posible. La única manera de ir rápido es ir bien. 

Agile es un proceso (disciplina) por el que el proyecto se divide en iteraciones. La salida de cada una es medida y se usa constantemente para evaluar la planificación (fecha). Los requisitos son implementados en el orden que aporten más valor a los stakeholders. La calidad siempre se mantiene alta. La planificación es gestionada principalmente cambiando y adaptando el alcance. 

Capítulo 2: las razones de Agile 

Con Agile, al final de cada iteración el sistema debe ser técnicamente desplegable, por lo que el despliegue es una decisión de negocio, no una decisión técnica. 

Las prácticas ágiles incluyen testing, pares, refactorización y diseño simple, para reducir deuda técnica y no meter nueva. Todo esto debe ser llevado a cabo en las iteraciones conforme se van sacando nuevos ítems con valor. 

El software significa producto fácil de cambiar. Si un cambio sobre un requisito rompe con lo que tienes, es probable que lo que tengas no esté bien diseñado o estructurado. Las anteriores técnicas nos ayudarán a realizar cambios seguros con el mínimo esfuerzo. 

La mejora continua es fundamental, tenemos que hacer código cada vez mejor. Una primera mejora de código es mantenerlo limpio (ver Clean Code).

QA no debería encontrar fallos. Si los encuentra, los desarrolladores deberían revisar su procedimiento para ver por qué se ha fallado. La automatización de test es fundamental, el test manual es caro y siempre acaba perdiéndose o no ejecutándose completamente. 

TDD es una buena técnica de diseño para hacer código de calidad. 

Necesitamos decir que No, cuando la respuesta es realmente No, da igual la presión de tiempo, da igual cuántos managers estén demandando resultados. 

Aprendizaje continuo, aprende, aprende, aprende... nuestra industria cambia muy rápido y tenemos que cambiar con ella. Y además, enseña, aprende a enseñar. 

Estimar es adivinar. Son conjeturas inteligentes para estar seguros, pero siguen siendo conjeturas. Mejoran con el tiempo. Las estimaciones nunca son compromisos. Es fácil que tengan que ser modificadas por aparecer nuevos factores que influyen.

Capítulo 3: Prácticas de negocio 

Planning, pequeñas entregas, pruebas de aceptación y Equipo Completo.

Cuando creas una historia de usuario, algo que aporta valor a un usuario, nuevas características al producto, no debe tener demasiado detalle. Esto es debido a que cuando se inicien, van a ser modificadas, divididas, unidas o incluso descartadas. Lo otro, es perder el tiempo. Ahora bien, cuando esté claro, puedes dar detalle de la conversación para que quede anotado. Recuerda que una HU son contenedores de que hay algo que hacer para un usuario, pero no son requisitos. Las HU cumplen INVEST: Independiente, Negociable, Valiosa, Estimable, Pequeña (Small), Testeable. Podemos estimar las HU con el Planning Póker y Fibonacci, tallas de ropa, etc. Las Hu se pueden unificar, si hay más de una con peso 0, se pueden dividir, manteniendo el invest. Podemos tener Spikes, una historia para estimar una historia. Un Spike es algo con una incertidumbre muy elevada porque nunca lo hemos hecho o no sabemos cómo abordarlo. 

Usamos la velocidad para intentar saber lo que nos cabe en una iteración. Pero no es un compromiso, es una ayuda que tiene el equipo para intentar predecir lo que podría hacer. El equipo decide si va más o menos según se sienta cómodo. 

Forma rápida de determinar el ROI (Return of Investment):

                         Alto Coste            Bajo coste

Alto Valor      hacer más tarde       hacer ahora

Bajo Valor     nunca se hará          hacer mucho más tarde

En cada iteración nos tenemos que focalizar en tener tareas hechas y completas, foco en cerrar antes que abrir. Al final de la misma, es mejor tener el 80% de las tareas completadas que todas las tareas al 80%.

Los criterios de aceptación deben ser especificados por negocio, en un lenguaje entendible e independiente de la programación, usando por ejemplo BDD (Behavior Driven Development. TDD es más técnico), usando la plantilla: Given, When, Then. 

Los test de aceptación son llevados a cabo por negocio, incluyendo el Happy path. QA escribirá el Unhappy path. 

Involucra a QA ya al inicio de la iteración, no esperes al final porque puede ser cuello de botella y retrasarse todo. Debe empezar cuanto antes. La responsabilidad de que los test pasen ok sobre el código es de los desarrolladores exclusivamente. 

Equipos ubicados en la misma localización trabajan mejor, desde luego, pero los tiempos evolucionan y nos tenemos que adaptar a lo remoto. 

Capítulo 4: Prácticas de equipo 

Tener un vocabulario de equipo común es fundamental, siendo equipo todo el mundo incluidos desarrolladores, QAs, stakeholders, etc, todos los que participan. 

Todos necesitamos un tiempo de desconexión y un ritmo sostenible de trabajo. No tener sobreesfuerzos permanentes es muy importante, si existen, deberían ser muy puntuales y hacia el final de la entrega. Cometemos más errores durante esos sobreesfuerzos. 

Todo pertenece al equipo, no hay individualismos. Todos pueden tocar o mejorar cualquier cosa. Esto ayuda a distribuir el conocimiento entre el equipo. 

Integración continúa, sube código muy a menudo, que funcione, que pase las pruebas, que no rompa nada.

Las dailys, son sincronizaciones del equipo, y ya, no más.

Capítulo 5: Prácticas técnicas 

TDD, consiste en codificar primero los test unitarios, hacer que fallen, después codificar el código necesario para hacer que funcione el test, y así sucesivamente hasta completar el caso de uso, desde lo más simple hasta tenerlo todo listo. No es una técnica de test, es una técnica de diseño. 

Refactorización es la práctica por la que mejoramos la estructura del código sin modificar el comportamiento y sin romper los test. 

Diseño simple es la técnica por la que debemos hacer el mínimo código posible para que funcione algo, sin meter complejidades innecesarias.

Pair programming es la técnica por la que dos personas están trabajando sobre lo mismo, a la vez, compartiendo la pantalla, ratón y teclado, o compartiendo pantalla en caso de estar en remoto. Es opcional, intermitente y las personas del equipo deciden cuándo aplica. El objetivo es expandir e intercambiar conocimiento. Pueden ser más de 2, nuevamente según criterio del equipo. No temas proponerlo, un buen responsable no te dirá que no. 

Capítulo 6: Llegando a ser Agile 

Quizás lo más efectivo no sea la transformación, sino la creación de nuevas divisiones que funcionen usando Agile para sus desarrollos de software.  

No podemos tener a la gente llamándolos con nuevos roles haciendo lo mismo que antes: agile Coach, Scrum Másters, etc actuando como los Project Managers de siempre. 

Las certificaciones de hoy en día son una broma. No te las tomes en serio porque no significarán nada, lo único que garantiza es que esa persona pagó por hacer el examen y probablemente por un curso de 1 o 2 días.  Pero los trainings no dejan de ser importantes para lograr una base a partir de la que crecer, y lo más importante, no centrarlo en una sola persona, todo el equipo debería ser formado en agile. La verdadera certificación es la práctica y la experiencia real con equipos y que de verdad apliques bien la agilidad, con una buena supervisión y mejora. 

No escales Agile con grandes equipos. Agile está pensado para equipos pequeños de desarrollo de software, no para grandes equipos y grandes problemas. 

Las herramientas nos hacen el trabajo mucho más sencillo, por lo general. Lo importante es que controlemos las herramientas, no que estas nos controlen. Tenemos que usar las herramientas apropiadas a nuestro flujo de trabajo.

El papel del Agile Coach a nivel de  individuos es ayudarlos a resolver problemas por ellos mismos. A nivel de equipos y organizaciones, es ayudarlas a conseguir sus objetivos por sí mismos. 

Capítulo 7: Artesanía (Craftsmanship)

Las ideas de Agile fueron distorsionadas y simplificadas, llegando a empresas como la promesa de un proceso de entrega de software más rápido. Todos aquellos acostumbrados al cascada o RUP lo querían. ¿Quién no querría ser agile con esa promesa?

Las transformaciones Agile que se centren puramente en el proceso son transformaciones parciales. Nadie estará ayudando a los desarrolladores a aprender las prácticas técnicas e ingeniería de Agile. 

No todas tienen problemas, al menos en el mismo grado. Aún así, a pesar de ello, aprovechan los beneficios de esa transformación. 

Muchos Agile Coach modernos no tiene suficientes conocimientos técnicos, si es que tienen algunos,  con lo que algunos desarrolladores comienzan a verlos como otra capa más de gestión: gente diciéndoles qué hacer en lugar de ayudarlos a ser mejores en lo que hacen. 

"¿Los desarrolladores se están alejando de Agile, o es Agile quien se aleja de los desarrolladores?" Ambos probablemente. En muchas organizaciones Agile es sinónimo de Scrum, olvidándose del resto. 

Un Agile centrado solo en el proceso no.es suficiente, es importante trabajar la parte técnica.

El principal objetivo de Agile es proveer agilidad de negocio y satisfacción de usuario, y esto se consigue con colaboración cercana, desarrollo iterativo, espacios cortos de feedback cada cierto tiempo y excelencia técnica. 

Todas las metodologías o marcos agile están bien para empezar. Pero conforme un equipo se hace maduro, deberá ir dejando de usarlos (o no) para encontrar su mejor forma de entregar valor. Si ponemos mucho foco en la metodología, marco o conjunto de prácticas distraemos a los equipos y organizaciones de sus verdaderos objetivos. El objetivo es ser Agile, no usar algo determinado. 

La Comunidad  International Software Craftsmanship considera a XP como el mejor conjunto de prácticas de desarrollo Agile que existen actualmente. 

Un error habitual en Agile es promover prácticas en lugar de ver el posible valor que ellas proveen. Estamos ofreciendo soluciones antes de saber cuál es el problema real. 

Cada práctica tiene sus intervinientes. Negocio y desarrolladores deberían tener conversaciones sobre valor de negocio, no sobre prácticas técnicas.  

Capítulo 8: Conclusión 

Escribe el libro para recordar lo que era Agile y lo que aún debería ser. Volver a las raíces, entenderlas bien, entender sus objetivos y aplicarlos.