¿Qué tiene de bueno Agile? Una cartilla sobre metodología ágil
Ágil Defínalo como sistemas de gestión ágil que han existido durante un tiempo, pero que han ganado vigencia en los últimos tiempos. De hecho, Agile Management se presenta constantemente en las principales tendencias de gestión de proyectos de casi todos los blogs de gestión de proyectos de TI cada año.
Las aplicaciones de Agile en proyectos basados en TI son indiscutibles, ya que encuentran uso no solo en proyectos de software de TI, sino también en el desarrollo de productos y la innovación.
Entonces, ¿qué tiene de bueno Agile? Pregunte a los empleados que se han mudado de un sistema tradicional a Agile, y podrían lamentarse de las reuniones constantes y "reuniones sobre reuniones".
Resulta que Agile tiene mucho más que solo reuniones y comentarios. Se enfoca en empoderar a los equipos y eliminar formas secuenciales de desarrollo de proyectos, para que haya más flexibilidad e innovación. Si bien eso significa reuniones y entregas más frecuentes que con los sistemas tradicionales, también significa que hay una menor probabilidad de iteraciones y cambios posteriores en el ciclo del proyecto.
Se promociona como la cura para todos los problemas comunes que afectan a los proyectos relacionados con TI. ¿Qué es exactamente y cómo es mejor que los sistemas tradicionales?
Necesidad de una metodología ágil: prácticas de gestión
Cualquiera que haya trabajado en una metodología ágil en proyectos de desarrollo de software tendrá una idea de algunos de los problemas habituales que surgen durante un proyecto: cambio de alcance, plazos que parecen imposibles de cumplir y recursos con exceso de trabajo.
Las metodologías ágiles tradicionales en la gestión de proyectos tuvieron muchos inconvenientes debido a que no pudieron hacer frente al entorno empresarial en constante cambio, especialmente en el desarrollo de software, y las situaciones anteriores fueron, por desgracia, demasiado comunes. Esto no quiere decir que los métodos tradicionales no sean aplicables en ninguna parte. Siguen siendo la mejor apuesta para proyectos en los que la idea está completamente formada desde el principio.
Las prácticas de gestión ágil se convirtieron en la necesidad de la hora porque satisfacían las siguientes necesidades de un producto lanzado en un entorno dinámico:
- Necesidad de velocidad para llegar al producto al mercado
- Necesidad de flexibilidad para acomodar múltiples cambios en las especificaciones
- Defectos en el escenario de 'división del trabajo'
- Dilema del cliente
- Necesidad de reducción de costos
Necesidad de velocidad para llegar al producto al mercado:
Vivimos en un entorno de ritmo rápido donde la flexibilidad y la velocidad son clave para el éxito.
La tecnología es uno de los sectores que cambia más rápido en la industria. Hay una nueva idea, producto o innovación cada minuto. En este contexto, el enfoque tradicional de gestión de proyectos no se cumple. Un proyecto secuencial depende necesariamente de que los pasos de la metodología ágil se completen satisfactoriamente en orden. Las líneas de tiempo en los proyectos gestionados tradicionalmente son siempre motivo de controversia.
Las organizaciones y los equipos que no son dinámicos perderán la carrera ante aquellos que se transforman para adaptarse al entorno cambiante.
Necesidad de flexibilidad para acomodar múltiples cambios en las especificaciones:
Las expectativas y requisitos del cliente a menudo cambian en el transcurso del desarrollo del producto. Antes de que los Sistemas de Gestión Ágil fueran convencionales, los proyectos en TI fallaban a menudo porque el sistema tradicional de gestión de proyectos se creó para "continuar". Si hubo algún cambio, los clientes a menudo sintieron el pellizco en sus billeteras o líneas de tiempo. El modelo tradicional de gestión de proyectos, adaptado de otras industrias, simplemente no funcionaba para una industria dinámica como la TI.
Division de trabajo:
En el modelo tradicional, hay fases distintas, que comienzan con el análisis de los requisitos del sistema y conducen al lanzamiento y mantenimiento del producto. Esto da como resultado la división del trabajo y el etiquetado de los miembros como 'diseñadores', 'programadores' o 'probadores'. Pero en realidad, los recursos actuales son extremadamente interfuncionales y tal distinción clara de roles no es factible en la mayoría de los proyectos.
Dilema del cliente:
En proyectos volátiles, muy a menudo, los clientes no están completamente seguros de cuál debe ser su producto final, con todas las especificaciones. Las funcionalidades y los requisitos a menudo cambian a medida que se realizan los trabajos. Los modelos tradicionales como el modelo Waterfall enfatizan la claridad con respecto al producto final, y las desviaciones en los planes ejercen una gran presión sobre el sistema. Esto nos lleva al último factor que condujo al desarrollo de sistemas ágiles.
Necesidad de reducción en el costo:
Tradicionalmente, se desaconsejaban los cambios en los requisitos en cualquier momento después del inicio del proyecto. Más bien, los costos para cualquier componente adicional eran altos, a veces de manera prohibitiva. Por lo tanto, era imperativo incluir todos los escenarios posibles en la etapa de planificación misma. Esto significó que se consideraron todos los escenarios y se propuso una solución. Pero como es casi imposible saber con certeza qué parte del producto preferirá el usuario, los equipos a menudo desarrollaron "versiones hinchadas" de un producto. Esto contenía todos los escenarios posibles, de los cuales un usuario típico usaría no más del 20%. Esto resultó en costos y desarrollo innecesarios.
No hace falta decir que esto significaba que todos los proyectos eran globales en su planificación.
Y cuando surgió un escenario no planificado completamente nuevo, hubo un costo adicional de todos modos, a pesar de toda la planificación.
Un grupo de personas se reunió en febrero de 2001 para discutir exactamente esto: la necesidad de un modelo de desarrollo de software flexible y ágil que ayudara a desarrollar productos que realmente funcionaran para el cliente y el desarrollador. El resultado fue el "Manifiesto Ágil", que fue el beneficio del desarrollo de software de metodología ágil, es decir, un conjunto de cuatro principios que son tan simples como descriptivos. También se desarrollaron doce "principios ágiles" que explican cómo los sistemas ágiles realmente funcionarían en un entorno de proyecto.
A través de este trabajo hemos llegado a valorar:
- Individuos e interacciones sobre procesos y herramientas
- Software de trabajo sobre documentación completa
- Colaboración del cliente sobre negociación de contrato
- Responde al cambio sobre el siguiente plan
Es decir, si bien hay valor en los elementos de la derecha, valoramos más los elementos de la izquierda.
Los 12 principios ágiles
Los 12 Principios Ágiles son un conjunto de conceptos rectores detrás del Manifiesto Ágil que apoyan a los equipos de proyecto en la implementación de Proyectos Ágiles. Son:
- Nuestra máxima prioridad es satisfacer al cliente a través de la entrega temprana y continua de software valioso.
- Acogiendo con beneplácito los requisitos cambiantes, incluso en la etapa de desarrollo tardío. La metodología ágil procesa el cambio de arnés para la ventaja competitiva del cliente.
- Entregue software de trabajo con frecuencia, desde un par de semanas hasta un par de meses, con preferencia a la escala de tiempo más corta.
- La gente de negocios y los desarrolladores deben trabajar juntos a diario durante todo el proyecto.
- Desarrollar proyectos en torno a personas motivadas. Bríndeles el entorno y el apoyo que necesitan, y confíe en ellos para hacer el trabajo.
- El método más eficiente y efectivo para transmitir información a un equipo de desarrollo y dentro de él es la conversación cara a cara.
- El software de trabajo es la medida principal del progreso.
- Los procesos de metodología ágil promueven el desarrollo sostenible. Los patrocinadores, desarrolladores y usuarios deberían poder mantener un ritmo constante indefinidamente.
- La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.
- La simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial.
- Las mejores arquitecturas, requisitos y diseños surgen de equipos autoorganizados.
- A intervalos regulares, el equipo reflexiona sobre cómo ser más eficaz, luego ajusta y ajusta su comportamiento en consecuencia.
Ejemplo de un proyecto que necesita una gestión ágil
Imagine una startup que desarrolla una aplicación móvil para un cliente. Congelar todo el diseño de la aplicación antes de que comience el desarrollo puede ser desastroso. También hay un tiempo limitado para realizar la encuesta de mercado, trazar un plan detallado, decidir sobre las variantes que desean ofrecer y luego desarrollar el producto. Además del enorme costo involucrado en este enfoque, corren el riesgo de que alguna otra compañía desarrolle la aplicación antes que ellos.
La metodología ágil en la gestión de proyectos ayuda a superar estos problemas. Bajo este sistema, la aplicación se desarrolla en etapas, con interacción con el cliente todos los días y entregables o hitos del proyecto identificados, por ejemplo, para cada semana.
Varios equipos también pueden trabajar en la misma aplicación, por lo que el tiempo de desarrollo se reduce drásticamente.
Las funcionalidades se refinan con cada reunión y el producto final refleja la necesidad final. Aprenden paso a paso lo que funciona para el cliente e improvisan las ofertas hasta que obtienen el producto deseado.
En el enfoque tradicional de la gestión de proyectos, uno pensaría en todas las revisiones antes de lanzar el producto. Esto daría como resultado plazos incumplidos, mayores cargas de trabajo e inflación de costos. Además, el producto podría haber perdido completamente su relevancia en el momento del lanzamiento.
¿Cómo funciona exactamente Agile Management?
Aunque Agile Management se conoce principalmente como un concepto de TI, sus usos no se limitan a la industria de TI. Por ejemplo, el minorista de ropa de cadena Zara utilizó los principios de Agile Management para transformar su negocio.
Utilizando principios ágiles, Zara fabricó productos en lotes pequeños en lugar de centrarse en una producción grande antes de la nueva temporada. La compañía evitó los costos relacionados con el alto inventario y las ofertas de descuentos impredecibles por este método.
Algunos de los aspectos clave de Agile Project Management son:
- La gestión ágil de proyectos sigue un enfoque flexible.
Agile Management agradece las adiciones y los cambios a lo largo del desarrollo del producto en lugar de conformarlo a las especificaciones originales.
- Los proyectos ágiles generalmente se dividen en partes separadas de trabajo, con equipos involucrados en el desarrollo de una o más de estas "partes" de trabajo.
Por lo tanto, es posible tener, por ejemplo, cuatro equipos trabajando simultáneamente en diferentes partes de un proyecto, para que los plazos del proyecto se acorten. Los equipos se coordinan entre sí y con el cliente a diario para los entregables.
- Hay reuniones diarias sobre el progreso o obstáculos en el proyecto con comentarios constantes.
Después de recibir los comentarios de los clientes, los cambios se incorporan y los equipos pasan a la siguiente parte. Este proceso continúa entregando un producto que es más dinámico y mejor adaptado a las necesidades del cliente.
- Hay una mayor participación de los miembros del equipo en lugar de un enfoque de arriba hacia abajo.
Dentro del Ciclo de vida del desarrollo de software, los miembros del equipo participan en todas las etapas: requisitos, diseño, desarrollo y pruebas de metodología ágil. Dado que hay una visión general periódica de la eficiencia de la tarea, los miembros del equipo ajustan el comportamiento y los procedimientos en consecuencia.
- El perfil del gerente de proyecto en un proyecto ágil cambiará de un rol tradicional.
Él / ella ya no pasa mucho tiempo planeando o monitoreando recursos, pero ahora dedica más tiempo a colaborar con los equipos y a asegurarse de que la imagen general esté siempre a la vista. Esta no es una transición fácil, y los gerentes que se trasladan a sistemas ágiles deben adaptarse rápidamente para que el proyecto tenga éxito.
Algunas palabras sobre Scrum:
Scrum es uno de los marcos más populares para implementar la metodología ágil. ¿Qué es la metodología ágil? Es anterior a Agile, y se propuso por primera vez en 1986, y se implementó en las industrias automotriz y de impresoras.
Metodología ágil con scrum no son sinónimos; Hay otros marcos que se pueden utilizar para implementar Agile, pero Scrum es uno de los más efectivos y probablemente el más popular. ¿Qué es el scrum? Por lo general, Scrum solo tiene tres roles: propietario del producto, equipo y maestro Scrum. El maestro de metodología Scrum no es un gerente de proyecto. Las responsabilidades de un rol de gerente de proyecto tradicional se dividen entre los tres roles de gestión de proyecto de Scrum. El proyecto está integrado en una serie de iteraciones de longitud fija llamadas sprints. El éxito de cada sprint de metodología ágil provoca una sensación de progreso tangible y una inspiración continua. El objetivo de cada iteración es producir un producto funcional que pueda demostrarse a los interesados. La metodología ágil scrum master trabaja con el propietario y el equipo del producto para facilitar el cumplimiento de los objetivos mediante la eliminación de obstáculos. El equipo de desarrollo de metodología ágil es multifuncional e incluye probadores, diseñadores e ingenieros de operaciones además de desarrolladores.
Gestión tradicional de proyectos: la cascada
Uno de los sistemas de gestión de proyectos tradicionales más destacados es la cascada. Fue utilizado con frecuencia desde la década de 1970. Existen varias metodologías en cascada bien conocidas y ampliamente implementadas en proyectos de TI. Estos incluyen PRINCE2 que fue creado por el Gobierno del Reino Unido para su sector público.
Al igual que su nombre sugiere, es un flujo de trabajo secuencial. El producto final se repara al comienzo del proyecto. Luego, las diversas etapas del flujo de trabajo se completan en secuencia (inicio de la concepción, análisis, diseño, construcción, prueba, implementación y mantenimiento). Una vez que se completa el paso anterior, los desarrolladores pasan al siguiente paso. El plan del proyecto debe ser infalible; Una vez que se completa una etapa en la secuencia, los desarrolladores no pueden volver a visitar la misma sin comenzar de nuevo. Es un enfoque estático a la metodología ágil en la gestión de proyectos. No hay espacio para cambios o errores y el plan de proyecto de metodología ágil debe seguirse diligentemente.
Se puede establecer una analogía entre Waterfall Management y pintar una obra maestra. La imagen de la obra maestra final ya está en la mente del artista, y él trabaja constantemente hacia ella. Si, por alguna razón, el producto final es diferente de lo que visualizó, no puede modificarlo fácilmente.
¿Ágil o cascada?
- ¿Qué es ágil? Agile es más adecuado para equipos pequeños que trabajan en proyectos incrementales y evolutivos, mientras que Waterfall es adecuado para grandes esquemas o proyectos de desarrollo. La gestión de cascadas podría ser más adecuada para industrias como la industria de la construcción. Agile se utiliza en proyectos más dinámicos, como los de la industria de TI.
- Los sistemas ágiles requieren miembros del equipo altamente calificados que puedan manejar todas las fases del proyecto. Requiere un cambio dramático en el papel de un gerente de proyecto. El proceso en cascada está estructurado de una manera más tradicional, es lineal y tal vez sea más fácil de entender para los no desarrolladores y los nuevos en el desarrollo de software.
- Muchas organizaciones encuentran reconfortante la metodología Waterfall, ya que está mejor documentada. Agile es conocido por no enfatizar una extensa documentación. Es más dependiente de las personas, lo que puede ser incómodo en organizaciones donde la tasa de deserción es alta.
- Los proyectos más pequeños y directos pueden no requerir un marco metodológico ágil y un modelo secuencial en cascada puede funcionar igual de bien.
¿A dónde va todo esto?
La metodología de desarrollo ágil representa más de dos tercios de todos los proyectos de TI en los EE. UU., Según una encuesta realizada por HP en mayo de 2015.
Pero Agile no siempre es la solución 'perfecta'. No es una solución única y, como resultado, muchas organizaciones (24% según la encuesta de HP) han adoptado un enfoque híbrido.
Un híbrido de métodos Agile y Waterfall podría aprovechar las ventajas de ambos. Este enfoque híbrido podría funcionar para proyectos complicados con clientes externos y grandes equipos. Este enfoque ha sido descrito por Erick Bergmann y Andy Hamilton. Es un compromiso entre los dos métodos, lo que permite a los equipos de software trabajar 'ágilmente' mientras que los equipos de desarrollo de hardware y los gerentes de producto usan el método tradicional.
Mark Fromson, un consultor digital, señala otra forma en que un híbrido puede funcionar:
Desglosar el proyecto en fases similares a una cascada para permitir la contratación de oferta fija y el alcance definido dentro de una fase más pequeña, pero manteniendo el proyecto fluido en su conjunto.
Independientemente de la forma que adopten los futuros equipos, está claro que el desarrollo de metodología ágil llegó para quedarse. Ha permitido ventajas de flexibilidad, tiempo y costo, junto con el factor más importante de todos: dar una sensación de satisfacción y un ambiente motivador a las personas que trabajan en estos proyectos.
Fuente:
Para el Manifiesto Ágil y Los 12 Principios Ágiles: www.agilemanifesto.org
Cursos relacionados:-
Gestión ágil de proyectos: aprenda metodologías ágiles