El parasitron Agile. Principios 11 y 12. Conclusión.

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

Con esto podemos estar de acuerdo o no, pero nuestro parasitrón agile entiende una de esta dos cosas:

1. Parasitrón agile manager. Auto significa YO así que, yo los organizo. Pero como no tengo conocimiento lo hago de forma colaborativa, les pregunto “¿Tú como lo harías?” Si lo entiendo entonces se hace y si no lo entiendo, es que nadie lo entiende, que para eso soy manager y llevo 15 años trabajando, así me lo enseñaron a mí.

2. Parasitrón agile No manager. Auto significa OTRO así que ya lo hará otro. Lo mejor de ser un parasitrón es que siempre tienes razón por lo cual puedes evaluar el trabajo de los demás pero eso significa que ellos pueden evaluar el suyo. Solución: jamás realizar trabajo, solo opinar. En las opiniones no hay posibilidad de error, son opiniones.

Esto se produce por una paradoja que ya señaló Issac Asimov: “El aspecto más triste de la vida actual es que la ciencia gana en conocimiento más rápidamente que la sociedad en sabiduría”. En el mundo de la tecnología esta paradoja es absolutamente radical, la forma de desarrollar, de crear aplicaciones, de usarlas o simplemente de analizar información ha cambiado tanto que cuando escucho frases que contienen las palabras “siempre”, “normal” o "típico" sé que estoy delante de un parasitrón.

No hay nada típico en el desarrollo actual de aplicaciones. Cuando diseñábamos arquitecturas hace solo 5 años intentábamos evitar los errores. Ahora diseñamos para el caos, solo somos capaces de tener control sobre una parte ínfima de los elementos que intervienen en nuestras aplicaciones. Pensemos por un momento en una aplicación web, en cuantos dispositivos distintos creados por distintos fabricantes y con distintas formas de interactuar van a acceder a ella, desde cuantas conexiones distintas, con cuantos tamaños de pantalla en horizontal o en vertical; no tenemos ningún control sobre ello por lo cual debemos pensar en detectar los errores y corregirlos lo antes posible porque jamás podremos hacer pruebas para todos los dispositivos del mundo. O sea debemos sobrevivir en el caos.

Pero esto es inaceptable para un Parasitrón. Los parasitrones lo tienen todo controlado. Ellos son líderes natos que no cometen errores, son perfectos aunque lo nieguen constantemente. Dicen que asumen los errores pero no son capaces de reconocerlos, los disfrazan y ocultan en una huida hacia delante. No, no son malas personas, simplemente no saben hacerlo de otra manera, simplemente carecen del conocimiento para hacer el trabajo que desempeñan y esto es muy duro de aceptar.

Principio 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. Este principio está íntimamente relacionado con el análisis anterior, dedicar tiempo a la autocrítica pensado que la perfección es un proceso y no un estado.

En este punto quiero realizar una pequeña reivindicación, desde hace unas semanas sigo el canal de Ter en YouTube, y quiero reivindicar la fantasía, el desarrollo de software es pura fantasía no es un proceso industrial es un proceso creativo y no existe la creatividad sin conocimiento así que, además de autogestionarnos deberíamos aspirar a la fantasía.

Viendo el canal de Ter, la primera Youtuber con estudios, me hizo reflexionar como ha cambiado todo y como se resolvían problemas antes y como la falta de conocimiento te provocaría echar agua con aviones sobre Notre Dame ardiendo para apagar el fuego, cuando eso es justamente lo que garantiza la catástrofe.

Os dejo el video, disfrutadlo https://youtu.be/bloOQd5YUQg y reflexionemos sobre cómo el conocimiento es la diferencia fundamental para hacer las cosas de otra forma.

Algunos echareis de menos que no solo diga como no se hacen las cosas sino que explique como se hacen. Pero eso, amigos míos, es un camino que debemos recorrer juntos. Debemos llenarnos de conocimiento, aspirar a la fantasía y cuestionarnos nuestra propia perfección. Ese es el camino, ese es nuestro bushido, esta es nuestra conclusión.

Así que, aquí tenéis un comienzo del camino https://docs.microsoft.com/es-es/azure/architecture/guide/