Formacion Continua-Sesión6-2022-2

Tu futuro es
SCRUM
hoy
José García La Riva

Jefe Académico de InGenio Leaning
Docente:Ing.
Docente: Ing. Hugo
Luis Dávila
EspejoQuispe
Briceño
Alianzas Estratégicas
SCRUM
SCRUM
Semana 4
Importancia del Backlog y
estimaciones
Logro de la sesión
Elaborar historias de usuario y
realizar estimaciones.
SCRUM
AGENDA
1. Características del backlog

2. Historias de usuario
3. Agile testing
4. Definición de Hecho
5. Estimaciones fiables y relativas
SCRUM
¿Qué hicimos la clase anterior?
Jamboard URL:
https://jamboard.google.com/d/1uY1x
bwlg_bQk4Xy062ol5g_mSvqvo3UGh
8uFtcSUQwQ/edit?usp=sharing
SCRUM
Importancia del Backlog
Características del Backlog
❑ ¿Qué es?
❑ Lista ordenada de PBI (Product Backlog Items) que representa al producto.
❑ El Dueño de Producto es el ultimo responsable de la pila de producto.
❑ Es un artefacto VIVO.
❑ Para un producto, sólo habrá una pila de producto, por muchos equipos que haya.
Product Backlog Item
❑ ¿Qué es?
❑ Historia de usuario, épica, historia no funcional, caso de uso, incidencia, requisito,
mejor, corrección.
❑ ¿Qué información deben contener?

❑ ID
❑ Descripción
❑ Priorización
❑ Estimación (si se tiene)
Refinamiento del Backlog
❑ Actividad continuada, pero a veces es necesario un evento.
❑ Si necesitamos un evento = 10 % de la capacidad del equipo.
❑ Consiste en añadir detalle y ordenación al PB.
❑ Asistentes → PO, SM y Equipo de desarrollo.
❑ Consiste en una versión de los elementos que van a entrar en el siguiente

sprint.
❑ Entregable: PB revisado con el equipo de desarrollo.

Definición de Listo (DoR)
❑ ¿Qué es?
❑ Conjunto de hechos que se tienen que dar para que un PBI del backlog se pueda incorporar
en un sprint.
❑ A tener en cuenta:
❑ Historia de usuario definida.
❑ Criterios de aceptación listos.
❑ Dependencias identificadas.
❑ Tamaño definido por el equipo.
❑ El equipo de desarrollo sabe como probar y enseñar esa funcionalidad.
¿Cómo escribir buenos requisitos?
❑ En agile, solemos emplear historias de usuario para la definición de requisitos.
❑ ¿Qué es una historia de usuario?

❑ Funcionalidad que aporta valor al cliente.
❑ Se almacenan en el product Backlog.
❑ Recomendaciones para escribirlas:

❑ Centradas en el usuario y no en la tecnología.
❑ Charla en el ascensor (menos de 30 seg).
❑ Seleccionar el tamaño adecuado: 1 día.
Composición de una Historia de Usuario
❑ ID.
❑ NOMBRE
❑ DESCRIPCIÓN
❑ “Como <rol de usuario>
❑ Quiero <función del sistema>
❑ Para <valor de negocio>”
❑ ID.
❑ NOMBRE
❑ DESCRIPCIÓN
❑ “Como <rol de usuario>
❑ Quiero <función del sistema>
❑ Para <valor de negocio>”
❑ PRIORIDAD
❑ ESTIMACIÓN
❑ CONVERSACIÓN: Son conversaciones que explican las
necesidades del usuario al desarrollador. Granularidad muy
fina.
❑ PRUEBAS: ¿Cómo vamos a probar nuestro software?
❑ NOTAS: personas de contacto, teléfono, email
❑ PRIORIDAD
❑ ESTIMACIÓN
❑ CONVERSACIÓN: Son conversaciones que explican las
necesidades del usuario al desarrollador. Granularidad muy
fina.
❑ PRUEBAS: ¿Cómo vamos a probar nuestro software?
❑ NOTAS: personas de contacto, teléfono, email
Modelo INVEST
❑ Una buena historia de usuario deberá satisfacer:
1. Independent: No dependencias.
2. Negotiable: contenido de la historia se genera a partir
de la conversación.
3. Valuable: para el usuario final o el cliente.
4. Estimable: se debe poder determinar su tamaño.
5. Small: duración no superior a 1 semana con 2-3
personas desarrollándola.
6. Testable: NO se desarrolla aquello que no se puede
probar.
5 W’s
❑ Las historia de usuario deben verificar:
1. Who: quien hace la acción.
2. What: que es lo que se va a hacer.
3. When: cuando se va a hacer.
4. Where: en que parte de la aplicación se va a realizar.
5. Why: para que se quiere desarrollar.
❑ Como Nuevo Usuario (who) quiero poder pulsar el botón de registro (what)
situado en la parte superior de la pagina (where) después de arrancar la
pagina inicial de www.contactos.com (when) para poder comenzar a
contactar con gente(why).
Elaboración de HU
❑ Para elabora una buena Historia de Usuario nos fijaremos en 3 componentes:
1. Tarjetas: Donde se escribirán las historias de usuario.
2. Conversaciones: Dialogo que representa las aclaraciones sobre la actividad a

realizar.
3. Criterios de aceptación: Que nos indicaran cuando una historia de usuario esta
completada.
Historias Técnicas
❑ Requisitos no funcionales.
❑ No suelen ser de valor para el cliente.
❑ Estrategia:
❑ Evitarlas incluyéndolas en historias de usuario con valor.
❑ Ejemplos:
❑ Instalación de un servidor.
❑ Configuración de repositorio de código.
❑ Refactorizar capa de acceso a base de datos.
Ejemplo de HU
Titulo: Reserva de Ticket Value 5
Descripción:
Como Usuario yo quiero reservar un ticket en línea para

escoger mis sitios en el teatro de manera mejor y mas
rápida
Priority Effort
1 15
Ejemplo de HU
CONVERSACIÓN
División de Historias
❑ Normalmente el backlog estará compuesto por épicas o
características.
❑ Una épica es simplemente una historia de usuario demasiado

genérica.
❑ Para poder comprobar si la historia de usuario puede entrar en un

sprint y para su mejor manejo en el sprint deberá ser dividida.
Patrones de Descomposición - Operaciones
Como usuario quiero crear mi perfil

de usuario
Como usuario quiero poder acceder

a mi perfil de usuario
Como usuario quiero poder
gestionar los datos de mi
perfil de usuario para
controlar mi información
Como usuario quiero poder cambiar
mi perfil de usuario
Como usuario quiero poder eliminar

mi perfil de usuario
Patrones de Descomposición – Entrada de Datos
Como usuario quiero reservar un

vuelo entre dos fechas pudiendo
Como usuario quiero indicar las fechas manualmente
reservar un vuelo entre dos
fechas pudiendo indicar las
fechas directamente o
marcarlas sobre un
calendario Como usuario quiero reservar un
vuelo entre dos fechas marcándolas
sobre un calendario
Patrones de Descomposición – Simple/Complejo
Como usuario quiero poder reservar

vuelos entre un origen y destino
Como usuario quiero poder

reservar vuelos entre un
origen y destino, pudiendo Como usuario quiero poder indicar
indicar numero de escalas, numero de escalas de un vuelo.
buscar fechas cercanas
Como usuario quiero poder buscar los

vuelos en fechas cercanas
Patrones de Descomposición – Workflow
Como usuario quiero cambiar los

precios de cada producto
Como usuario quiero Como usuario quiero mostrar en la

actualizar y publicar mi pantalla los precios de mis
lista de precios para poder productos para dar información a
incrementar mis ventas los clientes.
Como usuario quiero enviar la lista

de precios por correo electrónico
para poder hacer miailings masivos
Diferencia entre Agile Testing y Testing
❑ Testing:
❑ “Asegurar que tu aplicación hace las cosas correctas de la manera
correcta” – Uncle Bob.
❑ La actividad de encontrar bugs ¿es calidad?

❑ Es medir cuanta calidad no tienes.
❑ Desperdiciamos nuestro tiempo en base a la búsqueda de errores
desconocidos.
Diferencia entre Agile Testing y Testing
❑ Agile Testing:
❑ Feedback rápido.
❑ Los testers generan pruebas que comprueban que su código funciona

correctamente. NO buscan posibles errores inexistentes.
❑ Automatización que permite acortar ciclos de calidad.
❑ Ponemos foco en testear, automatizar y en la calidad de los nombres de los

test. No en documentar.
Definición de Hecho Historia de Usuario
❑ Una historia de usuario estará completa cuando se satisfacen sus criterios

de aceptación.
❑ Permiten orientar los test que se van a crear.
❑ Formato:
❑ Dada una página web con comentarios, cuando pulso el botón de añadir
comentarios, entonces aparece un área de texto para introducir mi
comentario.
Definición de Hecho Sprint
❑ Conjunto de condiciones entendidas, acordadas y establecidas para dar por

finalizada una funcionalidad en el contexto del incremento de producto.
❑ Suelen ser restricciones organizacionales o del mercado, mas allá de la propia

funcionalidad.
❑ El contexto de un criterio de aceptación esta en la propia historia de usuario, pero

cuando varias historias deben incorporarse en un incremento aplicamos la Definición
de Hecho.
Definición de Hecho Sprint
❑ Ejemplo: Definición de Hecho el incremento de producto.
❑ Pasar las validaciones del departamento de QA de la empresa.

❑ Pasar las pruebas de usuario en entorno integrado.
❑ Cobertura de código a través de los test de un 80%.
❑ Generar el manual de usuario corporativo.
Definición de Hecho Release
❑ A nivel de reléase tendría la misma definición que para un sprint, solo que englobaría
incremento de producto.
❑ Entraríamos en un contexto de mercado, en el que tendríamos que tener en cuenta la

forma de consumir el producto.
❑ Ejemplo:
❑ Generación de DVD con entregable para su venta.
❑ Publicación en la App Store de la nueva aplicación generada.
❑ Generación de articulo en la revista de la empresa.
❑ Paso de pruebas de QA de rendimiento.
Estimaciones
Como realizar Estimaciones Fiables
❑ Una estimación es una aproximación de un parámetro en base a una muestra de

datos.
❑ ¿Qué variables intervienen en la estimación?

❑ El Parámetro a evaluar
❑ Los datos.
❑ Las personas que realizan la estimación
Estimaciones
Como realizar Estimaciones Fiables
❑ La muestra de datos de estimación de un equipo será sus historia de usuario, y estas

deberán ser comprendidas y explicadas en el sprint planning.
❑ Las personas deberán familiarizarse con un método de estimación y sentirse cómodas

con él.
❑ Sólo deberían estimar aquellas personas que van a comprometerse a realizar la tarea.
Estimaciones
Tipos de Estimación
Estimaciones
Ventajas Estimación relativa
❑ Ventajas de la estimación relativa:

❑ Nos permite que todos los miembros del equipo se sientan igualmente
involucrados.
❑ No generamos distinción de conocimiento. El conocimiento se comparte y se

piensa en el esfuerzo o tamaño de las historias.
❑ Se obtiene consenso y compromiso en las estimaciones, ya que la duración de

la tarea puede variar por miembro del equipo.
Estimaciones
Unidad de Medida de Tamaño
❑ Días ideales:
❑ Cuanto tiempo te costaría si:
❑ Trabajaras todo el tiempo
❑ Sin interrupciones
❑ Con todo lo necesario disponible

❑ Son fáciles de explicar fuera del equipo, ya que los puntos historia usan
una referencia interna
❑ Son sencillos cuando no hay experiencia en estimar
Estimaciones
Técnica: Tamaño relativo / story points
Estimaciones
Técnica: Tamaño relativo / story points

Estimaciones
Técnica: Planning Poker
Sucesión Fibonacci
Estimaciones
Estimaciones
Trabajemos: Hagamos historias de usuario y
estimemos
Miro Trello
SCRUM
Resumen
Una historia de usuario es una representación de un requisito escrito en
una o dos frases utilizando el lenguaje común del usuario. Las historias de
usuario son utilizadas en las metodologías de desarrollo ágiles para la
especificación de requisitos
SCRUM
¿Preguntas…?
Expositor:
Ing. CIPDávila
Ing. Luis Hugo Espejo Briceño
Quispe
E-mail:
hugo.espejo@ingenio.edu.pe
luis.davila@ingenio.edu.pe
luis.davila@ingenio.edu.pe
hugo.espejo@ingenio.edu.pe

Formacion Continua-Sesión6-2022-2

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Formacion Continua-Sesión6-2022-2

Cargado por

Copyright:

Formatos disponibles

Tu futuro es

José García La Riva

1. Características del backlog

❑ El Dueño de Producto es el ultimo responsable de la pila de producto.

❑ ¿Qué información deben contener?

❑ Si necesitamos un evento = 10 % de la capacidad del equipo.

❑ Consiste en añadir detalle y ordenación al PB.

❑ Asistentes → PO, SM y Equipo de desarrollo.

❑ Consiste en una versión de los elementos que van a entrar en el siguiente

❑ Entregable: PB revisado con el equipo de desarrollo.

❑ ¿Qué es una historia de usuario?

❑ Se almacenan en el product Backlog.

❑ Recomendaciones para escribirlas:

1. Tarjetas: Donde se escribirán las historias de usuario.

2. Conversaciones: Dialogo que representa las aclaraciones sobre la actividad a

Titulo: Reserva de Ticket Value 5

Como Usuario yo quiero reservar un ticket en línea para

❑ Una épica es simplemente una historia de usuario demasiado

❑ Para poder comprobar si la historia de usuario puede entrar en un

Como usuario quiero crear mi perfil

Como usuario quiero poder acceder

Como usuario quiero poder eliminar

Como usuario quiero reservar un

Como usuario quiero poder reservar

Como usuario quiero poder

Como usuario quiero poder buscar los

Como usuario quiero cambiar los

Como usuario quiero Como usuario quiero mostrar en la

Como usuario quiero enviar la lista

❑ La actividad de encontrar bugs ¿es calidad?

❑ Los testers generan pruebas que comprueban que su código funciona

❑ Automatización que permite acortar ciclos de calidad.

❑ Ponemos foco en testear, automatizar y en la calidad de los nombres de los

❑ Una historia de usuario estará completa cuando se satisfacen sus criterios

❑ Permiten orientar los test que se van a crear.

❑ Conjunto de condiciones entendidas, acordadas y establecidas para dar por

❑ Suelen ser restricciones organizacionales o del mercado, mas allá de la propia

❑ El contexto de un criterio de aceptación esta en la propia historia de usuario, pero

❑ Ejemplo: Definición de Hecho el incremento de producto.

❑ Pasar las validaciones del departamento de QA de la empresa.

❑ Entraríamos en un contexto de mercado, en el que tendríamos que tener en cuenta la

❑ Una estimación es una aproximación de un parámetro en base a una muestra de

❑ ¿Qué variables intervienen en la estimación?

❑ La muestra de datos de estimación de un equipo será sus historia de usuario, y estas

❑ Las personas deberán familiarizarse con un método de estimación y sentirse cómodas

❑ Ventajas de la estimación relativa:

❑ No generamos distinción de conocimiento. El conocimiento se comparte y se

❑ Se obtiene consenso y compromiso en las estimaciones, ya que la duración de

❑ Con todo lo necesario disponible

Técnica: Tamaño relativo / story points

También podría gustarte