Esta mañana me he levantado con el twitt de @recuenco:

Y no me he podido resistir a escribir esto que llevo pensando hace tiempo.

Hace tiempo que hemos pervertido la expresión «tener derecho» porqué hemos generalizado la expresión, y yo creo que hace falta decir que en algunos casos, lo siento, no tienes derecho en el sentido de que los demás te deben garantizar algunas cosas.

Y voy con los tres ejemplos que siempre se me vienen a la cabeza:

• Tienes derecho al paro, si te quedas sin trabajo, entre todos te ayudamos para que puedas salir adelante mientras encuentras un trabajo. Pero no tienes derecho a estar dos años sin trabajar, y ya si eso cuando se acabe el paro busco trabajo, porque eso es abusar de la solidaridad de la sociedad.
• Tienes derecho a jubilarte, si tus condiciones físicas o mentales no te permiten trabajar. La jubilación se «invento» para ayudar a los que no pueden trabajar. Pero no tienes derecho a que entre todos te garanticemos 30 años de vida sin trabajar, por mucho que hayas trabajado antes. Cada vez que veo a alguien prejubilado en perfectas condiciones de trabajar, y que está montando una empresa, o haciendo otro trabajo.
• Tienes derecho a un trabajo digno, pero no tienes derecho a que la sociedad te garantice un trabajo en las condiciones que tú quieras (horario, distancia al trabajo, salario, de que es el trabajo, etc.). He estudiado 3 masters sobre «inserta tu pasión favorita» no te da derecho a tener un trabajo de «inserta tu pasión favorita». Nunca he entendido eso de: «tengo derecho a tener un trabajo de lo mío«.

Empiezo por dar las gracias de nuevo al equipo que organizo el AOS en Bilbao. Esto no es ni mucho menos una crítica a ellos, sino a todos nosotros que aceptamos muchas veces cosas sin darles la relevancia que tienen.

Todo empieza porque se me ocurre leer el código de conducta del AOS que no tiene nada de especial, hasta donde yo se fue una copia del código de conducta de otras conferencias parecidas. Hasta aquí nada que reseñar.

Yo no pensaba hacer ninguna de las cosas que «prohíbe» el código, así que no me afecta demasiado. Cuando estoy en sociedad procuro ser respetuoso con todo el mundo. Pero la tolerancia tiene un limite como explica muy bien Enrique Dans en su artículo sobre la paradoja de la tolerancia.

Mi crítica hacia el código es que acepta como intolerables algunos comportamientos, en especial todo lo que tiene que ver con el género y el sexo, pero se deja otros que no tiene en cuenta. A título de ejemplo el código de conducta no prohíbe quemar billetes de 500 € mientras el ponente se jacta de la miseria de muchos.

O permite a los ponentes usar fotos de gatitos que como todo el mundo sabe para muchas personas son un claro ataque a su libertad sexual y les coloca en situaciones incomodas.

Es decir, como resultado de una cultura muy mojigata (creo que la norteamericana) hemos decidido que la forma correcta de tratar temas sexuales es la suya, y que por tanto cualquier otra manera de verlo queda fuera.

Al mismo tiempo otras cosas abiertamente inmorales, para mi y puede que para mas gente, no quedan relegadas porque en la cultura mayoritaria son aceptables.

En la última y desternillante sesión de mindfulless , donde hicimos una parodia de muchas de las modas ágiles de hoy en día, estoy seguro de que alguien se podría haber sentido ofendido, pues estábamos riéndonos de cosas que para algunos son importantes. Pero no tienen derecho a prohibirnos hacerlo por el hecho de que les moleste u ofenda.

Mi queja al respecto tiene que ver con el control que se impone de los «ofendiditos» y como poco a poco vamos cediendo espacios de libertad. No podemos poner el límite de la libertad de expresión en que no debemos molestar a alguien, porque siempre hay alguien que se sentirá ofendido por otro, y yo creo que el limite a la libertad de expresión no podemos ponerlo en cuanto ofende al que lo escucha.

Si en una charla o ponencia alguien usa o dice algo que te ofende, es bien fácil, te levantas y te vas, pero no permitamos que se restrinja la libertad de expresarnos.

No pienso usar fotos de lo que la mayoría considera contenido sexual en mis presentaciones, pero nadie nunca me impedirá usar fotos de gatitos.

En primer lugar quiero empezar dando las gracias al equipo que ha organizado el AOS, muchas gracias por todo vuestro trabajo. Vuestro esfuerzo ha hecho posible que otros pasáramos un gran día. Muchas gracias.

Cada vez me gustan mas los Open Space y menos las conferencias. En las conferencias me suelo quedar en los pasillos, aquí pasan cosas en los pasillos pero en general las “charlas” son los pasillos. He aprendido, conocido gente nueva, confirmado algunas percepciones y descartado otras, espero haber aportado mis dos centavos, y me he reído mucho haciendo que no hacía mindfullless, y encima me he descertificado holísticamente. Me quedo con la frase de que las “silent retros” son como la homeopatía.

Me llevo de este AOS:

• La confirmación de que hay mucho humo alrededor de ágil . Agil está de moda, y todo el mundo es ágil, pero me vuelvo con la confirmación de que mucho del humo tiene que ver con no adoptar los valores, sino sólo las prácticas. Y aunque las prácticas te pueden llevar a cambiar los valores, me temo que ese camino es difícil.
• Hay mucha gente explicando a los demás como tienen que ser ágiles, muchas de las conversaciones no tenían que ver con como ser “mas ágiles”, sino en cómo hacer que otros sean ágiles. He visto mucha gente empeñada en que los demás sean ágiles, pero yo ya, si eso, otro día.
• Hay un montón de gente peleando pro ser ágile en entornos muy difíciles, he conocido gente de Zara que está peleándolo o el equipo de la diputación de Álava. Enhorabuena luchan contra gigantes donde debe ser una batalla cada minuto.
• Quizás lo  que hace falta es mas VERDAD que dirían los taurinos. Yo creo que hace falta menos foco en las herramientas y los procesos, y mas en los valores.
• Me quedo con la tarea de buscar formas de hacerle hueco  a la VERDAD (no la mia, sino la taurina ) en el mercado. Creo que el riesgo de que el humo acabe ahogando los principios ágiles es real. Yo creo que muchas organizaciones van a fracasar por falta de verdad, y el mercado culpará a los valores.
• Hay muchas prácticas en muchas empresas interesantes.  Necesitamos mas espacios para compartir prácticas, no grandes transformaciones, si no cosas pequeñas a las que a veces no damos valor pero que pueden tenerlo para muchos.
• El manifiesto se ha hecho mayor, pero sigue sirviendo. Es para muchas organizaciones todavía inalcanzable,  pero para otras sigue siendo una guía para la mejora.
• Necesitamos encontrar la manera de incorporar a espacios como el AOS a mas gente que trabaja de manera ágil, y un poco menos de gente que te explica como tienes que trabajar para ser ágil. Está bien contar con expertos, formadores, coaches, etc. Pero yo creo hace falta mas gente de los equipos que lo practican día a día.
• Por último, esperaba oír algún mensaje del tipo lo que vosotros hacéis no es ágil, y con alegría he recibido mas la impresión de que a mucha gente le ha parecido que lo que hacemos es ágil aunque no contennos con todas las ceremonias o herramientas.  Creo que está bien entender que ágil no es rígido (vaya obviedad). Me vuelvo mas convencido de lo que vine de que lo importante son los valores y los principios.

Ah, y una cosa mas: Gracias mil al equipo. Os debemos la experiencia estupenda que ha sido el AOS 2019.

Últimamente ando enfrascado en conversaciones interesantes sobre desarrollo de software, empezamos con la discusión sobre metodologías y frameworks, luego hablamos de tests.

En esa conversación uno de los principios ágiles que fue mencionado es:

«Continuous attention to technical excellence 
and good design enhances agility.»

El problema surge sobre lo que es la excelencia, quizás sobre esto tenemos visiones distintas.

Yo creo que la excelencia no es una propiedad del software aislado del contexto. Me explico, un sistema con triple cifrado más doble autenticación más 4 códigos de verificación de las integridad que está lleno de tests, y bien documentado. Que también sigue los mejores patrones de diseño y que ha sido refactorizado varias veces…. Puede ser una excelente pieza de software salvo que todo eso no fuera necesario.

Es verdad que el manifiesto dice que la entrega de software que funciona es la principal guía para el avance. Pero eso tiene que aportar valor de negocio.

No basta, además con aportar valor, hay que aportar más valor de los que cuesta producirlo. Parece una obviedad pero yo creo que a mucha gente ser le olvida. Por no hablar de qué es más importante el valor percibido que el aportado (otro post).

En ese contexto el artículo que recomendó:

El otro día @jmbeas decía que si el software no tiene tests se puede decir que no fue construido ágilmente, y yo discrepo un poquito: https://t.co/1Iy80MRu2p

— Agustin Cuenca (@agustincnc) June 3, 2019

Es claro que hacer mal software tiene coste as largo plazo, y no voy a ser yo quien lleve las contraria al Sr. Fowler. Pero en ese mismo artículo está bien claro que al principio del proyecto es más caro hacer el software «cómo dios manda».

Y también está claro que eso al final se paga. Pero yo creo que la solución no es perseguir la excelencia técnica de las primera línea de código.

Yo creo que en un proyecto que arranca los tests al principio son un cierto desperdicio. El proyecto en las primeras fases tiene un enorme nivel de incertidumbre, y creo que la mejor manera de resolverlo es salir a probar en real lo antes posible (Siempre que el coste del error lo permita #otropost 😉 ), y una vez el mercado te ha dicho si el proyecto está bien o no, entonces es el momento de invertir en tests.

Es decir, yo creo que el problema no es si debemos hacer tests o no, el problema es cuando debemos hacerlo, y yo creo que se debe invertir en tests y mejorar la calidad de tu código una vez el proyecto tiene un cierto grado de estabilidad.

Es verdad que no hacerlo deteriora la “excelencia” de tu código, pero creo que la excelencia tiene que ver con el contexto. Y en muchos proyectos la “excelencia” técnica es un lujo que un equipo con pocos recursos no se puede permitir.

La clave está en no olvidar que la deuda técnica que adquieres (y no escribir tests ayuda a que la deuda técnica crezca) hay que pagarla.

Siempre me ha gustado la metáfora de la deuda técnica, se parece mucho a la deuda de una empresa.

Todos pensamos que endeudarse es un error, y que sería mejor no hacerlo, pero en cuanto sabes un poco de finanzas entiendes que el nivel de endeudamiento es una de las magnitudes mas relevantes que se deben gestionar, e igual con la deuda técnica, endeudarse por las razones equivocadas es un error, igual que lo es no recurrir a la deuda porque endeudarse es malo.

Yo creo que no está mal que un proyecto arranque generando deuda técnica, a veces no tienes dinero para no hacerlo. Y por lo tanto la deuda técnica hay que gestionarla y ser conscientes de que lo que estás haciendo te va a costar ( y puede que no te guste el tipo de interés).

El error es no tener en cuenta la deuda técnica, ignorar que el software que no persigue la excelencia es mas caro a largo plazo y pensar que da igual 8 que 80.

El otro día se me ocurrió preguntar:

Y @jmbeas dijo que:

De lo que se puede deducir que si no tiene test el software no fue construido ágilmente. Y yo no estoy de acuerdo, pero 140 dan para lo que dan, así que intentaré explicarme un poco mejor aquí.

No es discutible que ante dos bases de código iguales es mejor la que tiene tests que la que no lo tiene.

Tampoco es discutible que uno de los principios del manifiesto ágil es:

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

Por lo tanto si el software no tiene tests no ha sido construido ágil mente por que se aleja de la excelencia técnica.

El problema surge a la hora de definir excelencia técnica. Yo estudiaba de pequeño una definición de calidad que siempre me gusto: «Una aplicación de calidad es aquella que satisface los requisitos del cliente». No necesariamente la mejor aplicación desde el punto de vista del puro diseño es una aplicación de calidad.

Y IMHO a veces los requisitos del cliente exigen velocidad, y creo que nadie discutirá que en muchos contextos, en mi caso en todos los proyectos en los que he estado, escribir tests tiene coste, a veces solo en dinero, pero muchas veces también en tiempo.

También el manifiesto hace hincapié en «working software» y una aplicación llena de tests que no hace nada, es muchas cosas, pero no hay «working software».

En alguna de las primeras conferencias Rails, algunos defensores del TDD, famosos muchos de ellos, me decían que yo estaba en el siglo XIX por pensar así, pero luego cuando montaron su propio proyecto el TDD quedó para los clientes.

Yo creo que los tests tienen valor, pero no siempre el valor supera al coste. Y os puedo asegurar que es muy difícil convencer a un cliente de que pague por algo que, sin duda tiene valor, pero el cliente no percibe. En ASPgems insistimos en dotar a las aplicaciones de tests, pro en el momento adecuado, no desde el principio del proyecto.

En NeuroK tenemos una buena cobertura de tests de la aplicación, y procuramos cuidarla y mantenerla, pero el nivel de cobertura cambia con el tiempo, y en los primeros meses de vida de la aplicación el nivel de cobertura era muy bajo.

Como decía un amigo:

En teoría las cosas son iguales en la teoría y en la práctica, pero en la práctica NO.

Este fin de semana se me ocurrió escribir un twit  sin importancia:

Cada vez que alguien dice que SCRUM es una metodología ágil en la red muerte un gatito.

— Agustin Cuenca (@agustincnc) May 26, 2019

Y se lio un poco en twitter, así que debe ser que el tema tiene interés, ya demás llevaba tiempo rondándome la idea de escribir un poco sobre el tema.

El mundo del falso agile es algo que me preocupa, así que igual este es un buen punto de arranque para empezar a hablar del tema.

Mi amigo Javier me pregunto que cual era en mi opinión la diferencia. En primer lugar las palabras Metodología y Framework son lo que algunos llaman (gracias @lsmntr ) «significados flotantes», es decir, palabras a las que cada uno da un significado diferente.

Para mi, y esto es solo mi opinión, una metodología impone una serie de procesos, ceremonias, documentos, estándares, etc. Con un cierto nivel de rigidez. Las personas hemos creado metodologías con objeto de poder darle escalabilidad a los procesos y asegurar la calidad del resultado siempre y cuando se sigan los pasos marcados por la metodología. Por el contrario un framework es mas laxo, te da una serie de pautas, roles, artefactos, ceremonias etc que debes usar como guía. Seguro que esta definición no le vale a todo el mundo, pero creo que da una pista de lo que quiero decir.

IMHO no existen «metodologías ágiles». Para mi ágil tiene que ver con valores, y no estoy hablando de valores éticos (o igual si), si no de que prefieres cuando tienes que tomar una decisión.

El manifiesto ágil habla de valores y principio, yo no he leído nada de metodología.

Hay valor en que el software esté documentado, pero si tengo que elegir entre software que funciona y una buena documentación, yo me prefiero dedicar mi dinero al software y no a la documentación. De esto estoy hablando cuando hablo de valores.

Por muchas razones se ha puesto de moda el agilismo, (igual es que funciona), tal vez el hecho de vivir en un mundo donde es mas importante adaptarse al cambio que seguir un plan, donde la colaboración con el cliente prima sobre los contratos, o que las personas sean mas importantes que los procesos, el caso es que se ha puesto de moda.

Pero como siempre con la moda viene la simplificación, y en muchas organizaciones,libros, debates, tweets, etc., la simplificación ha hecho que se olviden los valores y nos centremos en aquello que es más fácil de medir, explicar y cambiar, que son los procesos, las ceremonias, las herramientas, etc.

Por eso decía lo de los gatitos, porque cuando se nos llena la boca de palabras y procesos que se han puesto de moda, lo que estamos haciendo es caminar hacia el fracaso porque nos hemos olvidado de los valores, y muchos que no tienen los valores que definen a un agilista, se han disfrazado de metodología. Y por eso surge el dolor, el fracaso y el humo.

Yo no voy a decidir quien es ágil y quien no, quien sigue o no una metodología, lo que si puedo ver son los valores de alguien. Porque los valores no se miden por lo que dices sino por lo que haces.

Es muy fácil hablar de metodologías, marcos de trabajo, roles, artefactos. El problema surge cuando tienes que decidir y entonces si te preocupa mas el contrato, o no te preocupas por las personas, o no buscas la mejora continua porque cuesta dinero, o no sigues los principios del manifiesto ágil entonces no me cuentes rollos. Te mola el discurso pero se te nota que no es lo tuyo.

Por cierto te lo dice un tipo ágil que pesa mas de 140Kg  ;-).

https://youtu.be/_Oq6C_XZ8t4