Descifrando la Gestión de Proyectos Ágiles

Aunque Agile libera a las personas del miedo de invertir demasiado en una decisión estúpida, puede ser algo confuso de aplicar.

En este artículo, vas a aprender:

• Diferencias entre Scrum y Kanban board

• Guía paso a paso para implementar Agile en tu equipo

• Consejos para evitar errores en cada paso.

La gestión de proyectos Agile difiere de los métodos tradicionales por su énfasis en los ciclos de retroalimentación corta y en ciclos adaptativos. Al liberar constantemente incrementos, los defensores creen que el proceso Agile es más adaptable al valor y las necesidades del cliente.

Fue introducido por primera vez en los años 90 para reemplazar las metodologías waterfall pesadas. Promueve mejoras continuas. Los primeros años de los 2000 fueron testigos de un hito en los métodos Agile. Cuando 10 prestigiosos practicantes, incluido Jeff Sutherland, co-presentaron el famoso Manifiesto para el Desarrollo Ágil de Software.

Desde entonces, han evolucionado muchas divergencias. Scrum, Extreme Programming (XP), Feature-Driven-Development (FDD) y Test-Drive-Development (TDD) son solo algunas de ellas. Sin embargo, independientemente de los nombres, los principios esenciales permanecen los mismos –> reducir el riesgo del negocio mediante el desarrollo iterativo, ciclos de retroalimentación más cortos y planificación adaptativa.

Entre todos esos marcos, Scrum es el más popular. Un ciclo completo implica cinco etapas: visión, reunión de planificación del sprint, sprint diario, envío y retrospectiva. Este artículo se centrará en el marco Scrum.

Pero primero…

¿Cuáles son las diferencias entre Scrum y Kanban?

Antes de la guía, aclaremos dos terminologías de uso común:

Scrum es un marco de trabajo, un proceso

Un marco Agile diseñado para que los equipos pequeños dividan su trabajo en acciones que se pueden completar dentro de iteraciones con tiempo limitado, llamadas sprints, comúnmente de dos semanas. El equipo sigue el progreso y replanifica en reuniones de pie de 15 minutos, llamadas scrums diarios.

Kanban es un método de visualización para tareas

Un método lean para gestionar y mejorar el trabajo visualizando los elementos de trabajo para ofrecer a los participantes una visión general de las demandas y la capacidad disponible. Las colecciones de elementos visualizados se llaman Tablero Kanban. El tablero también se utiliza en Scrum.

Kanban y Scrum son dos métodos. Pero debido a la prevalencia y efectividad del Tablero Kanban, los marcos Scrum a veces también adoptan esta herramienta. Aparte de las terminologías mencionadas anteriormente, también puedes consultar más en el Glosario Ágil de AgileAlliance.

Cómo establecer la práctica Agile

Paso 1: Preparación - Construye tu equipo

Un equipo Agile típicamente se compone de tres roles: el Scrum Master (SM), el Product Owner (PO) y los desarrolladores. El tamaño del equipo es alrededor de 7(+/-2): 1 Scrum Master, 1 Product Owner, y 3-5 desarrolladores.

El Scrum Master está del lado del desarrollador para asegurarse de que el proyecto sé desarrolle sin problemas, y con suerte más rápidamente. Él/Ella debería ser un mediador o facilitador como un rol independiente. Sin embargo, basándose en el interés del equipo, el líder técnico o QA funciona bien como Scrum Master a tiempo parcial.

El Product Owner está del lado del proyecto y del usuario. El Product Owner es el representante del negocio y de los clientes. En consecuencia, los Product Owners son a menudo gerentes de producto o de marketing.

Mejor práctica: Evitar conflictos serios

Colaborar pero no competir.

El Scrum Master y el Product Owner tienen un enfoque diferente y pueden entrar en conflictos serios. Pero recuerda, el trabajo en equipo debe lograr cosas colaborativamente. El propósito de tener tres roles es hacer que el equipo funcione completamente. Por eso todos en el equipo planifican juntos.

Paso 2: Visionado - Preparar el backlog del producto

El Product Owner es el principal contribuyente en esta etapa. Él/Ella habla con los stakeholders y sintetiza un backlog de características del producto. Los stakeholders usualmente incluyen ejecutivos, el equipo de ventas y soporte, el equipo de marketing, usuarios o clientes.

El PO tiene que organizar el backlog y priorizar las características. Y de este gran backlog, él/ella articula visiones y metas siguientes.

Mejor práctica: Evitar lo tedioso

Automatizar el proceso laborioso.

Alimentar el backlog del producto a veces es un trabajo tedioso. Los procedimientos de recolección y seguimiento pueden ser altamente repetitivos. Para la corrección de errores, el PO puede conectar el backlog con un sistema de seguimiento de errores. Las herramientas de seguimiento de comentarios y una plataforma de gestión de redes sociales también son útiles.

Paso 3: Reunión - Realizar la reunión de planificación del sprint

La reunión propone metas claras para el sprint y backlogs del sprint. Generalmente dura menos de una hora y ocurre al inicio de la semana(s) del sprint. Basado en las metas del producto y los backlogs del producto, el equipo trabaja junto en dividir los backlogs en incrementos enviables.

Los desarrolladores deciden el número apropiado de puntos de historia, la manera de descomponer la meta en tareas y por lo tanto el backlog del sprint. Al final de la reunión, el equipo debe estar seguro del alcance y los entregables deseados de este sprint.

Mejor práctica: Evitar metas vagas

Dar una expectativa clara para los entregables del sprint.

La meta del sprint NO es solo unas pocas frases al azar, sino que da a los stakeholders la expectativa sobre los entregables. Funciona como un informe rápido para los stakeholders sobre lo que el equipo está haciendo. Una meta clara del sprint allana el camino para medir el rendimiento de la entrega.

Paso 4: Scrum Diario - Verificar en el camino

La reunión diaria de scrum (reunión de pie diaria) es para actualizaciones de estado del proyecto. Lo mejor es organizar la reunión en el mismo tiempo y lugar todos los días durante la iteración. El scrum diario demuestra el enfoque de Agile en las comunicaciones cara a cara.

El Scrum Master debería abordar los impedimentos para facilitar el proceso de desarrollo. Si hay algo que afecta gravemente la meta del sprint, el PO tiene todo el derecho a saberlo de inmediato. A cambio, el PO resiste la tentación de cambiar el backlog del sprint.

Mejor práctica: Evitar reuniones largas

Mantener cada reunión de pie bajo 15 minutos. Note que la reunión es como una sincronización de información dentro del equipo, más que una resolución de problemas. Es mejor dejar la resolución de problemas en otros procesos.

Paso 5: Envío - Liberar y retro

La liberación del equipo se demuestra al final de la iteración. Los stakeholders, dentro o fuera de la organización, están en la reunión de revisión. Al comparar la meta general del sprint con los logros, el Product Owner puede medir cuán exitoso es el sprint.

Después de la reunión de revisión, el equipo Agile realiza una reunión retrospectiva para reflexionar sobre lo que debe mejorarse y lo que debe continuar. Para los desarrolladores novatos, también es un momento perfecto para revisar la expectativa de velocidad y capacidad.

Mejor práctica: Nunca omitir el retro

Aunque no haya nada mal, el equipo nunca debe omitir la retrospectiva. Confirmar lo que está bien por sí solo es útil para futuros sprints. Si el SM quiere, él/ella puede incluso realizar una votación para propuestas de mejora.

¿Cuáles son las limitaciones de Agile?

Los defensores afirman que las prácticas Agile son un equilibrio entre la microgestión y la no gestión. Sin embargo, surgen críticas de la experiencia de adopción. Algunos estudios empíricos no han encontrado evidencia científica de la agilidad del equipo.

Dado que Agile enfatiza la flexibilidad, afecta al control continuo de calidad. La reducción de la duración del proyecto implica actuar rápida y ágilmente. Eso a menudo viene con una falta de documentación y recursos adecuados. Los proyectos tienden a carecer de continuidad e integridad, haciendo que el principio de enfoque en la calidad sea casi obsoleto.

Agile no es adecuado para organizaciones o industrias con alto rechazo al riesgo, como la farmacéutica. Estas industrias establecidas desde hace tiempo tienen sus convenciones importantes y complejas que seguir. Cambiar procedimientos contra la gestión tradicional es extremadamente riesgoso, si no peligroso.

Habiendo dicho eso, innumerables ejemplos exitosos son evidencia de que Agile funciona. Aunque hay trampas, los marcos Agile en constante evolución proporcionan herramientas y técnicas, como la Integración Continua (CI/CD), Pruebas Unitarias Automatizadas y Refactorización de Código, para al menos remediar los problemas.

Conclusión clave

El proceso Agile aboga por iteraciones rápidas, mejora continua y respuesta rápida al cambio. Principalmente consiste en cinco pasos: visión, planificación del sprint, scrum diario, envío y retrospectiva.

Este método tiene como objetivo equilibrar entre metodologías tradicionales y gestión flexible. Aunque carece de evidencia sólida y tiene trampas, el proceso Agile tiene sus puntos para tener éxito.

¿Cuál es tu opinión? Twitmanos para compartir tus lecciones y trucos aplicando métodos Agile :).