Metodologías de desarrollo de software: un enfoque ágil

Cuántos de nosotros nacimos desarrollando software basado en etapas secuenciales dependientes unas de otras. Durante muchos años la principal destreza medida a un ingeniero de software se refería a su capacidad para producir líneas de código para satisfacer una indocumentada etapa de requerimientos y saltar a la implantación del sistema, anteriormente denominada salida a producción.

Los múltiples problemas de presupuesto, costo, calidad y desgaste del equipo del proyecto nos llevaron al desarrollo basado en iteraciones cuya marca más conocida fue el Rational Unified Process  o Proceso de Desarrollo Unificado, donde se incorporaron conceptos como iteración, fases y etapas; además agregaron temas como como Modelado de Negocio, donde convertimos a exitosos ejecutivos de negocio de las organizaciones, en frustrados diseñadores de procesos usando UML (Lenguaje Unificado de Desarrollo), inició el ciclo de la arquitectura de software como modelo de rescate de una incomprendida etapa de diseño de software de su anterior metodología (diseño en cascadas). Las empresas se enrutaron en el viaje para incorporar todos estos conceptos a su departamento de desarrollo implementando capacitaciones masivas de Requerimientos, Arquitectura de Software y Manejo y control de versiones.  Una vez que las capacitaciones masivas eran finalizadas, los proyectos pilotos empezaron a surgir, y consigo trajo las siguientes preguntas:

  1. ¿Debo hacer todos esos documentos en todos los proyectos?
  2. ¿Qué pasa si no hay una correcta definición de los requerimientos?

Y de la mano vinieron aseveraciones como:

  1. Voy a tardar más documentando que programando
  2. Yo estudié para programar y no para ser documentador
  3. Cuando vamos a ir a producción con estos cambios
  4. No sé cómo pasar del diseño en papel al código fuente

 

Las empresas empezaron a notar una excesiva burocracia para implementar proyectos, en un mundo cada día más dinámico. En mi experiencia y opinión, eso mató el modelo iterativo para dar paso a la agilidad.

Y la agilidad trajo consigo dudas:

  • ¿Si lo hacemos rápido bajará la calidad?
  • ¿Rápido significa menos interacción con el usuario?
  • ¿Qué pasará con las fechas de entrega?

Entonces los conceptos de transparencia, inspección y adaptación se volvieron la principal arma de trabajo para los equipos de desarrollo de software.

Transparencia para aceptar que los modelos agiles requieren madurez en el liderazgo de los requerimientos o historias de usuarios; transparencia para aceptar nuestras limitaciones técnicas en un mundo donde la tecnología evoluciona más rápido de cómo podemos comprenderla, y transparencia para tener una comunicación asertiva con el equipo, que aumente la cohesión del mismo.

Los modelos agiles nos enseñaron que mediante la inspección podemos identificar las limitaciones del equipo, y cómo comunicarlas en el momento y lugar indicado, aceptando la crítica constructiva para mejorar las habilidades de las personas involucradas en el proceso de desarrollo de software.

Adicionalmente, los modelos ágiles trajeron una habilidad blanda muy apreciada en los tecnológicos días que nos desempeñamos: adaptación; sin ella, no podríamos sobrevivir en un mundo profesional cada día más automatizado.

¿Hasta cuando es posible que perduren estos modelos ágiles? Probablemente evolucionarán a equipos cada día más estructurados, cohesivos, con capacidad de autocapacitación y adaptación a nuevos modelos de negocio que traen consigo muchos aprendizajes.

Finalmente, la pregunta, ¿podríamos haber sobrevivido al modelo ágil, sin antes parar por un cruel proceso iterativo, y sin definiciones previas de entregables y estándares? En mi opinión, no, porque solo una mente estructurada es capaz de mutar hacia la agilidad sin morir en el intento.

Mira los cursos que hemos creado para ti

Contáctenos