Historia movimiento Agile

Artículo

Historia del movimiento Agile

Hacia la Agilidad y más allá (II parte)

Una reacción contra los procesos pesados

En el capítulo anterior veíamos como problemas que consideramos muy del presente ya aparecían en el mundo del desarrollo de software hace 30 años y que esto había provocado la reacción que llevó a la aparición del movimiento Agile, sus valores y el manifiesto Agile, los mandamientos de este movimiento.

Agile no es en absoluto crítico con las metodologías de desarrollo practicadas en las décadas de los 70 y 80, que habían sido creadas en respuesta a los enfoques caóticos y no planificados que se utilizaban en los primeros tiempos del software.

De hecho, de 1970 a 1990 fue en gran medida cuando surgieron las teorías y prácticas fundacionales de la ingeniería de software. La idea era equiparar la ingeniería de software con la ingeniería tradicional y tomar prestada la mayor cantidad posible del diseño y la construcción de esta.

Este enfoque se manifestó principalmente en lo que conocemos como metodología Waterfall o en cascada. Este enfoque definió claramente las principales fases del ciclo de vida de desarrollo de aplicaciones, desde las necesidades hasta la implementación. Se le llamó "cascada" porque los equipos completan un paso, completamente, antes de pasar al siguiente. Los requisitos deben estar completos antes de pasar al diseño funcional, el diseño funcional completo antes del diseño detallado, y así sucesivamente.

Al igual que el agua que no fluye cuesta arriba, rara vez hay disposiciones para volver a una etapa más temprana del proceso. Una vez que terminabas con un escenario, este quedaba congelado en el tiempo. Este método trajo un sentido de organización y práctica de ingeniería al desarrollo de software.

Aquí es donde nos encontramos con el primer y probablemente troncal problema. Los proyectos de software se parecen muy poco a los proyectos de la ingeniería tradicional. Estos proyectos de ingeniería civil o mecánica rara vez cambian en el transcurso de una década o más. Si necesita diseñar un puente o un edificio de gran altura hoy en día, es muy probable que los detalles específicos no requieran modificación en un año o dos.

En ese momento, en la mayoría de los grupos de desarrollo de software y en los departamentos de informática de las universidades se consideraba un evangelio que cuanto más tiempo se dedicara a la planificación, menos tiempo se dedicaría a escribir código, y mejor sería ese código.

Esto sólo reforzó el enfoque de procesos pesados, que ponía más énfasis en la planificación y la documentación que en la entrega de software de trabajo.

Y el caldo de cultivo se generó.

Permitidnos no estar de acuerdo con lo establecido

Los proyectos de software rara vez tienen el mismo tipo de estabilidad que los proyectos de ingeniería tradicionales. Las necesidades del negocio cambian, aparentemente de la noche a la mañana, y ciertamente más rápido que los meses o años requeridos anteriormente para completar una aplicación de software. En retrospectiva, parece obvio que el software requiere un enfoque diferente de la ingeniería.

Por supuesto, la otra parte del problema es que el diseño de software es tanto una ciencia como un arte, con imperfecciones y limitaciones humanas asociadas. Primero, simplemente no sabemos cómo definir muy bien el software. Los usuarios pueden describir sus flujos de trabajo de negocio, pero no pueden decir a los diseñadores de software qué características los automatizarán y cómo deberían funcionar. Nuestra incapacidad para definir con precisión lo que se necesita antes de empezar a construir el producto separa la ingeniería de software de la mayoría de las otras disciplinas de ingeniería.

En segundo lugar, la traducción de los requisitos, por imperfectos que sean, a las especificaciones, y de las especificaciones a la implementación, está plagada de ambigüedades. Algo de eso viene de la naturaleza de la palabra escrita; si una declaración puede ser malinterpretada, es casi seguro que lo será. Pero debido a que los equipos están leyendo a nivel de diseño y traduciéndolo a un nivel de implementación, los errores y malentendidos están destinados a ocurrir y a ocurrir de manera frecuente.

Los visionarios tienen diferentes puntos de vista

Parte de la reacción también fue impulsada por el mayor desarrollador de software del mundo: el gobierno de los Estados Unidos. En particular, los estándares del Departamento de Defensa (DoD) para el desarrollo de software (en particular, DOD-STD-2167) favorecieron claramente el modelo de cascada hasta finales de la década de 1990, cuando fueron cambiados para apoyar explícitamente los procesos iterativos.

A pesar de que el modelo de cascada predominó en las décadas de 1980 y 1990, la industria y los líderes de pensamiento académicos estaban retrocediendo. Una respuesta inicial importante fue la de James Martin con el desarrollo rápido de aplicaciones, o RAD. El propósito del RAD era reducir la etapa de preparación y entrar rápidamente en el desarrollo, para que el negocio pudiera comenzar a colaborar de inmediato con el equipo de desarrollo al ver un prototipo funcionando en tan sólo unos días o semanas.

También hubo un movimiento hacia el llamado desarrollo de software iterativo. Mientras que el desarrollo de software iterativo tiene sus raíces al menos en los años 60, el concepto de mejora incremental se había arraigado a través del trabajo del gurú de la calidad W. Edwards Deming y otros incluso antes. El concepto es que se realiza una actividad, se miden las características esenciales, se hacen cambios de sentido común y se vuelve a medir para mejorar.

Probablemente el trabajo más reconocido en el desarrollo iterativo de los años 80 fue "A Spiral Model of Software Development and Enhancement" de Barry Boehm. El modelo en espiral era una técnica iterativa específica por la cual un proyecto comienza pequeño y crece gradualmente a medida que se incorporan más características y capacidades. Mientras que los proyectos de gran envergadura y gran visibilidad utilizaban a menudo un modelo de cascada estricto, las alternativas estaban al acecho en segundo plano.

Continuará…

Julio Roche

Julio Roche es Specialist Director del área de System Development&Integration, en la práctica de DxD de Deloitte. Profesional con más de 25 años de experiencia en el mundo del desarrollo de soluciones tecnológicas, su labor se encuentra actualmente focalizada en el terreno de la movilidad y la transformación digital, lo que le ha llevado a estar involucrado en procesos de implantación de metodologías ágiles desempeñando todos los roles que estas enumeran. Ha sido Agile Coach&Trainer, Scrum Master, Product Owner y parte del Development Team.