Ingeniería de

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

2 2
Planificando
con Scrum I
 Fin del Inicio y comienzo
de la Planificación…….
» En la actividad anterior se logró conocer los aspectos del
desarrollo ágil y sus postulados, además comenzamos a revisar
la metodología SCRUM, sus principios y fases.
» Dentro de la fase de inicio, ya revisamos la definición de la
visión del proyecto y los roles, en esta actividad completaremos
la fase de inicio y comenzaremos la fase de planificación y
estimación.

4
 Procesos de la fase de
Inicio de Scrum
1. Crear visión del proyecto
2. Identificar Roles
3. Formar Equipos Scrum
4. Desarrollar épicas
5. Crear el backlog Priorizado
6. Realizar la planificación del lanzamiento

5
 Desarrollo de
Épicas y Backlog
 Épicas

» Como en todo desarrollo de software, en las

fases de inicio el cliente generalmente no
define requisitos muy concretos.
» En las etapas iniciales de redacción, la
mayoría del las necesidades son
funcionalidades y/o requerimientos de alto
nivel, conocidas como épica(s).
» Las épicas al ser un nivel más general, Historia de
generalmente se dividen en pequeñas Usuario 1

Épica
historias de usuario y son definidas por el Historia de
Usuario 2
producto owner y se basan tanto en la visión
Historia de
de proyecto como el caso de negocio. Usuario 3

7
 Descubrir Épicas

» Para desarrollar las épicas se pueden

llevar a cabo reuniones de grupos de
usuarios para hablar sobre las épicas
adecuadas.
» Es importante en este proceso la
determinación del concepto de
“Persona” que es una representación
abstracta de un grupo de usuarios o
stakeholders.
» La identificación de las “Personas”,
permiten identificar épicas basadas en
sus necesidades.

8
 Descubrir Épicas
» En un contexto de negocio, es posible que puedan existir
requerimientos expresados al inicio que de alguna forma son
generales y sea necesario posteriormente especificar con
mayor detalle.
» Generalmente, las épicas son de gran tamaño y requieren
abordar muchas funcionalidades implícitas o requisitos de
funcionamiento.

9
 Ejemplos de Épicas
» Orientadas la funcionalidad
• Se requiere que el vendedor pueda mantener un registro de
ventas.
• Se necesita que el administrador pueda publicar ofertas
online a los clientes para compras presenciales en tiendas y
online.
• Se necesita que los cliente puedan realizar sus pedidos on
line.
• Se requiere que el administrador pueda revisar las ventas
diarias.

10
 Ejemplos de Épicas
» Orientadas al negocio
• Como administrador quiero mantener el control de las ventas.
• Como gerente quiero aumentar la publicidad de mis
productos.

11
 Backlog de producto nivel
épicas
» El Backlog de producto a nivel de épicas representa el alcance
del proyecto.
» Es una lista de las funcionalidades del producto y otras
características, por ejemplo, de operación, seguridad u otros.
» Es dinámico, en un contexto ágil,  se puede modificar conforme
avanzamos en desarrollo de la solución.

12
 Backlog de producto nivel
épicas
» Esta lista es priorizada y mantenida por el product owner, según
el valor de negocio que se busque.
» Con esta lista inicial a alto nivel priorizada, procedemos a la
posterior creación de definiciones más específicas como las
historias de usuario.
» Además del valor de negocio, se puede priorizar según el nivel
de incertidumbre de la implementación de una funcionalidad o
el riegos que presenta dicha implementación.

13
 ¿Cómo priorizar?

» El backlog priorizado lo define el product owner de acuerdo a

diversos criterios y técnicas de priorización.
» Algunas técnicas son:
• Análisis de Kano: las épicas se clasifican en Entusiasmantes,
Satisfactorias con su implementación o mínimas que se debe cumplir.

• Comparación de pares: los requerimientos son comparados en

pares y se prioriza uno sobre otro.

• Análisis MoSCoW: se analizan las épicas considerando los

siguientes criterios “Must have”, “Should have”, “Could have” y “Will
not have”.

• Los 100 Puntos: el equipo de análisis asigna puntos a las épicas, se 14

 Por ejemplo…..
» Si tomamos las épicas anteriores, podríamos utilizar la
técnica de 100 puntos y otorgar puntaje a las épicas:
A. Se requiere que el vendedor pueda mantener un registro de
ventas.
B. Se necesita que el administrador pueda publicar ofertas
online a los clientes para compras presenciales en tiendas y
online.
C. Se necesita que los cliente puedan realizar sus pedidos on
line.
D. Se requiere que el administrador pueda revisar las ventas
diarias.

15
 ¿A qué le damos más
puntos?
» A las épicas que el equipo de análisis defina como
relevantes de implementar al inicio, según el valor de
negocio, por ejemplo:
» Si la empresa necesita ofrecer sus productos en
internet para aumentar ventas presenciales en
tiendas, en forma urgente y después ofrecer el servicio
de ventas online, la priorización quedaría:
B: 100 puntos
A: 80 puntos
D: 50 puntos
C: 30 puntos
16
 ¿Cómo priorizar?
» El equipo define que primero se necesita :
B. Que el administrador pueda publicar ofertas online a los
clientes para compras presenciales en tiendas.
A. Que el vendedor pueda mantener un registro de ventas.
D. Que el administrador pueda revisar las ventas diarias.
C. Que los cliente puedan realizar sus pedidos on line.

17
 El criterio de terminado

» Para nuestro proyecto de software, el Product Owner, en

acuerdo con los interesados, define el criterio de término del
proyecto, es decir, que condiciones se deben cumplir para decir
que el proyecto está terminado.
» Esta definición depende del valor de negocio que se quiera
obtener y de la factibilidad de implementación.
» Por ejemplo:
• La condición para dar por terminado el proyecto es lograr
implementar el sistema en todos sus módulos.
• El término del sistema será cuando el product owner
apruebe todas las funcionalidades y reciba conforme.

18
Resumiendo……

19
 Planificación del
Lanzamiento
» El proceso de planificación del lanzamiento se refiere a
establecer cómo vamos a organizar las entregas del producto.
» Debemos definir qué entregables recibirán los usuarios en el
tiempo del proyecto y el largo de cada iteración de entregas.

20
 Planificación de las
entregas.
» El largo de cada iteración puede ir de 1 a 6 semanas y se
recomienda no exceda más de 4 semanas.
» El plan de entregas se define de manera que cada entrega
aporte un valor significativo para el cliente.
» Cada entrega es de un producto funcional y usable.

Scrum
Diario

Sprint
1a4
Semanas

21
 Ejemplo de Planificación
de Entregas

Inicio y
Planificació Iteración 0 Iteración 1 Iteración 2 Iteración 3
n

Definición de
Visión
Preparación de
Ambientes
Mantener
registro de las
Definición de ventas
Roles

Publicar ofertas
Definición de Modelamiento Realizar pedidos
online a los
Épicas Inicial on line.
clientes

Definición de
Historias de
Usuario Revisar las
ventas diarias
Definición de
Definición de Pila Arquitectura
del Producto
Priorizada

3
2
1

e
e
e

as
as
as

le
le
le

Re
Re
Re

2 1 2 3 3
Semanas 22
Planificación y
Estimación
 Planificación en Scrum

» En Scrum la planificación posee el comportamiento de las

planificaciones ágiles y está presente en:
• Planificación de entregas (releases).
• Planificación del Sprint.
• Planificación del día.
• Planificación de las mejoras.

24
 Planificación del Sprint

» A partir del product backlog (lista priorizada de lo que se espera

desarrollar) correspondiente a requerimientos de alto nivel o
épicas, debemos revisar cada una de ellas para descomponer
esta gran funcionalidad o capacidad en funcionalidades más
pequeñas y manejables, es decir, historias de usuario.
» Las metodologías ágiles como Scrum utilizan las historias de
usuario como el instrumento principal para identificar los
requerimientos de usuario.
» No solo son requerimientos funcionales, además pueden estar
presentes requerimientos no funcionales.

25
 Planificación del Sprint

» Las historias de usuario y necesidades serán analizadas y

estimadas en esfuerzo por parte del team, generando una lista
de historias de usuarios priorizada y con estimaciones.
» Durante el sprint planning, el equipo analiza y extrae algunos
elementos de la parte superior de esta lista, conformando un
sprint backlog y decide cómo implementar los elementos.

26
 Planificación del día

» El equipo tiene cierta cantidad de tiempo (un sprint, que dura

usualmente de 2 a 4 semanas) para completar el trabajo
seleccionado, pero se reúne todos los días para coordinar el
trabajo y al final del día para evaluar el progreso (daily Scrum).
» En el camino, el ScrumMaster mantiene al equipo concentrado
en los objetivos.

27
 Planificamos para……

» Entregar claridad al team en lo que debe

considerar en el proceso de
Implementación en cada iteración o Sprint.
» Al final del sprint se obtiene un producto
entregable.
» Si hay elementos que no fueron cubiertos
en el Sprint recién concluido, se incorporan
a la pila de elementos pendientes (pila del
producto) para ser considerada su inclusión
en el siguiente Sprint.
» Para el siguiente sprint, el equipo escoge
otra porción de actividades de la pila
pendiente (product backlog) para trabajar
en ello nuevamente.
28
 Sigamos adelante!!!!!

» Ahora, que ya tenemos una visión general de la planificación en

Scrum, iniciaremos la definición de las Historias de Usuario para
poder trabajar posteriormente en la planificación de los Sprints.

29
 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

30
 Historias de Usuario a
partir las épicas

Historia de

Épica 1
Usuario 1
» Las Historia de Usuario Historia de
Usuario 2
generalmente nacer a
Historia de
partir de épicas que son Usuario 3
más generales.

Historia de

Épica 2
Usuario 4
Historia de
Usuario 5
Historia de
Usuario 6

31
 Historias de Usuario

» Las historias de usuario son descripciones cortas y simples de

una funcionalidad, escritas desde la perspectiva de la persona
que necesita una nueva capacidad de un sistema, por lo general
el usuario, área de negocio o cliente.

Típicamente las historias siguen una plantilla simple: Yo como

un [Rol], necesito [Descripción de la funcionalidad], con la
finalidad de [Descripción de la consecuencia].
» Debe describir el rol desempeñado por el usuario de forma
explícita e indicar el beneficio para el área de negocio que
representa esta funcionalidad

32
 Historias de Usuario

» Ejemplo de Historia de Usuario:

• Como vendedor quiero registrar en el sistema las ventas para

mantener un historial de los productos que vendo.

• Como administrador quiero ver un reporte en pantalla de los

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

33
 Criterio de Aceptación

» Las historias de usuario deben presentar al reverso los criterios

de aceptación, se sugiere que no sean más de 4 por historia,
redactado una frase que indique el contexto, el evento y el
comportamiento esperado ante el evento descrito en la
historia.
» Es relevante identificar los criterios de aceptación ya que nos
servirán para verificar cuando está terminada la funcionalidad.

34
Criterio de Aceptación

» Los criterios de aceptación están relacionados con

las pruebas que se realizaran para verificar el
cumplimiento y satisfacción del usuario.
» El Scrum Master debe asegurar que el Product
Owner no cambie los criterios de aceptación
durante el desarrollo de una etapa de construcción
del software.
» NO CONFUNDIR CON CONDICIÓN DE TÉRMINO!!!!!
» El criterio de aceptación es para objetivos
específicos reflejados en de las historias de usuario
y la condición de término es una condición
transversal que señala cuando el producto está en
condiciones de ser entregable y usable.

35
 Orientaciones para escribir
historias de usuario
» Definir quién utilizara la funcionalidad a
desarrollar.
• Podemos hacernos preguntas como ¿Para qué usuario
estamos trabajando en esta historia? ¿Qué hace, en qué
trabaja, cómo y dónde vive, cuántos años tiene?
» Especificar qué producto quiere el usuario.
• Identificar qué se espera como salida de la
implementación, y cómo se ve beneficiado el usuario
final. Se expresa en lenguaje natural y sencillo, para
poder conversar con ellos.
» Para qué utilizará el producto.
• Definir el contexto de la historia, esto ayudará a
comprender la relevancia para el usuario.
» Identificar los criterios de aceptación.
• Señalar qué salidas obtendremos cuando finalice el
proceso de ejecución de la funcionalidad ya que nos sirve
para verificar que está terminada la funcionalidad. 36
 ¿Se aceptan nuevas
historias de usuario?
» Por supuesto, es desarrollo ágil, se pueden generar cuando:
• Existen nuevas funcionalidades
• Hay cambios sobre una funcionalidad ya existente
• Existen errores en una historia y su corrección es muy compleja, se
dividen en nuevas historias
• Producto del constante feedback de usuarios
• Por motivos de pruebas de usabilidad.

37
Formato de Historia de
Usuario

38
 Veamos una historia de
usuario.
» A partir de la Épica:
• Se necesita que los cliente puedan realizar
sus pedidos on line.
» Se pueden descomponer las siguientes
historias de usuario:
Historia de
• Como Cliente quiero revisar los productos Usuario 1

Épica
y sus precios para seleccionar los productos
Historia de
del pedido. Usuario 2
Historia de
Usuario 3
• Como Cliente quiero confirmar los
productos elegidos para obtener el precio
total del pedido.

• Como Cliente quiero registrar el tipo de

despacho para elegir la modalidad de envío
del pedido. 39
 Ejemplo de Historia de
Usuario
» Se registran los escenarios de posibles cursos de acción en la
historia de usuario, por ejemplo, caso exitoso o caso de error.

Enunciado de la historia Criterios de aceptación

Identificador (ID) Característica / Razón / Número (#) de Criterio de Resultado / Comportamiento
Rol Contexto Evento
de la historia Funcionalidad Resultado escenario aceptación (Título) esperado
E1-H1 Como un Revisar los productos y Con la finalidad 1 El producto esta Existen productos con Cuando se seleccione el El sistema mostrará el número
cliente. sus precios ordenados de seleccionar los disponible stock para ventas producto. de productos en stock y
de menor a mayor productos del permitirá registrar la cantidad
pedido. de productos del pedido.
2 El producto no esta No existen productos Cuando se seleccione el El sistema mostrará el texto
disponible con stock para ventas producto. NO DISPONIBLE y no dejará
seleccionar el producto.
3 Orden de los Selección de Cuando se muestran los El sistema mostrará los
productos productos productos productos en orden de precios
de menor a mayor.

» El criterio de aceptación nos ayudará a la hora de codificar la

funcionalidad y efectuar las pruebas correspondientes.
40
Actividad
Práctica
 Desarrollo de Historias de
Usuario
» Para el caso entregados a cada grupo, los equipos deben definir una lista de
épicas y priorizarlas, esta tarea deberá estar liderada por alumno que está
asigando como product owner, ya que es responsabilidad del product
owner.
» Para la épica de mayor prioridad, el grupo debe definir al menos 3 historias
de usuario, con sus respectivos criterios de aceptación, esta tarea deberá
estar liderada por alumno que está asigando como product owner, ya que es
responsabilidad del product owner.
» El alumno con el rol de Scrum Master, deberá orientar al grupo en la forma
de efectuar las estimaciones de las épicas, el uso de las plantillas para las
Historias de Usuario, se sugiere que explique el método de los 100 puntos.
» Este trabajo estará guiado por el docente, quien deberá retroalimentar a los
alumnos para lograr el desarrollo de la actividad.

42
 PLANNING POKER

IMPORTANTE
» La próxima clase los alumnos deberán realizar estimaciones con
planning poker.
» El docente debe solicitar a los alumnos imprimir y recortar las
cartas respectivas, las cuales debe traer la próxima clase.
» Se debe indicar a los alumnos que el recurso está disponible en
AVA o será enviado por el docente vía correo electrónico.
» Para el docente el recurso está disponible como material
complementario de la actividad 9.

43
44
45