SPOC Cuaderno de Trabajo Resuelto

© 2014 SCRUMstudy.com

v4.1

Tabla de Contenidos INTRODUCCIÓN ................................................................................................................ 3 VISIÓN GENERAL AGILE..................................................................................................... 5 ¿Qué es Agile?.......................................................................................................................... 5 ¿Por qué utilizar Agil? ............................................................................................................... 5 The Agile Manifesto ................................................................................................................. 6 Principios de Agile Manifesto ................................................................................................... 7 Declaración de Interdependencia ............................................................................................. 9 Gestión de Proyectos Tradicional versus Agil ........................................................................... 11 Preguntas - Capítulo Visión de Agile ........................................................................................ 16

VISIÓN GENERAL DE SCRUM ........................................................................................... 18 Planificando en Scrum ............................................................................................................ 18 Marco de Trabajo Scrum......................................................................................................... 19 Roles de Scrum....................................................................................................................... 22 Flujo Scrum ............................................................................................................................ 26 Preguntas - Capítulo Visión Scrum .......................................................................................... 27

FASE: INICIAR ................................................................................................................. 28 Proceso 1: Crear la Visión del Proyecto (Create Project Vision) ................................................ 28 Proceso 2: Identificar al Scrum Master y a los Interesados Identify Scrum Master and Stakeholder(s) ........................................................................................................................ 29 Proceso 3: Formar el Equipo Scrum (Form Scrum Team) .......................................................... 31 Proceso 4: Desarrollo de Epic(s) (Develop Epic(s)) .................................................................... 32 Proceso 5: Crear la Lista de Requerimientos Pendientes del Producto (Create Prioritized Product Backlog) ................................................................................................................................. 34 Proceso 6: Realizar la Planificación de las Versiones (Conduct Release Planning) ...................... 36 Preguntas - Capítulo Fase: Iniciar ............................................................................................ 39

FASE: PLANEAR Y ESTIMAR ............................................................................................. 41 Proceso 1: Crear Historias de Usuarios (Create User Stories) .................................................... 41 Proceso 2: Aprobar, Estimar y Comprometerse con las Historias de Usuarios (Approve, Estimate, and Commit User Stories) ....................................................................................................... 44 Proceso 3: Crear Tareas (Create Tasks) .................................................................................... 45 Proceso 4: Estimar las Tareas (Estimate Tasks) ........................................................................ 47 Proceso 5: Crear la Lista de Pendientes del Sprint (Create Sprint Backlog) ................................ 48 Preguntas - Capítulo Fase: Planear y Estimar ........................................................................... 51

FASE: IMPLEMENTAR ...................................................................................................... 53 Proceso 1: Crear Entregables (Create Deliverables).................................................................. 53 Proceso 2: Realizar la Reunión Diaria (Conduct Daily Standup)................................................. 54 Proceso 3: Mantenimiento de los Pendientes Priorizados del Producto (Groom Prioritized Product Backlog) .................................................................................................................... 55 Preguntas - Capítulo Fase: Implementar .................................................................................. 59

FASE: REVISAR Y RETROSPECTIVA ................................................................................... 60 Proceso 1: Convocar Scrum de Scrums (Convene Scrum of Scrums) .......................................... 60


1

Proceso 2: Demostrar y Validar el Sprint (Demostrate and Validate Sprint) .............................. 61 Proceso 3: Retrospectiva del Sprint (Retrospect Sprint) ........................................................... 62 Preguntas - Capítulo Fase: revisar y retrospectiva.................................................................... 64

FASE: LANZAMIENTO ...................................................................................................... 65 Proceso 1: Enviar los Entregables (Ship Deliverables)............................................................... 65 Proceso 2: Retrospectiva del Proyecto (Retrospect Project) .................................................... 67 Preguntas - Capítulo Fase: lanzamiento................................................................................... 68

IMPLEMENTACIÓN DE SCRUM ........................................................................................ 69 Escalabilidad de Scrum ........................................................................................................... 69 Scrum en Programas y Portafolios. ......................................................................................... 69 Transición a Scrum ................................................................................................................. 71 Preguntas - Capítulo Implementando Scrum ........................................................................... 73

IMPORTANCIA DEL VALOR .............................................................................................. 74


2

INTRODUCCIÓN Reglas Básicas del Taller    



Está es una clase que dura cinco días y cada día tendrá 3 horas de clase. Los participantes deberán estar en el aula de clases a tiempo y regresar puntualmente luego de los descansos de 15 minutos. Los teléfonos celulares deberán estar apagados o estar en modo de silencio. Se espera una completa participación por parte de los participantes. Únase a las actividades y ejercicios de acuerdo a las indicaciones del docente. Advertencia – ¡de hecho podría divertirse en este taller! Los materiales y recursos de estudio que utilizarán los participantes tienen derechos de autor y son propiedad absoluta de SCRUMstudy y PM Certifica. No deberán ser fotocopiados, distribuidos o compartidos y deberán ser utilizados únicamente por los participantes que se hayan inscrito en el aula de capacitación del Taller de Preparación para la Certificación SMC.

Objetivos del Curso    

Proveer el entendimiento de la filosofía y principios Scrum. Proveer conocimiento práctico de Scrum desde la perspectiva del Product Owner, incluyendo los roles, reuniones y artefactos. Preparar a los participantes para sentirse cómodos asumiendo el rol del Product Owner en sus organizaciones, así como también manejando conflictos y obstáculos comunes. Preparar a los participantes para rendir el examen de Scrum Product Owner Certified (SPOC™) de forma exitosa.

Resultados del Curso   

  

Los estudiantes reconocerán, definirán y trabajarán con facilidad los conceptos, ventajas y retos del Marco de Trabajo de Scrum. Los participantes estarán preparados para manejar los temas relacionados al negocio y para gestionar el compromiso de los interesados. Los estudiantes serán capacitados para desempeñar el rol de Product Owner en sus organizaciones y ayudarán a adoptar el Marco de Trabajo Scrum en estas. Este conocimiento incluye el entendimiento funcional de los otros roles de Scrum. Los participantes participarán en dinámicas en las cuales llevarán a cabo un proyecto Scrum. Los participantes contarán con las herramientas apropiadas para anticiparse a los problemas relacionados a la implementación práctica de Scrum. Se proporcionará a los participantes acceso a un examen en línea.

Metodología del Curso    

La metodología asegura una alta retención de los conceptos y teorías. Se motiva a los participantes a poner en práctica los conceptos más que a solamente escucharlos – esto provee una mejor internalización y retención. Se llevarán a cabo dinámicas prácticas y se discutirán los problemas comunes de la implementación de Scrum a través de diversos ejercicios. Los participantes ponen en práctica un caso de estudio para simular el desarrollo del producto utilizando el Marco de Trabajo Scrum.


3

Acerca de SCRUMstudy SCRUMstudy es la entidad de certificación global para las certificaciones Scrum y Agile. Una gran cantidad de información acerca de SCRUMstudy y sus programas de certificación y membresía está disponible en SCRUMstudy.com. En la parte inferior se proporciona un resumen de las certificaciones que otorga SCRUMstudy.

Expert Level

Intermediate Level

ESMCTM

SCTTM

Expert Scrum Master Certified

SCRUMstudy Certified Trainer

SMCTM

SPOCTM

Scrum Master Certified

Scrum Product Owner Certified

AECTM Agile Expert Certified

SDCTM

Foundation Level

Scrum Developer Certified

l

Membresía Básica - Gratuita Esta membresía provee acceso a las principales páginas de información, foros de discusión general y blogs limitados y recursos en línea. Los candidatos a la certificación deben tener por lo menos una Membresía Básica para poder dar cualquier examen de certificación de SCRUMstudy.

Membresía Avanzada – Cuota Anual La Membresía Avanzada provee acceso a foros de discusión y recursos en línea adicionales, además de descuentos en el precio del examen. Esta membresía es opcional.

Acerca del Examen de Certificación SPOCTM Certification Exam Formato del Examen       

Elección Múltiple 140 preguntas por examen Un punto otorgado por cada respuesta correcta No hay puntos negativos por respuestas erróneas 180 minutos de duración Examen en línea supervisado Tasa de Aprobación Actual: 93%


4

VISIÓN GENERAL AGILE ¿QUÉ ES AGILE? Jim Highsmith, un gurú conocido de Ágil, quien ha escrito varios libros sobre Agile y los métodos adaptativos, define Ágil de la siguiente forma: “La agilidad es la capacidad tanto de crear como de responder a los cambios con el objetivo de obtener beneficios en un entorno empresarial turbulento. La agilidad es la habilidad para equilibrar la flexibilidad y la estabilidad”. – Highsmith, 2002

¿POR QUÉ UTILIZAR AGIL? Con el paso del tiempo, el proceso de desarrollo de software ha sufrido cambios dramáticos. El desarrollo del software es cada vez más dinámico debido a que los entornos de negocio cambian rápidamente y las tecnologías están en constante evolución. Además, el mercado global enfrenta un incremento de presión debido a las demandas de desarrollo rápido de productos, a las modificaciones y adiciones frecuentes a los requerimientos de productos; y a la alta expectativa de que los equipos de desarrollo sean altamente flexibles y tengan conocimiento de funciones cruzadas. En respuesta a esto, las técnicas de desarrollo Agiles de productos se han desarrollado con el tiempo para atender a las necesidades de la industria. El mercado de celulares smartphone es un ejemplo de cómo y por qué Ágil es necesario para mantenerse al día con las tendencias actuales del mercado:

La rápida evolución del mercado y de la tecnología; exige estar a la vanguardia.

La disminución del "time to market" de los productos y el incremento de la innovación desde el cliente final; requiere desarrollar de forma incremental con retroalimentación.

Reducción de los costos de pruebas (simulaciones y automatización).

El valor del cliente es entregado en el punto de venta, no en la planificación.

La necesidad de un método de desarrollo adaptativo más que de uno tradicional, métodos predictivos.


5

THE AGILE MANIFESTO El Manifiesto del Desarrollo Ágil, o el Manifiesto Ágil, como es más conocido, es la creación de un grupo de diecisiete expertos en software que incluye a Kent Beck, Jim Highsmith, Ken Schwaber, Alistair Cockburn, y Robert C. Martin, quienes definieron la visión y principios de está metodología de desarrollo. Estamos descubriendo mejores formas de desarrollar software haciéndolo y ayudando a que otros lo hagan. A través de este trabajo hemos llegado a valorar:

Los individuos y las Interacciones Procesos y Herramientas Software Funcionando Documentación Extensiva Colaboración con el Cliente Negociación Contractual Respuestas ante el cambio Seguir un Plan

Es decir, mientras que hay valor en los elementos de la derecha, valoramos más los elementos de la izquierda. El permiso para copiar fue proporcionado por los autores mencionados mediante aviso en http://agilemanifesto.org/.

El manifiesto claramente establece que mayor valor tienen los puntos de la izquierda en comparación con los de la derecha, lo que implica un cambio significativo al método tradicional de cascada de desarrollo de software. 1. Individuos e interacciones sobre procesos y herramientas Aunque los procesos y herramientas ayudan a completar con éxito un proyecto o producto, las personas que se comprometen, participan e implementan un proyecto determinan el grado de eficacia de los procesos y herramientas utilizadas. 2. Software funcionando sobre la documentación extensiva Mientras que la documentación es necesaria y útil para cualquier proyecto, Ágil se enfoca en los entregables. El objetivo principal de un proyecto Ágil es entregar valor real en forma de trabajo de software de alta calidad (u otro producto o servicio). Esto no solo mejora el Retorno sobre la Inversión (ROI), sino también permite que el cliente proporcione retroalimentación oportuna. 3. Colaboración con el Cliente sobre la negociación contractual Tradicionalmente, los clientes han sido jugadores externos que participan sólo al principio y al final del ciclo de vida del proyecto, y las relaciones con ellos se basa en términos y condiciones de los contratos. Sin embargo, Ágil cree en un enfoque de valor compartido en la que los clientes son colaboradores. Un proyecto sólo puede completarse con éxito cuando hay una visión compartida del producto. 4. Responder ante el cambio en vez de seguir un plan Ser ágil significa aceptar el cambio y convertirlo en una ventaja competitiva. Debido a la situación actual del mercado que se caracteriza por frecuentes cambios en las necesidades del cliente, tecnología en constante evolución y constante fluctuación de patrones comerciales, es más importante ser flexible que seguir un plan estático.


6

PRINCIPIOS DE AGILE MANIFESTO El Manifiesto Ágil no sólo proclama los cuatro valores de la filosofía Ágil, también resalta los principios esenciales que forman el marco ideológico y estructural de cada metodología de desarrollo basado en el enfoque Ágil de desarrollo de software.

1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor. 2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente. 3. Entregamos software funcional de manera frecuente, entre dos semanas y dos meses, con preferencia el periodo de tiempo más corto posible. 4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto. 5. Los proyectos se desarrollan en torno a individuos motivados. Hay que brindarles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo. 6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara. 7. El software funcionando es la medida principal del avance del proyecto. 8. Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida. 9. La atención continua a la excelencia técnica y al buen diseño mejora la agilidad. 10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial. 11. Las mejores arquitecturas, requisitos y diseños emergen de equipos autoorganizados. 12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para que como consecuencia procedan a ajustar y perfeccionar su comportamiento.


7

PRINCIPIO

CONSECUENCIAS

1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.

 Satisfacción al cliente (no a la oficina de gestión de proyectos).  Entrega temprana y continua (obteniendo retroalimentación temprana para solucionar los problemas).  Software que entrega valor (se enfoca en el valor y en el producto final, no en la documentación).  Aceptación del cambio; que sucederá de todos modos.  Esfuerzo por proporcionar información más reciente, funcionalidad de alto valor (ventaja competitiva).  Mayor tiempo que puede ser invertido en el producto final, aceptando el cambio en lugar de luchar contra él.

2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

3. Entregamos software funcional de manera frecuente, entre dos semanas y dos meses, con preferencia el periodo de tiempo más corto posible. 4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.

5. Los proyectos se desarrollan en torno a individuos motivados. Hay que brindarles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.

6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.

 Entrega frecuente.  Retroalimentación temprana y frecuente.  Detección si se puede proceder o si se necesita cambiar las cosas.  Mantiene clientes comprometidos.  Los desarrolladores aprenden sobre el negocio y lo entienden.  Los representantes del negocio logran un mejor entendimiento de lo que es difícil/costoso desarrollar y lo que es fácil/barato.  El equipo se esfuerza por tener reuniones diariasmayor frecuencia, mejor.  Mantiene a la gente del negocio comprometida.  La diferencia de “tener el mejor equipo” frente a “tener los mejores procesos y herramientas” es de 10 a 1.  Los equipos empoderados confían en su experiencia y su trabajo en equipo.  Dan apoyo cuando es necesario.  Gente motivada.  Las emociones y el lenguaje corporal se consideran como elementos importantes del proceso de la comunicación.  La realidad mostrará que la comunicación cara a cada no siempre se puede dar, en estos casos, se utilizará medios similares como video conferencia.

7. El software funcionando es la medida principal del avance del proyecto.

 Hacer software que funcione es el enfoque principal. La documentación se convierte en la segunda prioridad, en un rol de soporte.  La medida del software esta relacionado a lo “terminado”.

8. Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.

 Mientras las metodologías ágiles están orientadas a la flexibilidad y a generar valor en un corto plazo, también se esfuerzan por maximizar el valor del tiempo.  No se agotarán las personas valiosas.


8

PRINCIPIO

CONSECUENCIAS

9. La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.

 En el mundo del software, una vez que este está muy interrelacionado, este se convierte resistente al cambio.  Conservan el software para que se pueda mantener fácilmente.  Dedicación de un poco de esfuerzo para mantener el software flexible (refactorización). Si el producto llega a ser inflexible y resistente al cambio, entonces no será posible direccionar los requisitos cambiantes de forma rápida.  En el mundo del software, el 60% de las funcionalidades implementadas son difícilmente (o nunca) utilizadas.  Se evita el código muerto que desperdicia esfuerzo y causa problemas.  Utilización del método más sencillo posible primero.

10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.

11. Las mejores arquitecturas, requisitos y diseños emergen de equipos autoorganizados.

12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para que como consecuencia procedan a ajustar y perfeccionar su comportamiento.

 Para obtener lo mejor de las personas, se deja que ellos se auto-organicen, lo que incluye sus asignaciones.  Aumenta el compromiso y orgullo por su trabajo.  El equipo conoce mejor lo que funciona o lo que no.  Las lecciones aprendidas se trabajan a lo largo del proyecto, no sólo al final.  Dado que el cambio es aceptado y es posible que se dé durante el proyecto, no se espera hasta que el proyecto termine para las lecciones aprendidas.  El equipo definirá los cambios necesarios y los pone en práctica.  Al hacerlo, pueden beneficiarse inmediatamente de las mejoras al proyecto en curso.

DECLARACIÓN DE INTERDEPENDENCIA

Escrita en 2005 como complemento al Manifiesto Ágil, la “Declaración de Interdependencia” es la piedra angular de las prácticas ágiles. Liderada por Alistair Cockburn, un grupo de directores de proyecto escribieron esta declaración. El manifiesto identifica el “qué”, y la Declaración de Interdependencia (DOI) explica el “por qué”.


9

Declaración de Interdependencia

Los enfoques ágiles y adaptables vinculan personas, proyectos y valor. Somos una comunidad de líderes de proyecto altamente exitosos en la entrega de resultados. Para alcanzarlos: 

Incrementamos el retorno de inversión, haciendo del flujo continuo de valor nuestro enfoque.



Entregamos resultados fiables mediante la participación de los clientes en las interacciones frecuentes y la propiedad compartida.



Esperamos la incertidumbre y la gestionamos a través de iteraciones, anticipación y adaptación.



Liberamos la creatividad y la innovación al reconocer que las personas son la fuente más grande de aporte de valor, y creamos un entorno en el que pueden hacer la diferencia.



Impulsamos el rendimiento mediante la rendición de cuentas del grupo para resultados y la responsabilidad compartida para la eficacia del equipo.



Mejoramos la eficacia y la confiabilidad a través de estrategias, procesos y prácticas específicas a la situación.

El DOI es un documento importante para todos los involucrados en un proyecto de desarrollo. Es aún más importante para el Product Owner porque este proporciona reglas para este rol. La tarea del Product Owner es: 

Garantizar un mayor retorno de la inversión (ROI) centrándose en el valor y su flujo continuo. El Product Owner es el interesado clave y posee la visión clara del proyecto. Debido a que el Product Owner bosqueja el Product Backlog, el o ella puede asegurar que el modelo de desarrollo iterativo e incremental se enfoque principalmente en la entrega continua de funcionalidades del negocio que den valor, y a su vez mejore el retorno de la inversión.



Obtener resultados fiables mediante la maximización del involucramiento del cliente. El Product Owner compromete a los clientes en interacciones frecuentes e inculca un sentido de propiedad compartida. Ágil es una metodología orientada a las personas porque promueve la participación directa y activa de los clientes. El Product Owner representa al cliente- el o ella es la Voz del Cliente, o VOC- y es el puente entre los interesados y el Equipo Scrum. El Product Owner da la perspectiva del cliente, decide la Visión del Producto, prioriza los elementos del Product Backlog, y proporciona criterios de aceptación para estos elementos.



Esperar que la incertidumbre y los riesgos disminuyan al dividir el trabajo en pequeñas iteraciones, impulsados por el valor basándose en los principios de la anticipación y la adaptación. La incertidumbre y los riesgos son inevitables en cualquier actividad de desarrollo; no deben ser ignorados o pospuestos; por el contrario deben ser identificados y gestionados. El Product Owner juega un rol importante en este tema, porque es responsable de evaluar la viabilidad y garantizar la entrega del producto.


10



Liberar la creación y la innovación mediante el reconocimiento que el software y el desarrollo de productos es una actividad humana, y las personas son la fuente última de valor. Un ambiente agradable para las personas permite que estas se diferencien a través de la creatividad y la innovación.



Impulsar el rendimiento mediante la activación de la rendición de cuentas grupal para obtener los resultados a través de la responsabilidad compartida en la eficacia del equipo. Cada actividad de desarrollo es una actividad dinámica, y todo el equipo tiene que ser responsable de su propio rendimiento. El Product Owner necesita ponerse a disposición de inmediato del equipo Scrum durante todo el proyecto para su retroalimentación y aclaraciones. Es su responsabilidad garantizar que la Visión del Producto y las funcionalidades prioritarias se entiendan claramente para fomentar un alto rendimiento.



Mejorar la eficacia y la confiabilidad a través de la implementación de estrategias específicas para cada situación, procesos y prácticas. El Product Owner asegura que las estrategias sean adecuadas para cada situación. Los procesos y las prácticas son los factores clave de cualquier actividad de desarrollo. Dado que los proyectos reales son complejos y están colmados de problemas, el Product Owner tiene que asegurar que los procesos estén alineados con la Visión del Proyecto.

GESTIÓN DE PROYECTOS TRADICIONAL VERSUS AGIL

Las metodologías ágiles requieren un cambio de mentalidad respecto a los métodos tradicionales. Mientras que los métodos de cascada se centran en el alcance y esta es utilizada para determinar los costos y el cronograma, el marco de trabajo ágil se enfoca en el valor del negocio y este se utiliza para determinar la calidad y las limitaciones de desarrollo. Mientras que el modelo de cascada es adecuado para ambientes ordenados y/o predecibles, los métodos ágiles son más exitosos en entornos caóticos porque son métodos “chaordic” [chaos+order]. Mientras que los modelos de cascada creen en un modelo de agente racional, los métodos ágiles se inclinan a basarse en enfoques de valor compartido. El método de cascada utiliza estructuras de comando control, mientras que los métodos ágiles utiliza estructuras más planas, colaborativas basadas en ciclos de inspección-adaptación.


11

Una comparación entre los métodos ágiles y tradicionales:

Enfoque

Agile

Gestión de Proyectos Tradicional: Cascada

El énfasis está en

Personas

Procesos

Dominio

No predecible/exploratorio

Predecible

Documentación

Sólo mínima según se requiera

Exhaustivo

Aseguramiento de Calidad

Centrada en el Cliente

Centrada en el Proceso

Estilo de Procesos

Iterativo

Lineal

Organización

Auto-organizada

Gestionada

Planificación por Adelantado

Baja

Alta

Perspectiva hacia el cambio

Adaptabilidad

Sostenibilidad

Priorización de los Requisitos

Según el valor del negocio y regularmente actualizada

Fija según el plan de proyecto

Estilo de Gestión

Descentralizado

Autocrático

Liderazgo

Colaborativo, Líder Servicial

Comando y control

Medición del Rendimiento

Valor del negocio

Plan de Conformidad

Retorno sobre la Inversión (ROI)

Al comienzo y a lo largo del proyecto

Al final del proyecto

La figura de abajo muestra la diferencia entre el Método de Gestión Tradicional y el Ágil representado por un proyecto Scrum.


12

Lanzamiento

Scrum vs Método Tradicional

Como se ilustra en el diagrama anterior, los proyectos Scrum se completan de forma iterativa de tal forma que las funcionalidades son liberadas al final de cada iteración- llamada Sprint en Scrum. De preferencia, aquellas que tiene alto valor al negocio se completan primero. Varios equipos multifuncionales trabajan en paralelo a través de los Sprints para ofrecer soluciones potencialmente comercializables al final de cada Sprint. El número de funcionalidades no terminadas – mostradas con una línea discontinua – decrece de manera constante a través del proyecto Scrum. En el método tradicional, la cantidad de funcionalidades no terminadas sigue siendo alta hasta el final y muy cerca del final del proyecto. Debido a que cada Sprint da como resultado un incremento de producto (que es parte del producto final), existe un objetivo medible que el equipo tiene que cumplir, por lo que se asegura el avance y así el proyecto podrá terminar a tiempo. Los métodos tradicionales no ofrecen dichos controles y, por lo tanto, pueden dar lugar a situaciones en las que el equipo podría relajarse y terminar con mucho trabajo al final. Debido a que el cliente interactúa regularmente con el Equipo Scrum, el trabajo completado es revisado regularmente; por lo tanto, se garantiza que el progreso satisface con las especificaciones del cliente. En la gestión tradicional, no hay tal interacción porque el trabajo se lleva a cabo en silos y no hay funcionalidad que se pueda mostrar hasta el final del proyecto. En proyectos complejos, en los que el cliente no tiene claro cuál será el producto final, por lo que, las funcionalidades del producto cambian, el modelo iterativo es más flexible para asegurar que estos se puedan incorporar durante el desarrollo. La gestión de proyectos tradicional lucha para dar cabida a dichas funcionalidades. Sin embargo, en el caso de proyectos sencillos con funcionalidades bien definidas, y cuando el equipo tiene la experiencia para desarrollar estos proyectos y por lo tanto puede hacer estimaciones precisas, el método de cascada puede tener éxito.


13

Métodos Ágiles Método Scrum

Valores Principales  Control del Proceso Empírico  Auto organización  Colaboración  Priorización basada en valor  Time-boxing  Desarrollo iterativo

Características Roles Modelo iterativo time-  Product Owner boxed con equipos  Scrum Master auto-organizados.  Scrum Team Procesos como Crear el Sprint Backlog, Crear Entregables, Mantener el Product Backlog Priorizado, y la Retrospectiva del Spring son parte de cada Sprint. Las Reuniones Diarias ayudan a tener una comunicación abierta. Propiedad individual de clases, modelamiento de dominio de objeto, equipos de funcionalidades, modelamiento inicial, gestión de configuración de modelo de turbulencia, y desarrollos regulares.

 Jefe de Proyecto  Jefe de Arquitectura  Gerente de Desarrollo  Jefe de Programación  Dueño de Clases  Experto del Dominio

EP Programación  Simplicidad Extrema  Comunicación  Retroalimentación  Coraje  Respeto

Enfocado en buenas prácticas de desarrollo de software, Programación en Pares, Desarrollo orientado a las Pruebas TDD, Propiedad colectiva de código y refactorización.

 XP Coach  XP Customer  XP Programmer  XP Admnistrator  XP Tracker  XP Tester

DSDM Métodos de  Enfocarse en la Desarrollo de necesidad del negocio Sistemas Dinámicos  Entregar a tiempo  Colaborar  Nunca comprometer la calidad  Construir incrementalmente a través de bases sólidas  Desarrollar iterativamente  Comunicarse Continua y Claramente  Demostrar Control

Fase de pre-proyecto, fase del ciclo de vida del proyecto, y fase de post-proyecto. Estudio de factibilidad, Estudio de negocio, Iteración del modelo funcional, Iteración de diseño y desarrollo, e implementación.

 Advisor user  Ambassador user  Analyst  Architect  Developer  Executive Sponsor  Project manager  Stakeholder  Tester  Visionary

FDD Desarrollo Basado en Funcionalidades

Planear, diseñar, y construir por funcionalidad.


14

Otros Métodos Ágiles

Crystal Clear

Lean Development

Kanban Development

Agile Unified Process


Essential Unified Process

Open Unified Process

15

PREGUNTAS - CAPÍTULO VISIÓN DE AGILE 1. ¿Cuál de las siguientes NO es un Principio del Manifiesto Ágil? a. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor. b. Aceptamos que los requisitos cambien, a menos que el proyecto se encuentre en etapas tardías del desarrollo. Los cambios tardíos en el ciclo de desarrollo es muy caro de adoptar. c. Entregamos software funcional de manera frecuente, entre dos semanas y dos meses, con preferencia el periodo de tiempo más corto posible. d. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto. 2. ¿Qué componentes describen el enfoque Ágil? a. b. c. d.

Manifiesto ágil, declaración de interdependencia y principios ágiles. Manifiesto ágil, declaración de interpretación y principios ágiles. Manifiesto ágil, declaración de interdependencia y prácticas ágiles. Políticas ágiles, declaración de interdependencia y principios ágiles.

3. ¿Cuál de las siguientes NO es una característica de los proyectos Ágiles? a. b. c. d.

Auto-organizados Iterativos Flexible Comando y Control

4. Identifica el principio ágil INCORRECTO y su consecuencia. a. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto: es obligatorio que los interesados y el equipo se reúnan y conversen diariamente. b. La atención continua a la excelencia técnica y al buen diseño mejora la agilidad: esto permite que el software sea fácil de mantener. c. Las mejores arquitecturas, requisitos y diseños emergen de equipos autoorganizados: los equipos auto-organizados tienen un alto nivel de apropiación en los diseños que ellos crean. d. Entregamos software funcional de manera frecuente: esto asegura la retroalimentación oportuna que puede ser incorporada al proceso de desarrollo de productos en una etapa temprana. 5. La Declaración de Interdependencia (DOI) es un documento importante en gestión de proyecto, especialmente para los Product Owners (PO). ¿Cuál de los siguientes enunciados respecto al DOI, NO es correcto? a. Recuerda al PO que el enfoque principal de desarrollo de proyectos es el ROI temprano. b. Afirma que el PO debe garantizar resultados confiables inculcando un sentido de propiedad compartida en los interesados. c. Establece que el PO es la voz oficial de todos los temas; el equipo no gozará de autonomía en cualquier parte del proceso de desarrollo. d. Reconoce que la incertidumbre y los riesgos son inevitables dentro del proceso de desarrollo, por lo que el PO juega un papel importante gestionando la incertidumbre y reduciendo el riesgo.


16

6. ¿Cuál de los siguientes principios NO es soportado por Ágil? a. El enfoque principal del proceso de desarrollo es asegurar incrementar el retorno sobre la inversión (ROI). b. El modelo de desarrollo iterativo e incremental debe enfocarse en la entrega continua de características valoradas por el negocio. c. La interferencia continua de los clientes obstaculiza el proceso de desarrollo, por lo que el involucramiento del cliente deberá reducirse al mínimo. d. Estrategias para situaciones específicas, procesos y prácticas deben ser implementadas para asegurar la efectividad y confiabilidad.


17

VISIÓN GENERAL DE SCRUM Scrum es uno de los marcos de trabajo ágil para desarrollo de proyectos. Emplea un enfoque adaptativo e iterativo para gestionar proyectos y desarrollo de productos. Ha sido diseñada para ser rápida, es un método flexible que entrega alto valor en el menor tiempo.

PLANIFICANDO EN SCRUM A diferencia de los métodos tradicionales de planificación de proyectos que implican una planificación adelantada que demanda mucho esfuerzo, la planificación de un proyecto Scrum es un esfuerzo continuo. Después de algunas demostraciones, los interesados pueden comunicar mejor los requisitos. Esto permite replanificar el proyecto de acuerdo a los nuevos requerimientos. Otra característica de los proyectos Scrum es que los cambios pueden hacerse en cualquier etapa del proyecto. Esto no quiere decir que en Scrum no se planifica. En lugar de ello, los planes se desarrollan durante todo el proyecto en base a repriorizaciones, retroalimentación y otros factores emergentes. Así, la planificación inicial Scrum sólo incluye la creación de un esquema básico del proyecto. Durante el desarrollo, la planificación es completada en ráfagas cortas, según sea necesario. Las metodologías ágiles (incluyendo Scrum) reducen los residuos mediante la disminución de trabajo que no entrega valor. La planificación de un proyecto no aporta directamente valor al negocio. Por lo tanto, la planificación en cualquier etapa de un proyecto Scrum debe ser lo más eficiente posible. La planificación adelantada para el proyecto completo se considera desperdicio, porque los proyectos Agiles están propensos a una alta tasa de cambio. Por lo que, la planificación se realiza Justo a Tiempo (Just in Time (JIT)).

Scrum es más útil en proyectos que involucren los siguientes puntos: 1. El desarrollo de proyectos de tecnología de vanguardia. 2. Los equipos son multifuncionales, altamente calificados y dedicados. 3. El desarrollo de productos se desenvuelve en entornos hipercompetitivos. 4. Los cambios de requisitos con frecuentes e intempestivos. 5. Necesidad frecuente de retroalimentación debido a los requisitos complejos.


18

MARCO DE TRABAJO SCRUM De acuerdo con Una guía para el conocimiento de Scrum (Guía SBOK™ 2013), Scrum puede ser mejor entendido a través de sus principios, procesos y aspectos.

Principios Scrum 1. Control del Proceso Empírico Scrum establece que la toma de decisiones basada en la observación y experimentación es mejor que la planificación detallada al inicio del proyecto. El control del proceso empírico está basado en tres ideas principales: transparencia, inspección y adaptación. Este enfoque es más apropiado para procesos que generan salir no repetibles e impredecibles. 2.

Auto-organización En lugar del estilo de gestión tradicional comando y control, Scrum enseña que los trabajadores de la actualidad tienen mucho conocimiento que ofrecer que sólo su experiencia técnica y que pueden entregar mayor valor cuando se auto-organizan.

3. Colaboración Scrum enseña que el desarrollo del producto es un proceso de creación de valor compartido que necesita que los interesados trabajen e interactúen junto para entregar mayor valor. 4. Priorización basada en el valor La entrega de alto valor en un tiempo corto requiere priorizar y dividir lo que se hará a partir de lo que necesita ser implementado. 5. Time-boxing El tiempo es considerado una restricción y el time-boxing proporciona el ritmo con el que todos los interesados trabajan y contribuyen. Time-boxing se refiere a la fijación de periodos cortos de tiempo para realizar una actividad. Si el trabajo realizado queda incompleto al final del time-box, entonces este se mueve a otro time-box. Ejemplos de time-boxes de Scrum incluyen:  Las reuniones diarias de Scrum (15 minutos por lo general)  Iteraciones que duran entre una a seis semanas. © 2014 SCRUMstudy.com

19

Los time-boxes pueden proporcionar la estructura adecuada para proyectos ágiles que tienen un componente de incertidumbre, son dinámicos por naturaleza, y son propensos a los cambios. Ayudan a medir el progreso del proyecto e indican cuándo modificar el enfoque. 6. Desarrollo Iterativo En proyectos complejos – en los que el cliente no es capaz de definir requisitos muy concretos o no está seguro cómo lucirá el producto final – el modelo iterativo es más flexible para asegurar que cualquier cambio solicitado por el cliente sea incluido como parte del proyecto. La nueva información puede ser utilizada para refinar y mejorar la precisión de los planes, requerimientos, estimaciones y otros aspectos del proyecto. Un principio esencial de Scrum es que los requerimientos de cualquier proyecto de largo plazo no pueden ser entendidos completamente o definidos al inicio del proyecto, especialmente si el mercado sufre cambios constantemente, por lo que este enfoque debe permitir que el equipo sea flexible para incorporar cambios de requerimientos. En el enfoque tradicional, el método predictivo de desarrollo no puede manejar tales cambios. En cambio, Scrum es especialmente útil para proyectos complejos con gran incertidumbre en los cuales los pronósticos de largo plazo podrían conllevar a riesgos críticos. Aspectos Scrum Los aspectos de Scrum se deben abordar y gestionar a lo largo de un proyecto Scrum. Los cinco aspectos de Scrum son: 1. Organización 2. Justificación de Negocio 3. Calidad 4. Cambio 5. Riesgo Procesos de Scrum Un proyecto Scrum sigue el modelo de cinco fases. Las cinco fases son las siguientes: 1. Iniciar 2. Planear y Estimar 3. Implementar 4. Revisión y Retrospectiva 5. Lanzamiento


20

Los 19 procesos de Scrum abordan las actividades y el flujo específico de un proyecto Scrum.

Fase

Procesos Crear la Visión del Proyecto Identificar al Scrum Master e interesados

Initiate

Formar el Equipo Scrum

(Iniciar)

Desarrollar Epic(s) Crear la Lista de Pendientes del Producto Priorizada Realizar la Planificación de las Entregas (Release) Crear Historias de Usuarios

Plan and Estimate

Aprobar, Estimar y Comprometerse con Historias de Usuarios

(Planear y Estimar)

Crear Tareas Estimar el Trabajos Crear la Lista de Pendientes de Sprint Crear Entregables

Implement Realizar el Standup Diario (Implementar) Mantener la Lista de Pendientes del Producto Priorizada Review and Retrospect (Revisión Retrospectiva)

Convocar Scrum de Scrums y Demostrar y Validar el Sprint Realizar la Retrospectiva del Sprint

Release

Enviar los Entregables

(Lanzamiento)

Realizar la Retrospectiva del Proyecto


21

ROLES DE SCRUM Los roles de Scrum se dividen en dos categorías: 

Core Roles—Los Core Roles son las funciones que obligatoriamente se requieren para producir el producto o servicio del proyecto, estos están comprometidos con el proyecto, y son los responsables del éxito de cada Sprint y del proyecto en su totalidad.



Non-core Roles: Son las funciones que no son obligatoriamente necesarias para el proyecto Scrum, y pueden incluir miembros de los equipos que están interesados en el proyecto, pero no tienen ningún papel formal en el equipo del proyecto. Ellos pueden interactuar con el equipo, pero no son responsables del éxito del proyecto. Estos roles no esenciales también deben tenerse en cuenta en cualquier proyecto de Scrum.

Los core roles son el Product Owner, Scrum Master, y el Equipo Scrum. Juntos se les conoce como el Equipo Central/Principal de Scrum (Scrum Core Team). Es importante tener en cuenta que, de estos tres roles, ninguno tiene autoridad sobre los otros. La figura presenta un resumen de los roles principales del Equipo Core de Scrum.


22

Equipo Scrum El Equipo Scrum es responsable de crear los entregables del producto. Un Equipo Scrum normalmente es pequeño, tiene entre 6 a 10 miembros. El equipo decide la cantidad de trabajo comprometido en un Sprint. El Equipo Scrum normalmente es multi-funcional, ejecutan tareas de desarrollo, aseguramiento de calidad, etc... Responsabilidades y Roles Generales

Es multi-funcional y auto-organizado. Goza de completa autonomía durante un Sprint Sus miembros son generalistas en los distintos dominios y especialistas en al menos uno. La igualdad se mantiene entre todos los miembros del equipo. Responsabilidad recae en todo los miembros del equipo.

Scrum Master El Scrum Master es un protector y facilitador que asegura que el equipo cuente con el mejor ambiente para completar con éxito el desarrollo del producto. El Scrum Master ayuda al equipo a aplicar las prácticas Scrum y protege el equipo de impedimentos externos, promoviendo así la eficacia de este.

Responsabilidades y Roles Generales

Es un protector y facilitador del equipo. Protege al equipo de interferencias externas. No consigue que el trabajo sea hecho, pero sí facilita el equipo. Asegura que el equipo siga e implemente prácticas Scrum. Motiva al equipo, es un coach del equipo. Como agente de cambio, asegura un proceso de cambio fluido y efectivo.

Product Owner (Dueño del Producto) El Product Owner interviene en el proyecto desde el punto de vista del cliente. El cliente es la persona u organización que adquiere el producto, servicio u otro resultado. El cliente es un interesado importante junto con los usuarios y patrocinadores. Product Owner representa a los interesados y a sus necesidades; es responsable de asegurar que el Equipo Scrum entregue valor, a través del producto, al proyecto. El Product Owner es “dueño” del producto y es responsable de la finalización exitosa del proyecto; este rol es el enfoque principal de este curso. La siguiente tabla resume las responsabilidades del Product Owner en los diferentes procesos de Scrum.


23

Proceso

Responsabilidades del Product Owner

Create Project Vision

 

Define la Visión del Proyecto Ayuda a crear el Acta de Constitución del Proyecto y el Presupuesto del Proyecto

Identify Scrum Master and Stakeholder(s)

 

Ayuda a elegir al Scrum Master para el proyecto Identifica a los interesados

Form Scrum Team

  

Ayuda a determinar los miembros del Equipo Scrum Ayuda a desarrollar el Plan de Colaboración Ayuda a desarrollar el Plan para la Formación del Equipo con el/los Scrum Master(s)

Develop Epic(s)



Crea Epic(s) y Personas



Prioriza los elementos del Product Backlog (cartera de pendientes) Define el Criterio de Terminado (Done)

Create Prioritized Product Backlog

 

Conduct Release Planning



Crea un Cronograma de Planificación de Versiones (Releases) Ayuda a determinar la duración del Sprint

 

Ayuda a crear Historias de Usuarios Define el Criterio de Aceptación para cada Historia de Usuario

 

Aprueba los Historias de Usuarios Facilita el compromiso del Equipo Scrum sobre las Historias de Usuarios que puede implementar.



Explica las Historias de Usuarios al Equipo Scrum mientras crean la Lista de Tareas



Proporciona orientación y aclaración al Equipo Scrum en la estimación de esfuerzo para las tareas

Create Sprint Backlog



Ayuda al Equipo Scrum a crear el Sprint Backlog

Create Deliverables



Aclara los Requisitos del Negocio al Equipo Scrum



Refina la Product Backlog y reprioriza si es necesario

 

Acepta / Rechaza los Entregables Proporciona retroalimentación al Scrum Master y al Equipo Scrum Actualiza el Plan de Versiones (Releases) y la Priorización del Product Backlog

Create User Stories Approve, Estimate and Commit User Stories Create Tasks Estimate Tasks

Groom Prioritized Product Backlog

Demonstrate and Validate Sprints

 

Ayuda con el lanzamiento de las Versiones de Producto y se encarga de la coordinación con el Cliente



Participa en las Reuniones de Retrospectiva del Proyecto

Ship Deliverables Retrospect Project


24

De la misma forma que existe un rol de Product Owner en un proyecto, podría haber un Product Owner del Programa en un Programa, o un Product Owner del Portafolio en un Portafolio.

Voz del Cliente - Voice of the Customer (VOC) El cliente es el interesado más importante para cualquier compañía. Por lo tanto, es muy importante entender sus necesidades y requerimientos. La voz del cliente se enfoca en necesidades declaradas y no declaradas del cliente, que deben entenderse muy bien antes de diseñar cualquier producto o servicio. En general, en un entorno de Scrum, El Product Owner representa la Voz del Cliente. La siguiente figura enumera las características deseables para los roles básicos de Scrum.


25

FLUJO SCRUM La figura a continuación proporciona una visión general del flujo de un proyecto Scrum.

•

El ciclo de Scrum comienza con la Fase de Inicio, durante la cual se determina la Visión del Proyecto y se crea el Product Backlog (Cartera de Necesidades) priorizado.

•

Luego el trabajo es completado en varios Sprints. Cada Sprint comienza con una Reunión de Planificación del Sprint (Sprint Planning Meeting) durante la cual son escogidas las tareas (los elementos con prioridad alta del Product Backlog) para el Sprint próximo a comenzar.

•

Un Sprint suele durar entre 1 - 6 semanas en el cual el Equipo Scrum trabaja en la elaboración Entregables (Deliverables) potencialmente listos en incrementos de producto.

•

Las reuniones diarias (Daily Stand-up Meetings) se llevan a cabo durante el Sprint donde Los miembros del Equipo Scrum reportan el trabajo avanzado, el trabajo que se proponen terminar y los impedimentos que están afrontado.

•

Al final del Sprint, se lleva a cabo una reunión de revisión del Sprint (Sprint Review Meeting) en el cual se le presenta una demostración del trabajo terminado al Product Owner y a los interesados relevantes. El Product Owner acepta o rechaza los entregables presentados.

•

El ciclo de Sprint termina con una Reunión de la Retrospectiva del Sprint (Retrospect Sprint Meeting).


26

PREGUNTAS - CAPÍTULO VISIÓN SCRUM 1. ¿Qué método de proceso de control es seguido en Scrum? a. Definido b. Empírico c. Explícito d. Lógico 2. ¿Cuál de los siguientes NO es correcto? a. Ágil valora las personas sobre los procesos. b. Ágil valora el valor del negocio sobre el plan de conformidad. c. Ágil valora el control definido del proceso sobre el control empírico del proceso. d. Ágil valora el liderazgo colaborativo sobre comando y control. 3. ¿Quién de los siguientes representa la voz del cliente? a. Scrum Master b. Product Owner c. Líder Equipo Scrum d. Ninguno de los anteriores 4. Todas las siguientes son ventajas de un equipo multifuncional, EXCEPTO: a. Toma rápida de decisiones b. Mejor comunicación c. Competencia efectiva d. Orientado al objetivo 5. Todos los siguientes son atributos de un miembro del Equipo Scrum Ideal, EXCEPTO (seleccione todas las que correspondan): a. Auto-motivado b. Orientado al proceso c. Dependiente d. Colaborar 6. ¿Cuál de las siguientes es responsabilidad del Scrum Master (seleccione todas las que correspondan)? a. Capacitar y facilitar al Equipo Scrum b. Completar el desarrollo del producto de forma exitosa c. Proporcionar al equipo un entorno de trabajo saludable d. Conseguir recursos financieros para el desarrollo del producto 7. ¿Quién es responsable del desarrollo del producto? a. Scrum Master b. Equipo Scrum c. Patrocinador d. Product Owner


27

FASE: INICIAR La primera fase de método Scrum es la fase Iniciar. Los procesos relacionados con la iniciación de un proyecto son los siguientes: Crear la Visión del Proyecto, Identificar al Scrum Master e interesados, Formar el Equipo Scrum, Desarrollar Epic(s), Crear la Lista de Pendientes del Producto Priorizada, Realizar la Planificación de las Versiones (Release).

PROCESO 1: CREAR LA VISIÓN DEL PROYECTO (CREATE PROJECT VISION) Define la Visión del Proyecto Una salida importante de este primer proceso de la fase de Iniciar es la identificación del Product Owner. El Product Owner es la persona responsable para que el proyecto brinde el máximo valor al negocio. Él o ella también es responsable de la articulación de requisitos por parte de los Clientes y de mantener la Justificación de Negocio para el Proyecto. El Product Owner representa a la voz del Cliente. Cada Equipo Scrum tendrá un Product Owner designado. Otro resultado clave del proceso Crear la Visión del Proyecto es una forma y bien estructurada Declaración de la Visión del Proyecto, la cual explica la necesidad del negocio y que es lo que el Proyecto tiene como objetivo satisfacer, en lugar de cómo se va a satisfacer la necesidad. Un Product Owner debe ser capaz de concebir el éxito de un producto. Las organizaciones generalmente realizan estudios de mercado y otras actividades, como la planificación y el análisis, para conceptualizar los productos. Un inconveniente de este enfoque es que se asume que los requisitos del clientes son predecibles y se ignoran otros factores de variación. Otro enfoque consiste en sumergirse en el proceso de desarrollo. Este podría llevar a un gran error, porque la organización no ha medido con precisión los requerimientos del cliente o incluso no entiende qué aspecto debe tener el producto para que sea exitoso. Una buena Visión de Producto describe qué aspecto debe tener el producto y cómo funcionará. Es un documento que crea un objetivo único para que el equipo trabaje enfocado a este. Es un punto de referencia para el equipo en caso exista alguna ambigüedad en los requerimientos del cliente. Una buena Visión de Producto responde a las siguientes preguntas: 

¿Quién es el cliente objetivo?



¿Cuál es la oportunidad del producto?



¿A qué categoría pertenece el producto?



¿Cuáles son los principales beneficios que obligan a los usuarios a comprar el producto?



¿Cómo se diferencia de los productos de la competencia?



¿Cuál es el punto de venta principal?

Ayuda a crear el Acta de Constitución y el Presupuesto del Proyecto Un Acta de Constitución es una declaración oficial de los objetivos y salidas deseados del proyecto. En muchas organizaciones, el Acta de Constitución es un documento oficial autorizado formalmente del proyecto, proporcionando al equipo un mandato escrito para comenzar el trabajo del proyecto. El presupuesto del proyecto es un documento financiero que incluye el costo del personal, materiales y otros gastos relacionados al proyecto. Este es autorizado y aprobado, normalmente, © 2014 SCRUMstudy.com

28

por el patrocinador para contar con los fondos suficientes disponibles. Una vez que el presupuesto se apruebe, el Product Owner y el Scrum Master podrían ser involucrados en la gestión del Presupuesto del Proyecto y también para asegurar que las personas y otros recursos requeridos para las actividades del proyecto estén disponibles.

1. Caso de Negocio del Proyecto* 2. Product Owner del Programa 3. Scrum Master del Programa 4. Interesados del Programa 5. Jefe Product Owner 6. Product Backlog del Programa 7. Prueba del Proyecto 8. Prueba de Concepto 9. Visión de la Empresa 10. Misión de la Empresa 11. Estudio del Mercado 12. Recomendaciones del Cuerpo de Asesoramiento de Scrum (SGB)

1. Reunión de la Visión del Proyecto * 2. Sesiones JAD 3. Análisis FODA (SWOT) 4. Análisis de Brechas

1. Product Owner Identificado * 2. Declaración de la Visión del Proyecto * 3. Acta de Constitución del Proyecto 4. Presupuesto del Proyecto

PROCESO 2: IDENTIFICAR AL SCRUM MASTER Y A LOS INTERESADOS IDENTIFY SCRUM MASTER AND STAKEHOLDER(S) El segundo paso en la fase de Inicio en un proyecto Scrum es identificar al Scrum Master y a los interesados. Ayuda a terminar la selección del Scrum Master para el Proyecto El Product Owner puede aceptar sugerencias de otras fuentes, como del Scrum Master de Programa, de la Matriz Organizacional de Recursos, Matriz de Destrezas Requeridas y el Cuerpo de Asesoramiento de Scrum para elegir una persona como Scrum Master. El Product Owner podría utilizar herramientas como criterios de selección, capacitación, y asesoramiento de expertos del departamento de Recursos Humanos para identificar al mejor de los candidatos a Scrum Master. Es importante que cuando el Product Owner seleccione al Scrum Masters tenga en cuenta sus habilidades de resolución de conflictos, que encarne el estilo de gestión : Liderazgo Servicial y que se comprometa a brindar al Equipo Scrum un ambiente propicio para la entrega exitosa del proyecto. Criterios de selección La selección adecuada del(los) Scrum Master(s) y la identificación de los interesados adecuados es crucial para el éxito de cualquier proyecto. En algunos proyectos pueden haber pre-condiciones que estipulen determinados miembros del equipo y sus roles. © 2014 SCRUMstudy.com

29

Los siguientes criterios de selección son importantes para ser un Scrum Master: 1. Habilidades para la resolución de problemas—Es uno de los principales criterios a considerar al seleccionar al Scrum Master. El Scrum Master debe tener las habilidades y experiencia necesarias para ayudar a eliminar cualquier Impedimento que encare el Equipo Scrum. 2. Disponibilidad—El Scrum Master debe estar disponible para agendar, supervisar y facilitar las reuniones, incluyendo Release Planning Meeting, Daily Standup Meeting, y otras reuniones relacionadas al Sprint. 3. Compromiso—El Scrum Master se debe comprometer a que el Equipo Scrum esté dotado de un ambiente de trabajo propicio para asegurar la entrega exitosa del proyecto Scrum. 4. Líder Servicial – El Scrum Master debe poseer cualidades básicas que permitan que sea un Líder Servicial. El Scrum Master debe escuchar, utilizar la empatía, el compromiso y la visión mientras que comparte el poder y la autoridad con los miembros del equipo. Los líderes serviciales son mayordomos que logran resultados enfocándose en la satisfacción de las necesidades del equipo. Identifica a los Interesados Cuando se identifica a los Interesados, es importante recordar que los Interesados incluyen a todos los clientes, los usuarios y patrocinadores, quienes a menudo interactúan con el Product Owner, Scrum Master y Equipo Scrum para proveer entradas y facilitar la creación de los productos del Proyecto. Los Interesados influyen en el proyecto a lo largo de todo su ciclo de vida.

1. 2.

Product Owner * Declaración de la Visión del Proyecto * 3. Product Owner del Programa 4. Scrum Master del Programa 5. Jefe del Product Owner 6. Jefe del Scrum Master 7. Interesados del Programa 8. Requisitos de Personal 9. Disponibilidad y compromiso de las Personas 10. Matriz de Recursos de la Organización 11. Matriz de Destrezas Requeridas 12. Recomendaciones del Cuerpo de Asesoramiento de Scrum

1. Criterios de Selección * 2. Consejo Experto del Recursos Humanos 3. Entrenamiento y Costos de capacitación 4. Costos de Recursos


1. Scrum Master Identificado* 2. Interesados Identificados*

30

PROCESO 3: FORMAR EL EQUIPO SCRUM (FORM SCRUM TEAM) Ayuda a seleccionar a los Miembros del Equipo Scrum El Equipo Scrum es una parte principal de cualquier proyecto Scrum, y conseguir a los miembros adecuados es importante para la entrega exitosa de estos proyectos. Los miembros del Equipo Scrum son especialistas generalistas, donde cada uno debe poseer un conocimiento general de diversos campos y son expertos en al menos uno. Más allá de ser expertos técnicos, son las habilidades interpersonales de cada miembro del equipo que determinará el éxito de los equipos auto-organizados. Los miembros ideales de un Equipo Scrum son independientes, auto-motivados, enfocados en el clientes, responsables y colaboradores. El equipo debe ser capaz de fomentar un ambiente de pensamiento independiente y toma de decisiones grupal con el fin de extraer los mayores beneficios de la estructura.

Ayuda a elaborar el Plan de Colaboración La colaboración es un elemento muy importante en Scrum. La planificación de cómo los diferentes decisores, los interesados y los miembros del equipo participarán y colaborarán entre sí es vital. El Plan de Colaboración es una salida opcional que puede ser formal o informal. A veces, puede ser simplemente un acuerdo verbal entre los interesados, ya que en Scrum se evita documentación innecesaria. Sin embargo, para proyectos grandes, complejos, especialmente donde los equipos son distribuidos, puede ser necesario poner en marcha un acuerdo más formal. Ayuda a elaborar el Plan de Desarrollo de Equipos con el (los) Scrum Master(s) Desde que el Equipo Scrum es multi-funcional, cada miembro necesita participar activamente en todos los aspectos del proyecto. El Scrum Master debe identificar problemas con los miembros del equipo y direccionar con ellos de forma diligente para mantener un equipo efectivo. Para construir la cohesión del equipo, el Scrum Master debe garantizar que las relaciones entre los miembros del equipo sean positivas y que todos como equipo estén enfocados en lograr los objetivos del proyecto y de la organización, esto permite tener una mayor eficiencia y productividad.

1. Product Owner * 2. Scrum Master* 3. Declaración de la Visión del Proyecto* 4. Jefe del Product Owner 5. Requisitos del Personal 6. Disponibilidad y Compromiso de las Personas 7. Matriz de Recursos de la Organización 8. Matriz de Destrezas Requeridas 9. Requerimientos de Recursos 10. Recomendaciones del Cuerpo de Asesoramiento de Scrum

1. Selección del Equipo Scrum* 2. Consejo Experto del Recursos Humanos 3. Costo asociado con el Personal 4. Costo de Entrenamiento y Capacitación 5. Costos de Recursos


1. Equipo Scrum Identificado * 2. Respaldos de los miembros del equipo 3. Plan de Colaboración 4. Plan de Desarrollo del Equipo

31

PROCESO 4: DESARROLLO DE EPIC(S) (DEVELOP EPIC(S)) Crea Epic(s) y Personas En terminología Scrum, un Epic es definido cómo una Historia de Usuario no refinada, la cual es generalmente muy grande para ser completada en un solo Sprint. Los Epics son escritos en las etapas iniciales del proyecto, en las que la mayoría de Historias de Usuario son funcionalidades de alto nivel o descripciones del producto, y los requisitos están ampliamente definidos y basados en la Visión del Proyecto. Por lo que es necesario desglosarla en Historias de Usuario (User Stories) más pequeñas en algún punto del proyecto antes de implementarlas. Estas Historias de Usuario no refinadas se colocan en el Product Backlog Priorizado. Una vez que estas Epics sean propuestas para ser implementadas en el próximo Sprint, se descomponen en Historias de Usuario pequeñas y más granulares. Estas pequeñas Historias de Usuario son generalmente simples, cortas y fáciles de implementar o bloques de tareas que son completadas en un Sprint. El Product Owner es el responsable de crear las Epics y las Historias de Usuarios. Generalmente, el Product Owner crea las Historias de Usuario, pero en algunos casos son desarrolladas por el Equipo Scrum en coordinación con el Product Owner. Sin embargo, la responsabilidad de asegurar que los requerimientos de negocio del cliente sean convertidos en requerimientos funcionales que el desarrollador pueda entender fácilmente e implementar, es del Product Owner. El Equipo Core Scrum puede hacer uso de muchas herramientas para crear eficientemente Epics y podría considerar varios factores tales como Solicitudes de Cambio aprobados y no aprobados, Leyes y Regulaciones, Contratos, etc. Algunas de estas herramientas utilizadas en el proceso Desarrollo de Epic(s) son: Reunión de Grupo de Usuario, Talleres de Historia de Usuario, Reuniones de Grupos de Opinión y Cuestionarios. Si bien en la creación de Epics, es importante identificar riesgos, el Equipo Core de Scrum también podría utilizar una sería de técnicas de identificación de riesgos. Otra salida principal a este proceso son las Personas. , las cuales son complementos a los Epics, dado que ayudan al equipo a entender mejor a los usuarios y sus necesidades y objetivos. Personas son personajes de ficción con descripción muy detallada que representan a la mayoría de los usuarios y otros interesados que podrían no utilizar directamente el producto final, son creados para identificar las necesidades de la base de usuarios destino. La creación de personas específicas puede ayudar al equipo a identificar usuarios y entender sus necesidades y metas. Basado en una persona, un Product Owner puede priorizar funcionalidades y crear un Product Backlog. Una cita que ilustra las necesidades de la persona puede ser incluida también. A continuación se muestra un ejemplo de una Persona para un sitio web de viajes.


32

Recopilación de Epics / Historias de Usuario La recopilación de requisitos en la forma de Epics/Historia de Usuario es un esfuerzo continuo. Al inicio del proyecto, el Product Owner colabora con el cliente para recopilar los requisitos, los cuales son de alto nivel y no están claramente definidos en este punto. Las Epics serán articuladas y definidas más adelante en el proyecto. Las brechas en la funcionalidad serán identificadas luego de algunas iteraciones exitosas, y las Historias de Usuario serán escritas para completar estas brechas. Un Product Owner puede tener muchas técnicas de recopilación de Epics/Historias de Usuario. Algunas de ellas son las siguientes: 

Entrevista a los Usuarios- Una de las formas más comunes de descubrir requerimientos es entrevistar diferentes tipos de usuarios de una aplicación o producto.



Reunión de Grupo de Usuarios- Las reuniones de grupo de usuarios involucran a interesados relevantes y proporcionan al equipo Core Scrum información de primera mano acerca de expectativas de los usuarios. Esto ayuda en la formulación de los Criterios de Aceptación del producto y da información valiosa para el desarrollo de Epics.



Cuestionarios- Observar a un usuario de una aplicación puede ayudar a obtener retroalimentación rápida acerca de áreas de mejora y descubrir requerimientos que podrían ser olvidados o ignorados.



Talleres de Historia de Usuario- Un Taller de Historia de Usuario puede ser un buen camino para recopilar requerimientos. El taller involucra a todos los interesados relevantes. El equipo escribe la mayor cantidad de historias posibles durante la sesión de tormenta de ideas.

1. Scrum Core Team* 2. Declaración de la Visión del Proyecto * 3. Interesados 4. Product Backlog del Programa 5. Solicitudes de Cambio Aprobadas 6. Solicitud de Cambio no Aprobadas 7. Riesgos del Portafolio y del Programa 8. Leyes y Regulaciones 9. Contratos 10. Información Previa del Proyecto 11. Recomendaciones del Cuerpo de Asesoramiento de Scrum

1. Reunión de Grupo de Usuarios * 2. Talleres de Historia de Usuario 3. Reunión de Grupos de Opinión (Focus Group) 4. Entrevista a Usuarios o Clientes 5. Cuestionarios 6. Técnicas de Identificación de Riesgos 7. Juicio Experto del Cuerpo de Asesoramiento de Scrum


1. 2. 3. 4.

Epic(s) * Personas * Cambios Aprobados Riesgos Identificados

33

PROCESO 5: CREAR LA LISTA DE REQUERIMIENTOS PENDIENTES DEL PRODUCTO PRIORIZADA(CREATE PRIORITIZED PRODUCT BACKLOG) Product Backlog Este es un los procesos más importantes para el Product Owner. Luego que los Epics y Personas son creados, el Product Owner crea la Lista Priorizada de Pendientes del Producto (Prioritized Product Backlog). Esta lista es priorizada donde los elementos de mayor valor, es decir los que dan el máximo valor comercial tienen la prioridad más alta. El Product Backlog es una lista de requerimientos que, al convertirse en funcionalidad de producto potencialmente comercializable, entregará la Visión del Producto.

Es responsabilidad del Product Owner elaborar el Product Backlog Priorizado inicial basado en los Epics, Enunciado de la Visión del Proyecto, Requerimientos de Negocios e Interesados. El Product Owner debe ser muy consciente de las necesidades y expectativas del negocio y de los requerimientos del producto. Un Product Backlog debería tener las siguientes características: 

Ser priorizado por valor, de modo que las características más importantes se construyan primero.



Se deben tener en cuenta todos los requisitos necesarios para completar el proyecto.



Es dinámico y evoluciona constantemente.



Sólo existe un Product Backlog, esto significa que se requiere que el Product Owner priorice las tareas de todo el trabajo a realizar.

En el Product Backlog también se suelen incluir requisitos tales como correcciones de errores, requerimientos no funcionales, y tareas que podrían no tener valor directo de negocio, sin embargo deben ser realizadas. Al comienzo de cualquier proyecto, el Product Backlog es poco probable que sea una lista clara y articulada. En cambio, el Product Backlog probablemente tendrá muchos Epics (historias de alto nivel). Es responsabilidad del Product Owner ordenar la lista, así todos los elementos serán claramente definidos y entendidos por el equipo.

Prioriza los Elementos del Product Backlog (Product Backlog Items PBIs) Priorizar el Product Backlog implica determinar la criticidad de una Historia de Usuario. A veces, el cliente dirá “todos los elementos tienen alta prioridad”. Si bien puede ser cierto, no se podrá tener un producto terminado. Incluso una lista de elementos de alta prioridad debe ser priorizada. Mientras se prioriza se tiene en cuenta estos tres factores: valor, riesgo e incertidumbre y dependencias. 1. Valor Es responsabilidad del Product que se entreguen aquellos elementos más valiosos primero. Incluso un elemento de gran valor podría no ser parte de la primera versión cuando hay un grupo de elementos con valor más alto que son suficientes para la primera versión.


34

2. Riesgo e Incertidumbre El riesgo es un aspecto inherente a cualquier negocio. El riesgo e incertidumbre están vinculados. Cuando hay más incertidumbre el proyecto es más riesgoso. Por lo tanto, es importante que a los elementos más riesgos se les asigne mayor prioridad. Los elementos riesgos también necesitarán acciones de mitigación. Cuando las acciones de mitigación de riesgos son priorizadas en el product backlog, este se convierte en Product Backlog priorizado ajustado a riesgos (Risk Adjusted Prioritized Product Backlog). 3. Dependencias No siempre es posible crear un Product Backlog en el que las Historias de Usuario no sean dependientes entre sí. Los requerimientos funcionales a menudo dependen de otros requerimientos funcionales e incluso no funcionales. Las dependencias pueden restringir la libertad que tenemos mientras priorizamos el Product Backlog. Por lo tanto, es importante resolver dependencias tanto como sea posible. Dos de las maneras más comunes de resolver dependencias es o bien dividir una sólo historia en varias partes o combinar historias interdependientes. Herramientas Comunes de Priorización  Esquema de Priorización MoSCoW—El esquema de priorización MoSCoW deriva su nombre de las primeras letras de las frases "Must have" (Debe tener), “Should have” (Debería tener), "Could have” (Podría tener), y "Would like to have, but not at this time” (Quisiera tenerlo, pero no ahora). Las etiquetas están en orden decreciente de prioridad. "Debo tener" estas Historias de Usuarios son aquellas que si no son incluidas en el producto, este no tendrá valor; y "Quisiera pero no ahora" estas Historias de Usuarios son aquellas que, a pesar de que sería bueno tenerlas, no es necesario incluirlas. “Would like to have” es a veces representado por “Won´t have”.  Comparación por Pares (Paired Comparison)— En esta técnica se prepara una lista de todas las Historias de Usuarios del Product Backlog Priorizado. Luego, cada Historia de Usuario se toma de forma individual y se compara con las otras Historias de Usuarios en la lista, uno a la vez. Cada vez que dos Historias de Usuarios se comparan, se toma una decisión sobre cuál de los dos es más importante. A través de este proceso, se puede obtener una lista priorizada de las Historias de Usuarios.  Método de los 100 Puntos (100-point method) — Fue desarrollado por Dean Leffingwell y Don Widrig (2003). Se trata de dar al Cliente 100 puntos que puede usar para votar por las Historias de Usuarios más importantes. El objetivo es dar más peso a las Historias de Usuarios que son de mayor prioridad en comparación con las otras Historias de Usuarios disponibles. Cada miembro del grupo asigna puntos a las diversas Historias de Usuarios, dando más puntos a aquellas que consideran más importantes. Al finalizar el proceso de votación, la Priorización se determina calculando el total de puntos asignados a cada Historia de Usuario. Define el Criterio de Terminado (Done Criteria) El criterio de Terminado se diferencia del Criterio de Aceptación en un aspecto principal. Mientras que el Criterio de Aceptación son únicos por cada Historia de Usuario, el Criterio de Terminado es un grupo de reglas que se aplican a todas las Historias de Usuario. Un Criterio de Terminado genérico podría incluir: 

Ser revisado por otros miembros del equipo.



Pasar por las pruebas unitarias de la Historia de Usuario.


35



Satisfacer o exceder con éxito las pruebas de control de calidad.



Completar toda la documentación relacionada a la Historia de Usuario.



Finalizar con la corrección de todos los errores.



Presentación exitosa del incremento del producto a los interesados y representantes del negocio.

1. 2. 3. 4. 5.

Scrum Core Team* Epic(s) * Personas * Interesados Declaración de la Visión del Proyecto 6. Product Backlog del Programa 7. Requisitos del Negocio 8. Solicitudes de Cambio Aprobadas 9. Riesgos Identificados 10. Contratos 11. Recomendaciones del Cuerpo de Asesoramiento de Scrum

1. Métodos de Priorización de Historias de Usuarios * 2. Talleres de Historia de Usuario 3. Planificación de Valor 4. Técnicas de Evaluación de Riesgo 5. Estimación de Valor del Proyecto 6. Métodos de Estimación de Historias de Usuario 7. Juicio Experto del Cuerpo de Asesoramiento de Scrum

1. Product Backlog Priorizado (Prioritized Product Backlog)* 2. Criterio de Terminado (Done Criteria)*

PROCESO 6: REALIZAR LA PLANIFICACIÓN DE LAS VERSIONES (CONDUCT RELEASE PLANNING) Crea el Cronograma de Planificación de Versiones En este proceso, el Equipo Core de Scrum trabaja elaborando el Cronograma de Planificación de las Versiones (Release Planning Schedule) para entregar incrementos de producto a los interesados. El Cronograma de Planificación de las Versiones indica qué entregables serán liberados a los clientes, junto con los intervalos planeados y las fechas de cada versión. Es responsabilidad del Product Owner definir la estrategia de versiones y asegurar que esta sea comunicada y entendida por el equipo. Estrategia de Versiones basada en la Funcionalidad - Si la estrategia de versiones está basada en la funcionalidad, entonces el producto debe ser lanzado lo antes posible. Sin embargo, debe haber suficiente valor en el producto para ser liberado efectivamente. El Product Owner define el producto mínimos comercializable (Minimun Marketable Feature MMF), también llamado Primera Entrega Factible (First Feasible Delivery FFD), como la mínima funcionalidad necesaria para el lanzamiento inicial. Si el Product Backlog inicial es priorizado correctamente, entonces el MMF incluirá las “x” características más importantes en el Product Backlog. La velocidad del equipo es un criterio importante para decidir los plazos para la versión. Una vez que se escoja la longitud del Sprint y las Historias de Usuario de alta prioridad sean estimadas, la velocidad histórica del equipo es utilizada para identificar cuánto trabajo el equipo podría completar en un Sprint particular. Si es el primer proyecto donde se utiliza Scrum, entonces se tendrá que dar la mejor estimación de cuánto trabajo se puede ejecutar en un Sprint. La velocidad del equipo se ajusta durante la ejecución del proyecto basada en la experiencia.


36

Estrategia de Versiones basada en Fechas- Si la estrategia de versiones está impulsada por la fecha, entonces no es posible definir un MMF. Si hay una fecha límite fija, como presentar el producto en una audiencia de prueba en una fecha determinada, entonces el objetivo es proporcionar el producto funcionando con mayor valor posible en el plazo determinado. En este caso, es crucial que el Product Owner realice un buen trabajo identificando las características con más alto valor. Directivas para las Versiones 

Cada versión debe proporcionar valor significativo para el cliente.



Cada Sprint debe tener una funcionalidad potencialmente comercializable como salida. A las características con alto valor en el negocio se les debe dar la más alta prioridad en el Product Backlog y deben ser desarrolladas primero. Esto garantiza que el valor más alto posible se proporciona al final de cada iteración.



Las interdependencias entre las características, así como otras precondiciones de los elementos del Product Backlog, como la infraestructura, que podrían no ser requisitos explícitos en una Historia de Usuario, necesitan ser consideradas en la planificación. Estos son incluidos en el Product Backlog como elementos no funcionales. Esto garantiza que cada salida puede ser utilizada inmediatamente.

Ayuda a determinar la Duración del Sprint La duración del Sprint es determinada por el tiempo mínimo que se necesita para crear incrementos de producto que generen valor al negocio. Esta una decisión estratégica basada en la experiencia del Equipo Scrum y las consideraciones del desarrollo del producto. Una vez que la duración del Sprint es fijada, normalmente no cambia en el proyecto. Podría ser modificada en medio del proyecto debido a mejoras en el ambiente del proyecto y en la velocidad del equipo. Para elaborar el Cronograma de Planificación de Versiones y para fijar la duración del Sprint se utilizan varias entradas como las de los interesados, Declaración de Visión del Proyecto, Product Backlog Priorizado, Requerimientos de Negocio y calendario de feriados. Un Sprint puede durar entre 1 y 6 semanas. Sin embargo para obtener el máximo beneficio de un proyecto Scrum se recomienda mantener la duración del Sprint en 4 o menos semanas, a menos que el proyecto tenga requerimientos estables, donde los Sprints puede ser ampliados a 6 semanas.


37

1. Scrum Core Team* 2. Interesados* 3. Declaración de la Visión del Proyecto * 4. Product Backlog Priorizado * 5. Criterio de Terminado * 6. Product Owner del Programa 7. Scrum Master del Programa 8. Jefe del Product Owner 9. Product Backlog del Programa 10. Requisitos del Negocio 11. Calendario de Feriados 12. Recomendaciones del Cuerpo de Asesoramiento de Scrum

1. Sesiones de Planificación de las Entregas* 2. Métodos de Priorización de las Entregas *


1. Cronograma de Planificación de las Entregas* 2. Duración del Sprint * 3. Clientes Objetivo para el Lanzamiento 4. Product Backlog Priorizado y Refinado

38

PREGUNTAS - CAPÍTULO FASE: INICIAR 1. ¿Cuál de las siguientes afirmaciones no es verdadera para el Product Backlog? a. El Product Backlog es priorizado de manera que el equipo construye las características más valiosas primero. b. El Product Backlog es dinámico y evoluciona en el proyecto. c. Los elementos del Product Backlog son priorizados basados en la complejidad. d. El Product Backlog es constantemente repriorizado para incorporar requerimientos emergentes del cliente. 2. ¿Cuál es la regla para el ordenamiento de los elementos en el Product Backlog? a. Los elementos más pequeños en la parte superior. b. Los elementos con menos interdependencias en la parte superior. c. Los elementos más complejos en la parte superior. d. Los elementos con mayor valor de negocio en la parte superior. 3. Los Epics pueden ser definidos como: a. Historias de Usuario grandes. b. Historias de Usuario con alto valor de negocio. c. Historias de Usuario más importantes. d. Ninguna de las anteriores. 4. ¿Cuál de las siguientes afirmaciones NO es correcta? a. Las Historias de Usuario son cortas, tienen una descripción simple de la funcionalidad deseada. b. Las Historias de Usuario generalmente tienen la perspectiva del desarrollador. c. Las Historias de Usuario pueden ser escritas en distintos niveles de detalle. d. Las Historias de Usuario, cuando son desarrolladas, genera funcionalidades del producto. 5. Todas las siguientes preguntas son respondidas por la Visión del Producto, EXCEPTO: a. ¿Quién es el cliente objetivo? b. ¿Cuál es la categoría del producto? c. ¿Cuál es nuestro principal punto de venta? d. ¿Cómo la Visión del Producto concuerda con el desarrollo del producto? 6. ¿Cuál de las siguientes afirmaciones NO es un factor en la priorización del Product Backlog? a. Factibilidad b. Riesgo c. Complejidad d. Dependencias © 2014 SCRUMstudy.com

39

7. ¿Cuál de las siguientes afirmaciones NO son verdaderas respecto a la planificación de las versiones? a. Una funcionalidad puede ser liberada sólo si cumple los criterios de aceptación definidos por el Product Owner. b. El Equipo Scrum y el Product Owner tienen la autoridad para aceptar y rechazar la funcionalidad desarrollada. c. Una funcionalidad desarrollada en una iteración no será entregada al cliente hasta el final de la iteración. d. La versiones están ordenadas de forma lógica para garantizar que se aborden las interdependencia entre las características. 8. ¿Cuándo el Product Owner libera una funcionalidad? a. Cuando el Equipo Scrum decida. b. Después de cada Sprint. c. Después de cada Sprint alternativo. d. De acuerdo a las necesidades del cliente.


40

FASE: PLANEAR Y ESTIMAR Como parte de esta fase, el Equipo Core de Scrum crea, aprueba, estima y se compromete con un grupo de Historias de Usuarios, adicionalmente crea y estima tareas, finalmente crea el Sprint Backlog.

PROCESO 1: CREAR HISTORIAS DE USUARIOS (CREATE USER STORIES) Ayuda a Crear Historias de Usuario Las Historias de Usuario eliminan la necesidad de la documentación detallada de los requerimientos del cliente. Son escritas en lenguaje que el negocio entiende. La responsabilidad de crear las Historias de Usuario recae en el Product Owner. Generalmente el Product Owner crea las Historias de Usuario, pero en algunos casos estos son creados por el Equipo Scrum en coordinación con el Product Owner. Las Historias de Usuario son descripciones breves de la funcionalidad del negocio desde un punto de vista del usuario. Esta herramienta fuerza a los interesados a identificar al usuario (o persona) y la razón de negocio de cada funcionalidad.

El formato típico de una Historia de Usuario es el siguiente: Como deseo para . Las Historias de Usuario son escrito en lenguaje claro y sencillo y son descripciones cortas acerca de la funcionalidad deseada desde la perspectiva del usuario final. Este es un ejemplo de una Historia de Usuario de tamaño Epic: “Como un usuario avanzado, deseo tener permisos administrativos, para que pueda realizar funciones administrativas.” Una Historia de Usuario tiene naturaleza iterativa y podría ser escrita frecuentemente durante el proyecto. Cuando una Historia de Usuario es demasiado grande para que el Equipo Scrum la pueda completar en un solo Sprint, es considerada un Epic, y se dividirá en muchas varias Historias de Usuario antes que sea implementada. El Epic del ejemplo anterior, podría ser dividido en docenas ( o posiblemente cientos), incluyendo los siguientes: 

“Como un usuario avanzado, deseo tener permisos administrativos, para que pueda asignar a un usuario permisos de lectura, escritura o modificación.”



“Como un usuario avanzado, deseo tener permisos administrativos, para que pueda añadir o eliminar nuevos usuarios.”

Las Historias de Usuario puede estar asociadas como Temas (“Themes”). Un Tema (Theme) es una colección de Historias de Usuarios. Los Temas pueden contener uno o más Epics. Muchos Temas pueden estar asociados con un producto, pero un Tema no puede estar relacionado con más un producto a la vez. Criterio para una Historia de Usuario bien elaborada Podemos utilizar el acrónimo INVEST para entender las características de una Historia de Usuario bien escrita. El acrónimo significa: Independent, Negotiable, Valuable, Estimable, Small y Testable.

 Independent (Independiente) — El objetivo de escribir Historias de Usuario es hacer que cada una de estas sea independiente y autónoma. Esto es importante, porque ayuda al Product Owner a evaluar e incluir Historias de Usuario en el Product Backlog Priorizado basado en el valor de cada uno. A menudo las Historias de Usuarios dependen intrínsecamente una de otra. En tales situaciones, no estará claro qué historia debe tener la estimación más alta. Una forma de solucionar esta situación es combinar estas historias en una historia independiente y grande. Si alguna de las funcionalidades requeridas ya fue creada o está siendo implementada, © 2014 SCRUMstudy.com

41

entonces la estimación debe ser revisada para reflejar este cambio. También, es importante definir una Historia de Usuario no funcional que define las precondiciones de cada una de las dependencias. 

Negotiable (Negociable) — Una Historia de Usuario no debe ser inamovible y debe tener margen suficiente para permitir la negociación entre el Equipo Scrum y el equipo de negocio. A veces el equipo de negocio sacrificará funcionalidades debido a las limitaciones de presupuesto, o el Equipo Scrum podría tener que convencer al equipo de negocio a incrementar el presupuesto cuando una característica crítica del usuario es requerida a pesar de las restricciones presupuestarias.

 Valioso (Valuable) — Es importante que cada característica en el Product Backlog tenga valor. Decir que una característica tiene valor no significa necesariamente que esta tiene valor en términos definidos por el usuario final. Algunas características podrían trabajar en un segundo plano (no visible) o podría indirectamente soportar otras funcionalidades que el usuario requiere, por lo que estas características todavía tienen valor. Este valor deber ser considerado por el Product Owner para que pueda priorizarlo e incluirlo en el Product Backlog.  Estimable (Estimable) — Una de las características de una buena Historia de Usuario es que fácilmente se puede estimar. Las estimaciones no tienen que ser precisas, pero deben lo suficientemente buenas para utilizarlas en la priorización. Historias de Usuario grandes son difíciles de estimar, e historias pequeñas son generalmente fáciles de estimar. Las Historias que son difíciles de estimar pueden indicar problemas de fondo – podría ser que la Historia es muy grande o podría no reflejar con claridad lo que la Historia de Usuario necesita satisfacer.  Pequeño (Small) — Una Historia de Usuario pequeña es relativamente fácil de estimar. Son más sencillas de hacer seguimiento y por lo general pueden ser completadas dentro de una iteración. Historias grandes tardan más tiempo, y los retrasos toman más tiempo reportar. Cuando el Product Owner está tratando de crear historias que tienen el tamaño adecuado, él o ella debe considerar la experiencia y capacidades del Equipo Scrum.  Verificable (Testable) — Si una Historia de Usuario no puede ser probada y su funcionalidad verificada, entonces será difícil de evaluar si esta puede ser considerada como Terminada. El Criterio de Aceptación de la Historia de Usuario debe estar claramente definido antes de determinar si es o no verificable. Diferencia entre una Historia de Usuario y un Caso de Uso La diferencia básica entre una Historia de Usuario y un Caso de Uso radica en la perspectiva y la intención, la cual afecta el nivel de detalle capturado. El Caso de Uso se enfoca en las interacciones entre un sistema y uno o más actores, donde un actor puede ser un usuario u otro sistema. El Caso de Uso describe un proceso y sus pasos con el detalle suficiente, de modo que puede ser entendido por si mismo. La descripción de las interacciones, normalmente, tiene un formato de llamada y respuesta. Por otro lado, la Historia de Usuario se concentra en los valores del usuario y es mucho más ligera que el Caso de Uso. Proporciona suficiente detalle para que el lector pueda comprender la funcionalidad en general que fue identificada. Se promueve el uso del lenguaje cotidiano para asegurar que la Historia de Usuario sea comprendida por desarrolladores y cliente. A diferencia con el Caso de Uso, una Historia de Usuario es un recordatorio para tener una conversación con tu cliente.


42

Criterio de Aceptación Junto con las Historias de Usuario, el Product Owner define los criterios de aceptación, que son los criterios de éxito de cada Historia de Usuario. Los criterios de aceptación claramente definidos son cruciales para la entrega oportuna y eficaz de las Historias de Usuario las cuales en última instancia determinar el éxito del proyecto. Estos son escritos y definidos por el Product Owner. Deben describir explícitamente las condiciones que las Historias de Usuario deben satisfacer. Los criterios de aceptación son únicos para cada Historia de Usuario. Por ejemplo, una Historia de Usuario para crear un sitio web en línea para un supermercado podría ser la siguiente: “Como un comprador en la tienda en línea, debería ser capaz de añadir y/o eliminar elementos del carrito de compras antes de comprometer la venta, para que pueda estar seguro de tener presupuesto.” Los criterios de aceptación para esta Historia de Usuario podrían ser escritos de esta forma:   

El carrito de la compra tiene que actualizarse automáticamente cuando un usuario agrega un elemento. Un usuario puede eliminar/modificar exitosamente los contenidos del carrito de compras desde una sola ventana. Los elementos del carrito de compras son guardados hasta que el usuario borre su contenido o cierra la sesión del sitio web sin guardar.

Es importante para el Product Owner tener en cuenta que las Historias de Usuario que cumplan con la mayoría, pero no todos, de los criterios de aceptación no pueden ser aceptadas como terminados. Estimación de Historias de Usuarios es un trabajo en equipo- El Product Owner prioriza las Historias de Usuario de acuerdo al valor del negocio. Esto se hace a nivel del proyecto, así como a nivel de cada iteración. Cuando la Historia de Usuario forma parte del Product Backlog, el equipo la estima. Las Historias de Usuario son estimadas en Puntos de Historia (story points). Un punto de historia está relacionado al esfuerzo requerido para desarrollar una sola unidad de producto con la complejidad menos relativa. Por lo tanto, un punto de historia se traduce en una unidad de producto. Los factores que influyen en el proceso de estimación incluyen al número de requerimientos en el Product Backlog, la complejidad de las Historias de Usuario e incertidumbre y riesgos. Estas estimaciones son cruciales, porque el Product Owner se basa en ellas para la planificación de las versiones. La estimación es una actividad importante de equipo, ya que las estimaciones permiten predecir los resultados del proyecto.


43

1. Scrum Core Team* 2. Product Backlog Priorizado* 3. Criterio de Terminado * 4. Personas * 5. Interesados 6. Epic(s) 7. Requisitos del Negocio 8. Regulaciones y Leyes 9. Contratos 10. Recomendaciones del Cuerpo de Asesoramiento de Scrum

1. Experiencia en la Escritura de Historias de Usuario * 2. Talleres de Historia de Usuario 3. Reuniones de Grupo de Usuarios 4. Reuniones de Grupo Focales 5. Entrevistas al Cliente / Usuario 6. Cuestionarios 7. Métodos de Estimación de Historia de Usuarios 8. Juicio Experto del Cuerpo de Asesoramiento de Scrum

1. Historias de Usuarios * 2. Criterios de Aceptación de la Historia de Usuario * 3. Product Backlog Priorizada y Actualizada 4. Personas Actualizadas y Refinadas

PROCESO 2: APROBAR, ESTIMAR Y COMPROMETERSE CON LAS HISTORIAS DE USUARIOS (APPROVE, ESTIMATE, AND COMMIT USER STORIES) Aprueba Historias de Usuario Después que las Historias de Usuarios son creadas, tienen que ser aprobadas por el Product Owner. El Product Owner evalúa las Historias de Usuarios de acuerdo al nivel de satisfacción de los requerimientos de negocio y verificando si cumplen con sus respectivos Criterios de Aceptación. Estimando Historias de Usuario (Equipo Scrum) Después de que las Historias de Usuarios son aprobadas por el Product Owner, el Equipo Core Scrum comienza el trabajo de estimación de estas. Estimar los recursos requeridos y el tiempo con precisión es un aspecto crítico en cualquier organización para garantizar una buena experiencia de la entrega del proyecto para el cliente. Sin embargo, las estimaciones, por definición, no son precisas. La precisión de la estimación varia de acuerdo a la complejidad del proyecto, el tamaño, disponibilidad del equipo, la prioridad del equipo, la volatilidad de los requerimientos, etc. El Equipo Scrum puede utilizar diversas herramientas y técnicas de estimación, que incluyen Wideband Delphi, Planning Poker y Estimación Relativa. Facilita al Equipo Scrum y Compromete Historias de Usuario Después de la estimación, el Equipo Scrum se compromete desarrollar un grupo de Historias de Usuario aprobadas y estimadas para el siguiente Sprint. Cabe señalar que es responsabilidad del Product Owner asegurar que las Historias de Usuarios aprobadas ofrezcan valor y satisfagan las necesidades y requerimientos de los interesados en el © 2014 SCRUMstudy.com

44

proyecto. Una vez aprobadas, las Historias de los Usuarios son estimadas por el equipo. Las Historias de Usuarios aprobadas y estimadas que el Equipo Scrum cree que puede completar en el siguiente Sprint son comprometidas, en consulta con el Product Owner y forman parte del Sprint Backlog.

1. Scrum Core Team* 2. Historias de Usuarios * 3. Criterios de Aceptación de Historia de Usuario* 4. Recomendaciones del Cuerpo de Asesoramiento de Scrum

1. Reunión del Grupo de Usuarios * 2. Planificación Poker 3. Puño de Cinco 4. Estimación de Puntos de Costo 5. Otras Técnicas de Estimación 6. Juicio Experto del Cuerpo de Asesoramiento de Scrum

1. Historias de Usuarios Aprobadas, Estimadas y Comprometidas *

PROCESO 3: CREAR TAREAS (CREATE TASKS) Explica las Historias de Usuario al Equipo Scrum mientras crean la Lista de Tareas En este proceso, el Equipo Scrum se dedica a desglosar las Historias de Usuario en tareas o actividades. El rol del Product Owner es ayudar a clarificar las Historias de Usuario y requerimientos para permitir al equipo capturar adecuadamente las tareas necesarias para las Historias de Usuario comprometidas en el Sprint actual. Reunión de Planificación de Tareas (Task Planning Meeting) Para que los miembros del Equipo Scrum, Creen Tareas, una Reunión de Planificación de Tareas se lleva a cabo para revisar las Historias de Usuario Comprometidas a detalle para eliminar ambigüedades y resolver todas las preguntas. La creación de tareas se realiza durante la Reunión de Planificación de Tareas. Esta reunión está dividida en dos partes:


45

Primera Parte

Segunda Parte

•El Product Owner sugiere Historias de Usuario que deben formar parte del Sprint. •El Equipo Scrum determina cuántas Historias de Usuario pueden ser ejecutadas en un Sprint. •Se alcanza consenso en las Historias de Usuario que serán incluídas en el Sprint.

• El Equipo Scrum determina cómo convertir las Historias de Usuario seleccionadas en Incrementos de Producto desglosándolas en tareas. •El Equipo Scrum se compromete con los entregables del Sprint.

El Product Owner es el jugador principal en la primera parte de la reunión. Ya ha priorizado los elementos del Product Backlog y debe utilizar parte de esta reunión para explicar los elementos con mayor prioridad que desearía tenerlos en el siguiente Sprint al Equipo Scrum. El Scrum Master y el Scrum Team son los principales asistentes. Durante esta reunión, el Product Owner alinea las expectativas de los interesados con las del Equipo Scrum. Mientras que los interesados desean que el equipo desarrolle el producto teniendo en cuenta el tiempo estimado, los recursos financieros y humanos disponibles; el Equipo Scrum necesita medir la viabilidad de las tareas desde un punto de vista técnico. Por lo tanto, se requiere información de los interesados, no sólo para que el Equipo Scrum organice su trabajo, sino también para asegurar que la funcionalidad a desarrollar sea factible y rentable cuando se implemente. El objetivo del Equipo Scrum es alcanzar un consenso en las Historias de Usuario que serán incluidas en el Sprint. En la segunda parte de la Reunión de Planificación de Tareas (Task Planning Meeting), el Equipo Scrum determina cómo convertir las Historias de Usuario seleccionadas en Incrementos de Producto desglosándolas en tareas. La principal salida de esta reunión es la Lista de Tareas, la cual contiene las tareas comprometidas por el Equipo Scrum para el Sprint.


46

1. 2.

Scrum Core Team* Historias de Usuario Aprobadas, Estimadas y Comprometidas *

1. Reunión de Planificación de Tareas* 2. Tarjetas 3. Descomposición 4. Determinación de Dependencias

1. Lista de Tareas * 2. Historias de Usuarios Aprobadas, Estimadas, Comprometidas y Actualizadas 3. Dependencies

PROCESO 4: ESTIMAR LAS TAREAS (ESTIMATE TASKS) Proporciona Orientación y Clarificación al Equipo Scrum en la Estimación de las Tareas Una vez que la Lista de Tareas esté lista, el Equipo Scrum estima las tareas. Este proceso es crítico para los miembros del Equipo Scrum para estimar el esfuerzo necesario para realizar cada tarea y así planear la forma de proceder. La estimación es hecha tomando en cuenta la duración y el esfuerzo requerido para convertir las tareas en entregables. “Esfuerzo” hace referencia tanto al personal como a otros recursos requeridos para completar las tareas dentro de un Sprint. El Product Owner no debe interferir en este proceso, sin embargo brinda orientación y clarificación al Equipo Scrum para estimar las tareas.

Reuniones de Estimación de Tareas (Task Estimation Meeting) Para estimar las tareas, el Equipo Scrum puede utilizar varias técnicas de Estimación. Es importante que el Equipo Scrum trabaje con Criterios de Estimación consensuados. El objetivo principal es utilizar los Criterios de Estimación para mantener tamaños relativos de estimación y minimizar la necesidad de re-estimación. Los Criterios de Estimación pueden ser expresados de muchas formas, dos ejemplos comunes son los Puntos de Historia y tiempo ideal. La salida más importante de este proceso es la Lista del Esfuerzo Estimado de las Tareas, la cual es una lista tareas relacionadas con sus Historias de Usuario Comprometidas que forman parte del Sprint. Normalmente, la precisión de los estimados varía de acuerdo a destreza del equipo. Es esfuerzo estimado es expresado en términos de los criterios de estimados acordados por el equipo. La Lista de Esfuerzo Estimado de las Tareas es utilizada por el Equipo Scrum durante las Reuniones de Planificación del Sprint para crear el Sprint Backlog y el Sprint Burndown Chart. La Reunión de Planificación de Tareas (Task Planning Meeting) y la de Estimación de Tareas (Task Estimation Meeting), por lo general, son llevadas a cabo como parte de la Reunión de Planificación del Sprint (Sprint Planning Meeting).


47

1. Scrum Core Team* 2. Lista de Tareas * 3. Criterios de Aceptación de las Historias de Usuario 4. Dependencias 5. Riesgos Identificados 6. Recomendaciones del Cuerpo de Asesoramiento de Scrum

1. Reuniones de Estimación de Tareas * 2. Criterios de Estimación * 3. Planificación Poker 4. Puño de Cinco 5. Otras Técnicas de Estimación

1. Lista del Esfuerzo Estimado de Tareas* 2. Lista de Tareas Actualizadas

PROCESO 5: CREAR LA LISTA DE PENDIENTES DEL SPRINT (CREATE SPRINT BACKLOG) Ayuda al Equipo Scrum crear el Sprint Backlog Este es el ultimo proceso de la fase de Planificación y Estimación. El Sprint Backlog es creado durante la Reunión de Planificación de Sprint (Sprint Planning Meeting). Después de que la Lista del Esfuerzo Estimado de Tareas haya sido elaborada, el Equipo Core de Scrum toma los elementos de la Lista de Tareas para revisarlos a detalle. Cada miembro del Equipo selecciona las tareas que planea trabajar durante el Sprint. Desde que el Equipo Scrum es auto-organizado, la decisión de quién trabajará en qué es hecha por los Miembros del Equipo. Ni el Product Owner ni el Scrum Master dan instrucciones al equipo sobre qué elementos deben trabajar y cómo tienen que hacer su trabajo. El Product Owner es el puente entre el Equipo Scrum y los interesados mientras que el Scrum Master es el líder facilitador y mentor del Equipo Scrum. Durante un Sprint, es posible que nuevas tareas podrían ser descubiertas, las cuales son necesarias para el desarrollo de la funcionalidad prevista. También es posible que las tareas previamente identificadas pueden no ser necesarias. En consecuencia, el Equipo Scrum modifica el Sprint Backlog. Algunos equipos incluyen algunas tareas adicionales como tareas de respaldo durante un Sprint, que se pueden ejecutar si el equipo completa las tareas asignadas y tiene capacidad libre. El Product Owner podría revisar qué elementos del Product Backlog priorizado pueden ser añadidos a Sprint actual. Las principales salidas de este son el Sprint Backlog y el Gráfico Sprint Burndown. 1. Sprint Backlog (Lista de Pendientes del Sprint) Es la lista de las tareas a ser ejecutadas por el Equipo Scrum en el próximo Sprint. Es una práctica común que el Sprint Backlog se muestre en un Scrumboard o tablero de tareas, este proporciona una representación visible y constante de la situación de las Historias de Usuarios en el backlog. Como Product Owner, este podría ser un artefacto importante para regularmente revisar el estado del proyecto y debería estar ubicado en un lugar de fácil acceso para todo el Equipo Core de Scrum. También se incluyen en el Sprint Backlog algunos Riesgos asociados © 2014 SCRUMstudy.com

48

con las diversas tareas. Las actividades de mitigación a los riesgos identificados podrían ser incluidas como tareas en el Sprint Backlog. Un Scrumboard estándar contiene 4 columnas que indican el progreso de las tareas estimadas para el Sprint: la columna “Pendiente” (“To Do”) para las tareas que aún no empiezan, la columna “En Progreso” (“In Progress”) para tareas que empezaron pero no han sido completadas aún, la columna “En Pruebas” (“Testing”) para tareas que han sido completadas pero se encuentran en el proceso de ser probadas y la columna “Terminado” (“Done”) para tareas terminadas y probadas exitosamente. Una columna opcional es la quinta: “Stories”. Al inicio del Sprint, todas las tareas se colocan en la columna “To Do” y se van moviendo a las columnas siguientes de acuerdo al avance. La siguiente figura muestra un ejemplo de un Scrumboard:

2. Sprint Burndown Chart – Es un gráfico que muestra la cantidad de trabajo que queda por hacer en el Sprint actual. El Gráfico Sprint Burndown inicial es acompañado por un Burndown planeado. El Gráfico Sprint Burndown debe actualizarse al final de cada día laborable. La siguiente figura muestra un ejemplo del Sprint Burndown Chart:


49



Este gráfico muestra el trabajo estimado pendiente (en el eje Y) y el tiempo (en el eje X).



Al final del día, los miembros del Equipo Scrum actualizan el gráfico con el trabajo completado.



El gráfico Sprint Burndown es un buen indicador de la velocidad del equipo en el Sprint actual y permite hacer pronósticos para saber si el equipo podrá completar o no todas las Historias de Usuario comprometidas.



La línea discontinua en el gráfico indica la tendencia ideal, y la línea continua representa la tendencia real. La región por encima de la línea discontinua es la zona de peligro que indica un retraso en la finalización de la tarea. La región por debajo de la línea discontinua indica que el equipo podría haber sobreestimado el esfuerzo necesario y puede tener capacidad libre en el Sprint.

Una vez que el Sprint Backlog se haya finalizado y el Equipo Scrum se haya comprometido al mismo, no deben añadirse nuevas Historias de Usuarios; sin embargo, puede ser necesario añadir las tareas que pueden haberse pasado por alto o ignorado de las Historias de Usuario comprometidas. Si surgen nuevas necesidades durante un Sprint, se añadirán al Product Backlog Priorizado y se incluirán en un Sprint posterior.

1. Scrum Core Team* 2. Lista del Esfuerzo Estimado de Tareas* 3. Duración del Sprint * 4. Velocidad del Sprint Previo 5. Dependencias 6. Calendario del Equipo

1. Reunión de Planificación del Sprint (Sprint Planning Meeting) * 2. Herramientas de Seguimiento del Sprint 3. Métrica de Seguimiento del Sprint


1. Sprint Backlog * 2. Sprint Burndown Chart*

50

PREGUNTAS - CAPÍTULO FASE: PLANEAR Y ESTIMAR 1. ¿Cuál de los siguientes atributos NO aplica a las Historias de Usuario? a. Negociable (Negotiable) b. Verificable (Testable) c. Estimable (Estimative) d. Técnico 2. ¿Cuál de las siguientes NO es correcta? a. El Product Owner asegura que el equipo siga los principios Scrum. b. El Product Owner es responsable de evaluar la viabilidad del producto. c. El Product Owner inspecciona el entregable para validar los criterios de aceptación. d. El Product Owner representar a un única voz en la decisión de los criterios del producto. 3. ¿Quién de los siguientes es responsable de lograr el máximo valor de negocio del proyecto? a. Scrum Master b. Product Owner c. Equipo Scrum d. Interesados externos 4. ¿Cuáles son las dos tareas más importantes ejecutadas por el Product Owner? a. Desarrollo del producto b. Creación del Product Backlog c. Definición de los criterios de aceptación d. Estimación de las Historias de Usuario 5. ¿Cuál de las siguientes dos alternativas son ciertas respecto al rol del Product Owner en la Reunión de Planificación del Sprint (Sprint Planning Meeting)? a. El Product Owner juega un rol importante en ambos segmentos del la Reunión de Planificación del Sprint. b. El Product Owner alinea las expectativas del Equipo Scrum con las de los interesados. c. El Product Owner explica los elementos con alta prioridad al equipo. d. El Product Owner protege al equipo de interferencia externa.


51

6. ¿Cuál de las siguientes NO es responsabilidad del Product Owner? a. Visión del Producto b. Definición objetiva c. Cronograma de Versiones d. Estimación de Tareas 7. ¿Cuál de las siguientes NO es una actividad de la Reunión de Planificación del Sprint (Sprint Planning Meeting)? a. El Product Owner explica las Historias de Usuario al Equipo Scrum. b. El Equipo Scrum en consulta con el Product Owner, estima las tareas de un Sprint dado. c. Basadas en las estimaciones, el Equipo Scrum se compromete con pocas Historias de Usuario para ser completadas en el próximo Sprint. d. El Equipo Scrum obtiene retroalimentación de los interesados.


52

FASE: IMPLEMENTAR La fase de Implementar abarca las ejecución de las tareas y actividades para crear el producto, servicio o resultado del proyecto. Estas actividades incluyen la creación de varios entregables, llevar a cabo la Reunión diaria y el mantenimiento del Product Backlog (es decir revisar, ajustar y actualizar periódicamente).

PROCESO 1: CREAR ENTREGABLES (CREATE DELIVERABLES) Clarifica los Requerimientos de Negocio al Equipo Scrum En este proceso es donde principalmente se realizan los trabajos de desarrollo. El Equipo Scrum es responsable de la creación de los Entregables del Sprint (Sprint Deliverables), mientras que el Product Owner y el Scrum Master también tienen un rol importante en este proceso.  El Product Owner es un puente entre el Equipo Scrum y los Interesados, proporcionando a los miembros del Equipo Scrum la información necesaria que necesitan mientras desarrollan los entregables Sprint.  El Scrum Master es responsable de asegurar un ambiente propicio para el desarrollo del trabajo de los entregables del Sprint. El esfuerzo principal de desarrollo recae en el Equipo Scrum, y como este es auto-organizado y multi-funcional, la decisión de cómo desarrollar algunas tareas recae en los miembros del Equipo Scrum. Ni los interesados, ni el Scrum Master, tampoco el Product Owner pueden dirigir al equipo en la forma de desarrollar los entregables. Los miembros del Equipo Scrum son expertos en sus dominios, y su juicio y experiencia son aplicadas a todos los aspectos técnicos y de gestión del proyecto durante este proceso. La salida más importante de este proceso es el entregable del Sprint, también conocido como el incremento del producto, el cual satisface todas las características y funcionalidades definidas en las Historias de Usuario del Sprint. Si los miembros del Equipo Scrum enfrentan cualquier obstáculo mientras completan los entregables del Sprint, ellos los registran en el Registro de Impedimentos (Impediment Log). Un Registro de Impedimentos es mantenido por el Scrum Master, y es su responsabilidad resolver los problemas y eliminar los impedimentos. Cuando el Product Owner quiere hacer cambios en medio del Sprint, el alcance del Sprint en curso no puede ser modificado. Si el cambio que se requiere es tan importante que el resultado del Sprint en curso podría ser inútil sin hacer estas modificaciones, entonces el actual Sprint debería ser terminado, y un nuevo Sprint que incorpora el cambio debe ser iniciado. Caso contrario, el cambio será incluido en un Sprint posterior. Si la estimación del equipo para el Sprint fue significativamente incorrecta, entonces el equipo, o bien tendrá capacidad libre para implementar Historias de Usuario (si es una sobreestimación) o no será capaz de completar las Historias de Usuario comprometidas (si es una subestimación). En cualquier caso, el equipo debería consultar al Product Owner la forma de proceder. El Product Owner debe tomar una decisión de negocio respecto a qué elementos adicionales del Product Backlog deben ser añadidos al Sprint actual (si el equipo tiene capacidad libre) o qué Historias de Usuario pueden quedar pendientes (si el equipo no tiene suficiente capacidad).


53

1. 2. 3. 4. 5.

Scrum Core Team* Sprint Backlog * Scrumboard* Impediment Log* Cronograma de Planificación de la Entrega 6. Dependencias 7. Recomendaciones del Cuerpo de Asesoramiento de Scrum

1. Experiencia del Equipo* 2. Software 3. Otras Herramientas de Desarrollo 4. Juicio Experto del Cuerpo de Asesoramiento de Scrum

1. Entregables del Sprint (Sprint Deliverables)* 2. Scrumboard Actualizado* 3. Impediment Log Actualizado* 4. Solicitudes de Cambio no Aprobadas 5. Riesgos Identificados 6. Riesgos Mitigados 7. Dependencias Actualizadas

PROCESO 2: REALIZAR LA REUNIÓN DIARIA (CONDUCT DAILY STANDUP) La colaboración se promueve en el Equipo Scrum a través de la Reuniones Diarias (Daily Standup Meetings). Esta es una reunión diaria de corta duración, generalmente dura 15 minutos como máximo. En esta reunión corta, los miembros del Equipo Scrum informan su estado y sus planes para las siguientes 24 horas al resto del equipo. Se revisa el trabajo completado desde la última Reunión Diaria (Daily Standup Meeting) y se proyecta el trabajo que debe ser hecho antes de la siguiente Reunión. La duración de las reuniones es muy corta y se espera que todos los miembros del Equipo Scrum asistan. Sin embargo, la reunión no se cancela o se retrasa si uno o más miembros no pueden asistir. En estas reuniones cada miembro del Equipo Scrum responde a estas tres preguntas específicas:   

¿Qué terminé ayer? ¿Qué voy a terminar hoy? ¿Qué impedimentos u obstáculos (si los hay) estoy enfrentando en la actualidad?

Aparte de la colaboración, las Reuniones Diarias promueven la transparencia entre los miembros del Equipo Core Scrum. El Scrum Master ayuda a los miembros del equipo a resolver problemas e impedimentos. El Scrum Master sólo es un facilitador, no dirige la reunión. El Daily Standup Meeting solo es un foro de intercambio de información. Cualquier discusión sobre la resolución de un problema, si es necesaria, se realiza después de la reunión diaria. El Scrum Master recolecta información de los impedimentos que los miembros del Equipo Scrum están enfrentando al realizar los trabajos del Sprint y los resuelve después de la reunión.


54

1. 2. 3. 4. 5. 6.

Scrum Team* Scrum Master* Sprint Burndown Chart * Impediment Log* Product Owner Experiencia del Día Previo de Trabajo 7. Scrumboard 8. Dependencias

1. Reunión Diaria de Standup (Daily Standup Meeting)* 2. Tres Preguntas Diarias * 3. Sala de Guerra (War Room) 4. Video Conferencia

1. Sprint Burndown Chart Actualizado* 2. Impediment Log Actualizado* 3. Equipo Scrum Motivado 4. Scrumboard Actualizado 5. Solicitud de Cambio no Aprobada 6. Riesgos Identificados 7. Riesgos Mitigados 8. Dependencias Actualizadas

PROCESO 3: MANTENIMIENTO DE LOS PENDIENTES PRIORIZADOS DEL PRODUCTO (GROOM PRIORITIZED PRODUCT BACKLOG) Refina el Product Backlog Priorizado Una de las responsabilidades más importantes del Product Owner es refinar el Product Backlog. Para asegurar que los elementos priorizados del Product Backlog (de los siguientes dos o tres Sprints) estén refinados, es recomendable que entre el 7% al 10% de cada Sprint sea destinado para refinar el backlog. El Product Owner es responsable de añadir o modificar los elementos del Product Backlog Priorizado como resultado de los cambios de requerimientos de negocio y es responsable de proporcionar información adicional detallada de las Historias de Usuario que se implementarán en el siguiente Sprint. Este proceso asegura que el Product Backlog Priorizado esté refinado bien antes de la siguiente Reunión de Planificación del Sprint, así el Equipo Scrum tendrá un grupo de historias bien analizadas y claramente definidas que permitirá agilizar el desglose de tareas y el proceso de estimación. ¿Por qué Refinar? 

Basándose en el aprendizaje del Sprint en curso, pueden haber cambios en los requisitos, o podrían haber nuevas prioridades que se pueden incorporar fácilmente en el siguiente Sprint.



Esta hace posible la flexibilidad del modelo Scrum mediante la incorporación de la última perspectiva de negocio y técnica para el desarrollo de productos.

El Procesos 1. Analizar los Requerimientos del Cliente y la Retroalimentación del Sprint Actual a. Porque los requerimientos y expectativas del clientes para proyectos complejos son poco claros, el Product Backlog continuamente cambia. Los cambio a los requerimientos del cliente tiene que ser analizados antes que sean incorporados.


55

b. La retroalimentación de la funcionalidad de la solución actual también es utilizada como entrada mientras se refina el Product Backlog para futuros Sprints. 2. Priorizar el Product Backlog a. Basándose en la información del cliente, cambios externos del mercado y aprendizaje de Sprints previos y el actual, es Product Backlog es repriorizado. 3. Desglosar los Epics / Historias de Usuario Largas a. Basándose en la prioridad del Product Backlog, las Historias de Usuario son creadas para el siguiente Sprint. Los elementos largos son desglosados en muchas Historias de Usuario, así estas puede ser estimadas. ¿Cuándo refinar? Es muy importante que los equipos planeen el refinamiento del Product Backlog en el momento adecuado. Este proceso garantiza que los equipos estén en el camino correcto al crear el producto. El Product Owner puede llevar a cabo este proceso ya sea antes del inicio del un Sprint o a medio camino de este, de acuerdo a sus necesidades. Este puede ser un ejercicio continuo ejecutado cuando sea necesario y no necesita ser hecho una sola vez. Al llevar a cabo la sesión de refinamiento antes del inicio del Sprint, da al Product Owner la oportunidad de recibir retroalimentación de las partes interesadas y de usuarios finales para comprender mejor sus necesidades, mientras el equipo empieza a desarrollar. Si la sesión de refinamiento es ejecutada antes del inicio del siguiente Sprint, entonces es importante que el equipo no se distraiga del Sprint actual. Por lo tanto, se sugiere que esa sesión se lleve a cabo días antes del inicio del siguiente Sprint. En caso se realice el refinamiento continuo, las sesiones podrían ejecutarse una vez por semana. Sesiones Efectivas de Refinamiento del Product Backlog Debido a que el Product Owner encabeza la Reunión de Refinamiento del Product Backlog, es importante que se fije una meta antes de empezar la reunión, para evitar la improvisación. Así la reunión será más eficiente. Es importante limitar el número de interesados que participarán en la reunión porque al tener muchos participantes podría disminuir la eficiencia de esta. El Product Owner podría invitar sólo a aquellos interesados cuya retroalimentación es requerida. También debe incluir a todo el Equipo Scrum, porque ellos podrían ayudar a afinar las características basadas en las aportaciones o problemas que enfrentan. Si luego de la sesión de refinamiento se reprioriza o cambia el Product Backlog, entonces es importante que el equipo tenga el conocimiento de estos cambios. Una reunión efectiva debe dar como resultado la definición del Product Backlog que permite que el Equipo Scrum entienda claramente los requerimientos del cliente. Requerimientos No Funcionales Los requerimientos no funcionales están relacionados a la seguridad, usabilidad, accesibilidad, estabilidad y otros atributos del producto. Estos requerimientos no funcionales son tan importantes como los funcionales. El incumplimiento de estos requisitos puede indicar que el producto no cumplirá con los requisitos de usabilidad, confiabilidad, desempeño o compatibilidad. Estos pueden ser limitaciones en el Product Backlog, ya que pueden imponer restricciones en diferentes aspectos del producto, como el diseño y la funcionalidad. Un Product Owner debe tener en cuenta los requisitos no funcionales y capturarlos mientras que los Epics y características se planifican. También tiene que tener en cuenta el tiempo y recursos necesarios para probar las Historias de Usuario para los requisitos no funcionales y debe utilizar © 2014 SCRUMstudy.com

56

de preferencia un sistema automatizado para probarlos porque las pruebas manuales pueden llegar a ser engorrosas. Entendimiento de la Importancia de las Historias y la Priorización del Product Backlog El rol del Product Owner es extremadamente importante para decidir qué funciones se colocan en el entregable de acuerdo a la importancia del negocio. Es responsabilidad del Product Owner garantizar que las Historias de Usuario tienen el detalle suficiente para que el equipo pueda implementarlas. Cuando el Sprint empieza, el Product Owner debe tener un Product Backlog Priorizado con las Historias de Usuario más importantes bien definidas y listas para que el equipo pueda trabajar con ellas. El equipo decidirá cuántas historias pueden implementar en el Sprint. No todas las Historias de Usuario encajarán en un Sprint, por lo que la priorización es obligatoria. Resumen del Refinamiento del Product Backlog

Adapta los requerimientos cambiantes de los clientes.

Utiliza la retroalimentación de Sprints actuales para modificar el Product Backlog.

Desglosa los elementos de mayor prioridad en Historisa de Usuario y los prepara para el siguiente Sprint.

El Equipo Scrum invierte entre 7 a 10% del tiempo del Sprint en curso.


57

1. Scrum Core Team* 2. Product Backlog Priorizado* 3. Entregables Rechazados 4. Solicitudes de Cambio Aprobadas 5. Solicitudes de Cambio no Aprobadas 6. Riesgos Identificados 7. Product Backlog del Programa Actualizado 8. Retrospect Sprint Log 9. Dependencias 10. Cronograma de Planificación del Entregable 11. Recomendaciones del Cuerpo de Asesoramiento de Scrum

1. Reunión de Revisión del Product Backlog Priorizado * 2. Técnicas de Comunicación 3. Otras Técnicas de Refinamiento del Product Backlog Priorizado


1. Product Backlog Priorizado Actualizado* 2. Cronograma de Planificación del Entregable Actualizado

58

PREGUNTAS - CAPÍTULO FASE: IMPLEMENTAR 1. ¿Cuál es la duración habitual de la Reunión Diaria (Daily Standup Meeting)? a. Cinco minutos b. Una hora c. Quince minutos d. Las reuniones diarias no son time-boxed 2. El rol que facilita la Reunión Diaria es responsabilidad de: a. El Scrum Master b. El Product Owner c. El lider del Scrum Team d. El grupo completo 3. ¿Cuándo los Epics se desglosan en Historias de Usuario para que muestren toda la funcionalidad requerida? a. En el proceso de creación del Product Backlog b. En el proceso de estimación de la tarea. c. En el proceso de definición del objetivo d. En el proceso de refinamiento del Product Backlog. 4. ¿Cuál de las siguientes alternativas NO son una ventaja del refinamiento del Product Backlog? a. Observaciones de Sprints previos son incorporados en Sprints futuros. b. Los últimos avances relacionados a los requerimientos del negocio y técnicos son considerados para Sprints futuros. c. El Product Backlog es refinado antes de la Reunión de Planificación del Sprint, así el equipo tiene idea de los requerimientos que se modificaron antes de la reunión. d. Elimina el requerimiento para la Reunión de Retrospectiva del Sprint. 5. El Criterio de Aceptación: a. Reduce la complejidad de las características que han sido incluidas en el backlog. b. Ayuda al equipo a seguir las normas de calidad respecto a la funcionalidad. c. Es formulada por el Scrum Master en revisión conjunta con los miembros del Equipo Scrum. d. Es formulada por el Scrum Master en revisión con el Product Owner.


59

FASE: REVISAR Y RETROSPECTIVA La fase Revisión y Retrospectiva se ocupa de la revisión de los entregables y del trabajo que se ha hecho, y determina las mejores prácticas y métodos utilizados para hacer el trabajo relacionado al proyecto. En las grandes organizaciones, la fase Revisión y Retrospectiva puede incluir la convocatoria de Reunión de Scrum de Scrums.

PROCESO 1: CONVOCAR SCRUM DE SCRUMS (CONVENE SCRUM OF SCRUMS) Este proceso sólo aplica para grandes proyectos Scrum donde varios Equipos Scrum están trabajando sincronizadamente para asegurar el progreso del proyecto. Dado que los equipos trabajan en paralelo, asegurar que todos avancen uniformemente es un tema crítico para los plazos del proyecto. A veces, las tareas de un equipo pueden depender de la entrega a tiempo de una tarea de otro equipo. Por lo que tiene que existir un mecanismo que asegure que los equipos coordinen y que se comuniquen efectivamente. Esto se lleva a cabo normalmente mediante el Scrum de Scrum que es parecido al Daily Scrum pero a nivel de varios equipos. Esta reunión es facilitada por el Jefe Scrum Master (Chief Scrum Master) quien también ayuda a direccionar los impedimentos que impactan a más de un equipo. Los Scrum Masters de cada Equipo Scrum, o representantes, asisten a la reunión Scrum de Scrum. Los participantes dan información de sus Registros de Impedimentos, Dependencias, y sus resultados del proceso de Retrospectiva del Sprint. Cada equipo proporciona respuestas a cuatro preguntas específicas: 1) ¿En qué ha estado trabajando mi equipo trabajando desde la última reunión? 2) ¿Qué hará mi equipo hasta la próxima reunión? 3) ¿Qué consideraban otros equipos que mi equipo termine que aún no se ha hecho? 4) ¿Qué está planeando hacer nuestro equipo que podría afectar a otros equipos? La salida principal de las Reuniones Scrum de Scrum es la mejor coordinación entre varios equipos trabajando en el mismo proyecto.


60

1 Scrum Master o Representantes del Equipo Scrum * 2. Jefe Scrum Master (Chief Scrum Master) 3. Jefe Product Owner (Chief Product Owner) 4. Agenda de la Reunión 5. Impediment Log 6. Dependencias 7. Salidas de la Retrospectiva del Sprint

1. Reunión de Scrum de Scrums (Scrum of Scrums Meeting)* 2. Cuatro Preguntas por Equipo* 3. Video Conferencia 4. Sala de Reunión 5. Juicio Experto del Cuerpo de Asesoramiento de Scrum

1. Mejor coordinación de Equipos * 2. Incidentes Resueltos 3. Impediment Log Actualizado 4. Dependencias Actualizadas

PROCESO 2: DEMOSTRAR Y VALIDAR EL SPRINT (DEMOSTRATE AND VALIDATE SPRINT) Acepta o Rechaza los Entregables En este proceso, el Equipo Scrum presenta los Entregables del Sprint (Sprint Deliverables) al Product Owner, quien valida que esos entregables cumplan con los Criterios de Aceptación. La salida de la Reunión de Revisión del Sprint (Sprint Review Meeting) es la aceptación o el rechazo de los elementos del Sprint Backlog por el Product Owner. Solo las funcionalidades del producto que satisfacen la definición de Terminado (Done) pueden ser presentadas, y las funcionalidades en proceso (WIP) son incluidas en un Sprint futuro. Los miembros del equipo presentan el trabajo completado durante el Sprint, responden a preguntas de los interesados y toman nota de sus sugerencias de cambio. Proporciona retroalimentación necesaria al Scrum Master y al Equipo Scrum El Product Owner y los interesados más importantes participan de la Reunión de Revisión del Sprint para inspeccionar qué ha sido completado hasta el momento y para determinar si algún cambio debe ser implementado en el proyecto o en los procesos en los siguientes Sprints. La retroalimentación de cualquier cambio del proyecto o producto o nuevos requisitos se comunican al Scrum Master y al Equipo Scrum. Actualiza el Plan de Versiones y Prioriza el Product Backlog Si la funcionalidad satisface los criterios de aceptación, entonces está lista para ser transferida al entorno de negocio. El Product Owner podría escoger por liberar inmediatamente la funcionalidad o esperar para realizar el lanzamiento luego de unos cuantos Sprints. El Product Owner tiene la autoridad para decidir cuándo, y después de cuántos Sprints, un lanzamiento se llevará a cabo.


61

Aunque el resultado final de todos los Sprints deben ser potencialmente comercializables, en la práctica no sucede esto con cada Sprint. El Product Owner decide sobre los lanzamientos de las versiones de acuerdo con el Plan de Cronograma de Versiones. El Product Owner debe actualizar el Plan de Versiones y el Product Backlog Priorizado basándose en las Historias de Usuario aceptadas y rechazadas. Si algunos entregables no cumplen con los criterios de aceptación, tales como los entregables rechazados. Las Historias de Usuario asociadas con entregables rechazados permanecen en el Product Backlog Priorizado para que puedan ser incluidos en un siguiente Sprint.

1. Scrum Core Team* 2. Entregables del Sprint (Sprint Deliverables)* 3. Sprint Backlog* 4. Criterio de Terminado (Done Criteria)* 5. Criterio de Aceptación de la Historia de Usuario * 6. Interesados 7. Cronograma de Planificación de la Entrega 8. Riesgos Identificados 9. Dependencias 10. Recomendaciones del Cuerpo de Asesoramiento de Scrum

1. Reunión de Revisión del Sprint (Sprint Review Meeting)* 2. Análisis de Valor Ganado 3. Juicio de Experto del Cuerpo de Asesoramiento de Scrum

1. 2. 3. 4.

Entregables Aceptados * Entregables Rechazados Riesgos Actualizados Resultados del Análisis de Valor Ganado 5. Cronograma de Planificación del Entregable Actualizado 6. Dependencias Actualizadas

PROCESO 3: RETROSPECTIVA DEL SPRINT (RETROSPECT SPRINT) Luego de la Reunión de Revisión del Sprint (Sprint Review Meeting), el Equipo Scrum se reúne en la Reunión de Retrospectiva del Sprint (Retrospect Sprint Meeting). Este es un elemento del marco de trabajo Scrum relacionado a la inspección y adaptación, dado que es una oportunidad para que el Equipo Scrum se tome un momento para mirar hacia atrás y examinar el Sprint que acaba de terminar para identificar mejoras potenciales en el proceso. Estas mejoras pueden resultar no solo en un simple acuerdo entre miembros del equipo para hacer las cosas de otra forma, también puede definir elementos no funcionales para el Product Backlog Priorizado. En la Reunión de Retrospectiva del Sprint (Retrospect Sprint Meeting) participan el Scrum Master y los miembros del Equipo Scrum. El Product Owner podría asistir pero no es obligatoria su presencia. Los miembros del equipo revisan qué se hizo bien y qué no en el Sprint que acaba de terminar. Plantean los problemas que enfrentaron durante el Sprint y discuten cómo se podrían direccionar estos temas. El Equipo identifica mejoras potenciales en la forma de trabajo y también sugiere mejoras en la definición de Done basándose en su experiencia. Estas actividades mejoran el sentido de pertenencia del Equipo Scrum.


62

1. Scrum Master* 2. Equipo Scrum* 3. Salidas de Demostrar y Validar el Sprint * 4. Product Owner 5. Recomendaciones del Cuerpo de Asesoramiento de Scrum

1. Reunión de Retrospectiva del Sprint (Retrospect Sprint Meeting)* 2. ESVP 3. Lancha Rápida (Speed Boat) 4. Técnicas de Métricas and Medidas 5. Juicio de Experto del Cuerpo de Asesoramiento de Scrum


1. Mejoras Viables Acordadas * 2. Acciones acordadas y asignadas con fecha de Entrega 3. Elementos Non-Functional propuestos para el Product Backlog Priorizado 4. Registro de la Retrospectiva del Sprint (Retrospect Sprint Log) 5. Lecciones aprendidas del Equipo Scrum 6. Recomendaciones Actualizadas del Cuerpo de Asesoramiento de Scrum

63

PREGUNTAS - CAPÍTULO FASE: REVISAR Y RETROSPECTIVA 1. No es obligatoria la participación del Product Owner en cuál de las siguientes reuniones (seleccione todas las que apliquen) a. Reunión de Planificación del Sprint (Sprint Planning Meeting) b. Reunión de Retrospectiva del Sprint (Retrospect Sprint Meeting) c. Reunión Diaria (Daily Standup) d. Reunión de Revisión del Sprint (Sprint Review Meeting) 2. ¿Qué proceso permite a los miembros del Equipo Scrum hacerse responsables del proyecto y mejorar la calidad? a. Retrospectiva del Sprint b. Aprobar, Estimar y Comprometerse con las Historias de Usuario c. Ejecutar la Reunión Diaria d. Refinar el Product Backlog 3. Durante el proceso de Retrospectiva del Sprint, el Scrum Master facilita la Reunión de Retrospectiva del Sprint. La reunión es el paso final de un Sprint. ¿Cuál de las siguientes alternativas es verdadera respecto a esta reunión? a. Esta reunión asegura que los riesgos identificados se incorporen en el Product Backlog Priorizado. b. Al final de la reunión, el Equipo Scrum podrá estimar adecuadamente las Historias de Usuario. c. La presencia del Product Owner en esta reunión es obligatoria. d. Esta reunión es un elemento importante del marco de trabajo de Scrum relacionado a la inspección y adaptación. 4. ¿Con qué frecuencia se lleva a cabo la Reunión de Revisión del Sprint? a. Según lo determine el Scrum Master. b. Cuando el Product Owner convoque esta. c. Al final de cada Sprint d. Al final de cada proyecto 5. La reunión en la cual el equipo revisa el trabajo completado y presenta la funcionalidad final del Sprint que acaba de finalizar al Product Owner es conocido como la: a. Reunión de Visión del Producto (Product Vision Meeting) b. Reunión de Planificación del Sprint (Sprint Planning Meeting) c. Reunión de Revisión del Sprint (Sprint Review Meeting) d. Reunión de Retrospectiva del Sprint (Sprint Retrospective Meeting) 6. ¿Cuál de los siguientes pares están correctamente relacionados? a. Reunión Diaria : Foro para comunicar b. Reunión de Revisión del Sprint: Entrega de Funcionalidades c. Reunión de Planificación del Sprint: Inicio del desarrollo del producto d. Reunión de Retrospectiva del Sprint: Evaluación del trabajo realizado en el Sprint


64

FASE: LANZAMIENTO La fase de lanzamiento (release) destaca la entrega de los Entregables Aceptados al Cliente y la identificación, documentación e internalización de las lecciones aprendidas del proyecto.

PROCESO 1: ENVIAR LOS ENTREGABLES (SHIP DELIVERABLES) Ayuda a desplegar las Versiones de Producto y Coordina con el Cliente Después que el Product Owner valida los entregables del Sprint basándose en los Criterios de Aceptación y de Terminado, los Entregables Aceptados están listos para la entrega o lanzamiento a los Interesados. Sin embargo, no todos los Sprints terminan en un lanzamiento. La decisión de cuándo la entrega es un incremento de producto potencialmente comercializable para los interesados es tomada en el proceso Conduct Release Planning. El Cronograma de Planificación de Entrega (Release Planning Schedule) documenta qué entregables serán liberados y cuándo. De este modo, las entradas principales para este proceso son los Entregables Aceptados y el Cronograma de Planificación de Entrega. Los entregables son desplegados utilizando los Métodos de Despliegue de la Organización. Cada organización tiene sus propios Métodos de Despliegue. Estos guían cómo y cuándo los entregables serán liberados a los interesados. Las principales salidas de este proceso son los Entregables Trabajados, Acuerdos de Entregables Trabajados y Lanzamientos de Producto. Las herramientas utilizadas para el lanzamiento de los entregables son las siguientes: 1. Métodos de Despliegue de la Organización – Los mecanismos de despliegue de cada organización es diferente de acuerdo a la industria, los usuarios objetivo y el posicionamiento. De acuerdo a las características del producto entregado, el despliegue puede ser remoto, podría implicar un envío físico o la transición de un elemento. Debido a que la implementación tiende a involucrar alto riesgo, las organizaciones normalmente tienen mecanismos de despliegue bien definidos, que incluyen procesos detallados para garantizar que se cumplan los estándares y medidas de aseguramiento de calidad establecidos. Estos podrían incluir aprobaciones de cierre de algunos representantes de gestión y usuarios; así como directivas respecto a la mínima funcionalidad que se puede desplegar. 2. Plan de Comunicaciones – En muchos proyectos, el plan de Comunicación existe. Este plan especifica los registros que deben ser creados y mantenidos durante todo el proyecto. Muchos métodos se utilizan para transmitir información del proyecto a los interesados, y el Plan de Comunicación define estos métodos, así como de quién es responsable de las distintas actividades de comunicación. El estado de las pruebas de los entregables debe ser comunicado por el Plan de Comunicación, según lo determine el Product Owner y el Patrocinador. Un mecanismo de comunicación muy útil es representar de forma visual la información más importante en un formato de fácil interpretación, en un lugar accesible donde se pueda mantener actualizada esta información.


65

La principal salida de este proceso es la siguiente: Acuerdos de Entregables Terminados – Los entregables que satisfacen los Criterios de Aceptación reciben la aprobación y cierre formal por parte del cliente y patrocinador. La obtención de la aceptación formal del cliente es fundamental para el reconocimiento de ingresos y la responsabilidad del cierre de la versión. La responsabilidad para su obtención será definida por políticas de la empresa y no necesariamente es responsabilidad del Product Owner. Entregables Terminados – Esta salida es el Entregable final por el cual el proyecto fue autorizado. A medida que se crean nuevos incrementos de los producto, son integrados continuamente a los incrementos anteriores, por lo se tendrá un producto potencialmente comercializable disponible en todo momento a lo largo del proyecto. Lanzamiento del Producto- Los lanzamientos de Producto deben incluir lo siguiente:

1. 2. 3. 4. 5. 6. 7. 8. 9.



Contenido de la Versión—Esto consiste en la información esencial acerca de las entregables que pueden ayudar al Equipo de Apoyo al Cliente (Cliente).



Notas de la Versión— Las notas de la versión debe incluir criterios de lanzamiento externos o los relacionados al mercado del Producto a ser entregado.

Product Owner * Interesados * Entregables Aceptados * Cronograma de Planificación de Entrega * Scrum Master Equipo Scrum Criterios de Aceptación de Historia de Usuario Plan Piloto Recomendaciones del Cuerpo de Asesoramiento de Scrum

1. Métodos de Despliegue de la Organización (Organizational Deployment Methods) * 2. Plan de Comunicación


1. Acuerdos de Entregables Trabajados (Working Deliverables Agreement)* 2. Entregables Trabajados (Working Deliverables) 3. Lanzamientos de Producto (Product Releases)

66

PROCESO 2: RETROSPECTIVA DEL PROYECTO (RETROSPECT PROJECT) Participa en las Reuniones de Retrospectiva del Proyecto El último proceso del flujo Scrum es la Retrospectiva del Proyecto, la cual es similar al proceso Retrospectiva del Sprint, pero a nivel de proyecto. Después que todos los incrementos de producto son entregados exitosamente a los interesados, el Equipo Core Scrum o los equipos revisan, analizan e identifican qué se hizo bien y que no durante el ciclo del proyecto. La reunión de Retrospectiva del Proyecto (Retrospect Project Meeting) tiene el objetivo de identificar las mejores prácticas y recomendaciones para el Cuerpo de Asesoramiento Scrum (Scrum Guidance Body). No solo ayuda a mejorar la colaboración y eficiencia del equipo, también identifica mejoras para toda la implementación Scrum. Las sugerencias, opiniones y conocimientos obtenidos en la reunión de Retrospectiva del Proyecto son registrados para referencias futuras. La Reunión de Retrospectiva del Proyecto es utilizada para determinar de qué manera se puede mejorar la colaboración y efectividad del equipo en futuros proyectos. Oportunidades positivas, negativas y potenciales de mejora son también discutidas. Esta reunión no es Time-boxed y podría ser ejecuta de forma presencial o virtual. Los participantes incluyen al Equipo del Proyecto, el Jefe de Scrum Master, Jefe de Product Owner e interesados. Durante la reunión, las lecciones aprendidas con documentadas y los participantes buscan oportunidades de mejora de procesos y direccionamiento de ineficiencias. Las principales salidas del proceso de Retrospectiva son las siguientes:

1. 2. 3. 4. 5.



Mejoras viables acordadas.



Acciones acordadas y asignadas con fecha de entrega.

Scrum Core Team(s)* Jefe Scrum Master Jefe Product Owner Interesados) Recomendaciones del Cuerpo de Asesoramiento de Scrum

1. Reunión de la Retrospectiva del Proyecto (Retrospect Project Meeting)* 2. Otras herramientas para la Retrospectiva del Proyecto 3. Juicio Experto del Cuerpo de Asesoramiento de Scrum


1. Mejoras viables acordadas* 2. Acciones acordadas y asignadas con fecha de Entrega* 3. Elementos Non-Functional propuestos para el Product Backlog Priorizado y para el Program Product Backlog 4. Recomendaciones Actualizadas del Cuerpo de Asesoramiento de Scrum

67

PREGUNTAS - CAPÍTULO FASE: LANZAMIENTO 1. Las salidas del proceso de Retrospectiva del Proyecto incluyen: a. Mejoras viables acordadas, Product Backlog Priorizado b. Mejoras viables acordadas, Acciones acordadas y asignadas con fecha de entrega c. Product Backlog Priorizado Actualizado, Acciones acordadas y asignadas con fecha de entrega d. Product Backlog Priorizado Actualizado, Notas de Versiones 2. Las principales salidas del proceso Enviar Entregables incluyen las siguientes, EXCEPTO: a. Acuerdo de Entregables Terminados b. Entregables Terminados c. Product Backlog d. Versiones de Producto 3. El propósito de la Reunión de Retrospectiva de Proyecto es para: a. Alentar el sentimiento de propiedad compartida entre los miembros del equipo para hacerlos más responsables. b. Determinar formas en las cuales la colaboración y efectividad del equipo puede ser mejorada para futuros proyectos. c. Planificar el siguiente proyecto para el equipo Scrum. d. Celebrar los logros y ofrecer recompensas monetarias para los miembros del equipo.


68

IMPLEMENTACIÓN DE SCRUM ESCALABILIDAD DE SCRUM Para ser eficaz, los Equipo Scrums deben tener idealmente de seis a diez miembros. Esta práctica podría llevar a la idea errónea de que el método de Scrum sólo se puede utilizar para proyectos pequeños. Sin embargo, se puede escalar fácilmente para el uso eficaz en proyectos grandes. En situaciones donde el tamaño del Equipo Scrum excede los diez miembros, múltiples Equipo Scrums se pueden formar para trabajar en el proyecto. El proceso Convocar Scrum of Scrum facilita la coordinación entre los Equipo Scrums lo que permite una aplicación efectiva en los proyectos grandes. Los proyectos grandes o complejos a menudo se implementan como parte de un Programa o Portafolio. El método de Scrum también se puede aplicar para gestionar Programas y Portafolios. El enfoque lógico de las directrices y los principios de este marco pueden utilizarse para gestionar proyectos de cualquier tamaño, que abarcan distintas geografías y organizaciones. Los proyectos grandes pueden tener varios Equipos Scrums trabajando de forma paralela por lo que es necesario sincronizarse y facilitar el flujo de información y mejorar la comunicación. El proceso Convocar Scrum de Scrum asegura esta sincronización. Los diversos Equipos Scrums están representados en esta reunión y el objetivo es proporcionar actualizaciones sobre el progreso, discutir los retos que enfrentan durante el proyecto y coordinar las actividades. No hay reglas fijas en cuanto a la frecuencia de estas reuniones. Los factores que determinan la frecuencia son el nivel de dependencia entre los equipos, el tamaño del proyecto, el nivel de complejidad y las recomendaciones del Cuerpo de Asesoramiento de Scrum.

SCRUM EN PROGRAMAS Y PORTAFOLIOS. Programas En los Programas, los roles principales para la gestión de Scrum son: 1. Product Owner del Programa — Define los objetivos y las prioridades estratégicas para el Programa. 2. Scrum Master del Programa — Resuelve problemas, remueve Impedimentos, facilita y lleva a cabo reuniones para el Programa. Estas funciones son similares a las del Product Owner y Scrum Master excepto que satisfacen las necesidades del Programa o unidad de negocio en lugar de las de un sólo Equipo Scrum. Portafolios En Portafolios, los roles importantes para la gestión de Scrum son: 1. Product Owner del Portafolio —Define los objetivos estratégicos y las prioridades del Portafolio. 2. Scrum Master del Portafolio —Resuelve problemas, elimina Impedimentos, facilita y lleva a cabo reuniones para el Portafolio. La siguiente figura ilustra cómo el método Scrum se puede utilizar en toda la organización para los Portafolio, Programa o Proyectos.


69

Scrum en toda la organización para Proyectos, Programas y Portafolios

Trabajando con Equipos de Programas y Portafolios Al aplicar Scrum para gestionar proyectos en el marco de un Programa o un Portafolio se recomienda que los principios generales de Scrum que se presentan en el SBOKTM se cumplan. Se entiende, sin embargo, que con el fin de cumplir con el Programa en su totalidad o las actividades relacionadas con el Portafolio e interdependencias, pueden ser necesarios pequeños ajustes en el conjunto de herramientas, así como en la estructura organizacional. Los Portafolios y Programas tienen equipos separados y con diferentes objetivos. Los equipos de gestión de Programa tienen por objetivo ofrecer capacidades y llevar a cabo ciertas metas que contribuyan a objetivos específicos del Programa. Por el contrario, el equipo de Portafolio tiene que equilibrar los objetivos de los distintos Programas para alcanzar los objetivos estratégicos de la organización en su totalidad. La gestión de comunicación con los equipos de Portafolio y Programas

Los problemas que se enfrentan al utilizar Scrum dentro de un Programa o Portafolio implican principalmente la coordinación entre los numerosos equipos. Esto puede conducir al fracaso si no se gestiona con cuidado. Las herramientas utilizadas para la comunicación deben ser escaladas para que coincida con los requisitos de los equipos que participan en un Programa o un Portafolio. Cada Equipo Scrum debe atender no sólo la comunicación interna, sino también la comunicación externa con otros equipos y los interesados del Programa o Portafolio.

Reuniones de Scrum of Scrums (SoS) Scrum of Scrums Meeting Un Scrum of Scrums (SoS) Meeting es un elemento importante al escalar o ajustar Scrum a proyectos grandes . Por lo general, hay un representante en la reunión de cada uno de los Equipo Scrums. Por © 2014 SCRUMstudy.com

70

lo general el representante es el Scrum Master, pero también puede asistir cualquier miembro del Equipo Scrum si es necesario. Esta reunión es usualmente facilitada por el Jefe Scrum Master y su objetivo es centrarse en las áreas de coordinación e integración entre los diferentes Equipo Scrums. Tal reunión se lleva a cabo en intervalos predeterminados o cuando lo requieran los Equipo Scrums. En organizaciones donde hay varios Equipo Scrums trabajando en varias partes de un proyecto de forma simultánea, SoS se puede escalar a otro nivel, esta se conoce como Scrum of Scrum of Scrums Meeting. En esta situación, una Reunión SoS mantiene la coordinación de cada grupo de los Equipo Scrums.

La Figura ilustra la dinámica de las reuniones Scrum of Scrums (SoS)

Reunión de Scrum of Scrums (SoS)

TRANSICIÓN A SCRUM Los dos métodos básicos para hacer la transición a Scrum son de arriba a abajo y de abajo a arriba. En el método de arriba hacia abajo, la transición es comunicada en toda la organización. Existe un esfuerzo por proveer capacitación del cambio a todos los involucrados. Esta comunicación puede ser fuente de resistencia al cambio. La otra posibilidad es cambiar las cosas gradualmente dentro de la cultura de la organización. Después, la transición a Scrum será de forma incremental. Con una implementación de arriba hacia abajo, podrían haber conflictos de comunicación. Por ejemplo, un líder de ingeniería implantó Scrum en su organización sin el consentimiento por parte del área de ventas. Esto llevaría a grandes conflictos con el mismo Product Owner. Otro aspecto a considerar de la transición es saber el impacto de la transición de la organización a los métodos Scrum. Toda organización puede hacer la transición al mismo tiempo. Sin embargo, este método es más susceptible a problemas que pueden resultar en la interrupción de actividades que generan ganancias. Por lo tanto, es generalmente preferible hacer la transición en diferentes secciones de forma iterativa para reducir el riesgo y proveer lecciones aprendidas para futuras iteraciones.


71

Mapeo de Roles tradicionales a Scrum Los roles tradicionales de la gestión de proyecto son divididos en tres roles en Scrum : Product Owner , Scrum Master y Scrum Team.   



El Product Owner se comunica con los interesados y establece las prioridades del proyecto. El Scrum Master ejecuta los deberes del jefe de proyecto porque remueve los impedimentos. El Scrum Master, como el jefe de proyecto, es responsable de asegurar que los procesos Scrum sean ejecutados adecuadamente. Los miembros del Equipo también ejecutan algunos roles tradicionales del jefe de proyecto, dado que ellos se auto gestionan y son dueños de su tiempo. Esto permite que el equipo tenga un sentido de pertenencia para que busque su propio éxito.

Mantenimiento de la Participación de los Interesados Scrum requiere gran apoyo por parte de los interesados del proyecto. Las siguientes son las acciones recomendadas para el mantenimiento de la participación y el apoyo de los interesados. 

Establecer un acuerdo de trabajo con los interesados para promover su colaboración y participación efectiva.



Evaluar continuamente los cambios del proyecto que afectan a los interesados para asegurar que nuevos interesados del proyecto estén comprometidos.



Mantener una comunicación regular con los interesados.



Administrar las expectativas de los interesados.

Importancia del Soporte Ejecutivo Los ejecutivos son las personas que financian el proyecto. Por tanto, para que cualquier proyecto de Scrum sea exitoso, los ejecutivos deben apoyarlo. Para conservar el apoyo ejecutivo:   

Comuníquese regularmente con los ejecutivos. Mantenga a los ejecutivos informados de los últimos avances. Informe a los ejecutivos de cualquier conflicto o retrasos potenciales en la entrega del proyecto para minimizar el impacto.

Es importante que los ejecutivos que financian el proyecto tengan claridad respecto a los siguientes temas: 





¿Cuál es el beneficio de implementar el Método Scrum? o ¿Cómo este cambio crea beneficios y / o evita pérdidas para la organización? o ¿Cuán imprescindible es adaptarse al actual ambiente de negocios? ¿Cuáles son los plazos límite y costos de la transición? o ¿Cuál es el tiempo estimado para completar la transición y cuál es el costo de la transición? o ¿Cuáles son los hitos principales para realizar la transición? o ¿Qué tan frecuentemente los ejecutivos se va a reunir para revisar el avance del proyecto? ¿Cuáles son los riesgos que involucra la transición? o ¿Cuáles son obstáculos o riesgos potenciales en la implementación? o ¿Cuál es el costo y tiempo adicional requerido para mitigar cada uno de estos riesgos?


72

PREGUNTAS - CAPÍTULO IMPLEMENTANDO SCRUM 1. ¿Cuál de los siguientes NO es un desafío en la implementación de Scrum en grandes proyectos? A. Se requieren varios equipos para trabajar en sincronía. B. Falta de un Product Backlog general para monitorear el progreso de todos los proyectos. C. Nivel adicional en la jerarquía en tenga el rol de Jefe Product Owner. D. Interdependencia de las tareas entre los equipos. 2. A. B. C. D.

¿Quién es responsable del todo el éxito o fracaso en proyectos grandes? Jefe de Scrum Master Jefe de Product Owner Equipo Scrum Interesados

3. ¿Cuál de los siguientes es parte de la Reunión Scrum de Scrums? A. Si alguna de tus decisiones podrían afectar a otros equipos. B. Hablar de los problemas que pueden haber surgido para cualquiera de los equipos de Scrum. C. Resolución de Impedimentos que pueden haber surgido. D. Resumen de las tareas a realizar en el Sprint.

4. ¿Cuál de las siguientes afirmaciones es FALSA respecto a Scrum en equipos grandes? (seleccione las que corresponden) A. Los equipos grandes tienen Jefe de Scrum Masters y Jefe de Product Owners para controlar el progreso del proyecto. B. El Jefe de Product Owner facilita la reunión de Scrum de Scrums. C. El Jefe de Product Owner es responsable de la asignación de recursos. D. El Jefe de Scrum Master es responsable del éxito o fracaso del proyecto.


73

IMPORTANCIA DEL VALOR Un proyecto de negocio se lleva a cabo para crear valor a este. Debido a que el valor es la razón principal del proyecto, la Entrega impulsada por el Valor debe ser el enfoque de cualquier proyecto y está arraigado en el ADN de los proyectos Scrum. El Manifiesto Ágil da fé de esto cuando declara su preferencia por el “software funcionando sobre documentación extensiva”, a través de su principio “entrega de software funcionando frecuentemente”, y con “ el software funcionando es la primera medida de avance”. Por lo tanto es responsabilidad del Product Owner asegurar que la creación es el enfoque del proyecto. Scrum tiene como objetivo ofrecer valor temprano al proyecto. Debido a la naturaleza impredecible del desarrollo del producto, es importante entregar componentes destacados tan pronto como sea posible. Esta entrega temprana de valor da una oportunidad para la reinversión, así como para demostrar el valor del proyecto a los interesados.

Prácticas de Entrega Impulsado por el Valor 1. Evaluación del valor- El valor del proyecto de negocio es estimado utilizar indicadores financieros como Retorno sobre la Inversión (ROI), Valor Presente Neto (VPN) y Tasa Interna de Retorno (TIR).

2. Caso de Negocio- Un caso de negocio es un documento que describe porque los patrocinadores potenciales deben emprender el proyecto. Esta proporciona un beneficio monetario estimado. Si el proyecto no brinda un valor monetario directo y es un servicio que debe ser proporcionado, entonces un caso de negocio puede mostrar el riesgo que los patrocinadores podrían evitar si el proyecto es implementado. Un caso de negocio normalmente incluye la siguiente información: 

Descripción del proyecto



Costos y beneficios esperados para los patrocinadores del proyecto



Evaluación del valor del proyecto mediante el cálculo del Retorno de Inversión (ROI), Valor Presente Neto (VPN) y Tasa Interna de Retorno (TIR).



Riesgos que se pueden evitar si el proyecto se lleva a cabo.



Sugerencias de los interesados.

3. Juegos Agiles (Juegos Colaborativos) Juegos Colaborativos, también conocidos como juegos de innovación, son técnicas utilizadas por equipos e interesados para identificar problemas y acordar soluciones. Hay varios juegos de colaboración que se pueden utilizar en los proyectos Scrum: 

Recordar el Futuro: Este ejercicio ayuda a establecer una visión para el proyecto y obtener requerimientos de los interesados.



Podar el Árbol de Producto: Este ejercicio de tormenta de ideas es llevado a cabo para determinar características y funcionalidades del producto.



Lancha rápida: Con este ejercicio, los equipos e interesados identifican beneficios y amenazas del proyecto.


74



Dinero de Monopolio: En este ejercicio, los clientes distribuyen una cantidad determinada de dinero de juego entre un conjunto de características.



Comprar una característica: Este ejercicio ayuda a priorizar las características una vez que estén finalizados.



Bang for the Buck: Este ejercicio evalúa el valor del negocio versus el costo.

4. Valor de la Planificación : Después de evaluar el valor del proyecto con herramientas como Mapa de Flujo de Valor, Chartering, Priorización basada en el valor y hojas de ruta del producto, el proyecto es planificado maximizando la Entrega basada en el Valor. La responsabilidad para determinar “cómo” se creará el valor recae en el Equipo Scrum, mientras que el Product Owner se concentra en “qué” debe ser desarrollado. La planificación del valor es una función muy importante del Product Owner, ya su visión y su habilidad para determinar efectivamente esta, dará como resultado el equipo entregue productos exitosos.

5. Valor de la Entrega : Una vez que completa la evaluación y planificación del valor, el equipo pasa a ejecutar y entregar valor. Para hacer este trabajo efectivamente, los equipos técnicos deben eliminar los siete desperdicios o muda sugeridos por Mary Poppendieck. Los siete desperdicios incluyen: hacer un trabajo parcial (como código que aún no se ha probado), procesos extra (documentación y formalidad oficial innecesaria), espera (aprobaciones pendientes), cambio de tareas (recursos que son distribuidos en muchos proyectos), funcionalidades extra (funcionalidades que no son esenciales para el producto), movimiento (tiempo y esfuerzo para comunicar o transferencia de entregables) y defectos (errores y defectos de software).

6. Valor de la Confirmación: Scrum es utilizada para crear productos y servicios que son a menudo intangibles. Debido a esto, es importante validar la ruta actual del proyecto con las directrices que se establecieron al inicio. Esto se puede hacer utilizando prototipos, simulaciones y demostraciones. La presentación de prototipos y simulaciones de las funcionalidades a los clientes es una práctica importante para confirmar valor.

7. Valor del Seguimiento y Reporte: El control de la tasa de entrega de valor es un aspecto importante de los proyectos Scrum. El seguimiento periódico y la elaboración de informes ayudan a evaluar el estado del proyecto, los cuales pueden ser comunicados al cliente. Valor Ganado Agile Los gráficos de la curva S y los diagramas Gantt tiene sus propias limitaciones para realizar el seguimiento y reporte del progreso del proyecto. Por esto que el Análisis de Valor Ganado (Earned Value Analysis EVA) y la Gestión del Valor Ganado (Earned Value Management EVM) fue creado. El Análisis de Valor Ganado mide el desempeño real del proyecto comparado con el desempeño planeado en cualquier punto. Sin embargo, para que esta herramienta sea efectiva se necesita tener una línea base fuerte. La Gestión de Valor Ganado se enfoca en la proyección en el tiempo que ayudará a saber cuándo se completará el proyecto y a saber el costo final. El Análisis de Gestión Ganado utiliza elementos visuales, en forma de gráficos, como una forma básica para comunicar el estado.


75

Diagrama de Flujo Acumulado (CFDs) El Diagrama de Flujo Acumulado da información valiosa sobre el estado del proyecto y es una herramienta importante para realizar seguimiento e informar el estado de los proyectos ágiles. El área sombreada muestra el total de funcionalidades a ser construidas. CFDs proporcionan una representación visual de cómo el proyecto se está realizando. Es una herramienta útil para identificar obstáculos y cuellos de botella dentro de los procesos. Si el CFD muestra una banda de proceso que está cada vez más pequeña que el proceso anterior mientras que el proceso anterior se hace más grande con el tiempo, entonces el proceso con la banda más pequeña es el cuello de botella, por lo que se tendrá que hacer cambio para hacer que el flujo sea más eficiente. Un ejemplo del diagrama CFD es el siguiente:


76

Gestión de Riesgo La gestión del riesgo es tan importante como la creación de valor y debe ser ejecutada durante todo el proyecto. Los riesgos se evalúan basados en: la probabilidad de riesgo y el impacto del riesgo. Si la probabilidad de riesgo es calculada como un porcentaje del y el impacto del riesgo es calculado en términos monetarios, entonces será fácil de evaluar el Valor Monetario del Riesgo (EVM) del riesgo. La fórmula de la severidad del riesgo es calculada de la siguiente forma: Severidad de Riesgo = Probabilidad de Riesgo x Impacto de Riesgo El cálculo de la severidad de riesgo puede también ayudar a priorizarlos y dar prioridad a la respuesta de estos, esto no solo se aplica a proyectos Agiles. Sin embargo, los proyectos Agiles están enfocados en la creación de valor, y el cálculo del VME puede ayudar a identificar y evitar riesgos. La severidad del riesgo se puede calcular en una escala numérica. Al tener un valor monetario asignado a un riesgo es posible priorizarlo contra el valor de una funcionalidad generada. Backlog ajustado a los Riesgos (Risk – adjusted Backlog): Un riesgo puede tener un impacto positivo o negativo al proyecto. Por lo tanto, se planifican las actividades de gestión de riesgos para minimizar cualquier riesgo negativo. Scrum rápidamente identifica y mitiga los riesgos y puede aprovechar las herramientas de gestión de riesgo. Antes de emprender cualquier proyecto, los representantes del negocio calculan el ROI estimado para el proyecto completo, que luego se divide en las funcionalidades individuales. Así, se crea una lista de características priorizada con los valores de retorno de la inversión (ROI). Del mismo modo, los pasos para evitar los riesgos están evaluados de forma monetaria mediante el cálculo del valor del riesgo. El valor monetario de la acción de mitigación del riesgo es calculada utilizando el Valor Monetario Esperado (EMV), en la que se utiliza la siguiente fórmula. El cliente se aproxima a estos valores. Valor Monetario Esperado = impacto de riesgo (en moneda) x probabilidad de riesgo (en porcentaje) A continuación se muestra un product backlog priorizado: Risk adjusted Backlog Con características y acciones de respuesta


77

SPOC Cuaderno de Trabajo Resuelto

Recommend Documents