Ingeniería de

Software
PRY3111
 CODIGO CURSO
SECCIÓN
Nombre del profesor de la seccion
correo@profesor.duoc.cl

2 2
Planificando
con Scrum II
 Terminando la
Planificación…….
» En la actividad anterior revisamos la fase de planificación y
estimación, logramos definir el product backlog priorizado, las
épicas y la planificación de Entregables, además, iniciamos la
planificación definiendo historias de usuario.
» En esta actividad completaremos la fase de planificación y
estimación, revisaremos la estimación de las historias de
usuario, identificación de tareas y la generación de la pila del
primer sprint.

4
 Procesos de la fase de
Planificación y Estimación
1. Crear Historias de Usuario
2. Estimar Historias de Usuario
3. Comprometer Historias de Usuario
4. Identificar Tareas
5. Estimar Tareas
6. Crear el Spring backlog

5
 Estimar
Historias
de Usuario
¿Qué vamos a estimar?

» Debemos estimar el esfuerzo que

implica construir las historias de
usuario y tareas relacionadas con
ellas, es decir, cuanto nos cuesta
crear las historias de usuario.
» En este punto es importante reiterar
lo siguiente: “En proyectos ágiles,
tenemos predefinida la fecha de
término, es decir, el tiempo es fijo y
debemos construir lo que tenga más
valor de negocio para el cliente”, por
lo tanto, debemos estimar el peso
de cada historia bajo un criterio de
los Desarrolladores para
comprometer las entregas.
7
 ¿Cómo y por qué?
» El team de desarrollo es quien mejor sabe cuanto tiempo y
esfuerzo requiere construir software.
» Es por ello que deben juntarse y acordar los pesos de cada
historia, de acuerdo a su criterio, ocupando diversas técnicas.
» Lo anterior nos permitirá, “como equipo” saber si una historia la
alcanzan a considerar en un Sprint o la dejan para otro Sprint.
» “El modelo ágil se sustenta en que el equipo se autogestiona”.

8
 Aprobación de las
Historias
» Antes de comenzar a trabajar con las estimaciones, es
necesario que el product owner apruebe las historias de
usuario que se han definido.
» El product owner debe asegurar al proyecto que las historias
aportan valor y por consiguiente serán parte de un sprint.

9
 Estimación de las Historias
de Usuario
» Tal como se señaló previamente, el equipo o team autogestiona
su trabajo y se compromete a construir el software respectivo,
por lo tanto, de común acuerdo, el team debe estimar lo
propuesto para codificarán y cumplir lo coprometido.
» El team es quien muy claro lo que cuesta desarrollar una
funcionalidad.
» Las estimaciones deben efectuarse aplicando un mismo patrón
de comparación.

10
 Medición del la
estimación
» El team debe definir una funcionalidad
o historia como unidad de medida de
referencia y luego comparar cada
historia de usuario con dicha
referencia.
» La medición se realizará analizando la
complejidad, riesgo o esfuerzo de
desarrollo de una historia.
» Si la historia analizada implica mayor esfuerzo, más compleja o
más riesgosa, se asignarán n unidades de medida para reflejar
que implica mayor trabajo con respecto a la medida.

11
 Medición del la
estimación
» Por ejemplo, el team decide que utilizará
como patrón de referencia el desarrollo de
un mantenedor para una entidad simple,
es decir, lo que implica elaborar la interfaz Patrón
gráfica, programación de estructuras de Mantenedor Simple
datos y manejo de persistencia, definiendo
que crear dicho mantenedor equivale a una
unidad de trabajo.
» La primera historia es hacer una
funcionalidad de generación de un pedido,
en este caso, el equipo concuerda que
“crear un pedido es más trabajo que crear
un mantenedor simple”, ya que el pedido
conlleva el control de reglas de negocio
específicas y utilizar más de una entidad.
12
 Medición del la
estimación
» Si debemos reflejar que una historia es n veces mas trabajo que
el patrón de referencia, debemos definirlo de común acuerdo
llagando a un consenso grupal según la experiencia y
especialización del equipo.
» Para llegar a un consenso grupal existen diferentes técnicas.
» Siguiendo el ejemplo anterior, el team podría llegar a consenso
y definir que “crear un pedido es más trabajo que crear un
mantenedor simple”, asignando 4 unidades de medición, esto
reflejaría que el pedido es 4 veces más trabajo que un
mantenedor simple, esto es un ejemplo.

Historia crear pedido

Mantenedor Simple
4 veces el esfuerzo de crear mantenedor simple 13
 Técnicas de Estimación
» Existen diversas técnicas ágiles para que el team pueda llegar a
consenso, las más conocidas son Wideband Delphi, planinng
poker y 5 puntos:

» Wideband Delphi: Es una técnica basada en

el consenso para estimar el trabajo.
» En forma anónima, los integrantes del
equipo hacen una estimación del trabajo
que implica cada funcionalidad y se registran
para ser discutidas, si aún no llegan a
consenso nuevamente se realiza una
segunda votación y se vuelve a analizar si
hay consenso, si es necesario se puede
volver a registrar las estimaciones hasta
lograr consenso.
14
 Técnicas de Estimación

» Planning Poker: Se utiliza un juego de cartas especialmente

numeradas para representar el esfuerzo de desarrollo y el team
se reúne a analizar las historias de usuario, cada historia se
analiza y se procede a realizar una votación donde cada
integrante del team asigna una carta de puntuación para
reflejar el trabajo necesario y llegar a consenso, si aún hay
muchas diferencias, se vuelve a realizar la estimación hasta
lograr consenso.

15
 Técnicas de Estimación

» Cinco Puntos: El grupo realiza un análisis y

discusión de una propuesta inicial de estimación,
cada uno vota en una escala de 1 a 5 usando sus
dedos, esto reflejará cuan de acuerdo están con
dicha propuesta
» La votación de 1 a 5 posee la siguiente escala:
• Un dedo: No estoy de acuerdo con la conclusión del
grupo y tengo grandes inquietudes.
• Dos dedos: No estoy de acuerdo con la conclusión del
grupo y me gustaría discutir algunos asuntos.
• Tres dedos: No estoy seguro y me gustaría sumarme a la
conclusión de consenso del grupo.
• Cuatro dedos: Estoy de acuerdo con la conclusión del
grupo y me gustaría discutir algunos asuntos menores.
• Cinco dedos: Estoy totalmente de acuerdo con la
conclusión del grupo
16
 Product Backlog con
estimación de historias

Ejemplo de resultado de la actividad Planning Poker

Puntos de Historia
Id Historia de Usuario Estimados

Como vendedor quiero registrar en el sistema las ventas para

H1
mantener un historial de los productos que vendo.
13

Como administrador quiero ver un reporte en pantalla de los

H2 productos que poseen más ventas en el día para conocer las 5
preferencias del cliente.

Patrón de comparación: Funcionalidad de Login de Usuario

Criterio: El esfuerzo de crear el reporte de la H2 es 5 veces mayor a crear un Login de Usuario

17
Comprometer
Historias
de Usuario
 Comprometer Historias de
Usuario
» Una vez que tenemos las historias de usuario estimadas, es
decir, sabemos cuanto pesa cada historia, el equipo revisa las
historias de usuario asignadas que encabezan la pila del
producto priorizada y establece cuales historias de usuario se
comprometen a desarrollar en los tiempos definidos y de
acuerdo al plan de entregas.
» Con la información de las estimaciones y según la prioridad, el
equipo establece que historias de usuario serán incluidas en el
primer Sprint, salen de la pila del producto y pasan a la pila del
Sprint.

19
 Sprint Planning

» El Product Owner participa en la reunión de planificación del

sprint donde se revisan las historias de usuario ya que podría
ser necesario aclarar algunos aspectos relativos a la prioridad
asignada.
» El team se comprometerá a entregar un subconjunto de
historias de usuario del Backlog Priorizado del Producto en el
primer sprint, salen de la pila del producto y pasan a la pila del
Sprint.

20
 Sprint Planning

» Por ejemplo, las estimaciones obtenidas podrían indicar que el

equipo estaría en condiciones de incluir las 3 primeras historias
del backlog de producto en el primer Sprint.
» Esto implica que el equipo estaría desarrollando 8 puntos de
historia de usuario (2+3+3) en el primer Sprint.
» Es decir, si el equipo completa las historias estaría avanzando a
una velocidad de 8 puntos de historia por sprint.

21
 Sprint Planning

» El time-boxing en un principio fundamental en las metodologías

ágiles, puesto que implica la necesidad de definir actividades o
tareas en tiempos específicos, los cuales debe ser respetados
por el equipo, esto permitirá centrarse en los objetivos de la
actividad y no desviarse a otros temas.
» En general se recomienda que en una reunión de planificación
de un Sprint se utilicen 4 horas para analizar y replantear el
objetivo de un Sprint y luego 4 horas para analizar y definir el
backlog del sprint. Las 8 horas propuestas son para un Sprint de
4 semanas aprox.

22
 Reunión Sprint planning

Primera Parte
Enfoque
• Se revisan los elemento de mayor
prioridad del product backlog
qué es lo que el Dueño de
• Se revisan los objetivos del sprint
• Se analizan con el product owner
Producto quiere y por qué es
aspectos que podrían tener mayor necesario
relevancia o dependencias.

Segunda Parte
cómo implementar los
• Se estima la cantidad de elementos que elementos que
pueden completar al final del Sprint,
comenzando desde la parte superior del el Equipo decide incluir en el
Backlog de Producto Sprint.
• Si el enfoque basado en capacidad, el
Equipo calcula cuánto tiempo dispondrán
para trabajos relacionados con el Sprint. el Equipo decide cuánto
• Generalmente se estiman 4-6 horas trabajo pueden completar
laborales diarias efectivas.
23
Definición
de tareas
 Reunión de Planificación
del trabajo del Sprint
» Las reuniones de planificación del Sprint también son usadas
para planificar un Sprint con historias ya comprometidas.
» En este caso, el equipo se reúne para planear el trabajo a
realizar en sprint, mediante la revisión de cada historia de
usuario comprometida y la identificación de las actividades
necesarias para cumplir con la funcionalidad (criterios de
aceptación) estimando las horas necesarias de cada tarea.
» El Product Owner puede ayudar al equipo a tomar decisiones
sobre diseño.

25
 Definición de Tareas

» El resultado de este
proceso es la lista de
tareas actualizada con
el esfuerzo estimado
en horas para su
desarrollo.
» El sprint backlog
ahora incluirá la lista
de tareas creadas y
estimadas, las cuales
el team se
compromete a
desarrollar durante el
sprint.

26
 Definición de Tareas

» El team puede añadir tareas para cumplir con el objetivo del

sprint o eliminar tareas innecesarias.
» Es importante señalar que la pila de tareas comprometidas por
el team solo puede ser actualizada por el team.
» Si existe nueva información, las estimaciones de las tareas
pueden ser actualizadas por el team.

27
 ¿Cómo estimar tareas?

» Básicamente de la misma manera en que se estiman las

historias de usuarios, es decir, proponiendo el trabajo que
implica cada tarea y logrando el consenso del grupo.
» En la estimación de tareas normalmente el equipo utiliza horas
para indicar el tiempo ideal ya que describe el número de horas
que los miembros de un equipo Scrum trabajan exclusivamente
en el desarrollo de los entregables.
» Se deben incluir las actividades necesarias para implementar la
funcionalidad, recordando que lo que vamos a construir en un
Sprint es un producto usable y entregable al cliente.

28
 Estimando Horas

» Por ejemplo, para las Historias de usuario, el equipo define las

tareas y horas necesarias para su implementación en consenso.
» Historia de Usuario H1: Como Cliente necesito revisar los
productos y sus precios para seleccionar los productos de un
pedido.
Subtarea 1.1. Crear
Interfaz de usuario

Subtarea 1.2.
Tarea 1: Mostrar los
Programar el módulo
productos
de software

Subtarea 1.3.
Tarea 2: Agregar los
Integrar con Base de
productos
Datos

Historia de usuario Tarea 3: Quitar los

5 Horas
H1 productos

Tarea 4: Manejar
sesión de usuario.

Tarea 5: Realizar 29
pruebas locales.
 Ejemplo de tabla de horas
Historia de
Usuario Descomposión de Tareas y/o spike horas estimadas

H1-T1: Crear módulo de software 10

Como Vendedor
necesito registrar H1-T2: Integrar BD 2
las ventas para
…..
H1-T3: Probar Funcionalidad 2

H1-T4: Implementar Funcionalidad 2

Como
Administrador H2-T1: Investigar sobre Reportes 1
necesito Obtener
un reporte para…
H2-T2: Crear Reporte en PDF 3

Un spike es la inclusión en un sprint de tareas que no son desarrollar

directamente la historia de usuario pero son necesarias para lograr la
implementación.

30
Otro ejemplo de backlog
de Sprint

31
 Estado de las tareas

» Para observar los avances y en general la visibilidad del estado

de las tareas, normalmente se usan tableros KanBan, donde las
tareas que pasan de la columna de tareas planificadas a tareas
en proceso y luego tareas terminadas.

32
 Herramientas KanBan

» Se pueden utilizar tableros en pizarra con notas adhesivas o

utilizar herramientas de software.

33
34
 Estado de las tareas

» Además de los tableros Kanban, para el control del avance de

las tareas del sprint se pueden utilizar gráficos “Burndown
Chart” que muestran el trabajo consumido o logrado y lo que
queda pendiente por completar.
» La información la actualiza el scrum master de acuerdo a lo
informado diariamente por el team y se pueden usar horas de
trabajo o puntos de historia.

35
 Estado inicial

» Antes de comenzar el Sprint,

nuestro gráfico mostrará que
quedan todas las horas de
pendientes por trabajar.
» Por ejemplo, en la imagen el
Sprint tiene 100 horas en total
y la línea azul señala que están
pendiente las 100 horas de
trabajo al día 1, la línea roja
señala que está proyectado ir
bajando las horas pendientes
en el medida que van
completando las tareas día a
día en un sprint de 20 días

36
 Velocidad del equipo

» Si el equipo va rápido, la
gráfica mostrará que quedan
menos horas pendientes que
las proyectadas por completar,
desde el día 4 el equipo
comenzó a tener menos horas
pendientes que lo proyectado.
» En este caso la línea azul está
bajo la roja, se avanza más
rápido de lo estimado hasta el
día 11.

Scrum Master:
“Debo analizar que pasa, el equipo más rápido,
¿estarán dejando de hacer algo planificado?
37
Si va todo Ok. Los felicito por su entrega!!!!
 Velocidad del equipo

» Si el equipo va lento, la gráfica

mostrará que quedan más horas
pendientes que las proyectadas
por completar, desde el día 11 el
equipo comenzó a tener más
horas pendientes que lo
proyectado.
» En este caso la línea azul está
sobre la roja, se avanza más
lento de lo estimado desde el 11
hasta el día 20 en que se
comenzó a completar el trabajo
atrasado.
Scrum Master:
“Debo analizar que pasa, el equipo anda lento,
38
¿tendrán algún problema? ¿agregaron algo al sprint?
 ¿Estamos listos para
comenzar a implementar?
» En este momento hemos completado la fase de Planificación y
Estimación, para comenzar la fase de implementación debemos
tener a la vista todas las tareas del sprint con sus horas de
trabajo estimadas, esto conformará el sprint backlog del Sprint
y estarán todas las tareas en estado pendiente ya que recién
comenzaremos a implementar.

39
 La arquitectura en
proyectos ágiles
» Es muy frecuente que los proyectos Scrum incluyan una etapa o
iteración 0, previo al inicio de la implementación de los sprints,
ya que se necesita contar con los recursos y ambientes
necesarios para desarrollar el software.
» La arquitectura necesaria debe proveerse antes de iniciar la
construcción, tales como, implementaciones de base de datos,
modelos de funcionamiento, hardware y software configurado y
otros requisitos.
» Si bien la premisa es privilegiar el “software funcionando sobre
documentación extensiva” es necesario documentar lo mínimo
necesario para comenzar el desarrollo de los sprints.

40
Actividad
Práctica
 Actividad práctica

» En esta clase, los alumnos deberán continuar trabajando en el

caso asignado para scrum, el cual tributa para el examen
transversal.
» Deberán aplicar planning poker para realizar la estimación del
esfuerzo de trabajo que implican 3 historias de usuario de la
cima del product backlog, la idea es visualizar que historias
pesan más que otras con el criterio definido por el grupo
(patrón).
» Para esta actividad en aula, asuma que los sprints serán 3 de un
largo de 1 semana cada uno, es decir, 15 días de trabajo para
lograr 3 historias de usuario.
» Debe utilizar la documentación que será proporcionada como
anexo a la actividad.

42
» Luego deberán realizar la definición de tareas de las 3 historias
de usuario, en consenso deberán indicar las horas que utilizarán
en cada tarea.
» Posteriormente deberán indicar que historias de usuario se
comprometen a generar en el primer Sprint, generando el
Sprint Backlog con las actividades y horas comprometidas.
» Para lograr las historias del primer Sprint, considere generar las
condiciones mínimas para lograr el desarrollo de un producto
funcional, es decir, considere que debe crear una base de datos,
modelamiento de datos, modelo holístico u otro modelo
necesario para la claridad de los desarrolladores, pruebas de
software u otra necesidad.

43
 Resumen

» Con planning poker (usando las cartas) crear la estimación de 3

historias de usuario en puntos de historia.
» Definir las tareas necesarias para cada una de las 3 historias de
usuario e indicar las horas estimadas de trabajo.
» Crear el Sprint Backlog con las actividades y horas
comprometidas para el primer Sprint.

44
45
46