Cuando estudiaba Ingeniería Informática una de las asignaturas era la Ingeniería del Software cuya función era entender cómo funcionaba el ciclo de vida del software. En la Universidad se orientaba exactamente igual que la Arquitectura, es decir teníamos que planificar primero y después ejecutar. Prueba de esta estrategia es que hoy en día existen profesiones como “arquitecto software”.
Sin embargo, si algo hemos aprendido en estas décadas con respecto al desarrollo software es que funciona diferente a la arquitectura. Un gran plan rara vez garantiza un éxito y es mucho más importante la capacidad de adaptación.
¿Debemos usar la arquitectura para entender el software?
Requisitos
En cualquier trabajo antes de ponerte manos a la obra tienes que entender muy bien qué es lo que quieres hacer. Esta actividad la llamamos la “toma de requisitos”, vital en un entorno complicado. Por ejemplo, en el mundo de la construcción los requisitos son clave porque nos van a permitir desde el punto de vista arquitectónico definir el trabajo que queremos hacer. Además, nuestro diseño tendrá que ser validado por el cliente antes de pasar a desarrollo. En arquitectura, un buen plano es clave y ayuda a estudiar el resultado final y a mejorar las expectativas que tenemos con el cliente. ¡Podemos tener una conversación sobre el resultado!
Sin embargo, en el mundo del conocimiento, y en concreto en el desarrollo de software, el plan puede ser importante pero nunca suele ser relevante. Una estrategia nos puede ayudar pero es más importante entender muy bien el problema a resolver que su plan. Y lo podemos ver en muchos ejemplos: el desarrollo de vacunas donde tú tienes clara la enfermedad y cómo se hace una vacuna pero, tienes que estar continuamente haciendo prueba-error. Por eso, siempre decimos que en el mundo del conocimiento resolvemos problemas complejos, si es que conseguimos hallar una solución. Incluso puede que la solución no sea 100% completa. Hay vacunas que cubren ciertas enfermedades pero no al 100% ni impiden que te afecte la enfermedad. Sin embargo, aceptamos como una enfermedad resuelta porque razonablemente la vacuna ayuda.
Entramos en el mundo de la ambigüedad, donde tener control en los problemas complicados tienen sentido, pero se vuelve más ambiguo en el mundo complejo donde el concepto razonable depende mucho de la persona que lo recibe. Aquel ciudadano que se pone una vacuna de una enfermedad y le sienta mal te dirá que las vacunas son malas y que no se la vuelva a poner. En construcción, el edificio tiene que estar perfecto
Estrategias
En el mundo de la construcción y en el mundo complicado si nos estamos enfrentando a un problema muy grande lo que solemos hacer es dividirlo. El divide y vencerás tiene sentido en el mundo complicado. Lo que hacemos es: dado un gran problema, lo troceamos en partes más manejables que nos permita incluso estimar para dar fecha o asignar a personas. Esta es la base del diagrama de Gantt o cronograma que nos permite desarrollar ese plan detallado para poder afrontar el problema complicado. Por eso cuando vemos unos requisitos en el mundo complicado partimos de una gran idea como puede ser un edificio y lo vamos partiendo en trozos que, juntos, resuelvan el problema. Ahora bien, cada uno de esos trozos puede ser importante pero nunca aportará valor hasta que el conjunto total de la obra quede terminado.
En un mundo complejo, como el del desarrollo de software, la estrategia es muy distinta. La clave es entender muy bien el problema a resolver, entender que existe ambigüedad y que no se puede planificar una solución. Podemos marcar una estrategia en la que construimos el denominado backlog o lista de pendientes compuesta por un montón de elementos que nos ayudarán a acercarnos a la solución que queremos conseguir.
Este backlog está compuesto por opciones: elementos que idílicamente son independientes y que podemos jugar con ellos para decidir en cada momento que incorporamos al producto de cara a resolver el citado problema. Es aquí donde entra la clave del mundo complejo. Al haber incertidumbre el orden que le demos puede ser muy distinto entre unos equipos y otros cosa que sería extremadamente rara cuando hacemos un edificio donde todo el mundo partiría por abrir un agujero y comenzar por los cimientos.
Entendiendo la complejidad y Scrum
Ágil y Scrum se basan en la idea de la complejidad. Cuando entendemos la complejidad entendemos que el plan no es importante y por eso la toma de requisitos se hace más desde el punto de vista de lo denominadas features o características. Es decir, parto de un problema y estudio que opciones y características pueden incorporar a mi producto para conseguir una solución que genere valor. Algunas características las haremos, otras las eliminaremos y otras pasaré de ellas con el tiempo porque iré descubriendo que no son relevantes.
Por ejemplo, puedo tener que decidir entre un requisito legal clave para que no me multen u otro requisito que me ayude a vender más. Si descubro que saltarme la ley me genera una multa asumible a cambio de hacer un desarrollo que me provoque muchos beneficios quizás merezca la pena. Sin embargo, si ese requisito legal me va a llevar a la cárcel, probablemente lo antepone a todo lo demás. Este juego es clave en entornos complejos y por eso el verdadero debate cuando hacemos software es con qué prioridades jugamos y en qué orden queremos hacer las cosas.
Es por ello, que en el mundo de la construcción se construye con un cierto orden que más o menos es similar y con muy poca capacidad de variación porque tu objetivo final es resolver esa construcción que estás haciendo. Mientras que en software el objetivo era resolver un problema y nunca sabes cuán lejos estás de él. Para ello, es clave tener métricas de negocio, que nos orienten y nos den información, lo que nos habilita la toma de decisión en cada momento con nuevas características a incorporar a nuestro producto con el ánimo de resolver el problema al que nos enfrentamos.
Y tú ¿sabes diferenciar bien los requisitos waterfall de los ágiles?
