Consideraciones

6.1. Contratación

6.1.1 - Roles del proyecto

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:

6.1.1.1 - Comprometidos

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

Los roles comprometidos son:

El Product Owner.
El Scrum Master.
El Equipo de Desarrollo.

6.1.1.2 - Involucrados

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

Los roles involucrados son:

Clientes.
Usuarios.
Proveedores (Ej: Freelancers; Proveedores de servicios; etc).
Oficina de Gestión de Proyectos Ágiles (APMO).

6.1.2 - Contratación del equipo (Personal)

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

Product Owner	Scrum Master	Equipo de Desarrollo
- Experto en Scrum	- Experto en Scrum	- Conocimiento básico de Scrum
- Amplia experiencia y dominio del negocio	- Capacidad para resolver problemas	- Expertos técnicos
- Buen negociador	- Habilidades de coordinación	- Multifuncionales
- Organizado	- Líder servicial	- Proactivos
- Experiencia en dirección de proyectos
- Líder servicial

6.1.2.1 - Los líderes serviciales

Los líderes serviciales tienes varias características que les permiten apoyar al Equipo de Desarrollo:

Capacidad de escuchar: Escuchan con atención y son receptivos a lo que se dice y no se dice para comprender y reflexionar sobre la situación.
Empatía: Aceptan y reconocen a los individuos por sus habilidades y destrezas únicas.
Persuasión: Logran el consenso del Equipo en la toma de decisiones.

6.1.2.2 - Matriz de competencias

La matriz de competencias le permite a la organización identificar las competencias necesarias en los miembros que hacen o harán parte de los distintos equipos y así encontrar cualquier brecha que pueda existir en los miembros del Equipo Scrum, y así también poder identificar los miembros que necesitarán capacitación adicional en un área o competencia específica.

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

dibujo

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:

Habilidades técnicas: Son las habilidades especificas que requieren los miembros que desarrollarán los entregables del proyecto. (Ej, Diseño – Desarrollo de Software – Conocimiento de una herramienta específica, etc)
Habilidades esenciales: También llamadas habilidades blandas, son las habilidades que permiten lograr la empatía y buenas relaciones entre todos los Stakeholders del proyecto.
Procesos y prácticas: Las personas deben conocer los entregables, eventos, o herramientas a usar dentro del proyecto. Scrum, por ejemplo, describe 17 prácticas aplicables a los proyectos.
Herramientas: Para desarrollar los entregables del proyecto siempre será indispensable el uso de herramientas, por ejemplo

dibujo

6.1.2.3 - Roles del Equipo de Desarrollo

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:

Analistas.
Desarrolladores.
Probadores.
Integradores.
Diseñadores.
Arquitectos.
Etc.

¿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.

6.1.3 - Tipos de contratos

Contrato de precio fijo

Se define un precio total fijo para todo lo que se desarrolle en el proyecto.
Mayor riesgo financiero si no se da cumplimiento a todo el proyecto en función del contrato.
Los entregables son fijos y definidos al inicio del proyecto.
No son ideales para el uso de Scrum.

Contrato de Unión Temporal

Generalmente se utiliza cuando dos o más socios ejecutan un proyecto.
El ROI (ingresos o beneficios) será compartido entre todos los socios.
Es importante definir los % de participación y las responsabilidades en el proyecto.
Es ideal centralizar los equipos o dividir el proyecto en componentes.

Contrato de desarrollo en fases

Se considera el concepto de Producto Mínimo Viable.
Se “fragmenta” el proyecto en varias fases, donde al final de cada fase se hacen pagos.
Cada fase genera un conjunto importante de entregables.
Útil para proyectos de gran tamaño.
Se reduce el riesgo monetario, ya que los despliegues sin éxito no son financiados.

Contrato de entrega incremental

El cliente/patrocinador puede tomar decisiones sobre el proyecto en cada inspección: Puede aceptar el entregable, Detener el desarrollo o Solicitar modificaciones.
Cada Sprint debe generar un incremento por lo general es una épica o componente completo.
El pago/facturación se hace con cada Iteración (se utiliza generalmente en proyectos internos).
También se le llama “Contrato por Sprints”.

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.

Este tipo de contrato es usado cuando no es preciso especificar durante el desarrollo de un trabajo, la cantidad requerida de trabajo a ejecutar.

6.1.4 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:

Precio.
Curva de Aprendizaje.
Facilidad de uso.
Velocidad de la Solución.
Soporte.
Seguridad.
Complejidad para la migración de Datos.
Tiempo de Implementación.
Reputación.
Facilidad de Pago.
Referencias.

6.1.6 – 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.

dibujo

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:

Inicio del proyecto: En la definición del presupuesto inicial del proyecto, que permitirá evaluar la viabilidad de iniciar un proyecto, además de asegurar los recursos financieros del proyecto, e incluso identificar posibles riesgos financieros.
Ejecución del Proyecto: Al final de cada Sprint, podría realizarse seguimiento y control financiero del proyecto, para así evitar desviaciones o la ocurrencia de posibles problemas, al ser realizada de forma iterativa, supone menor desgaste para la persona que asuma esta responsabilidad (normalmente es el Product Owner), además de garantizar que siempre se encuentra actualizada la información.
Cierre del Proyecto: Por lo general, las organizaciones solicitan a los equipos de proyecto un reporte final que describa los costos del proyecto, en relación al presupuesto solicitado. En Scrum la función encargada de analizar dicha información se conoce como la APMO (Agile Project Management Office). Además esta información servirá para alimentar el portafolio de proyectos.

dibujo

6.2. Finanzas

6.2.1 - Presupuesto inicial del proyecto

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

Personas que harán parte del proyecto.
Materiales.
Servicios.
Infraestructura.
Capacitación del equipo.
Reservas.
Otros gastos que afecten el desarrollo del proyecto.

Nota: Es responsabilidad del Product Owner y el Patrocinador del proyecto, 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:

6.2.2 - 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.

dibujo

Nota: No todos los proyectos están diseñados para generar utilidades (ganancias), así que en estos proyectos lo que se mide es el valor entregado (beneficios) en algo llamado VOI (Value of Investment)

6.2.3 - 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:

Históricos reales de proyectos anteriores: Esta técnica funcionará siempre y cuando la organización mantenga el registro del esfuerzo y duración reales del proyecto (la técnica más recomendable en Scrum).
Históricos planeados: En los que se cuenta con un estimado original, aunque no se haya tenido un seguimiento a los datos reales (la técnica más común). Esto es por ejemplo el histórico de cotizaciones de proyectos externos o casos de negocio de proyectos no ejecutados o no aprobados.

6.2.4 - Coeficiente de conocimiento del negocio

Esta técnica está basada en la idea de que a mayor conocimiento del negocio/proyecto, más precisa será la estimación del presupuesto. A menor conocimiento 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:

Experiencia en proyectos similares.
Calidad de requerimientos iniciales del proyecto.
Grado de riesgo al que está expuesto el proyecto.
Desviación (%) en las estimaciones de proyecto.

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.

6.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:

Estudiar la viabilidad de las iniciativas de proyectos.
Generar guías de apoyo.
Brindar asesoría a los diferentes Equipos Scrum de la Organización.
Dar seguimiento a los proyectos.
Reportar a la Alta Dirección.
Mantener actualizado el portafolio de proyectos.
Definir los “Criterios de terminado” globales para la organización (Ver sección - Definición de terminado (DoD)).
Por lo general se encarga de guiar las retrospectivas de proyecto.
Garantizar la correcta gestión de las lecciones aprendidas de los proyectos.
No toma decisiones sobre los proyectos, pero funciona como apoyo de consultoría, asesoramiento u orientación para todos los proyectos, programas y portafolios de proyectos de la organización.

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.

Todos los equipos tienen diferente velocidad, así hagan parte del mismo proyecto. A continuación, la fórmula para calcular la velocidad de un equipo Scrum:

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).

6.4. Riesgos

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

Un riesgo es definido como una situación inesperada que puede afectar los objetivos de un proyecto.
Los riesgos pueden tener un impacto tanto positivo como negativo sobre el 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:

Planificar las actividades del personal actual.
Evitar en lo posible los cambios urgentes.
Considerar la contratación de personal o de proveedores externos que puedan aportar a la ejecución de los proyectos.

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:

Usar una herramienta para el seguimiento y control de los proyectos.
Realizar una actualización continua del portafolio de proyectos, para confirmar la entrega de valor.
Monitorear el cronograma y el presupuesto de cada proyecto.

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:

Definir claras y correctas expectativas para todos los involucrados.
Comunicar a tiempo y con el detalle suficiente los compromisos e importancia de la participación de los involucrados.
Mantener siempre informados a los involucrados sobre los avances y/o cambios que puedan tener los proyectos (utilizar un lenguaje sencillo que todos los involucrados puedan entender).
Evitar reuniones que no generen valor o reuniones demasiado extensas que interrumpan significativamente las actividades de los involucrados.
Comunicar siempre los resultados y beneficios logrados con la ejecución de cada proyecto.
Agradecer al equipo involucrado y funcionarios su participación y resaltar la importancia de sus ideas y revisiones.

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:

Realizar transferencia de conocimiento entre los miembros del equipo.
Constituir una base de conocimiento y lecciones aprendidas.
Garantizar la documentación continua.

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:

Al inicio del proyecto: Se identifican los riesgos globales del proyecto, por ejemplo, riesgos relacionados con el presupuesto, el personal, etc.
Los Sprints: Se identifican los riesgos que pueden afectar el desarrollo de ese Sprint particular, por ejemplo, riesgos del producto. Esta actividad se realiza se forma iterativa durante todo el proyecto principalmente en las reuniones de Planificación de los Sprint.

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:

Proximidad = Cantidad de días o fecha estimada en la que se podría presentar el riesgo.
Probabilidad = Medida porcentual que ayuda a determinar la posibilidad de que el riesgo ocurra.
Impacto = Mide el daño que ocasiona el riesgo, suele clasificarse numéricamente según las siguientes categorías: Crítico (6), Muy Alto (5), Alto (4), Medio (3), Bajo (2), Muy Bajo (1)

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:

Identificar la fecha aproximada en la que se presentaría el riesgo. (Considerar que los riesgos más próximos deben ser atendidos primero).
Calcular el factor de exposición (Relación entre probabilidad e impacto) y con este factor, prioriza entre los riesgos más próximos.

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

La respuesta a cada riesgo dependerá de la probabilidad y el impacto del riesgo.
La naturaleza iterativa de Scrum, con sus ciclos de tiempo de respuesta y retroalimentación rápida permite que las fallas se detecten de forma temprana; por lo tanto, hablando en términos prácticos, tiene una función de mitigación natural construida dentro del sistema.
Los riesgos pueden ser mitigados mediante la implementación de una serie de respuestas que pueden ser Proactivas/preventivas o reactivas.

6.3.4.4.1 – Mitigación

La mitigación se enfoca en reducir la probabilidad de ocurrencia o el impacto del riesgo.
Comprende acciones que se toman por adelantado o acciones Proactivas.
Se reduce la exposición al riesgo (probabilidad vs impacto) dentro de límites aceptables para el proyecto.

6.4.4.4.2 – Contingencia

La contingencia se enfoca en definir una respuesta que se utiliza si el riesgo se materializa o se identifican señales de advertencia.
Comprende acciones Reactivas y acciones de monitoreo en caso de que el riesgo sea inevitable.

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.

6.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:

¿Quién solicita el cambio? ¿Por qué? ¿Para qué necesitamos hacerlo?
¿Para cuándo se necesita?
¿Qué tan importante es?
¿Qué pasa si no se realizara/aprobara el cambio?
¿Quién lo va a ejecutar? ¿Qué necesita? ¿Es un empleado o debemos contratar?

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

El Product Owner es el rol responsable de aprobar/rechazar los cambios, sin embargo, en algunas ocasiones cuando los cambios se salen de su conocimiento o están por fuera del alcance definido para el proyecto podrá escalar los cambios a la gerencia de la organización.
Los cambios pueden venir de distintas fuentes, las más comunes son:
- Cambios solicitados por las partes interesadas.
- Solicitudes realizadas por los miembros del Equipo.
- Nuevas tecnologías emergen y es necesario realizar cambios al producto.
- El producto definido comienza a perder vigencia y es necesario cambiar el alcance.

6.6. Diseño de 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:

Crear: Plantear la idea y probar con prototipos de bajo costo.
Medir: Comprobar el interés de posibles usuarios y medir resultados.
Aprender: Con los resultados se decide si se continua con la idea o se cambia algo.

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”.