Desarrollar software no es nada sencillo
¿Con cuánta frecuencia concluimos un proyecto y nos preguntamos: «Si hubiéramos dedicado más tiempo al análisis, seguramente habríamos evitado algunos problemas»?. En otras ocasiones, pasamos meses analizando algo, solo para descubrir que el tiempo de construcción es tan breve que pensamos: «Si hubiéramos empezado a desarrollar antes, habríamos progresado más rápido». ¿Cuál es la razón detrás de esto? Cuando aplicamos el método causa-efecto para abordar nuestros problemas, raramente encontramos las causas reales y terminamos con un «si hubiéramos hecho…». Sin embargo, no podemos predecir los efectos en el momento en que las causas se manifiestan. El software es intrínsecamente complejo.
¿Por qué surge Scrum en el mundo del software y no antes? El software, como disciplina relativamente nueva, intentó seguir el modelo de otras disciplinas ya existentes. Utilizamos la arquitectura como disciplina, lo que lleva a procesos de diseño y construcción, y creamos el rol del «arquitecto de software». No obstante, con el tiempo, el desarrollo orientado a objetos y la necesidad de trabajo en equipo complicaron las cosas.
Descubrimos que el software es diferente a otras disciplinas; es complejo. Ser complejo implica que hay más variables desconocidas que conocidas. Esto conduce a estimaciones que raramente se cumplen, ya que no podemos anticipar problemas que desconocemos en el momento de hacer predicciones. Aquí radica la razón por la cual, al analizar situaciones negativas, pensamos: «¿Si hubiéramos sabido esto, podríamos…?» y creemos que al agregar más tiempo de análisis, podríamos haber resuelto los problemas. Sin embargo, al agregar más tiempo, surgen nuevos problemas no detectados previamente.
¿Es posible que nuestras predicciones nunca sean exactas?
Los firmantes del manifiesto Ágil, al descubrir la complejidad del software, optaron por una estrategia diferente. La ciencia, que se enfrenta a problemas complejos desde hace siglos, ofrece una respuesta. El método científico se basa en tres pilares fundamentales: inspección, adaptación y transparencia. Para abordar problemas complejos con pocas variables controladas, es ideal avanzar gradualmente, detenerse para inspeccionar el progreso y adaptarse en consecuencia. Además, se requiere transparencia para tomar decisiones informadas.
Precisamente, Scrum se basa en estos tres pilares. Cada evento en el marco de Scrum proporciona oportunidades para inspeccionar, adaptar y fomentar la transparencia. Por ejemplo, en la Daily Scrum, inspeccionamos nuestro plan de Sprint (Sprint Backlog) y adaptamos nuestras acciones para las próximas 24 horas hasta la siguiente reunión. Más detalles sobre el funcionamiento de Scrum se abordarán en futuras publicaciones.
Es crucial internalizar que el software es complejo. Los problemas complejos no se resuelven con más tiempo de análisis, sino con el método de prueba y error. Cuando te enfrentas a problemas en un equipo, reflexiona sobre cuánto tiempo invertiste en planificación y si más tiempo realmente habría sido la solución o si los problemas surgieron durante el desarrollo. La importancia de llevar a producción cuanto antes, aunque sea con una pequeña funcionalidad, radica en eliminar las variables desconocidas.
Resulta interesante cómo muchos autores destacan la complejidad del software. Creo que ahí reside la clave del éxito de Agile: entender que el software no es predecible y que la gestión basada en estimaciones presenta numerosos desafíos.
0 comentarios