Llegamos a ustedes gracias a:



Reportajes y análisis

¿Qué es una metodología ágil?

Desarrollo de software moderno

[07/02/2018] Hoy en día, todas las organizaciones de desarrollo de software parecen practicar la metodología ágil de desarrollo de software, o una versión de la misma. O al menos ellos creen que sí. Si es nuevo en el desarrollo de aplicaciones o aprendió sobre el desarrollo de software hace décadas usando la metodología de desarrollo de software de cascada, hoy su trabajo está al menos influenciado por la metodología ágil.

Pero, ¿qué es exactamente la metodología ágil y cómo se debe practicar en el desarrollo de software?

La metodología ágil se lanzó formalmente en el 2001 cuando 17 tecnólogos redactaron el Manifiesto Ágil. Ellos escribieron cuatro principios principales para desarrollar un mejor software:

  • Individuos e interacciones antes que procesos y herramientas
  • Software operativo por encima de una documentación completa
  • Colaboración del cliente antes que la negociación del contrato
  • Respuesta al cambio por encima de seguir un plan

Antes de la metodología ágil: La era de la metodología de cascada

Los viejos como yo recordamos los días en que la metodología de cascada era el estándar de oro para el desarrollo de software. El proceso de desarrollo de software requirió una gran cantidad de documentación por adelantado antes de realizar cualquier codificación. Alguien primero escribía un documento de requisitos comerciales que capturaba todo lo que el negocio necesitaba en la aplicación. Estos documentos fueron largos y detallaban todo: Especificaciones funcionales completas de la estrategia y diseños de interfaz visual de usuario.

Esta iniciativa de documentación se siguió con alguna forma de especificación técnica que documentó la arquitectura de la aplicación, las estructuras de datos, los diseños funcionales orientados a objetos, las interfaces de usuario y otros requisitos no funcionales.

Este proceso de desarrollo de software de cascada finalmente iniciaría la codificación, luego la integración y, finalmente, las pruebas antes de que una aplicación se considerara lista para la producción. Todo el proceso podría tomar un par de años.

Se esperaba que los desarrolladores supiéramos "la especificación, tal como se llamaba la documentación completa, tan bien como lo hacían los autores de los documentos y, a menudo, nos regañaban si olvidábamos implementar correctamente un detalle clave delineado en la página 77 de un documento de 200 páginas.

El desarrollo de software en ese entonces tampoco fue fácil. Había muchas herramientas de desarrollo que requerían capacitación especializada, y no había nada parecido a los componentes de software de código abierto, las API y los servicios web que existen en la actualidad. Tuvimos que desarrollar cosas de bajo nivel como la apertura de conexiones de bases de datos y el procesamiento múltiple de datos.

Incluso para aplicaciones básicas, los equipos eran grandes y las herramientas de comunicación eran limitadas. Nuestras especificaciones técnicas fueron las que nos alineaban y las aprovechábamos como la Biblia. Si se modificaba un requisito, sometíamos a los líderes empresariales a un largo proceso de revisión y firma porque comunicar los cambios en todo el equipo y corregir el código era costoso.

Debido a que el software se desarrolló en base a la arquitectura técnica, los artefactos de nivel inferior se desarrollaban primero y los artefactos dependientes después. Las tareas se asignaban por habilidad, y era común que los ingenieros de bases de datos construyeran las tablas y otros artefactos de base de datos primero, seguidos por los desarrolladores de la aplicación que codificaban la funcionalidad y la lógica comercial, y finalmente se superponía la interfaz del usuario. Pasaban meses antes de que alguien viera funcionar la aplicación y, para entonces, las partes interesadas se ponían inquietas y, a menudo, con mayor conocimiento respecto a lo que realmente querían. ¡No es de extrañar que los cambios fueran tan caros!

No todo lo que se ponía delante de los usuarios funcionaba como se esperaba. A veces, los usuarios no utilizaban ninguna función, algo que representaba una inversión desperdiciada. Otras veces, una capacidad tuvo un gran éxito, pero requirió una reingeniería para soportar la escalabilidad y el desempeño requeridos. En el mundo de las cascadas, uno solo aprendía estas cosas después de implementar el software, después de todo ese esfuerzo y gasto.

El cambio de dirección hacia el desarrollo ágil de software

Inventada en 1970, la metodología de cascada fue revolucionaria porque trajo disciplina al desarrollo de software para garantizar que hubiera una especificación clara a seguir. Se basó en el método de fabricación en cascada derivado de las innovaciones de la línea de montaje de Henry Ford de 1913, que proporcionaba certeza en cada paso del proceso de producción para garantizar que el producto final era lo que se especificaba en primer lugar.

Cuando la metodología de la cascada llegó al software, los sistemas informáticos y sus aplicaciones eran generalmente complejos y de gran tamaño, lo que requería una disciplina y un resultado claro. Las cosas también cambiaron lentamente, por lo que los esfuerzos a gran escala no fueron problemáticos como lo son hoy. De hecho, los sistemas se construyeron bajo el supuesto de que no cambiarían, sino que serían buques de guerra perpetuos. Los marcos temporales multianuales fueron comunes no solo en el desarrollo de software, sino también en la fabricación y otras actividades empresariales. Pero la rigidez de la cascada se convirtió en un talón de Aquiles en la era de Internet, donde se requería velocidad y flexibilidad.

La metodología de cascada comenzó a cambiar cuando los desarrolladores comenzaron a trabajar en aplicaciones de Internet. Gran parte del trabajo inicial se realizó en las startups, donde los equipos eran más pequeños, colocados y, a menudo, no tenían antecedentes tradicionales en informática. Hubo presiones financieras y competitivas para llevar sitios web, aplicaciones y nuevas capacidades al mercado más rápido. La tecnología y las plataformas de desarrollo cambiaron rápidamente por ello.

Esto llevó a muchos de nosotros a trabajar en startups para cuestionar los procesos de desarrollo tradicionales y buscar formas de ser más eficientes. No pudimos permitirnos hacer toda la documentación detallada. Todavía debatíamos sobre los cambios en los requisitos, pero nuestras organizaciones estaban menos estructuradas y nuestras aplicaciones no eran tan complejas como los sistemas legados empresariales, por lo que con mayor frecuencia preferíamos hacerlas en lugar de comprarlas. Más importante aún, estábamos tratando de hacer crecer las empresas, así que cuando nuestros usuarios nos dijeron que algo no funcionaba, la mayoría de las veces decidimos escucharlos.

Nuestras habilidades para innovar se volvieron estratégicamente importantes. Era posible recaudar todo el dinero que uno quisiera, pero no se podía atraer a desarrolladores de software talentosos, capaces de trabajar con tecnologías de Internet que cambian rápidamente, si se les trataba como codificadores subordinados siguiendo servilmente "las especificaciones. Rechazábamos a los gerentes de proyectos que llegaban con programas de principio a fin que describían qué deberíamos desarrollar, cuándo deberían enviarse las aplicaciones y, a veces, incluso cómo se debía estructurar el código. Éramos muy malos para alcanzar los cronogramas de tres y seis meses que se redactaban y actualizaban incesantemente.

En cambio, comenzamos a decirles cómo las aplicaciones de Internet necesitaban ingeniería, y entregamos los resultados en un cronograma que elaboramos iterativamente. Resultó que no éramos tan malos al entregar lo que dijimos que haríamos cuando nos comprometimos con él en intervalos pequeños de una a cuatro semanas.

En el 2001, un grupo de desarrolladores de software experimentados se reunieron y se dieron cuenta de que estaban practicando colectivamente el desarrollo de software de forma diferente a la metodología clásica de cascada. Y no todos estaban en nuevas empresas. A este grupo se le ocurrió el Manifiesto Ágil que documentaba sus creencias compartidas sobre cómo debería funcionar un proceso moderno de desarrollo de software. Hicieron hincapié en la colaboración por encima de la documentación, la autoorganización en lugar de prácticas de gestión rígidas, y la capacidad de lograr un cambio constante en lugar de encerrarse en un proceso de desarrollo de cascada rígido.

De esos principios nació la metodología ágil para el desarrollo de software.

Los roles en la metodología ágil

Un proceso ágil de desarrollo de software siempre comienza definiendo a los usuarios y documentando una declaración de visión sobre un alcance de problemas, oportunidades y valores que deben abordarse. El propietario del producto capta esta visión y trabaja con un equipo (o equipos) multidisciplinario para cumplir con esta visión. Aquí están los roles en ese proceso.

Usuario: Los procesos de metodología ágil siempre comienzan con el usuario o el cliente en mente. Hoy en día, a menudo los definimos con personajes de usuario para ilustrar los diferentes roles en un flujo de trabajo que el software está soportando o diferentes tipos de necesidades y comportamientos de los clientes.

Propietario del producto: El proceso de desarrollo ágil en sí comienza con alguien que debe ser la voz del cliente, incluidos los interesados internos. Esa persona destila todos los conocimientos, ideas y comentarios para crear una visión del producto. Estas visiones son a menudo simples y cortas; pero, sin embargo, muestran una imagen de quién es el cliente, qué valores se están abordando y una estrategia sobre cómo abordarlos. Me imagino que la visión original de Google parecía algo así como: "Hagamos que sea fácil para cualquier persona con acceso a Internet encontrar sitios web y páginas web relevantes con una interfaz simple basada en palabras clave y un algoritmo que ubique las fuentes de mayor reputación en los resultados de búsqueda.

Llamamos a esta persona el dueño del producto. Su responsabilidad es definir esta visión y luego trabajar con un equipo de desarrollo para hacerlo realidad.

Para trabajar con el equipo de desarrollo, el propietario del producto desglosa la visión en una serie de historias de usuarios que deletrean más detalles sobre quién es el usuario objetivo, qué problema se resuelve para ellos, por qué es importante para ellos y qué restricciones y los criterios de aceptación definen la solución. Estas historias de usuarios son priorizadas por el propietario del producto, revisadas por el equipo para garantizar que tengan una comprensión compartida de lo que se les pide.

Equipo de desarrollo de software: En la metodología ágil, el equipo de desarrollo y las responsabilidades de sus miembros difieren de los del desarrollo de software tradicional.

Los equipos son multidisciplinarios, compuestos de un grupo diverso de personas con las habilidades para hacer el trabajo. Debido a que la atención se centra en la entrega de software en funcionamiento, el equipo debe completar aplicaciones de funcionamiento de extremo a extremo. De modo que la base de datos, la lógica comercial y la interfaz de usuario de una parte de la aplicación se desarrollan y luego se demuestran -no se hace con toda la aplicación. Para hacer esto, los miembros del equipo tienen que colaborar en qué y cómo se están desarrollando. Para hacerlo, se reúnen con frecuencia para asegurarse de que todos estén alineados con quién está haciendo qué y cómo se está desarrollando realmente el software.

Además de los desarrolladores, los equipos de desarrollo de software pueden incluir ingenieros de control de calidad (QA), otros ingenieros -de bases de datos y sistemas de respaldo-, diseñadores y analistas, según el tipo de proyecto de software.

Scrum, Kanban y otros marcos de trabajo de metodología ágil

Existen muchos marcos ágiles que proporcionan detalles sobre el proceso de desarrollo y prácticas de desarrollo ágiles, alineados con un ciclo de vida de desarrollo de software.

El marco ágil más popular se llama Scrum. Se centra en un ritmo de entrega llamado sprint y estructuras de reuniones que incluyen:

  • Planificación (donde se identifican las prioridades del sprint)
  • Compromiso (donde el equipo revisa una lista o acumulación de historias de usuarios y decide cuánto trabajo se puede hacer en la duración del sprint)
  • Reuniones diarias stand up (para que los equipos puedan comunicar actualizaciones sobre su estado de desarrollo y estrategias)

Los sprints concluyen con una reunión de demostración en la que se muestra la funcionalidad al propietario del producto, seguida de una reunión retrospectiva donde el equipo analiza qué fue bien y qué necesita mejoras en su proceso.

Muchas organizaciones emplean maestros de Scrum o entrenadores para ayudar a los equipos a administrar el proceso de scrum.

Aunque el scrum domina, hay otros marcos ágiles:

  • Kanban funciona como un proceso de fan-in y fan-out en el que el equipo extrae las historias de los usuarios de una tabla de entrada y las canaliza a través de un proceso de desarrollo por etapas hasta que son terminadas.
  • Algunas organizaciones adoptan un enfoque híbrido ágil y en cascada, utilizando procesos ágiles para nuevas aplicaciones y cascada para tecnología previa.
  • También existen varios marcos para permitir a las organizaciones aplicar el procedimiento a escala en múltiples equipos.

Si bien los marcos de trabajo de metodología ágil definen el proceso y la colaboración, las prácticas de desarrollo ágiles son específicas para abordar tareas de desarrollo de software realizadas en alineación con un marco ágil.

Así, por ejemplo:

  • Algunos equipos adoptan la programación de pares, donde dos desarrolladores codifican juntos para generar un código de mayor calidad, y para permitir que más desarrolladores senior guíen a los junior.
  • Algunos equipos adoptan un desarrollo basado en pruebas para asegurarse de que la funcionalidad subyacente brinde los resultados esperados.
  • Muchos equipos también adoptan estándares técnicos para que la interpretación del desarrollador de una historia del usuario no solo conduzca a la funcionalidad deseada, sino que también cumpla con la seguridad, la calidad del código, las convenciones de nomenclatura y otras normas técnicas.

Por qué la metodología ágil es mejor

Cuando toma el conjunto de principios ágiles, los implementa en un marco ágil, aprovecha las herramientas de colaboración y adopta prácticas de desarrollo ágiles, generalmente obtiene aplicaciones de mejor calidad, aplicaciones más rápidas y mejores procedimientos técnicos (también conocidos como higiene).

La razón principal es que la metodología ágil está diseñada para brindar flexibilidad y la adaptabilidad. No define todas las respuestas por adelantado como lo hace en el método de cascada, sino que divide el problema en componentes digeribles que luego desarrolla y prueba con los usuarios. Si algo no funciona bien o como se espera, o si la iniciativa revela algo que no se ha tenido en cuenta, puede adaptar la iniciativa rápidamente para retomar el camino con agilidad, o incluso cambiar las pistas si eso es lo que se necesita. La metodología ágil permite que cada miembro del equipo contribuya a la solución, y requiere que cada uno asuma la responsabilidad personal por su trabajo.

Para muchos problemas, el desarrollo ágil es mejor porque sus principios, marcos y prácticas están diseñados según las condiciones operativas actuales. Los marcos de trabajo ágiles y los procesos de desarrollo que priorizan la entrega de software en funcionamiento de forma iterativa y promueven el aprovechamiento de la retroalimentación para mejorar la aplicación y el proceso son más adecuados para el mundo actual de funcionamiento más inteligente y más rápido.

Los propietarios de productos pueden pensar que saben exactamente cómo desean desarrollar una aplicación que cumpla con su visión, pero rara vez quieren renunciar a la capacidad de mejorar esa visión mientras hablan con más usuarios y ven cómo una aplicación realmente funciona para ellos. De manera similar, los equipos de desarrollo creen saber cómo diseñar la aplicación perfecta, pero no pueden demostrarla hasta que la aplicación completa esté integrada, la funcionalidad demostrada y los cambios en los requisitos estén racionalizados.

El desarrollo ágil también es mejor porque fomenta un proceso continuo de mejora. Imagínese que Microsoft hubiese finalizado el desarrollo de Windows después de la versión 3.1, o que Google hubiese dejado de mejorar sus algoritmos de búsqueda en el 2002. El software necesita ser actualizado, respaldado y mejorado constantemente; los procesos ágiles, que son de naturaleza iterativa, establecen tanto una mentalidad como un proceso para esa mejora continua.

Finalmente, el desarrollo ágil es mejor porque las personas en el equipo son más productivas y están más felices trabajando con este proceso. Los ingenieros tienen voz en cuanto a la cantidad de trabajo que están asumiendo, y están orgullosos de mostrar sus resultados. A los propietarios de productos les gusta ver su visión expresada en el software más rápido y poder cambiar la prioridad según los últimos conocimientos. A los usuarios les gusta obtener software que haga lo que realmente necesitan, de una manera que satisfaga o mejore sus procesos.

Hoy en día, las empresas necesitan ser competentes en el desarrollo de software para ofrecer buenas experiencias digitales, grandes experiencias para sus clientes, en un mundo extremadamente competitivo. Necesitan atraer y mantener un gran talento para hacer eso. El desarrollo ágil es la forma en que las empresas lo logran.

Isaac Sacolick es el autor de Driving Digital: La Guía del Líder para la Transformación Empresarial a través de la Tecnología, que cubre muchos procedimientos tales como la metodología ágil, Devops y ciencia de datos, que son fundamentales para programas de transformación digital exitosos. Sacolick es un CIO social reconocido, bloguero desde hace mucho tiempo en Social, Agile and Transformation y CIO.com, y es presidente de StarCIO.

Artículos relacionados