Las técnicas ágiles llevan a los desarrolladores de software a entregar valor en incrementos pequeños e implementar una retroalimentación continua. 

 

Ágil se define como un enfoque de desarrollo de software iterativo donde el valor se le da a los usuarios en pequeños incrementos en vez de hacerlo en un lanzamiento grande. Los equipos ágiles evalúan los requisitos y los resultados continuamente, lo que lleva a una implementación de cambio eficiente. Este artículo cubre el significado de, ciclo de vida, metodología y algunos ejemplos de Agile. 

 

¿Qué es el Desarrollo Ágil de Software ?

 

Las metodologías de desarrollo de software ágil que a menudo son llamadas Agile, predican la flexibilidad y pragmatismo en el proceso de entrega de aplicación. Este enfoque iterativo de desarrollo de software ofrece el valor a los usuarios en incrementos pequeños en vez de lanzamientos tan grandes. Los equipos ágiles evalúan continuamente los requisitos y resultados, lo que da pie a la implementación eficiente del cambio.

 

El uso de Agile le da a los equipos la habilidad de crear valor frente a un mercado dinámico y de una competencia muy acelerada mientras que se mantiene la eficiencia y la rapidez. Un principio fundamental de Agile es la creación de una cultura de trabajo colaborativa ya que le permite a los equipos trabajar conjuntamente con un mayor entendimiento de los roles individuales dentro del sistema. 

 

Agile también establece las pruebas en todo el proceso del ciclo de desarrollo. Esto le permite a los equipos hacer cambios cuando sea necesario, alertar entre sí sobre potenciales problemas y por ende les da la suficiente confianza para crear y lanzar aplicaciones de muy alta calidad.

 

Los valores fundamentales de Agile se encuentran en el Manifesto Agile, que fue creado en 2001 por un grupo de personas de desarrollo de software. Este manifiesto resalta los 4 conceptos más importantes que promueven el desarrollo ligero, a continuación se muestran. 

 

• Darle más prioridad a las personas sobre las herramientas y procesos. Mientras estos últimos son muy esenciales, las interacciones individuales son significativas y vitales en el proceso de desarrollo de software, también ayudan a crear una respuesta a las necesidades empresariales de manera efectiva. 
• Una aplicación muy bien construida antes que la documentación en detalle. Agile no elimina toda la documentación recolectada, sino que se enfoca mucho más en darle al equipo de desarrollo la información necesaria que es requerida para cumplir los objetivos, así como las historias de usuario.
• Se sustituyen las negociaciones de contrato del gerente de proyectos y el cliente por una colaboración que sea frecuente. El producto puede tomar forma de acuerdo a la visión del cliente de manera efectiva si se involucran en todo el proceso de desarrollo y no solamente al comienzo y al final. 
• Responder al cambio de manera rápida y eficaz. Agile descarta la idea del cambio como un costo no deseado. En su lugar, le da valor al cambio y promueve las iteraciones cortas para permitir que las modificaciones se hagan de manera fácil y rápida.

 

Además de estos valores que son tan importantes, el Manifesto Agile también resalta 12 principios para los equipos de desarrollo que pueden mejorar su funcionamiento:

 

1. Dividir las tareas más grandes en pequeñas piezas para una mejor realización.
2. Se enfoca en la satisfacción del cliente a través de la entrega rápida y continua de valor. 
3. Asegura la creación de procesos que llevan a un impulso de esfuerzo sostenible.
4. Acepta los requisitos de cambios, aunque se agreguen en una etapa más avanzada del proyecto. 
5. Toma el cambio como un medio para lograr una ventaja 
6. Le ofrece a los miembros motivados del equipo el entorno de trabajo y la confianza necesarios para completar los requisitos con rapidez.
7. Reconoce que los equipos autoorganizados realizan el mejor trabajo
8. Mide el progreso en función del trabajo realizado
9. Completa el trabajo a un ritmo constante
10. Garantiza la colaboración regular entre los equipos de proyecto y de negocio a lo largo de la duración del proyecto
11. Reflexiona periódicamente sobre cómo se puede ajustar el comportamiento del equipo para mejorar su eficacia.
12. Por último, busca constantemente la excelencia.

 

Implementar Agile requiere de un cambio en la cultura tradicional de las empresas, ya que impulsa la entrega limpia de componentes aislados en lugar de una aplicación completa de una sola vez. Al día de hoy, Agile ha reemplazado el modelo de desarrollo de software Waterfall en la mayoría de las empresas. Sin embargo, podría ser fusionado o reemplazado a medida que el último crece en popularidad mundialmente. 

 

Ciclo de vida del desarrollo de software ágil

 

En el ciclo de vida ágil, los desarrolladores pasan estratégicamente de la conceptualización a la salida de la aplicación.

Ciclo de vida del desarrollo de software ágil 

 

A continuación se encuentran los pasos de este ciclo:

 

1. Conceptualización

 

En el primer paso del ciclo de vida ágil, el product owner define el alcance del proyecto. En el caso de múltiples proyectos, los más críticos son lo que se priorizan. Dependiendo de la estructura de la organización, el personal puede ser asignado a más de un proyecto a la vez.

 

En esta fase  el product owner y el cliente discuten los requerimientos esenciales y formular la documentación básica  que se basa en los objetivos delvproyecto finalizado. Esta documentación, en la forma de un documento de requerimientos de producto (PRD), incluirá el principal objetivo del proyecto y las características o funciones soportadas. También en esta etapa se estima el ttiempo y el costo del proyecto.

 

El análisis a profundidad que se lleva a cabo durante la conceptualización ayuda a determinar la factibilidad antes de que el trabajo comience. Los desarrolladores pueden apostar a completar los requisitos más críticos ya que pueden irse agregando muchas más etapas.

 

2. Creación 

 

Una vez el proyecto sea conceptualizado, el siguiente paso es construir el equipo de desarrollo de software. En esta etapa, el product owner verifica la disponibilidad de cada integrante del equipo y asigna a los mejores al proyecto. El product owner se responsabiliza de darle a los integrantes los recursos adecuados.

 

Una vez el equipo se complete, el proceso de diseño comenzará y se crea una maqueta de la interfaz de usuario y, quizás, algunos diagramas de flujo de usuario y UML. En esta fase también se construye la arquitectura del proyecto. Luego, los elementos diseñados se muestran a las partes interesadas para que hagan sus aportaciones.

 

Todo esto lleva al equipo a establecer completamente los requerimientos del diseño y ver la funcionalidad de la aplicación y cómo encaja en el sistema existente. Las comprobaciones frecuentes del equipo de empresas garantizarán que la creación se mantenga en marcha.

 

3. Construcción

 

En la fase de construcción, más conocida como fase de iteración, es dónde básicamente se hace todo el trabajo. Normalmente es la etapa con más duración, con el equipo Dev (desarrolladores) y los diseñadores UX, se trabaja en colaborativo para llevar a cabo todos los requerimientos, retroalimentación y la interpretación del diseño en código.

 

La meta de construcción es crear la funcionalidad básica de las aplicaciones antes de que la primera iteración (o ‘sprint’) termine. Funciones secundarias adicionales y modificaciones menores pueden ocurrir en iteraciones futuras. El objetivo principal es crear una aplicación funcional e implementar todas las mejoras para la satisfacción del cliente. 

 

4. Lanzamiento

 

Cuando el equipo trabaja en esta etapa, el producto ya debería estar casi listo para su lanzamiento. Sin embargo, antes de que esto pase, el equipo de control de calidad (QA) deberá probar la aplicación para asegurarse de que sea totalmente funcional de acuerdo a lo que se propuso en los objetivos del proyecto. La prueba también se hace con el fin de estar seguros de que no haya ningún defecto ni bug en el código; si se llega a encontrar alguno, tendrá que ser reportado y arreglado rápidamente por el equipo de desarrolladores. El código limpio es una muy esencial en esta etapa

 

Esta fase también incluye el entrenamiento de usuario, la creación del sistema y  la documentación del usuario para apoyarse. Visualizar el código en esta parte es esencial. Una vez los defectos hayan sido corregidos y el entrenamiento de usuario se complete, la iteración final del producto puede tomarse y ser enviada para producción.

 

5. Producción y mantenimiento

 

Una vez la aplicación se lance de manera efectiva y esté disponible para los usuarios, el equipo pasa a modo de mantenimiento. En esta fase el equipo de desarrolladores proporciona soporte continuo para asegurarse de que todo vaya perfecto en las operaciones del sistema y puedan arreglarse todo tipo de bugs y defectos

 

El equipo también estará al pendiente de ofrecer entrenamiento adicional a los clientes y resolver todo tipo de dudas para asegurarse de que el producto se utilice de manera adecuada. Los desarrolladores también pueden utilizar la retroalimentación recolectada durante esta etapa para planificar diferentes funciones para las siguientes iteraciones.

 

6. Retiro

 

La aplicación puede estar destinada a retirarse por dos razones: la sustitución por una nueva versión o la falta de un caso de uso debido a la redundancia.

 

Si la aplicación no se encuentra en esta fase, el primer paso es notificarle a los usuarios sobre el retiro de la aplicación. Luego, se deberá asegurar una migración más fluida del sistema. Finalmente, el equipo de desarrolladores deberá completar todas las actividades pendientes y cerrar todo lo relacionado con el soporte que se proporciona a la aplicación existente.

 

Planificación de los sprints en Agile

 

Cada fase ágil que se resalta anteriormente conlleva a la creación de numerosas iteraciones de software. Estas iteraciones se crean conforme el equipo de desarrolladores repite los procesos para pulir la aplicación y crear la mejor versión de acuerdo a los requerimientos determinados del proyecto. Éstas son ‘sub ciclos’ que  están contenidos entre el largo ciclo de vida ágil de desarrollo de software.

 

El ciclo de vida ágil divide el trabajo en “sprints” para completar estas iteraciones. El objetivo de cada sprint es producir una aplicación que funcione. Un sprint típico debería durar 10 días laborables (2 semanas).

 

A continuación se ve el flujo de trabajo en un sprint típico:

 

1. Planear: Cada ‘sprint’ comienza con una reunión de ‘planificación de sprint’ en el los integrantes de un equipo se reúnen y deciden que objetivos o metas deberían tratarse a lo largo del trabajo. Durante la reunión, el gerente de proyectos debería priorizar los trabajos que se encuentran pendientes y asignar tareas a personas específicas.
2. Desarrollar: Una vez se lleve a cabo el plan, este equipo trabaja en el diseño y desarrollo de acuerdo a lo que se establezca.
3. Pruebas de calidad: Luego de que la aplicación haya sido desarrollada, el equipo de control de calidad se encarga de probarlo minuciosamente, lleva a cabo todas las correcciones de cualquier error o imprevistos, y documenta los resultados.
4. Entrega: Luego de la prueba, la aplicación está lista para su lanzamiento y se presenta a todos los stakeholders y clientes relevantes.
5. Valorar: Luego de la entrega, la retroalimentación que se recolecta de los clientes y se combina con toda la información relevante para la implementación del siguiente sprint. 

 

Las reuniones de planificación del sprint son útiles, pero el equipo también debería reunirse regularmente (si es posible, a diario) para hacer un balance del progreso del sprint y resolver cualquier conflicto. La colaboración y la receptividad al cambio son componentes clave del ciclo de vida ágil y una forma probada de mantener el proceso en marcha de forma eficaz.

 

Metodologías ágiles de desarrollo de software

 

El desarrollo ágil de software no es un marco de metodologías singular. En cambio, abarca numerosos marcos de gestión de proyectos.

 

A continuación se explican cuatro metodologías ágiles muy conocidas:

 

1. Scrum

 

Scrum puede ser la metodología de gestión de proyectos ágiles más popular. La definen los sprints, y aboga por maximizar el tiempo de desarrollo de la aplicación y alcanzar el objetivo del producto. Esta meta es un objetivo de valor a gran escala que se acerca a la realización con cada sprint. 

 

Un equipo que sigue la metodología Scrum comienza su jornada con una reunión de 15 minutos para sincronizar todas las actividades y trazar el mejor camino para el día siguiente. El jefe de producto puede aprovechar esta oportunidad para comprobar la “salud” del sprint y el progreso del proyecto.

 

Aunque Scrum se asocia popularmente con el desarrollo de software, se puede utilizar con éxito en la mayoría de los contextos empresariales.

 

Ventajas de Scrum

Desventajas de Scrum

Fuerte planificación, con todo el equipo entendiendo el “qué, por qué, cómo” de las tareas asignadas Alta motivación, ya que el equipo trabaja para cumplir los plazos de cada sprint Alta transparencia que permite el seguimiento del proyecto a nivel de equipo e incluso de organización Valida los requisitos mediante un método sencillo de “definición de lo hecho”. Se centra en garantizar la calidad y minimizar los errores Prioriza lo flexible, ya que los propietarios del producto pueden cambiar el enfoque a sprints urgentes con frecuencia.

Una gran concentración en partes específicas del proyecto puede hacer que el equipo pierda de vista el panorama general Las organizaciones pueden no definir con detalle el papel de cada miembro, lo que puede generar confusión.

 

2. Kanban

 

El término Kanban tiene origen japonés y se asocia con el concepto de “justo a tiempo”. Este método divide un “tablero Kanban” (tablero o mesa) en columnas. Cada flujo dentro del proyecto se muestra en las columnas como una “tarjeta”, y la información cambia a medida que se avanza. Se añade una nueva tarjeta cada vez que se introduce una nueva tarea. 

 

Kanban impulsa la transparencia y la comunicación al permitir que los miembros de todos los equipos vean el estado del proyecto en cualquier momento. Su objetivo principal es la capacidad del equipo, lo que es especialmente útil para las iteraciones con múltiples cambios menores. Además del desarrollo de software, Kanban es útil para los departamentos de negocio como RRHH y marketing, ya que impulsa la visibilidad de todas las tareas del equipo.

 

Ventajas de Kanban	Desventajas de  Kanban
Fácil de usar Ve todas las tareas de un proyecto al mismo tiempo, según su categoría (realizadas, en proceso, en pruebas, etc.) Controla el número de tareas en las que se trabaja en función de la prioridad Una duración transparente del ciclo: desde la cartera de pedidos hasta la finalización Impulsa la entrega continua	La falta de plazos puede provocar retrasos Los datos pueden ser malinterpretados, especialmente si no se actualizan con frecuencia

 

3. Extreme Programming (XP)

 

Este típico marco de trabajo ágil se enfoca en el descubrimiento de “de la manera más fácil se puede lograr” mientras se le va quitando prioridad al objetivo del producto a largo plazo. Dentro de sus valores fundamentales, se encuentra la simplicidad, la comunicación, ánimo, el respeto y la retroalimentación. La prioridad número uno de XP es la satisfacción del cliente, y esto fomenta a que el equipo acepte cambios en requisitos de proyectos incluso en las etapas avanzadas del proceso de desarrollo.

 

El trabajo en equipo es también un componente clave de XP, con clientes, gerentes y miembros del equipo trabajando estrechamente para asegurar la creación eficiente de la mejor aplicación posible. En XP, las pruebas tienen lugar desde el primer día, y se recogen continuamente los comentarios para mejorar la calidad. En esta metodología de ingeniería se fomentan actividades como la programación por parejas.

 

Ventajas de  XP	Desventajas de  XP
Código simplificado que se puede mejorar en iteraciones posteriores Un ciclo de desarrollo transparente y una gran visibilidad del proceso conducen a una fijación de objetivos eficiente y a resultados rápidos Gran agilidad de desarrollo gracias a las pruebas continuas Fomenta el trabajo enérgico y fomenta el talento	La gran atención que se presta al código puede hacer que se preste menos atención al diseño, convirtiéndolo en una tarea separada en lugar de formar parte de los requisitos originales La falta de atención a la documentación de las pruebas puede hacer que se repitan errores similares No es ideal para los equipos que trabajan a distancia

4. Desarrollo Lean

 

Se adapta directamente de Lean Manufacturing de Toyota; este método de desarrollo de software lleva al equipo a descartar cualquier actividad que no le agregue valor al producto. 

 

Sus siete principios fundamentales son:

1. Eliminar sin ninguna consideración todo lo que no importa para la calidad del producto
2. Centrarse en el desarrollo de la calidad
3. Crear conocimiento a través de una valiosa documentación
4. No planificar el desarrollo sin una comprensión completa de los requisitos del negocio
5. Ofrecer valor al cliente lo antes posible
6. Se comunica con regularidad, gestiona los conflictos con rapidez y desarrolla una cultura de respeto
7. Por último, no se centra en la optimización parcial y se asegura de que toda la aplicación sea de alta calidad

Ventajas de Lean	Desventajas de Lean
Minimiza el tiempo y el dinero invertido Aumenta la motivación al informar al equipo durante el proceso de toma de decisiones Muy adaptable y escalable Minimiza el riesgo de sobre ingeniería	Depende en gran medida de miembros del equipo dedicados y con talento La división de las tareas en subtareas puede dificultar la concentración. Es relativamente pesado en cuanto a la documentación.

 

Ejemplos de Desarrollo de Software Ágil

 

¿Cómo funciona Agile en el mundo real? Veremos un ejemplo del desarrollo de software tradicional utilizando la metodología de cascada contra el desarrollo de software ágil. 

 

Escenario
Una aplicación en específico con muchos requisitos de funciones avanzadas que debe estar lista para la venta en 8 meses.
Tradicional (Waterfall)	Agile
El equipo dedicaría el 15% del tiempo del proyecto (unas cinco semanas) a recopilar y analizar los requisitos. Diseñar un esquema básico pero preciso de todas las funciones de la aplicación supondría un 20% del tiempo del proyecto (unas 6,5 semanas). Traducir el diseño en código y probarlo llevaría aproximadamente el 40% del tiempo del proyecto (13 semanas). Las pruebas de integración y del sistema supondrían un 20% del tiempo del proyecto (otras 6,5 semanas). Los desarrolladores dedicarían el tiempo restante a las pruebas de aceptación por parte del equipo de marketing.	En Agile, el proyecto se divide en numerosas iteraciones, todas ellas de la misma duración (entre 2 y 8 semanas). El equipo entrega una aplicación que funciona al final de cada iteración. Para este ejemplo, supongamos que el proyecto se divide en ocho entregas de 4 semanas cada una. En lugar de pasar cinco semanas recopilando y analizando los requisitos, los equipos de negocio y de desarrollo trabajarán juntos para determinar las características esenciales que se necesitan al final de la primera iteración (o sprint). El equipo entregará una aplicación funcional con las características predeterminadas al final del primer sprint. Una vez que la aplicación esté lista, los equipos determinarán en colaboración si la aplicación va en la dirección correcta. También decidirán qué cambios se pueden hacer y qué características se pueden añadir en las siguientes iteraciones en función de la prioridad. Esta metodología permite al equipo de marketing mostrar al cliente una aplicación en funcionamiento en tan solo cuatro semanas (en lugar de 8 meses). Los comentarios pueden recogerse y transmitirse a los desarrolladores, que los aplicarán en futuras iteraciones.

 

En el ejemplo con la metodología tradicional de cascada, el cliente llega a experimentar el producto realmente sólo después de 8 meses cuando el proceso se completa. Además, si se ve la necesidad de hacer cambios significativos, los desarrolladores deben mover la fecha de lanzamiento por un par de semanas más. 

 

Está claro por qué Agile es muchísimo más efectivo que Waterfall. En el ejemplo de Agile, con el pasar de los 8 meses, no sólo la aplicación quedará listo sino también se encontrará en un estado de uso pleno y perfecto que si fuera producido con el método cascada. 

 

Takeaway – Para llevar

 

Agile fomenta la entrega continua y prioriza la satisfacción del cliente. Esta metodología de desarrollo de software ofrece una aplicación con funciones y características nuevas cada varias semanas. Los clientes pueden tener la experiencia de la última iteración de la aplicación y pueden dar su feedback sobre ello, lo que luego es procesado por el equipo de desarrollo para futuras iteraciones.

 

La colaboración frecuente entre las empresas y los equipos de desarrollo es un aspecto muy importante de Agile. Todos los stakeholders están al tanto de los progresos de un proyecto y mejorar los requisitos, para poder garantizar la entrega eficiente de un producto de alta calidad al final de cada Sprint. 

 

Aunque Agile ya ha reemplazado el modelo de cascada en la mayoría de las empresas, puede que sea obsoleto, o combinado con DevOps, debido a la creciente popularidad de esta última disciplina.

 

Tomado de la web:

Traducido al español por Devops Latam.

Contribuido por by Hossein Ashtari Technical Writer – Sep 29, 2022, – https://www.forbes.com/sites/forbesbusinesscouncil/2022/09/19/how-to-make-scrum-work-for-startups/?sh=5101edf875e3