Universidad Santa María.Carrera de Ingeniería de Informática de Gestión.

Fundamentos del Toolkit de apoyo al Rol deProduct Owner en las metodologías Agiles

AutorJuan Carlos Alonso Holmstron

Profesor Guía de Memoria de TitulaciónLuis Fernando Hevia Rodriguez

Profesor Correferente de Memoria de TitulaciónJuan Pablo Garcia Baquerizo

Memoria para la obtención del título deIngeniero Informático de Gestión

Guayaquil - Ecuador

Diciembre, 2016

Resumen / Abstract

Español

Este trabajo de memoria de título es una investigación que expondrá sobre el cómo poderayudar al desempeño de diferentes personas que se encuentren en un proyecto ágil, Scrum.

Esta investigación demostrará como guiarse utilizando la propuesta de solución, con unaaplicación y con una encuesta para diferentes personas y roles de trabajo; y validar su ayuda.

El resultado será una propuesta de solución y su análisis del desempeño del rol que prota-goniza el Dueño del Producto, el cual es responsable de la visión del producto en el contextomencionado anteriormente y como éste rol debe seguir los principios del manifiesto ágil, en basea Scrum y otras disciplinas similares combinadas.

English

This undergraduate thesis is a research that will expose on the performance of a team ofpeople in a company multicultural, in the context of an agile project, using the SCRUM methodo-logy.

It will show the performance of this foundation, where a case study on an internal project forthe generation of the financial information addressed to the top management. It will display andguide you through the challenges of forming a team work and application of SCRUM to achievebusiness objectives.

The result will be an analysis of the performance of the role that the protagonist, the Owner ofthe Product, which is responsible for the vision of the company in the context mentioned aboveand as this role should follow the principles of the agile manifesto, the basis of SCRUM.

Juan Carlos Alonso Holmstron i

ii

Índice de figuras

1.1. Elaboración Propia: Elaboración Propia Diagrama de Ishikawa, basado en 7S Fra-mework de McKinsey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1. Elaboración Propia: Diagrama de Mapa mental el ambiente del Dueño del Producto 82.2. Pasos para realizar una investigación de una queja (Australia, 2011) . . . . . . . 92.3. Imagen representativo y explicativo de SCRUM (Svinchuk, 2015) . . . . . . . . . 112.4. Elaboración Propia: mix de metodologías ágiles en ciclo de vida del producto digital 122.5. Gráfico de la resolución del Caos (Sutherland, 2014) . . . . . . . . . . . . . . . . 132.6. Características deseables de un Product Owner (Leffingwell and Widrig, 2010) . . 152.7. Habilidades blandas para un liderazgo resonante (Goleman et al., 2014) . . . . . 152.8. Puntos clave para comprometer al StakeHolder (Cobb) . . . . . . . . . . . . . . . 18

3.1. Elaboración Propia: Modelo mental de las herramientas del Product Owner . . . . 243.2. Los elementos de la estrategia del producto (Pichler, 2016) . . . . . . . . . . . . 253.3. Elaboración Propia: Tiempo donde se elaborando los Canvas . . . . . . . . . . . 263.4. Elaboración propia: Elaboración propia: Jerarquía de Misión a Resultados . . . . 293.5. Elaboración propia: Elaboración propia: Mapa Visual de Artefactos . . . . . . . . 303.6. Elaboración Propia: Diagrama de flujo de Datos de Artefactos y Procesos . . . . 34

5.1. Elaboración Propia: Resultados sobre metodologías ágiles más conocidas . . . . 445.2. Elaboración Propia: Resultados de los artefactos más conocidos . . . . . . . . . 445.3. Elaboración Propia: Resultados de los artefactos menos conocidos . . . . . . . . 455.4. Elaboración Propia: Disposición para utilizar el Toolkit . . . . . . . . . . . . . . . 455.5. Diagrama de Continuidad entre el Orden y Caos (Williams and Hummelbrunner,

2010) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.6. Diagrama de estilo de liderazgo(lea, 2015) . . . . . . . . . . . . . . . . . . . . . 495.7. Diagrama Representativo del ciclo y capas del Desarrollo adaptado a (Consulting

and Consulting, 2014) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

A.1. Árbol de Decisión, Este Proyecto puede ser ágil? (Mamoli, 2012) . . . . . . . . . 53

C.1. Product Canvas (Pichler, 2012) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

D.1. Modelo UX Canvas (Crothers, 2013) . . . . . . . . . . . . . . . . . . . . . . . . . 58

H.1. Circuito para el rápido aprendizaje en el MVP (Patton et al., 2014) . . . . . . . . . 67

Juan Carlos Alonso Holmstron iii

Índice de figuras

K.1. Elaboración Propia: diagrama representativo del flujo de trabajo para la genera-ción de reportes financieros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

iv

Índice de cuadros

2.1. Cuadro guía de práctica de lo que se debe y no hacer (Pichler et al., 2010) . . . . 16

3.1. Elaboración Propia: Cuadro de lote de documentos de entrada y salida . . . . . . 33

5.1. Elaboración Propia: Resumen de la simulación de la aplicación de la propuestade solución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.2. Elaboración Propia: Objetivos y preguntas para obtener validación de la propuestapor encuestas a profesionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.3. Elaboración propia: Cuadro de conclusiones Parte 1 . . . . . . . . . . . . . . . . 465.4. Elaboración propia: Cuadro de conclusiones Parte 2 . . . . . . . . . . . . . . . . 475.5. Elaboración propia: Cuadro de roles necesarios . . . . . . . . . . . . . . . . . . . 485.6. Elaboración propia: Cuadro de herramientas necesarios . . . . . . . . . . . . . . 485.7. Elaboración propia: Historia ágil de una Hipótesis . . . . . . . . . . . . . . . . . . 495.8. Elaboración propia: Historia ágil de un Negocio . . . . . . . . . . . . . . . . . . . 505.9. Elaboración propia: Historia ágil de Desarrollo de Usuario . . . . . . . . . . . . . 505.10.Elaboración propia: Historia ágil de Desarrollo de Trabajo (JTBD) . . . . . . . . . 505.11.Elaboración propia: Historia Beneficio (Impacto / Efecto) . . . . . . . . . . . . . . 51

B.1. Lean UX Canvas (Stephan, 2016) . . . . . . . . . . . . . . . . . . . . . . . . . . 54

F.1. Cuadro de Valores y Principios del ’Agile Chartering’ (Larsen and Nies, 2011) . . 62F.2. Cuadro del propósito del ’Agile Chartering’ (Larsen and Nies, 2011) . . . . . . . 63F.3. Cuadro del alineación del ’Agile Chartering’ (Larsen and Nies, 2011) . . . . . . . 63F.4. Cuadro del Contexto del ’Agile Chartering’ (Larsen and Nies, 2011) . . . . . . . . 63

K.1. Elaboración Propia: Cuadro Resumen de la aplicabilidad del Primer Ciclo delDesarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

K.2. Elaboración Propia: Cuadro Resumen de la aplicabilidad del Segundo Ciclo delDesarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

K.3. Elaboración Propia: Cuadro Resumen de la aplicabilidad del Tercer Ciclo delDesarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Juan Carlos Alonso Holmstron v

Índice de cuadros

vi

Introducción

Este documento describe cómo se debe generar un buen producto y el rol del responsable,quien es el encargado de seguir buenas prácticas y velar por la realización de la visión delproducto. Además, se presenta el desarrollo de la creación de un producto y su relación con eldesempeño de un equipo de personas que está cambiando su forma de trabajar en un períodode tiempo. Se describe los variados problemas que se van encontrando cómo; intentar mantenerla velocidad del equipo, también cómo el Scrum Master hace acrobacias para mantener estableel equipo de desarrollo y primordialmente como el Dueño del Producto hace su mejor trabajoante la incertidumbre para entregar valor al cliente y satisfacer sus necesidades.

En el Capítulo 1 se describe sobre cómo llegar a la problemática, del por qué hacer "Toolkitde apoyo al rol de ’Product Owner’"para la creación de una solución y como llevarlo al contextodel desarrollo de software utilizando metodologías ágiles, Scrum.

El Capítulo 2 explica el estado del arte de las metodologías ágiles, con respecto a la funciónde "Dueño del Producto", cómo este papel debe ser interpretado o ejecutarse. Cómo se debemantener las diferentes relaciones que tiene el "Product Owner.en relación a los Stakeholders,al equipo de trabajo y al ScrumMaster en torno (previo, durante y post) al del desarrollo delproducto. También se indicarán las distintas técnicas que deben o podrían utilizar para permitirla creación de un Producto. En resumen, un breve listado del "Toolkit de apoyo al rol de ’ProductOwner’çon una descripción.

El Capítulo 3 propone un conjunto de herramientas, artefactos y buenas prácticas que puedeutilizar el "Product Owner". Este conjunto lo acompaña la necesidad de dar valor al negocio, conla conformación del equipo y roles que se deben asumir. Además, este conjunto propone dar elresultado de un esquema de trabajo o diseño inicial para trabajos de equipo para el desarrolloparticular.

Capitulo 4 es una breve guía de 5 pasos de la implementación de la propuesta de solución;es un criterio de uso de las distintas herramientas que el "Product Owner"puede trabajar quedentro del proceso de su utilización de Scrum.

En el Capítulo 5 se recopila información de encuestas a diferentes profesionales enfocadosen el contexto del Toolkit, indicando que herramientas funcionan y apoyen durante el procesodel desarrollo de sus proyectos y además un resumen del resultado de una simulación real.

En el último capítulo se dará las conclusiones y sugerencias de esta memoria.

Juan Carlos Alonso Holmstron vii

Índice de cuadros

viii

Índice general

Resumen I

Índice de figuras IV

Índice de cuadros V

1. La problemática 21.1. Identificación del Marco del Problema . . . . . . . . . . . . . . . . . . . . . . . . 21.2. Análisis de la información relativa al problema . . . . . . . . . . . . . . . . . . . . 21.3. Impacto inicial de solucionar el problema, y la transcendencia de resolverlo . . . . 31.4. Participantes, interrelaciones, entorno y contexto de la problemática . . . . . . . . 31.5. Definición de la problemática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.5.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.5.1.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . . 51.5.1.2. Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . 5

1.5.2. Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.5.3. Resultados y propuesta de valor . . . . . . . . . . . . . . . . . . . . . . . 5

2. Estado del Arte 82.1. El Problema de satisfacer una necesidad con crear un producto de Software . . . 8

2.1.1. Ventajas del uso Scrum en el desarrollo del producto . . . . . . . . . . . . 102.2. Agilidad sobre Product Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.1. La necesidad de ser un buen Product Owner . . . . . . . . . . . . . . . . 122.2.2. Entendimiento del Rol de Product Owner . . . . . . . . . . . . . . . . . . 132.2.3. Las experiencias necesarias para llegar a ser un Product Owner . . . . . 142.2.4. Características requeridas para poder ser un Product Owner . . . . . . . . 152.2.5. La inteligencia emocional del liderazgo necesaria para Product Owner . . 152.2.6. Breve guía para hacer transición a un Product Owner . . . . . . . . . . . 162.2.7. Las responsabilidades del Product Owner . . . . . . . . . . . . . . . . . . 16

2.3. Agilidad sobre el equipo, el Stakeholder y el ScrumMaster . . . . . . . . . . . . . 172.3.1. Entender al Stakeholder y definirlo . . . . . . . . . . . . . . . . . . . . . . 172.3.2. Pautas para tener un Stakeholder comprometido . . . . . . . . . . . . . . 172.3.3. Pauta para conseguir trabajo en equipo . . . . . . . . . . . . . . . . . . . 182.3.4. Cuestionario el diseño de estructura de equipo de trabajo . . . . . . . . . 192.3.5. Características del ScrumMaster . . . . . . . . . . . . . . . . . . . . . . . 19

Juan Carlos Alonso Holmstron ix

Índice general

2.3.6. Condiciones en que el ScrumMaster se convierte en un problema . . . . . 202.4. Agilidad sobre el Producto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.4.1. Descubrimiento del Producto . . . . . . . . . . . . . . . . . . . . . . . . . 202.4.2. Visualizar el Producto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.4.3. Los meta-principios del Producto . . . . . . . . . . . . . . . . . . . . . . . 21

3. Propuesta solución: herramientas y artefactos 243.1. Estrategia del producto o ciclo de vida . . . . . . . . . . . . . . . . . . . . . . . . 243.2. Modelo de Negocio / Agile Canvas: UX Canvas . . . . . . . . . . . . . . . . . . . 253.3. Carta de Agilidad (Agile Kata) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.3.1. Pautas para Agile Kata . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.4. Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.5. Historias de Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.6. Entregas de Valor y Beneficios al Negocio . . . . . . . . . . . . . . . . . . . . . . 313.7. Modelo de negocio / Lean UX Canvas - Product Canvas . . . . . . . . . . . . . . 323.8. Diagrama de Datos de Entradas y Salidas de artefactos . . . . . . . . . . . . . . 33

4. Guía para la implementación de la propuesta de solución 364.1. Creación de la Estrategia del Producto . . . . . . . . . . . . . . . . . . . . . . . . 364.2. Registrar el modelo de negocios y sus cambios . . . . . . . . . . . . . . . . . . . 374.3. Levantamiento de información para el producto . . . . . . . . . . . . . . . . . . . 374.4. Creación del Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.5. Supervisar y registrar las correspondientes entregas de valor . . . . . . . . . . . 38

5. Evaluación de la propuesta de solución 405.1. Evaluación de la propuesta por simulación práctica . . . . . . . . . . . . . . . . . 405.2. Evaluación y validación de la propuesta por encuestas a profesionales . . . . . . 415.3. Validación y resultados estadísticos de las encuestas profesionales . . . . . . . . 445.4. Conclusiones de la propuesta solución . . . . . . . . . . . . . . . . . . . . . . . 465.5. Recomendaciones para implementarlo . . . . . . . . . . . . . . . . . . . . . . . . 47

Apéndices 52

A. Árbol de Decisión para proyectos Ágiles 53

B. Lean UX Canvas 54

C. Product Canvas 56C.1. Mecánica del Product Canvas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

D. UX Canvas 58D.1. Mecánica del Canvas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

E. El Despegue / LiftOff 60E.1. Propósito, tiempo y KickOff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60E.2. Planificación del LiftOff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

x

F. Chartering 62

G. Formato y ejemplo básico de un Chartering de un proyecto X 64

H. Planificación inicial de las Historias de Usuario 66H.1. Planificar para aprender rápido . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

I. Escribiendo historias de usuarios 68I.1. Estimación de las historias de usuario . . . . . . . . . . . . . . . . . . . . . . . . 69

J. Earned Value Management / Gestión del Valor Conseguido 71

K. Simulación de una aplicación de la propuesta solución en la compañía XYZ 73K.1. La compañía XYZ y su necesidad . . . . . . . . . . . . . . . . . . . . . . . . . . 73K.2. Resolver la necesidad de la compañía XYZ . . . . . . . . . . . . . . . . . . . . . 73K.3. Producto Visibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

K.3.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74K.3.2. Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74K.3.3. Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

K.4. Antecedentes del Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74K.4.1. Antecedentes del Proyecto Visibilidad . . . . . . . . . . . . . . . . . . . . 75K.4.2. Previo al inicio de la ceremonia . . . . . . . . . . . . . . . . . . . . . . . . 75

K.5. Primera Iteración del Ciclo de Desarrollo . . . . . . . . . . . . . . . . . . . . . . 76K.5.1. Incepción Zero - Parte 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 76K.5.2. Incepción Zero - Parte 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 77K.5.3. Incepción Zero - Parte 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 77K.5.4. Incepción Zero - Parte 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 77K.5.5. Día del Demo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77K.5.6. Resultados de la Evaluación . . . . . . . . . . . . . . . . . . . . . . . . . 78

K.6. Revisión y resumen de la aplicabilidad del Primer Ciclo del Desarrollo . . . . . . . 78K.7. Segunda Iteración del Ciclo de Desarrollo . . . . . . . . . . . . . . . . . . . . . . 79

K.7.1. Incepción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79K.7.2. Sprint 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79K.7.3. Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79K.7.4. Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

K.8. Revisión y resumen de la aplicabilidad del Segundo Ciclo del Desarrollo . . . . . 80K.9. Tercer Iteración del Ciclo de Desarrollo . . . . . . . . . . . . . . . . . . . . . . . 81

K.9.1. Revisión y resumen de la aplicabilidad del Tercer Ciclo del Desarrollo . . . 81

L. Encuesta de la propuesta de solución realizada a profesionales 82

Referencias 91

Juan Carlos Alonso Holmstron xi

.

1

Capítulo 1

La problemática

1.1. Identificación del Marco del Problema

Actualmente la compañía XYZ no cuenta con suficiente información con lo que respectaal Rol de "Product Owner", solo existen uno pocos tutoriales que fueron adquiridos para elconocimiento del personal.

La información que se tiene con respecto al Rol de "Product Owner", no se encuentra dis-ponible en un solo lugar; la información como guías de trabajo, herramientas, manuales para lacreación correcta de User Story y Story Mapping, es escasa como indica (Pichler et al., 2010) y(Patton et al., 2014).

Toda esta información se encuentra gradualmente o parcialmente en diferentes sitios, sepuede encontrar en libros, páginas webs, artículos digitales. Sin embargo, existen reunioneso workshops presenciales en donde se capacita, con la promesa de poder ser certificado en"Scrum Product Owner".

La situación se encuentra en un ambiente específico de trabajo. Esta situación es para todaslas personas que adoptan el rol de "Product Owner 2necesitan claridad visual en que comprendelas responsabilidades, las virtudes y/o características que debe tener para asumir el rol, comodebe hacer sus artefactos, que buenas prácticas puede implementar y que guías manualesdebe utilizar para poder abordar la responsabilidad del éxito del producto, saber gestionar lasexpectativas del cliente, y del equipo integrado en su desarrollo.

1.2. Análisis de la información relativa al problema

Existe un alto nivel de comprensión y entendimiento de lo que se necesita. La urgencia detener un esquema de trabajo viene de la mano de la forma va avanzado en la creación delproducto; estratégicamente es muy riesgoso resolverlo sin un esquema.

Actualmente en Chile no existe la formación correspondiente a la necesidad de tener unToolkit de apoyo para el Product Owner, esta información se encuentra en algunos libros. Ysu posible entrenamiento reside en países como Alemania, Estados Unidos y pocas en LatinoAmérica. Llevar la correspondiente aplicación sin orientación o falta de guía que puede llevar alfracaso la creación de un producto.

Juan Carlos Alonso Holmstron 2

1.3. Impacto inicial de solucionar el problema, y la transcendencia de resolverlo

En la institución Kleer1 a través de Scrum Alliance dicta entrenamiento práctico periódica-mente. Entre las entidades más avanzadas esta Pichler Consulting2, en donde se hacen en-trenamientos y lecturas desde un punto de vista global de la gestión del producto, en dondetambién se abarca varios temas acerca del "Product Owner"según (Pichler et al., 2010)

1.3. Impacto inicial de solucionar el problema, y la transcen-dencia de resolverlo

Impactará a todos los clientes que deseen, a través de un desarrollo interno, un productodigital que de real valor al negocio. También a todos los interesados en usar metodologíaságiles, en especial Scrum, quienes necesiten asumir el rol de "Product Owner.o, a su vez, unequipo que necesite designar al representante del producto con los clientes y usuarios.

Resolver la preparación con un "Toolkit de apoyo"para equipos de desarrollo ágiles, ofrecemejor orientación, con respecto a lo que se debe entregar durante el tiempo de desarrollo.Esto visualiza un impacto positivo, siempre y cuando no quiebre un principio ágil ïndividuos einteracciones sobre procesos y herramientas".

1.4. Participantes, interrelaciones, entorno y contexto de laproblemática

El "Product Owner"se relaciona e influye en todos los actores del entorno de desarrollo.Dentro de la mecánica del Scrum, está identificado solo 3 tipos de roles de actores (ProductOwner, Scrum Master y los desarrolladores). Al revisar los grados de relevancia, también seencuentran otros actores, estos corresponden a: "Product Manager 2ÜX Designers". Fuera delentorno de trabajo existe otros roles como los Stakeholders y dentro del nivel de utilización delproducto digital se definen su relevancia de valor de negocio.

En la actualidad las responsabilidades que se han absorbido del rol "Jefe de Proyecto"haciael responsable del cliente (Product Owner), están tomando más foco. Esto lleva al igual que losotros roles, a tener sus propias buenas prácticas y herramientas. Al tomar más foco en esterol, esto se visualiza en el respeto de los valores: comunicación, retroalimentación, confianza,honestidad, colaboración y empoderamiento.

El efecto de refinamiento de este rol, ofrece, al responsable una correcta entrega de valor denegocio al producto que se desarrolla. También tiene como consecuencia, que el producto enconstrucción tenga el éxito esperado.

1Kleer: institución que asiste a organizaciones, equipos y profesionales a través coaching ágil, ver máshttp://www.kleer.la/

2Pichler Consuting: provee entrenamiento y consultoría experta en Gestión Ágil de Productos, ver máshttp://www.romanpichler.com/

3

1.Laproblem

áticaA continuación, en la siguiente ilustración se da una representación de diagrama de causa y efecto, basando en la agru-

pación de factores usando “7S Framework de Mckinsey” 3 . Estos factores nos permiten organizar las causas de necesidadesorganizacionales y suplirlas al efecto de necesidad de “¿Cómo se un Product Owner?”

Figura 1.1: Elaboración Propia: Elaboración Propia Diagrama de Ishikawa, basado en 7S Framework de McKinsey

3McKinsey 7S Framwork; modelo que aporta punto de inflexión del pensamiento acerca de la eficiencia de la organización. Véase más enhttp://www.mckinsey.com/business-functions/strategy-and-corporate-finance/our-insights/enduring-ideas-the-7-s-framework

4

1.5. Definición de la problemática

1.5. Definición de la problemática

El tema que se plantea para realizar esta memoria es:�� ��“ Fundamentos de un Toolkit de apoyo al Rol de ‘Product Owner’ en las metodologías ágiles ”

1.5.1. Objetivos

1.5.1.1. Objetivo General

Construir los "Fundamentos de un Toolkit de apoyo para el ’Product Owner’ en las metodo-logías ágiles".

1.5.1.2. Objetivos Específicos

• Definir el rol de "Product Owner 2sus responsabilidades.

• Determinar las herramientas que están alcance al rol de "Product Owner"

• Describir y detallar guías, manuales y buenas prácticas para el rol de "Product Owner"

• Evaluar el Toolkit de apoyo para el "Product Owner"

1.5.2. Alcance

El desarrollo de "Fundamentos del Toolkit de apoyo al Rol de ’Product Owner’çontendráguías de trabajo, manuales de las herramientas, y buenas prácticas.

1.5.3. Resultados y propuesta de valor

“ “We’re filling product owner slots internally, without much regard to skills orlong-term success. Or leaving these slots open for development teams to fill asthey may. That s a road to market failure. We need to be thoughtful, intentional

and organizationally savvy about picking and mentoring product owners.”

Rich Mironov (Mironov, 2014)”Debido a todos los puntos anteriormente mencionados, se propone lo siguiente:

Desarrollar "Fundamentos del Toolkit de apoyo para el rol ’Dueño del Producto’ 2definirlacompletamente. Este Toolkit debe rescatar del ambiente de trabajo, herramientas, buenas prác-ticas, etc., y tratar de aplicarlo durante el desarrollo de la Compañía XYZ. Con el fin de conseguirun producto exitoso y su entrega de valor de negocio.

Los Fundamentos del Toolkit, ya propuesto, podrán responder lo siguiente:

• ¿Quién representa a los clientes y usuarios en la compañía?

5

1. La problemática

• ¿Quién identifica y descubre las necesidades de los clientes y la funcionalidad del produc-to?

• ¿Quién lidera las actividades de la visión, y quien lidera las actividades que traen la visiónrealizada?

• ¿Qué roles hacen el equipo de trabajo y las decisiones colaborativas juegan?

• ¿Qué es lo necesario para implementar este rol de Dueño de Producto?

6

1.5. Definición de la problemática

7

Capítulo 2

Estado del Arte

Para mostrar el estado del arte del “Product Owner” se presentará en un diagrama mapamental.

Figura 2.1: Elaboración Propia: Diagrama de Mapa mental el ambiente del Dueño del Producto

2.1. El Problema de satisfacer una necesidad con crear unproducto de Software

“ “I don’t skate to where the puck is. I skate to where the puck is going.”

Wayne Gretzky (Hoover, 2011)”Si hacer bien un software es problemático, también crear bien un producto es un problema.El problema de crear un producto no es simplemente tomar una idea y hacerla un producto, odiseñar un artefacto que se pretende que es la respuesta a un problema.

Juan Carlos Alonso Holmstron 8

2.1. El Problema de satisfacer una necesidad con crear un producto de Software

Crear bien un producto es la creación de la resolución de un problema.

“ “A big part of knowing how to go about solving a problem is: understanding whatneeds fixing in the first place, creating the base to solve said problem, and

prioritizing that feature list. For every product I start, I spend a lot of time educatingand submerging myself into that world as much as possible.”

Cat Noone (Noone, 2015)”Hay que definir la base de lo que es la problemática. Y para sumergirte en el problema, si esque es un problema para resolver, se deberán buscar las quejas asociadas a este problema. Ypara lo cual se sugiere seguir estos 6 simple pasos:

Figura 2.2: Pasos para realizar una investigación de una queja (Australia, 2011)

Una vez que se haya reconocido las quejas del problema que se desea resolver, es tiempode analizar y reflexionar. El resultado de aquella reflexión nos da la posibilidad de crear un pro-ducto, pues se tiene la oportunidad de innovar, en este caso particular desarrollar una aplicacióntecnológica.

Desde este punto de vista, la cual no es una tarea fácil, proponer diseñar un producto queresuelva una necesidad.

Al crear un producto, usando metodologías ágiles, es donde se envuelve la problemática y sereconoce lo siguiente: errores comunes al desarrollar un producto y los problemas relacionadosa ellos. Estos problemas lo vamos a mencionar:

• Los errores comunes más conocidos en desarrollar son (Design, 2011):· No llevar adelante una correcta investigación de mercado.· Ir directamente al desarrollo de productos sin elaboración de estrategias y la concep-

tualización.· Centrarse en las características en lugar de los beneficios.· Subestimar los costos y los plazos con los prototipos.· Mal entendimiento con los requisitos reglamentarios.

• Los problemas relacionados con el producto son (Atkinson, 2016):· Exceso de requerimientos.· Cambio de las prestaciones (plantear demasiados objetivos a la vez).· Desarrollo meticuloso (requerimientos inestables).· Tiras y aflojas en la negociación.· Resolver un problema es resolver una necesidad.

9

2. Estado del Arte

Las metodologías agiles prometen, debido a su mecanismo de interacción, crear bien un pro-ducto digital. Para que el proyecto, sea un proyecto ágil debes considerar lo siguiente (Mamoli,2012):

• ¿Tú entregable es una aplicación de software?• ¿Existe incertidumbre en el entorno de lo que vas a construir?• ¿Existe incertidumbre sobre la complejidad de lo que se va a resolver?• ¿Existe la oportunidad de realizar cambios y adaptar durante el proyecto?• ¿Existe alto riesgo en el proyecto?

Al responder afirmativamente cualquier de estas preguntas, se puede seleccionar cualquierade las metodologías ágiles disponibles. En el proyecto se tomó una combinación entre Lean UXa Scrum (véase más en el Árbol de Decisión4 o Apéndice A )

2.1.1. Ventajas del uso Scrum en el desarrollo del producto

El punto de vista del usuario es uno de los más importantes, la recopilación de requisitospara crear un producto que resuelva una necesidad, se realiza teniendo en cuenta la visión delcliente y del usuario. Esta necesidad se puede resolver con prácticas que permiten recoger losrequisitos en forma correcta, que en definitiva se pueden traducir en unidades de trabajo cono-cidas como historias de usuario (clientes, u otros). Las historias de usuario son unas sencillastarjetas nemotécnicas en la que se almacena de forma esquemática y en un lenguaje claro todala información.

Aunque las historias del usuario son una técnica que se encuentra en diversas metodologíaságiles, para este caso práctico se utilizara Scrum.

En la metodología ágil Scrum, además de resolver el proceso de desarrollo de software, conlos roles actuales que maneja, también permite fabricar bien un producto, con una adecuadainteracción.

Usando Scrum, en este caso particular, él "Product Owner"genera un esquema al cual vi-sualiza "todo el enfoque del producto", çentrado en el cliente 2de financiación del desarrollo enforma iterativa.

En un punto de vista práctico. Para descubrir el momento adecuado en usar Scrum y versemás justificable como indica (Pichler, 2016). Es con la demostración de la visualización de lacurva de ciclo de vida estratégico del producto cuando se lanza hasta llegue "Product MarketFit"5.

Y usando la misma propuesta visual; el uso de metodologías ágiles a utilizar para ProductOwner, se agrega un contexto del cono de incertidumbre y optimización del flujo aplicado en elmantenimiento. Y se visualiza la figura 2.4:

4Árbol de Decisión: es un diagrama de flujo sobre uso de metodologías ágiles véase más en http://nomad8.com/should-this-project-be-agile/

5Product Market Fit (PMF): es término utilizado cuando el producto está listo para servir a la corriente principaldel mercado, véase más en: https://leanstack.com/achievingproductmarketfit/

10

2.1. El Problema de satisfacer una necesidad con crear un producto de Software

Figura 2.3: Imagen representativo y explicativo de SCRUM (Svinchuk, 2015)

A razón, entre más compatibles se envuelven las distintas metodologías, según el periododel ciclo de vida, se requiere que el Product Owner tenga como liderazgo y conocimiento un granset de herramientas metodológicas, artefactos de apoyo y tener desarrollado las habilidadesblandas principalmente.

Lean UX nos permite aterrizar, no eliminarla la incertidumbre. La incertidumbre alrededor dela propuesta de la creación del producto que se está buscando. Para pronosticar de tiempo eldesarrollo que se necesita la mejor metodología a utilizar es Scrum, según (Svinchuk, 2015),mientras lleve a un alto nivel de incertidumbre. Una vez disminuida la incertidumbre, para lamejor mantención del producto, es utilizar la metodología Kanban conllevado con la capacidadde trabajo más limitado y disponible a largo plazo.

Otra de las bondades del Scrum, está en sus fundamentos de costos, mejora de produccióny tiempos de entrega. Uno de los casos precursores que cuentan con estas ventajas, es el casodel desarrollo del "Proyecto Sentinel", que es notablemente comprobado en el libro de "Scrum:The art of doing twice the work in half the time"de (Sutherland, 2014) y demuestra el factordiferenciador de los costos entre el mismo proyecto con uso de la metodología cascada conscrum.

Este caso determina que el nivel de caos o incertidumbre es más alto, y muestra las defi-ciencias de la metodología Cascada versus Ágil en los costos.

Desde 2006 hasta el 2010 este proyecto llego a costar hasta $401 millones de dólares,utilizando la metodología cascada obteniendo un éxito de solo 14 %. Y desde 2010 hasta 2011costo $35 millones de dólares con un éxito del 42 %.

11

2. Estado del Arte

Figura 2.4: Elaboración Propia: mix de metodologías ágiles en ciclo de vida del producto digital

2.2. Agilidad sobre Product Owner

2.2.1. La necesidad de ser un buen Product Owner

“ “Quality is more important than quantity. One home run is much better than twodoubles.”

Steve Jobs (Beahm, 2011)”En los enfoques antiguos, durante el proceso del desarrollo de software, al no realizar pron-tas entregas de valor se aumenta el riesgo de la aceptación del producto por parte del cliente.Por esta razón el rol nace de forma necesaria para no malinterpretar los requerimientos, eliminarla falta de dirección, propósito e invalidar suposiciones.

El Product Owner es resumen, finalmente, es mucho más que un recopilador de requeri-mientos. Este rol es mucho más de lo pensado. Además, se convierte en un rol de tiempocompleto.

12

2.2. Agilidad sobre Product Owner

Figura 2.5: Gráfico de la resolución del Caos (Sutherland, 2014)

Este rol también tiene errores de percepción al revisar sus responsabilidades, hay erroresen enfrentar correctamente sus responsabilidades y/o errores concebidos por las empresas ylo que hacen al respecto es tener un supuesto "Product Owner". Es así como se enlistaron losproblemas sobre el producto, brevemente se indicarán los problemas sobre el rol de "Dueño deProducto".

Los errores comunes son (Pichler et al., 2010):

• La falta de poder para desenvolverse.• El tenerlo con exceso de trabajo.• Se sitúa parcialmente.• El estar distante del equipo.• El tener un asistente, en vez de su completa funcionalidad.• Al tener un comité, o varios en el mismo.

Hay que destacar lo siguiente, que los más graves son:

• ¿Cuándo varios o cualquiera asume este rol sin previo entrenamiento?• ¿Cuándo hay ausencia o distanciamiento del equipo?

Estos errores pueden ser garrafales en el momento de crear un producto digital. Pero, unavez ya sucedido estos errores se deben corregir solo asignando únicamente a la persona alcual haya mantenido correctamente la visión del producto, ofreciendo entrenamiento y todos losmecanismos para continuar con sus funciones y responsabilidades.

Arrancar de raíz el liderazgo del benefactor de la creación de la visión del producto, puedeconllevar a la eliminación de la continuidad de la creación del producto.

2.2.2. Entendimiento del Rol de Product Owner

Para entender la existencia de este rol regresemos hacia la metodología clásica que habíaantes. Según (Eriksson, 2015) desde 1930 hasta 2010 se manejaba a través de Gestor deProducto, Gestor de Marketing y Gestores de Proyectos y la visión del producto ha pasado portraspasos de muchos actores.

13

2. Estado del Arte

El peso de trabajo que tiene el "Product Owner"no solo rinde en la investigación del mercado,sino también en la visión del producto. Esta visión es solo un modelo conceptual que se entregaal "Gerente del Producto". El "Gerente del Producto"lleva esta visión y escribe los requerimientosdel producto. Para así después traspasar la visión del producto al "Gestor de Proyectos". El"Gestor de Proyectos"toma la visión y administra los requerimientos con el equipo de desarrollo.

En este punto nadie del circuito es responsable de la visión del producto, y también la visióndel producto ha cambiado. La visión del producto no alcanza a mantenerse ni ser correspondien-temente compartida. Debido a esta razón en las metodologías ágiles se haya el rol de "ProductOwner", un rol con autoridad y responsabilidad de ser dueño de la visión del producto y más(Pichler et al., 2010)

El rol de "Product Owner"se ve resumido en sus responsabilidades y tareas, además delos artefactos y métricas que debe elaborar, y las habilidades duras y blandas que sostiene. Esimportante que sus habilidades blandas se encuentren en completo desarrollo con la inteligenciaemocional para liderar según (Goleman) el desarrollo del producto.

A brevedad, para concebir la función de "Product Owner"se debe conseguir cuatro roles deexperiencia.

2.2.3. Las experiencias necesarias para llegar a ser un Product Owner

Las experiencias necesarias que se deben obtener para lograr ser un Product Owner estadescubierto en un paquete de 4 diversas experiencias estos son (Galen, 2013):

• 14 Jefe de Producto: Para entender profundamente y ampliamente la necesidad del negociohacia el producto y crear una visión compartida en donde el mercado es participe de subeneficio.

• 14 Jefe de Proyecto: Guiar el período del trabajo, la relación del propuesto versus la veloci-dad del equipo, y cumplir con varios objetivos. Cumplir estos objetivos vía negociar y crearpasos para lograr exitosamente la entrega de valor.

• 14 Analista de Negocios: Define e involucra correctamente los requerimientos del negocio.Para que el equipo lo pueda llevar a cabo y fomente la colaboración entre arquitectos,desarrolladores, controladores de calidad y demás.

• 14 Líder: Motivar a los miembros del equipo. Proporcionando metas y objetivos posibles decumplir. Defiende al equipo y quita impedimentos relevantes.

De estos el más importante es el líder, ya que es el liderazgo es esencial en todo el trayectoy duración de la creación del producto

14

2.2. Agilidad sobre Product Owner

2.2.4. Características requeridas para poder ser un Product Owner

Básicamente se requiere las ciertas características deseables son (Leffingwell and Widrig,2010):

Figura 2.6: Características deseables de un Product Owner (Leffingwell and Widrig, 2010)

2.2.5. La inteligencia emocional del liderazgo necesaria para Product Ow-ner

(Irene, 2014) El liderazgo tiene 2 formas de llegada ante el equipo, son disonante y resonan-te. Para las características del Product Owner, es necesario que sea resonante. Y para que searesonante se requiere un nivel amplio de habilidades blandas descritas en la figura 2.7 (Golemanet al., 2014)

Figura 2.7: Habilidades blandas para un liderazgo resonante (Goleman et al., 2014)

Estas habilidades blandas serán muy necesarias también cuando se requiera un estilo deliderazgo. Según el marco cynefin6, en el ambiente de desarrollo

6Cynefin: clasifica los problemas que enfrentan los líderes en cinco contextos definidos por la naturaleza de larelación entre causa y efecto, véase mas http://www.designthinking.es/comparte/view.php?id=289

15

2. Estado del Arte

2.2.6. Breve guía para hacer transición a un Product Owner

Para hacer la transición a un Product Owner, además de conseguir la experiencia, las habi-lidades blandas. Obtener una visión y desarrollar la transcripción de las historias de usuario. Esescencial apoyarse en un cuadro de lo que se debe y no se debe practicar lo que ayudará en eldía a día del desarrollo (Pichler et al., 2010):

DEBES HACER NO DEBES HACERDecir ¿Que es lo que necesitas para lograrlo? Decir ¿Cómo debes hacerlo?, o, ¿Cuánto tiempo debes hacerlo?Desafía al equipo Hacer Bullying al equipoInterésate en construir un equipo de alto rendimiento Enfocarte en cortos plazos de entregaPractica pensamiento motivador de entrega de valor de negocio Quedarse en el alcance original sin importar que.Protege al equipo de ruido externo Preocupar el equipo de cambios que talvez puedan suceder, hasta que sean realIncorpora un cambio entre Iteraciones Permitir cambios influencien en la iteración

Cuadro 2.1: Cuadro guía de práctica de lo que se debe y no hacer (Pichler et al., 2010)

2.2.7. Las responsabilidades del Product Owner

La definición de las responsabilidades del "Product Owner.están entre: lo básico que debehacer, lo que debe resistir en realizar y una guía de buenas prácticas para lograr sus responsa-bilidades a cabalidad, esto son:

• Las responsabilidades del Product Owner (Mamoli, 2014) son:· Primarias

1. Asegurar que el equipo construya el producto correcto.2. Asegurar que los beneficios del negocio sean entregados.3. Priorizar las características del producto y ajustar su alcance en forma correcta.4. Siempre tener informados a los Stakeholders/Product Partners.5. Asegurar que los impactos de los cambios sean medidos y entendibles.

· Ante el equipo1. Comunicar la visión del producto ante el equipo.2. Motivar al equipo con la visión del producto.3. Comunicar los beneficios del producto y sus características.4. Crear, priorizar y mantener "Product BackLog".5. Definir las entregas y las metas de las iteraciones.6. Responder preguntas que agreguen detalle a las historias de usuario.7. Aceptar o rechazar las historias de usuario desarrolladas.8. Ser el único punto de contacto de las preguntas.9. Tratar de involucrar a otros

• Las responsabilidades que debe evitar el “Product Owner” según (Szalvy) son:· Evitar la micro-gestión (esto es muy común en el estilo liderazgo ejemplificado)· Agredir el espíritu del equipo (esto es muy común en el estilo de liderazgo coercitivo)

16

2.3. Agilidad sobre el equipo, el Stakeholder y el ScrumMaster

• Guía de buenas prácticas para poder conseguir bien sus responsabilidades según (Galen,2013) es:

· Siempre ser activo en la gestión del Backlog del Producto.· Contestar a preguntas cuando aparezcan.· Siempre entregar retroalimentación.· Solo tomar los resultados de las historias terminadas del trabajo.· Comprender las necesidades del cliente.· Ser activo en la gestión de los StakeHolders.· Tener un conocimiento básico de cómo el software es desarrollado e implementado.

2.3. Agilidad sobre el equipo, el Stakeholder y el ScrumMas-ter

2.3.1. Entender al Stakeholder y definirlo

De las técnicas existentes hay dos técnicas (McDonald, 2015) que proporcionan el mejorentendimiento de las personas que van a utilizar el producto y que entregan valor. Este ejerciciose llama .Análisis de Usuario"previo del .Análisis del Stakeholder"

• Análisis del StakeHolder; es el acto de entender a los Stakeholders, usualmente tiene lameta de investigar y comprender la mejor forma de comunicarse, participar y trabajar conellos. Las dos técnicas de análisis que conlleva son:

· Mapear los Stakeholders por relatividad e interés para decidir cómo comprometersecon los mismos.

· Escala de compromiso guía para conocer sobre el nivel que los Stakeholders apoyanel proyecto.

• Análisis del Usuario; ayuda a entender cómo el usuario va a utilizar la solución, que eslo que puede hacer, y en qué ambiente lo va a utilizar. Esta información sirve para guiarlas decisiones de diseños y estructurar los permisos de las acciones de las personas enel producto. Las dos técnicas que conlleva este análisis son:

· Modelamiento del Usuario; estructura las conversaciones sobre los roles de los usua-rios involucrados en la solución. En una orden de lista para ser utilizado en la organi-zación e identificación de las funcionalidades.

· Modelo de Persona; ayudan al equipo a entender el contexto en el cual la soluciónfunciona, y además a guiar a las decisiones de diseños y su experiencia.

2.3.2. Pautas para tener un Stakeholder comprometido

Comprometer actuales y futuros intereses de las partes involucradas mediante la construc-ción de un entorno de confianza que se alinea con sus necesidades y expectativas. Balancearlas peticiones con una comprensión a la relación coste/esfuerzo involucrado. Promover la parti-cipación y colaboración de todo el ciclo de vida del producto, proporcionando las herramientaspara una eficaz toma de decisiones informadas (Cobb) en la figura 2.8

17

2. Estado del Arte

Figura 2.8: Puntos clave para comprometer al StakeHolder (Cobb)

Asegurar la involucración y manejar su expectativa dependerán mucho que tan exitoso sea elProduct Owner para entregar valor y beneficios al negocio, además que tan activo es su gestión.

2.3.3. Pauta para conseguir trabajo en equipo

Previo a iniciar la creación de la Çarta de Agilidad"(ver 3.3 ), en el momento en formar unequipo de trabajo es necesario conocer un buen trabajo en equipo.

Existen muchas formas de organizarse los equipos de trabajo dentro del desarrollo ágil(Burn, 2013) son: componentes, características, producto; que asisten solo al cliente. (Cohn andLister, 2009) Y debido a esto existen varias técnicas, sugiriéndose que para tener correctamenteun equipo que se auto-organice se deben tener los siguientes elementos:

• Incluir personas de todas las disciplinas necesarias: como un equipo multifuncional, esimportante tener personas de todas las habilidades para plasmar la idea en una caracte-rística y no importa que el equipo sea más grande de lo deseado.

• Balancear los niveles de habilidades técnicas: se debe equilibrar los niveles de habilidaden el equipo. Un miembro del equipo con pocas habilidades se lo puede nivelar con "pairprogramming"7, y así obtener beneficios con mejores habilidades.

• Balancear el dominio de conocimiento: no es necesario armar un equipo que tenga todoel conocimiento, más bien se debe considerar los objetivos a largo plazo. Uno de estosobjetivos es la acumulación del dominio del conocimiento.

• Buscar diversidad: la diversidad de pensamiento ayudará a la resolución de problemas ytoma de decisiones; lo importante es tener un equipo equilibrado entre heterogeneidad yhomogeneidad de pensamiento.

• Considerar la posibilidad de la persistencia: los miembros del equipo deberán ya habertrabajado en el pasado y conocer que haya sido una buena experiencia. Al formar unequipo se debe considerar que los miembros trabajarán juntos por largos periodos o comoresultado se tendrán compromisos dispersos.

Hay diferentes estructuras de equipo, las que se puede mencionar según (Harrin, 2013) sonlas siguientes: generalista, especialistas, transición, biatlón, y por entrega.

7Pair Programming: requiere que dos programadores participen en un esfuerzo combinado de desarrollo enun sitio de trabajo, ver más https://es.wikipedia.org/wiki/Programacion_en_pareja

18

2.3. Agilidad sobre el equipo, el Stakeholder y el ScrumMaster

2.3.4. Cuestionario el diseño de estructura de equipo de trabajo

Para validar los elementos del equipo de trabajo hay un cuestionario diseñado (Cohn andLister, 2009). En el cual se valida el diseño del equipo de trabajo con un cuestionario y que debevelar que siempre se pueda responder ’Si’ en él.

• ¿La nueva estructura acentúa las fortalezas, acosta de las debilidades del equipo y apoyaa la motivación de los miembros del equipo?

• ¿La nueva estructura minimiza la cantidad de personas en el equipo para ser de dospersonas?

• ¿La nueva estructura maximiza la cantidad del tiempo para que el equipo se mantengajunto?

• ¿Si los componentes del equipo usan solamente casos fáciles y limitados?• ¿Podrás alimentar al equipo con dos pizzas?• ¿La nueva estructura minimiza el número de canales de comunicaciones entre equipos?• ¿La nueva estructura motiva al equipo a comunicarse, y sino por qué?• ¿El diseño del soporte aclara la rendición de cuentas?• ¿Uno de los miembros del equipo tiene retroalimentación que pueda participar en el diseño

del equipo?

La finalidad de esto es que el equipo de trabajo llegue a lograr con sus habilidades blandaslas siguientes metas propuestas como equipo experimentado son (DeMarco et al., 2013) :

• Dar un culto a la calidad del producto.• Proporcionar mucho cierre satisfactorio a cada iteración.• Tener un sentido de élite como equipo.• Tener y fomentar la heterogeneidad de los individuos.• Preservar y proteger los equipos exitosos y su continuidad.• Proporcionar dirección estratégica, pero no táctica ante el producto.

2.3.5. Características del ScrumMaster

El facilitador del equipo y apoyo del Product Owner, debe tener características especialesque le permitan realizar correctamente (Watts, 2013):

• Ingeniosos en la eliminación de obstáculos a la productividad del equipo.• Resolver y ayudar a otros a ser más efectivo.• Discreto, ser la diplomacia personificada.• Respetado, saber de integridad, tanto dentro del equipo hacia la organización en general.• Alternativo, preparado para promover una contra-cultura.• Inspirar, generar entusiasmo y energía en los demás.• Nutrir, tanto como a los individuos como al equipo.• Empático, sensibles a aquellos alrededores del equipo.

Sin estas características deja de asistir a la interacción con el equipo. Pero también hay otrascondiciones en que el ScrumMaster llega también ser un problema y no un facilitador.

19

2. Estado del Arte

2.3.6. Condiciones en que el ScrumMaster se convierte en un problema

Las condiciones en que el ScrumMaster se convierte en un problema según la compilacióny sus situaciones pueden ser (Gomez, 2009) :

• En el momento en que se compromete a cumplir con el "Sprint BackLog"8.• No permitir su auto-organización de tareas, y a su vez indicar al equipo lo que debe hacer

en las tareas.• Actuar como proxy o intermediario entre el Product Owner y el equipo.• No solo debe registrar los impedimentos, sino también anticiparse a que hayan.• Las tareas que realizan son dependientes al equipo.• Incorporar nuevas funciones que correspondan de otros.

2.4. Agilidad sobre el Producto

La agilidad sobre el producto es parte clave del Toolkit, donde por un proceso hace la pesqui-sa de información para la Çarta de Agilidad", una de las herramientas para el "Product Owner".Se revisará como descubrirlo, visualizarlo y los meta-principios que puede cumplir.

2.4.1. Descubrimiento del Producto

Un producto digital en los proyectos de software puede ser definido en dos fases (Cagan,2008):

• Primera fase trata solo de dominar el descubrimiento.• Segunda fase como poder ejecutar el descubrimiento.

En la ejecución del descubrimiento del producto hay varias metodologías, entre ellas, quedan los mejores resultados son: "Design Thinking"9, "Lean 2ÜX". Realizando prototipos, crearun wireframe10, u otros elementos son importante para reconocer que hay una predefinición deuna propia y única preferencias y habilidades de implementación en el proceso.

Otros puntos clave que ayudan en el proceso de descubrimiento son:

• El proceso de descubrimiento no es predecible como se desea.• Los recursos son restrictivos y limitados en el desarrollo de software dentro de una orga-

nización en los ingenieros, aun así, el equipo podría estar detenido. Esto hace que lasunidades de gestión pierdan motivación.

8Sprint BackLog; una visión general de la labor de desarrollo para realizar un Sprint a la meta, normalmenteun pronóstico de la funcionalidad y el trabajo necesario para ofrecer esa funcionalidad.

9Design Thinking; Es una metodología para generar ideas innovadoras que centra su eficacia en entender y darsolución a las necesidades reales de los usuarios, véase más http://designthinking.es/inicio/index.php

10Wireframe; es una representación visual de una página web que demuestra donde cada artefacto debe serpuesto

20

2.4. Agilidad sobre el Producto

2.4.2. Visualizar el Producto

Para visualizar el producto, o bien los resultados del desarrollo, es necesario que la visiónestimulé a las personas como objetivo general; los impulsé y los guie a la razón de ser delproducto.

Desde el proceso del Scrum (Pichler et al., 2010) : realizando demos de forma incrementalal cliente y a los usuarios, ofreciendo publicaciones tempranas (fallar pronto) de forma frecuentey válida; ayuda a clarificar la expectativa sobre la visión del producto.

Los valores que logran obtener una buena visualización son:

• Compartir y unificar la visión: involucrando a todos en el esfuerzo de desarrollo para con-seguir la visión.

• Amplio y atractivo: el objetivo guía los esfuerzos del equipo, pero a su vez debe dejarespacio para su creatividad. También se debe resistir a la tentación de dar detalles odesarrollar especificaciones del producto.

• Corto y dulce: la visión debe ser breve y concisa, solo debe contener la información críticapara el éxito del producto.

En el siguiente cuestionario, estos valores, dan una visión efectiva:

• ¿Quién va a comprar el producto?, ¿Quién será el cliente?, ¿Quién va a utilizar el produc-to?, ¿Cuáles son los usuarios que vamos a ayudar?

• ¿Cuáles son las necesidades que el producto va a satisfacer?, ¿Qué valor agrega el pro-ducto?

• ¿Cuáles son los atributos críticos del producto para que comprometen las necesidadesseleccionadas y comprometerán el éxito del producto?

• ¿Cómo el producto se compara con otros productos existentes?• ¿Cómo ganará la empresa por vender el producto?, ¿Cuáles son las fuentes y que modelo

de negocio tiene?• ¡El producto es factible!, ¿Puede la compañía desarrollarlo y vender el producto?

Las respuestas de estas preguntas ayudan a poder empezar a crear los principios y estrate-gias del ciclo de vida del producto.

2.4.3. Los meta-principios del Producto

Los meta-principios son como una plantilla, es un set de objetivos que están implícitamenteheredados a los valores de los resultados del producto. Deben ser suficientemente específicospara medir la investigación, decisiones, artefactos y su resultado.

Los principios, o meta-principios, del producto son (Grainer, 2015):

• Ser suficientemente específico para medirlo.• Trabajarse a través del proceso del producto.

21

2. Estado del Arte

• Inspirar al equipo para crear mejores resultados.• Desafiar la mediocridad y no dar resultados a medias.• Ser simple y memorable.• Diferenciarse a los productos de los competidores, si es que tuviese.

22

2.4. Agilidad sobre el Producto

23

Capítulo 3

Propuesta solución: herramientas y artefactos

Dentro de las herramientas están las siguientes:

Figura 3.1: Elaboración Propia: Modelo mental de las herramientas del Product Owner

Cada una de estas herramientas pueden ser o no implementadas a su totalidad. Toda he-rramienta tiene como finalidad producir un artefacto. Aunque previo a los principios de agilidadde procesos sobre interacción de personas, tiene objetivo de asistir y documentar el proceso deAgilidad.

3.1. Estrategia del producto o ciclo de vida

Como parte consecuente de la visualización del producto, el artefacto .Estrategia del Producto.es

un plan de alto nivel. Según (Pichler, 2016) describe para quien es el producto, quien quierecomprarlo y utilizarlo; lo que es producto, por qué se destaca y porque es valioso invertir en él.

Tener claridad sobre las metas del negocio permiten conseguir correctos KPI’s que puedanmedir el rendimiento del producto. La estrategia del producto no es un plan rígido, este cambiamientras el producto crece y madura. Debido a lo antes expuesto se debe revisar y ajustar laestrategia del producto periódicamente.

La estrategia del producto se divide en tres fases:

• Fundamentos.• Desarrollo.

Juan Carlos Alonso Holmstron 24

3.2. Modelo de Negocio / Agile Canvas: UX Canvas

Figura 3.2: Los elementos de la estrategia del producto (Pichler, 2016)

• Validación.

Uno de los artefactos pilar que ayuda al direccionamiento de la estrategia del producto es el"Lean UX Canvas"11 para el largo plazo y durante el corto plazo dentro desarrollo del productoes el "Product Canvas"12 y para el descubrimiento del producto ÜX Canvas"13.

Los artefactos de "Lean UX Canvas 2sus posibles extensiones de canvas ÜX Canvas 2"Pro-duct Canvas"pueden ser obtenido después de realizar dentro del proceso conocido .Agile Ka-ta"(véase más en 4.1.- ), esto se realiza en el tiempo previo al desarrollo, muchos le llaman a laceremonia Ïncepción.o "Sprint Zero".

Desde el proceso de inicio y evolución del producto para registrar su estrategia es opcio-nal guardar la información más relevante en un artefacto desarrollado por Pichler Consultingconocido como "Tablero de Visión del Producto".

3.2. Modelo de Negocio / Agile Canvas: UX Canvas

Modelar el negocio dentro de varios procesos y metodologías de agilidad puede perder losobjetivos del negocio. Varias metodologías dan una breve dirección de cómo usarlas, pero hayque detenerse en cierto momento y validar que la innovación es rentable.

Crear un modelo de negocios antes del desarrollo del producto es el momento más idóneo.La preferencia dentro de las metodologías es encontrar el modelo Canvas, es mejor un modeloque pueda cambiar durante la construcción viable del producto, para lo cual se propone utilizarLean; dado que tiene la forma ágil de descubrir el modelo centrado al usuario, de fallo rápido,que estén dispuesto a rentabilizar.

Para mantener la misma metodología, el artefacto disponible es "Lean UX Canvas", esteartefacto engloba todos los cambios importantes del negocio.

11Lean UX Canvas: es un diagrama del modelo de negocio basado en el uso de las metodologías Lean y UX,véase más en el apéndice B

12Product Canvas: es un diagrama ofrecido por Pichler Consulting para el rescate de valor del negocio, véasemás en el apéndice C

13UX Canvas: es una forma de obtener la correcta estrategia del producto durante su descubrimiento, véase másen el apéndice D

25

3. Propuesta solución: herramientas y artefactos

Figura 3.3: Elaboración Propia: Tiempo donde se elaborando los Canvas

Para la primera parte del "Lean UX Canvas"se puede realizar previo o al principio que se varealizando la .Agile Kata"del Proyecto. Se puede extender usando el UX Canvas con los "ProductPartner", este proceso se puede realizar antes o en paralelo de Incepción. Lo que es importantees que la información que conlleva a realizar el UX Canvas sea siempre transmitida al equipode desarrollo.

3.3. Carta de Agilidad (Agile Kata)

“Agile Kata”15 es uno de los artefactos más importantes en el inicio de cualquier proyecto deagilidad. Tiene mucha preparación, planificación, ejecución parcializada en periodos y ademásdebe permitir cambiar en el tiempo bajo negociación de todos los participantes dentro y fueradel proyecto. En el inicio del “Agile Kata” esta la agilidad del producto, llevando a la secuencia

15Agile Kata; en la gestión de lean se refiere a dos comportamientos: mejorar kata y coaching kata, véase másen http://www.lean.org/lexicon/kata

26

3.3. Carta de Agilidad (Agile Kata)

del “LiftOff”16, “KickOff”17 y su “Chartering”18.

Dependiendo de la naturaleza del producto "LiftOff 2"KickOff"pueden realizar más de una vezen el ciclo estratégico del producto, ya que estos van a representar la evolución del producto.

LiftOff (Larsen and Nies, 2011) ; es una actividad inicial del proyecto. Típicamente suelenempezar con una sesión que clarifica las direcciones, visión - misión - objetivos, de alto nivel ysus intenciones. Para conocer en detalle del despegue e indicar su propósito se lo puede ver enlas actividades de planificación y diseño, véase más adelante.

Las metas del LiftOff dan como resultado un documento, un artefacto, llamado KickOff. Enel que se indica los siguientes puntos:

• Los miembros del equipo de desarrollo que deben ponerse al tanto del proyecto y suestado actual dentro de la planificación.

• Los StakeHolders que trascendieron a “Product Partner”.• La coordinación actual de roles y paquetes de trabajos.• Información actual de los procesos, herramientas, y las estructuras de los reportes.• Los códigos de conducta hacia los “Product Partner”.• El documento y gestión del riesgo.

Dentro del “Agile Kata” deben estar:

• Valores del Negocio, son los resultados de las metas obtenidas, ver más en el apéndiceG.

• Acuerdos de trabajo, es una pauta de que todos los participantes del desarrollo del pro-ducto deben respetar o seguir. Esto es, por ejemplo:

· Política de Codificación: control de cambios - TDD19, ATDD20 y BDD21,· Ambientes de desarrollo - pruebas - control de calidad - demo - etc., . . .

• Definición de los estados de trabajo; en la mayoría de los casos esto se encuentra dentrode los acuerdos de trabajo, están:

· ¿Cuántos días son los Sprints?· ¿Cuáles son las columnas del “Kanban” o “Sprint Board” Workflow?

16LiftOff: le da a su equipo de su trayectoria y lanzar su proyecto, véase más en el apéndice E17KickOff: son las metas que se aprobaron por los StakeHolder para dar inicio al proyecto de software, véase

más en el apéndice E18Chartering: es un documento en que se encuentra todos los entendimientos, acuerdos de trabajo y su alinea-

ción para el proyecto, véase más en el apéndice F19TDD (Test Driven Development); estilo de programación con objetivo de un desarrollo guiado por pruebas

de diseño. El objetivo de desarrollo guiado por pruebas es la especificación y la no validación de pensar a travésde un diseño antes de que el código está escrito, para crear código limpio que siempre funciona. Véase más enhttps://es.wikipedia.org/wiki/Desarrollo_guiado_por_pruebas

20ATDD (Aceptance Test Driven Development); técnica en la cual los participantes en colaboración se dis-cuten los criterios de aceptación, vía ejemplos, antes de que se inicie el desarrollo. Véase más en https://www.agilealliance.org/glossary/atdd/

21BDD (Behaviour Driven Development); es una síntesis, unión y refinamiento de las prácticas de programaciónTDD y ATDD. Véase más en https://www.agilealliance.org/glossary/bdd/

27

3. Propuesta solución: herramientas y artefactos

· ¿Cuál es el WIP (Work In Progress) predeterminado?· ¿A qué hora es el Daily StandUp?· ¿En qué día es el Sprint Planning?· ¿Dónde estará el Visual Workflow?· ¿Cuál es la definición de “Ready”?· ¿Cuál es la definición de “Done”?· ¿Dónde van estar las métricas de velocidad?· ¿Dónde va estar el clima para product burnup charts - burndown charts?· ¿Cuándo serán los demos?· Y herramientas que vayan asistir en estos artefactos.

3.3.1. Pautas para Agile Kata

Previo a definir el despegue, la incepción se utiliza al iniciar cualquier tipo de proyecto, aun-que es perfecto para las fases iniciales de un emprendimiento, porque facilita la definición delMVP22.

(Rasmusson, 2010) El inicio de la ceremonia es un conjunto de dinámicas orientadas aenfocar a todas las personas involucradas en un proyecto hacia un mismo objetivo, reduciendomuchas de las incertidumbres, ayudando a explicitar los riesgos más evidentes y poniendo encomún las expectativas de todos.

Para que este no falle sugiere lo siguiente (Alliance, 2015) :

• Evite el uso de cualquier documento plantilla para la construcción de la incepción. El valordel ejercicio radica más en la actividad que en el producto, y en centrarse en el contextoespecífico de la información que va a guiar al equipo hacia una buena toma de decisiones.

• Independientemente del formato, una carta del proyecto debe concentrarse en una solapágina.

Previamente de los acuerdos de trabajo y definición de los estados de trabajo, con los Can-vas sintetizar y realizar un cuadro de jerarquía que puedas tener la Visión, Misión comprobable,OKR23 y “Objetivos en BDD”24 por ejemplo en la figura 3.4

22MVP: Producto mínimo viable; es un concepto que proviene de ’Lean StartUp’ que describe la forma másrápida para conseguir la retroalimentación a través de construcción mesurable

23OKR: Objetivos y sus resultados clave, véase más en el apéndice https://en.wikipedia.org/wiki/OKR24Objetivos en BDD: también conocido como Hipótesis en los MVE es una historia de usuario con el si-

guiente formato: creemos. . . (capacidad), resultará en. . . (resultado) y sabremos haber logrado cuando cumpli-mos. . . (métrica).

28

3.4. Roadmap

Figura 3.4: Elaboración propia: Elaboración propia: Jerarquía de Misión a Resultados

3.4. Roadmap

Roadmap25 , es uno de los artefactos que siempre está cambiando. Lleva todas las historiasde usuario y se maneja a través de las metas clave resueltas en el ’Agile Kata’.

Para tener un correcto Roadmap se debe planificar muy rigurosamente las historias de usua-rio inicial. Dentro de los tipos (características, metas y mixto) de Roadmap hay:

• Por Características; son de largo plazo y tiene variantes al formular el equipo.• Por Metas del Negocio; son de corto plazo, permite la pronta entrega y el equipo es multi-

disciplinario.

El Roadmap más común en trabajar es el de metas de negocio, por qué obedece el ’Time toMarket’26. Su validación debe estar de la mano durante la efectiva aceptación del resultado delproceso de descubrimiento del producto.

La planificación del ’Product BackLog¡, véase más en el apéndice H, se ve realizada en dosdimensiones de construcción:

• Planificar para la menor construcción.• Planificar para aprender rápido.

Una vez seleccionado el Product Roadmap, durante el lapso de revisión global sintetizadasde artefactos, se visualiza dentro de la gestión del desarrollo los siguientes artefactos otorgadosen la figura 3.5

25Roadmap; Objetivos y sus resultados clave, véase más en https://en.wikipedia.org/wiki/OKR o en elApéndice

26Time to Market; se define como la capacidad de reacción que tienen las organizaciones para crear o mantenerventajas competitivas ante los retos que presenta el mercado y sus competidores, véase más en https://www.accenture.com/mx-es/insight-time-market-accelerator-high-performance

29

3. Propuesta solución: herramientas y artefactos

Figura 3.5: Elaboración propia: Elaboración propia: Mapa Visual de Artefactos

3.5. Historias de Usuario

Las historias del usuario son una de las herramientas más cotidianas de trabajar para elProduct Owner y el equipo de desarrollo, es el trabajo comprobable del valor del negocio. Parasaber más sobre ellas ir al Apéndice I sobre como pueden ser escritas y priorizadas.

Una forma de organizar las historias de usuario es, para el Product BackLog, por:

• Épicas; es la denominación cuya historia tiene un valor muy alto y está descompuesta envarias historias de usuario.

• Hitos; son una agrupación de historias cuya finalidad es representada en una demostra-ción funcional al “Product Partner”

• Temas; a relación del patrón que conllevan en su contexto, en casos prácticos que suenancomo el tema de una película. Esto ayuda a dar una finalidad de destino que las representesu implementación.

Hay que recalcar que dentro de la gestión de Sprints tenemos la priorización por nivel decomplejidad, opcionalmente se puede hacer ’Póker Planning’ antes, sugerido durante del Sprinty evitar hacerlo al final. En el momento cuando se desea hacer un entregable o demo de loshitos, la priorización de las historias de usuario se debe realizar vía MOSCOW (Más informaciónsobre MOSCOW ir al Apéndice I.1 ).

En cada iteración de desarrollo o Sprint, hay planificación y su retrospectiva, las formas ymétodo pueden varias en el rescate del aprendizaje, como sugerencia utilizar retrospectiva. Enel rescate del aprendizaje hay que recordar lo siguiente:

30

3.6. Entregas de Valor y Beneficios al Negocio

3.6. Entregas de Valor y Beneficios al Negocio

“ “Value is rarely straightforward to analyze in a consistent manner as it embodiesnot only quantitative aspect but also intangible element. Value is therefore as

much a matter of subjective judgement as it is a statement of element of priorities.Accordingly, the clear articulation, measurement and assessment of value

constitute important elements of project governance. What value is must beclearly laid out during project initiation and continually tracked through the project.

Value must therefore be the focus of benefits realization, assement andmanagement during and beyond the project lifetime.”

Alan Moran (Moran, 2016)”Las entregas de valor y los beneficios al Negocio, solo se resumen en métricas y resultados.

Estas métricas son:

1. Del rendimiento de una interacción del equipo de desarrollo.2. De los procesos de la creación del producto que permite el equipo de desarrollo.3. De los costos del desarrollo que se pueden aplicar.

Según (Moran, 2016) a razón de que a las ingenierías no predictivas les es más convenienteutilizar agilidad, es distinto el proceso para disponer una inmediata estimación y presupuesto.En proyectos ágiles lo más común es: predicción y presupuesto iterativos.

Para lograr este nivel de predicción se empieza desde el tiempo en que el equipo de desa-rrollo logra terminar las historias de usuario, después de varios Sprint y se obtienen el búfer decola de trabajo, y las metas alcanzadas. Estos son conocido como las ’métricas de velocidad’27

, y los gráficos de ’burn-down’28 y ’burn-up’29 . Estas solo son métricas de aproximación, quevarían durante todo el proceso y sucesos disruptivos.

27Velocidad; unidad de medida de la velocidad a la que se haya completado el trabajo por unidad de tiempodeterminado, véase más en https://www.Scrumalliance.org/community/articles/2007/march/glossary-of-Scrum-terms#1110

28 Burn-down Chart; gráfico que se muestran en el eje vertical la cantidad de trabajo restante en el tiempo, quese muestra en el eje horizontal. Porque menos y menos trabajo debe permanecer a través del tiempo, la tendenciageneral en el gráfico es para quemar a un punto donde ya no queda. Véase más en https://www.Scrumalliance.org/community/articles/2007/march/glossary-of-Scrum-terms#1127

29Burn-up Chart; gráfico que muestra el progreso de trabajar hacia una meta línea asociada con un valor en eleje vertical. Como el trabajo se completó a lo largo del tiempo, la barra de progreso se mueve hasta más cerca dela meta. Podemos mostrar el resultado proyectado en quemado de los gráficos se ha completado. Véase más enhttps://www.Scrum.org/Resources/Scrum-Glossary

31

3. Propuesta solución: herramientas y artefactos

Por lo cual se entiende lo siguiente:

• La velocidad del equipo es conocida como la métrica del rendimiento del equipo por sprint• Las gráficas de retroalimentación como burn-up y burn-down son las métricas de los pro-

cesos de la creación del producto.• Y de las métricas de los costos se encuentra Earned Value Management (Gestión del

Valor Conseguido). Véase más información en el apéndice J.

Recapitulemos, ya previamente en la Kata Agilidad se transfiere la visión, las metas y lacomprobación de las metas en OKRs, lo cual nos permites colocarlos en forma estructuradaen el Roadmap. De los OKRs hemos conseguido los varios escenarios de MVE. El equipode desarrollo consigue rendimiento óptimo (en el mejor de los casos) y brevemente consiguefabricar un MVF a un MVP con nuestros MVE. Podemos derivar que al realizar EVM30 a travésde nuestros OKRs se puede conseguir valor y sus beneficios.

Este circuito nos dará un monto a financiar, también a cuantificar y cualificar el valor de losocial, la comunicación y la interacción del uso de metodologías ágiles y el beneficio presentado.

Por último, los beneficios y su gestión ya se ven demostrados en los resultados obtenidos. Lafinesa de su medición está dentro la gestión del Product Backlog e iterativamente en el SprintBackLog, por lo cual la “Pulcritud de la dinámica del Backlog” y la metodología “DEEP”31 seconvierten en nuestras herramientas económicas al sistema financiero del EVM, sobre EVMvéase más en el apéndice J.

3.7. Modelo de negocio / Lean UX Canvas - Product Canvas

De vuelta al modelo del negocio. Para que este modelo “Lean UX Canvas” no quede in-completo. Es necesaria su mantención y actualizarla, por lo cual se propone usar el siguienteartefacto ’Product Canvas’, véase más sobre en el apéndice C de Product Canvas. Este artefac-to según usen la metodología de interacción ’XP’ o ’Scrum’ ayudará al traspaso de información.Así como su extensión del modelo de negocio con mayor facilidad.

El registro del valor que se dio en la gestión globalizada del EVM se lo puede transferir al’Product Canvas’.

Ya transferido los resultados del ’Product Canvas’ se puede llevar a cabo a la estrategia delproducto usando el artefacto ’Tablero de Visión del Producto’.

30EVM / AgileEVM (Earned Value Management / Gestion de Valor Conseguido); requiere de un conjuntomínimo de parámetros de entrada: el costo real de un proyecto, se estima que el Product BackLog, un plan delanzamiento que proporciona información sobre el número de iteraciones en la liberación y el supuesto de la velo-cidad. Todas las estimaciones pueden ser en horas, de la historia de los puntos, el equipo de días o de cualquierotra estimación consistente de tamaño. El factor crítico es que debe ser una estimación numérica de algún tipo. Eneste artículo vamos a utilizar la historia señala como una medida de la historia tamaño y la velocidad. Véase másen http://www.methodsandtools.com/archive/archive.php?id=61

31DEEP; según sus acrónicos es: detallada adecuadamente, estimado, emergente, y priorizadas. Véase más enhttp://www.romanpichler.com/blog/make-the-product-backlog-deep/

32

3.8. Diagrama de Datos de Entradas y Salidas de artefactos

3.8. Diagrama de Datos de Entradas y Salidas de artefactos

En el beneficio de brindar una mejor orientación durante los procesos y artefactos necesariosen el Toolkit de Product Owner, se presenta un cuadro de lote de documento:

Lote de Documento Documentos

Información EstratégicaCaracterísticas de productos deseadosObjetivos del negocio

Problemas auditadosNicho del mercado de necesidad sin resolver (Innovación por JTBD)Problemas de otros productos

Propuestas de ImpactoPropuesta de Ciclo de Vida del ProductoPropuestas de visión y metas de negocio a satisfacerPropuestas de KPI de la empresa que van a hacer afectadas

Modelos del negocioCanvas

UX CanvasLean Canvas

Agile KataValores del NegocioAcuerdos de TrabajoDefinición de los estados de Trabajo

Unidades de trabajo

OKRExperimentos mínimo viablesStory and Impact MapProduct BackLog

Product Roadmap &Presupuesto

Product RodaMapInicio de Presupuesto

Documento de Autorización yPresupuesto de Inicio delProyecto de Producto y

otros DocumentosRecopilados

Problemas auditadosDocumento de Autorización y Presupuesto de Inicio delProyecto de ProductoInformación estratégica recopiladaPropuesta de Impacto

Cuadro 3.1: Elaboración Propia: Cuadro de lote de documentos de entrada y salida

Y la figura 3.6 indica el flujo de artefactos dentro de los procesos entre las herramientas queasisten al Product Owner.

33

3.Propuesta

solución:herramientas

yartefactos

Figura 3.6: Elaboración Propia: Diagrama de flujo de Datos de Artefactos y Procesos

34

3.8. Diagrama de Datos de Entradas y Salidas de artefactos

35

Capítulo 4

Guía para la implementación de la propuesta de solución

Este “Toolkit” tiene como objetivo apoyar al Product Owner:

• La idea es tener un esquema flexible a seguir.• Solo implementar las herramientas necesarias.

Todas las herramientas, deben ser aplicadas con el criterio que se requiera según la nece-sidad del Product Owner y en base a como puedan ajustarse a las necesidades del cliente y alos KPI afectados.

Para implementar el “Toolkit” en su totalidad se deben realizar 5 pasos, en ayuda véase enel gráfico de la ilustración 16 la simbología para los tiempos de cómo proceder.

1. Creación de la Estrategia del Producto o ciclo de vida.

2. Registrar el modelo de negocios y sus cambios.

3. Creación del Roadmap o mapa de navegación de trabajo.

4. Registrar el modelo de negocios y sus cambios.

5. Supervisar y registrar las correspondientemente entregas de valor.

4.1. Creación de la Estrategia del Producto

Para fundamentar la estrategia se debe tener como respaldo la identificación del marco dela problemática y aquel marco debe contener al menos el reporte de todas las quejas.

Es ideal que estas quejas hayan sido bien tratadas (2.1). De esta forma las quejas pue-den usarse y aplicar la metodología "Design Thinking". En "Desing Thinking"puedes utilizar confacilidad sus primeros 3 pasos: empatizar, definir e idear; una posible solución.

Una vez concebida la idea puede empezar a registrar elementos en el artefacto "Tablero deVisión del Producto"

Juan Carlos Alonso Holmstron 36

4.2. Registrar el modelo de negocios y sus cambios

Y los demás pasos del "Design Thinking": hacer prototipos y probarlos, se puede transfe-rir hacia otra metodología "Lean UX", el cual da más aporte en crear los artefactos de MVe,Experimentos de Producto Mínimo Viable.

4.2. Registrar el modelo de negocios y sus cambios

En la creación del “UX Canvas” es importante destacar que “Lean UX Canvas” sea unabitácora resolutiva de alto o mediano nivel del “UX Canvas” y que el dueño del artefacto “UXCanvas”, es el equipo UX. Los productos de insumo que requiere este equipo son los funda-mentos de la estrategia del producto y el realizar el proceso de “UX Canvas”:

Para el proceso de "Design Thinking":

• Identificación de Usuarios y necesidad del Cliente.

• Realizar lluvias de ideas y bosquejo de casos de uso.

Para el proceso de “Lean UX Canvas”:

• Discutir e iterar.

• Testear, iterar y repetir.

El proceso de “Lean UX” deben ser gestionado como parte del proceso de la creación delchartering.

4.3. Levantamiento de información para el producto

El proceso de levantamiento de información empieza justo después de iniciar el procesodel desarrollo de la creación “UX Canvas”. Para un correcto levantamiento debe estar y tenerconcordado el documento de KickOff. El KickOff ya establecido, empieza el desarrollo del Liftoff.

Entre mejor este desarrollado y completo el LiftOff, mejor calidad tendrá los artefactos delproceso de “Agile Kata”. La calidad del valor aportado en el LiftOff se ve directamente influen-ciado en la calidad del contenido de los artefactos de “Valores del Negocio” y “Acuerdos deTrabajo”.

La calidad del contexto de la “Definición de los estados del trabajo” son solamente y di-rectamente influenciados por los factores de rendimiento óptimo e interacción del equipo dedesarrollo. El factor de esta interacción de influencias se la conoce como bien Chartering.

Durante el proceso de “Agile Kata” se puede definir la Jerarquía de la Visión en función delos resultados deseados. Los artefactos de OKR y objetivos BDD son de ayuda para la creacióndel Roadmap.

37

4. Guía para la implementación de la propuesta de solución

4.4. Creación del Roadmap

La implementación de la creación del Roadmap es el más relevante cuando el tipo es orienta-do a objetivos. El Roadmap orientado a objetivos congenia bien con la metodología de desarrollode “Entrega Continua”. Al utilizar la metodología de “Entrega Continua” permite justificar ante alcliente la monetización iterativa del desarrollo.

Puede llegar a ser agravante para el desarrollo estable de las historias de usuario el que notengan un Roadmap claro.

4.5. Supervisar y registrar las correspondientes entregas devalor

La implementación de la supervisión y registro de las entregas de valor al negocio se trabajaen conjunto con la creación de las historias de desarrollo y el Roadmap. Es importante que suimplementación sea reflejo del Roadmap y tenga plena navegación de los mismos, ya que suvalor debe estar bien dirigido por el mapa de impacto o “Story Mapping”, Lo que se registrarádebidamente en el “Product Canvas”.

Los registros realizados hacia el “Product Canvas” tiene que ser balanceadas con el “UXCanvas” y su resultado podrá opcionalmente registrarse nuevamente en el “Lean UX Canvas”.

La bitácora de los registros que se vayan a poner en el “Lean UX Canvas” deben apropiada-mente tener sus documentos respaldados, preferiblemente, con los artefactos del “Agile EVM”.

Como parte final de este paso; los artefactos de Roadmap, historias de desarrollo, ProductCanvas y EVM deben estar sintetizadas y reflejadas en el “Tablero de la Visión del Producto”

38

4.5. Supervisar y registrar las correspondientes entregas de valor

39

Capítulo 5

Evaluación de la propuesta de solución

En la evaluación de la propuesta de solución se desarrolló con dos formas: la primera fueuna simulación de la aplicación práctica y la segunda fue a través de encuestas realizadas adiferentes profesionales.

5.1. Evaluación de la propuesta por simulación práctica

En esta evaluación de la propuesta, una simulación de la aplicación práctica de un proyecto,en el que se realiza el desarrollo de un producto de software. Esta aplicación se trata de unproducto para la automatización de reportes financieros. Esta aplicación, aunque no fue desa-rrollada completamente, cumplió con cerca de tres iteraciones del ciclo de desarrollo Lean, cuyoobjetivo propuesto es conseguir el Roadmap.

El Beneficio del descubrimiento de la propuesta, se obtuvo gracias al proceso de desarrollode este producto de automatización e investigación.

Herramienta 1o Ciclo 2o Ciclo 3o Ciclo

Estrategia del Producto Si Si SiUX Canvas No No NoLiftOff No Si SiKickOff Si Si SiValores del Negocio para el SH No Si SiAcuerdos del Trabajo No Si SiDefinición del WorkFlow No Si SiRoadmap No No SiHistorias de Usuario No Si SiProduct Canvas No No NoEntregas de Valor y Beneficios al Negocio No No No

Cuadro 5.1: Elaboración Propia: Resumen de la simulación de la aplicación de la propuesta desolución

En el rescate de la información, dado por los resúmenes de tres iteraciones Lean que encap-sulan lapsos Scrum, se observa que el modelo Canvas no llego a resolver el objetivo propuesto.Por esta situación fue muy complejo crear un Roadmap orientado a objetivos.

Juan Carlos Alonso Holmstron 40

5.2. Evaluación y validación de la propuesta por encuestas a profesionales

Otra situación también observable, fue resolver las entregas de Valor y Beneficios del Ne-gocio, sin importar que se haya constituido la visión, objetivos y misiones a conseguir. Estaconstitución no fue suficientemente efectiva en lograr un lenguaje común, como lo que ofrecelos OKR; por lo cual las tres iteraciones no se pudieron conseguir.

Para conocer más detalles de la simulación, dirigirse al apéndice K

5.2. Evaluación y validación de la propuesta por encuestas aprofesionales

La evaluación por encuesta está dirigida a profesionales que se encuentren en el contextodel rol de Product Owner. La encuesta se conforma de los siguientes objetivos y preguntas:

Objetivo Pregunta

Medir si el Toolkit consiguelos objetivos indicados

¿Has trabajado como o tienen familiaridad con el rol de ProductOwner o similar?¿Qué beneficios percibes en este Toolkit para la labor de un ProductOwner?

Medir el aporte del Toolkit altrabajo actual

¿Qué partes del Toolkit ya conoces?¿Qué partes del Toolkit son nuevas para tí?

Medir la aceptación delToolkit

¿Esté Toolkit te brinda apoyo o guía en tu labor?, ¿SI, NO y Por qué?¿Utilizarías este Toolkit en tus proyectos?, ¿Si, NO y Por qué?

Medir qué mejoras necesiteel Toolkit

¿De este Toolkit y sus herramientas, según el criterio, se pueden odeben: mantener, corregir y/o agregar?

Cuadro 5.2: Elaboración Propia: Objetivos y preguntas para obtener validación de la propuestapor encuestas a profesionales

La información entregada para la evaluación del Toolkit corresponde al capítulo “Propuestasolución: herramientas y artefactos”. En el caso que se requiera una guía de implementaciónse propone el capítulo “Guía para la implementación de la propuesta de solución”. Para lo quecorresponde a información sobre agilidad, se recomienda el capítulo “Estado del Arte” y losanexos referidos de los capítulos.

El universo de los encuestados corresponde a 7 profesionales, los cuales se desempeñanen perfiles de mando alto o medio y a 1 consultor independiente. Para información sobre elresultado de las encuestas ir al apéndice L.

41

5. Evaluación de la propuesta de solución

Primer objetivo:

En la medición si el Toolkit consigue los objetivos indicados, se pregunta previamente si losprofesionales encuestados están familiarizados en el contexto del desempeño de rol de Productowner.

Primera pregunta:Respuesta:¿Has trabajado como o tienen familiaridad con el rol de Product Owner o similar?El universo completo contesto que sí.

Segunda Pregunta:¿Qué beneficios percibes en este Toolkit para la labor de un Product Owner?Respuesta:El universo completo contestó que sí perciben al menos un beneficio. Entre las respuestas hayen común:

• Claridad y guía para sincronizar el desarrollo con las propuestas de valor.

• Detección de las problemáticas del Product Owner.

• Un proceso formal sin perder la agilidad.

Segundo objetivo:

En la medición del aporte del Toolkit al trabajo actual

Tercera pregunta:Respuesta:¿Que partes del Toolkit ya conoces?Encontramos que lo más común es: Scrum, Kanban, Lean, Historias de Usuario y Roadmap

Cuarta pregunta:Respuesta:¿Qué partes del Toolkit son nuevas para ti? Se encontró que lo más común es: Product Canvas,UX Canvas, EVM, Agile Kata

Tercer Objetivo:

Medir la aceptación del Toolkit

Quinta pregunta:Respuesta:¿Esté Toolkit te brinda Apoyo o guía en tu labor?, ¿Sí, no y por qué?En el universo de los encuestados 6 de ellos respondieron Si y dos respondieron que tal vez

42

5.2. Evaluación y validación de la propuesta por encuestas a profesionales

pueda ayudar en su labor.

Sexta pregunta:Respuesta:¿Utilizarías este Toolkit en tus proyectos?, ¿Sí, no y por qué?En el universo de los encuestados 6 de ellos respondieron Si y dos respondieron No.Quienes respondieron No, sus razones fueron:

• No tener la suficiente experiencia para responder con propiedad.• Prefiere ver la necesidad del cliente y que la herramienta sea propuesta por el mismo

cliente.

Cuarto Objetivo:

Medir qué mejoras necesite el Toolkit

Séptima pregunta:¿De este Toolkit y sus herramientas, según el criterio, se pueden o deben: mantener, corregiry/o agregar?Respuesta:En el universo de los encuestados 7 de 8 respondió que se debe mantener. Quien respondiódistinto, fue quitar el UX Canvas; por razones que solo le corresponde al equipo UX.

43

5. Evaluación de la propuesta de solución

5.3. Validación y resultados estadísticos de las encuestasprofesionales

En los resultados de las encuestas se determina:

Figura 5.1: Elaboración Propia: Resultados sobre metodologías ágiles más conocidas

Figura 5.2: Elaboración Propia: Resultados de los artefactos más conocidos

44

5.3. Validación y resultados estadísticos de las encuestas profesionales

Figura 5.3: Elaboración Propia: Resultados de los artefactos menos conocidos

Figura 5.4: Elaboración Propia: Disposición para utilizar el Toolkit

En resumen, a la redacción de las respuestas y estadísticas indicadas, se determina que lavalidación de los objetivos de las encuestas se ha cumplido.

También se detectó que el Toolkit, al menos, propone responder:

• ¿Quién representa a los clientes y usuarios en la compañía?• ¿Quién identifica y descubre las necesidades de los clientes y la funcionalidad del produc-

to?• ¿Quién lidera las actividades de la visión, y quien lidera las actividades que traen la visión

realizada?

Es el Product Owner

45

Conclusiones, recomendaciones ysugerencias

Las conclusiones descritas a continuación son descubrimientos de las reflexiones de partesde los capítulos anteriores, las recomendaciones son indicaciones de requerimientos posibles uopcionales, para implementar en su totalidad la propuesta de solución.

5.4. Conclusiones de la propuesta solución

# Conclusión Referencia

1En la creación de historias de usuario se descubrió cómo poder medir la innovacióny como usarlo en el Toolkit.

3.5

2La creación de las historias de usuario, le implican un mayor tiempo de desarrollo alProduct Owner. Debido a esto, el lenguaje utilizado debe ser de fácil lectura.También que las propiedades antes descritas en el apéndice I,se puedan mantener

3.5

3En la creación de historias de usuario se descubrió que existen historias de usuarioque dan valor a la innovación en el negocio de la empresa y se puede proponer usaruna metodología conocida JTBD (Job to be donde)

3.5

4En la simulación de la aplicación se detectó una relación entre el Toolkit y lanaturaleza de la empresa que implemento. Y sus razones de las dificultades enobtener un Roadmap.

5.1

5

Se detectó también durante la simulación que, en los procesos formales dedescubrimiento, en donde intervienen las metodologías Lean, se encuentra lavalidación del producto en la dimensión del propósito. Y el Producto no solo debesatisfacer una necesidad puntual sino también un propósito en el ciclo estratégicodel producto.

5.1

6En la simulación de la aplicación se presentaron los siguientes problemas:- Faltaron procesos formales de descubrimiento del producto- Falto validar la idea del producto con prototipo terminado

5.1

7En la simulación, también se detectó que en el proceso de descubrimiento delproducto se encuentran activos los roles de Diseñadores UX, para velar que tengaéxito la validación concreta del producto

5.1

8En las encuestas realizadas se detectó que el valor del Toolkit tiene distintos puntosde vista y las posibilidades de un pulimiento de contenido u otros más

5.2

Cuadro 5.3: Elaboración propia: Cuadro de conclusiones Parte 1

Juan Carlos Alonso Holmstron 46

5.5. Recomendaciones para implementarlo

# Conclusión Referencia

9En las encuestas realizadas se descubrió que el toolkit desarrollado, en vez de dejarun camino abierto a la interpretación, propone un balance entre la interacción de laspersonas en los procedimientos y el uso adecuado de las herramientas

5.2

10

En las repuestas de las encuestas también se descubrió la necesidad de ofrecer másejemplos, detallistas de preferencia, en los cuales se detalle la interacción. Y si esposible; como encontrar el “Camino Feliz”, cercano a un tablero visual, entre lo técnicoy lo funcional para un sencillo entendimiento.

5.2

11En reflexión de las respuestas de las encuestas se descubre que el Toolkit se prestapara ser un compás náutico, en donde, el Scrum es una de las metodologías ágilesque se puede complementar

5.2

12A través del proceso realizado y evaluado por profesionales en metodologías ágiles,se valida la importancia del Toolkit como una herramienta de apoyo para el ProductOwner, con la finalidad de elevar su rendimiento y optimizar su trabajo

5.2

Cuadro 5.4: Elaboración propia: Cuadro de conclusiones Parte 2

5.5. Recomendaciones para implementarlo

En la creación de las historias de usuario, existen historias que son disruptivas para traba-jarlas y en el Toolkit le falta algo que permita gestionarlas

Previo a las ventajas de la implementación del Toolkit también se recomienda que parapoder implementar este fundamento de Toolkit se debe tener al menos conocimientos sobre lassiguientes metodologías:

• Design Thinking; para encontrar los problemas que realmente afectan al negocio.• Lean; para modelar y validar una propuesta de la idea solución ante la necesidad del

negocio. Y posiblemente generar un propósito que de valor más allá de la simple vista.• Scrum; para poder conocer la mecánica y adaptación de metodología de desarrollo.• Kanban; para poder conocer la gestión y solución debida ante incidentes en producción.

También es preferible tener mínimo un año de experiencia utilizando cualquiera de estasmetodologías.

47

5. Evaluación de la propuesta de solución

En término de roles de personas que se requieren son:

ROLCantidadmínima

necesaria

Cantidad mínimade años deexperiencia

Stakeholders que estén propuestos a ser Product Partners 1 0Diseñador UX 2 1Analista de Negocio 1 2Experto de la plataforma 1 3Scrummaster 1 2Desarrolladores 8 2Product Owner 1 2Product Manager 1 3

Cuadro 5.5: Elaboración propia: Cuadro de roles necesarios

En término de conocimiento de herramientas funcionales, conocer cómo utilizar las siguien-tes:

Herramienta Indispensable Recomendable OpcionalAnálisis de Costo y Beneficio XAuditorias deCaracterísticasTableros Kanban y/o Scrum X XDashboard de Personas XCanvas XLíneas de Tiempo XWorkflow XMapa de Viaje del Cliente XDiagramas de Flujo XMapas Mentales XDiagrama de Pescado XAnálisis SWOT XAnálisis Pest X

Cuadro 5.6: Elaboración propia: Cuadro de herramientas necesarios

Sobre los requisitos de las habilidades blandas del Product Owner y el uso exclusivo dehistoria de usuario como únicas unidades de trabajo de desarrollo en donde sé que, en estaexisten dos grandes puntos de investigación que se sugiere que requiera ser vistas en mayorprofundidad, son:

• Liderazgo• Mejor uso de historias de Usuario

48

5.5. Recomendaciones para implementarlo

Mejorar las habilidades blandas de estilo de liderazgo ante situaciones en el marco cynefin,por ejemplo, viendo las siguientes ilustraciones:

Figura 5.5: Diagrama de Continuidad entre el Orden y Caos (Williams and Hummelbrunner,2010)

Figura 5.6: Diagrama de estilo de liderazgo(lea, 2015)

También se recomienda cambiar el uso de las historias de usuario por historias de agilidady poder fomentar los siguientes:

Historia ágil de una Hipótesis

EspañolCreemos en la ’capacidad’,resultará en ’resultado(s)’ o se va a conseguir la ’expectativa’,sabremos tener éxito cuando cumplimos con la(s) ’métrica’

InglésWe believe ’THIS CAPABILITY’,Will result in ’THIS OUTCOME’,We will know we have succeeded when ’ACHIEVE MEASURABLE SIGNAL’

Cuadro 5.7: Elaboración propia: Historia ágil de una Hipótesis

49

5. Evaluación de la propuesta de solución

Historia ágil de un Negocio

EspañolSe necesita/requiere ’lograr la capacidad’,tendrá ’los resultados claves’.

Inglés’Objective’ (What we want to achieve),and a set of ’Key Results’ (How do we know if we are getting there)

Cuadro 5.8: Elaboración propia: Historia ágil de un Negocio

Historia ágil de Desarrollo de Usuario

Español

Como el “Usuario”Necesita o requiere “comportamiento del sistema”,Por lo que da cuenta “valor del negocio”

Dado “contexto”,Cuando “tipo de acción se lleva a cabo”,Entonces “determinando conjunto de observables en el caso de obtener”,Posible resultado “ofrecer un supuesto opcional del resultado obtenido”

Inglés

As a “user”,I want “goal/desire”,so that “BECAUSE”

Given “INITIAL CONTEXT”,when “EVENT OCCOURS”,then “ENSURE OUTCOMES”

Cuadro 5.9: Elaboración propia: Historia ágil de Desarrollo de Usuario

Historia ágil de Desarrollo de Trabajo

EspañolCuando “situación X”,Se requiere la “motivación Y”,Así yo pueda obtener el siguiente resultado

InglésWhen SITUATIONI want to MOTIVATIONSo I can Expected Outcome

Cuadro 5.10: Elaboración propia: Historia ágil de Desarrollo de Trabajo (JTBD)

Los tipos de historia de desarrollo de trabajo y técnicas son nuevas en el mundo ágil, lo cualrequieren maduración de uso.

Las “historias de trabajo”32 responden hacia escenarios de complejidad de ansiedad de eje-cución, por decir si las historias de usuario tienen más de dos escenarios pueden llegar a estre-sar y es preferible utilizar las historias de trabajo.

En las “historias técnicas”33 que no son requerimientos no funcionales, corresponden a lasmejoras de calidad del producto. Estas historias trabajan en el flujo de trabajo que requiere queun producto necesite ejecutarse.

32Historias de Trabajo; para conocer más sobre ellas ir a https://blog.intercom.com/using-job-stories-design-features-ui-ux/

33Historias de Técnicas; para conocer más sobre ellas ir a http://www.seilevel.com/requirements/user-stories-technical-stories-agile-development

50

5.5. Recomendaciones para implementarlo

Recordar que las historias deberán tener la siguiente Pruebas de Aceptación:

• Historia de Usuario: tener una información esperada.• Historias de Trabajo: tener una emoción esperada, para sirve mucho el modelo kano.• Historia Técnica: tener un flujo de trabajo esperado a realizar.

Y para el rescate del beneficio:

Historia de Beneficio (Impacto/Efecto)

Español

Como <actor(es)/emoción/flujo de trabajo>,Motivados por <comportamiento del sistema>,Se entregó <características que cumplen con los resultados>,Para Satisfacer <capacidad necesitada>

Inglés

As an <ACTOR/EMOTIONAL/WORKFLOW>,Driven by <BEHAVIOUR>,I want <DELIVERABLE>,so that <IMPACT THIS ACHIEVMENT>.

Cuadro 5.11: Elaboración propia: Historia Beneficio (Impacto / Efecto)

Un diagrama que ayuda a un proceso opcional de gestión de tipos de historias de desarrolloes:

Figura 5.7: Diagrama Representativo del ciclo y capas del Desarrollo adaptado a (Consulting andConsulting, 2014)

51

Apéndices

En esta sección se entregan elementos que son base para entender y profundizar aspectosdesarrollados en los capítulos.

Juan Carlos Alonso Holmstron 52

Apéndice A

Árbol de Decisión para proyectos Ágiles

Figura A.1: Árbol de Decisión, Este Proyecto puede ser ágil? (Mamoli, 2012)

Juan Carlos Alonso Holmstron 53

Apéndice B

Lean UX Canvas

Mark Stephan, (Stephan, 2016) , creo este modelo. Desde el modelo tradicional CANVAS al"Lean UX Canvas", han desarrollado cambios importantes, ahora se presenta como un modelode negocios de trabajo continuo. Es decir, es un documento vivo, que debe ser actualizadocontinuamente y volver a ser evaluado nuevamente cuando información nueva es ingresada.

"Lean UX Canvasçomo extensión de "Lean Canvas tiene":

Negocio Producto/Solución Usuario/Marketing

ProblemasSoluciones yCaracterísticasPrincipales

Atributos de los Usuarios

Problemas que no sevan a resolver

Métricas Principales Acciones de los Usuarios

Riesgos Propuestas de Valor Sentimientos

CompetidoresRelación con losclientes

Canales

Socios principales Flujos de IngresosVentaja InjustaCriterios de ÉxitoMétricas principalesActividades y Recursosprincipales

Cuadro B.1: Lean UX Canvas (Stephan, 2016)

Este modelo que está centrado más hacia el usuario y en una metodología de diseño deproducto. Lean UX Canvas ayuda a no solo entender el negocio desde el punto de vista delproducto, sino también a entender al usuario desde el mismo punto de vista a través de ladocumentación de la experiencia del usuario.

Las direcciones de uso son:

• En el cuadrante del Negocio van los Stakeholder del producto. Es necesario llenar unmodelo Lean UX Canvas individual por Stakeholder hasta descubrir las discrepancias en-tre Stakeholders.

• En el cuadrante del Usuario están las entrevistas, encuestas, estudios de usabilidad,entre otros. Contiene la esencia mínima del usuario ya categorizado. A razón como seva llenando, su primer contenido es del usuario investigado posible que vaya a utilizar elproducto.

Juan Carlos Alonso Holmstron 54

.

• En el cuadrante del Producto contendrá los supuestos del negocio, lo que se ha pro-puesto y confirmará las necesidades del cuadrante expuesto.

55

Apéndice C

Product Canvas

Artefacto creado "Pichler Consulting"(Pichler, 2012). "Product Canvasçontiene: el nombre,versión, objetivos y las métricas en que se está midiendo los objetivos, la gran imagen y losdetalles del producto.

Parte del propósito del “Agile Chartering” se encuentra los objetivos y las métricas del objetivoa un nivel mayor de detalle.

Figura C.1: Product Canvas (Pichler, 2012)

Los grupos objetivos de personas se transcriben de la información resultante ya aplicadade la técnica del análisis del Usuario con la creación de perfil de personas. Empleando losperfiles primarios ayudara a tener la correcta priorización de la toma de decisiones con unamejor experiencia.

En la gran imagen se describe que es lo que se necesita conseguir con respecto a los objeti-vos de las personas. Conceptualizar el viaje del usuario y con diseño visual fabrica la experienciade usuario deseado. Uso de escenarios, historietas, diagramas de flujo, y mapeo de historias deusuario son excelentes técnicas en describir el viaje del usuario. La funcionalidad del productoes capturada como épicas, las cuales son grandes historias de usuario. Las épicas asisten a ladescripción de las ideas sin entrar a gran detalle, ahorro de tiempo y facilita actualizar el Canvasen nuevos conocimientos. Restringir las historias de usuario permite ofrecen la captación de

Juan Carlos Alonso Holmstron 56

C.1. Mecánica del Product Canvas

requerimientos no funcionales que impacten a la experiencia del usuario y la arquitectura delsoftware. Se puede capturar las ideas con diseño visual en el Canvas como diseño de bosque-jos, mockUPs, fotos, etc. Los artefactos de la gran imagen se enfocan en lo critico aspectosdel diseño. Además; los escenarios, historietas, épicas, borradores de diseño y las restriccio-nes describen el futuro del producto, las historias de usuario aseguran la implementación de losobjetivos.

Los detalles del producto proveen la meta para la siguiente iteración y lo suficiente elemen-tos, por ejemplo: abordar los riesgos y la adquisición de los conocimientos relevantes para com-pletar las características del producto. Dependiendo del objetivo, se debe usar diferente técnicaen la captación de su implantación. Objetivos tales como que requieran codificación e historiasde usuario disponibles a trabajar alimentan mejor a los detalles del producto.

C.1. Mecánica del Product Canvas

Este Canvas está diseñado en base que la información fluya de izquierda a derecha, empe-zando con el perfil de las personas. Con el objetivo de poner al usuario en el centro del esfuerzodel desarrollo y asegurando que el desarrollo del producto es beneficioso y deseable.

57

Apéndice D

UX Canvas

El modelo UX Canvas desarrollado en Atlassian, permite tomar la misma lógica incrementalpara la creación de MPV, pero en este caso corresponden a MVE. Es un modelo tipo frameworkque permite a los equipos de desarrollo enrolar cada característica del producto centrada alusuario usando Lean, sin comprometer su flexibilidad (Crothers, 2013).

En este modelo no es necesario que los requerimientos sean especificados, tampoco esnecesario tener un Roadmap para el trabajo.

Un ejemplo del Canvas:

Figura D.1: Modelo UX Canvas (Crothers, 2013)

• Hipótesis: de preferencia se debe escribir de forma BDD siguiendo las reglas cree-mos. . . (capacidad), resultará en. . . (resultado) y sabremos haber logrado cuando cum-plimos. . . (métrica).

Juan Carlos Alonso Holmstron 58

D.1. Mecánica del Canvas

• Problema: causales que provocaron que la hipótesis se ejecute, en una breve explicación

• Personas: participantes que requieren utilizar opcionalmente la solución• Stakeholders: personas quien hayan sido realmente afectado.• Equipo: Personas que van a realizar el desarrollo de la solución.• Idea: son pensamientos previos u otras opciones de resolver el problema.• MVE: la forma más pequeña, fácil, que se pueda probar una versión de la idea en que se

puede iniciar la experiencia.• Extremo a extremo del Demo: la historia de usuario llevada a su posible realización

usando juegos de roles, dibujos, hasta un posible prototipo.• Resultados de las Pruebas: la comprobación de la experiencia y validar la anticipación

del resultado.

D.1. Mecánica del Canvas

Debe realizarse en un taller, de gran espacio de preferencia, que dura de dos horas hasta eldía completo. El taller debe ser un lugar estratégicamente situado donde se puede revisar loscanvas de vez en cuando o las veces necesarias. Las formas de contar el canvas es:

• En una pizarra con el canvas se plantea cada cuadro en preguntas para los demás.• Cada cuadro es abordado por primera vez, escribir todos los pensamientos en post-its,

para después ser clarificadas y agrupadas.• Con actividades de grupos pequeños se ponen en cada cuadro ideas, en especial los

cuadros de la idea, el MVE y su valor.

Lo importante de este ejercicio es no siempre completar todo, puede que uno de los cuadrosquede atascado o sin post-its. O a su vez, no completar todos los cuadros, ya que más tardepuede ser complementando con las experiencias formalizadas.

59

Apéndice E

El Despegue / LiftOff

E.1. Propósito, tiempo y KickOff

Un efectivo LiftOff tiene las siguientes características:

• Logra alineación.

• Gana impulso.

• Aclara roles.

Su tiempo, cuando inicia, cuando debes hacer LiftOff: solo después que el Stakeholder hayareconocido la necesidad del negocio y autorice la inversión de personas, recursos e identificarel equipo que lo satisfaga.

Las metas del LiftOff, dan el resultado de un artefacto conocido como KickOff, estos son:

• Los miembros del equipo deben ponerse al tanto de la historia del proyecto y el estado desu situación actual de la planificación.

• Coordinar la asignación de roles, paquetes de trabajo e interfaces.

• Informar sobre los procesos, herramientas, y las estructuras de los reportes.

• Aclarar los códigos de conducta hacia el cliente.

• Recoger todo lo que es para la gestión de riesgos.

• Conocerse entre todos para empezar a convertirse en equipo.

E.2. Planificación del LiftOff

Para empezar la planificación del LiftOff se considerna muchos elementos. Por esto se re-quiere conocer si hay disposición para realizarlo con las siguientes:

• ¿Si los entregables están comprometidos por el patrocinador e identificado por el “ProductManager”?

• ¿Está bien articulado el caso del negocio?

• ¿Hay presupuesto designado al proyecto?

• ¿Están claras las intenciones para lo que se desea que el proyecto cumpla?

Una vez respondidas estas preguntas se procederá a las preguntas del planteamiento de laPlanificación:

Juan Carlos Alonso Holmstron 60

E.2. Planificación del LiftOff

• ¿Este proyecto es para un equipo o un grupo de trabajo, o de múltiples equipos o unainiciativa?

• ¿Qué es lo necesario para que los equipos empiecen?• ¿A qué otros miembros se deben invitar?• ¿Quién soporta el esfuerzo esencial para el éxito?• ¿Cuáles Stakeholders son necesarios que atiendan en el LiftOff?• ¿El equipo necesita nuevas habilidades?• ¿El equipo necesita nuevos conocimientos?• ¿Cómo y dónde se puede anticipar a las interrupciones de comunicación y el flujo de

información del proyecto durante el LiftOff?• ¿Se ha identificado todos los miembros y el trabajo inter-funcional?• ¿Hay limitaciones y problemas ya conocidos?• ¿Se ha identificado la existencia sobre desconocimiento del proyecto?• ¿Qué tono de conversación es el que se quiere?• ¿Es probable que nueva información surja durante el LiftOff y cuál es la posibilidad de

adaptarse?• ¿Cómo se puede hacer mejora continua al LiftOff para que se beneficie los proyectos?

Obteniendo esta información facilitará la disponibilidad para el diseño y actividades del “Di-seño del LiftOff”, que serán los artefactos de:

• Agenda y Contenido: Es información de alto nivel que se transmite y recupera, habilida-des de entrenamiento, mejoramiento del equipo y otros contenidos que debe incluir en elLiftOff.

• Duración: Puede ser de día completo o medio día durante semanas desde dos en adelantey posiblemente sesiones continuas.

• Participantes: Todos que tienen interés principal en la ejecución y/o resultado del proyectodeben estar para el LiftOff. Estos pueden ser: Sponsors del negocio, el equipo esencial,product managers, clientes y cualquier otra persona que actúe como recurso para el equi-po.

• Logística: Normalmente esto es subestimado. La importancia de tomar las debidas deci-siones, tales como, habitacionales, agendamiento, cronograma, suministros y alimentos,viajes, y apoyo de comunicación, y cualquier otro factor; crea el ambiente idóneo que sedesea en el LiftOff.

61

Apéndice F

Chartering

Continuando con (Larsen and Nies, 2011), como parte del LiftOff, el “Agile Chartering”; pro-porciona un potente núcleo. Será el combustible para todo el proyecto y suministrará al menosel impulso de la primera iteración del proyecto.

El “Agile Chartering” es ligero, y de mínima documentación con aproximaciones a la creacióninicial de los entendimientos, acuerdos, y la alineación sobre el trabajo y como se logrará. Debeestimular las interacciones necesarias para el trabajo, facilitar el inicio, la pronta entrega de soft-ware, acelerar la colaboración dentro del equipo, y establecer el contexto para la re-planificacióncuando exista mayor información disponible.

Los beneficios del “Agile Chartering”; debido a su naturaleza se requiere que los Stakehol-ders y el equipo de desarrollo se relacionen desde el principio del proyecto. El enfoque de unaalta banda ancha de comunicación y colaboración, lo que da la mayoría del valor, se encuentradentro de este proceso y no dentro del documento que resume el artefacto del “Agile Chartering”.

Los valores y principios del “Agile Chartering”; los valores reflejan las creencias fundamen-tales acerca de lo que se necesite crear en el acuerdo inicial y los principios muestran comotomar acciones basados en aquellos valores. Juntos, proporcionan la transparencia de la tomade decisiones en la primera versión del “Agile Chartering” y también sus versiones venideras.

Valor Principios

El sistema completoTomar foco en las relaciones de las personas, ideas, acciones y sus resultados deforma integral

Trabajo ColaborativoTrabajar juntos para aprender unos de los otros, experiencias yperspectivas, para crear nuevas posibilidades.

Suficientementebuenos por ahora

Hacer lo suficiente por el momento, debe resistirse a perfeccionar.

Empezar bienEn cada emprendimiento en un contexto de posibilidades; enfócate en lograrlo ytener éxito.

Aprendizaje ContinuoAprende en el transcurso del proyecto; actualiza la vivencia del charter comoconocimiento obtenido.

Cuadro F.1: Cuadro de Valores y Principios del ’Agile Chartering’ (Larsen and Nies, 2011)

Juan Carlos Alonso Holmstron 62

.

Los elementos del “Agile Chartering”; Dentro de estas actividades críticas son: propósito,alineación y contexto.

Propósito¿Qué es? ¿Cómo se conduce?

Esta sesión es esencial para tener claro lasactividades a realizar, obtener a labrevedad: la misión del proyecto, la visióndel producto y formas como testear lamisión del proyecto.

Previo a la sesión, ’Product Managers’,Sponsors, y StakeHolders principales,hacen un borrador de la declaración delpropósito.

Cuadro F.2: Cuadro del propósito del ’Agile Chartering’ (Larsen and Nies, 2011)

Alineación¿Qué es? ¿Cómo se conduce?

Esta sesión en que el equipo incluye losvalores y principios compartidos que guíana la toma de decisiones y los acuerdos detrabajo. Esto dará punta pie al proyecto.

Esto se desarrolla desde cero. El equipo dedesarrollo debe preparar, revisardefiniciones, descripciones y la justificaciónde cada parte: los principios y valoresfundamentales del equipo, y los acuerdosde trabajo.

Cuadro F.3: Cuadro del alineación del ’Agile Chartering’ (Larsen and Nies, 2011)

Contexto¿Qué es? ¿Cómo se conduce?

Esta sesión incluye los límites del proyecto,las interacciones del proyecto y los recursoscomprometidos. Hay un análisis anticipadodel prospecto de las posibles riesgos ybeneficios.

El equipo lo desarrolla; prepara, revisa lasdefiniciones, descripciones y racionalizacada elemento: limitaciones, el proyecto,recursos comprometidos y prospectos deanálisis.

Cuadro F.4: Cuadro del Contexto del ’Agile Chartering’ (Larsen and Nies, 2011)

63

Apéndice G

Formato y ejemplo básico de un Chartering de un proyecto X

Equipo X

VisiónDar el mejor servicio a nuestra organización, clientes y Stakeholders y empleados con:

• Producir información de forma oportuna, clara y precisa.• Comunicar a la organización de nuestro productos y servicios.• Mantener el cumplimiento regularmente.

MisiónAprovechamos la tecnología, el desarrollo de los empleados, y el proceso de trabajo para pro-ducir información precisa, oportuna y confiable de los datos del cliente. Nos aseguramos de quela información es entregada a la organización de nuestros clientes, accionistas y empleadosa través de canales de comunicación adecuados. Nos aseguramos de que los datos que nosentregue los apoyos de nuestros clientes con las necesidades cambiantes.

Pruebas de la misión

• Lograr el 100 % de precisión en relación con las cuentas por pagar y facturación y proce-dimientos en el tercer trimestre de este año.

• Promediar de menos de dos en de denuncias de un mes sobre las cuentas por pagar opor errores de facturación, durante el año en proceso.

• Nuestros patrocinadores de la organización y Product Owners informe de satisfacción del90 % con nuestra comunicación.

Valores y principios

• Comunicación; tener expectativa de una comunicación abierta dentro del equipo y contodas las partes interesadas.

• Confianza; hacerlo bien, de forma individual y como equipo.• Responsabilidad; conocer los compromisos del equipo y comuníquese con ellos, de forma

inmediata, cuando algo se interpone en su camino.

MiembrosLos miembros del equipo con nombre, cargo y avatar

Acuerdos de TrabajoPueden variar según la naturaleza de las tareas y criterios de aceptación

Juan Carlos Alonso Holmstron 64

.

Limitaciones e interaccionesAquí se puede colocar un grafica de tarjetas de responsabilidad de colaboradores (CRC; ClassResponsability Collaborator)

Análisis estructural prospectivo*(Puede ser visualizado en una aplicación web de base de conocimiento)

65

Apéndice H

Planificación inicial de las Historias de Usuario

Uno de los mejores autores que explican esta planificación es Patton Cooper (Patton et al.,2014) . Está planificación se sugiere al momento de conservar las historias, no se debe usarabsolutos como ’siempre’ o ’nunca’ porque al hacerlo lograra obtener malos entendimientos ydiversos problemas.

Para planificar menos la construcción, se debe mapear la realización de las entregas a tra-vés de múltiples equipos hacia la visualización de dependencias. Mapear ayuda a encontrarvacíos en las historias de tal manera que el alcance no debería influenciar; esto hace crecer elentendimiento.

Al mapear las historias siempre habrá más; por consecuencia:

• Enfócate en lo que esperas en el resultado que obtendrás del sistema para la toma dedecisiones acerca de lo que está dentro del sistema.

• Trazar hacia la entrega de MVP. Enfócate en los resultados, ¿Qué es lo que los usuariosnecesitan hacer y ver cuando el sistema les muestra su resultado?

• Trazar hacia el Roadmap. Enfócate específicamente en el resultado del objetivo, ya queesto es el secreto al priorizar el desarrollo del trabajo.

• No priorizar las características, prioriza los resultados; detrás de los resultados hay com-portamiento especifico que pueda cambiar a personas comprometidas en actividades es-pecíficas. No se debe satisfacer a todos, solo a la mayoría.

• Se debe discutir varias veces el MVP, ya que no están temible el producto que es posibleentregar. El MVP es el producto más pequeño posible que puedas entregar que exitosa-mente puede lograr el resultado deseado.

• El nuevo MVP, aunque no sea un producto completo; es la forma más pequeña que sepueda crear para lograr aprobación y desaprobación.

H.1. Planificar para aprender rápido

Se debe dar disponibilidad al rápido aprendizaje y se debe empezar por discutir las oportu-nidades, con las siguientes preguntas:

• ¿Si la idea es muy grande?• ¿Cuáles son los clientes que se cree que compraría el producto?• ¿Cuáles son los clientes de las categorías de segmento que pertenecen que se cree van

a usar el producto y para qué?

Juan Carlos Alonso Holmstron 66

H.1. Planificar para aprender rápido

• ¿Por qué quisieran tener el producto? ¿Qué problemas resolverá a los clientes y usuariosque no podían resolver a la fecha? ¿Qué beneficios tendrán al comprar y al usarlo?

• ¿Por qué están fabricando el producto? ¿Si se construye este producto y es exitoso, comoesto ayudara a la empresa?

Aprender rápido, además es, validar los problemas que realmente existen y se está resol-viendo.

Hay que realizar prototipos para aprender, así se podrá plasmar la visión de la solución. Rea-lizar diseños iterativos e interactivos, utilizando el mayor tiempo con los usuarios y los clientespara crear estos prototipos. En cada iteración se aprende si la solución es viable y utilizable.Al realizar estos prototipos se debe tener cuidado, por qué se debe minimizar las veces que sevaya a construir y a la vez mantener feliz a los demás.

Construye para aprender rápido. La primera meta no es para construir un MVP, sino construiralgo menos que eso; habrá usuarios que le pueden dar algún uso potencial, talvez se impresio-ne, o también a su vez lo odien. Cualquier retroalimentación ayudará a la viabilidad del producto.Planifica las entregas con artefactos que los clientes realmente pueden utilizar. Realiza un tra-tamiento de cada entrega como un experimento y se consiente de lo que se quiere aprender.

Realiza una estrategia de la validación del aprendizaje. Se debe discriminar las suposicionesde lo real aprendido, con el siguiente circuito:

Figura H.1: Circuito para el rápido aprendizaje en el MVP (Patton et al., 2014)

Deben realizar las mínimas iteraciones a través de estos experimentos, la meta es aprender.La faceta de descubrimiento de la solución dirigirse o centrarse al usuario, también lo incluye endiferentes técnicas: ’Lean Startup’, ’Lean User Experience’, ’Design Thinking’, u otras prácticas.

67

Apéndice I

Escribiendo historias de usuarios

Los Product Owner deben tener la habilidad de escribir historias de usuario. También serproficientes al escribirlas, pueden ser largas o cortas, pero deben ser justas a la necesidaddonde el equipo colabora y conversa la importancia de sus elementos (Galen, 2013).

Los Product Owner para abordar la discusión de las historias de usuario se usan el métodode las 3C’s:

• Card (tarjeta); es la representación de la misma, que puede ser un post-it, una nota, unatarjeta, etc., Este debe estar escrito una o dos oraciones/enunciados simples y claros dela descripción del requerimiento.

• Confirmation (Confirmación); esto representa los criterios y las pruebas de aceptaciónde la historia de usuario. Esto es un complemento que ayuda a clarificar el comportamientoque la historia requiere exhibir.

• Conversation (Conversable); en el momento de leer la tarjeta y empezar a desarrollarel paisaje técnico con la reflexión de sus diseño y construcción. Este pensamiento dedesarrollo y pruebas inician conversación con el Product Owner para su implementaciónde esta perspectiva única. En esta conversación se ve, además, plasmada la visión delProduct Owner en las pruebas de aceptación.

Los Product Owner deben utilizar un formato/estructura especifico al escribirlas. Un formatoque asista en el enfoque del objetivo ’Product Partner’. Un formato con foco en la descripciónfuncional. Finalmente, un formato que apunte al valor propuesto y/o a que se trata de resolver.

Este formato es propuesto de esta forma:

Forma básicaComo “rol”Necesita o requiere “comportamiento del sistema”Por lo que da cuenta “valor del negocio”

Extensión UATDado “contexto”Cuando “tipo de acción se lleva a cabo”Entonces “determinando conjunto de observables en el caso de obtener”

Posible resultadoOfrecer un supuesto opcional del resultado obtenido

Juan Carlos Alonso Holmstron 68

I.1. Estimación de las historias de usuario

En el desarrollo de estas historias de usuario deben tener las siguientes características yque sean heurísticas; para esto se aplica el método INVEST:

• Independent (Independiente); las historias de usuario necesitan desarrollarse de formaindependientes de otras. Es importante, también, para que en el momento de su prioriza-ción de ejecución sea orquestable en el Sprint Planing.

• Negotiable (Negociables); deben ser claras para que el negocio y su percepción de valorsea negociable individualmente, entre el equipo y los ’Product Partners’.

• Valuable (Valorizable); en relación a negociable, cada historia debe ser priorizada en elorden que entregue valor, prioridad, al negocio y ’Product Partners’.

• Estimatable (Estimable); dentro de los aspectos más importantes de la gestión del Bac-kLog está el tamaño de su estimación. El tamaño de la estimación para el Product Ownerdebe estar entendido en nivel de complejidad y nivel de esfuerzo asociada a cada historia.

• Small (Pequeño); es unarelación de lo estimable, las historias de usuario su tamaño deejecución debe estar dentro de 1 Sprint.

• Testeable (Comprobable); esto enfoca en la aceptación, las historias de usuario debenser claras en la delineación de sus condiciones para comprobarlos y hacer sus pruebasde aceptación.

I.1. Estimación de las historias de usuario

Para la estimación según (Patton et al., 2014) hay ’Poker Planing’ y ’MOSCOW’

Póker Planing es una técnica que ayuda a distinguir las historias. Trata de abstraer su dificul-tad. Utilizando la secuencia de Fibonacci, los valores son 0, 1

2 , 1, 2, 3, 5, 8 y 13; esta numeraciónrepresenta los puntos en las historias de usuario indicando el tamaño de complejidad.

La Ceremonia del Póker Planing en cada historia de usuario:

1. El Product Owner o líder del equipo, alguien que entiende la naturaleza de la historia deusuario explica al equipo brevemente.

2. El equipo tiene un tiempo limitado de 3 a 5 minutos de preguntas para clarificar dudassobre la historia sin sobre analizarlas.

3. Todo el equipo piensa y reflexiona y le poner un valor.

4. Todo el equipo revisa el promedio de puntaje y quienes hayan tenido los valores mayoreso menores, se distingue las razones de sus estimaciones y se vuelve a repetir la votación.

MOSCOW; es una técnica de estimación de priorización para dividir las historias de usuarioen cuatro categorías específicas de consideración, discusión y ejecución. Estas son:

• Must Have (Debe hacerse); significa que sus características y capacidades se debenrealizarse en el entregable.

69

I. Escribiendo historias de usuarios

• Should Have (Debería hacerse); características, funcionalidades, capacidades de altapriorización.

• Could Have (Podria hacerse); de moderada priorización, se hacen si en el tiempo espermitido y a su vez son aplazables.

• Won’t Have (Que no se pueden hacerse); características, funcionalidades o capacida-des negociable en el entregable.

70

Apéndice J

Earned Value Management / Gestión del Valor Conseguido

EVM es una técnica para la gestión de proyectos que es utilizada para evaluar el progre-so de un proyecto desde los términos financieros, la utilización del tiempo y estimar un futurorendimiento versus el plan actual (Moran, 2016).

El Valor es identificado en términos de costos, con bases financieras y la utilización, segui-miento de los entregables estables versus el eje de los entregables estimado.

En el proceso de Agilidad se tiene este enfoque y toma esta variante. Lo incorpora dentrosu naturaleza de adaptabilidad en la planificación iterativa, da un carácter incremental en laelaboración de presupuestos y necesita que el valor del negocio sea asignado en historias deusuario.

Es importante y relevante entender que el valor siempre sea expresado en valores del nego-cio en lugar de términos técnicos.

“AgileEVM” está basado en el seguimiento de los costos sobre un lapso de tiempo específico,en que cada iteración incremental de presupuesto haya sido aseguradamente fundada. Loscostos son interpretados en los siguientes parámetros.

• (PV) Planned Value / Valor Planificado; durante el lapso especifico se haya presupues-tado los costos correctamente, el trabajo se haya agendado y completado a su totalidad,y reflejado la estimación del flujo del dinero.

• (EV) Earned Value / Valor Conseguido; durante el lapso cuanto trabajo ha completadoexitosamente para el monto presupuestado.

• (AC) Actual Cost / Costo Actual; los costos actuales que hayan sido incurridos duranteel lapso de trabajo conducido.

AgileEVM es una herramienta que se auto limita hacia los costos directos incurridos en elperiodo cuestionado y por eso no concierne sobre temas de rentabilidad. Además, debido a lavolatilidad del alcance en los proyectos agiles no es aconsejable tratar de incorporar presupues-tos de largo periodos; esto es porque la información disponible se encuentra fundada de formaincremental y/o iterativa su evaluación y elaboración.

La diferencia entre Valor Planificado y Conseguido es conocido como ’la variancia progra-mada’ y puede ser capturado en los gráficos Burn-down. Es importante indicar que las unidadestomadas son unidades de tiempo.

Juan Carlos Alonso Holmstron 71

J. Earned Value Management / Gestión del Valor Conseguido

Los gráficos Burn-Up diagrama de forma anticipada el número de puntos de las historiassobre el lapso en una relación lineal y compara con el número actual de puntos de las historiascompletadas.

72

Apéndice K

Simulación de una aplicación de la propuesta solución en lacompañía XYZ

La aplicación de los Fundamentos de un Tollkit de apoyo al rol de Product Owner es basa-da en la necesidad, que va creciendo y/o evolucionando, de sucesos entre los cumplimientosde satisfacer el desarrollo de esta memoria y la duración permitida en el desarrollo del proyec-to de la Compañía XYZ. El desarrollo de la necesidad fue iterativo hasta poder conseguir losFundamentos de un Toolkit.

Por consecuencia se presenta la descripción del proyecto de la Compañía XYZ. . .

K.1. La compañía XYZ y su necesidad

En la búsqueda de resolver un problema, nos encontramos con la generación de la soluciónde un problema.

La compañía XYZ, es una empresa consultora, en donde el personal es multicultural y susclientes son nacionales e internacionales. La problemática que se presenta en esta compañíaes automatizar la actual generación de reportes financieros.

La compañía consta de pocos productos internos. Estos productos se inician con la creaciónde un esquema, de forma personalizada, en que se usen metodologías ágiles.

K.2. Resolver la necesidad de la compañía XYZ

La compañía XYZ, es una empresa consultora de desarrollo de software con clientes dentroy fuera de Chile. Esta empresa tiene como iniciativa para el año 2016, el proyecto bautizado conel nombre de: “Visibilidad”, para lo cual requieren automatizar la generación de sus “ReportesFinancieros” a sus 4 niveles gerenciales.

La compañía XYZ fabrica sus propios desarrollos de software, utilizando metodología ágilScrum y LEAN. Este desarrollo se realiza utilizando Scrum.

El equipo de desarrollo a cargo de este proyecto, crecerá dependiendo de la necesidad delas etapas, del proceso de la iniciativa y también de la metodología aplicada. Además, los par-ticipantes del equipo tendrán que aprender nuevo roles, tareas y tecnologías. Esto dará como

Juan Carlos Alonso Holmstron 73

K. Simulación de una aplicación de la propuesta solución en la compañía XYZ

resultado una curva de aprendizaje, de lo teórico a lo práctico, de modo que pase de lo repro-ductivo a transferencial a crítico y a creativo.

K.3. Producto Visibility

K.3.1. Objetivo General

Documentar el aprendizaje logrado durante el proceso (de desarrollo) para llegar a desa-rrollar una aplicación para que genere de forma automática “Reportes Financieros”, utilizandometodologías ágiles y buenas prácticas de programación para minimizar los errores en el desa-rrollo.

K.3.2. Objetivos Específicos

• Formular un conjunto de buenas prácticas dentro de los roles aprendidos.• Crear claves y criterios para conseguir un equipo de alto rendimiento a través de pruebas

que miden su madurez, dentro del uso de la disciplina ágil.• Formular indicadores clave de rendimiento.

K.3.3. Alcance

Durante el proceso del proyecto en la compañía, se recopilará la mayor información posible,de modo que permita abarcar los diferentes ámbitos y roles de aprendizaje para el desarrollo deesta memoria.

Los roles que se van a documentar en el aprendizaje son los siguientes:• Product Owner

Y habrá breve documentación de:

• ScrumMaster.• Líder de Equipo.• Desarrollador.• Implementador de la solución.

K.4. Antecedentes del Desarrollo

En la búsqueda de la solución del proyecto en la empresa XYZ se ha detectado que el rolde Dueño de Producto tiene más responsabilidades, tareas e interacciones entre el equipo dedesarrollo y los Stakeholders.

74

K.4. Antecedentes del Desarrollo

Y en el adoptar el rol puede tener carencias de habilidades blandas y técnicas:

• Saber a controlar la ansiedad de no programar.• Minimizar la cantidad de reuniones innecesarias entre los clientes y los usuarios del pro-

yecto.• Saber cómo iniciar el proyecto sin confundirlo con la recopilación de información.• Evitar las sobre dimensión del proyecto con cumplir las necesidades de todos los Sta-

keholders.• No perder el control de la expectativa del cliente.

Desde antes de iniciar las incepciones y los primeros Sprints, y recuperación de informaciónde análisis se realizó el descubrimiento de su problemática.

K.4.1. Antecedentes del Proyecto Visibilidad

La compañía es una consultora, tipo Joint Venture37 , que requiere resolver una necesidadespecífica y limitada. La compañía, para resolver esta necesidad lo nombró como ProyectoVisibilidad. Para lo cual requiere de la generación de reportes financieros, automatizando elproceso.

K.4.2. Previo al inicio de la ceremonia

Este diagrama de flujo de trabajo es una representación abstracta que en su actualidad serealizan los Reportes Financieros.

Se creó un documento sobre la propuesta del proyecto. En esta propuesta se definió objeti-vos, alcance y lo procurado a realizar. Además, también conlleva un documento de confidencia-lidad del software. Una vez aceptada el documento se dio el KickOff para realizar el desarrollodel proyecto.

El Gerente de desarrollo asigno a Juan Carlos Alonso Holmstron el rol de Product Owner, loque es rol del representante del cliente en el desarrollo, y brevemente la compañía asigno unrecurso de ScrumMaster (el que es identificado como el facilitador de proyecto) para agilitar lainiciación del proyecto.

En otros antecedentes se indica que el Scrum Master asignado tiene la siguiente debilidadpara el proyecto: no tiene conocimiento de contabilidad. Esta falta de conocimiento provoca queel proyecto sea menos expedito en avanzar.

Consecuentemente el Scrum Master requiere conocer capacitación en cada uno de los 7reportes contables de la compañía a su plenitud. Una vez terminada esta explicación se podrániniciar las reuniones con los Stakeholders.

37 Joint Venture; Una empresa conjunta, alianza estratégica o alianza comercial o consorcio, también denomi-nada con el anglicismo joint venture, es un tipo de acuerdo comercial de inversión conjunta a largo plazo entre doso más personas (habitualmente personas jurídicas o comerciantes), a quienes se les denomina venturers o socios.Véase más en https://es.wikipedia.org/wiki/Empresa_conjunta

75

K. Simulación de una aplicación de la propuesta solución en la compañía XYZ

Figura K.1: Elaboración Propia: diagrama representativo del flujo de trabajo para la generaciónde reportes financieros

K.5. Primera Iteración del Ciclo de Desarrollo

El Scrum Master para el inicio de la ceremonia se empezó con itinerario estándar y bases yapreconcebidas del proyecto anterior de otro cliente.

Una observación por cada parte de la Incepción Zero hasta el día del Demo hubo aproxima-damente 6 iteraciones de 2 semanas.

K.5.1. Incepción Zero - Parte 1

La primera reunión con los Stakeholders, donde se busca conocer las necesidades, curio-samente en esta reunión solo pudieron atender los usuarios de los sistemas que se alimenta lainformación de los reportes, sin los Stakeholders principales que se requerían que realizan losreportes financieros.

En esta sesión, se podría decir, que se conoció todo lo que está detrás para hacer la in-formación. Se demostró todos los problemas para obtener la información que se requiere paraconseguirla.

Aunque muy informativa logro ser, y además de permitir más puntos de generar sistemas deautomatización, era mayormente metas a resolver, un alcance del sistema y una visión global.En resumen, se dio todo lo que esta fuera del alcance del producto a resolver.

76

K.5. Primera Iteración del Ciclo de Desarrollo

Debido a toda esta información fue necesario realizar otra reunión con los Stakeholderssobre el alcance final del desarrollo a realizar, marcar el límite de automatizar la generación delos reportes y la relación de todos los sistemas.

K.5.2. Incepción Zero - Parte 2

La segunda reunión con los Stakeholders. Esta sesión se limitó la solución a realizar. Sereciben oficialmente por parte de los Stakeholders las plantillas de los reportes idóneos.

También se realiza una base de reglas para manejar la información contable y estrictamentedesde que punto se necesita resolver.

K.5.3. Incepción Zero - Parte 3

Sesión con uno de los usuarios, Stakeholders del sistema, que realiza el ensamble de lainformación para representarla en los reportes. En esta sesión se trabaja con la propuesta desolución para realizar los reportes. Los resultados fueron prometedores, a tal medida que per-mitió a seguir con confianza para realizar un prototipo.

K.5.4. Incepción Zero - Parte 4

Sesión con los desarrolladores; previamente una semana aproximadamente a la incepciónzero parte 3 se unieron 3 desarrolladores y un consultor, uno de los mismos es un experto en elstack tecnológico seleccionado y el consultor un experto sobre realizar aplicaciones de reportes(Una observación: El experto en el stack tecnológico su asistencia fue de 2 iteraciones hastapresentar un demo al cliente).

En la sesión de la incepción se realizó los acuerdos de trabajo, se escribió las historiasde usuario. Se definió las columnas de trabajo: BackLog, Ready, Work in Progress, Validation,Signoff y Done, con su propia definición de estado. Por último, se definen los riesgos que puedenafrontar el equipo durante el tiempo de desarrollo.

K.5.5. Día del Demo

Debido al desafío de aprender contabilidad y el nuevo stack tecnológico se ha únicamentecompletado una historia de usuario y dos investigaciones. La historia de usuario con un valor degran complejidad alto (5) se completó aproximadamente un 50 %.

2 de los 3 Stakeholders del proyecto, están satisfechos del progreso; 2 de ellos son pro-motores correspondientemente, aun así, sin tener un demo presentable, ni mockups. El tercerStakeholders tiene dudas de la escalabilidad y del Stack tecnológico.

A razón de esto; se solicita una reunión de emergencia, en donde se convoca a todos losconsultores y desarrolladores expertos en aplicaciones con propósitos similares, para llevar acabo una sesión de trabajo D.A.R. (Design Assessment Report).

77

K. Simulación de una aplicación de la propuesta solución en la compañía XYZ

K.5.6. Resultados de la Evaluación

En la reunión D.A.R. con el Gerente de Desarrollo y consultores senior (todos los consul-tores en la reunión eran de nacionalidad india) se revisó nuevamente toda la documentacióndel cliente y el stack tecnológico. Se determinó que todo el stack tecnológico se debe hacer denuevo y volver hacer otra Incepción con los Stakeholders.

K.6. Revisión y resumen de la aplicabilidad del Primer Ciclodel Desarrollo

En este ciclo de desarrollo los fundamentos de un Toolkit se han aplicado solo el estadodel arte. Debido a la falta de mecanismo para laborar correctamente para el siguiente ciclo seempezó a buscar la creación formal de este Toolkit.

Lo que se puede decir de la aplicación de la totalidad del Toolkit es:

Herramienta Aplicada Comentarios

Estrategia del Producto Si

Se puede decir que hubo un trazado formal dela creación de solo:Visión y MisiónAdemás, se dio algo Design Thinking a losproblemas del negocio

UX Canvas NoNo hubo maduración al respecto del ciclo devida y no se pudo implementar metodologíaLean para el diseño del producto

LiftOff NoSe implementó un CDE formal de otro clientesin realizar la planificación correspondientedel cliente actual.

KickOff SiValores del Negocio para el SH No

Acuerdos del Trabajo NoSe implementó mal los acuerdos, se tomaronotros de otros proyectos

Definición del WorkFlow NoSe implementó mal los acuerdos, se tomaronotros de otros proyectos

Roadmap No

Historias de Usuario NoSe escribieron, pero fuera del formatocorrespondiente

Product Canvas No

Entregas de Valor y Beneficios al Negocio NoNo hubo suficiente tiempo para lograr una líneade predicción de tiempos

Cuadro K.1: Elaboración Propia: Cuadro Resumen de la aplicabilidad del Primer Ciclo del Desa-rrollo

78

K.7. Segunda Iteración del Ciclo de Desarrollo

K.7. Segunda Iteración del Ciclo de Desarrollo

Para este reinicio del Ciclo de Desarrollo se empezó a madurar la necesidad de tener unToolkit de apoyo al rol de Product Owner en vez de solo tener las bases del uso de las metodo-logías.

K.7.1. Incepción

Se trató de aplicar las mejores prácticas ante los Stakeholders y los desarrolladores. LasMejores prácticas presentes en la Compañía XYZ.

K.7.2. Sprint 0

En el nuevo stack tecnológico se nivelaron los nuevos conocimientos. Se aplicaron las bue-nas prácticas en el trabajo de equipo. Las historias de usuario se utilizaron los formatos corres-pondientes.

K.7.3. Sprint 1

En la entrega del demo, se decidió entregar valores del negocio, en vez de describir co-mo van las historias de usuario. En esta entrega a los Stakeholders indicaron satisfacción porel trabajo realizado. Pero, la gestión de las expectativas ante los Stakeholders no se realizódebidamente.

K.7.4. Sprint 2

Durante esta iteración, en la semana 5, hubo una reunión con la empresa socia; cuya geren-cia mostro interés sobre el proyecto. En esta reunión pidió planificación totalmente proyectadao al menos el Roadmap del mismo. Este Roadmap no estaba disponible por lo cual se decidiócongelar el Sprint y reiniciar el ciclo del desarrollo.

79

K. Simulación de una aplicación de la propuesta solución en la compañía XYZ

K.8. Revisión y resumen de la aplicabilidad del Segundo Ci-clo del Desarrollo

Este ciclo de desarrollo fue dirigido más a la labor de la investigación de las necesidades delas herramientas, sin poder aplicarlas en sus correspondientes elementos.

Herramienta Aplicada Comentarios

Estrategia del Producto SiSe mantuvo la visión, misión y se logró proponerlos ciclos del producto

UX Canvas NoLiftOff Si Hubo mejores reuniones con los StakeholdersKickOff SiValores del Negocio para el SH Si

Acuerdos del Trabajo SiSe logró conseguir nuevos acuerdos detrabajo con solo el equipo de desarrollo

Definición del WorkFlow SiSe renovaron los valores de Listo, Enprogreso, validado y entregado; tanto historiasfuncionales y no funcionales

Roadmap No

Historias de Usuario SiSe respetó el formato y se extendió a Pruebasde Aceptación al Usuario

Product Canvas NoEntregas de Valor y Beneficios al Negocio No

Cuadro K.2: Elaboración Propia: Cuadro Resumen de la aplicabilidad del Segundo Ciclo delDesarrollo

80

K.9. Tercer Iteración del Ciclo de Desarrollo

K.9. Tercer Iteración del Ciclo de Desarrollo

En este crucial tercer ciclo de desarrollo, la Incepción se dio al direccionar la creación delRoadmap de Objetivos del Negocio para crear el BackLog del Producto con Mapeo de historiasde Usuario y Mapa de Impacto.

K.9.1. Revisión y resumen de la aplicabilidad del Tercer Ciclo del Desa-rrollo

Para solo la primera semana del tercer ciclo se logró lo siguiente:

Herramienta Aplicada ComentariosEstrategia del Producto SiUX Canvas NoLiftOff Si Hubo mejores reuniones con los StakeholdersKickOff SiValores del Negocio para el SH SiAcuerdos del Trabajo Si

Definición del WorkFlow NoSe renovaron los valores de Listo, Enprogreso, validado y entregado; tanto historiasfuncionales y no funcionales

Roadmap SiSe logró hacer Roadmap realizando un mapeode historias de usuario funcionales conobjetivo del negocio.

Historias de Usuario SiProduct Canvas NoEntregas de Valor y Beneficios al Negocio No

Cuadro K.3: Elaboración Propia: Cuadro Resumen de la aplicabilidad del Tercer Ciclo del Desa-rrollo

81

Apéndice L

Encuesta de la propuesta de solución realizada aprofesionales

Las encuestas realizadas se realizaron de forma remota a través de google forms en laprivacidad del sujeto. A continuación, se presenta cada encuesta realizada con sus respuestascorrespondientes, correo de recepción, y fecha con hora de entrega.

Juan Carlos Alonso Holmstron 82

.

83

L. Encuesta de la propuesta de solución realizada a profesionales

84

.

85

L. Encuesta de la propuesta de solución realizada a profesionales

86

.

87

L. Encuesta de la propuesta de solución realizada a profesionales

88

.

89

Referencias

(2015). Leadership models & tools.Alliance, A. (2015). Project chartering.Atkinson, B. (2016). 5 common mistakes in developing new products.Australia, O. W. (2011). Since its establishment in 1972, ombudsman western australia has dealt

with thousands of complaints. Technical report.Beahm, G., editor (2011). I, Steve: Steve Jobs in his own words. Agate Publishing, United States.Burn, D. (2013). 5 ways to organize agile teams.Cagan, M. (2008). Inspired: How to create products customers love.Cobb, C. Pmi-acp R©: Introduction to agile project management and the pmi-acp exam.Cohn, M. and Lister, T. (2009). Succeeding with agile: Software development using Scrum.

Addison-Wesley Educational Publishers, United States, 5 edition.Consulting, L. and Consulting, L. (2014). The agile method ecosystem (scrum, xp, devops,

leanstartup).Crothers, B. (2013). Fight the dark side of lean ux with the experience canvas - atlassian blogs.DeMarco, T., Lister, T., and House, D. (2013). Peopleware: Productive projects and teams.

Addison-Wesley Educational Publishers, Boston, MA, United States, 3 edition.Design, M. . (2011). 5 product development mistakes - m3 design |strategic product develop-

ment.Eriksson, M. (2015). The history and evolution of product management.Galen, R. (2013). Scrum product ownership: Balancing value from the inside out. Rgcg, United

States.Goleman, D. Emotional intelligence: How competent are you?Goleman, D., Mayor, C., and Goleman, P. D. (2014). Liderazgo / leadership. Ediciones B,

Barcelona.Gomez, D. (2009). Cuando el scrummaster se vuelve un impedimento.Grainer, S. (2015). Design a better product with product principles.Harrin, E. (2013). 5 team structure for agile teams.Hoover, J. (2011). How to work for an idiot, revised and expanded with more idiots, more insanity,

and more incompetency: Survive and thrive without killing your boss. Career Press, SanDiego, CA, United States, 2 edition.

Irene, M. (2014). 5 habilidades para ser un líder resonante - fblog360Âo.Larsen, D. and Nies, A. (2011). Liftoff: Launching agile teams & projects. Onyx Neon Press,

United States.Leffingwell, D. and Widrig, D. (2010). Agile software requirements: Lean requirements practices

for teams, programs, and the enterprise (agile software development series). Addison-

Juan Carlos Alonso Holmstron 90

.

Wesley Educational Publishers, Boston, MA, 4 edition.Mamoli, S. (2012). Should this project be agile?Mamoli, S. (2014). Product owner. Technical report.McDonald, K. J. (2015). Beyond requirements: Analysis with an agile mindset. Addison-Wesley

Educational Publishers, Boston, MA, United States.Mironov, R. (2014). We don’t hire product owners here.Moran, A. (2016). Valuing agile: The financial management of agile projects. TSO, United

Kingdom.Noone, C. (2015). Building a problem solving product.Patton, J., Cooper, A., and Cagan, M. (2014). User story mapping: Building better products using

agile software design. O’Reilly Media, Inc, USA, Bloomington, IN, United States.Pichler, R. (2012). A product canvas for agile product management, lean ux, lean startup.Pichler, R. (2016). Strategize: Product strategy and product Roadmap practices for the digital

age. Pichler Consulting, United Kingdom.Pichler, R., Sutherl, J., and Queener, B. (2010). Agile product management with Scrum: Creating

products that customers love. Addison-Wesley Educational Publishers, United States.Rasmusson, J. (2010). The agile inception deck.Stephan, M. (2016). Lean ux canvas.Sutherland, J. (2014). Scrum: The art of doing twice the work in half the time. Crown Business,

New York, NY, United States.Svinchuk, V. (2015). Scrum & kanban: Spot the differece - perfectial blog.Szalvy, L. Top 7 responsibilities of a scrum product owner.Watts, G. (2013). Scrum mastery: From good to great servant leadership. Inspect & Adapt,

London, United Kingdom.Williams, B. and Hummelbrunner, R. (2010). Systems concepts in action: A practitioner’s toolkit.

Stanford University Press, Palo Alto, CA, United States.

91