Marcos de gestión de proyectos

B. ¿Qué tienen en común los distintos marcos Agile?

La metodología de proyectos Agile es un enfoque de gestión de proyectos que utiliza cuatro pilares clave y 12 principios para organizar proyectos. Una cosa que todos los marcos Agile tienen en común es que todos están diseñados para respaldar el logro de esos pilares y principios. 

El flujo de procesos Agile destaca sobre otros enfoques de gestión de proyectos debido al hincapié que hace en el desarrollo iterativo, la flexibilidad, la retroalimentación continua, además de en la valoración de las personas sobre los procesos. Por lo tanto, cualquier marco Agile debe crearse en torno a estos valores clave. 

Si bien cada marco tiene sus facetas únicas, también se han creado para garantizar que se sigan los principios básicos de la gestión de proyectos y que el proyecto se pueda completar con éxito. Los marcos Agile se consideran ligeros en comparación con los marcos tradicionales, ya que generalmente se centran en mantener la documentación y las reglas al mínimo. Sin embargo, cada marco de proyectos Agile debe incluir todos los procesos y las fases críticas del proyecto, como el inicio, la planificación, etc. 

C. El marco Scrum

Si se pregunta cuál es la metodología Agile más popular, la mayoría de las personas probablemente responderá que el marco Scrum. 

La metodología Scrum se desarrolló en la década de 1990, basándose en un artículo de Harvard Business Review titulado, «The New New Product Development Game». 

Al igual que ocurre con otros marcos Agile, Scrum describe un enfoque iterativo hacia la gestión de proyectos. La metodología Scrum dicta dividir un proyecto en sprints que generalmente solo duran de una a cuatro semanas. Cada sprint debe terminar con la finalización de una versión viable o un borrador del entregable final del proyecto. 

Mediante el uso de iteraciones cortas, el enfoque de gestión de proyectos de Scrum permite a tu equipo de trabajo entregar una versión funcional del producto final con frecuencia. 

Scrum se diseñó inicialmente utilizando un modelo de software que sigue un conjunto de funciones, responsabilidades y reuniones. Sin embargo, es lo suficientemente flexible como para utilizarse en cualquier proyecto complejo de cualquier industria. No obstante, funciona mejor cuando tu proyecto genera como resultado un producto concreto, en lugar de un servicio.

Scrum se considera ligero y flexible, pero difícil de dominar. Su marco se basa en tres pilares:

1. Transparencia. Se debe usar un lenguaje y unas definiciones comunes.
2. Inspección. Los «artefactos» y productos de Scrum se deben inspeccionar periódicamente y con diligencia para garantizar la calidad.
3. Adaptación. Cuando una inspección descubre una calidad inferior a la estándar, el equipo debe poder hacer ajustes o correcciones lo antes posible. 

Scrum en Agile requiere funciones y responsabilidades particulares, entre las que cabe mencionar:

• Propietario del producto. En un proyecto, el propietario del producto es la persona responsable de defender los intereses del cliente. Esta persona tiene la máxima autoridad para decir lo que se incluye en el producto final. La labor del propietario del producto es garantizar que se entiendan y se cumplan los requisitos, las funciones y las prioridades del producto.
• Maestro Scrum. El maestro Scrum es un facilitador, responsable de organizar las reuniones diarias, mejorar las interacciones del equipo y ayudar a maximizar la productividad. La diferencia entre el gerente de proyectos y el maestro Scrum es que la definición de este último se centra únicamente en ser un líder al servicio de los demás. Las funciones y responsabilidades del gestor de proyectos Agile a menudo incluyen la labor de maestro Scrum, pero esta también se puede delegar a cualquier miembro del equipo que sea experto en Scrum y buen facilitador. 
• Equipo de desarrollo. El equipo de desarrollo es el equipo de tu proyecto Scrum. Por lo general, es de naturaleza auto-organizada y multifuncional. Este equipo debe incluir a todas las personas necesarias para diseñar, producir, probar y lanzar el producto final.
• Equipo Scrum. La estructura del equipo Scrum incluye al equipo de desarrollo, el maestro Scrum y el propietario del producto. 

Scrum también tiene una terminología única. A continuación, se enumeran los términos más importantes que se utilizan habitualmente en el marco Scrum: 

• Trabajo pendiente del producto. El trabajo pendiente es una lista de tareas y requisitos que se deben incluir en el producto final. El propietario del producto es el responsable de crear y administrar el trabajo pendiente. 
• Sprint. Un sprint es un período de tiempo establecido para completar cada conjunto de tareas del trabajo pendiente. Todos los sprints deben tener la misma longitud. Son habituales dos semanas de duración, pero el sprint puede ser de entre una y cuatro semanas, dependiendo de las necesidades del equipo y el proyecto. 
• Planificación del trabajo pendiente. La planificación del trabajo pendiente se refiere al proceso de determinar qué tareas de la lista de trabajo pendiente se incluirán en cada sprint. Esto a veces también se llama planificación del sprint Agile.  
• Trabajo pendiente del sprint. La parte del trabajo pendiente asignado al sprint actual. 
• Scrum diario. Se espera que un equipo del proyecto Scrum se reúna todos los días para comentar el progreso realizado en las últimas 24 horas, el progreso esperado en las próximas 24 horas y cualquier problema nuevo que haya surgido. Estas reuniones normalmente se conocen como Scrum diario o reunión diaria y suelen durar solo unos 15 minutos.
• Retrospectiva. Cada sprint debe terminar con una reunión de revisión, llamada retrospectiva. Esta reunión es donde el equipo revisa su progreso hasta el momento y comenta cómo puede mejorar la ejecución del próximo Sprint.
• Tabla Scrum. Una tabla Scrum es una herramienta que ayuda a tu equipo a ver y gestionar el trabajo pendiente del sprint. Puede ser una tabla física, como una pizarra, o una virtual dentro de una herramienta de gestión de proyectos. La tabla suele tener tres columnas: «Pendiente», «En progreso» y «Hecho». A medida que se completan los elementos pendientes, van pasando de una columna a la siguiente de la tabla. Esto permite que todos vean rápidamente lo que hay que hacer durante el sprint actual y cómo progresa el trabajo. 
• Artefacto. El trabajo pendiente del producto, el trabajo pendiente del sprint y el incremento del producto son los tres artefactos Scrum de un proyecto. El trabajo pendiente del producto y el trabajo pendiente del sprint representan el trabajo que queda aún por hacer, y el incremento es la parte del producto que ya se ha hecho durante el sprint actual.

D. Otros métodos populares de gestión de proyectos Agile

Si bien Scrum es uno de los métodos de gestión de proyectos Agile más populares, desde luego no es tu única opción. Tal vez te preguntes: ¿qué es la planificación Agile y cuál debo elegir? A continuación, enumeramos otras cinco metodologías de gestión de proyectos Agile entre las que elegir:

1. Kanban

Kanban es una forma sencilla y visual de gestionar proyectos, que hace hincapié en la visibilidad. Kanban se diseñó inicialmente como un método de programación y ayuda a los equipos para ejecutar la producción justo a tiempo, al permitir que todos vean dónde se encuentra el trabajo en el proyecto y qué va a continuación. 

Kanban se centra en un flujo de trabajo visualizado en el que el trabajo se divide en pequeñas partes. El marco Kanban es similar a Scrum en muchos sentidos. Por ejemplo, Kanban también usa una tabla para ayudar a ver y realizar un seguimiento del progreso del trabajo. Dicha tabla ayuda a segmentar las tareas del proyecto en tres columnas principales: «Pendiente», «En progreso» y «Hecho». Sin embargo, a diferencia de Scrum, la tabla Kanban hace un seguimiento de todo el trabajo del producto pero no lo divide en sprints. 

Algunos de los puntos fuertes de Kanban son su capacidad para ayudar a identificar bloqueos y despilfarros, así como a reducir el tiempo de espera.

2. Extreme Programming (XP)

Extreme Programming (XP) es un marco Agile diseñado inicialmente para proyectos de desarrollo de software Agile. Al igual que Scrum, este marco se centra en el desarrollo continuo y la entrega al cliente. También usa intervalos o sprints, de forma similar a una metodología Scrum. 

Sin embargo, el marco XP se centra en principios de ingeniería e incluye 12 procesos de apoyo específicos para el mundo del desarrollo de software, que son:

1. El juego de la planificación
2. Pequeñas entregas
3. Pruebas de aceptación del cliente
4. Diseño sencillo
5. Programación por parejas
6. Desarrollo guiado por pruebas
7. Refactorización
8. Integración continua
9. Propiedad colectiva del código
10. Estándares de codificación
11. Metáfora
12. Ritmo sostenible

3. Feature-Driven Development (FDD)

El desarrollo basado en funciones es otro marco de trabajo Agile específico del software. Este marco se basa en la idea de crear modelos de software cada dos semanas. También requiere un plan de desarrollo y diseño independiente para cada función del modelo de software, lo que hace que requiera más documentación que algunos de los otros marcos Agile. Debido a sus rigurosos requisitos de documentación, FDD suele ser mejor para equipos con capacidades avanzadas de diseño y planificación. 

El marco FDD divide los proyectos en cinco actividades básicas y repetibles:

1. Desarrollo de un modelo general
2. Creación de la lista de funciones
3. Planificación por función
4. Diseño por función
5. Creación por función

4. Dynamic Systems Development Method (DSDM)

El método de desarrollo de sistemas dinámicos surgió de la necesidad de proporcionar un marco industrial común para la entrega rápida de software. El DSDM parte de la base de que se ha de esperar una revisión y cualquier cambio de desarrollo que se produzca debe ser reversible. Al igual que Scrum, XP y FDD, el marco DSDM divide los proyectos en sprints más pequeños. 

Este marco se basa en ocho principios clave:

1. Centrarse en la necesidad empresarial
2. Entregar a tiempo
3. Colaborar
4. No comprometer nunca la calidad
5. Construir gradualmente a partir de cimientos firmes
6. Desarrollar iterativamente
7. Comunicarse de forma continua y clara
8. Demostrar control

5. Crystal

Crystal es en realidad una familia de metodologías Agile que incluye Crystal Clear, Crystal Yellow, Crystal Orange, Crystal Red, etc. Cada metodología Crystal tiene su propio marco único. El que elijas depende de varios factores del proyecto, como el tamaño de tu equipo, las prioridades de tu proyecto y la importancia del proyecto. A la hora de decidir cómo adoptar Agile en tu proyecto, es importante admitir que los diferentes proyectos requieren un conjunto de políticas, prácticas y procesos ligeramente distintos en función de sus características únicas. 

¿Qué es un proyecto Lean?

Aunque Lean aparece a menudo en las listas de marcos Agile, el desarrollo Lean es en realidad una metodología completamente independiente. La razón por la cual Lean y Agile se agrupan tan a menudo es porque comparten muchos de los mismos valores. Por ejemplo, tanto la metodología Lean como Agile hacen hincapié en la capacidad de adaptarse fácilmente al cambio. 

Entre losprincipios fundamentales de la metodología Lean cabe destacar:

1. Eliminar despilfarros
2. Producir con calidad
3. Crear conocimiento
4. Aplazar el compromiso
5. Hacer entregas rápidas
6. Respetar las personas
7. Optimizar la totalidad del proceso

E. Definición de épica Agile

La definición básica de épica Agile es «grandes historias de usuario». Por supuesto, esto es intrínsecamente impreciso y a menudo conduce a malentendidos. Sin embargo, la definición debía ser imprecisa para proporcionar a los proyectos y los gestores de proyectos una mayor flexibilidad.   

Para comprender mejor qué es una épica, definamos primero una historia de usuario. Una historia de usuario es simplemente algo que un usuario quiere. En otras palabras, es una descripción de los resultados que solicita tu cliente. Idealmente, una historia de usuario es lo suficientemente pequeña como para caber dentro de un sprint del proyecto. Por ejemplo, si estabas produciendo un libro y cada capítulo se podía hacer en un sprint, cada capítulo se convertiría en una historia de usuario. 

Pero, ¿qué pasaría si se tardara ocho semanas en completar un capítulo? La historia de usuario sería demasiado grande para llevarla a cabo dentro de un sprint con éxito. Por lo tanto, se considera una gran historia de usuario o una épica. 

No hay unas directrices de tamaño exacto para las épicas. Depende de la longitud del sprint de tu equipo de trabajo y las necesidades del proyecto. 

Otra definición importante que hay que entender es la de tema. Un tema es una colección de historias de usuario relacionadas o que se pueden agrupar fácilmente. Por ejemplo, si estuvieras planeando construir una casa, podrías optar por agrupar todos los requisitos eléctricos bajo un tema y todos los requisitos estructurales bajo otro. 

Historia, épica y tema son términos que muchos equipos Agile usan para ayudar a simplificar las conversaciones y la planificación del trabajo pendiente del producto. Por ejemplo, en el trabajo pendiente de tu producto puede haber un requisito demasiado grande para asignar a un sprint. Al etiquetarlo como una épica, todos saben que debe desglosarse para que pueda formar parte del trabajo pendiente del sprint.

Del mismo modo, agrupar requisitos bajo temas te puede ayudar a llevar a cabo la planificación del trabajo pendiente del sprint. Después de todo, los requisitos que se agrupan pueden beneficiarse de que se los incluya en el mismo sprint. 

La gestión de proyectos de épica consiste en administrar el trabajo pendiente de una manera que sea ejecutable. Asegura que los requisitos sean lo suficientemente concisos para cumplirlos en un período de entre una y cuatro semanas.  

Dos de los beneficios de las épicas son: 

• Las épicas te permiten realizar un seguimiento de las ideas grandes y poco definidas del trabajo pendiente. Puedes anotar un requisito como una épica y luego precisarlo más adelante, a medida que avanza el proyecto. 
• Las épicas te permiten establecer una jerarquía para los elementos de tu trabajo pendiente. La épica permanece en el trabajo pendiente como la idea o el requisito original. Las historias de usuario asociadas a ella hacen un seguimiento de los aspectos del producto que te permitirán cumplir con ese requisito. 

Uno de los mayores problemas con las épicas es cuando los equipos se ven demasiado absorbidos por los detalles como para diferenciar entre épicas e historias. Otro problema es cuando los equipos ponen demasiado esfuerzo en hacer un seguimiento de las épicas por separado de las historias, o demasiado esfuerzo en tratar de valorar y precisar las épicas antes de dividirlas en historias. 

La conclusión es que las épicas están destinadas a ser una herramienta de agrupación útil para el trabajo pendiente. Si están creando problemas y dolores de cabeza a tu equipo del proyecto, es necesario reevaluar su uso.

Aquí puedes ver un vídeo de Knowledge Hut en el que se ilustra en mayor medida la definición y el valor de las épicas Agile.

F. Buenas prácticas del gestor de proyectos para escoger el marco adecuado

Con más de seis marcos de proyectos Agile populares entre los que elegir, ¿cómo saber cuál es el adecuado para tu proyecto? 

En primer lugar, no existe un marco que valga para todos los proyectos, por lo que es importante evaluar las necesidades individuales de tu proyecto y tu equipo a la hora de determinar qué marco utilizar. 

A continuación, enumeramos siete prácticas recomendadas para gestores de proyectos basadas en el Organizational Project Management Maturity Model (OPM3, Modelo de madurez organizacional en gestión de proyectos) y la Implementing Organizational Project Management Guide (Guía de implementación de gestión de proyectos en organizaciones) del Project Management Institute.  

1. Evalúa el tamaño y el alcance del proyecto. Si es un proyecto grande y largo, puede ser difícil dividirlo en sprints de dos semanas. Por otro lado, si el alcance es difícil de definir y se espera que evolucione con el tiempo, es probable que Agile se ajuste mejor que un marco más tradicional. 
2. Determina los impulsores del proyecto. Antes de iniciar un proyecto, es importante comprender su argumento comercial y su valor para la organización. ¿Qué beneficios aporta este proyecto a tu empresa?  
3. Comprende los objetivos clave del cliente, los resultados esperados y las prioridades para el proyecto.
4. Identifica los impulsores, los objetivos, los resultados y las prioridades del proyecto que se verán afectados por las diferentes metodologías de gestión de proyectos. Por ejemplo, si un objetivo del proyecto es hacerlo de la manera más rentable posible, una metodología Lean puede ser más efectiva. Si un cliente espera documentación de funciones en profundidad, FDD podría ser la mejor opción. 
5. Crea una lista de las posibles metodologías que pueden adaptarse a tu proyecto y clasifica su idoneidad según los criterios descritos en el último paso. Puede consistir en una tabla sencilla con cada marco Agile posible en la parte superior y todos los impulsores clave, objetivos, etc. en el lado izquierdo. A continuación, puedes confirmar uno por uno si cada marco admite los impulsores. 
6. El marco que respalde la mayoría de los impulsores, objetivos, resultados y prioridades debe ser el elegido. Ten en cuenta que si alguno de resultados es más crítico que otro, puedes ponderar tus evaluaciones para asegurarte de que no se pase por alto. Te interesa elegir el marco que proporcionará los mejores resultados con la menor cantidad de riesgo. 
7. Una vez que hayas elegido el marco, supervisa qué tal funciona. Recuerda que un concepto clave de Agile es la flexibilidad y la adaptabilidad. Si la metodología del proyecto que has elegido no produce los resultados deseados, es posible que debas modificarla o incluso cambiar de marco. 

G. Herramientas gratuitas para la gestión de proyectos Agile

Las herramientas de gestión de proyectos Agile son cualquier herramienta que utilices para la administración de un proyecto Agile. En la forma más básica, una pizarra y unas notas post-it pueden considerarse herramientas de gestión de proyectos Agile. 

Sin embargo, existe una amplia variedad de herramientas digitales más sofisticadas entre las que puedes elegir. La diferencia clave entre las herramientas Agile y otras herramientas de gestión de proyectos es su capacidad para administrar marcos Agile, como Scrum y Kanban. 

A continuación, se enumeran cinco herramientas de gestión de proyectos Agile gratuitas:

1. KanbanTool KanbanTool es una tabla Kanban en línea. Dispone de tarjetas Kanban, carriles, colores y mucho más que te ayudan a garantizar la visibilidad del proyecto. La versión básica de la herramienta es gratuita para un máximo de dos usuarios y dos tablas.
2. PipefyPipefy es una herramienta que te permite crear y ejecutar flujos de trabajo al estilo Kanban. No ofrece plantillas de proceso prediseñadas, pero te ofrece la capacidad de diseñar y personalizar completamente tus propios flujos de trabajo. Esta herramienta es gratuita para equipos de hasta cinco personas. 
3. Wrike Wrike es una herramienta de gestión de proyectos basada en la nube que admite tanto marcos de gestión de proyectos Agile como otros más tradicionales. Wrike ofrece una versión básica de la herramienta de forma gratuita para un máximo de cinco miembros del equipo. 
4. YodizYodiz es una plataforma Agile todo en uno totalmente personalizable. La herramienta te permite personalizar campos, diseños de tabla, colores de tabla y mucho más. Es gratis para un máximo de tres usuarios.
5. Zoho SprintsZoho Sprints es una herramienta basada en la nube para equipos Agile. Ofrece una variedad de funciones de gestión de proyectos Agile, incluidas las tablas Scrum. El software es gratuito para un máximo de cinco proyectos y cinco usuarios.