Consideraciones para la gestión de un proyecto ágil

Las consideraciones para la gestión de proyectos basados en Scrum describen 6 elementos que debe considerar el Equipo Scrum para garantizar que un proyecto entrega los resultados esperados. Estas consideraciones se relacionan con las prácticas descritas en el Ciclo de vida de un proyecto basado en Scrum. Las 6 consideraciones, son: 1. Contratación: Esta consideración toma un enfoque en la contratación del personal, el contrato del proyecto, y la contratación de proveedores que son externos al Equipo Scrum 2. Finanzas:** Esta consideración aborda principalmente la definición del presupuesto del proyecto 3. Seguimiento y control: Esta consideración aborda el concepto de la APMO (Oficina de Gestión de Proyectos Ágiles) y su rol frente al seguimiento, control y apoyo a los proyectos basados en Scrum 4. Gestión de riesgos: Esta consideración comprende el tratamiento que se recomienda dar a los riesgos. El ciclo propuesto permite asegurar que durante toda la construcción del producto se ejecute la gestión de riesgos dada la naturaleza iterativa de Scrum. 5. Gestión de cambios: En esta consideración se define el flujo para el tratamiento de los cambios que puedan surgir durante la construcción de un producto con Scrum. Cabe mencionar que según los postulados del manifiesto ágil, se busca la "Respuesta ante el cambio sobre seguir un plan", por lo que desde Scrum se asegura cumplir con esta premisa. 6. Diseño de producto: En esta consideración se abordan recomendaciones para el diseño iterativo de producto, manteniendo el enfoque ágil de que no es necesario contar con el diseño detallado de producto para iniciar con su construcción.

1. Contratación

1. Contratación

Esta consideración toma un enfoque en la contratación (selección) del personal del equipo, el contrato del proyecto, y la contratación de proveedores que son externos al Equipo Scrum

El primer enfoque que veremos es la contratación (selección) del personal del equipo:

1. Contratación (selección) del personal del equipo

Las personas ocupan un papel clave en la gestión de proyectos ágiles, su participación se da a través del conjunto de responsabilidades que les son asignadas, es decir, su rol en el proyecto. En un proyecto Scrum se consideran 2 categorías de clasificación para los roles:

Roles Comprometidos

Los comprometidos son los roles que obligatoriamente se requieren para construir el producto del proyecto, por ende, son los responsables del éxito de cada iteración del producto y del proyecto en sí.

Los roles comprometidos son:

Roles Involucrados

Los involucrados son los roles que no son obligatoriamente necesarios durante la ejecución del proyecto Scrum. Ellos pueden interactuar con el equipo Scrum, pero NO son responsables del éxito del proyecto.

Los roles involucrados son:

Criterios para la contratación/Selección del equipo Scrum

A continuación, se describen algunos de los elementos que se deben considerar para la asignación/contratación/selección de las personas que ocuparán los distintos roles en un proyecto Scrum.

Product Owner Scrum Master Developers
Experto en Scrum Experto en Scrum Conocimiento básico de Scrum
Amplia experiencia y conocimiento del negocio y el cliente Capacidad para la resolución de problemas Expertos técnicos
Buen negociador Habilidades de coordinación Multifuncionales
Organizado con la captura de información y redacción de Historias de usuario Líder al servicio del equipo Proactivos
Experiencia en gestión de proyectos (recomendable)
Líder al servicio del equipo y el cliente (partes interesadas)

Líderes al servicio del equipo

Los roles del Scrum Master y el Product Owner se consideran como líderes que están al servicio del equipo, para lo cual deben contar con varias características que les permiten apoyar a los Developers y el equipo en general:

Competencias del equipo: Matriz de competencias

La matriz de competencias permite identificar las competencias necesarias en los miembros que hacen o harán parte de los distintos equipos y de esta manera poder identificar los miembros que necesitarán capacitación adicional en un área o competencia específica, e incluso diseñar una estrategia de tutoría entre los miembros del equipo.

Nota: Esta matriz está basada en el Modelo de desarrollo de habilidades de Dreyfus explicado más adelante.

matriz-competencias

Aunque generalmente para la contratación de los miembros del equipo se realiza con base en el conocimiento o habilidades técnicas, en Scrum se reconoce que también es necesario que los miembros del equipo cuenten con otro tipo de habilidades que le permitan desarrollar mejores interacciones, mejor comunicación y mayor cohesión. Las necesidades del equipo Scrum, se toman como criterios adicionales a tener en cuenta para la adecuada contratación de los miembros.

Los elementos necesarios para el buen desempeño de un equipo son:

necesidades-equipo

Competencias de los Developers

Se suele pensar que en los equipos multifuncionales no pueden existir roles ni especialistas, siendo esta afirmación totalmente falsa, por lo general un equipo está compuesto por distintos especialistas tales como:

¿Contratar Novatos o Expertos?

Si el objetivo es terminar el proyecto en poco tiempo y con muy alta calidad deberás contratar expertos técnicos, considerando que esto tendrá un impacto significativo en el costo; por otro lado, se podrían contratar solo novatos, pero el proyecto tardará bastante en desarrollarse debido a la curva de aprendizaje, además la calidad podría verse comprometida.

Realizar una combinación entre novatos y expertos, puede desmotivar a los expertos, aunque también puede darse la situación en la que los novatos crezcan rápido y se logre el equilibrio esperado.

2. Contrato del proyecto

Contrato de precio fijo

Contrato de Unión Temporal

Contrato de desarrollo en fases

Contrato de entrega incremental

Contrato de tiempo y materiales

Este tipo de contrato cuenta con un componente fijo: el precio, el cual puede estar definido por (horas, unidades, metro cuadrado…, etc.,) y, un componente variable, el cual se refiere a cantidades, es decir, (número de horas, número de unidades y/o metros cuadrados, etc.,) invertidos finalmente en el desarrollo de un trabajo.

3. Contratación de proveedores

Para garantizar que se trabaja con los mejores proveedores, la selección se realiza considerando las opiniones de todo el Equipo Scrum.

Algunos de los criterios que se pueden considerar para la selección de los proveedores son:

Los “Freelancers”

En algunos proyectos, podría ser necesario el apoyo de personal no disponible en el Equipo de Desarrollo, por ejemplo “Arquitectos”, “Diseñadores”, “Administradores de Bases de Datos”, etc.

Este tipo de personal es considerado como proveedor, y normalmente solo se contrata por días, y en momentos muy específicos del proyecto.

freelancer

2. Finanzas

Las finanzas del proyecto son una de las consideraciones más importantes en la gestión de un proyecto (sobre todo en proyectos externos a la organización), ya que, de no realizarse una adecuada gestión financiera, el proyecto podría generar pérdidas, comportamiento no deseados, e incluso la cancelación total de un proyecto.

Las finanzas del proyecto se ven reflejadas principalmente en los siguientes momentos:

finanzas

Presupuesto inicial del proyecto

Una de los momentos clave en las prácticas Scrum es la definición del Presupuesto inicial del proyecto, para lo cual se deben tener en cuenta como mínimo los siguientes elementos:

Nota: Es responsabilidad del Product Owner y el Patrocinador del proyecto (cliente), discutir, negociar y aceptar el presupuesto para asegurar que haya suficientes fondos disponibles para el proyecto.

Algunas de las técnicas y herramientas que se pueden utilizar para gestionar las finanzas del proyecto son:

Retorno de la Inversión

El ROI (Return Of Investment) es el cálculo de las utilidades (o valor financiero) generado por un proyecto. Esto sirve a muchas organizaciones para determinar si los proyectos externos son exitosos o no.

roi

Nota: No todos los proyectos están diseñados para generar utilidades (ganancias), así que, cuando a un proyecto no se le puede calcular el ROI, lo que se mide es el valor entregado (es decir, los beneficios) utilizando VOI (Value of Investment).

Estimación basada en históricos

Los datos históricos del mismo proyecto o de otros proyectos serán de gran utilidad para lograr mejores estimaciones de los elementos que hacen parte del Product Backlog.

Dependiendo de la información disponible en la organización, se puede utilizar:

Coeficiente de conocimiento del negocio

Esta técnica está basada en la idea de que a mayor conocimiento o experiencia del negocio/proyecto, más precisa será la estimación del presupuesto, y, a menor conocimiento o experiencia del negocio/proyecto, habrá mayor riesgo y menor precisión en la estimación.

El objetivo de esta técnica es calcular en una escala porcentual el grado de conocimiento sobre el negocio y a partir de allí calcular la reserva financiera o presupuestal.

Algunos factores para el cálculo del coeficiente de conocimiento sobre negocio son:

El seguimiento y control del proyecto, es una actividad que debe hacerse de forma continua a lo largo del ciclo de vida del proyecto. Por lo general los momentos donde se realiza de forma intensiva son: Al inicio, a intervalos predefinidos durante el proyecto o en cualquier momento cuando surgen problemas o riesgos de viabilidad.

3. Seguimiento y control

6.3.1 - Oficina de Gestión de Proyectos Ágiles (APMO)

Una APMO (Agile Project Management Office) está conformada por un Grupo de expertos en Scrum u otros Marcos de Trabajo ágiles.

La Oficina de Gestión de Proyectos Ágiles (APMO) tiene como responsabilidades:

dibujo

6.3.2 - Informes y reportes del proyecto

En cualquier momento es posible conocer el progreso del proyecto tan solo con sumar el trabajo total restante para alcanzar el objetivo. El Product Owner hace seguimiento de este trabajo restante total al menos en cada Revisión de Sprint. El Product Owner compara esta cantidad con el trabajo restante en Revisiones de Sprint previas, para evaluar el progreso hacia la finalización del trabajo proyectado en el tiempo deseado para el objetivo. Esta información se muestra de forma transparente a todos los interesados.

Varias prácticas de proyección de tendencias se han utilizado para predecir el progreso, como trabajo pendiente (Burn Down), trabajo completado (Burn Up) y el flujo acumulado (Cumulative Flow). Estas han probado ser útiles, sin embargo, no reemplazan la importancia del empirismo. En entornos complejos se desconoce lo que ocurrirá. Solo lo que ya ha ocurrido puede utilizarse para la toma de decisiones con miras al futuro.

6.3.2.1 - Velocidad del Equipo Scrum

La velocidad del Equipo es la velocidad con la que el equipo puede completar el trabajo en un Sprint. Por lo general se expresa en las mismas unidades que las utilizadas para la estimación, normalmente puntos de historia.

dibujo

6.3.2.2 – Métricas en proyectos Scrum

Algunas de las métricas que son realmente útiles cuando se trabaja usando Scrum son:

Métrica ¿Qué se mide? ¿Para qué se utiliza? Responsable Responsable
Flujo acumulado Historias de Usuario Completadas Historias de Usuario Pendientes Historias de Usuario En Progreso • Monitorear el progreso del equipo. • Evitar la deuda técnica del equipo en cada sprint. Scrum Master Sprint
Costos de Proyecto Costos mensuales del Proyecto Disminuir el riesgo de desvíos financieros. Product Owner Mes
Velocidad de Equipo Velocidad de Equipo Encontrar el punto de equilibrio del trabajo al que se puede comprometer el equipo en cada sprint. Scrum Master Sprint
Impedimentos Cantidad de Impedimentos Resueltos Evitar que el equipo tenga inconvenientes o atrasos en el próximo sprint. Equipo de Desarrollo / Scrum Master Sprint
Cambios # Cambios aceptados # Cambios rechazados # Cambios pendientes por revisar Garantizar la estabilidad de los proyectos y Garantizar que los cambios son atendidos a tiempo. Product Owner Semanal
Errores Errores en pruebas unitarias Errores en pruebas de colegas Errores en producción Errores en Validación Garantizar la calidad del producto. Equipo de Desarrollo Sprint
Riesgos Riesgos Materializados Riesgos Mitigados Riesgos No tratados Garantizar la calidad del producto y la estabilidad del proyecto Product Owner Sprint

6.3.2 - Seguimiento de Calidad

En Scrum, la calidad se define como la capacidad del producto para cumplir criterios de “terminado” y alcanzar el valor que espera el cliente. En los proyectos Scrum es sumamente importante realizar un seguimiento constante a la calidad del producto y así evitar inconvenientes en el futuro (esta es una práctica iterativa que se realiza en todos los Sprints).

6.3.3.1 - Control de calidad

El Control de Calidad se refiere a la ejecución de las actividades de calidad que se realizan a los incrementos de producto que están potencialmente listos para la entrega y posteriormente sobre el Producto.

Normalmente los controles de calidad son realizados por el Equipo de Desarrollo y el Scrum Master durante la práctica de Desarrollo del Sprint, y por el Product Owner en la Revisión del Sprint.

6.3.3.2 - Aseguramiento de calidad

El Aseguramiento de la Calidad se refiere a la evaluación de los procesos y normas que están definidos en el Ciclo de vida de un proyecto Scrum.

Normalmente el aseguramiento de calidad se hace por medio de auditorías de proceso, realizadas por la APMO (Sección 6.3.1).

Para realizar las actividades de Aseguramiento de calidad, puede usarse el Marco para la Evaluación y Mejora de Procesos de Tecnologías de la Información (MEMPTI).

4. Riesgos

La gestión de riesgos es una actividad que se realiza proactivamente y a través del ciclo de vida del proyecto.

6.4.1 - Ejemplos de riesgos comunes:

Falta de capacidad del recurso humano actual: En algunas organizaciones, el personal disponible para la ejecución de los proyectos tiene asignadas otras responsabilidades que le impiden tener total disponibilidad para ejecutar las actividades del proyecto.

Algunas de las posibles acciones a tomar son:

Falta de seguimiento y control sobre los proyectos: La falta de seguimiento y control del portafolio de proyectos puede provocar su obsolescencia y/o fracaso.

Algunas de las posibles acciones a tomar son:

El presupuesto se agota o no es suficiente: Se debe considerar que, para el desarrollo de la mayor parte de los proyectos internos, se necesitan considerables sumas de dinero, que deberán ser proyectadas dentro del presupuesto general de la organización.

Falta de compromiso por parte de los involucrados en los proyectos: Los proyectos Scrum requieren una colaboración entre los miembros del equipo y las partes interesadas, por lo que es importante contar con el compromiso de todos los involucrados.

Para este fin, se recomienda:

Posible rotación del personal actualmente involucrado en el proyecto: Uno de los mayores riesgos a los que normalmente se encuentra expuesto un proyecto, es la posible renuncia de los miembros del equipo, por lo que se recomienda:

6.4.2 - Apetito de Riesgo

El Apetito de Riesgo es un modelo utilizado para medir la preferencia de las Partes Interesadas por el riesgo o su actitud hacia el riesgo. Esto define el nivel de las Partes Interesadas para aceptar riesgos.

dibujo

6.4.3 - Tolerancia al Riesgo

La tolerancia al riesgo es la cantidad máxima de riesgo que la organización está dispuesta a aceptar para lograr los objetivos del proyecto; la tolerancia al riesgo sirve como una alerta para evitar llegar a la capacidad de riesgo.

Capacidad de Riesgo

La capacidad de riesgo es el nivel de riesgo máximo que se puede permitir antes de que el proyecto se desvíe de tal forma que no entregue valor al cliente. En caso de superar la capacidad de riesgo, por lo general se da por terminado el proyecto (Sección - Etapa 6: Cierre del proyecto).

6.4.4 - Ciclo de vida de la gestión de riesgos

La gestión de riesgos se compone de cinco pasos que se enuncian a continuación:

dibujo

6.4.4.1 - Identificación del riesgo (1)

La identificación de riesgos permite conocer los posibles riesgos que pueden afectar el desarrollo del proyecto y de sus respectivos Sprints.

Existen 2 momentos importantes donde se realiza la identificación de riesgos:

Solo mirando el proyecto desde diferentes perspectivas y utilizando una variedad de técnicas, se puede hacer la identificación de los posibles riesgos. La técnica más utilizada es la lluvia de ideas.

6.4.4.2 - Evaluación del riesgo (2)

La evaluación de riesgos ayuda a entender el impacto potencial de un riesgo, ¿qué tan probable es que se produzca, y cuándo es posible que el riesgo se materialice? Con ello una decisión podrá ser tomada y determinar si sería buena idea continuar con el Sprint o incluso el Proyecto.

La evaluación de riesgos se hace considerando 3 factores:

dibujo

6.4.4.2.1 – Valor Monetario Esperado

Esta técnica se utiliza para calcular el impacto monetario que podrá tener un riesgo, y con esta información realizar reservar monetarias para la prevención y/o mitigación de riesgos.

La técnica considera 2 factores: El impacto monetario del riesgo y la probabilidad de ocurrencia.

dibujo

Ejemplo: Una organización que implementa sistemas de energía solares detecta una posible tormenta tropical que le impediría continuar con la instalación de los paneles previstos para el próximo Sprint. Para calcular el impacto que esto tendría en el proyecto se identifican factores como posibles multas, salario de las personas, etc. Llegando a la conclusión de que para este riesgo se perderían 538 dólares. El siguiente paso es calcular la probabilidad de ocurrencia del riesgo, que según el instituto meteorológico es del 35%. Al aplicar la técnica como se explica, el Valor Monetario de ese riesgo es de 188.3 dólares.

dibujo

6.4.4.3 - Priorización del riesgo (3)

La priorización de riesgos permite establecer un orden para la mitigación de los riesgos. Para realizar la priorización de los riesgos se siguen los siguientes pasos:

dibujo

6.4.4.4 - Mitigación del riesgo (4)

En la etapa de mitigación, el Equipo Scrum determina la acción a tomar con el riesgo. En Scrum existen 3 posibles respuestas a los riesgos:

dibujo

6.3.4.4.1 – Mitigación

6.4.4.4.2 – Contingencia

6.4.4.5 - Comunicación del riesgo (5)

Las Partes Interesadas deben ser informadas continuamente acerca del estado de los riesgos, incluyendo el impacto potencial de estos riesgos y los planes para responder a cada riesgo.

Por lo general, la comunicación del Riesgo es llevada a cabo por el Scrum Master hacia el Product Owner y por el Product Owner hacia el cliente.

Esta comunicación siempre está en curso y debe ocurrir en paralelo durante los cuatro pasos secuenciales discutidos hasta ahora.

5. Cambios

Ágil implica la apertura al cambio, por lo que es común que todos los proyectos ágiles estén expuestos a cambios, y es de vital importancia que los miembros del equipo estén preparados para enfrentar los cambios en cualquier etapa del proyecto.

Es aún más importante que la organización sea consciente de la exposición a los cambios para crear sinergia con los equipos Scrum y buscar aprovechar los beneficios minimizando el impacto negativo que pudiese resultar del cambio.

Dada la naturaleza iterativa o incremental de Scrum, es posible manejar los cambios sobre el producto de una manera ordenada y cíclica, respondiendo continuamente a lo que espera el cliente; en correspondencia con el manifiesto ágil, “Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente”.

Aunque en Scrum hay una fuerte inclinación a no mantener grandes cantidades de información sin valor, una forma apropiada de solicitar los cambios sobre los productos Scrum, es a través del formato para Solicitud de Cambios – RFC (Request For Change), sin embargo esto no implica que necesariamente haya documentación de por medio.

Un buen RFC, debería tener como mínimo los siguientes componentes:

Es importante que detrás de cada cambio solicitado exista un “iniciador” para mantener la traza entre el cambio y saber de dónde proviene. Además dentro de la gestión de cambios en Scrum se reconoce la autoridad del Product Owner en la aprobación/rechazo de los cambios, por lo que es importante que durante todo el proyecto, el Product Owner esté enterado de lo que sucede con el producto.

A continuación, se describe el flujo de los cambios:

dibujo

6. Diseño del producto

Scrum es usado comúnmente para la Gestión de Proyectos ágiles orientados a la construcción de productos/servicios, sin embargo, etapas previas al proyecto como la concepción, prototipado y diseño del producto no siempre se explican al detalle, siendo altamente importantes para el buen desarrollo del proyecto.

Algunos de los conceptos que se deben considerar en esta etapa son:

6.6.1 - Producto mínimo viable

El definir el Producto Mínimo Viable o también llamado Características Mínimas de Mercado es una actividad extremadamente importante, de modo que la primera versión del producto se construye tan pronto como sea posible, lo que lleva a un aumento de rendimiento de la inversión.

Normalmente, estos requerimientos se ubicarían como alta prioridad dentro del Product Backlog.

El Producto Mínimo Viable se define entre el Cliente y el Product Owner.

6.6.2 - Análisis de viabilidad del producto

El objetivo del modelo Lean Canvas (adaptado de Business Model Canvas) es el de identificar la viabilidad de un producto o servicio y así disminuir el riesgo y los posibles obstáculos.

En muchas ocasiones el Lean Canvas se utiliza como el artefacto sustituto del caso de negocio.

Las claves a la hora de construir un Lean Canvas son:

El Lean Canvas está compuesto por 9 cuadrantes, tal como los que se describen a continuación:

dibujo

6.6.3 – Principios para el diseño de un producto

Cuando se realiza el diseño de Productos Innovadores, se podrían considerar los siguientes principios:

1. División: Dividir el producto en partes independientes (permitirá construirlo iterativamente), crear productos modulares o fáciles de desarmar o dar mantenimiento o soporte. Ej: Arquitectura de microservicios.

2. Multifuncionalidad: Considera que el producto pueda ejecutar múltiples funciones, o que se elimine la dependencia de otros productos para funcionar.
Ej: Centralización de funcionalidades en una sola aplicación

3. Simplicidad: Reducir el número de acciones que debe realizar el usuario o consumidor del producto para poder operarlo, en función de la experiencia de usuario (UX) Ej: Reducir la cantidad de botones de un producto; Reducir la cantidad de clics necesarios para lograr una acción en una aplicación.

4. Personalización: Garantizar que los consumidores o usuarios de un producto, pueden personalizarlo de tal forma que se ajuste a sus necesidades Ej: Personalización de colores, tamaños, cantidades, tipografías, imágenes, productos on-demand, etc

5. Curvatura y flexibilidad: En lugar de usar componentes, superficies o formas cuadradas, rectangulares, cúbicas, planas o rígidas, usar las curvas redondeadas, trabajar con estructuras o materiales flexibles esto permitirá un mejor uso del producto, facilidad en las interacciones e incluso aumenta la resistencia del mismo Ej: Teléfonos plegables, autos de chasis flexible, tendencia hacia el uso de diseños con formas redondeadas

6. Diseño o apariencia: Construir productos con diseños atractivos, simples y que reflejen la calidad de los materiales o componentes. Además, realizar un cambio de imagen a los productos, refleja a los clientes que existe una innovación constante.

7. Retroalimentación: Permitir la recolección de datos, estadísticas o comentarios del producto para realizar mejora continua. Ej: Aplicaciones que recolectan datos de uso o consumo; Productos que permiten enviar comentarios o recibir calificaciones.

8. Autoservicio: Se refiere a que el producto sea útil por sí mismo y no dependa de acciones de terceros para ser utilizado (diagnóstico de fallas, configuración, implementación) Ej: Autos modernos con sistema de ayuda para la identificación y prevención de fallas; Aplicaciones en la nube que no requieren de capacitación previa para ser usadas.

9. Homogeneidad: Si tu organización diseña varios productos o servicios, debe crearse un ecosistema consistente de elementos como interoperabilidad, diseños similares, o productos secundarios. Ej: Suites ofimáticas “Google Apps” – “Microsoft Office”; Ecosistema de funciones de Apple, etc.

Estos principios son genéricos y aplicables a cualquier producto o servicio, y harán parte de la práctica “Definición de la Arquitectura de Producto”.