Guía Rápida de Scrum

Universidad Universidad Adventista A dventista de Centro América Am érica Escuela de Ingeniería de Sistemas S istemas Computacionales

Material anexo de:

Propuesta de implementación del marco de desarrollo ágil (SCRUM) en el departamento de sistemas y en el curso Análisis de Sistemas II de la Escuela de Ingeniería en UNADECA. Título a optar:

Licenciatura en Ingeniería de Sistemas Autor:

Lucy M. Andrade Ana M. Baíza Asesor:

Lic. Jorge Ulate, MBA, MGP Fecha:

Septiembre – Septiembre – 2016 2016

Guía Rápida de Scrum

CONTENIDO

Introducción Introducción a las metodologías ágiles ............................... 3 Concepto de scrum .............................................................. .............................................................. 3 El equipo de scrum.............................................................. 4 Product Product owner ................................................................ .................................................................. 4 Development Development Team ......................................................... ......................................................... 5 Tamaño del developmen deve lopmentt team t eam ................................... ................................ ... 5 Scrum Master ................................................................ .................................................................... 6 Artefactos Artefactos de scrum ........................................................... ............................................................. 7 Product Product Backlog .............................................................. .............................................................. 7 User Stories Stories ................................................................. ................................ ..................................... .... 8 Sprint Backlog ................................................................ 9 Scrum Taskboard ............................................................ ............................................................ 9 Burndown Burndown Chart ............................................................ ............................................................ 10 Eventos Eventos de scrum .............................................................. .............................................................. 10 Sprints Sprints ........................................................................... ...................................................... ..................... 11 Sprint 0 (preparación) ............................................... ................................ ............... 11 Product Product Backlog Refinemen R efinementt Meeting .......................... 12 Sprint Planning Meeting ............................................... ................................ ............... 13 Daily Scrum ................................................................ .................................................................... 14 Sprint Review................................................................ 15 Sprint Retrospectiv R etrospectivee ...................................................... ...................................................... 15 Estimación Ágil ................................................................ 17 Definición de “Terminado” y “Listo” ............................... 19 1


Glosario.............................................................. ............................................................................. ............... 20 Referencias Referencias Bibliográficas ................................................ ................................ ................ 22

2


INTRODUCCIÓN A LAS METODOLOGÍAS ÁG ILES

Las metodologías tradicionales han sido s ido efectivas y utilizadas para un gran número de proyectos; pero también han presentado problemas en muchos otros. Como resultado de esto han surgido nuevas metodologías se basan en el manifiesto para un desarrollo de Software Ágil, el cual expone formas mejores de desarrollar software, desarrollándolo y ayudando a otros a desarrollarlo. A través de ese trabajo hemos empezado a valorar: individuos e interacciones por sobre procesos y herramientas, software funcionando por sobre documentación completa, cooperación con el cliente por sobre negociación de contratos, respuestas frente a cambios por sobre sobre seguimiento de un plan.

CONCEPTO DE SCRUM

Es un framework (marco de trabajo) en el que la gente puede hacer frente cambios frecuentes haciendo más productiva productiva y creativa la entrega entrega de productos. productos. Scrum no es un proceso o una técnica para la construcción de productos; más bien, es un marco dentro del cual se puede emplear varios procesos procesos y técnicas. Scrum consiste en Equipos Scrum y sus funciones asociadas, eventos objetos y reglas. Donde cada elemento tiene su propósito específico y es esencial para el éxito y el uso de Scrum. Scrum emplea un enfoque iterativo e incremental para optimizar optimizar la previsibilidad y control control de riesgos. 3


EL EQUIPO DE SCRUM

El Equipo de Scrum consiste en:   

Product Product Owner Ow ner (Dueño del Producto). Deverlopment Deverlopment Team (Equipo de Desarrollo). Scrum Master.

Los Equipos Scrum son autoorganizados y multifuncionales. Los Equipos Scrum entregan productos de forma iterativa e incremental, maximizando las oportunidades de obtener obtener retroalim retr oalimentación. entación. Las entregas e ntregas incrementales de producto producto “Terminado” aseguran que siempre estará disponible una versión potencialmente útil y funcional del producto. producto.

PRODUCT OWNER El Product Owner es el único responsable de gestionar gestionar el Product Backlog (lista de producto). La gestión incluye: 





Expresar claramente los elementos del Product Pr oduct Backlog. Ordenar los elementos según la prioridad de entrega. Asegurar que el Product Backlog sea clara para todos.

El Product Owner es una única persona, no un comité.

4


DEVELOPMENT TEAM El Development Team es responsabl resp onsablee de desarrollar desarr ollar el producto. Las actividades de cada uno de los miembros del equipo están alineadas de tal manera que se alcancen los objetivos objetivos asociado as ociadoss a un u n sprint específico. Los Equipos de Desarrollo tienen las siguientes características:   

 

Son auto organizados. Son multifuncionales. Scrum no reconoce títulos para los miembros del equipo, todos son desarrolladores. Scrum no reconoce sub-equipos. Los miembros individuales pueden tener habilidades especializadas y áreas en las que estén más enfocados, pero la responsabilidad recae en el Equipo de Desarrollo como un todo. t odo.

TAMAÑO DEL DEVELOPMENT TEAM El tamaño óptimo del Equipo de Desarrollo es lo suficientemente pequeño como para permanecer ágil y lo suficientemente grande como para completar una cantidad de trabajo significativa. Tener menos de tres miembros reduce la interacción y resulta con ganancias de productividad productividad más pequeñas encontrándose con limitaciones en cuanto a habilidades necesarias durante un sprint. Tener más de nueve miembros requiere demasiada coordinación. 5


Los roles de Product Owner y Scrum Master no cuentan con el cálculo del tamaño del equipo a menos que también estén contribuyendo a trabajar en el Sprint Backlog (Lista de Pendientes del Sprint).

SCRUM MASTER El Scrum Master es el responsable de asegurar que Scrum es entendido y adoptado; asegurándose de que el Equipo Scrum trabaja ajustándose a la teoría, prácticas y reglas de Scrum. También es un líder que está al servicio del Equipo Scrum. El Scrum Master ayuda a las personas externas al Equipo Scrum a entender qué interacciones con el Equipo Scrum pueden ser de ayuda y cuáles no. Es responsable de dirigir y planificar la logística necesaria para las reuniones.

6


ARTEFACTOS DE SCRUM

Los artefactos definidos por Scrum está diseñados para asegurar asegurar que todos tengan tengan el mismo entendimiento entendimiento del proyecto. proyecto. Los artefactos artefactos en Scrum son: s on:     

Product Product Backlog B acklog User Stories Sprint Backlog Task Boards Burndown Burndown Chart C hart

PRODUCT BACKLOG Es una lista del producto ordenada de todo lo necesario en el producto (requisitos) y es la única fuente para cualquier cualquier cambio. El Product Owner es el responsable de la lista, incluyendo su contenido y priorización. El Product Backlog va evolucionando a medida que el producto y el entorno también lo hacen es decir que es dinámica y cambia contantemente para identificar los que el producto producto necesita para ser competitivo competitivo y útil. út il. El Product Backlog Producto 7


enumera todas las características, características, funcionalidades, requisitos, requisitos, mejoras y correcciones que constituyen cambios a ser hechos sobre el producto para entregas futuras . Y tienen como atributo la descripción, la ordenación la estimación y el valor.

USER STORIES Los User Stories son las descripciones descripciones de las funcionalidades que tendrá el software; y serán el resultado de la colaboración entre el Product Owner y el Scrum Team. Se sugiere una determinada forma de redactar los User Stories: Como (rol) Necesito/quiero (funcionalidad) Para (beneficio)

Ejemplo: Como estudiante necesito comprar un pase de estacionamiento estacionamiento para poder poder estacionar mi vehículo vehículo en la universidad. Préstamo de Libro

Cómo cliente quiero que los socios puedan pedir prestado un libro, para ser llevados fuera de la biblioteca pero indicando su número de d e socio y la referencia del libro, siempre y cuando no tengan ya tres libros prestados en ese momento.

8


SPRINT BACKLOG Es la lista de tareas que se elaboran durante la planificación planificación del sprint y que que formarán parte parte del próximo incremento. También debe ser un plan con un nivel de detalle suficiente como para que los cambios en el progreso se puedan entender entender en el e l Scrum Diario. El Development Team modifica el Sprint Backlog y las nuevas tareas se añaden al estado de pendientes; a medida que el trabajo se ejecuta o se completa, se va actualizando la estimación y el estado de la tarea. Estas tareas son asignadas a cada persona pers ona del Development Development Team y el tiempo t iempo que queda en terminarlas. terminarlas.

SCRUM TASKBOARD Generalmente, Generalmente, las tareas a completar se suelen sue len gestionar mediante el scrum taskboard, se usan post-its que se van moviendo de columna para cambiar cambiar el estado.

9


BURNDOWN CHART El progreso del equipo se realiza un seguimiento mediante un Burndowns Chart que representa visualmente el progreso de un proyecto. El Burndown Chart proporciona proporciona una medida medida de día a día del trabajo que que queda en un sprint o liberación dada. La pendiente de la gráfica, o la burndowns velocity, se calcula comparando el número de horas trabajadas a la estimación original del proyecto y muestra la tasa promedio de la productividad para cada día.

Saber si o no el proyecto está en el tiempo, temprano, o correr detrás puede ayudar a los equipos hacer los ajustes que hará que todo vuelva a la pista.

EVENTOS DE SCRUM

10


Con Scrum el producto es construido en series de iteraciones predefinidas llamadas Sprints. Iteraciones cortas refuerzan la importancia de una buena estimación estimación de tiempo tiempo y una retroalimentación retroalimentación rápida de las pruebas. Scrum solicita cuatro eventos que aporten estructura a cada sprint.     

Product Product Backlog B acklog Refinement Meeting Sprint planning Daily Scrum Sprint Review Sprint retrospective

SPRINTS El corazón de Scrum es el Sprint, es un bloque de tiempo (time-box) de un mes o menos durante el cual se crea un incremento de producto “Terminado”, utilizable y potencialmente potencialmente desplegable. desplegable. Cada nuevo Sprint comienza inmediatamente después de la finalización del Sprint previo. Cada Sprint tiene una definición de qué se va a construir, un diseño y un plan flexible que guiará la construcción y el trabajo y el producto resultante.

SPRINT 0 (PREPARACIÓN) 11


Es la fase inicial en donde se intenta comprender el caso de negocio para tomar decisiones que agreguen valor al producto. Durante esta fase se producen inexactitudes con las estimaciones, pero es normal. En lugar de buscar estimaciones exactas se busca invertir ese tiempo en el producto. producto. Las tareas en el sprint 0 son:   

Definir el proyecto Definición Definición del Backlog Inicial Definición de los entregables (criterios, fechas de reuniones)

PRODUCT BACKLOG REFINEMENT MEETING Asisten: Product Owner, Scrum Team (no ( no es

necesario todo el equipo). Cuando: Se realiza después de que el Product

Owner ha definido el Product Backlog y antes que se realice la planeación del sprint sigui s iguiente, ente, preferiblemente tres días antes del final del sprint spr int actual. Propósito: En la reunión se añaden más detalles a

los User Stories, estimaciones y priorización. priorización. Al Scrum Team se le da la ocasión de formular preguntas preguntas que normalmente normalmente surgirían durante durante el Sprint Planning. Preguntándose esto antes, al Product Owner se le le da la oportunidad de responder con tiempo a cualquier pregunta que él o ella pueda que no esté preparado para 12


hacerlo de manera inmediata y ser presentada en el Sprint Planning Meeting. Si estas preguntas surgen en el sprint planning s ean meeting por primera vez, pueda ser que muchas no sean contestadas, podría ser necesario poner un elemento de Product Backlog de alta prioridad a un lado y no trabajar en él durante el Sprint.

SPRINT PLANNING MEETING Asisten: Development Team, Scrum Master,

Product Product Owner. Ow ner. Cuando: al principio del Sprint. Propósito: el product owner tendrá un product

backlog backlog priorizado. priorizado. Discuten cada elemento con el development team y el grupo estima colectivamente el tiempo que supone. El development team tendrá que hacer un pronóstico del sprint con respecto a la cantidad de trabajo que el equipo puede entregar referente al backlog. Este cuerpo de trabajo se convierte en el sprint backlog. Solo el Equipo de Desarrollo puede evaluar qué es capaz de lograr durante el Sprint que comien c omienza. za. La reunión alienta a los miembros del equipo para bosquejar bosquejar las tareas de todas las las historias, bugs, y tareas que entran en el sprint.

13


DAILY SCRUM Team, Scrum Master. Asisten: Development Team, Opcionales: Product Owner, inversionistas.

Cuando: una vez por día, normalmente en la

mañana. Duración: no más de 15 minutos. Sin reservar una

sala de conferencias y llevar la reunión a cabo de pie. Estar de pie ayuda a mantener la reunión corta. Propósito: la reunión está diseñada para ser rápida

e informar a todos lo que está sucediendo en los equipos. No es una reunión reunión detallada; debería ser ligera y divertida, divertida, pero informativa. informativa. El Scrum Diario es una reunión para que el Equipo de Desarrollo sincronice sus actividades y cree un plan para las siguientes 24 horas. Cada miembro del Development Development Team explica:   

¿Qué hice ayer? ¿Qué haré hoy? ¿Veo algún impedimento?

El Scrum Master se asegura de que el Development Team tenga la reunión y que todos sus miembros participen, pero el Development Team es el responsable de dirigir el Scrum Diario. Los Daily Scrum mejoran la comunicación, eliminan la necesidad de mantener otras reuniones, identifican y eliminan impedimentos relativos al desarrollo, resaltan y promueven la toma de decisiones rápida, y mejoran el nivel de conocimiento del Equipo de Desarrollo. 14


SPRINT REVIEW Asisten: Development Team, Scrum Master, Product Owner. Opcionales: inversionistas. Cuando: al final del sprint o hito importante.

30 – 60 60 minutos. Duración: 30 – Propósito: la revisión del sprint es un momento para mostrar el trabajo del equipo. Puede ser casual como

o más una reunión más formalmente estructurada. Este es el tiempo para que el equipo celebre sus logros, demuestre el trabajo finalizado dentro del sprint y obtiene feedback inmediato por parte de los inversionistas. Recodar que el trabajo debe estar completamente demostrable y cumplir la barra de calidad del equipo equipo dentro de la consideración consideración de completo; completo; listo para mostrar m ostrar en la revisión.

SPRINT RETROSPECTIVE Asisten: Development Team, Scrum Master,

Product Product Owner. Ow ner. Cuando: al final del sprint. Duración: 30 – 30 – 60 60 minutos. Propósito: Las retrospectivas ayudan al equipo a

entender que funcionó bien y que mal; no solo son un momento para quejarse sin hacer nada, sino más bien tomarse el tiempo para encontrar soluciones creativas y desarrollar desarrollar un plan p lan de acción. 15


En conclusión, el propósito de la Retrospectiva de Sprint es: 





Inspeccionar cómo fue el último Sprint en cuanto a personas, personas, relaciones, procesos procesos y herramientas; Identificar y ordenar los elementos más importantes que salieron bien y las posibles mejoras; y, Crear un plan para implementar las mejoras a la forma en la que el Equipo Scrum desempeña su trabajo.

16


ESTIMACIÓN ÁGIL

La buena estimación ayuda a los products owners a optimizar para obtener eficiencia e impacto. Deben tomar en cuenta serie de factores que ayudará al product owners realizar decisiones que afectan todo el equipo equip o y el negocio. Con todo lo que está en jueg juegoo no es de extrañar que todos los desarrolladores se sientan vulnerables a cometer un error. Pero eso está incorrecto, ya que la estimación es solo eso: una estimación; no un juramento de sangre. A continuación, se enumeran algunas maneras de hacer de la estimación lo más acertado posible. Colaboración Colaboración con el product owner

Cuando el equipo de ingeniería comienza el proceso de estimación, las preguntas normalmente surgen acerca de los requerimientos requerimientos y los user stories. Y eso es bueno: estas preguntas preguntas ayudan a todo el equipo equipo a entender entender el trabajo más ampliamente. Para product owners específicamente, separar historias en pequeñas tareas y estimarlas ayuda a priorizar todo (y potencialmente escondidas) áreas de trabajo. Y una vez que se obtiene la estimación del development team, no es raro para el product owner reordenar estos elementos en el backlog. A esta reunión se le llama goomming meeting o backlog refinement meeting.

La estimación ágil involucra a un equipo completo

Incluyendo a todos (desarrolladores, diseñadores, testers, deployers, todos) en un equipo es la clave. Cada

17


miembro miembro del equipo tiene t iene una diferente perspectiva del producto producto y el trabajo requerido requerido para realizar realizar el user story. story. Story points vs. Horas

Los quipos de softwa s oftware re tradicionales tradicionales realizan realiza n estimaciones en formato de tiempo: días, semanas, meses. Muchos equipos ágiles, sin embargo, han cambiado a story points. Los story points valoren el esfuerzo relativo en formato Fibonacci: 0, 1, 2, 3, 4, 8.

1 2 3 4 8

Very small Small Medium Large Very large

Los equipos que comienzan con los story points pueden usar el ejercicio llamado planning póker . El equipo agarra un elemento del backlog, lo discuten brevemente y cada miembro hará una estimación mental. Después cada uno toma una carta con el número que refleja su estimación. Si todos está de acuerdo, excelente; si no se tomaría unos minutos para entender el porqué de las diferentes estimaciones. Estimar inteligentemente dividiendo dividiendo el trabajo en tareas

Un trabajo individual no debería ser más de 16 horas horas de trabajo. (Se están utili ut ilizando zando story points, puedes pu edes decidir que 20 puntos es el límite). Es simplemente muy difícil estimar un trabajo individual mayor con un alto grado de confianza. Cuando algo es estimado por encima de las 16 hrs (o 20 puntos), es la señal para dividir en partes y reestimar la tarea. 18


Aprender de las estimaciones pasadas

La estimaciones se pueden realizar de dos maneras: 1. De forma aploximada: se debate el story points hasta llegar a un acuerdo. Suele fuincionar de forma correcta correcta si los sprints son cortos. 2.

Por medio de calculo de velocidad.

DEFINICIÓN DE “TERMINADO” Y “LISTO” Listo

Es el conjunto de caracterí c aracterísticas sticas que User Us er Story debe cumplir para que el Development Team pueda comprometerse a su entrega , es decir, incluirla en un Sprint Backlog. Backlog. Un U n típico criterio de “Listo” podría ser: 

Todos Todos sus pre-requisitos pre-requisitos están resueltos

Terminado

Es el conjunto de caracterí c aracterísticas sticas que un u n User Story St ory debe cumplir para que el equipo de desarrollo pueda determinar si ha terminado de trabajar en ella. Un típico criterio de “Terminado” podría podría ser: ser : 



Todos los criterios de aceptación funcionan correctamente Todos los archivos fuentes están en el repositorio de código fuente fuente y el build se ejecutó exitosamente.

19


GLOSARIO Blacklog: es una lista de historias de usuarios pendientes,

errores y características para un producto (product backlog) o sprint (sprint backlog). burndow n chart muestra la cantidad Burndown Chart: el burndown de trabajo actual y estimado que debe ser hecho en un sprint. Development Team: equipo de desarrolladores. Framework: marco de trabajo. Se diferencia entre la

palabra palabra “metodología” y de procedimiento proc edimientoss especificados paso a paso. Un marco de trabajo trabajo son un conjunto conjunto de conceptos, criterios, prácticas y acuerdos de trabajo, para avanzar con determinado proyecto que permiten mantener el foco y dejar espacio para la creatividad. Product backlog: es una lista de alto nivel que contiene los

requerimientos requerimientos del cliente para el e l proyecto y es realizado por el product product owner. owner. Product Owner: dueño del producto, cliente. Es quien

ocupa el rol de escuchar e integrar las necesidades involucradas en determinados productos, cuidando que los resultados resultados y el valor entregado sean necesarios. Scrum: Scrum es un marco de desarrollo ágil que es

completado por iteraciones sobre un número discreto de periodos periodos de tiempo (sprint). (sprint). Scrum Board: un Scrum Board es una pizarra que fue

creada usando los preajustes de “Scrum” (ver creando una pizarra). pizarra). 20


Scrum Master: facilitador. Es quien ocupa el rol de cuidar

el equipo de personas y el marco de trabajo a través del cual avanzan los proyectos. sprint – también conocido como iteración – es es Sprint : un sprint – un periodo corto (idealmente de dos a 4 semanas) en el cual el equipo de desarrollo implementa y entrega un incremento discreto del producto p. ej trabajando en una versión versión beta. Sprint Backlog: el sprint backlog contiene la lista de tareas

necesarias para ser completas y así implementar las características características planeadas para un u n sprint en particular. Idealmente cada tarea en un sprint es relativamente corto y puede ser escogida escogida por un miembro miembro del equipo equipo en lugar de ser asignada. User Story: un user story es un requerimiento del sistema

de software que es expresada en cortas oraciones preferiblemente preferiblemente no usando usando lenguaje técnico. técnico. Story Point: un story points es una estimación de la

complejidad complejidad relativa de una u na historia. Tarea: una tarea es una unidad de trabajo contenida dentro

de una historia. Velocidad: la velocidad del equipo es una medición de

cuanto trabajo el equipo puede manejar dentro de un periodo especifico de tiempo tiempo es decir cuánto del product backlog backlog puede ser completado completado por un equipo equipo en un sprint. Versión: una versión es un conjunto de características y

arreglos lanzados en conjunto como una sola actualización de tu producto. 21


REFERENCIAS BIBLIOGRÁFICAS Alaimo, M. (2006). Análisis, estimacion y planificacion

ágil. Kleer. Cohn, M. (25 de Abril de d e 2008). Mountain Goat.

Obtenido de Advantages of the “As a user, I want” user story template.: http://www. mountaingoatsoftware. mountaingoatsoftware. com/blog/advantages-of-thecom/blog/advantages-of-theas-a-user-i-want-user-story-template. Gupta, S. (14 de 0 de d e 2013). Performance & Load Testing. Obtenido de Roles of team members involved in an AGILE Scrum project: http://www.quotium.com/perfo http://www.quotium.com/performance/role rmance/roles-t s-teameammembers-involved-agile-scrum-project/ Radigan, D. (15 de 8 de d e 2016). atlassian. Obtenido de "Have we met?" Four agile ceremonies, demystified.: https://www.atlassian.com/agile/ceremonies Paredes, Arleth (2012). Manifiesto Ágil.Recuperado el 14 de agosto de 2016 de https://arlethparedes.word https://arlethparedes.wordpress.com/2012/ press.com/2012/08/25/mani 08/25/mani fiesto-agil/ Defi nitive Schwaber, K. and Sutherl S utherland, and, J. (2013). The Definitive Guide to Scrum: The Rules of the Game.

22

Guía Rápida de Scrum

Recommend Documents