Métodos y metodología ágiles para principiantes: desarrollo de software ágil y ejemplos de gestión de proyectos ágiles

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 comentarios sobre su producto continuamente.

Agile 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 sobre la negociación del contrato
  4. Responde al cambio sobre el siguiente plan

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

Cascada

El desarrollo en cascada es un enfoque muy lineal para la construcción de un producto. Tiene poco o ningún espacio para comentarios o iteraciones hasta que el producto esté completamente construido y probado.

Así es como funciona: los equipos pasan semanas (ya 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 armarán un documento masivo que describa los requisitos del producto con extremo detalle.

Por decir lo mínimo, se trata de un proceso largo y laborioso en el que, inevitablemente, se pasan por alto algunas cosas.

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

Ahora intente imaginarse el documento de requisitos para estos productos.

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

Si ha creado un producto, ya sea como constructor en solitario o como miembro de un equipo, es probable que pueda identificarse con esta afirmación.

Cuando todo está acordado, las especificaciones se entregan al equipo de ingeniería, que luego construye el producto según las especificaciones, aprovecha los datos e insumos cualitativos y cuantitativos.

Cuando todo está codificado, comienza la prueba.

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

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

Falta de mecanismos de retroalimentación integrados

¿Qué pasa si el equipo de desarrollo sigue las especificaciones exactamente y resulta que verlo cobrar vida no es tan convincente como el equipo de producto pensó que era? O peor aún, ¿y si hubiera un error en el documento de especificaciones?

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

El desarrollo de productos puede generar grandes costes fijos. Si el producto no funciona, estos costos pueden convertirse en costos irrecuperables.

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

¿Y si cambia la hoja de ruta?

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

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

Nuevamente, si no puede convertir sus costos fijos en algo flexible, se quedará con una gran factura y no tendrá mucho que mostrar.

Todo el trabajo dedicado, los plazos estresantes, el calendario de la pizarra y las altas horas de la noche no conducirán a los resultados que deseaba al comienzo del proyecto.

El producto acumula 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 en cascada espera entregar el producto completo hasta el final.

Si bien este es un enfoque razonable para construir un automóvil, 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 producidos a medias. Pero usamos software a medio construir todo el tiempo.

Entrar ágil

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

Con el empleo de métodos ágiles, los equipos envían de forma constante y predecible pequeños fragmentos de código a producción a un ritmo rápido.

Una vez que han completado cualquier tipo de función que agregue valor, la prueban y la lanzan 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 con el tiempo.

Esto significa que las pruebas son más rápidas, ya que solo está probando la compatibilidad del código más reciente. 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.

Considere ambos enfoques para un ejemplo real de remodelación de una cocina. Digamos que llevará seis meses hacer bien el trabajo de remodelación.

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

Si bien el trabajo se realiza en la misma cantidad de tiempo, el propietario se queda en la oscuridad. Preguntas simples como cómo va todo quedan sin respuesta. Lo peor de todo es que los propietarios no pueden utilizar ninguna parte de la cocina hasta el final.

Con Agile, el contratista, en cambio, averiguaría qué podría hacer su equipo cada pocas semanas y luego permitiría que su cliente lo viera y lo usara mientras remodelaban el resto.

Tal vez puedan reemplazar los gabinetes en el primer mes, las encimeras en el segundo mes y para el tercer mes instalen un refrigerador y una estufa nuevos. ¡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 se quede ahí y acumule polvo, en realidad se está utilizando tan pronto como se puede usar.

¿Y tal vez el dueño de la cocina quiere cambiar un gabinete por un estante?  

El contratista ahora puede al menos planificar ese cambio antes de que pasen los seis meses y dejarle saber al propietario cómo afectará el cronograma del proyecto.

Aparentemente, ambas partes pueden trabajar juntas y comunicarse de manera transparente para garantizar que se realicen los resultados y el trabajo correctos.

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

Intente seguir adelante con esta lección mientras aprende nuevas habilidades de desarrollo en freeCodeCamp y aplica sus 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 el mundo real y digital.

A estas alturas espero que pueda ver cómo estos principios son un asalto directo al proceso en 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, valorar a las personas y las interacciones sobre las herramientas permite una mayor creación y producción de valor.

Los miembros individuales del equipo pueden innovar.

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

Parte de colocar a las personas sobre las herramientas es experimentar 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 de computadora que codifica o decodifica un flujo de datos digitales o señales.

El códec H266 / VVC usa aproximadamente la mitad de los datos para transmitir videos 4K. Y es reconocida como la solución de codificación más eficiente para la futura transmisión en tiempo real 4K e incluso 4K VR.

¿Cómo se hizo este descubrimiento? Fue creado por personas que usaban 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 les dijeron que construyeran la cocina desde cero y volvieran en seis meses.

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

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

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

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

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

Principio n. ° 2: software de trabajo sobre documentación completa

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

Pruébalo. Obtenga comentarios al respecto. Envíalo.

Luego, hazlo de nuevo.

Repetir.

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 de lanzarla; escribieron algunas líneas de código, lo probaron y lo enviaron.

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

Y repitieron lo que funcionó y tiraron lo que no funcionó. los resultados hablan por si mismos.

Principio n. ° 3: colaboración con el cliente sobre la negociación del contrato

Agile promueve un ciclo de retroalimentación rápido para obtener retroalimentación de los clientes y las partes interesadas.

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

Tengo un mentor de negocios que me aconsejó que, en lugar de analizar demasiado lo que quieren los clientes mediante una planificación interminable, simplemente manténgalo simple. "Mitigar las distracciones", dijo.

He escrito sobre el principio KISS en freeCodeCamp y ese consejo ciertamente es cierto en Agile: construya algo pequeño y vea si a sus clientes les gusta.

Si lo hacen, continúe.

Principio n. ° 4: responder al cambio en lugar de seguir un plan

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

Es por eso que debes abrazarlo.

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

Hay ocasiones en las que responder al cambio significa ajustar su producto o cambiar su forma de pensar sobre los usuarios o la competencia.

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

Es aconsejable desplegar soluciones tácticas y maleables.

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

Cuando pienso en Agile, pienso en este dicho.

Agile se trata de aprender, Agile se trata de enseñar. Agile se trata de flexibilidad.

Puedes practicar Agile en tu trabajo diario o tomar cursos online para desarrollarte más.

Algunas personas son lo suficientemente inteligentes como para predecir lo que quiere su cliente. Saben en qué dirección sopla el viento.

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

Es el sistema que nos permite ajustar constantemente nuestras velas.