SCRUM
Dra Virginia Lagunes Barradas
viclag@[Link]
Contenido
1. Lean, Agile and Scrum
2. Marco de Referencia SCRUM
3. Scrum Team
1. Product Owner
2. Development Team
3. Scrum Master
4. Scrum Events and Artifacts
1. Sprint and Increment
2. Sprint Planning
1. Producto Backlog
2. Sprint Backlog
3. Definition of Done (DoD)
3. Daily Scrum
4. Sprint Review
5. Sprint Retrospective
Historia (1)
• En 1986 Takeuchi y Nonaka publicaron el artículo “The New Product
Lean, Agile and Scrum
Development Game”, ([Link]
development-game) – Equipo rojo
• Da a conocer la nueva forma de gestionar proyectos (agilidad, flexibilidad,
reducción de incertidumbre)
• Empresas tecnológicas del mismo entorno que realizaban productos en
menos tiempo, de buena calidad y con menor costo.
• Honda, HP, Canon -> No hay fases, se parte de requisitos generales y se
realiza por equipo multidisciplinar.
• Colaboración de equipo de Rugby y la utilización de una formación
denominada Scrum.
• Marco de Referencia SCRUM
Historia (2)
• Scrum aparece como una práctica destinada a los productos tecnológicos y en
Lean, Agile and Scrum
1993 Jeff Sutherland la aplica como un modelo de desarrollo de software en
Ease/Corporation.
• En 1996, Jeff Sutherland y Ken Schwaber presentarn las prácticas que se
usaban como un proceso formal para el desarrollo de software y que se
incluyeron en el Manifiesto Ágil – 12 principios. (Equipo verde)
[Link]
• Desde 1995 miles de proyectos en todo el mundo utilizan Scrum (startups o
multinacionales):
Historia de
SCRUM Personaje
Fecha Aportación
1986 Hirotaka Takeuchi e Ikujiro Aproximación holística para desarrollo de nuevos
Nonaka productos comerciales, hacen referencia al rugby como
ejemplo de juego en equipo
1991 De Grace y Stahl Wicked Problems, Righteous Solutions (aproximación
SCRUM)
90´s Ken Schwaber Advanced Development Methods
90´s Jeff Sutherland Easel Corporation (primero en denominar una
aproximación al framework “SCRUM)”.
1995 Sutherland y Schwaber Scrum (producen serie de artículos describiendo
SCRUM)
2001 Schwaber y Mike Beedle Agile Software Development with SCRUM (describieron
la metodología en este libro).
2002 Ken Schwaber and Mike Cohn SCRUM Alliance
2010 Ken Schwaber Busca combatir las debilidades de SCRUM, al tener
diferencias con SCRUM Alliance crea SCRUM ORG.
Historia (3)
Lean, Agile and Scrum
Sectores Ejemplos de empresas que utilizan metodologías ágiles como Scrum
Media y BBC, BellSouth, British Telecom, DoubleYou, Motorola, Nokia, Palm,
Telecomunicaciones Qualcomm, Schibsted, Sony/Ericsson, Telefonica I+D, TeleAtlas,
Verizon
Software, Hardware Adobe, Autentia, Biko2, Central Desktop, Citrix, Gailén, IBM, Intel,
Microfocus, Microsoft, Novell, OpenView Labs, Plain Concepts,
Primavera, Proyectalis, Softhouse, Valtech, VersionOne.
Internet Amazon, Google, mySpace, Yahoo
ERP SAP
Banca e Inversión Bank of America, Barclays Global Investors, Key Bank, Merrill Lynch
Sanidad y Salud Patientkeeper, Philips Medical
Defensa y Boeing, General Dynamics, Lockheed Martin
Aeroespacial
Juegos Blizzard, High Moon Studios, Crytek, Ubisoft, Electronic Arts
Otros 3M, Bose, GE, UOC, Ferrari
Soluciones LEAN de
Manufactura
• Kanban
(Morado)
• Kaizen
(Amarillo)
• Lean (Azul) Deming Robot Toyota
(Gris)
• Andon (Azul)
Tom y Mary Poppendieck
[Link]
[Link]
[Link]
y%20entregados.
[Link]
¿Por qué se dice que es ágil?
• Veloz
• Adaptable
• Compacto
• En búsqueda de Valor!!!
“Agile Manifesto”
We are uncovering better ways of
implementing and developing
complex solutions by doing it and helping
others do it.
Through this work we have come to value:
Individuals and interactions
over processes and tools
Working Components
over comprehensive documentation
Customer collaboration
over contract negotiation
Scrum
Responding to change Mike Beedle
over following a plan Ken Schwaber
Jeff Sutherland
That is, while there is value in the items
in white, we value the items in yellow more.
“Agile Manifesto”
Estamos descubriendo formas mejores de desarrollar software tanto por nuestra
propia experiencia como ayudando a terceros.
A través de este trabajo hemos aprendido a valorar:
ü Individuos e interacciones sobre procesos y herramientas
ü Software que funciona sobre documentación exhaustiva
ü Colaboración con el cliente sobre negociación de contratos
ü Responder al cambio sobre seguimiento de un plan
SCRUM
Scrum (s): Es un marco de trabajo que permite atender y resolver problemas
complejos, proponiendo soluciones creativas y productivas con el fin de entregar
productos con el mayor valor posible.
ü Ligero
ü Fácil de entender
ü Difícil de Dominar
Útil para:
ü Trabajar con requerimientos cambiantes.
ü Donde se necesita obtener resultados pronto.
ü Proyectos en entornos complejos.
¿Qué es SCRUM?
ENERO FEBRERO MARZO
Todos los roles participan
Pilares SCRUM
“Transparencia” “Adaptación” “Inspección”
Las Promesas de SCRUM
“Siempre entregar VALOR”
“Nunca entregar después de TIEMPO”
“Permitir constantemente la VISIBILIDAD”
Principios SCRUM
ü Disciplina
ü Espíritu de equipo
ü Objetivo claro
ü Mismas reglas para todos
ü Diversión
ü Entrega de resultados
Criterios de Aplicación SCRUM en una Cultura Org =>
SHIFT MIND!!!
• Colaborativa • Jerárquica
• Desarrollo • Competitiva
Criterios de Aplicación SCRUM
Framework
Un framework, es un conjunto estandarizado de
conceptos, prácticas y criterios para enfocar un
tipo de problemática particular que sirve como
referencia, para enfrentar y resolver nuevos
problemas de índole similar.
Framework de SCRUM
SCRUM Team
• Product Owner
• Scrum Master
• Development Team
Eventos
• Sprint planning
• Sprint review
• Sprint retrospective
• Daily scrum
Artefactos
• Product backlog
• Sprint backlog
• Incremento***
¿Porque SCRUM NO es un proceso o una metodología?
La agilidad implica una transformación cultural
mientras que la metodología implica un proceso
basado en pasos predefinidos.
La metodología no fomenta y por el contrario
puede impedir el descubrimiento y empirismo.
Programación Tradicional
Enero Febrero Marzo Abril Mayo Junio Agosto Sep. Oct. Nov. Dic.
Análisis de
Requerimientos
Diseño
Código
Dr. Winston Integración
Royce:
Managing the
Development of Pruebas
large SW systems
Despliegue
Programación con Scrum
Enero Febrero Marzo Abril Mayo Junio Agosto Sep. Oct. Nov. Dic.
SPRINT SPRINT SPRINT SPRINT SPRINT
Análisis Análisis Análisis Análisis Análisis
Diseño Diseño Diseño Diseño Diseño
Código Código Código Código Código
Integración Integración Integración Integración Integración
Pruebas Pruebas Pruebas Pruebas Pruebas
Despliegue Despliegue Despliegue Despliegue Despliegue
Entregables en Scrum
SCRUM Team
Scrum Team
Framework de SCRUM
SCRUM Team
• Product Owner
• Scrum Master
• Development Team
Eventos
• Sprint planning
• Sprint review
• Sprint retrospective
• Daily scrum
Artefactos
• Product backlog
• Sprint backlog
• Incremento***
Valores
ü Transparencia
ü Respeto profesional
ü Autoadministración (empowerment)
ü Compromiso
ü Entrega de resultados (valor)
Product Owner
ü Es el representante de todas las personas interesadas en los
resultados del proyecto
ü Decide cuándo tiene sentido implementar o liberar funcionalidad a
los clientes al final de cada Sprint.
Es el encargado principal del: PRODUCTO
Development Team
ü Es el grupo de personas encargadas
principalmente de desarrollar el Proyecto
Scrum Master
ü Es el encargado principal de vigilar, promover e
impulsar la aplicación del Framework
Comprometidos vs Involucrados
Ciclo de Vida SCRUM
El desarrollo es iterativo (Sprints) en Scrum, se prioriza cada uno de los
desarrollos en base a las necesidades/objetivos del cliente.
Scrum Master - Development
Team
Facilitar eventos Scrum
Coaching equipos auto organizados
Ayudar en la mejor comprensión del
Scrum marco Development
Master Team
Facilitar y eliminar impedimentos
Scrum Master - Product
Owner
Entender y practicas la agilidad
Sugerir técnicas admón. Product B.
Técnicas de recolección de req.
Scrum Product
Master Owner
Ayudar en comunicar visión y objeticos
Desventajas de roles compartidos
Product Owner
ü Es el representante (una persona) de todas las personas
interesadas en los resultados del proyecto
ü Actúa como interlocutor único ante el equipo, con autoridad para
tomar decisiones.
ü Es responsable del valor de negocio del producto (ROI)
ü Definir los objetivos del producto y proyecto.
ü Define las funcionalidades del producto.
ü Decide cuándo tiene sentido implementar o liberar funcionalidad a
los clientes al final de cada Sprint.
Es el encargado principal del: PRODUCTO
Development Team
ü Equipo auto dirigido (self-managed / self-organizing)
ü Equipo multidisciplinario (cross-functional). Todos pueden colaborar
en las diversas actividades.
ü Tiempo completo en el proyecto.
ü Realizan sus propias estimaciones.
ü Consiste entre 3 a 9 personas.
DEV TEAM
Es el encargado principal de desarrollar el Proyecto =>Producto
Tamaño del Dev Team
Instrucciones:
En equipo identifiquen al menos 3 ventajas y 3
desventajas de que el tamaño de un Dev Team
sea no menos de 3 y no mas de 9 personas y
expongan sus opiniones.
Actividad
Scrum Master
ü Remover los impedimentos.
ü Apoyar en las técnicas y prácticas Scrum.
ü Ayudar a mantener al equipo enfocado.
ü Apoyar en la comunicación entre el equipo.
ü Facilitar las reuniones
ü Proteger al equipo
Es el encargado principal de vigilar,
promover e impulsar la aplicación del Framework
Scrum Event & Products
Framework de SCRUM
SCRUM Team
• Product Owner
• Scrum Master
• Development Team
Eventos
• Sprint planning
• Sprint review
• Sprint retrospective
• Daily scrum
Artefactos
• Product backlog
• Sprint backlog
• Incremento
Ciclo de Vida SCRUM
El desarrollo es iterativo (Sprints) en Scrum, se prioriza cada uno de los
desarrollos con base en las necesidades/objetivos del cliente.
Time Box
ü Un evento no puede durar mas allá de una duración Fija
Sprint
ENERO FEBRERO MARZO
Todos en el SCRUM TEAM participan
Sprint
ü Duración Fija (se negocia Alcance, no fechas)
ü promueve la entrega exitosa del objetivo del sprint
ü Ayuda al Scrum Team a aprender a entregar incrementos valiosos de forma iterativa
ü No mas de un mes calendario
ü No tan largo que el riesgo es inaceptable para el Product Owner.
ü No tan largo que otros eventos de negocio no puedan ser rápidamente
sincronizados con el trabajo de desarrollo.
ü El propósito de un Sprint es el producir un incremento terminado
(DONE) del producto
Incremento
ü Funcionalidad adicional en un estado utilizable que complementan las
entregadas en iteraciones previas.
Cancelación del Sprint
¿Cuál de las siguientes opciones es correcta?:
a) Cuando el Product Owner determina que no tiene sentido
terminarlo.
b) Cuando Ventas tienen una nueva oportunidad importante.
c) Cuando está claro al final del Sprint que no todo estará
completado.
d) Cuando el Equipo siente que el trabajo es demasiado duro
¿Quién puede cancelar un sprint?
PRODUCTOS - PRODUCT BACKLOG
Product Backlog
El Product Backlog es una lista ordenada de todo lo que debe contener el producto
(Solución).
Cualquiera puede sugerir o añadir elementos al Product Backlog, sólo el Product
Owner los valida.
PBI: Producto Backlog Items
Product Backlog
El PBI debe ser: Item
ü Completo ALTA Product Backlog
ü Ordenado PRIORIDAD Item
ü Poco detallado Product Backlog
Item
BAJA Product Backlog
PRIORIDAD Item
Product Backlog
Item
SCRUM Product
Master Owner
Taller de Historias de
Requerimientos Usuario
Product Sprints
BackLog Iteraciones
Historias de Usuario
Nombre de la Historia de Usuario Categoría
Descripción de la función o servicio desde la perspectiva de
un rol.
a
*Notas: Descripciónón de Notas o Comentarios
Esfuerzo Estimado
Propietario Prioridad
Criterios de Aceptación
Artefactos
Descripción de los Criterios que hacen Válida y/o (Tantos como
Completa la Historia de Usuario
sea Necesario)
a
*Notas: Descripción de Notas o Comentarios
Historias de Usuario
Realizar las siguientes consideraciones:
ü Es importante redactar de manera corta y concreta la funcionalidad, servicio o
capacidad que requiere el cliente utilizando su jerga.
ü Representan un acuerdo entre el product owner y el dev team
Criterios INVEST
Independiente.- una historia debería ser independiente de otras.
Negociable.- una historia es negociable, no incluye detalles.
Valiosa.- cada historia debe de tener valor.
Estimable.- una historia de usuario deberá ser clara para una posterior
estimación.
Small (pequeña).- generalmente representan un sólo escenario.
Test (comprobable).- una historia necesita ser medible y comprobable.
Identificación de
Requerimientos
Instrucciones:
Reunirse en equipos.
1. Leer el caso de estudio.
2. Identificar los requerimientos.
3. Priorizar los requerimientos.
4. Ordenar los requerimientos.
Actividad
Ordenamiento de las HU
El ordenamiento debe ser por valor de negocio y secuencia
**Se puede invitar a los Stakeholders
Técnica: MoSCoW
Must Have – Se debe tener la característica, es crítica!
Should Have – Requerimientos importantes pero NO cruciales para el reléase.
Could Have – Requerimientos deseables pero no necesarios para el reléase.
Wont Have – Los menos críticos para el producto, “agradables” pero prescindibles,
a veces incluso no alineados a la estrategia del producto.
Técnica: MosCow
Instrucciones:
Reunirse en equipos.
1. Leer el caso de estudio.
2. Identificar los requerimientos.
3. Priorizar los requerimientos.
4. Ordenar los requerimientos.
Actividad
EVENTOS - SPRINT PLANNING
Sprint Planning Meeting
Product Backlog
¿Qué se hará?
• Analizar y evaluar el Product Objetivo del
Tecnología Backlog Sprint
• Seleccionar el Objetivo del Sprint
Condiciones del
• Elegir Backlog items
Negocio
Producto Actual ¿Cómo se hará?
• Decidir como alcanzar el objetivo El trabajo
del Sprint detallado
• Crear el Sprint Backlog
Capacidad del
• Estimar Sprint Backlog en horas
Equipo
Sprint Planning Meeting
ü Dividir la reunión en dos
ü Time box de 4 horas cada sesión.
Sprint Planning Meeting
En la reunión de planeación se espera tener como resultado lo siguiente:
Definir Definir
Definir Meta
duración de historias del
de Sprint
Sprint Sprint
Asistentes:
• Product Owner
• Development Team
Decidir QUÉ
Product
Backlog
¿Qué se hará?
• Analizar y evaluar el Product
Objetivo del
Tecnología Backlog
Sprint
• Seleccionar el Objetivo del
Sprint
Condiciones del • Elegir Backlog items
Negocio
Producto ¿Cómo se hará?
Actual • Decidir como alcanzar el
objetivo del Sprint
• Crear el Sprint Backlog
Capacidad del • Estimar Sprint Backlog en
Equipo horas
Decidir QUÉ
2 3 4
** Pasos reunión Sprint Planning Meeting 1.
Criterios PBI
PBI Significa “Product Backlog Items” y son un determinado número de
elementos del PBI seleccionados por el Development Team considerando los
siguientes criterios:
Objetivo del Sprint
¿Por qué vale la pena este esfuerzo?
Será necesario desarrollar una narrativa pensando en futuro que
justifique todo el esfuerzo que se hará en el Sprint.
Técnica: Planning Poker
Instrucciones:
Estima el tamaño de las historias de usuario y
desarrolla un draft de planeación del 1er sprint
basado en la técnica de planning poker
Actividad
Sesión 1 Sprint Planning
Meeting
La reunión termina cuando tenemos lo siguiente:
1 Objetivo del Sprint
2 PBI Seleccionado
Scrum Team de
3 acuerdo
Sesión 2 Sprint Planning
Meeting
Product
Backlog
¿Qué se hará?
• Analizar y evaluar el Product
Tecnología Backlog
• Seleccionar el Objetivo del
Sprint
Condiciones del • Elegir Backlog items
Negocio
Producto ¿Cómo se hará?
Actual • Decidir como alcanzar el
objetivo del Sprint El trabajo
• Crear el Sprint Backlog detallado
Capacidad del • Estimar Sprint Backlog en
Equipo horas
Decidir CÓMO
1 2 3
**Pasos reunión Sprint Planning Meeting 2.
PRODUCTOS - SPRINT BACKLOG
Atributos SBL
Atributos del Sprint Backlog:
Sprint Backlog
Es en lo que hemos acordado hacer durante el Sprint.
Elementos del PB
No Iniciado En Progreso Completado
acordados
Product Backlog
Item
Product Backlog
Item
Product Backlog
Item
Product Backlog
Item
QUÉ CÓMO
Características Sprint Backlog
1. Contiene el desglose de lo que se tiene que hacer a detalle
a partir de las historias que se encuentran en el Product
Backlog.
2. Entrega un resultado de valor para el Product Owner
durante un tiempo delimitado llamado “Sprint”.
3. No se asignan las tareas a los miembros del equipo.
Detallando Historias en Tareas
Las historias son desglosadas en tareas que pasarán a ser parte del Sprint
Backlog.
H1 H2
Historias
H3 H4
Tareas T1 T2 T3 T1 T2 T3
Detallando Historias en Tareas
Historias:
H H
Responsable
Product
H H
Owner
Tareas:
T T T
Responsable
T T T
Development
Team
Sprint Backlog
Delimitación
ü Suma de esfuerzo de las historias debe ser < = Capacidad del
Equipo.
ü Ordenando en función de lo que se realiza primero o es más
importante
** Investigar sobre el concepto de WIP = Work in Progress de LEAN
Sprint Backlog
Instrucciones:
Juntarse en equipos.
• Detallar las tareas de las 3 Historias de
Usuario mas prioritarias del PB.
• Estimar el esfuerzo.
• Crear el Sprint Backlog. Actividad
Ordenamiento (1)
Las historias y tareas pueden publicarse en la pared, lo cual hace más interactiva la
planeación. El uso del tablero ayuda a que el equipo se sienta más involucrado.
Los tableros y elementos que se pegan en la pared tienen la intensión de comunicar y
generar Visibilidad en el equipo, se conocen comúnmente como “Radiadores de
Información”
Más importante Menos importante
Migration Back Office Back Office
Deposit Withdraw
Tool Login User Admin
Ordenamiento (2)
Más importante Menos importante
Migration Back Office Back Office
Deposit Withdraw
Tool Login User Admin
T T T T T T T
T T T T
T T
Ordenando Elementos
Instrucciones:
Juntarse en equipos.
• Ordena los elementos del Sprint Backlog.
Actividad
Recomendaciones
Duración: ü Se pueden realizar sprint largos hasta de 1 mes. (no
mas de eso)
ü Las fechas NO se recorren.
ü El equipo está en modo de aprendizaje
siempre!
ü El equipo debe ser humilde con sus
estimaciones.
ü El alcance puede variar pero no el tiempo.
Sesión 2 Sprint Planning Meeting
La reunión termina cuando tenemos lo siguiente:
1 Compromiso del equipo
2 El Sprint Backlog**
** el SB suficiente para que el Dev Team pueda crear su mejor previsión de lo que
realizará, y lo suficiente como para poder trabajar en el Sprint por varios días.
DoD - Criterio de Terminación del Sprint
Se debe de llegar a un acuerdo en cuanto al significado de “Terminado” en el
Sprint. Los responsables son el Product Owner y el Development Team
Definition of Done
ü Cada equipo es responsable de establecer los criterios de aceptación de cuando o
cómo se considera que una HU está completamente terminada.
ü Este conjunto de criterios se les conoce como “Definition of Done” (DoD)
ü DoD es dinámico y es esperado que conforme el producto vaya evolucionando sprint
tras sprint, así también pueda evolucionar el DoD.
ü En multi-equipos trabajando en el mismo producto cada equipo podrá contar con un
DoD pero que en conjunto resulte en un DoD que potencialmente sea
implementable.
Un ejemplo de elementos que pueden estar incluidos en DoD:
• Estimar el volúmen Generar Documento de Arquitectura
• Pasar criterios INVEST Hacer pruebas de integración
• Escribir código, Hacer notas del release
• Hacer pruebas unitarias etc.
Definition of Done
Algunas consecuencias de no tener bien definido un DOD:
ü El Dev Team no sabrá cuántos PBIs podrá hacer en un Sprint
ü El Product owner no sabrá que revisará en el Sprint Review
ü El Product owner será incapaz de medir el progreso de sus objetivos
ü El Dev Team no sabrá el trabajo implicado en completar los PBIs seleccionados
Tablero de Control
Kanban Board
Kanban Board
EVENTOS - DAILY SCRUM
EVENTOS DAILY
- DAILY
SCRUM SCRUM
DAILY SCRUM (1)
l 3 Preguntas importantes:
1 • ¿Qué hiciste ayer?
2 • ¿Qué vas a hacer hoy?
3 • ¿Qué problemas has
tenido?
DAILY SCRUM (2)
Características:
ü Todos los días en un mismo lugar a una misma hora.
ü Timeboxing 15 minutos
ü Se recomienda permanecer de pie durante la sesión.
ü No es para solución de problemas (Estos pueden anotarse para su posterior solución).
ü Sólo los miembros del SCRUM TEAM (Development Team, Scrum Master y Product
Owner) pueden participar.
ü Los únicos requeridos en la reunión es el Dev Team.
DAILY SCRUM (3)
Adicionalmente:
ü Es posible identificar riesgos y sugerencias/acciones para mitigarlos, confrontarlos o
evitarlos.
ü Es importante que las actividades que se hayan hecho o se vayan a realizar se
comuniquen a todos los miembros del Dev team.
ü Es responsabilidad de cada miembro transmitir, responder y clarificar las dudas o
comentario que pudiese surgir durante el daily.
ü Usualmente es útil tener Kanban board físico y/o electrónico durante la reunión y
actualizar los avances.
MONITOREO DEL PROGRESO
Seguimiento tradicional vs
SCRUM
El seguimiento tradicional en los proyectos se da enfocado al tiempo que ya se
ha trabajado. En Scrum se ve el avance mediante el tiempo que queda para
terminar.
De esta manera tenemos la oportunidad de recalcular el plan de trabajo y la
rapidez con que hacemos el trabajo. Así, el equipo puede decidir si trabajar más
rápido o más lento para lograr el objetivo de la fecha.
VS
BURNDOWN Chart
El BURNDOWN es..
ü Un tipo de gráfica de volumen de trabajo
pendiente a lo largo del tiempo que
muestra la velocidad a la que se está
completando los
objetivos/requerimientos.
ü Permite extrapolar si el equipo podrá
completar el trabajo en el tiempo
estimado.
ü El objetivo principal es estimar y aprender
no necesariamente incrementar la
velocidad.
Gráfica de Burndown (1)
Se pueden utilizan los siguientes gráficos de esfuerzo pendiente:
ü Valor pendiente para completar los requerimientos del producto o
proyecto (product burndown chart), realizado a partir del Product
Backlog.
ü Horas pendientes para completar las tareas de la iteración (sprint
burndown chart), realizado a partir del Sprint Backlog.
Gráfica de Burndown (2)
Algunas Características:
ü Para nuevos requerimientos la línea de progreso será descendente
ü La línea de progreso debe ser descendente hasta llegar al eje de las X’s.
ü Si existen cambios la pendiente variará o podrá valer 0.
ü Para tener un seguimiento cercano se recomienda actualizarlo diariamente.
Gráfica de Burndown (3)
Esta grafica en su eje “X” se refiere al tiempo y representa la duración de un Sprint
(Días).
En su eje “Y” se refiere al volumen de tamaño (trabajo) que queda pendiente en un
Sprint.
Desviación
La desviación se representa mediante un grafico de avance que se aleja ya sea
positiva o negativamente de la diagonal de lo planeado(Ideal).
Sabemos que avanzamos si el
número de horas de esfuerzo
disminuyen
EVENTOS - SPRINT REVIEW
SPRINT REVIEW (1)
Demostración de producto completado
(Sprint Review)
ü Se lleva acabo al final del Sprint
ü Time box de 4 horas para un Sprint de un mes.
ü Se presenta el objetivo del Sprint.
ü La sesión va intencionada a revisar el producto y
relacionarlo a la definición de terminado(DoD).
ü Se revisa el avance logrado (PBDC).
ü Los involucrados (clientes) deben Inspeccionar el
producto.
ü Mencionar errores solucionados.
ü Se identifican cambios.
SPRINT REVIEW (2)
Beneficios
ü El cliente ve un avance temprano del producto y así dar retroalimentación.
ü El equipo puede ver si entendió realmente los requerimientos iniciales.
ü El equipo no esta meses trabajando sin poder mostrar su producto.
ü Se puede identificar de que manera mejorar la comunicación entre el
equipo y el cliente.
ü Se integran nuevos cambios de ser necesario.
EVENTOS - SPRINT RETROSPECTIVE
Sprint Retrospective (1)
Esta reunión es para..
ü Mejorar la comunicación del equipo.
ü Identificar todas las lecciones aprendidas del Sprint.
ü Mejorar el proceso.
ü Obtener el compromiso de todo el equipo.
ü Incrementar la creatividad del equipo.
Sprint Retrospective (2)
ü Tiene un Timeboxing de no más de 3 horas.
ü Se realiza al termino de cada Sprint.
ü El Scrum Team participa.
ü El Scrum Master funge como facilitador de la sesión.
ü Reconocer logros.
ü Reconocer que se puede mejorar.
ü NO es una sesión de culpabilidad ni señalamientos.
ü Planificar hallazgos, ejecutar y dar seguimiento.
Sprint Retrospective (3)
Preguntas que nos hacemos en la reunión:
¿Qué hicimos bien y como queremos mantenerlo?
¿Qué no hicimos tan bien y qué hacemos para solucionarlo?
Sprint Retrospective (4)
¿ QUÉ HICIMOS BIEN ? ¿ EN QUÉ PODEMOS MEJORAR ?
Evaluación y calidad
Algunas Métricas Ágiles útiles
Capacidad del equipo:
ü Esfuerzo ideal colectivo sobre unidad de tiempo seleccionada.
Eficiencia de Planeación:
ü # tareas plan / (# tareas plan + # tareas no
planeadas)
Velocidad
ü Tamaño (O Volumen) colectivo logrado sobre la unidad de tiempo
seleccionada:
ü Ejem: En el 1er sprint de 2 semanas se hizo una historia de usuario de 5
puntos otra de 6 puntos y otra de 9 puntos, la velocidad hasta ese momento
es de 20 puntos / cada 2 semanas.
CALIDAD EN SCRUM
El Testing nos ayuda a validar que lo que se solicito como un requerimiento se este
cubriendo en el sistema.
Pruebas de Software común:
ü Pruebas Unitarias
ü Pruebas Funcionales
ü Pruebas de Regresión
ü Pruebas de Humo
**Las pruebas nos ayudan a conocer la salud del proyecto y a decidir si liberar o
no el producto.
CALIDAD EN SCRUM
Estructura de Equipo Tradicional Estructura de Equipo Ágil
Programadores
Programadores
Tester Analista
Tester Analista
Testing Tradicional
Requerimientos
Cascada
Especificaciones
Código
Pruebas
Despliegue
Tiempo
Testing Ágil
Ágil:
Iterativo e Incremental
ü Cada historia es
expandida,
F
codificada y
E probada.
D D ü Posible release
después de cada
C C sprint.
A B A B A B
sprint 0 sprint 1 sprint 2 sprint 3
Calidad
Si la calidad es importante en el Sprint:
ü Realizar menos desarrollo en cada Sprint para incluir pruebas.
Siempre es más barato producir menos y hacerlo estable,
que hacer mucho pero con menos calidad.
=> DEUDA TÉCNICA !!!!!
Calidad
DEUDA TÉCNICA
Refleja el trabajo de desarrollo extra que surge cuando el
código u otra actividad es más fácil de implementar o de
ejecutar en lugar de desarrollar o ejecutar la mejor solución.
La deuda técnica no atendida incrementa la entropía del
software.
Calidad – Deuda Técnica
DEUDA TÉCNICA
ü Diferentes aspectos, NO sólo son pruebas funcionales!!!
• Estructuras de Datos apropiadas • Glosarios
• Diseño • Pruebas Unitarias
• Arquitectura • Pruebas de Carga
• Refactorización • Pruebas de Volumen
• Uso de Patrones de Diseño • Análisis de Código
• Documentación de Código • Control de Cambios
• Estándares de Código • Análisis de Desempeño
• Análisis de Consumo de
Memoria
Calidad – Deuda
Técnica...posturas
Imprudente,
Temerario Prudente
Deliberado,
intencionado, No hay tiempo para diseñar, Debemos salir para el viernes,
reflexivo Es demasiada documentación, Aceptemos los riesgos,
eso dejémoslo para después Registrémoslos, y tomemos
nota de los posibles impactos
Inadvertido, Bueno, al menos ahora sabemos
desatento ¿Qué es un microservicio? como debimos de haberlo
hecho
Calidad – Deuda
Técnica
Deuda Técnica TCO
vs Costo a lo largo del ciclo de
Valor de Negocio vida del software
Lo que comúnmente sucede..
Usuarios
Finales
1.0.0 1.0.1 1.1.0
Sprint 1 Sprint 2
Propuesta 1
Se añade un periodo de pruebas entre los Sprints en el que solo se ejecutarían
pruebas y correcciones.
Tiempo Extra Tiempo Extra
Sprint 1 Pruebas Sprint 2 Pruebas Sprint 3
Tiempo
** No se inicia el siguiente Sprint hasta que no este en producción
Propuesta 2
Se realizan pruebas durante el Sprint pero adicional al final se añade un periodo
de pruebas en el que todo el equipo se enfoca en probar y corregir.
Pruebas Todo el Pruebas Todo el Pruebas Todo el
equipo equipo equipo
Sprint 1 Sprint 2 Sprint 3
Tiempo
Cambios
Cambios normales:
ü Requerimientos nuevos con valor de negocio se incluyen por el Product
Owner al Product Backlog.
Para detener el Sprint:
ü Costo de continuar el proyecto > valor agregado.
Change For Free:
ü El cliente puede incluir cambios al Sprint mientras estos no
afecten el alcance del Sprint o elimine elementos del mismo
alcance del contrato.
Referencias
l [Link]
7_v2.[Link]
l [Link]
level-release-plan/
l [Link]
[Link]#zoom=100
l [Link]
user-story-mapping-2674be8aeb60
l [Link]
tareas/
l [Link]
l [Link]
producto-mapa-historias-
usuario/#:~:text=Para%20elaborar%20nuestro%20Backlog%20de,se%2
0tratara%20de%20una%20historia.