Y con este ultimo post de los otros dos (primera parte y segunda parte), damos por concluido el repaso a los principios del manifiesto agile casi 20 años después de su postulación.

Al final de este post están las conclusiones con detalle, pero lo puedo resumir en:

El manifiesto ágil , sus 4 pilares principales y sus 12 principios sentaron las bases del software moderno, fueron los principios de como se desarrolla hoy en día, 20 años después siguen quedando retos por superar pero es innegable la gran aportación que se realizo a la ingeniería del software.

 

9. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.

Por si quedaba alguna duda respecto a las ecuaciones «rapidez & cambios constantes & chapuza» y similares ideas, en este punto se deja bien claro, la agilidad no esta reñida, todo lo contrario, con la excelencia técnica, de hecho en este punto se hace referencia justo a eso, a que se debe tener el foco en un buen diseño de software y en técnicamente tener un código excelente (y todo lo que no es código; como la integración continua, las pruebas funcionales, infraestructuras, despliegues, automatización, etcétera).

A día de hoy nadie tiene dudas de que una buena arquitectura, basada en unos principios racionales y adaptados al producto, lo que se espera de el, su ciclo de vida, etcétera son básicos para tener un producto que entregue valor y que obviamente lo haga de manera eficiente y rápida. sobre las complejidades excesivas, del perfeccionamiento o la pobreza de código hablamos después en otro punto.

Además, sin cosas tan básicas como unos estándares a la hora de escribir código (indentación, nomenclaturas, etcétera) un modelo natural y lógico de objetos, una organización de dicho código, y tests, tests, y más test (unitarios, funcionales, integración o de sistema pero haz tests), sin calidad en todo esto difícilmente lograremos los objetivos básicos como es entregar valor, adaptarnos a los cambios, realizar incrementos, entregas frecuentes, reducir deuda técnica, etcétera.

Por no hablar de incorporar nuevas funcionalidades, o corregir las existentes. Es mucho más rápido y sencillo hacerlo si tenemos la «capa técnica» bien desarrollada.

Un código «espagueti» sin tests, sin cobertura, desorganizado, sin estándares, etcétera es una fuente de retrabajo y de desperdicio de esfuerzo y tiempo, especialmente si tenemos que cambiar cualquier cosa, esto es una perogrullada hoy en día y es de sobra conocido, pero de verdad que hace 20 años, si estaba claro, pero se quedaba muchas veces «en la teoría de los técnicos» y no se veía el propio valor, y ojo que hablo de jefes de proyecto y similares y no se ponía en marcha nunca nada relacionado con la calidad y mucho menos con la excelencia técnica.

 

10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.

Básicamente habla de sencillez en su sentido más amplio, de hacer las cosas lo menos complicadas posibles, pero en varios ámbitos, por un lado lo que es la parte visible (más a nivel de experiencia de usuario) en el software y por otra en los procesos intrínsecos al desarrollo, por ejemplo tomar requisitos, crear modelos de trabajo, analizar, testear, desplegar, etcétera.

Aquí me gustaría resaltar un concepto muy sufrido por las primeras puestas en marcha de, por ejemplo SCRUM, que es reducir al máximo los backlogs interminables que por otra parte contienen funcionalidades que no se llegan a implementar nunca.

Esto esta muy ligado al principio lean de desperdicio y retrasar la toma de decisiones todo lo posible, dado que tiene una profunda relación con tener a el cliente siempre presente, participando y colaborando para no dar por supuestas las cosas (como aspectos funcionales y expectativas del mismo respecto un modus operandi y situaciones similares).

La idea es que el equipo se pueda centrar en lo fundamental e imprescindible, esto facilita enormemente las entregas de manera iterativas y frecuentes y ya se sabe que eso es una gran ventaja competitiva a la hora de hacer software.

Por otro lado, aún se sigue teniendo el problema de las priorizaciones de backlogs, de los MVP que necesitan medio año para ser usables, de los sprint «zero» que al final son 3 meses de sprint y lo único que se tiene es un framework instalado y poco más, de los spikes que acaban siendo análisis, etcétera, etcétera.

Aun así, este principio calo muy hondo en la comunidad de desarrollo y hoy en día el problema se ha ido transformado en otros, que si bien pueden tener similitudes ya no son aquellos volúmenes enteros de documentos, código y miles de horas y esfuerzos que no servían para nada incluso mucho antes de que el software viera la luz.

 

11. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.

Aunque esta afirmación ha traído mucha polémica, en mi opinion por la falta de separación de dos conceptos: auto-organizados no es lo mismo que auto-gestionados y aquí es donde han saltado, saltan y muy probablemente saltaran, chispas entre product owners, desarrolladores, scrum masters y en general los miembros de los equipos.

Un equipo auto organizado debe tener unos soft skills que no siempre son fáciles ni de poseer ni de trabajar, y además se deben dar en todo el equipo, esto es muy complicado de conseguir especialmente si no se tienen los objetivos muy, pero muy claros.

Si, el objetivo es aportar valor, pero claro hay muchas interpretaciones de que es aportar valor, por eso lo lógico es que el valor lo definan los usuarios del software y/o el cliente.

Otro problema que existía con este punto eran las jerarquías, al final el modelo de «liderazgo» de la vieja escuela era un orden y mando, y claro esto no es que fuera muy eficiente dado que es imposible que una sola persona (y sobre todo en otra especialidad) tenga más conocimiento que un grupo, especialmente cuando un producto de software cubre areas funcionales tan complejas y extensas como viendo siendo habitual.

Sobre las arquitecturas, requisitos y diseños, para mi es super sencillo, si nos basamos en que el software es incremental, que va a cambiar si o si, que se entrega en los periodos más cortos posibles, que es evaluado por como perciben valor los clientes, etcétera partir de un arquitectura y un diseño inamovible es un error de libro.

De hecho estos aspectos deben partir de un modelo si, pero de un modelo lógico y con sentido común, con capacidad de adaptabilidad, que muy probablemente cambie de manera radical conforme el paso del tiempo y se den los incrementos necesarios.

Si mantenemos calidad y  excelencia en nuestro código, el movernos con arquitecturas emergentes no debe ser ningún problema, todo lo contrario, nos aportan flexibilidad y rapidez para asumir los cambios que seguro tendremos a lo largo del ciclo de vida del producto.

 

12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

Al final, muchas veces esta frase se ha interpretado como una «simple» retrospectiva, pero hay bastante más dentro del significado de estas palabras.

Es toda una declaración de intenciones sobre la filosofía de mejora continua desde el punto de vista de entregas frecuentes, software acabado, usable por el cliente, con la menor deuda técnica posible, cumpliendo con estándares, etcétera, etcétera, no únicamente sobre reflexionar que hicimos bien, mal, como cambiarlo, etcétera.

Este concepto, el de mejora continua no es nada nuevo, y apareció mucho antes del manifiesto, bajo mi punto de vista la principal diferencia vino dada por el uso de una forma de trabajar que no se centraba tanto en métricas, diagramas, indicadores, encuestas, y demás artefactos, sino por ese concepto de valor, de trabajo en equipo, de comunicación verbal, de diluir jerarquías, que proponer ideas y que se ha ido transformando de un modelo basado en excels, gantts, indicadores varios y métricas dispares a una filosofía que se puede ver muy fácilmente en el concepto de retrospectiva o de sprint review de SCRUM entre otros, vamos que lo importante en la mejora continua son las personas.

Sobre todo el planteamiento de que todo el equipo (no un jefe/a en un despacho, a solas mirando informes de rendimiento), a intervalos de tiempo regulares (no tiene porque ser como SCRUM lo plantea final de un sprint, abramos la mente) , reflexiona (no necesariamente mira métricas y gráficos, que también ayudan, pero se enfoca en reflexionar no en esto ultimo) para buscar la efectividad (efectividad desde el punto de vista del valor aportado, de los incrementos, de la vision de los usuarios y clientes) y perfeccionamiento (código, técnica, requisitos, desarrollo, valor) en consecuencia (como lo percibe el cliente, como lo viven los usuarios del software, no según un porcentaje o similares).

 

Conclusiones

A nadie se le escapa que todo esto «huele a scrum»  😉 y de hecho no solo a scrum. Muchas de las buenas prácticas «beben» de estos principios, aunque en algunos casos es justo al revés, estos principios beben de otras fuentes (así, de repente se me viene a la cabeza Lean manufacturing, XP y CRYSTAL  entre otros).

Pero SCRUM no es otra cosa que un marco de trabajo, bajo ciertos principios, si, pero un marco de trabajo, y como cualquier marco de trabajo no siempre te puede funcionar y se debe estar abierto a modificarlo, se que no es muy popular este modelo de «crear» formas e trabajo, pero precisamente una de las cosas básicas de los modelos agile es la flexibilidad y capacidad de adaptarse a lo que existe, de aceptar los cambios como algo positivo y enriquecedor y olvidarse de aquellos sistemas tan waterfall y que hoy en día están tan desfasados.

Para mi una cosa que es muy importante en todo esto, es la capacidad que tuvieron de sintetizar la problemática que tenía el software (ahora tenemos otras) de una manera que nadie se sintiera atacado, de una manera participativa e inclusiva para todos los participantes, y cuidando la calidad en las relaciones humanas sin perder en ningún momento el foco en lo importante que debe aportar el software: el incremento constante de valor hacia los usuarios finales del mismo.

Realmente ahora nos parecen unos principios muy básicos, sencillos, de sentido común, pero  hace 20 años no los eran, y recuerdo muchas conversaciones sobre el agilísimo con personas, empresas y demás que ahora lo defienden a «capa y espada» y antes incluso hacían bromas o directamente pensaban que eso era «cosa de hippies» -> literal.

Al final, lo importante es tener claro que estos principios han contribuido muchísimo a que el software actual sea como es hoy en día, a que la gente vea normal  el que se disponga de actualizaciones de una manera muy periódica (integración continua, iteraciones, ciclos cortos de desarrollo, entregas frecuentes…) a que tengamos muchos softwares «que hacen lo mismo», a que ya no tengamos enormes libros (o documentos de word) para entender que ha cambiado en una versión o como usar un software concreto, a que los pantallazos no sean habituales, a que los usuarios no necesiten «expertos», etcétera, etcétera.

En mi opinion, si hoy tenemos ciertos modelos de desarrollo y de productos, con una industria, profesionales y ese «todo» que forma uno de los ecosistemas tan inmensos en nuestros días como es el software actual, es en parte gracias a estos 12 principios, que insisto no reinventaron la rueda, solo fueron capaces de sintetizar el sentido común y ser una palanca para impulsar una forma de hacer software que efectivamente cambio para siempre la disciplina y la historia de la ingeniería del software.

Aquí se encuentran la primera parte y la segunda parte del esta entrada

Etiquetas:

4 comentarios en «Los doce del manifiesto – parte III de III»

  1. Me quedo con esta frase XD

    «auto-organizados no es lo mismo que auto-gestionados y aquí es donde han saltado, saltan y muy probablemente saltaran, chispas entre product owners, desarrolladores, scrum masters y en general los miembros de los equipos.»

    Toda la razón.

    Saludos

Deja una respuesta

Tu dirección de correo electrónico no será publicada.