Scrum

M. Sc. Ing. Gener Zambrano

 Objetivos:

 Comprender los conceptos que considera el desarrollo

ágil

 Conocer las actividades y artefactos que maneja Scrum

Agenda
Índice:

 Gestión ágil

 Scrum:
Ciclo de vida

Componentes
Gestión ágil.
La gestión ágil gestiona el desarrollo de
software ágil, un proyecto ágil se
completa en pequeñas secciones
llamadas iteraciones. Cada iteración es
revisada y criticada por el equipo del
proyecto, que puede incluir
representantes de la empresa cliente, así
como empleados.

Cada iteración del proyecto está

programada normalmente para ser
completada dentro de dos semanas.

Debido a que la gestión ágil se basa en la capacidad de tomar decisiones con rapidez, no
es adecuada para las organizaciones que tienden a deliberar sobre cuestiones durante un
período prolongado o para aquellos que llevan las decisiones a un comité.

Hacer un cambio necesario para un proyecto en el momento adecuado puede ahorrar

recursos y, en última instancia, ayudar a entregar un proyecto exitoso a tiempo y dentro
del presupuesto.
Manifiesto ágil:
Scrum
Es un marco de trabajo para el desarrollo ágil de proyectos, pero de suficiente sencillez
y flexibilidad como para ser aplicado en contextos muy diversos. Dentro de este marco,
el proceso de desarrollo de un proyecto se concibe como una sucesión de ciclos cortos
de trabajo denominados Sprints, obteniendo de cada uno de ellos un producto funcional
que va completándose en forma iterativa.

Características: Proceso.
 Gestión de las expectativas del
cliente
 Resultados anticipados
 Flexibilidad y adaptación
 Mitigación de riesgos
 Alineamiento entre cliente y equipo
 Simplicidad
 Enfocado en la productividad
 Motivación y responsabilidad
Ciclo
Scrum –de vida SCRUM
Sprint
1. El ciclo de vida de Scrum se divide en Sprints. Es decir, en iteraciones.

2. Crea un incremento de producto “Terminado”, utilizable y potencialmente

desplegable.

3. Dura típicamente entre 2-4 semanas

4. En cada Sprint se diseña, codifica y testea el producto

5. Dentro de cada sprint, SCRUM gestiona la evolución del proyecto

mediante reuniones breves de seguimiento en las que se revisa el trabajo
realizado desde el hito anterior y los planes para el hito siguiente.
Scrum – ciclo de trabajo.
1. Toma de requisitos al cliente. Para cada requisito principal se crea
un bloque de trabajo, llamado historia

2. El cliente ordena los bloques de trabajo en una pila de producto

según su prioridad de entrega.

3. El equipo de trabajo toma un grupo de historias, con el que

trabajan durante una iteración o sprint.

4. Una vez finalizado un sprint entregan al cliente el resultado del

trabajo. Se vuelve al punto 2 hasta terminar la pila de producto.
Componentes
Scrum – componentes:
- Roles:
• Responsables del producto: “Product Owner”
• Responsables del funcionamiento de Scrum: “ScrumMaster”
• Responsables del desarrollo: “Scrum Team”

- Reuniones:
• Sprint planning
• Sprint review
• Sprint retrospective
• Daily scrum meeting

- Artefactos:
• Product backlog – pila del producto, historia de usuario
• Sprint backlog – pila del sprint,
• Incremento
Scrum – asignación de roles:
Si se está emprendiendo la conformación del equipo:
 Uno de los emprendedores debe ser el dueño del producto
 El resto serán clientes (cuando se reúnan para definir objetivos y planteamientos de la
empresa)
 Scrum master, es el facilitador y guía del equipo
 Miembros del equipo si tienen tareas concretas que hacer, es decir, no son solo
inversores o consejeros.
 Al equipo de emprendedores habrá que agregarle colaboradores como asesores legales,
desarrolladores, empresas de marketing, etc.
 Con respecto a los colaboradores externos, explicarles simplemente los objetivos y el
plazo que tienen para cumplirlo y que habrá un control diario de su progreso. Si no
están dispuestos a asumir el control diario, lo mejor es buscar otro proveedor.
Scrum – roles:
Cada persona que
interviene en el proceso de
creación de un producto o
servicio tiene un rol
específico en Scrum.
Scrum – roles:
Product owner – dueño del producto.

Uno de los roles clave definidos en Scrum es el denominado propietario

del producto (Product Owner), que participa activamente en el proceso
de desarrollo, facilitando la comprensión por parte del equipo de los
aspectos prioritarios y centrales del resultado esperado.

Es quien representa al cliente, con una fuerte y continua interacción con

el equipo, facilita desde el inicio la clara percepción de la visión del
producto y de los aspectos que se consideran de valor sustancial en el
mismo. Al mismo tiempo que provee retroalimentación continua al
equipo sobre estos aspectos, adquiere una comprensión de las
posibilidades y dificultades a partir de la comunicación con ellos.
Scrum – roles:
Scrum master ó Scrum manager.

Persona que lidera al equipo guiándolo para que cumpla las reglas y
procesos de la metodología. Gestiona la reducción de impedimentos del
proyecto y trabaja con el Product Owner para maximizar el ROI. Sus
responsabilidades son:

1. Asegurar que el equipo se mantenga plenamente funcional y

productivo
2. Permitir la cooperación estrecha entre todos los roles y funciones
3. Eliminar las barreras que obstaculicen el desarrollo del proyecto.
Remueve impedimentos del equipo.
4. Facilitador y líder del equipo
5. Garantiza el funcionamiento de los procesos
y metodologías que se emplean
Scrum – roles. Team.
1. Pocos integrantes (7 +/- 2)

2. Equipo multifuncional e interdisciplinario que cubre todas las

habilidades necesarias para generar el resultado

3. Su labor consiste en seleccionar el objetivo final de cada sprint,

especificar los resultados del trabajo y llevarlo a cabo.

4. Trabajan a tiempo completo en un sprint

5. Definen y estiman tareas de cada requerimiento

6. Propietario de la lista de tareas

7. Desarrollan el proyecto de manera conjunta llevando a cabo las

historias a las que se comprometen al inicio de cada sprint.
Componentes - Reuniones
Scrum – reuniones.
I. Sprint planning:

• Reunión previa al comienzo de cada sprint:

 Cuál es el trabajo
 Objetivos a cumplir

• Intervienen todos los roles

• Se genera el “Sprint Backlog” o lista de tareas que se van a

realizar

• Se determina el “objetivo del Sprint” (funcionalidad del

negocio que se va a generar)
Componentes - Reuniones
Scrum – reuniones.
I. Sprint planning:

La planificación de las tareas a realizar en la iteración se divide en dos

partes (¿Qué? y ¿Cómo?):

Primera parte de la reunión, se realiza en un máximo 4 horas :

1. El cliente presenta al equipo la lista de requisitos priorizada del

producto o proyecto, pone nombre a la meta de la iteración y propone
los requisitos más prioritarios a desarrollar en ella.

2. El equipo examina la lista, pregunta al cliente las dudas que le surgen,

añade más condiciones de satisfacción y selecciona los objetivos más
prioritarios que se compromete a completar en la iteración, de manera
que puedan ser entregados si el cliente lo solicita.
Componentes - Reuniones
Scrum – reuniones.
I. Sprint planning:

Segunda parte de la reunión, se realiza en máximo 4 horas:

1. El equipo planifica la iteración (sprint), elabora la táctica que le

permitirá conseguir el mejor resultado posible con el mínimo esfuerzo.
Esta actividad la realiza el equipo dado que ha adquirido un
compromiso, es el responsable de organizar su trabajo y es quien mejor
conoce cómo realizarlo.

2. Define las tareas necesarias, para poder completar cada objetivo,

creando la lista de tareas de la iteración (Sprint Backlog) basándose en
la definición de completado.
Componentes - Reuniones
Scrum – reuniones.
I. Sprint planning:

Segunda parte de la reunión, se realiza en máximo 4 horas:

3.Realiza una estimación, esfuerzo necesario para realizar cada tarea.

4.Cada miembro del equipo se auto asigna las tareas, que puede realizar.

Al final de la reunión todos los

miembros del equipo tienen que tener
claras sus tareas para el sprint, cómo
se determinará que están terminadas y
qué tiempo tienen asignado para
hacerlas.
Componentes - Reuniones
Scrum – reuniones.
II. Revisión de sprint (Sprint Review):

1. Análisis y revisión del incremento generado. Se lleva a cabo al final del

Sprint, donde todo el equipo participa y hay una demo del producto,
tiene una duración máximo de 2 a 4 horas.

2. Reunión informal donde el equipo presenta al cliente los requisitos

completados en la iteración, en forma de incremento de producto.

3. Se presenta al Product Owner las nuevas funcionalidades. Las

funcionalidades no implementadas no se presentan

4. Se genera feedback del producto

Componentes - Reuniones
Scrum – reuniones.
III. Retroespectiva de Sprint:

Con el objetivo de mejorar de manera continua su productividad y la calidad

del producto que está desarrollando, el equipo analiza lo siguiente:

1. ¿Cómo ha sido su manera de trabajar durante la iteración? (al finalizar el

sprint), lecciones aprendidas (ejemplos, oportunidades de mejoras)

2. ¿Por qué está consiguiendo o no los objetivos? a que se comprometió al

inicio de la iteración.

 ¿Qué fue lo bueno y malo del sprint?

 ¿Qué cosas se pueden mejorar?

Componentes - Reuniones
Scrum – reuniones.
III. Retroespectiva de Sprint:

3. ¿Por qué el incremento de producto que acaba de demostrar al cliente era

lo que él esperaba o no?:

 ¿Qué cosas han funcionado bien?

 ¿Cuales hay que mejorar?
 ¿Qué cosas quiere probar hacer en la siguiente iteración?
 ¿Qué ha aprendido?
 ¿Cuales son los problemas que podrían impedirle progresar
adecuadamente?
El gestor de Scrum se encargará de ir eliminando los obstáculos identificados
que el propio equipo no pueda resolver por sí mismo, tiene una duración de 30
minutos (1/2 hora).
Scrum – reuniones.
IV. Reunión diaria (Daily Scrum):

• Máximo 15 min. en la que el equipo se sincroniza para trabajar de

forma coordinada.
• Scrum master es el responsable.
• Está reunión no es para la solución del problema, es para
informar de lo que hace cada miembro responde a tres preguntas:
 Trabajo realizado desde la reunión
anterior
 Trabajo que se va a realizar hasta la
próxima reunión de seguimiento
 Problemas que se deben solucionar
para realizar el trabajo propuesto
Componentes
Scrum - Reuniones
– reuniones.
V. Re planificación del proyecto (Star-Stop-Continue):

 Reunión que se celebra al final del sprint y en la que el equipo presenta

las historias conseguidas mediante una demostración del producto.
Posteriormente, en la retrospectiva, el equipo analiza qué se hizo bien,
qué procesos serían mejorables y discute acerca de cómo
perfeccionarlos.
Componentes
Scrum – Artefactos
– artefactos.
1. Pila del producto (Product Backlog):

 Lo primero que debe hacer el dueño del producto es crear

la pila de producto.

 La pila de producto permitirá tener visualización de las

funcionalidades a desarrollar, priorizar las características
del software según las necesidades del negocio, dejar
registrado el esfuerzo necesario para desarrollar la
historia y asignarla a una iteración (Sprint).

 Hay que tener en cuenta que la lista de

objetivos/requisitos priorizada representa la visión y
expectativas del cliente respecto a los objetivos y entregas
del producto o proyecto.
Componentes
Scrum – Artefactos
– artefactos.
1. Pila del producto (Product Backlog):

 Lista de requisitos (el Qué) denominados historias descritos en

un lenguaje no técnico y priorizados por valor de negocio, o por
retorno de inversión considerando su beneficio y coste. Los
requisitos y prioridades se revisan y ajustan durante el curso del
proyecto a intervalos regulares.

 Todos los integrantes del equipo de desarrollo podrán acceder a

él aportando ideas. Si el equipo identifica un requisito le notifica
al Product Owner, y verifica si tiene un fuerte impacto, de no
tenerlo, lo agregan normal en el Product Backlog, caso contrario
el Product Owner bloquea o para el sprint.
Componentes
Scrum – Artefactos
– artefactos.
1. Pila del producto (Product Backlog):
 El responsable es el Propietario del producto (Product Owner),
quien prioriza. Repriorizada al inicio de cada Sprint
Componentes
Scrum – Artefactos
– artefactos.
1. Pila del producto (Product Backlog):
Ejemplos:

 Como Cliente, quiero suscribirme a un nuevo plan de T.V. por cable por medio del sitio
Web: …..
 Como Cliente, quiero pagar mi suscripción mensual vía sitio web por medio de
transferencia bancaria o tarjeta de crédito
 Como Cliente, quiero suscribirme a un canal de T.V Premium por períodos flexibles de
tiempo por medio del sitio web
 Como Cliente, quiero consultar un listado de las suscripciones de Pay per View que se
han realizado en mi cuenta
 Como Vendedor, quiero registrar los productos y cantidades que me solicita un cliente
para crear un pedido de venta.
 Como Supervisor de ventas, quiero consultar un listado de los pedidos de venta que
han sido registrados y aún no han sido procesados.
Componentes
Scrum – Artefactos
– artefactos.
1. Pila del producto (Product Backlog):
Ejemplo:
Componentes
Scrum – Artefactos
– artefactos.
1. Pila del producto (Product Backlog):
Ejemplo:
Componentes – Artefactos
Scrum – artefactos.
1. Pila del producto (Product Backlog) - Historia de usuario:

Una historia de usuario es una manera simple de describir una tarea

concisa que aporta valor al usuario o al negocio. No se detalla más
hasta el momento que la historias de usuario se vaya a desarrollar

Son descripciones cortas y simples de las funcionalidades del

sistema, narradas desde la perspectiva de la persona que
desea dicha funcionalidad, usualmente un usuario.

La historia de usuario es una invitación a la conversación.

Las historias de usuario permiten crear un vínculo entre usuarios y

desarrolladores de productos.
Componentes – Artefactos
Scrum – artefactos.
1. Pila del producto (Product Backlog) - Historia de usuario, modelo INVEST:

Una buena historia de usuario también sigue el modelo de INVEST: Independiente,

Negociable, Estimable, Pequeña (Small), y Testeable.

Independiente; Una historia debería ser independiente de otras. Facilitan la planificacion,

priorizar y estimación.

Negociable; La "tarjeta" de la historia es tan sólo una descripción corta que no incluye
detalles. Los detalles se añaden mediante la conversación.

Valiosa; Cada historia tiene que tener valor para el cliente (usuario y cliente).

Estimable; El equipo necesita poder estimar una historia de usuario. Historias demasiado
grandes o inconcretas, no se pueden estimar.

Pequeña; Una buena historia debe ser pequeña en esfuerzo, debería ser realizable en
menos de una semana.

Testeable; Una historia necesita poder probarse y saber que la HU se ha completado con
éxito.
Componentes – Artefactos
Scrum – artefactos.
Usamos la formula :

"Como... Quiero (deseo, necesito)... Para... "

Clarifica que se quiere conseguir, a quien aportara valor y porqué

una HU es útil.
Componentes – Artefactos
Scrum – artefactos.
1. Pila del producto (Product Backlog) - Historia de usuario:

Ejemplo:
Como: Bloguero
Quiero: ingresar a mi blog con usuario y contraseña
Para: mantener la seguridad y confiabilidad de la información del blog

Criterios de Aceptación:
 El sistema debe enviarme un correo electrónico para confirmar el cambio de
contraseña
 El usuario debe ser mi dirección de correo electrónico
 El sistema debe bloquear la cuenta cuando haga tres intentos fallidos
consecutivos
 Si olvidé la contraseña, el sistema debe preguntarme por la dirección de
correo asociada a mi cuenta o por mi nombre de usuario y enviarme un enlace
para establecer una nueva contraseña.
Componentes – Artefactos
Scrum – artefactos.
1. Pila del producto (Product Backlog):
Estructura de la historia de usuario:
Componentes – Artefactos
Scrum – artefactos.
1. Pila del producto (Product Backlog):
Estructura de la historia de usuario:
Scrum – errores–alArtefactos
Componentes definir H. U.
1. Definir el rol a quien va dirigida la historia como el “Usuario”

Ejemplo: “Como un Usuario, deseo poder gestionar cuentas de

cliente, con el fin de eliminar cuentas no utilizadas o cuentas
erróneas”.

No podemos saber ¿Quién es la persona para la cual se

desarrollará esta funcionalidad?, ¿es un administrador de un
canal virtual de atención al cliente que necesita una lista de
clientes para actualizarlas?

Las expectativas del sistema pueden ser muy diferentes según se

defina el rol para quien se desarrolla la historia, por lo que es
muy importante definirlos específicamente, evitando roles
genéricos "El Usuario".
Scrum – errores–alArtefactos
Componentes definir H. U.
2. Definir el rol a quien va dirigida la historia como el “Product
Owner”

Ejemplo: ¿Cómo Product Owner, quiero que el sistema tenga la

posibilidad de eliminar cuentas del cliente, con la finalidad que
los usuarios puedan eliminar las cuentas de cliente?

El “Product Owner Quiere”, pareciera ser una historia que se

escribió porque alguien la quería y no porque realmente la
necesitaba. Luego, una historia no puede ser dirigida al Product
Owner (este es un representante de las necesidades de los
usuarios de las áreas de negocio), no se le asigna un rol claro a
la persona que permita establecer sus expectativas.
Scrum – errores–alArtefactos
Componentes definir H. U.
3. Definir el rol a quien va dirigida la historia como el
“Desarrollador”

Ejemplo: “Como desarrollador, yo quiero reemplazar el Widget

(pequeña aplicación) de Barra para seleccionar productos, con
la finalidad de dar mantenimiento al Widget de barra para
seleccionar productos”.

Si describimos estás historias técnicas de la forma en que se

presenta en el ejemplo, no estamos agregando ningún valor al
cliente, por lo que no obtendremos el apoyo del Product Owner
y muchos menos de los usuarios del área de negocio.
Scrum – errores–alArtefactos
Componentes definir H. U.
3. Definir el rol a quien va dirigida la historia como el
“Desarrollador”

¿Cómo escribir esta historia de forma correcta?, por ejemplo

podría hacerse de la siguiente forma:

“Como un usuario comercial, yo necesito poder ver

múltiples productos en una misma barra y poder
seleccionarlos, para poder hacer mi selección de forma más
rápida”.

Luego de describir la historia, describiríamos tareas como

"Hacer Refactorización del mecanismo para incluir los
productos en el widget de barra de productos" y luego
"actualizar la versión de Java", entre otras.
Scrum – errores–alArtefactos
Componentes definir H. U.
3. Definir el rol a quien va dirigida la historia como el
“Desarrollador”

Los criterios de aceptación deben ser medibles y verificables

mediante pruebas, por ejemplo,

“el usuario puede ver en la barra 5 productos en una misma

vez” y “al presionar el botón para mover la barra, el usuario
puede recorrer cinco productos en menos de 5 segundos”.
Otro criterio pudiera ser, “al hacer click sobre el producto, la
página de detalle del producto se muestra en menos de 4
segundos”.
Scrum – errores–alArtefactos
Componentes definir H. U.
4. No describir el valor para el negocio o beneficio

Ejemplo: “Como vendedor de libros, quiero una opción de

filtrado”.

En este ejemplo, tenemos el rol, tenemos la necesidad, pero

falta la razón y el valor de negocio.

¿Por qué un vendedor quiere una opción de filtrado?,

¿Qué objetivo necesita alcanzar con eso?,

Necesitamos describir este valor o funcionalidad en las historias

de usuario para que los desarrolladores cuenten con más
información sobre las expectativas de los usuarios.
Scrum – errores–alArtefactos
Componentes definir H. U.
5. No establecer los criterios de aceptación o condiciones de
satisfacción
Cada historia de usuario, debe ser documentada con sus
criterios de aceptación o condiciones de satisfacción, no
hacerlo, puede ocasionar una definición inadecuada de las tareas
o estimación errónea. Como resultado, los casos de prueba no
cubrirán los criterios adecuados debido a un entendimiento
erróneo.

Los criterios de aceptación juegan un papel importante en la

confirmación del entendimiento del requerimiento.

En la medida en que se descubren estos criterios de aceptación,

es posible que las historias necesiten ser refinada, re
planificadas o divididas en varias historias.
Componentes – Artefactos
Scrum – artefactos.
2. Pila del sprint (Sprint Backlog):

1. Lista de las tareas necesarias para llevar a cabo las historias del sprint. El equipo
elabora en la Reunión de Planificación de la iteración (Sprint Planning) como plan
para completar los objetivos y requisitos seleccionados para cada iteración y que se
compromete a demostrar al cliente al finalizar la iteración, en forma de incremento de
producto preparado para ser entregado.

2. Requerimientos detallados a mas bajo nivel (el Cómo)

Componentes – Artefactos
Scrum – artefactos.
Pila del sprint – pila producto. Ejemplo:

 Asignación de tareas de forma personal con estimación de

tiempos y recursos necesarios.
Scrum – artefactos.
3. Incremento:

El Incremento es la suma de todos los elementos del Product

Backlog completos durante un Sprint, más el valor de todos los
Incrementos anteriores. Al final de un Sprint, el nuevo
incremento debe poder marcarse como "Terminado", lo que
significa que debe estar en condición de ser utilizable e
independientemente de que el Product Owner decida o no
liberarlo.
Componentes – Artefactos
Scrum – herramienta.
1. Gráficos de trabajo pendiente (Burn Down
chart):

El diagrama de Burndown sirve para saber el Horas restantes

tiempo que falta para completar el trabajo. Se
utiliza para saber cuánto falta para terminar las
historias comprometidas en un sprint.

Datos que muestra:

 Las versiones previstas de un producto
 Velocidad estimada
 Fechas probables para cada versión
 Margen de error previsto en las
Tiempo
estimaciones
 Avance real
Scrum – herramienta.
El tablero de tareas (Scrum Taskboard)
El sprint backlog es visible al ponerlo en una tabla de tareas Scrum. Los
miembros del equipo actualizan la tabla de tarea continua durante todo el
sprint; si alguien piensa en una nueva tarea ("Prueba el código en Windows
8.1"), escribe una nueva tarjeta y la coloca.
Scrum – herramienta.
El tablero de tareas (Scrum Taskboard)
Cada fila en el tablero Scrum es una historia de usuario, que es la unidad de
trabajo y animamos a los equipos a utilizarlo para su cartera de productos.
Acta de constitución de proyecto (Project Charter)

 Cuando se da inicio a un proyecto, es necesario definir qué es lo que se

espera lograr y cuál será el alcance para lograrlo. Cada proyecto se inicia
con una idea, visión u oportunidad de negocio, que representa el punto de
partida y debe estar asociado con los objetivos de negocio de la
organización.

 El acta de constitución del proyecto (Project Charter) es el documento en el

cual se documenta ese punto de partida, la relación entre estrategia
organizacional y el alcance del proyecto, así como la relación de
colaboración que existirá entre la organización solicitante del proyecto y la
organización ejecutora.

 El acta de constitución de un proyecto documenta las necesidades del área

de negocio (el cliente) que dieron origen a la iniciativa, las premisas
(supuestos), restricciones (de tiempo, presupuesto, etc.), los requisitos de
alto nivel del cliente y los requisitos de alto nivel del producto, servicio
o resultado que el proyecto debe proporcionar.
En resumen:
Componentes
Scrum – Artefactos
– artefactos.
Los 3 principales artefactos de Scrum son:

Product backlog – pila del producto

 Lista que contiene todos los requerimientos que necesitamos implementar en
el producto.
 Priorizar aquellos elementos que tienen más valor en cada etapa
 Puede contener sólo los requisitos inicialmente conocidos y mejor entendidos

Historia de usuario.

Sprint backlog – pila del sprint.

 Lista de tareas técnicas para trabajar en cada Sprint
 Visualizar el trabajo a realizar durante cada Sprint

Incremento – funcionalidad.
Resultado del Sprint
Concertación del Historia de usuario
Componentes
Scrum – Artefactos
– ceremonias o eventos.
Las 4 principales ceremonias de Scrum son:

Planificación de Sprint.
Se definen los objetivos del proyecto y producto final
Se realiza la gestión de los requerimientos
Priorizar y definir lo que se entregara por cada Sprint

Scrum diario o Standup diario.

Todos conozcan el progreso del Sprint y siempre esté sincronizado
Inspeccionar el progreso y asegurarse de que todos logren el objetivo del sprint.
Responde a: ¿Qué hice ayer? y ¿Qué haré hoy?

Revisión de Sprint.
Antes de enviar a producción
Mostrar su progreso y cómo beneficiará al usuario final

Retrospectiva de Sprint.
El objetivo es mejorar para futuros sprints
Responder a: ¿Qué salió bien durante el último sprint?, ¿Qué se podría haber hecho mejor
en el último sprint? y ¿Qué no salió bien en el sprint anterior?
Componentes
Scrum – Artefactos
– ceremonias o eventos.
4 ceremonias de Scrum:
Componentes
Scrum – Artefactos
– herramientas.
Principales herramientas:

Burn down Chart – gráfico de seguimiento, gráfico de trabajo pendiente.

Monitorear el progreso (trabajo) del Sprint hacia el Objetivo del Sprint.
Muestra la velocidad con la que se están completando las historias de usuarios

Scrum Board - tablero de Scrum.

Se actualizan en una pizarra las tareas técnicas para la implementación de cada
Historia de usuario. To Do – In progress – Done.
Sprint 0.
El sprint 0 no produce una funcionalidad del producto, en el se desarrolla la
arquitectura ágil básica para que los incrementos de los siguientes sprints puedan añadir
valor de forma eficiente al producto. Se incluye tareas de análisis y diseño,
investigación y selección de herramientas, entre otros. Paso previo al desarrollo de un
proyecto Scrum.

Ejemplo de artefactos y/o entregables.

 Acta de constitución del proyecto – Project Charter

 Lista de requerimientos funcionales – Product backlog, historias de usuario - épicas
 Lista de requerimientos no funcionales – Requerimientos técnicos
 Lista de iteracciones – Sprint Backlog (tareas técnicas por Sprint)
 Definición del tablero de Scrum - Scrum Board
 Definición del gráfico de seguimiento - Burn Down chart
 Artefactos de diseño
Herramientas ágiles:
Conclusiones.
 Los roles, eventos, artefactos y reglas de Scrum son inevitables. Si solo se
implementan algunas partes de Scrum, el resultado no es Scrum. Scrum debe
implementarse en su totalidad y funciona bien si está alineado con otras técnicas,
metodologías y prácticas.

 Scrum no genera todos los artefactos del producto final para el desarrollo de una
aplicación o software, por lo tanto debe de complementarse con otras herramientas
tecnologicas y la integración se representa en un EDT que mostrara los pasos de la
metodología que se llevo a cabo para la generación del resultado final en el
producto como tangible.

 Ayuda mucho elaborar una lista de cotejo, donde se muestre la etapa, actividad,
artefacto generado como producto del despliegue de las actividades realizadas, las
metodologías y herramientas tecnologicas utilizadas para generar el artefacto o
producto intermedio.

 Los criterios de aceptación, indican qué pruebas (validación) se llevarán a cabo para
poder decir que la Historia de Usuario se ha completado con éxito, no debe dejar de
considerar las excepciones, reglas de neglocio y observaciones.
Scrum – referencias:
Scrum Process. Obtenido de: https://docs.microsoft.com/en-
us/azure/devops/boards/work-items/guidance/scrum-process?view=azure-devops

ÁGIL ES ALGO QUE ERES…: https://luchosalazar.com/category/agilidad/page/3/

Scrum

M. Sc. Ing. Gener Zambrano