El software es una disciplina que ha nacido recientemente. Comparada con la arquitectura, que lleva miles de años, estamos hablando de comparar una larva al lado de una mariposa que lleva muchos kilómetros volando. Al ser una disciplina nueva, se ha abordado con los paradigmas que existían, primero tomamos datos, analizamos el problema, diseñamos una solución, ejecutamos, probamos y finalmente lo llevamos a producción. Esto es lo que llamamos el ciclo de vida del software.
Una vez que llevamos unos años trabajando así, los responsables de las empresas deciden que es el momento de productivizar este ciclo. Hiperespecializamos a las personas, tenemos mega diseñadores de software que nunca desarrollan, desarrolladores que no quieren testear su trabajo, testers que no quieren saber nada de la subida de código y así nos convertimos en auténticas máquinas de hacer software.
Unos años después aparecen nuestros amigos de Scrum, que como se ha puesto de moda, han aprovechado para traernos ideas raras donde hablan de equipos sin etiquetas y que compartan la responsabilidad. Que los equipos se autoorganizan y no necesitan un responsable que les diga lo que tienen que hacer. ¿Por qué dicen eso si el software no ha cambiado? ¡Si lo seguimos haciendo igual! Primero tomamos información o requisitos, analizamos, diseñamos la solución, ejecutamos, probamos y lo llevamos al usuario.
Una duda ¿Si el ciclo de vida del software no ha cambiado porque ha surgido Scrum y otras maneras diferentes de hacer software? ¿Nos estamos engañando? ¿Estos frikis se han subido a la ola? Para muchos, Scrum no es más que una moda pasajera que no está aportando mucho a su organización. Es más, para algunos incluso lo ven como algo negativo porque no quieren darme la fecha final de entrega y no hay control.
¿Dónde está la diferencia entre Scrum y lo que hemos hecho siempre? Hay dos maneras de verlo, la manera incorrecta es la que hacen muchas compañías: sustituyen la toma de requisitos por un Design Thinking, el análisis y el diseño por una conceptualización, el desarrollo por Sprints con fecha cerrada, el testing lo abordan en un “hardening Sprint” y la subida en un “Release Sprint”. Si lo piensas, estás poniendo nombres molones a lo de siempre y post-its, muchos post-its. ¿Realmente esperamos convencer a alguien de que somos diferentes?
La otra manera es la que realmente propone Scrum y, en mi opinión, muchas organizaciones no han interiorizado. Sí, el ciclo de vida es el mismo, pero lo vas a desarrollar en un timebox, en un tiempo cerrado que va a ser corto para que falles, aprendas y vuelvas a empezar. Realmente todo el ciclo de vida se hace igual, pero solo en un periodo inferior a 30 días, lo que llamamos Sprint. ¡Aquí está el cambio de paradigma!
Para que esto funcione, tenemos que dejar de pensar en la optimización de las personas, y pensar en la optimización del valor que queremos entregar. No hay que pensar si el analista tendrá o no suficiente tarea o en qué momento entra el QA. “Tenemos 2 semanas, un objetivo, ¡A por ello!”.
Durante el Sprint se hacen todas las fases, se toman requisitos y se hablan de ellos, se analiza e incluso se diseña y todo eso se puede hacer en una Sprint Planning. Durante los días nos organizamos, desarrollamos y probamos a la par. Además, dado que el objetivo es poner a disposición del usuario valor, también haremos la entrega y puede que la subida. ¡Somos un equipo!
Por eso el Sprint es un proyecto con una vida corta que añade valor a nuestro producto a base de incrementos. Es por esto que ¡El propósito de Scrum es hacer productos!
Por tanto, no hemos cambiado la manera de hacer software como tal, lo que hemos hecho es asumir que el software es complejo y que se parece más a disciplinas como la investigación científica. La manera de hacer software es la misma, conocemos el problema, analizamos la solución, ejecutamos y terminamos. Solo que, lo hacemos muchas veces para descubrir lo que realmente necesita un usuario, lo que le da valor y lo que, en definitiva, hace que las organizaciones tengan éxito.
Tabla de contenido
Entradas relacionadas
Los 5 pilares de una transformación Agile5 (1)
Comentarios recientes