Agile es una metodología para abordar el desarrollo de software. Consiste en diferentes marcos como SCRUM o Kanban que ayudan a los equipos de desarrollo a construir, probar y recopilar continuamente comentarios sobre su producto.

Ágil consta de cuatro principios básicos:

  1. Individuos e interacciones sobre procesos y herramientas
  2. Software de trabajo sobre documentación completa
  3. Colaboración con el cliente a través de la negociación de contratos
  4. Responder al cambio sobre el seguimiento de un plan

Revisaré estos principios más adelante y daré más sentido a ellos. Para hacerlo, es importante dar un paso atrás y comprender las prácticas de desarrollo de software que se usaban anteriormente.

Waterfall

El desarrollo de Waterfall es un enfoque muy lineal para construir un producto. Tiene poco o ningún espacio para retroalimentación o iteración hasta que el producto esté completamente construido y probado.

Así es como funciona: los equipos pasan semanas (y a veces meses) redactando documentos de requisitos de productos..

Antes de que se escriba realmente cualquier código, los gerentes de producto, analistas y diseñadores reunirán un documento masivo que describa los requisitos del producto con extremo detalle.

Por decir lo menos, este es un proceso largo y laborioso en el que, inevitablemente, se pierden algunas cosas.

Aquí hay un experimento mental simple. Piensa en la búsqueda de Google o en un buscador de correo electrónico de cliente.

Ahora intenta tratar de imaginar el documento de requisitos para estos productos.

Sin lugar a dudas, las cosas importantes se perderán. Uno simplemente no puede concebir el caso de uso o la escala o el alcance de cómo estos productos evolucionarán con el tiempo.

Si haz creado un producto, como constructor en solitario o como miembro de un equipo, es probable que puedas relacionarte con esta afirmación.

Cuando todo está acordado, las especificaciones se entregan al equipo de ingeniería que luego construye el producto para especificar, aprovechar cualitativamente y cuantificar datos e insumos.

Cuando todo está codificado, comienza la prueba.

Si se trata de un producto complejo, las pruebas y la corrección de errores pueden tomar semanas o meses ya que todo el producto debe pasar por una revisión rigurosa. Cuando los probadores y los gerentes de producto firman los requisitos de la prueba, el producto está listo para enviarse a la producción.

Hay una serie de deficiencias en el desarrollo de Waterfall, y aquí hay algunas.

Falta de mecanismos de retroalimentación

¿Qué pasa si el equipo de desarrollo sigue exactamente las especificaciones y resulta que al ver el producto cobrar vida simplemente no es tan convincente como el equipo de producto pensó que habría sido? O peor aún, ¿qué pasa si hay un error en el documento de especificación?

En el desarrollo de Waterfall, no sabrá la respuesta a estas preguntas hasta que el producto ya esté construido.

El desarrollo de productos puede conducir a grandes costos fijos. Si el producto no funciona, estos costos podrían convertirse en costos hundidos.

Los costos hundidos son el enemigo del constructor porque un costo hundido es un costo que ya se ha incurrido y no se puede recuperar.

¿Qué pasa si la hoja de ruta cambia?

Esto sucede todo el tiempo. Sucede en el equipo que está utilizando para leer este artículo, sucede en su empresa, y sucede en las empresas de tecnología grandes y pequeñas.

¿Qué pasa si la hoja de ruta cambia y el equipo necesita dirigir su atención a otra cosa? Bajo Waterfall, te quedas con un producto inutilizable. Piense: rigidez.

Una vez más, si tu no puedes convertir tus costos fijos en algo flexible que te quedará con una factura grande y no hay mucho que mostrar para ello.

Todo el trabajo dedicado, los plazos estresantes, el calandrado de la pizarra y las noches no conducirán a los resultados que deseabas al comienzo del proyecto.

El producto recoge el polvo hasta que finalmente se envía

En lugar de entregar mejoras incrementales a la producción durante un período de tiempo, la metodología de Waterfall espera para entregar todo el producto hasta el final.

Si bien este es un enfoque razonable para construir un automóvil, este no es un gran enfoque para el software.

El software, a diferencia de los automóviles, es flexible en las entradas de diseño.

La gente no puede usar autos a medias. Pero usamos software medio construido todo el tiempo.

Entra a ágil

Agile ayuda a resolver estos problemas al permitir que equipos de desarrollo de productos crean continuamente características que agregan valor. También permite a los equipos obtener constantemente comentarios sobre su trabajo y realizar los cambios según sea necesario.

Con el empleo de métodos ágiles, los equipos de manera consistente y predecible envían pequeñas piezas de código a la producción a un ritmo rápido.

Una vez que han completado cualquier tipo de característica que agregua valor, lo prueban y lo liberan al mundo. Este es un enfoque iterativo para la construcción de tecnología.

En lugar de tomar meses para construir un producto final y ejecutar una prueba de extremo a extremo, el desarrollo ágil permite a los equipos construir continuamente piezas más pequeñas del producto final y agregarlas a la producción a lo largo del tiempo.

Esto significa que las pruebas son más rápidas ya que solo está probando la compatibilidad del último fragmento de código. Esto también significa que los usuarios y las partes interesadas están más felices porque pueden ver y utilizar las últimas mejoras de productos de forma continua.

Considera ambos enfoques para un verdadero ejemplo de la palabra de remodelación de una cocina. Digamos que tomará seis meses hacer bien el trabajo de remodelación.

Waterfall sugeriría que el contratista y su equipo reconstruyan toda la cocina, luego revelen toda la cocina al cliente después de que se acaben los seis meses.

Mientras que el trabajo se hace en la misma cantidad de tiempo, el propietario se queda en la oscuridad. Preguntas simples como el "¿cómo?", va ir en gran parte sin respuesta. Lo peor de todo es que los propietarios no pueden usar ninguna parte de la cocina hasta el final.

Con Agile, el contratista en su lugar averiguaria lo que su equipo podría hacer cada pocas semanas, y luego permitir que su cliente lo vea y lo use mientras remodelan el resto.

Tal vez puedan reemplazar los gabinetes en el primer mes, las encimeras en el segundo mes, y en el tercer mes instalan una nueva nevera y estufa. No es un mal resultado para ambas partes!

En el segundo enfoque, el propietario obtiene el beneficio de usar partes de la cocina antes de que todo esté completo. En lugar de que la nueva estufa este allí acumulando polvo, en realidad se está utilizando tan pronto como se pueda usar.

¿Y tal vez el propietario de la cocina quiera cambiar un gabinete por un estante?

El contratista ahora puede al menos planificar ese cambio antes de que se acaben los seis meses y dejar saber al propietario cómo afectará la línea de tiempo del proyecto.

Al parecer, ambas partes pueden trabajar juntas y comunicarse de manera transparente para garantizar los resultados y que el trabajo sea termido.

Estos son algunos de los muchos beneficios de Agile. Ambas partes están mejor.

Trate de llevar esta lección adelante a medida que aprendas nuevas habilidades de desarrollo en freeCodeCamp y aplicar tus habilidades en proyectos.

Consideremos algunos otros ejemplos en el mundo del software

Revisando los cuatro principios de Agile, ahora podemos comenzar a encontrar ejemplos de la aplicación de Agile en los mundos real y digital.

Por ahora espero que puedan ver cómo estos principios son un asalto directo al proceso de cascada.

Principio #1: Individuos e interacciones sobre procesos y herramientas

Tener un proceso sólido y un conjunto de herramientas es muy importante en Agile. Sin embargo, la valoración de los individuos y las interacciones sobre las herramientas permite una mayor creación de valor y producción.

Los miembros individuales del equipo pueden innovar.

En lugar de obligar a las personas a cumplir con estrictas ideaciones y especificaciones, puede darles más ancho de banda para experimentar.

Parte de colocar a los individuos sobre las herramientas es la experimentación con nuevos flujos de trabajo. Un ejemplo que es relevante para la innovación en el desarrollo de software ágil es el códec, un programa informático que codifica o decodifica señales de datos digitales.

El códec H266 / VVC utiliza aproximadamente la mitad de los datos para transmitir videos 4K. Y se reconoce como la solución de codificación más eficiente para el futuro 4K e incluso 4K VR streaming en tiempo real.

¿Cómo se hizo este descubrimiento? Fue hecho por personas que usan Agile para resolver problemas de compresión de video.

Específicamente, se hizo porque a las personas se les dio libertad para construir, probar, experimentar e innovar durante un período de tiempo. No se les dijo que construyeran la cocina desde cero y regresaran en seis meses.

Tomaron pequeños pasos en la dirección correcta. Este resultado es instructivo.

Aquí hay un segundo ejemplo: cuando Lastpass fue adquirido por LogMeIn, LogMeIn estaba tan interesado en la tecnología como en la cultura del diseño que Lastpass había implementado para construir productos.

¿Qué tipo de cultura era esa? Uno que priorizó Agile.

Agile no solo lleva los productos al mercado más rápido, sino que crea resultados creativos y sinérgicos que son valiosos.

La creación de valor está incrustada en la cultura de Agile.

Principio #2: Trabajar software sobre documentación completa

Este debería ser obvio por ahora. En lugar de especificaciones detalladas y planificación, simplemente escriba algunas líneas de código que funcionen.

Pruébalo. Obten comentarios sobre él. Envialo.

Después, hazlo de nuevo.

Repite.

Un ejemplo muy relevante de este proceso de repetición se encuentra en "Forms on Fire".

Crearon un software para facilitar la recopilación de datos móviles. No escribieron toda su empresa antes del lanzamiento; escribieron algunas líneas de código, lo probaron y lo enviaron.

A medida que adquirieron impulso, aceleraron sus pruebas y pasos iterativos.

Y repitieron lo que funcionó y arrojaron lo que no. Los resultados hablan por sí mismos.

Principio #3: Colaboración del cliente sobre la negociación del contrato

Agile promueve un ciclo de retroalimentación rápida para obtener comentarios de clientes y del accionista.

¿Qué podría ser mejor que trabajar al revés de lo que los usuarios y clientes reales quieren?

Tengo un mentor de negocios que aconsejó que en lugar de sobre-analizar lo que los clientes quieren a través de una planificación sin fin, simplemente mantenerlo simple. "Mitigar las distracciones", dijo.

He escrito sobre el principio KISS en freeCodeCamp y ese consejo ciertamente es cierto en Agile: construye algo pequeño y ver si tus clientes les gusta.

Si les gusta, sigue adelante.

Principio # 4: Responder al cambio sobre el seguimiento de un plan

Los bucles de retroalimentación rápida generan cambios y ajustes rápidos. Esto es lo que hace que Agile sea tan bueno para los equipos de desarrollo.

Esta es la razón por la que debes abrazarlo.

Las hojas de ruta siempre cambian, esta es una constante conocida. Utilizando metodologías ágiles, los equipos pueden responder al cambio escuchando los comentarios de los clientes y haciendo los ajustes necesarios.

Hay momentos en que responder al cambio significa ajustar su producto o cambiar la forma en que piensa acerca de los usuarios o la competencia.

Un ejemplo clásico que los estudiantes ágiles pueden ver en el espacio de comercio electrónico es la venta en Amazon. ¿Cómo se adapta rápidamente a la competencia? Una forma es construir comunidades cerradas o probar diferentes estrategias de lanzamiento de productos.

Es aconsejable implementar soluciones tácticas y maleables.

Hay un maravilloso proverbio: "No podemos cambiar la dirección del viento. Solo podemos ajustar nuestras velas.”

Cuando pienso en Agile, pienso en este dicho.

Ágil es sobre el aprendizaje, Ágil es sobre la enseñanza. Ágil se trata de flexibilidad.

Puedes practicar Agile en tu trabajo diario o tomar cursos en línea para seguir desarrollándote.

Algunas personas son lo suficientemente inteligentes como para predecir lo que quiere su cliente. Ellos saben de qué manera sopla el viento.

Pero para nosotros los mortales, Agile es una metodología para navegar alrededor de nuestras deficiencias en la comprensión de lo que los clientes quieren.

Es el sistema que nos permite ajustar constantemente nuestras velas.

Traducido del artículo de Adam Naor - Agile Methods and Methodology for Beginners – Agile Software Development and Agile Project Management Examples