• Author / Uploaded
• Arturo Amapanqui Ormaeche

• Categories
• Scrum (desarrollo de software)
• Desarrollo Ágil de Software
• Ingeniería de software
• Software
• Desarrollo de productos

Citation preview

© 2014 SCRUMstudy.com

v4.1

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



Está es una clase de tres días y cada día tendrá 5 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, incluyendo los roles, reuniones y artefactos. Preparar a los participantes para sentirse cómodos al implementar Scrum en sus organizaciones así como también manejar conflictos y obstáculos comunes.

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 desempeñar el rol de Scrum Master en sus organizaciones y ayudar a sus organizaciones a adoptar el Marco de Trabajo Scrum. Los participantes participarán en dinámicas en las cuales llevarán a cabo un proyecto Scrum. Los participantes obtendrán conocimientos para anticipar conflictos relacionados a la implementación de Scrum. Los participantes contarán con las herramientas apropiadas para dirigir, resolver y tomar el liderazgo en los conflictos de Scrum en sus organizaciones. 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 implementación de todas las partes del flujo Scrum. Los participantes ponen en práctica un caso de estudio para simular el desarrollo del producto utilizando el Marco de Trabajo Scrum.

© 2014 SCRUMstudy.com

1

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

SCRUMstudy Certified

SMCTM

SPOCTM

AECTM

Scrum Master Certified

Scrum Product Owner Certified

Agile Expert Certified

SDCTM

Foundation Level

Scrum Developer Certified

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

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

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

© 2014 SCRUMstudy.com

2

RESUMEN DE AGILE El término agile (ágil) generalmente se refiere a ser capaz de moverse o responder rápidamente y fácilmente. En cualquier tipo de disciplina de gestión, ser ágil es una cualidad, por lo tanto esto debe ser una meta que se debe tratar de alcanzar. La gestión de Proyectos Agile especialmente, implica la adaptabilidad durante la creación de un Producto, Servicio o cualquier otro Resultado. Es importante entender que a pesar de que el desarrollo de los métodos ágiles es altamente adaptable, de todos modos es necesario tener en cuenta la estabilidad en sus procesos de adaptación.

El gran interés por Agile Agile se basa en la planificación de adaptación en el desarrollo y la entrega iterativa. Se centra principalmente en que el equipo ejecute el trabajo con eficacia. Aunque las metodologías adaptivas e incrementales han existido desde la década de 1950, sólo las metodologías que se ajustan a El Manifiesto Ágil son generalmente consideradas verdaderamente como "Ágil".

The Agile Manifesto El propósito de The Agile Manifesto fue distribuido de la siguiente manera: 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 Software Funcionando Colaboración con el Cliente Respuestas ante el cambio

Procesos y Herramientas Documentación Extensiva Negociación Contractual Seguir un Plan

Es decir, mientras que hay valor en los elementos de la derecha, valoramos más los elementos de la izquierda.

Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler

James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick

Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas

El permiso para copiar fue proporcionado por los autores mencionados mediante aviso en http://agilemanifesto.org/.

© 2014 SCRUMstudy.com

3

Las cuatro compensaciones de The Agile Manifesto se elaboran de la siguiente manera: 1. 2. 3. 4.

Individuos e interacciones sobre procesos y herramientas Software funcionando sobre la documentación extensiva Colaboración con el Cliente sobre la negociación contractual Responder ante el cambio en vez de seguir un plan

Principios de Agile Manifesto 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.

© 2014 SCRUMstudy.com

4

Métodos Agile Una serie de metodologías ágiles se crearon y ganaron fuerza en la década de 1990 y principios del 2000. Si bien difieren en una variedad de aspectos, lo que tienen en común se deriva de su adhesión a The Agile Manifesto. Los siguientes métodos ágiles se discuten brevemente a continuación: 1. 2. 3. 4. 5. 6. 7. 8. 9.

Lean Kanban Extreme Programming (XP) Crystal Methods Dynamic Systems Development Methods (DSMD) Feature Driven Development (FDD) Test Driven Development (TDD) Adaptive Software Development (ASD) Agile Unified Process (AUP) Domain-Driven Design (DDD)

Lean Kanban El concepto de Lean optimiza el sistema de una organización para producir resultados valiosos sobre la base de sus recursos, necesidades y alternativas, mientras reduce las pérdidas. Las pérdidas, por ejemplo, podrían ser la construcción incorrecta de un Producto, el no saber aprender, o las prácticas que impiden que el proceso fluya. Debido a que estos factores son de naturaleza dinámica, una organización ágil evalúa la totalidad de su sistema y continuamente hace ajustes a sus procesos. El fundamento de Lean es que la reducción de la duración de cada ciclo (es decir, una iteración) conduce a un aumento de Productividad mediante la reducción de los retrasos, ayuda en la detección de errores en una etapa temprana, y en consecuencia reduce la cantidad total de esfuerzo requerido para terminar una tarea. Los principios de software Lean se han aplicado con éxito en el desarrollo de software. Kanban significa literalmente un "cartel" o "cartelera” y enfatiza el uso de ayudas visuales para ayudar y realizar un seguimiento de la producción. El concepto fue introducido por Taiichi Ohno, considerado como el padre de los sistemas Toyota Proudction Systems (TPS).

Extreme Programming Extreme Programming (XP), que se originó en Chrysler Corporation, ganó fuerza en la década de 1990. XP hace que sea posible mantener el costo de cambiar el software sin que éste aumente radicalmente con el tiempo. Los atributos claves de XP incluyen el desarrollo gradual, horarios flexibles, pruebas automatizadas de código, la comunicación verbal, el diseño en constante evolución, Colaboración cercana y la vinculación de las unidades, de largo como de corto plazo, de todos los involucrados.

Crystal Methods Las metodologías de desarrollo de software Crystal fueron presentadas por Alistair Cockburn a principios de 1990. Los métodos Crystal se centran en las personas, son ligeros y fáciles de adaptar. Porque la gente es lo primordial, los procesos y las herramientas de desarrollo no son fijos sino que se ajustan a las necesidades y características específicas del Proyecto. Todos los métodos de Crystal tienen cuatro roles – patrocinador, diseñador principal, desarrolladores y usuario experto. Los métodos Crystal recomiendan diversas estrategias y técnicas para lograr agilidad. Un ciclo de proyectos Crystal consta de gráficos, ciclo de entrega y de recapitulación.

© 2014 SCRUMstudy.com

5

Dynamic Systems Development Methods (DSDM) El marco Dynamic Systems Development Methods (DSDM) se publicó inicialmente en 1995 y es administrado por el Consorcio DSDM. DSDM establece la calidad y el esfuerzo en términos de costo y el tiempo desde el principio y ajusta los entregables del proyecto para cumplir con los criterios establecidos, dando prioridad a las prestaciones en las siguientes categorías: lo que "deben tener", "deberían tener", "podrían tener", y "no tendrán" (mediante la técnica Priorización MoSCoW). DSDM es un método orientado al sistema con seis distintas fases de pre-proyecto; Viabilidad; Fundamentos; Exploración e Ingeniería; Despliegue y Evaluación de Beneficios.

Feature Driven Development (FDD) Feature Driven Development (FDD) fue presentado por Jeff De Luca en 1997 y opera bajo el principio de la realización de un proyecto donde éste se separa en pequeñas funciones valoradas por el cliente que pueden ser entregadas en menos de dos semanas. FDD tiene dos principios - el desarrollo de software es una actividad humana y el desarrollo de software es una funcionalidad valorada por el cliente.

Test Driven Development (TDD) También conocido como Test-First Development, Test Driven Development fue presentado por Kent Beck, uno de los creadores de Extreme Programming (XP). Test Driven Development es un método de desarrollo de software que consiste en escribir primero un código de prueba automatizado y en el desarrollo de la menor cantidad de códigos necesarios para luego pasar la prueba.

Adaptive Software Development (ASD) Adaptive Software Development (ASD) surgió a partir de la rápida labor de desarrollo de aplicaciones por Jim Highsmith y Sam Bayer. Los aspectos más destacados de los ASD son Adaptación constantes de los procesos de trabajo, el suministro de soluciones a los problemas que surgen en los grandes Proyectos y el desarrollo incremental iterativo con prototipos continuos.

Agile Unified Process (AUP) Agile Unified Process (AUP) evolucionó del proceso llamdo Rational Unified Process de IBM. Desarrollado por Scott Ambler, AUP combina técnicas ágiles de la industria ya probadas como Test Driven Development (TDD), Agile Modeling, gestión del cambio ágil y la base de datos Refactoring para ofrecer un Producto de trabajo de la mejor calidad.

Domain-Driven Design (DDD) Domain-Driven Design se trata de un enfoque de desarrollo ágil con la intención de manejar diseños complejos con aplicación vinculada a un modelo en evolución. Fue concebido por Eric Evans en el año 2004 y gira en torno al diseño de un dominio básico.

© 2014 SCRUMstudy.com

6

Scrum vs Gestión de Proyectos Tradicional En la tabla se resumen muchas de las diferencias entre los modelos tradicionales de gestión de proyectos y Scrum.

Enfoque

Scrum

Gestión de Proyectos Tradicional

El énfasis está en

Personas

Procesos

Documentación

Sólo mínima según se requiera

Exhaustivo

Estilo de Procesos

Iterativo

Lineal

Planificación por Adelantada

Baja

Alta

Prioritización de los Requisitos

Según el valor del negocio y regularmente actualizada

Fijo en el plan de proyecto

Garantía de Calidad

Centrada en el Cliente

Centrada en el Proceso

Organización

Auto-organizada

Gestionada

El Estilo de Gestión

Descentralizado

Centralizado

Cambio

Las actualizaciones de Prioritized Product Backlog

Sistema formal de Gestión del Cambio

Liderazgo

Colaborativo, Líder Servicial

Mando y control

La Medición del Rendimiento

El valor del negocio

Plan de la Conformidad

Return on Investiment (ROI)

Al comienzo y a lo largo del proyecto

Al final del proyecto

Participación del Cliente

Alta durante todo el proyecto

Varía en función del ciclo de vida del proyecto

© 2014 SCRUMstudy.com

7

Los proyectos Scrum se completan de manera iterativa entregando valor a lo largo del ciclo de vida del proyecto. El beneficio del desarrollo iterativo es que permite la corrección a medida que todas las personas involucradas obtengan una mejor comprensión de lo que debe ser entregado como parte del proyecto, e incorporen lo aprendido de manera iterativa. Así, el tiempo y el esfuerzo requerido para alcanzar el punto final definitivo, se reduce considerablemente y el equipo produce entregables que se adaptan mejor al entorno empresarial.

Lanzamiento

Scrum vs Método Tradicional

© 2014 SCRUMstudy.com

8

Capítulo Visión de Agile y Scrum - Preguntas 1. ¿Cuál de las siguientes NO es una característica común de la gestión adaptativa de proyectos? A. Desarrollo iterativo del producto B. Alto esfuerzo en la planificación adelantada (al inicio del proyecto) C. Reduce el tiempo de lanzamiento al mercado D. Entrega del producto flexible 2. Usted es el CEO de una empresa que maneja cuatro proyectos diferentes. ¿En qué proyecto implementaría metodologías Ágiles? A. Construcción de un edificio de departamentos multifamiliares de 5 plantas con 6 departamentos por piso. B. Trabajo en la décima etapa de un proyecto de implementación a largo plazo de un software en el que los requerimientos del proyecto fueron claramente definidos y la entrega, hasta el momento, cumple con estos requerimientos. C. El desarrollo de un aplicativo de software para un cliente para un ejercicio de gestión del cambio que implica la identificación de las prácticas del estado actual y el desarrollo de una hoja de ruta para el proceso del estado futuro en función de la visión del equipo de gestión. D. La construcción de un automóvil en una fábrica basada en un prototipo desarrollado con anterioridad. 3. A. B. C. D.

¿Cuál de los siguientes NO es parte del Manifiesto Ágil? Promover a las personas sobre los procesos. Responder al cambio en lugar de hacer planes a largo plazo. Tener un equipo especializado en lugar de un equipo multifuncional. El software funcionando es más importante que la documentación extensa.

4. Como jefe de proyecto empleando prácticas Ágiles en su organización, ¿cuál de los siguientes principios NO emplearía? A. Empleados del negocio y técnicos deben trabajar juntos. B. Documentar todos los detalles de un nuevo software antes de permitir su lanzamiento. C. Ubicar a los equipos en un mismo lugar y promover la comunicación cara a cara. D. Recibir cambios de requerimientos, incluso tarde en el desarrollo. 5. A. B. C. D.

¿Cuál de los siguientes NO es verdadero con respecto a las metodologías Ágiles? Se enfoca en las personas en lugar de los procesos. Promueve la documentación mínima, a diferencia de la técnica de Cascada. Recomienda un estilo de liderazgo basado en comando y control. Se centra en la capacidad de adaptación del proyecto.

© 2014 SCRUMstudy.com

9

INFORMACIÓN GENERAL DE SCRUM Scrum es una de las metodologías ágiles más populares. Emplea un enfoque adaptativo e iterativo para gestionar proyectos y desarrollo de productos. Ha sido diseñada para ser una manera rápida, flexible y eficaz para ofrecer _____ significativo de forma _________ en todo el proyecto. El marco de Scrum, tal como se define en la Guía SBOK™, 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. 2.

Auto-organización —Este principio se centra en los miembros del equipo, quienes entregan un valor significativamente mayor cuando son auto-organizados, lo cual genera equipos muy comprometidos y con un alto nivel de responsabilidad; a su vez, esto produce un entorno innovador y creativo que es más propicio para el crecimiento.

3. Colaboración —Este principio se centra en las tres dimensiones básicas relacionadas con el trabajo colaborativo: conciencia, articulación y apropiación. 4. Priorización basada en el valor —Este principio pone de relieve el enfoque de Scrum para ofrecer el máximo valor de negocio, desde el principio del proyecto hasta su conclusión.

© 2014 SCRUMstudy.com

10

5. Time-boxing —Este principio describe cómo el tiempo es considerado como una restricción limitante en Scrum, y cómo se utiliza para ayudar a manejar eficazmente la planificación y ejecución del proyecto. 6. Desarrollo Iterativo — Este principio define el desarrollo iterativo y enfatiza cómo manejar mejor los cambios y crear productos que satisfagan las necesidades del Cliente. También delinea las responsabilidades del Product Owner y de la organización relacionadas con el desarrollo iterativo. 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 desarrrollo no puede manejar tales cambios. En cambio, Scrum es especialmente útil para proyectos complejos con gran ____________ en los cuales los pronósticos de largo plazo podrían conllevar a riesgos críticos. Scrum guía a través de la transparencia, inspección y adaptación para alcanzar los resultados más valiosos de negocio.

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

© 2014 SCRUMstudy.com

11

Procesos de Scrum Los procesos de Scrum abordan las actividades y el flujo específico de un proyecto Scrum. En total hay diecinueve procesos que se agrupan en cinco fases.

© 2014 SCRUMstudy.com

12

El término "Producto" en la Guía SBOK™ puede referirse a un Producto o, Servicio, o cualquier otra prestación. Scrum se puede aplicar de manera efectiva a cualquier proyecto en cualquier industriadesde proyectos pequeños o equipos con tan sólo seis miembros, hasta proyectos grandes y complejos con varios cientos de miembros por equipo.

© 2014 SCRUMstudy.com

13

¿Por qué utilizar Scrum?* Algunas de las ventajas principales de la utilización de Scrum en cualquier proyecto son: 1. ______________ — El Control del Proceso Empírico y la Entrega Iterativa hacen que los proyectos sean adaptables y abiertos a la incorporación de cambios. 2. ______________ —Todos los radiadores de información tales como el Scrumboard y el Sprint Burndown Chart son compartidos, lo que promueve un ambiente de trabajo abierto. 3. _________________ Continua — Se proporciona a través de los procesos: Ejecutar Reuniones Diarias y Demostrar y Validar. 4. ___________ Continua —Los entregables se mejoran progresivamente Sprint por Sprint a través del proceso de Mantenimiento del Product Backlog. 5. Entrega Continua de Valor—los procesos iterativos permiten la entrega continua de valor tan frecuentemente como el Cliente lo requiere a través del proceso Enviar los Entregables. 6. Ritmo Sostenible — Los procesos Scrum están diseñados de tal manera que las personas involucradas pueden trabajar a un mismo ritmo que, en teoría, se puede continuar indefinidamente. 7. Entrega Temprana de Alto Valor—El proceso de Crear el Product Backlog Priorizado asegura que los requisitos de mayor valor del Cliente sean los primeros en satisfacerse. 8. Proceso de Desarrollo Eficiente— El time-boxing y la reducción al mínimo el trabajo que no es esencial conduce a mayores niveles de eficiencia. 9. Motivación—Los procesos de Ejecutar la Reunión Diaria y la Retrospectiva del Sprint conducen a mayores niveles de motivación entre los empleados. 10. Resolución de Problemas de forma más Rápida— Colaboración y la coubicación de equipos multi-funcionales conducen a la resolución de problemas con mayor rapidez. 11. Entregables Efectivos—El procesos de Crear el Product Backlog Priorizado y revisiones periódicas después de la creación de entregables asegura entregas efectivas para el Cliente. 12. Centrado en el Cliente — El poner énfasis en el valor del negocio y tener un enfoque de colaboración con los interesados asegura un marco orientado al Cliente. 13. Entorno de Alta Confianza—Los procesos de Ejecutar la Reunión Diaria y la Retrospectiva del Sprint promueven transparencia y colaboración, dando lugar a un ambiente de trabajo de alta confianza, asegurando así una baja fricción entre los empleados. 14. Responsabilidad Colectiva—El proceso de Aprobar, Estimar y Comprometerse con Historias de Usuario permite que los miembros del equipo se sientan responsables del proyecto, así su trabajo tiene una mejor calidad. 15. Alta Velocidad—Un marco de colaboración que le permite a los equipos multi-funcionales altamente calificados alcanzar su potencial y alta velocidad. 16. Medio Ambiente Innovador—Los procesos Retrospectiva del Sprint y Retrospectiva del Proyecto crean un ambiente de introspección, aprendizaje y capacidad de adaptación que lleva a un entorno de trabajo innovador y creativo. *Reference: SBOKTM Guide 2013, p. 4-5

© 2014 SCRUMstudy.com

14

Capítulo Visión General Agile y Scrum - Preguntas 1. El control del proceso empírico es un principio de Scrum que: A. Es utilizado en casos en los que las entradas están claramente definidas. B. Se centra en proporcionar control a través de inspecciones y adaptaciones frecuentes de los procesos que están perfectamente definidos. C. Se utiliza en situaciones en las que los procesos generan salidas impredecibles e irrepetibles. D. Se utiliza cuando una entrada particular ofrece siempre una salida específica. 2. A. B. C. D.

Todos los siguientes son parte de los principios del Scrum EXCEPTO: La auto-organización Time-boxing Priorización basada en valor Control de procesos definidos

3. A. B. C. D.

¿En cuál de los siguientes entornos proyectos Scrum NO son aplicables? El desarrollo de productos de vanguardia Alta frecuencia de cambio de requerimientos Mercados volátiles y hipercompetitivos Ninguna de las anteriores

4. A. B. C. D.

¿Cuál es el resultado respecto al desarrollo de productos utilizando Scrum? Transparencia con todo el Equipo de Scrum y con los interesados Ambiente adaptativo de desarrollo de producto Las características que ofrecen el máximo valor comercial se desarrollan primero Todas las anteriores

5. La entrega priorizada en Scrum significa que: A. Las características que son las más simples y no requerirían mucha participación por parte del equipo se completarán primero. B. Las características con la menor o interdependencia nula se completarán primero para asegurar la entrega sin problemas ni interrupciones. C. Las características que proporcionan el máximo valor comercial se completarán primero. D. Las características se desarrollan de acuerdo al orden de llegada, las que primero entran, son las que primero salen.

© 2014 SCRUMstudy.com

15

LOS 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 ____________ 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.

Core Roles Hay tres Core Roles (roles/funciones principales) en Scrum que son los responsables de cumplir con los objetivos del proyecto. 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.

© 2014 SCRUMstudy.com

16

Core Role: Product Owner (Dueño del Producto) El Product Owner representa a los interesados y es responsable de asegurar que el Equipo Scrum entregue valor, a través del producto, al proyecto. El Product Owner escribe los requerimientos de negocio en la forma de ________________ con apoyo de los miembros del Equipo Core Scrum; también gestiona el Product Backlog (cartera de pendientes) en el proceso Priorizar el Product Backlog. En algunos casos, los miembros del Equipo Scrum podrían escribir las User Stories (Historias de Usuario) bajo la supervisión del Product Owner. El Product Owner es también responsable de asegurar la comunicación clara de las funcionalidades del producto al Equipo Scrum, por lo que también es conocido como la ___________________. 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 __________________________ 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. Para cualquier proyecto Scrum, el cliente podría ser: 

Interno (dentro de la misma organización)



Externo (fuera de la organización)

La siguiente tabla resume las responsabilidades del Product Owner en los diferentes procesos de Scrum.

© 2014 SCRUMstudy.com

17

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 Entregas (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 que se harán en un Sprint Ayuda al Equipo Scrum a comprender las Historias de Usuarios para que puedan estimar.



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



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



Aclara los requisitos al Equipo Scrum mientras crea el Sprint Backlog

Create Deliverables



Aclara los Requisitos del Negocio al Equipo Scrum

Groom Prioritized Product Backlog



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 Entregas (Releases) y la Priorización del Product Backlog

Create User Stories

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

Demonstrate and Validate Sprints

Ship Deliverables Retrospect Project

 

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



Participa en las Reuniones de Retrospectiva del Proyecto

© 2014 SCRUMstudy.com

18

Core Role: Scrum Master La responsabilidad principal del Scrum Master es asegurarse que los procesos Scrum sean aplicados correctamente por todos los miembros del Equipo Core Scrum, incluyendo al Product Owner. El Scrum Master es la persona responsable de garantizar que la gestión de proyectos avance sin problemas y que los miembros del Equipo Scrum tengan todas las herramientas necesarias para hacer su trabajo. El rol del Scrum Master se basa en el concepto de ________________ en el cual los líderes logran resultados atendiendo a las necesidades de aquellos a quienes lideran. De la misma forma que existe un rol de Scrum Master en un proyecto, podría haber un Scrum Master del Programa en un Programa, o un Scrum Master del Portafolio en un Portafolio. La tabla resume las responsabilidades del Scrum Master en los diferentes procesos de Scrum.

© 2014 SCRUMstudy.com

19

Procesos

Identify Scrum Master and Stakeholder(s)

Form Scrum Team

Responsabilidades del Scrum Master



Ayuda a identificar a los interesados del proyecto

 

Ayuda a determinar los miembros del Equipo Scrum Ayuda a desarrollar el Plan de Colaboración y el Plan para la Formación del Equipo Asegura que los recursos de respaldo estén disponibles para el funcionamiento del proyecto sin problemas



Develop Epic(s)



Facilita la creación de Epic(s) y Personas

Create Prioritized Product Backlog



Ayuda al Product Owner en la creación del Product Backlog Priorizado y en la definición de los Criterios de Terminado



Coordina la creación del Cronograma de Planificación de las Entregas (Releases) Determina el duración del Sprint con el Product Owner

Conduct Release Planning

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

Create Deliverables

Conduct Daily Standup Groom Prioritized Product Backlog Convene Scrum of Scrums Demonstrate and Validate Sprints Retrospect Sprint Retrospect Project

 

Apoya al Equipo Scrum en la creación de Historias de Usuarios y sus Criterios de Aceptación



Facilita reuniones del Equipo Scrum para estimar y Crear Historias de Usuarios



Facilita al Equipo Scrum en la creación de la Lista de Tareas para el siguiente Sprint



Ayuda al Equipo Scrum en la estimación del esfuerzo necesario para completar las tareas acordadas para el Sprint



Apoya al Equipo Scrum en el desarrollo del Sprint Backlog y el Gráfico Sprint Burndown



Apoya al Equipo Scrum en la creación de los Entregables (Deliverables) acordados para el Sprint Ayuda a actualizar el Scrumboard y el Impediment Log

 

Asegura que el Scrumboard y el Impediment Log permanezcan actualizados



Facilita la reuniones de revisión del Product Backlog



Se asegura que los Incidentes que afectan al Equipo Scrum se discutan y resuelvan



Facilita la presentación de los Entregables ya completados por el Equipo Scrum para la aprobación del Product Owner



Asegura que exista un ambiente ideal para el Equipo Scrum en los sucesivos Sprints



Representa al Equipo Core de Scrum (Scrum Core Team) para proporcionar lecciones del proyecto actual, si es necesario

© 2014 SCRUMstudy.com

20

Core Role: Scrum Team- Equipo Scrum El Equipo Scrum es un grupo o equipo de personas que son responsables de la comprensión de los requerimientos de negocio especificados por el Product Owner, de la estimación de Historias de Usuarios y de la creación de los _________________ del proyecto.

Características del Equipo Scrum Auto-organizados: 

Les permiten a los miembros del equipo enfocarse en los resultados deseados del Sprint.



El equipo tiene un conjunto definido de objetivos durante cada Sprint y la flexibilidad para dar cuenta de un cambio en los objetivos antes de comenzar el siguiente Sprint.



Garantiza que los miembros del Equipo Scrum decidan por sí mismos la forma de hacer el trabajo del proyecto sin la microgestión de las tareas llevadas a cabo por un jefe.

Multi-funcionales: 

El uso de equipos multi-funcionales también se asegura de que todas las habilidades y conocimientos necesarios para llevar a cabo el trabajo del proyecto existan dentro del equipo.



Este modelo de equipo en Scrum está diseñada para optimizar la flexibilidad y la productividad.



Un equipo multi-funcional está más enfocado en un objetivo común.

Coubicación y comunicación cara a cara: 

Scrum permite la creación de equipos auto-organizados fomentando la coubicación de todos los miembros y recomienda la comunicación cara a cara entre todos los miembros.



Un equipo coubicado conformado por expertos funcionales que colaboran para alcanzar un objetivo común tendrá mayor probabilidad de éxito que un equipo que trabaja separado físicamente de acuerdo a la función que realiza.



Cuando un Equipo Scrum necesita ser distribuido, el Scrum Master debe garantizar que las técnicas de comunicación eficaces estén disponibles para que los equipos puedan autoorganizarse y trabajar con eficacia.

Entrega Iterativa de Producto: 

Los equipos Scrum entregan productos de forma iterativa e incremental, maximizando oportunidades para la retroalimentación.



Las entregas incrementales de producto “Terminados” asegura estas versiones se encuentren disponibles para comercializarse.

La siguiente tabla muestra las responsabilidades del Equipo Scrum durante los diferentes procesos de Scrum.

© 2014 SCRUMstudy.com

21

Proceso

Form Scrum Team Develop Epic(s) Create Prioritized Product Backlog

Conduct Release Planning

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

Create Deliverables

Responsabilidades del Scrum Team 

Brinda información para la creación del Plan de Colaboración y para el Plan para la Formación del Equipo



Se asegura de tener un buen entendimiento de los Epic(s) y de Personas.



Se asegura de entender las Historias de Usuario del Product Backlog Priorizado.



Acuerda con los miembros del Equipos Core Scrum la duración del Sprint. Solicita aclaración de los nuevos productos o cambios al producto existente en el Product Backlog Priorizado y Refinado.

 

Brinda información al Product Owner para la creación de Historias de Usuario.

 

Estima las Historias de Usuario aprobadas por el Product Owner. Se compromete ha implementar algunas Historias de Usuario en un Sprint.



Elabora la Lista de Tareas basadas en las Historias de Usuario y sus dependencias.



Estima las tareas identificadas y si es necesario actualizar la Lista de Tareas.



Elabora el Sprint Backlog y el gráfico Sprint Burndown

 

Crea Entregables. Identifica riesgos e implementa acciones de mitigación a los riesgos si es necesario. Actualiza el Registro de Impedimentos y sus dependencias.

 

Conduct Daily Standup

  

Groom Prioritized Product Backlog Convene Scrum of Scrums Demonstrate and Validate Sprints



Participa en las reuniones de refinamiento y repriorización (si es necesario) del Product Backlog.



Brinda información al Scrum Master para las reuniones de Scrum de Scrums.



Presenta los entregables completos al Product Owner para su aprobación.



Identifica oportunidades de mejora, si existiesen, del Sprint que acaba de finalizar y acuerda las acciones de mejora para llevarlas a cabo el siguiente Sprint.



Participa en la reunion de Retrospectiva del Proyecto.

Retrospect Sprint

Retrospect Project

Actualiza el gráfico Sprint Burndown, el Scrumboard y el Registro de Impedimentos. Discute problemas que enfrentan los miembros y busca soluciones para motivar al equipo. Identifica riesgos si existiesen. Presenta solicitudes de cambio si se requiere.

© 2014 SCRUMstudy.com

22

Etapas de Desarrollo de Equipos El método de Scrum inicialmente pueden parecer muy diferente y difícil para un nuevo Equipo Scrum. Un nuevo Equipo Scrum, al igual que cualquier otro equipo nuevo, por lo general se desenvuelve a través de un proceso de cuatro etapas. Este proceso se conoce como Modelo de Dinámica de Equipo de Tuckman (Tuckman, 1965). Las cuatro etapas del modelo son las siguientes: ____________________ Este a menudo se experimenta como un escenario divertido porque todo es nuevo y el equipo aún no ha encontrado ninguna dificultad con el proyecto. Storming (Turbulencia) Durante esta etapa, el equipo trata de cumplir con el trabajo. Sin embargo, puede encontrar conflictos de poder y con frecuencia hay caos o confusión entre los miembros del equipo. ____________________ En esta fase es cuando el equipo comienza a madurar, resolver sus diferencias internas y encontrar soluciones para así trabajar juntos. Performing (Desempeño) Durante esta etapa, el equipo está unido y opera en su nivel más alto en términos de rendimiento. Los miembros se han convertido en un equipo eficiente de profesionales que son consistentemente productivos.

La siguiente figura muestra las etapas en el Modelo de Tuckman de Desarrollo de Equipo.

Etapas de Tuckman de Desarrollo de Equipos

© 2014 SCRUMstudy.com

23

Selección del Equipo El Equipo Scrum es la base de cualquier Proyecto de Scrum y el tener a los miembros adecuados para el equipo es vital para la entrega exitosa del proyecto. Los miembros del Equipo Scrum son especialistas generalistas ya que cuentan con conocimiento de diversos campos y son expertos en al menos uno. Más allá de la experiencia en la materia, son las habilidades interpersonales de cada miembro del equipo que determinará el éxito de los equipos auto-organizados. Los miembros ideales del Equipo Scrum son independientes, auto-motivados, enfocados al cliente y tienen un sentido alto de responsabilidad y de colaboración. Cuando se selecciona el equipo, un aspecto importante es crear _________ para cada miembro del equipo. Esto asegura evitar que haya una disminución importante de la productividad debido a la pérdida de miembros críticos.

Ventajas de Equipos Multi-funcionales Scrum utiliza el enfoque de equipos multi-funcionales porque este brinda las siguientes ventajas: 

Toma rápida de decisiones: Un equipo multi-funcional es pequeño y está conformado por expertos que pueden alcanzar un objetivo común más rápido que en un proyecto tradicional donde los equipos estás orientados a la función que ejecutan.



Mejor comunicación: Los equipos multi-funcionales generalmente están _______ lo que permite tener una comunicación más fluida cara a cara entre los miembros del equipo. Así el equipo interactúa regularmente haciendo posible que se comparta el conocimiento.



Orientado al objetivo: Los equipos multi-funcionales en Scrum están enfocados totalmente al resultado deseado. El Equipo Scrum ha definido un grupo de objetivos durante un Sprint y es suficientemente flexible para realizar cambios en los objetivos antes del siguiente Sprint.



Propiedad colectiva: El equipo como un todo es responsable de la entrega de resultados, y el éxito o el fracaso del proyecto es de todo el equipo.



Innovación continua: El uso de expertos en varios campos en el equipo multi-funcional permite el intercambio de ideas, de esta forma se fomenta el pensamiento creative.

Non- core Roles Los roles non-core o no esenciales son las funciones que no son obligatorias para el proyecto Scrum, y pueden incluir miembros que no están involucrados directamente o continuamente con el proceso Scrum. Sin embargo, los roles no esenciales pueden jugar un papel importante en el proyecto. Los Roles no Esenciales pueden incluir: 1. Interesados Es un término colectivo que incluye a los Clientes, los usuarios y patrocinadores, que a menudo interactúan con el Product Owner, Scrum Master y Equipo Scrum para proporcionarles información y para ayudar en la creación del producto, servicio, o cualquier otro resultado del proyecto. Los interesados influyen en el proyecto a lo largo del desarrollo del proyecto. También pueden desempeñar un papel en los procesos importantes de Scrum tales como: Desarrollo de Epic(s), Crear Product Backlog Priorizados, Ejecutar la Planificación de la Entrega, Retrospectiva del Sprint.

© 2014 SCRUMstudy.com

24



Cliente El Cliente es la persona o la organización que adquiere el producto, servicio, o cualquier otro resultado del proyecto. Para cualquier organización, dependiendo del proyecto, pueden haber Clientes internos (es decir, dentro de la misma organización) o Clientes externos (es decir, fuera de la organización).



Usuarios El usuario es el individuo o la organización que utiliza directamente el Producto, servicio, o cualquier otro resultado del proyecto. Al igual que los Clientes, para cualquier organización pueden haber usuarios internos y externos. También, en algunos proyectos los Clientes y los usuarios pueden ser los mismos.



Patrocinador El patrocinador es la persona o la organización que provee recursos y apoyo para el proyecto. El patrocinador es también el interesado, a quien todos le deben rendir cuentas al final. A veces, la misma persona u organización pueden desempeñar múltiples funciones – el interesado, por ejemplo, el patrocinador y el cliente puede ser el mismo.

2. Vendedores Los vendedores incluyen a individuos u organizaciones externas que ofrecen productos y/o servicios que no están dentro de las competencias básicas de la organización del proyecto. 3. Cuerpo de Asesoramiento de Scrum (SGB) es un rol _______. Por lo general, se compone de un grupo de documentos y/o un grupo de expertos que normalmente están involucrados en la definición de los objetivos relacionados con la calidad, las regulaciones gubernamentales, la seguridad y otros parámetros importantes de la organización. Estos objetivos guían la labor llevada a cabo por el Product Owner, Scrum Master y Equipo Scrum. El Cuerpo de Asesoramiento de Scrum también ayuda a capturar las mejores prácticas que se deben utilizar en todos los proyectos Scrum de la organización. El Cuerpo de Asesoramiento de Scrum no toma decisiones relacionadas con el proyecto. En cambio, actúa como una consultoría o una estructura de orientación para todos los niveles de jerarquía en la organización de proyectos - Portafolio, Programa y proyecto. Los Equipo Scrums tienen la opción de solicitar ayuda al Scrum Guidance of Body sobre cualquier asesoramiento requerido.

© 2014 SCRUMstudy.com

25

Capítulo Roles de Scrum - Preguntas 1. ¿Cuál de los siguientes es un rol esencial (core) de Scrum? A. B. C. D.

Product owner Interesado Patrocinador del proyecto Administrador del proyecto

2. ¿Quién de los siguientes es responsable de proporcionar al Equipo de Scrum de un ambiente favorable para la creación de entregables? A. B. C. D.

Scrum Master Product Owner Cuerpo de Asesoramiento de Scrum (SGB) Interesados externos

3. ¿Quién de los siguientes es el responsable de crear una conciencia de las prácticas de Scrum entre los miembros del Equipo de Scrum? A. B. C. D.

Scrum Master Product Owner Equipo de Scrum Cuerpo de Asesoramiento de Scrum (SGB)

4. ¿Quién de los siguientes es responsable de lograr el máximo valor de negocio del proyecto? A. B. C. D.

Scrum Master Product Owner Equipo Scrum Las partes interesadas externas

5. ¿Quién de los siguientes es el responsable de crear los entregables en el proceso Crear Entregables? A. B. C. D.

Jefe Scrum Master Product Owner del Portafolio Líder Equipo Scrum Equipo Scrum

© 2014 SCRUMstudy.com

26

6. Las ventajas de utilizar un equipo multi-funcional son: A. Mejora de la comunicación entre los miembros del equipo. B. Toma de decisiones más rápida. C. Responsabilidad individual asignada a cada miembro del equipo en función de su experiencia. D. Ambos A y B.

7. ¿Quién de los siguientes es el responsable de decidir sobre los criterios de aceptación para diversas tareas? A. Scrum Master B. Product Owner C. Líder Equipo Scrum D. Equipo Scrum 8. ¿Quién de los siguientes representa la voz del cliente? A. Jefe Scrum Master B. Product Owner C. Líder Equipo Scrum D. Los miembros del equipo Scrum

9. Miguel es responsable de resolver los conflictos entre los miembros del equipo de Scrum. ¿Qué rol está ejerciendo en un proyecto Scrum? A. Scrum Master B. Product Owner C. Líder Equipo Scrum D. Equipo Scrum

© 2014 SCRUMstudy.com

27

FASES 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 ________ 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 Meeting) se llevan a cabo durante el _______, donde Los miembros del Equipo Scrum reportan el trabajo avanzado, el trabajo que se proponen terminar y los impedimentos que están afrotando.

•

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

Un proyecto Scrum tiene las siguientes cinco fases: 1. Iniciar 2. Planear y Estimar 3. Implementar 4. Revisión y Retrospectiva 5. Lanzamiento

© 2014 SCRUMstudy.com

28

Fase

Initiate (Iniciar)

Plan and Estimate (Planear y Estimar)

Implement (Implementar)

Review and Retrospect (Revisión y Retrospectiva)

Release (Lanzamiento)

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

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 Entregas (Release)

7. Crear Historias de Usuarios 8. Aprobar, Estimar y Comprometerse con Historias de Usuarios 9. Crear Tareas 10. Estimar el Trabajos 11. Crear la Lista de Pendientes de Sprint 12. Crear Entregables 13. Realizar el Standup Diario 14. Mantener la Lista de Pendientes del Producto Priorizada

15. Convocar Scrum de Scrums 16. Demostrar y Validar el Sprint 17. Realizar la Retrospectiva del Sprint

18. Enviar los Entregables 19. Realizar la Retrospectiva del Proyecto

© 2014 SCRUMstudy.com

29

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 Entregas (Release).

Proceso 1: Crear la Visión del Proyecto En este proceso, el Caso de Negocio es revisado para crear un Declaración de la Visión del Proyecto que servirá de inspiración y proporcionará el enfoque de todo el Proyecto. El Product Owner es el responsable de crear la visión del proyecto.

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)

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

4. Análisis de Brechas

Caso de Negocio del Proyecto (Project Business Case) * Un caso de negocio (business case) puede ser un documento bien estructurado o simplemente una declaración verbal que expresa la razón para iniciar un Proyecto. Puede ser formal y detallado, o informal y breve. Independientemente del formato, a menudo incluye información sustancial sobre los antecedentes del Proyecto, los objetivos del negocio y los resultados deseados, un análisis FODA (SWOT), Análisis de Brechas, una lista de los Riesgos identificados, y las estimaciones de tiempo, el esfuerzo y costo. El Proyecto se inicia con la presentación del Caso de Negocio. El caso de negocio se presenta a los interesados y patrocinadores para que comprendan los beneficios de negocio esperados del Proyecto. Finalmente los patrocinadores confirman que van a proporcionar los recursos financieros para el Proyecto.

© 2014 SCRUMstudy.com

30

Reunión de la Visión del Proyecto Reunión de la Visión del Proyecto es una reunión con los interesados del Programa, el Product Owner del Programa, el Scrum Master del Programa y el jefe del Product Owner. Ayuda a identificar el contexto empresarial, Requisitos del Negocio y las expectativas de los interesados con el fin de desarrollar una Declaración de la Visión del Proyecto eficaz. Scrum cree en la participación y colaboración cercana con todos los representantes de las compañía para que estén convencidos de apoyar al Proyecto.

Product Owner Identificado Uno de los resultados de este proceso es identificar al Product Owner. El Product Owner es la persona responsable de lograr el valor máximo empresarial para el Proyecto. É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 la voz del Cliente. Cada Equipo Scrum tendrá un Product Owner designado. Un pequeño Proyecto puede tener sólo un Product Owner, mientras que los Proyectos más grandes pueden tener varios. Estos Product Owners son responsables de la gestión del Product Backlog Priorizado. Ellos escriben los Historias de Usuarios y gestionan el mantenimiento del Product Backlog.

Declaración de la Visión del Proyecto El resultado clave del proceso Crear la Visión del Producto es la Declaración de la Visión del Proyecto. Una buena visión del Proyecto 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. El Declaración de la Visión del Proyecto no debería ser muy específico y debe ser flexible. Es posible que el conocimiento actual sobre el Proyecto esté basado en suposiciones que luego van a cambiar conforme avanza el Proyecto, por lo que es importante que la visión del Proyecto sea lo suficientemente flexible como para adaptarse a estos cambios. La visión del Proyecto debe centrarse en el problema y no en la solución.

© 2014 SCRUMstudy.com

31

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.

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*

Un proyecto Scrum empieza cuando una necesidad de negocio y la visión son identificadas; entonces se puede continuar con la identificación de los interesados del proyecto tales como el patrocinador, usuarios finales, proveedores, etc, quienes estarán impactados por la necesidad de negocio o ayudarán a llevarla a cabo. Por lo tanto, una vez que la Visión del Proyecto esté lista, el Product Owner procede a identificar todos los interesados del proyecto. Dentro de este proceso, el Product Owner identifica al Scrum Master, quien ayuda al Product Owner a cumplir con la Visión del Proyecto siendo el jefe facilitador y mentor del Equipo Scrum. 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 : ______________, 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 Scrum Master y la identificación de los interesados adecuados es crucial para el éxito de cualquier proyecto. En algunos proyecto puede haber pre-condiciones que estipulen determinados miembros del equipo y sus roles. Cuando hay flexibilidad en la elección del Scrum Master, se deben considerar los siguientes criterios de selección:

© 2014 SCRUMstudy.com

32

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 En la identificación de 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 su ciclo de vida. Scrum Master Identificado Un Scrum Master es un facilitador y Líder Servicial que se asegura de que el Equipo Scrum esté dotado de un ambiente propicio para completar el Proyecto con éxito. El Scrum Master guía, facilita y enseña prácticas de Scrum a todos los involucrados en el Proyecto; elimina impedimentos que encara el equipo; y asegura que se estén siguiendo los procesos de Scrum. Es la responsabilidad del Product Owner identificar al Scrum Master para un proyecto Scrum. Interesados Identificados Los interesados, término colectivo que incluye a los Clientes, los usuarios y los patrocinadores, quienes con frecuencia interactúan con el Equipo Core Scrum, influyen en el Proyecto durante todo el proceso de desarrollo de Productos.

© 2014 SCRUMstudy.com

33

Proceso 3: Formar el Equipo Scrum Form Scrum Team Uno de los procesos más importantes en el flujo Scrum es la formación del Equipo Scrum, porque éste es el que crea los entregables del proyecto, y con estos se logra satisfacer la Visión del Proyecto. El Equipo Scrum es también conocido como el Equipo de __________. Un Equipo ideal Scrum tiene entre 6 a 10 miembros. 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.

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. Entrenamiento y Costos de capacitación 4. 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

El Product Owner y el Scrum Master colaboran para formar el Equipo Scrum. El Equipo Scrum es formado teniendo en cuenta la Visión del Proyecto porque el tipo de proyecto y el tipo de industria son factores cruciales en la selección de expertos técnicos. Sin embargo el Product Owner y el Scrum Master podría considerar otros factores como los requerimientos de personal, disponibilidad y compromiso de las personas y la matriz de destrezas requeridas. Una vez que el Equipo Scrum es seleccionado, el Equipo Core Scrum (Product Owner, Scrum Master y Equipo Scrum) está completo. La salida más importante de este proceso es un equipo ____________ y ________________. Los miembros ideales del Equipo Scrum son independientes, auto-motivados, se enfocan en el Cliente, y tienen un alto sentido de responsabilidad y colaboración. El equipo debe ser capaz de fomentar un ambiente de reflexión independiente y de tomar decisiones con el fin de extraer los mayores beneficios de la estructura.

© 2014 SCRUMstudy.com

34

Objetivos de un equipo auto-organizado

Proceso 4: Desarrollo de Epic(s) Develop Epic(s) Es el cuarto proceso de la fase de Incio. En terminología Scrum, un Epic es definido cómo una ________________ no refinada, la cual es generalmente muy grande para ser completada en un solo Sprint, 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. El Equipo Core Scrum empieza escribiendo Epics basados en la Visión del Proyecto y podría considerar otros factores como Solicitudes de Cambio aprobados y no aprobados, Leyes y Regulaciones, Contratos, etc. 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. Las dos salidas principales de este proceso son los ______ y ________. Personas son complementos a 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 no utilizan directamente el producto final.

© 2014 SCRUMstudy.com

35

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. Contractos 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 * Campos Aprobados Riesgos Identificados

Reunión de Grupo de Usuarios La Reunión de Grupo de Usuarios involucre a los interesados del proyecto, principalmente los usuarios o Clientes del Producto. Ellos proporcionan al Equipo Core de Scrum información de primera mano acerca de las expectativas del usuario. Esto ayuda en la formulación de los Criterios de Aceptación para el Producto y proporciona información valiosa para el desarrollo de Epics. Creación de una Persona Esto implica la asignación al personaje de un nombre ficticio y preferentemente una foto. A la Persona se le incluirán atributos muy específicos como su edad, género, nivel de educación, entorno, intereses y metas. 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.

© 2014 SCRUMstudy.com

36

Proceso 5: Crear la Lista de Requerimientos Pendientes del Producto Create Prioritized Product Backlog Luego que el Equipo Core Scrum crea los Epics y Personas, el Product Owner crea la Lista Priorizada de Pendientes del Producto (Prioritized Product Backlog), la cual incluye una lista de características y funcionalidades necesarias para cumplir con los objetivos del proyecto. Esta lista es priorizada donde los elementos de mayor valor, es decir los que dan el máximo valor _________, tienen la ________ 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 inicial Product Backlog Priorizado. El Product Backlog Priorizado generalmente contiene Epics, pero a veces también contiene información relacionada a hallazgos importantes como problemas reportados, requerimientos funcionales y no funcionales, etc. Los elementos del Product Backlog Priorizado tienen asignadas estimaciones de alto nivel para indicar el esfuerzo en tiempo y recursos que son necesarios para implementarlos basados en características como el tamaño, complejidad y experiencia requerida.

© 2014 SCRUMstudy.com

37

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

La priorización tienen en cuenta tres factores principales: valor, riesgo e incertidumbre, y dependencias. El Equipo Core Scrum podría utilizar varios métodos de priorización como los mencionados a continuación:  Análisis Kano : El análisis Kano fue desarrollado por Noriaki Kano (1984) , Esta técnica puede ser utilizada para clasificar las preferencias del cliente en cuatro categorías, a las cuales nos referiremos como Exciters/ Delighters, Satisfiers, Dissatisfiers e Indifferent. o Exciters/Delighters: Funcionalidades nuevas o de alto valor para el cliente. o Satisfiers: Funcionalidades que ofrecen valor al cliente. o Dissatisfiers: Funcionalidades que, si no están presentes, probablemente causen que el cliente esté disgustado con el producto, sin embargo no afecta el nivel de satisfacción si ellos están presentes. o Indifferent: Funcionalidades que no afectan al cliente de ninguna forma y deben ser eliminadas.

© 2014 SCRUMstudy.com

38

 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.  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. Criterios de Terminado (“Done”) Es un conjunto de reglas que se aplican a todas los Historias de Usuarios. Una definición clara de “Done” es crítica, ya que elimina la ambigüedad de los requisitos y ayuda a que el equipo se adhiera a las normas de calidad obligatorias. Esta definición se utiliza para crear los Criterios de Terminado, que son un resultado del proceso de Crear la Lista de Requerimientos Pendientes del Producto. Una Historia de Usuario se considera Terminada (“Done”) cuando se le muestra y es aprobada por el Product Owner que juzga sobre la base de los Criterios de Terminado y los Criterios de Aceptación de la Historia del Usuario.

© 2014 SCRUMstudy.com

39

Proceso 6: Realizar la Planificación de los Entregables Conduct Release Planning En este proceso, el Equipo Core de Scrum trabaja elaborando el Cronograma de Planificación de los Entregables (Release Planning Schedule) para entregar incrementos de producto a los interesados. El Cronograma de Planificación de los Entregables indica qué entregables serán liberados a los clientes, junto con los intervalos planeados y las fechas de entrega. También, el Equipo Core de Scrum también define la duración del Sprint para el proyecto. 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 los Entregables 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. El Cronograma de Planificación de los Entregables debe ser planeado de tal manera que se asegure que cada entrega dé valor significativo al cliente. Cada Sprint debe tener una funcionalidad potencialmente comercializable como salida; y la fecha de implementación de este entregable del Sprint es determinada en el Cronograma de Planificación de los Entregables. 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 requirimientos estables, donde los Sprints puede ser ampliados a 6 semanas.

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 *

© 2014 SCRUMstudy.com

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

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 Este es el primer proceso en la fase de Planear y Estimar. Una Historia de Usuario (User Story) es una declaración que expresa una funcionalidad deseada de un usuario. Normalmente esta es desglosada en bloques de tareas secuenciales. Las Historias de Usuario son importantes para el Equipo Core de Scrum y para los interesados porque ayudan a mejorar la comunicación entre ambos grupos. Los requerimientos expresados en Historias de Usuario son fáciles de entender y permiten tener mejor estimaciones. 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. A veces, el Equipo Core de Scrum trabaja en el desarrollo de “themes”. Un Theme es un grupo de Historias de Usuario relacionadas. Estos contienen uno o más Epics. Muchos Themes puede ser asociados a un producto, pero un Theme no puede ser relacionado con más de un producto al mismo tiempo. La responsabilidad de crear las Historias de Usuario recae en el _________. 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. El Equipo Core de Scrum tiene que asegurar que los requerimientos de negocio del cliente serán convertidos en requerimientos funcionales que el desarrollador pueda entender fácilmente para implementarlos. Por lo tanto, el Equipo Core de Scrum debe ser experto escribiendo Historias de Usuario que den valor, sean estimables y factibles. Para dominar la habilidad de crear buenas Historias de Usuario se requiere práctica y tiempo; sin embargo el Equipo Core de Scrum puede acortar ese tiempo asistiendo a Talleres para Escribir Historias de Usuario. El Equipo Scrum podría seguir el modelo INVEST para crear mejores Historia de Usuario. INVEST es un acrónimo que significa: Independent, Negotiable, Valuable, Estimable, Small y Testable.

 Independent (Independiente) — Cada Historia de Usuario debe ser independiente de las otras. La interdependencia de historias puede causar problemas en la estimación y la priorización.  Negotiable (Negociable) — Una Historia de Usuario debería tener una descripción corta sin muchos detalles. Por lo que se puede conversar y negociar con el cliente.  Valioso (Valuable) — Cada Historia de Usuario debe dar valor al cliente. Para asegurar que la historia sea valiosa, el cliente debe estar involucrado en su escritura.  Que se puede Estimar (Estimable) — La Historia de Usuario debe ser fácil de estimar por parte de los desarrolladores, así ellos no tendrán dificultades en la priorización y planificación.  Pequeño (Small) — Una Historia de Usuario bien escrita debe ser pequeña en esfuerzo. Si se requiere mayor esfuerzo existe alta probabilidad de tener errores en la estimación y el alcance.  Verificable (Testable) — Para confirmar que una Historia de Usuario está Terminada, es necesario que sea verificable. Algo que no puede ser verificado no debería ser desarrollado, porque no podrá ser confirmado como Terminado. Por ejemplo: “Como usuario, yo quiero que mi trabajo sea fácil, así este proceso no debería ser complicado.” esta historia de usuario no es verificable. Una Historia de Usuario nos muestra tres características de un requerimiento: Quién, Qué y Cómo. Los requerimientos expresados como Historias de Usuario son enunciados cortos, simples y fáciles de entender.

© 2014 SCRUMstudy.com

41

El formato de una Historia de Usuario es el siguiente: Como deseo para . Junto con las Historias de Usuario, el Equipo Core Scrum escribe los Criterios de Aceptación. Las Historias de Usuario son a veces subjetivas, por lo que los Criterios de Aceptación brinda la objetividad requerida para las Historias de Usuario para ser consideradas como Terminadas o no Terminadas durante la Revisión de un Sprint. Los Criterios de Aceptación ayudan al equipo a entender qué se espera de una Historia de Usuario, eliminan la ambigüedad de los requerimientos y ayuda a alinear expectativas. El Product Owner define y comunica el ________________ al Equipo Scrum. En los Sprint Review Meetings, el Critero de Aceptación brinda el contexto para que el Product Owner decida si la Historia de Usuario ha sido completada satisfactoriamente. Es importante, y es responsabilidad del Scrum Master, asegurar que el Product Owner no cambie los Criterios de Aceptación de una Historia de Usuario, mientras este se esté ejecutando, que ya está comprometida a un Sprint,. .

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

© 2014 SCRUMstudy.com

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

42

Proceso 2: Aprobar, Estimar y Comprometerse con las Historias de Usuarios Approve, Estimate, and Commit User Stories Después que las Historias de Usuarios son creadas, tienen que ser aprobadas por el Product Owner, estimadas por el Equipo Scrum, este también se compromete a desarrollar un conjunto de Historias de Usuarios. Approve

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.

Estimate

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 y el tiempo con precisión es un aspecto crítico en cualquier organización para garantizar una buena experiencia en la entrega del proyecto para el cliente. Sin embargo, las estimaciones, por definición, no son _________ . La precisión de la estimación varia de acuerdo a la complejidad del proyecto, el tamaño, disponibilidad del equipo, volatilidad de los requerimientos, etc. Scrum trata de asegurar una mejor estimación usando actividades de estimación de equipos y métodos de comparación relativas.

Commit

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; así, estas Historias de Usuario aprobadas, estimadas y comprometidas forman parte del Sprint Backlog.

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

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 *

Algunas herramientas conocidas que se pueden utilizar para este proceso son: Wideband Delphi Es una técnica de estimación grupal para determinar cuánto trabajo está involucrado y cuánto tiempo tomará completarlo. Los participantes de forma anónima proveen estimaciones de cada funcionalidad, y estas estimaciones iniciales son graficadas en un cuadro. El equipo entonces discute sobre los factores que influenciaron en sus estimations y se procede a realizar una segunda ronda de estimación. Este proceso se repite hasta que el estimado de los participantes

© 2014 SCRUMstudy.com

43

converja y se llegue a un consenso en el estimado final. La información de cada participantes se recolecta de forma que se evite el problema de pensamiento de grupo (group think). Planificación Poker (Planning Poker) También llamada Estimación Poker, es una forma de aplicar Wideband Delphi. Es una técnica de estimación donde se utiliza el consenso para estimar tamaños relativos de Historias de Usuario o el esfuerzo requerido para crearlos. En Planificación Poker, a cada miembro se le asigna una baraja de cartas, cada carta está numerada en una secuencia. Estos números representan la complejidad del problema, en términos de tiempo o esfuerzo. El Product Owner escoge una Historia de Usuario del Product Backlog Priorizado y lo presenta al equipo. Los miembros del Equipo Scrum evalúan la Historia de Usuario y tratan de entenderla mejor antes de dar su estimación para desarrollarla. Entonces cada miembro elige una carta de la baraja que represente su estimado para la Historia de Usuario. Si la mayoría o todos los miembros del equipo eligen la misma carta, entonces esta será la estimación de la Historia de Usuario. Si no hay consenso, entonces los miembros del equipo discuten las razones por la que seleccionaron diferentes cartas o estimaciones. Después de la discusión, vuelven a escoger una carta. Se siguen los mismos pasos hasta que los supuestos sean comprendidos y los malentendidos sean resueltos, de esta forma se alcanzará consenso en la estimación. La Planificación Poker promueve la interacción entre los participantes y mejora la comunicación. También permite el pensamiento independiente de los participantes evitando el fenómeno de pensamiento de grupo. Puño de Cinco (Fist of Five) Es un mecanismo simple y rápido para alcanzar consenso en un grupo y direccionar la discusión. Después de una discusión inicial de una propuesta dada o decisión pendiente, a los miembros del Equipo Scrum se les pide que voten en una escala entre el 1 al 5, usando sus dedos. Esta técnica no solo permite llegar a un consenso, sino también direcciona la discusión porque a cada miembro del equipo se le pide explicar la razón de su elección. Ellos tienen la oportunidad de expresar cualquier preocupación o problema que tengan. Una vez que el equipo ha intercambiado opiniones, una decision colectiva es tomada.

© 2014 SCRUMstudy.com

44

El número de dedos usados para votar indica cuán de acuerdo está el participante con el tema propuesto y si tiene observaciones que desea discutir con el grupo: 

Un dedo: Estoy en desacuerdo con la conclusión del grupo y tengo preocupaciones importantes que deseo revisarlas con el grupo.



Dos dedos: Estoy en desacuerdo con la conclusión del grupo y quisiera revisar con el grupo algunas preocupaciones menores.



Tres dedos: No estoy seguro pero elijo estar de acuerdo con la conclusión del grupo.



Cuatro dedos: Estoy de acuerdo con la conclusión del grupo y quisiera discutir algunos temas menores.



Cinco dedos: Estoy totalmente de acuerdo con la conclusión del grupo.

Estimación Relativa / Puntos de Historia (Relative Sizing / Story Points) Además de ser utilizada para la estimación de costos, los story points pueden también servir para la estimación de toda una Historia de Usuario o funcionalidad. Este enfoque asigna un valor de Story Point basado en una evaluación completa del tamaño de la Historia de Usuario considerando el riesgo, el esfuerzo requerido y el nivel de complejidad. Esta evaluación será llevada a cabo por el Equipo Scrum y un valor de story point será asignado. Una vez que la evaluación de una Historia de Usuario del Product Backlog Priorizada es efectuada, el Equipo Scrum puede evaluar las otras Historias de Usuario de forma relativa considerando la primera historia. Por ejemplo, una funcionalidad que tiene asignada 2 story point debe tener el doble de dificultad que una funcionalidad que tiene asignada 1 story point; una que tenga 3 story point debe tener el triple de dificultad que una con 1 story point. Estimación de Afinidad (Affinity Estimation) Esta técnica es utilizada para estimar rápidamente un gran número de Historias de Usuario. Usando notas adhesivas o tarjetas y una cinta adhesiva, el equipo coloca las Historias de Usuarios en la pared u otra superficie desde la más pequeña hasta la más grande. Para esto, cada miembro del equipo empieza ordenándo un subconjunto de Historias de Usuario del Product Backlog Priorizado según su tamaño relativo. El ordenamiento inicial es realizado en silencio. Una vez que todos han colocado sus Historias de Usuario en la pared, el equipo revisa todas las ubicaciones y podría mover Historias de Usuario según corresponda. La segunda parte del ejercicio incluye la discusión. Finalmente, el Product Owner indicará algunas categorías de tamaños en la pared. Estas categorías podrian ser small, medium, o large; o estas pueden ser numeradas utilizando Story Points para indicar la medida relativa. El equipo entonces moverá las Historias de Usuario a la categoría que corresponda, este es el ultimo paso del proceso. Algunos beneficios principales de esta ténica es que el proceso es muy transparente y fácil de ejecutarla.

© 2014 SCRUMstudy.com

45

Proceso 3: Crear Tareas Crear Tasks En las fases iniciales donde se ponen por escrito los requerimientos, la mayoría de las Historias de Usuario recaban información de funcionalidades de alto nivel, por lo que éstas tienen que ser desglosadas en __________ realizables y simples. Reunión de Planificación de Tareas (Task Planning Meeting) Como parte de esta reunión, los miembros del Equipo Scrum revisan las Historias de Usuario Comprometidas a detalle para eliminar ambigüedades resolver todas las preguntas. Aunque no es mandatoria la presencia del Product Owner en esta reunión, es importante su participación porque ayudará al Equipo Scrum a entender mejor las Historias de Usuario, lo que hará que la reunión sea más eficiente. La creación de tareas se realiza durante la Reunión de Planificación de Tareas. Esta reunión está dividida en dos partes:

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

En la primera parte de la Reunión de Planificación de Tareas (Task Planning Meeting), el Product Owner sugiere Historias de Usuario que deben formar parte del Sprint basándose en la estimación provista por el Equipo Scrum de cuántas Historias de Usuario pueden entregar en un Sprint. El objetivo del Equipo Scrum es alcanzar un consenso en las Historias de Usuario que serán incluídas 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. La Reunión de Planificación de Tareas puede ser llevada a cabo dentro de la Reunión de Planificación del Sprint (Sprint Planning Meeting).

© 2014 SCRUMstudy.com

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

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

Reuniones de Estimación de Tareas (Task Estimation Meeting) El Equipo Scrum estima las tareas en la Reunión de Estimación de Tareas. Esta reunión puede ser llevada a cabo como parte de la Reunión de Planificación del Sprint (Sprint Planning 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 _______________ y _______________.

© 2014 SCRUMstudy.com

47

El Tiempo Ideal (Ideal Time) normalmente describe el número de horas que un miembro del Equipo Scrum trabaja exclusivamente en el desarrollo de los entregables del proyecto, sin incluir el tiempo dedicado a otras actividades o trabajos que están fuera del proyecto.

Proceso 5: Crear la Lista de Pendientes del Sprint Create 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.

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*

Es importante monitorear el progreso del Sprint y conocer el avance del Equipo Scrum midiendo las tareas completadas del Sprint Backlog. Una de las herramientas de seguimiento es el Scrumboard, conocido como Tablero de tareas y Cuadro de Avance. Un Scrumboard estándar contiene 4 columnas que indican el progreso de las treas 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.

© 2014 SCRUMstudy.com

48

La siguiente figura muestra un ejemplo de un Scrumboard:

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. También se incluyen en el Sprint Backlog algunos Riesgos asociados con las diversas tareas. Las actividades de mitigación a los riesgos identificados podrían ser incluidas como tareas en el Sprint Backlog. 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. Si surgen nuevas necesidades durante un Sprint, se añadirán al Product Backlog Priorizado y se incluirán en un Sprint posterior.

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:

© 2014 SCRUMstudy.com

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

© 2014 SCRUMstudy.com

50

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

Proceso 1: Crear Entregables Create Deliverables 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, brindando 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.

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

El esfuerzo principal de desarrollo recae en el Equipo Scrum, y como este es auto-organizado y multifuncional, 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 puede 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 _______________, 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 Impediment Log. Un Impediment Log 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 es 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.

© 2014 SCRUMstudy.com

51

PROCESO 2: REALIZAR LA REUNIÓN DIARIA CONDUCT DAILY STANDUP La figura muestra todas las entradas, las herramientas y las salidas del proceso Realizar un Standup Diario.

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

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 _____ minutos como máximo. En esta 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 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.

© 2014 SCRUMstudy.com

52

Proceso 3: Mantenimiento de los Pendientes Priorizados del Producto Groom Prioritized Product Backlog El tercer proceso en la fase de Implementar es el proceso Groom Prioritized Product Backlog. Para asegurar que los elementos priorizados del Product Backlog 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 refinar el Product Backlog Priorizado, lo que conlleva a añadir o cambiar algunos elementos para satisfacer cambios de requerimientos y para detallar Historias de Usuario para el siguiente Sprint. Este proceso asegura que el Product Backlog Priorizado esté refinado bien antes del siguiente 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. También permite que el desarrollo sea más flexible porque se podrá incorporar requerimientos recientes técnicos y de negocio en el siguiente Sprint. De acuerdo a la informacón del cliente, cambios externos del mercado y conocimiento ganado del Sprint actual y de los anteriores, el Product Backlog Priorizado es repriorizado. Scrum no considera que este tipo de reuniones tenga una restricción de tiempo (timebox). Este proceso es una tarea permanente del Product Owner.

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

© 2014 SCRUMstudy.com

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

53

FASE: REVISIÓN 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, el proceso de 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 ____________, 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.

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

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

5. Impediment Log 6. Dependencias 7. Salidas de la Retrospectiva del Sprint

Normalmente, un miembro de cada Equipo Scrum representará a su equipo en el Scrum of Scrums (SoS) Meeting. En la mayoría de los casos, este es el Scrum Master, pero a veces alguien más puede representar al equipo. Una sóla persona puede ser nominada por el equipo para que los represente en todas las reuniones SoS, o el representante puede cambiar con el tiempo, dependiendo si hay otra persona que pueda cumplir mejor esta función de acuerdo a los incidentes y circunstancias. La persona que participe en la reunión debe tener el conocimiento técnico para identificar los casos en los que los equipos podrían causar impedimentos o retrasos.

© 2014 SCRUMstudy.com

54

Cada representante de los Equipos Scrum proporcionará actualizaciones de su equipo. Estas actualizaciones se proporcionan generalmente en forma de respuestas a cuatro preguntas específicas: 1) ¿En qué ha estado trabajando mi equipo desde la última reunión? 2) ¿Qué va a hacer mi equipo hasta la próxima reunión? 3) ¿Qué consideraban otros equipos que mi equipo termine que no se ha hecho? 4) ¿Qué está planeando hacer nuestro equipo que pueda 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.

Proceso 2: Demostrar y Validar el Sprint Demostrate and Validate Sprint 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 __________ o el ____________ de los elementos del backlog por el Product Owner. Los elementos no aceptados permanecen en el Product Backlog Priorizado. Es responsabilidad del Scrum Master asegurar que el Product Owner no cambie requerimientos o criterios de aceptación durante el Sprint o rechace un elemento terminado del backlog porque no se satisface los nuevos cambios de requerimientos. Si el requerimiento fue cambiado, una nueva tarea necesita ser creada para direccionar a estos cambios a un Sprint futuro. 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. Si un entregable no cumple con los Criterios de Aceptación no es considerado como Terminado. Los miembros del equipo presentan el trabajo completado durante el Sprint, responden a preguntas de los Interesados y anotan los cambios sugeridos.

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

© 2014 SCRUMstudy.com

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

55

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). Esta es una oportunidad para que el Equipo Scrum se tome un momento para mirás 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 Prioritizado. 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.

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

Para llevar a cabo una reunión efectiva de Retrospectiva, el evento puede tener estos 5 pasos: 

Set the Stage (Preparar el ambiente): Se le da la bienvenida al equipo, se establece un consenso sobre el propósito de la reunión y se evalúa la predisposición de los asistentes para participar activamente.



Gather data (Obtener información): El equipo comparte información sobre el Sprint que acaba de terminar y discuten sobre las fortalezas y debilidades. Este estado permite que los participantes se enteren sobre las cosas más importantes que sucedieron en el Sprint.



Generate insight (Generar ideas): Este paso está enfocado en la pregunta “Por qué”? (¿por qué algunas cosas funcionaron bien y por qué otras necesitan cambiar?) Este ayuda a los participantes a tener perspectiva y a saber la causa raíz de los problemas.

© 2014 SCRUMstudy.com

56



Action (Acción): El equipo descubre la solución para mejorar el trabajo que se viene haciendo y para reducir o prevenir errores.



Circle of questions and Closing (Círculo de preguntas y Cierre): Cada miembro del equipo tiene la oportunidad de preguntar o compartir sus preocupaciones. En esta etapa se clarifican las acciones que se realizarán en el siguiente Sprint. Finalmente, los miembros del equipo se agradecen entre si y se cierra la reunión.

La información, opiniones, discusiones y los puntos acordados que son expuestos en la Reunión de Retrospectiva del Sprint (Retrospect Sprint Meeting) son registradas en el Retrospect Sprint Log.

© 2014 SCRUMstudy.com

57

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 Después que el Product Owner valida los ____________ 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 hecha 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 lanzados 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.

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

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

© 2014 SCRUMstudy.com

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

58

Proceso 2: Retrospectiva del Proyecto Retrospect Project El último proceso del flujo Scrum es la Retrospectiva del Proyecto, la cual es similiar 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 _______________ 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.

1. 2. 3. 4. 5.

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

© 2014 SCRUMstudy.com

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

59

Capítulo Flujo Scrum - Preguntas 1. El conjunto de prioridades de trabajo a realizar se conoce como A. Una historia de usuario. B. La Cartera priorizada del producto. C. Un gráfico Burndown. D. Aceptado entregables. 2. ¿Cuál de las siguientes es la definición de una historia de usuario? A. Una declaración que describe la visión del producto. B. Un documento que describe la prioridad de tareas a realizar en el proyecto. C. Una declaración que expresa la funcionalidad para el usuario final deseado. D. Una historia que proporciona información sobre tareas similares completado en anteriores proyectos de implementación de Scrum. 3. ¿Cómo se organizan los elementos de la Pila de Producto Priorizada (Prioritized Product Backlog)? A. Los artículos más pequeños están en la cima. B. Los elementos con menos interdependencias están en la parte superior. C. Los elementos más complejos están en la cima. D. Los elementos con el mayor valor de negocio están en la cima. 4. ¿Quién es el responsable de crear historias de los usuarios en el proceso Desarrollar Historias de usuario? A. Scrum Master B. Product Owner C. Equipo Scrum D. Interesados 5. La responsabilidad de la estimación de los elementos de la Pila de Producto Priorizada (Prioritized Product Backlog) en la fase de Planificación y Estimación recae en el A. Equipo Scrum B. Scrum Master C. Product Owner D. Equipo externo experimentado 6. ¿Cuál de los siguientes NO es una entrada para el proceso de Envío de Entregables (Ship Deliverables)? A. Entregables Aceptados B. Crnonograma de Planificación de Entregas C. Product Owner D. Impediment Log 7. ¿Con qué frecuencia se cambian las prioridades de la Pila de Producto Priorizada (Prioritized Product Backlog)? A. Nunca. B. Siempre que el Product Owner decide que un elemento tiene que ser tener una mayor prioridad. C. Siempre que el Scrum Master cree que un elemento tiene que ser añadido. D. Cuando la alta dirección se siente que un elemento tiene que ser añadido.

© 2014 SCRUMstudy.com

60

8. ¿Cuál de las siguientes herramientas es utilizada por el Equipo Scrum para estimar en el proceso de Estimación de Tareas? A. Experiencia en la escritura de Historias de Usuario B. Wideband Delphi C. Comparativo por Pares D. Sesiones JAD 9. ¿Cuál de las siguientes afirmaciones NO es verdadera? A. Velocidad del equipo es una medida de la cantidad de trabajo que un equipo puede completar en un Sprint. B. Velocidad histórica del equipo que se utiliza como un indicador en la asignación de tareas para cada Sprint. C. La velocidad del equipo es independiente de la composición del equipo. D. La velocidad del equipo se utiliza en la decisión de los plazos de entrega. 10. ¿Cuál de los siguientes no es discutido en una reunión Standup diaria (Daily Standup Meeting)? A. Lo que el miembro del equipo ha avanzado desde la última reunión B. Lo que el miembro del equipo tiene previsto trabajar hasta la próxima reunión C. Lo que el miembro del equipo ha aprendido al completar su trabajo D. Las barreras que el miembro del equipo enfrenta 11. ¿Cuál es la duración normal de una reunión Standup diaria (Daily Standup Meeting)? A. 5 minutos B. 1 hora C. 15 minutos D. Reuniones de stands-up no tienen límite de tiempo. 12. Asegurar que las reuniones diarias de Standup se ejecutan de manera oportuna y estructurada es la responsabilidad de A. Scrum Master B. Product Owner C. Scrum Team Leader D. Del grupo a nivel colectivo 13. El Sprint Burndown Chart es una herramienta utilizada por los equipos para A. Medir el trabajo completado durante un Sprint. B. Medir el trabajo que queda por realizar durante un Sprint. C. Calcular el remanente del presupuesto del equipo. D. Identificar los miembros de bajo rendimiento del equipo. 14. La reunión en la que el equipo discute las tareas a realizar en el próximo Sprint es conocido como la: A. Reunión de Visión de Producto (Product Vision Meeting). B. Reunión de Planificación del Sprint (Sprint Planning Meeting). C. Reunión de Revisión de Sprint (Sprint Review Meeting). D. Reunión de Restrospectiva del Sprint (Retrospect Sprint Meeting).

© 2014 SCRUMstudy.com

61

15. La reunión al final del Sprint en el que el equipo presenta su trabajo al Product Owner es conocido como la: A. Reunión de Visión de Producto (Product Vision Meeting). B. Reunión de Planificación del Sprint (Sprint Planning Meeting). C. Reunión de Revisión de Sprint (Sprint Review Meeting). D. Reunión de Restrospectiva del Sprint (Retrospect Sprint Meeting). 16. La reunión en la que el equipo analiza el Sprint anterior e identifica mejoras potenciales en los procesos se conoce como la: A. Reunión de Visión de Producto (Product Vision Meeting). B. Reunión de Planificación del Sprint (Sprint Planning Meeting). C. Reunión de Revisión de Sprint (Sprint Review Meeting). D. Reunión de Restrospectiva del Sprint (Retrospect Sprint Meeting). 17. Durante la reunión de revisión de Sprint (Sprint Review Meeting): A. El equipo presenta el producto final entre sí. B. El Scrum Master puede aceptar o rechazar la entrega del producto final. C. El equipo presenta la entrega del producto final al Product Owner. D. Cada miembro del equipo puede aceptar o rechazar la entrega del producto final. 18. ¿Cuál de las siguientes actividades NO es parte de la Reunión de Restrospectiva del Sprint (Retrospect Sprint Meeting)? A. El equipo discute los aspectos positivos y negativos del Sprint anterior. B. El equipo identifica los problemas que enfrentaron en el Sprint anterior y discute cómo mitigar estos temas en Sprints futuros. C. El equipo revisa e identifica posibles mejoras en su trabajo. D. Sobre la base de los cambios propuestos, el equipo procede a cambiar la prioridad de la Pila de Producto priorizada (Prioritized Product Backlog). 19. Las ventaja del proceso Grooming the Prioritized Product Backlog (Mantenimiento de los Pendientes Priorizados del Producto) es la siguiente: A. El conocimiento ganado a partir de un Sprint anterior se incorpora en Sprints futuros. B. Los últimos requisitos técnicos y de negocio se agregan al siguiente Sprint. C. El mantenimiento del Product Backlog priorizado asegura tenerlo refinado antes de la reunión de planificación de Sprint para que el equipo tiene una mejor idea de los requisitos antes de la reunión. D.Todas las anteriores. 20. La responsabilidad de la preparación de la Pila de Producto priorizada (Prioritized Product Backlog) recae en el A. Product Owner (propietario del producto). B. Scrum Master. C. Equipo Scrum. D. Los interesados externos. 21. ¿Cuál de las siguientes actividades se pueden realizar en conjunto durante la reunión de planificación del Sprint (Sprint Planning Meeting)? A. Estimación Tareas y Planificación de Entregas B. Mantenimiento de la Pila de Producto y Planificación de Tareas C. Planificación de Tareas y Tareas de Estimación D. Planificación de Entregas y Mantenimiento de la Pila de Producto

© 2014 SCRUMstudy.com

62

22. ¿Cuál de las siguientes no es parte de la reunión de planificación de Sprint? A. El Product Owner, explica los principales elementos de la Pila de Producto priorizada para el equipo. B. El Equipo Scrum, en colaboración con el Product Owner, estima las tareas de un Sprint dado. C. Sobre la base de las estimaciones, el equipo se compromete en algunas tareas que deben completarse en el próximo Sprint. D. El equipo recibe la retroalimentación de las partes interesadas. 23. Usted es miembro de un equipo Scrum y se le indica que el gerente general de la empresa ha solicitado que se desarrolle una tarea urgente que no forma parte del Sprint actual. ¿Qué debe hacer? A. Hacerse responsable de la tarea, y hablar con el Product Owner para ampliar el plazo del Sprint actual. B. Hablar con el Scrum Master para volver a asignar las tareas a otra persona. C. Hablar con el Product Owner para volver a a asignar las tareas a otra persona. D. Informar al Scrum Master de la situación para que revise la situación con el gerente general. E. No realizar ninguna acción porque ya está ocupado. 24. A. B. C. D.

Para cualquier Sprint en curso, ¿cuándo se pueden agregar nuevas historias de usuarios? Cuando el Scrum Master agrega la historia de usuario a la Pila de Sprint (Sprint Backlog) Cuando el Product Owner (propietario del producto) aprueba la historia de usuario Cuando el equipo Scrum aprueba la historia de usuario Nuevas historias de los usuarios nunca pueden ser añadidas al Sprint

25. A. B. C. D.

Los Criterios Aceptación: Incrementan la ambigüedad de los requerimientos. Ayudan al equipo se ceñirse a las normas de calidad relacionadas con la funcionalidad. Son determinados por el Scrum Master en colaboración con los miembros del equipo. Son determinados por el Scrum Master en colaboración con el Product Owner (propietario del producto).

26. A. B. C. D.

¿En cuál de los siguientes procesos de la fase Iniciar se determina la duración del Sprint? Crear Visión del Proyecto Desarrollar Epics Crear la Pila de Producto Priorizada Realizar la Planificación de las Entregas (Conduct Release Planning)

© 2014 SCRUMstudy.com

63

ESCALANDO 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 _________ asegura esta sincronización. Los diversos Equipos Scrums están representados en esta reunión y el objetivo es proporcionar actualizaciones sobre del 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 Producto 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.

© 2014 SCRUMstudy.com

64

La siguiente figura ilustra cómo el método Scrum se puede utilizar en toda la organización para los Portafolio, Programa o Proyectos.

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.

© 2014 SCRUMstudy.com

65

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 ___________. Por lo general, hay un representante en la reunión de cada uno de los Equipo Scrums. Por 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 ________________ y de______________. 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.

© 2014 SCRUMstudy.com

66

Mapeo de Roles tradicionales a Scrum Los roles tradicionales del gestión de proyecto son divididos en tres roles en Scrum : ___________, ______________ y ________________.   



El Producto 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 autogestionan 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 __________ 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 __________ y / o evita ____________ para la organización? o ¿Cuán imprescindible es adaptarser 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 trascició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?

© 2014 SCRUMstudy.com

67

Capítulo Escalando Scrum - Preguntas 1. ¿Cuál de los siguientes NO es cierto con respecto a la implementación de Scrum para grandes proyectos? A. Se requieren varios equipos para trabajar en sincronía. B. Una Cartera priorizada del producto no es necesaria para monitorear el progreso de todos los proyectos. C. Un Jefe Product Owner es necesario para supervisar todos los proyectos. D. Las tareas pueden no ser interdependientes entre los equipos. 2. ¿Cuál de los siguientes es parte de la Scrum de Scrums? A. Resumen de las tareas a realizar en el Sprint. B. Si alguna de tus decisiones podrían afectar a otros equipos. C. Hablar de los problemas que pueden haber surgido para cualquiera de los equipos de Scrum. D. Resolución de Impedimentos que pueden haber surgido. 3. ¿Cuál de las siguientes afirmaciones es FALSA respecto a Scrum en equipos grandes? 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 es responsable de la asignación de recursos. C. El Jefe de Producto Owner facilita el Scrum de Scrums. D. El Jefe de Producto Owner es responsable del éxito o fracaso del proyecto. 4. ¿Cuál de las siguientes es la responsabilidad del Producto Owner del programa? A. Comunicar las metas y objetivos de Sprint a los miembros del Equpo Scrum. B. Definir los objetivos y prioridades estratégicas para el Programa. C. Establecer los criterios mínimos de terminado de los equipos. D. Resolver problemas, eliminando los obstáculos, facilitar y realizar reuniones para el programa. 5. ¿Cuál de los siguientes procesos garantiza la sincronización y facilita el flujo de información entre varios equipos Scrum que trabajan en paralelo en grandes proyectos Scrum? A. Convene Scrum of Scrums. B. Conduct Daily Standup. C. Retrospect Proyect. D. Retrospect Sprint.

© 2014 SCRUMstudy.com

68