Grupo

16

Facultad de
Ingeniería en
Ciencias de la
Computación y
Telecomunicaciones
Sistema de Información para Gestionar la
Venta y Inventario en un E-commerce
aplicando CRM

INTEGRANTES: Aviza Mamani Alexander

Cardona Chávez Alex
Colque Orellana Nicolas
Hurtado Gutiérrez Erasmo Cuarto
Limachi Sarzuri Grover Fernando
Portugal Hurtado Maguin

MATERIA: SISTEMAS DE INFORMACIÓN II

INF 412 – SA
DOCENTE: Ing. Angélica Garzón Cuellar

1
INDICE
1. PERFIL ........................................................................................................................................................ 4
1.1. INTRODUCCIÓN ............................................................................................................................. 4
1.2. OBJETIVOS ................................................................................................................................... 5
1.2.1. Objetivo General ................................................................................................................. 5
1.2.2. Objetivos Específicos .......................................................................................................... 5
1.3 DESCRIPCIÓN DEL PROBLEMA ........................................................................................................ 6
1.4. ALCANCE ..................................................................................................................................... 8
2. MARCO TEORICO METODOLOGÍA ÁGIL..................................................................................... 12
2.1. PROPÓSITO DE SCRUM ............................................................................................................... 12
2.2. VISIÓN GENERAL DE SCRUM........................................................................................................ 16
2.3. EL EQUIPO DE SCRUM (SCRUM TEAM) ......................................................................................... 17
2.4. EL DUEÑO DE PRODUCTO (PRODUCT OWNER) ............................................................................. 17
2.5. EL EQUIPO DE DESARROLLO (DEVELOPMENT TEAM) .................................................................... 18
2.6. EL SCRUM MASTER .................................................................................................................... 20
2.7. EVENTOS DE SCRUM ................................................................................................................... 22
2.8. EL SPRINT .................................................................................................................................. 22
2.9. REUNIÓN DE PLANIFICACIÓN DE SPRINT (SPRINT PLANNING MEETING) .......................................... 23
2.10. OBJETIVO DEL SPRINT (SPRINT GOAL) ....................................................................................... 24
2.11. SCRUM DIARIO (DAILY SCRUM) ................................................................................................. 25
2.12. REVISIÓN DE SPRINT (SPRINT REVIEW)...................................................................................... 26
2.13. RETROSPECTIVA DE SPRINT (SPRINT RETROSPECTIVE) .............................................................. 27
2.14. ARTEFACTOS DE SCRUM ........................................................................................................... 28
2.15. LISTA DE PRODUCTOS (PRODUCT BACKLOG) ............................................................................. 32
2.16. LISTA DE PENDIENTES DEL SPRINT (SPRINT BACKLOG) ............................................................... 33
2.17. INCREMENTO ............................................................................................................................ 33
2.18. TRANSPARENCIA DE LOS ARTEFACTOS....................................................................................... 34
2.19. DEFINICIÓN DE “TERMINADO” ..................................................................................................... 35
2.20. VENTAJAS Y DESVENTAJAS ....................................................................................................... 36
2.20.1. Ventajas........................................................................................................................... 36
2.20.2. Desventajas ..................................................................................................................... 36
2.21. VALORES DE TRABAJO .............................................................................................................. 37
2.22. HERRAMIENTAS DE TRABAJO ..................................................................................................... 38
3. PERSONAS Y ROLES DEL PROYECTO .......................................................................................... 40
4. MODELOS USADOS PARA EL DESARROLLO DE SCRUM...................................................... 41
4.1. REUNIÓN DE PLANEAMIENTO DEL SPRINT (SPRINT PLANNING) ....................................................... 41
4.2. PILA DE SPRINT (SPRINT BACKLOG 0) .......................................................................................... 43
4.3. ELEMENTOS: PILA DEL SPRINT..................................................................................................... 44
4.4. SPRINT REVIEW .......................................................................................................................... 45
4.5. SPRINT RETROSPECTIVE ............................................................................................................. 45
4.6. PROCESO SCRUM (ROLES, COMPONENTES, REUNIONES Y PILAS DE PRODUCTO POR SPRINT) ......... 46
4.7. EJECUCIÓN DE LA ITERACIÓN....................................................................................................... 47
4.8. DIAGRAMA DE CLASE .................................................................................................................. 48
4.9. LISTA DE CASOS DE USO Y DIAGRAMA DE CASOS DE USO ............................................................ 49
4.9.1. Lista de Casos de Uso ...................................................................................................... 49
4.9.2. Diagrama General de Casos de Uso ................................................................................ 50

2
4.10. PAQUETES DE CASOS DE USO ................................................................................................... 51
4.10.1. Paquete Usuario .............................................................................................................. 51
4.10.2. Paquete Inventario .......................................................................................................... 52
4.10.3. Paquete Venta ................................................................................................................. 53
4.10.4. Paquete Promociones ..................................................................................................... 54
4.11. ARTEFACTO .............................................................................................................................. 55
4.11.1. Product Backlog .............................................................................................................. 55
4.11.2. Scrum Taskboard ............................................................................................................ 56

3
1. PERFIL
1.1. Introducción
A veces al momento de desarrollar un sistema de información nos encontramos
con proyectos que por sus requerimientos no pueden ser definidos completamente
en la fase de Análisis del proyecto ya que requieren un proceso constante de
revisión y modificación.
Para este tipo de proyectos debemos utilizar una metodología de desarrollo ágil
que nos permita una mayor flexibilidad capaz de adaptarse a los continuos posibles
cambios requeridos por el cliente, sin que estas peticiones de cambio afecten el
análisis que se hizo del proyecto.
En este contexto, SCRUM se puede considerar como el paradigma de
metodología ágil.
Scrum es un proceso en el que se aplican de manera regular un conjunto de
buenas prácticas para trabajar colaborativamente, en equipo, y obtener el mejor
resultado posible de un proyecto. Estas prácticas se apoyan unas a otras y su
selección tiene origen en un estudio de la manera de trabajar de equipos altamente
productivos.
En Scrum se realizan entregas parciales y regulares del producto final, priorizadas
por el beneficio que aportan al receptor del proyecto. Por ello, Scrum está
especialmente indicado para proyectos en entornos complejos, donde se necesita
obtener resultados pronto, donde los requisitos son cambiantes o poco definidos,
donde la innovación, la competitividad, la flexibilidad y la productividad son
fundamentales.
Este documento describe la implementación de la metodología de trabajo scrum en
las empresas para la gestión del desarrollo el proyecto “Desarrollo del módulo de
contabilidad del proyecto homónimo”.
Incluye junto con la descripción de este ciclo de vida iterativo e incremental para el
proyecto, los artefactos o documentos con los que se gestionan las tareas de
adquisición y suministro: requisitos, monitorización y seguimiento del avance, así
como las responsabilidades y compromisos de los participantes en el proyecto.

4
1.2. Objetivos
1.2.1. Objetivo General
Implementar la metodología de desarrollo ágil (SCRUM) en el proyecto de comercio
electrónico de un producto o servicio, para la categoría Empresa-consumidor (B2C)
de comercio electrónico utilizando CRM.

1.2.2. Objetivos Específicos

❖ Reunirse con el product owner.

❖ Disponer de la información adecuada e histórica de los clientes (y del

mercado en general).

❖ Cumplir responsablemente con los ciclos diarios establecidos durante el

sprint.

❖ Analizar la información captada mediante herramientas específicas para

profundizar en el conocimiento del cliente, su valor y sus necesidades.

❖ Establecer requerimientos funcionales para el diseño del sistema de

información ideal para el desarrollo competitivo de la empresa.

❖ Diseñar e implementar una base de datos capaz de soportar todos los

requerimientos que sean necesarios.

❖ Definir el sistema ideal en referencia a su propósito, alcance y funcionalidad.

❖ Diseñar e implementar una interfaz gráfica agradable entre el usuario y el

sistema de información, tanto en la aplicación web, como en la aplicación móvil.

❖ Diseñar el Backend del módulo en el lenguaje de programación php con

framework laravel a través del modelo 3 capas.

5
1.3 Descripción del Problema
Clientes
El seguimiento hacia los clientes no se lo realiza por no realizar los reportes
necesarios, saber sus más mínimos intereses es importante para evitar gastos
innecesarios.
Deficiencia en la atención al cliente. Por normativa de ley las empresas empiezan
su horario laboral a las 8:00 am, hora en que están disponibles para empezar a
recibir sus primeros clientes lo cual todo está preparado para empezar la jornada
laboral.
En la mayoría de las empresas se puede observar que el cliente llega y observa la
gama de productos, elige los productos que va a comprar, espera a la realización
del pago que se hace en facturas convencionales, y luego se retira. La empresa
cuando se retira el cliente no llega a saber más de ese cliente, así que puede a
llegar a perder lo que pudo haberse convertido en un cliente potencial.
Los reportes de fidelizar de los clientes no se lo realizan por la inconsistencia de
datos.
Ventas
Los registro de los productos o servicios que ofrece la empresa hay inconsistencia.
Las estadística de productos más requeridos por clientes es muy demoroso, por lo
tanto nadie lo realiza.

Limitación de oferta de Productos

Para todo buen negociante lo principal es que los clientes puedan a llegar a
conocer todos sus productos y de esta forma poder llegar a vender la mayor
cantidad de productos .Es por eso que el problema más notorio es que nuestro
cliente pueda conocer todos nuestros productos ya que al no estar siempre a la
vista de lo que un cliente necesite en ese momento, además de que el cliente
tendrá ciertas dificultades al momento de querer comparar características de un
producto con otro, incluyendo la diferencia de precios.

6
Mora en el proceso de pago
En este proceso podemos resaltar unos de los problemas más habituales que
sufren la mayoría de las empresas que están en pleno incursiona miento de
crecimiento. Tales como el momento cuando los clientes necesitan realizar sus
transacciones de pago, y se presentan las colas largas de clientes en espera de
poder pagar sus productos, cobranzas de manera manual, cajas insuficientes para
abastecer los pagos, productos sin un código de especificación de precio son
perjudiciales para los usuarios en su tiempo.

Marketing
Una agenda estructurada para las campañas de marketing o lanzamiento de un
producto. Organizar estos eventos llega a ser muy tedioso si no se tiene una buena
gestión de información acerca de las necesidades de los clientes. Gestionar la
publicidad es tan importante como la elaboración de un producto por eso
imprescindible capacitar a nuestro personal de ventas y proporcionarles las
herramientas adecuadas para un excelente desempeño.

Soporte y Asistencia
Los clientes no tienen suficiente tiempo para acudir a la empresa y recibir
asistencia, esto hace que el cliente no vuelva más a adquirir algún producto o
servicio por parte de la empresa.
Estas son algunas de las razones por la cual hemos decidido optar por trabajar con
la metodología ágil “Scrum”. A través de esta metodología se pretende darle
agilidad a los procesos que se realizaran en el desarrollo de nuestro proyecto,
además de poder brindar un control del progreso a nuestros clientes y poder
trabajar de manera ordenada como equipo.
Con las todas herramientas que nos ofrece esta metodología y haciendo un buen
uso de ellas, pretendemos cumplir con el objetivo de poder realizar un buen
sistema de comercio electrónico cubriendo todas las necesidades ya mencionadas
y por supuesto las requeridas por nuestros clientes en un corto plazo.

7
1.4. Alcance

El proyecto tiene como finalidad facilitar las tareas críticas, priorizando las más
necesarias que presenta actualmente, además de simplificar y automatizar otras
tareas. Por lo tanto, el sistema estará compuesto o formado por los siguientes
procesos:
Gestionar Usuario
Permitirá al administrador: registrar, modificar y dar de baja a los distintos tipos de
usuarios que interactuarán con el sistema. Las contraseñas serán encriptados para
mejor seguridad en el sistema. Se registraran los siguientes datos:
(Nombre de usuario, Contraseña, Habilitado)
Iniciar sesión
Permitirá al usuario ingresar al sistema a través de su cuenta, escribiendo su
nombre de usuario y su contraseña para ingresar en este.

Asignar Privilegio
Permitirá al administrador: asignar como quitar privilegios a los diferentes usuarios
que se encuentran registrados en el sistema. Los datos son los siguientes:
(ID del Privilegio, Tipo de Privilegio, Descripción)

Gestionar Perfil
Permitirá al usuario: registrar, modificar información sobre su cuenta personal en el
sistema. El cual cuando se cree un nuevo usuario y este ingrese por primera vez al
sistema se le informara mediante un mensaje que debe introducir estos datos de
forma alternativa para una facturación de forma más detallada. Los datos a
registrar son:
(Nombre, Apellido, Correo Electrónico, Carnet de Identidad, Fecha de Nacimiento,
Puntos, Foto)

8
Mensajes
En esta parte los clientes pueden enviar mensajes de consultas sobre algún
producto o cualquier consulta en general al administrador, las cuales serán
enviadas a un buzón de mensajes donde el administrador podrá leer los mensajes
y responderlos.
(ID del Mensaje, Mensaje, Fecha, Hora)

Ver bitácora
Se administrador podrá visualizar todas las operaciones realizadas por los distintos
usuarios en el sistema.
(ID del usuario, Fecha, Hora, Tipo de Acción)

Gestionar Categorías
El administrador podrá realizar la creación de nuevas categorías, modificaciones y
eliminar categorías creadas.
(ID de Categoría, Tipo de Categoría, Descripción)

Gestionar Subcategorías
El administrador podrá realizar la creación de nuevas subcategorías para poder
ordenar en mejor detalle los productos, permitiendo modificaciones y eliminación de
subcategorías creadas.
(ID de subcategoría, Tipo de subcategoría, Descripción)

Gestionar Producto
Cumplirá la función de registrar, modificar los datos de los productos y también se
los podrá dar de baja, los datos a registrar serán:
(ID del producto, Nombre del producto, Descripción, Precio, Foto, Habilitado)

9
Gestionar Almacén
Se administrara la cantidad de stock de productos en cada almacén, realizando las
acciones de registrar, modificar y reducir la cantidad de stock de un producto
determinado en el sistema. Se registraran los siguientes datos:
(Nombre del Almacén, Stock)

Realizar la compra de un producto

El cliente podrá interactuar con el carrito realizando sus respectivas compras,
escogiendo sus productos por las cantidad que el desee y añadiéndolos a una
bolsa la cual contendrá todos los productos escogidos que se compraran. Los
datos a registrar serán:
(Cantidad, Precio Total)

Gestionar Bolsa
Aquí encontramos todos los productos que se escogieron para comprar en el cual
se podrá eliminar productos indeseados y confirmar la compra de los productos
para pasar a las metodologías de pago. En esta parte se anotara lo siguiente:
(Fecha, Precio Total, Puntos Ganados, Puntos Gastados)

Confirmar una metodología de Pago

Entre las metodología de Pagos que se tienen son: PayPal, Visa, MasterCard y los
Puntos por compra. Con respecto a los puntos estos son ganados por comprar en
la tienda online y pueden ser canjeados en la misma tienda. Para verificar que
productos están en promociones debemos ir a la sección de promociones la cual
dispone de los productos habilitados para ser comprados por puntos. Además de
esto la compra podrá hacer los cálculos respectivos para denotar el precio total
tanto usando puntos como no usándolos.

10
Realizar el proceso de Facturación e compra
Una vez se ha escogido la metodología de pago y confirmándola, se guardara e
imprimirá una factura detallada y se aumentaran los puntos ganados o se reducirán
los puntos gastados en la compra en la cuenta del cliente, se guardaran los
siguientes datos:
(ID del cliente, Nro. Bolsa)

Administrar Producto – Promoción Descuento

Permitirá al administrador asignar productos a una determinada promoción para
ofrecerla a los diferentes clientes tanto registrados como no en el sistema. Esto
podrá tanto habilitar como inhabilitar productos para su respectiva aplicación de
descuento en su precio.

Administrar Producto – Promoción por Puntos

Permitirá al administrador asignar productos a una determinada promoción para
ofrecerla a los diferentes clientes tanto registrados como no en el sistema. Esto
podrá tanto habilitar como inhabilitar productos para su promoción de Puntos.

Marketing

❖ Productos Populares: En esta parte mediante un filtro se denotaran los

productos que más son comprados en la tienda.
❖ Productos en Promoción de Descuento: En esta parte se observaran productos
que tendrán un descuento en su precio.
❖ Productos en Promoción por Puntos: En esta parte se verá los productos que
están en promoción para comprar por puntos en la tienda.

11
Reportes
❖ Generar reporte de venta: Se podrá obtener reporte de las ventas realizadas.
❖ Generar reporte de clientes: Se podrá obtener un reporte de los clientes
detallado de todos sus movimientos.
❖ Generar reporte de promoción: se emitirá un reporte de las diferentes
promociones ofrecidas por la empresa y como es que esta promoción fue
acogida por los clientes.

2. MARCO TEORICO METODOLOGÍA ÁGIL

2.1. Propósito de Scrum

Los propósitos de scrum son fundamentales para para que se pueda desarrollar el
proyecto con eficiencia de parte del equipo scrum.
Skills de un miembro de equipo scrum.

Los skills de un miembro de un equipo ágil se pueden clasificar en varios grupos,

según se basen en aportar valor al producto que desarrolla (calidad), en la
capacidad de colaborar con el resto de miembros del equipo o en la capacidad de
mejorar, a nivel técnico y humano.
La productividad y la innovación son el resultado de:
– Orientarse a proporcionar el máximo valor en el mínimo tiempo.
– Favorecer la colaboración en el equipo para conseguir las mejores sinergias
posibles
– Mejorar continuamente la manera de trabajar.
Ver Productividad y ejemplo de organización ágil

12
Veamos cuáles son estos grupos de skills en más detalle:

Inteligencia de negocio – Orientación a producir valor

El miembro del equipo scrum tiene que estar orientado a producir con CALIDAD,
tiene que saber compaginar los siguientes aspectos:

❖ Interés por entender el producto o negocio para el que trabaja. Se preocupa

por proporcionar valor al usuario final o consumidor.
❖ Tener una visión a medio plazo de los objetivos a conseguir (facilitada, por
ejemplo, por la Lista de objetivos priorizada (Product Backlog), tener pro
actividad (ser capaz de detectar oportunidades y anticipar riesgos) y aun así
(y dado que el foco está en proporcionar resultados tangibles cada
iteración):
✓ Buscar la simplicidad y la utilidad, conseguir la mejor solución
utilizando sólo el esfuerzo necesario y no trabajar en futuribles que
quizás no lleguen nunca o cambien.
✓ En línea con el principio de fluir en el proyecto (en que el equipo
minimiza el número de objetivos en curso, WIP), el miembro de un
equipo ágil acaba tareas y no deja temas abiertos, de manera que se
minimizan los cambios de contexto, aumentando la productividad y
avanzando en el proyecto.
❖ Pasión y orgullo por el trabajo que se realiza, ser exigente con la calidad
técnica, disciplinado y metódico, para que el producto pueda crecer de
manera sostenida.

13
 Inteligencia emocional – Capacidad de trabajar en equipo

El miembro del equipo scrum tiene que favorecer la COMUNICACIÓN y para ello
tener las siguientes aptitudes:

❖ Transparencia en las tareas que realiza y su estado, para que el resto del
equipo tenga la información necesaria (por ejemplo en las reuniones diarias
de sincronización (Scrum daily meetings) o en las retrospectivas), que todos
puedan colaborar y ayudarse a conseguir los objetivos de la iteración,
evitando también que se realicen esfuerzos innecesarios.
❖ Franqueza con el cliente sobre la situación del proyecto (especialmente en
las demostraciones (Sprint review)), para que pueda tomar decisiones
basadas en lo que realmente está hecho y en la velocidad del equipo.
❖ No hacerse dueño de conocimiento, si no compartirlo y ser capaz para
enseñar.
❖ Escucha activa, entender lo que le están explicando
❖ Observar, escuchar, preguntar mucho y re parafrasear para entender las
necesidades, motivaciones y sentimientos de los otros, ponerse en su lugar
antes de dar la propia opinión (si realmente es necesario ofrecerla). Es decir,
evitar juzgar inmediatamente al otro y tener empatía.
❖ El miembro del equipo ágil tiene que saber respetar las opiniones de los
otros y para ello tener las siguientes aptitudes:
❖ Confianza en los demás miembros del equipo, creer que serán capaces de
realizar sus tareas, sin necesidad de estar controlándolos, recordar siempre
que todos están actuando con la mejor voluntad posible, y tener paciencia.
Esta confianza se ve facilitada por la compartición de conocimiento que se
produce en las reuniones de alta productividad que el equipo al completo
realiza en las actividades de Scrum, las cuales necesitan de la transparencia
indicada anteriormente.

14
 ❖ Consensuar, ser capaz de negociar un ganar/ganar, no imponer su criterio.
Ser honesto y sincero, no engañar o aprovecharse de los otros (sean
clientes, gestores o miembros del equipo).
❖ Educación, buenas maneras, dando su opinión sin atacar ni acusar
(simplemente hablando de los hechos que le han sucedido), tranquilo, no
irascible, afable y con sentido del humor, para no vivir en tensión constante
y, por contra, compartir momentos de relajación con el resto del equipo.

Inteligencia vital – Capacidad de mejorar

El miembro del team es capaz de conjugar el progreso técnico y el humano, tiene

afán por APRENDER nuevas formas de trabajar y de relacionarse, y para ello tener
las siguientes aptitudes:

❖ Humildad, evitar la prepotencia (que no es necesaria, la valía se demuestra

realizando un trabajo excelente, el reconocimiento es una consecuencia que
debe llegar por sí solo), tener una mente abierta a escuchar ideas diferentes
de otros y flexibilidad para probar nuevas cosas.
❖ Capacidad de autocrítica, reconocer equivocaciones y tomarlas como
oportunidades de mejora. Similarmente, no buscar culpables cuando se
cometen errores, si no ver entre todos cómo mejorar el proceso de trabajo.
❖ Capacidad de reflexión e inconformismo productivo, cuando algo no funciona
ser capaz de cuestionar cómo se están haciendo las cosas. Tener valores,
ética, integridad, coraje para tomar decisiones y hacer “lo que se tiene que
hacer” (o no hacer lo que no se tiene que hacer), aunque sea más difícil
(asumiendo riesgos controlados). Para ello necesita ser asertivo en los
mensajes, hablar de manera clara, objetiva, ser franco (con compañeros,
gestores y clientes) sobre los problemas que hay y proponer alternativas
mejores.
❖ Creatividad, intuición, capaz de desaprender e innovar aportando nuevas
ideas tanto en el producto como en la manera de trabajar.

15
 ❖ Como se ha mencionado anteriormente, tiene que ser capaz de disfrutar en
el camino, realizarse en su trabajo (son muchas horas a la semana como
para que no sea así), aprendiendo, creando, superando retos, progresando y
contagiando entusiasmo al resto del equipo.
❖ Evitar estar en sobreesfuerzo continuo, tener como objetivo no trabajar más
de 40 horas a la semana (en caso contrario, cuando sea necesario un
sobreesfuerzo, no va a haber de donde sacar, sin contar con que la calidad
del trabajo se degrada cuando se alarga demasiadas horas) y dedicar el
tiempo restante a actividades personales, familiares, ocio, formarse, otros
proyectos. Es necesario disponer de tiempo para crecer a nivel personal y
profesional, para alcanzar un equilibrio y tener estos pilares vitales
afianzados

2.2. Visión General de Scrum

El scrum en cuanto a desarrollo, es descomponer un proyecto en varias fases, y

realizar tareas que se definen dentro de cada fase. Este enfoque se conoce como
“staged-gate”.

Se inicia con la demanda del cliente, o una necesidad que debe ser atendida. Tras
la identificación de las necesidades del cliente, el desarrollo se mueve a través de
las distintas fases (del proceso de lanzamiento del producto), hasta llegar al
proceso de prueba final, después del cual el producto pasa a producción y
finalmente es entregado al cliente.

16
2.3. El Equipo de Scrum (Scrum Team)

El Equipo Scrum consiste en un Dueño de Producto (Product Owner), el Equipo de

Desarrollo (Development Team) y un Scrum Master. Los Equipos Scrum son
autoorganizados y multifuncionales. Los equipos autoorganizados eligen la mejor
forma de llevar a cabo su trabajo y no son dirigidos por personas externas al
equipo. Los equipos multifuncionales tienen todas las competencias necesarias
para llevar a cabo el trabajo sin depender de otras personas que no son parte del
equipo. El modelo de equipo en Scrum está diseñado para optimizar la flexibilidad,
la creatividad y la productividad.

Los Equipos Scrum entregan productos de forma iterativa e incremental,

maximizando las oportunidades de obtener retroalimentación. Las entregas
incrementales de producto “Terminado” aseguran que siempre estará disponible
una versión potencialmente útil y funcional del producto.

2.4. El Dueño de Producto (Product Owner)

El Dueño de Producto es el responsable de maximizar el valor del producto y del
trabajo del Equipo de Desarrollo. El cómo se lleva a cabo esto podría variar
ampliamente entre distintas organizaciones, Equipos Scrum e individuos.
El Dueño de Producto es la única persona responsable de gestionar la Lista del
Producto (Product Backlog). La gestión de la Lista del Producto incluye:

❖ Expresar claramente los elementos de la Lista del Producto

❖ Ordenar los elementos en la Lista del Producto para alcanzar los objetivos y
misiones de la mejor manera posible.
❖ Optimizar el valor del trabajo desempeñado por el Equipo de Desarrollo.
❖ Asegurar que la Lista del Producto es visible, transparente y clara para
todos, y que muestra aquello en lo que el equipo trabajará a continuación.

17
 ❖ Asegurar que el Equipo de Desarrollo entiende los elementos de la Lista del
Producto al nivel necesario.

El Dueño de Producto podría hacer el trabajo anterior, o delegarlo en el Equipo de

Desarrollo. Sin embargo, en ambos casos el Dueño de Producto sigue siendo el
responsable de dicho trabajo.

El Dueño de Producto es una única persona, no un comité. El Dueño de Producto

podría representar los deseos de un comité en la Lista del Producto, pero aquellos
que quieran cambiar la prioridad de un elemento de la Lista deben hacerlo a través
del Dueño de Producto.

Para que el Dueño de Producto pueda hacer bien su trabajo, toda la organización
debe respetar sus decisiones. Las decisiones del Dueño de Producto se reflejan en
el contenido y en la priorización de la Lista del Producto. No está permitido que
nadie pida al Equipo de Desarrollo que trabaje con base en un conjunto diferente
de requerimientos, y el Equipo de Desarrollo no debe actuar con base en lo que
diga cualquier otra persona.

2.5. El Equipo de Desarrollo (Development Team)

El Equipo de Desarrollo consiste en los profesionales que desempeñan el trabajo

de entregar un Incremento de producto “Terminado”, que potencialmente se pueda
poner en producción, al final de cada Sprint. Solo los miembros del Equipo de
Desarrollo participan en la creación del Incremento.
Los Equipos de Desarrollo son estructurados y empoderados por la organización
para organizar y gestionar su propio trabajo. La sinergia resultante optimiza la
eficiencia y efectividad del Equipo de Desarrollo.

18
Los Equipos de Desarrollo tienen las siguientes características:

❖ Son autoorganizados. Nadie (ni siquiera el Scrum Master) indica al Equipo

de Desarrollo cómo convertir elementos de la Lista del Producto en

Incrementos de funcionalidad potencialmente desplegables.

❖ Los Equipos de Desarrollo son multifuncionales, contando como equipo con

todas las habilidades necesarias para crear un Incremento de producto.

❖ Scrum no reconoce títulos para los miembros de un Equipo de Desarrollo,

todos son Desarrolladores, independientemente del trabajo que realice cada

persona; no hay excepciones a esta regla.

❖ Scrum no reconoce sub-equipos en los equipos de desarrollo, no importan

los dominios particulares que requieran ser tenidos en cuenta, como pruebas

o análisis de negocio; no hay excepciones a esta regla.

❖ Los Miembros individuales del Equipo de Desarrollo pueden tener

habilidades especializadas y áreas en las que estén más enfocados, pero la

responsabilidad recae en el Equipo de Desarrollo como un todo.

Tamaño del Equipo de Desarrollo

El tamaño óptimo del Equipo de Desarrollo es lo suficientemente pequeño como

para permanecer ágil y lo suficientemente grande como para completar una
cantidad de trabajo significativa. Tener menos de tres miembros en el Equipo de
Desarrollo reduce la interacción y resulta en ganancias de productividad más
pequeñas.

19
Los Equipos de Desarrollo más pequeños podrían encontrar limitaciones en cuanto
a las habilidades necesarias durante un Sprint, haciendo que el Equipo de
Desarrollo no pudiese entregar un Incremento que potencialmente se pueda poner
en producción. Tener más de nueve miembros en el equipo requiere demasiada
coordinación.

Los Equipos de Desarrollo grandes generan demasiada complejidad como para

que pueda gestionarse mediante un proceso empírico. Los roles de Dueño de
Producto y Scrum Master no cuentan en el cálculo del tamaño del equipo a menos
que también estén contribuyendo a trabajar en la Lista de Pendientes de Sprint
(Sprint Backlog).

2.6. El Scrum Master

El Scrum Master es el responsable de asegurar que Scrum es entendido y

adoptado. Los Scrum Masters hacen esto asegurándose de que el Equipo Scrum
trabaja ajustándose a la teoría, prácticas y reglas de Scrum.

El Scrum Master es un líder que está al servicio del Equipo Scrum. El Scrum
Master ayuda a las personas externas al Equipo Scrum a entender qué
interacciones con el Equipo Scrum pueden ser de ayuda y cuáles no.

El Scrum Master ayuda a todos a modificar estas interacciones para maximizar el

valor creado por el Equipo Scrum.

20
El Servicio del Scrum Master al Dueño de Producto

El Scrum Master da servicio al Dueño de Producto de varias formas, incluyendo:

Encontrar técnicas para gestionar la Lista de Producto de manera efectiva.

❖ Ayudar al Equipo Scrum a entender la necesidad de contar con elementos

de Lista de Producto claros y concisos.

❖ Entender la planificación del producto en un entorno empírico.

❖ Asegurar que el Dueño de Producto conozca cómo ordenar la Lista de

Producto para maximizar el valor.

❖ Entender y practicar la agilidad.

❖ Facilitar los eventos de Scrum según se requiera o necesite.

El Servicio del Scrum Master al Equipo de Desarrollo

El Scrum Master da servicio al Equipo de Desarrollo de varias formas, incluyendo:

❖ Guiar al Equipo de Desarrollo en ser auto organizado y multifuncional.

❖ Ayudar al Equipo de Desarrollo a crear productos de alto valor.

❖ Eliminar impedimentos para el progreso del Equipo de Desarrollo.

❖ Facilitar los eventos de Scrum según se requiera o necesite; y Guiar al

Equipo de Desarrollo en el entorno de organizaciones en las que Scrum aún

no ha sido adoptado y entendido por completo.

21
El Servicio del Scrum Master a la Organización

El Scrum Master da servicio a la organización de varias formas, incluyendo:

❖ Liderar y guiar a la organización en la adopción de Scrum.

❖ Planificar las implementaciones de Scrum en la organización.

❖ Ayudar a los empleados e interesados a entender y llevar a cabo Scrum y el

desarrollo empírico de producto.

Motivar cambios que incrementen la productividad del Equipo Scrum; y, Trabajar

con otros Scrum Masters para incrementar la efectividad de la aplicación de Scrum
en la organización.

2.7. Eventos de Scrum

Otro factor determinante para la buena marcha de la metodología son los eventos
que realizan los distintos participantes, los cuales tienen lugar tanto en la etapa
previa del proceso como durante y después de su ejecución.

2.8. El Sprint

Se le considera la esencia del método Scrum. Son períodos cortos de 15-30 días
en los que se realiza una acción concreta. Cada sprint debe ponerse en marcha
sólo cuando el anterior haya terminado. Lo ideal es no modificar sus plazos y
tiempos; por el contrario, la mejor forma de obtener los resultados esperados es
cumpliendo con lo acordado.

22
2.9. Reunión de Planificación de Sprint (Sprint Planning Meeting)
La reunión de planificación del sprint es uno de los eventos de scrum técnico.

Descripción:
En esta reunión se toman como base las prioridades y necesidades de negocio del
cliente, y se determinan cuáles y cómo van a ser las funcionalidades que se
incorporarán al producto en el siguiente sprint.
Se trata de una reunión conducida por el responsable del funcionamiento del marco
scrum (Scrum Master en scrum técnico, o un miembro del equipo, en scrum
pragmático) a la que deben asistir el propietario del producto y el equipo completo,
y a la que también pueden asistir otros implicados en el proyecto.
La reunión puede durar una jornada de trabajo completa, cuando se trata de
planificar un sprint largo (de un mes de duración) o un tiempo proporcional para
planificar un sprint más breve. Esta reunión debe dar respuesta a dos cuestiones:
Qué se entregará al terminar el sprint.
Cuál es el trabajo necesario para realizar el incremento previsto, y cómo lo llevará a
cabo el equipo.
• La reunión se articula en dos partes de igual duración, para dar respuesta a
una de estas cuestiones, en cada una.
Precondiciones
La organización tiene determinados los recursos disponibles para llevar a cabo el
sprint.
Ya están “preparados” los elementos prioritarios de la pila del producto, de forma
que ya tienen un nivel de detalle suficiente y una estimación previa del trabajo que
requieren.
El equipo tiene un conocimiento de las tecnologías empleadas, y del negocio del
producto suficiente para realizar estimaciones basadas en juicio de expertos, y para
comprender los conceptos del negocio que expone el propietario del producto.

23
Entradas
La pila del producto.
El producto desarrollado hasta la fecha en los incrementos anteriores
(Excepto si se trata del primer sprint).
Dato de la velocidad o rendimiento del equipo en el último sprint, que se emplea
como criterio para estimar la cantidad de trabajo que es razonable suponer para el
próximo sprint.
Circunstancias de las condiciones de negocio del cliente y del escenario
tecnológico empleado.
Resultados
Pila del sprint.
Duración del sprint y fecha de la reunión de revisión.
Objetivo del sprint.
Formato de la reunión
Esta reunión marca el inicio de cada sprint. Duración máxima: un día. Asistentes:
Propietario del producto, equipo de desarrollo y Scrum Master. Pueden asistir: todo
aquellos que aporten información útil, ya que es una reunión abierta. Consta de dos
partes separadas por una pausa de café o comida, según la duración.

2.10. Objetivo del Sprint (Sprint Goal)

Cada iteración debe tener un objetivo claro, el cual está definido de antemano en el
Product Backlog. A medida que los equipos trabajan, se deben ir implementando
los recursos previstos u otros que no se habían tenido en cuenta previamente.

24
2.11. Scrum Diario (Daily Scrum)

La reunión de scrum diario es uno de los eventos de scrum técnico.

Descripción
Reunión diaria breve, de no más de 15 minutos, en la que el equipo sincroniza el
trabajo y establece el plan para las 24 horas siguientes.
Entradas
Pila del sprint y gráfico de avance (burn-down) actualizados con la
información de la reunión anterior.
Información del avance de cada miembro del equipo
Resultados
❖ Pila del sprint y gráfico de avance (burn-down) actualizados
❖ Identificación de posibles necesidades e impedimentos.

Formato de la reunión
Se recomienda realizarla de pie junto a un tablero con la pila del sprint y el gráfico
de avance del sprint, para que todos puedan compartir la información y anotar. En
la reunión está presente todo el equipo, y pueden asistir también otras personas
relacionadas con el proyecto o la organización, aunque éstas no pueden intervenir.
En esta reunión cada miembro del equipo de desarrollo explica:
❖ Lo que ha logrado desde el anterior scrum diario.

❖ Lo que va a hacer hasta el próximo scrum diario.

Si están teniendo algún problema, o si prevé que puede encontrar algún

impedimento.

25
Y actualiza sobre la pila del sprint el esfuerzo que estima pendiente en las tareas
que tiene asignadas, o marca como finalizadas las ya completadas. Al final de la
reunión:
-El equipo refresca el gráfico de avance del sprint, con las estimaciones
actualizadas,
- El Scrum Master realiza las gestiones adecuadas para resolver las
necesidades o impedimentos identificados.
El equipo es el responsable de esta reunión, no el Scrum Master; y no se trata de
una reunión de “inspección” o “control” sino de comunicación entre el equipo para
compartir el estado del trabajo, chequear el ritmo de avance y colaborar en posibles
dificultades o impedimentos.

2.12. Revisión de Sprint (Sprint Review)

La reunión de revisión del sprint es uno de los eventos de scrum técnico.
Descripción
Reunión realizada al final del sprint para comprobar el incremento. . No debe durar
más de 4 horas, en el caso de revisar sprints largos. Para sprints de una o dos
semanas, con una o dos horas de duración debería ser suficiente.
Objetivos:
❖ El propietario del producto comprueba el progreso del sistema. Esta reunión

marca, a intervalos regulares, el ritmo de construcción, y la trayectoria que

va tomando la visión del producto.

❖ El propietario del producto identifica las funcionalidades que se pueden

considerar “hechas” y las que no.

❖ Al ver y probar el incremento, el propietario del producto, y el equipo en

general obtienen feedback relevante para revisar la pila del producto.

❖ Otros ingenieros y programadores de la empresa también pueden asistir

para conocer cómo trabaja la tecnología empleada.

26
Formato de la reunión
Es una reunión informal. El objetivo es ver el incremento realizado. Están
prohibidas las presentaciones gráficas y “PowerPoint”. El equipo no debe invertir
más de una hora en desarrollar la reunión, y lo que se muestra es el resultado final:
terminado, probado y operando en el entorno del cliente (incremento). Según las
características del proyecto puede incluir también documentación de usuario, o
técnica. Es una reunión informativa. Su misión no es la toma de decisiones ni la
crítica del incremento. Con la información obtenida, posteriormente el propietario
del producto tratará las posibles modificaciones sobre la visión del producto.

Protocolo recomendado:
1. El equipo expone el objetivo del sprint, la lista de funcionalidades que se incluían
y las que se han desarrollado.
2. El equipo hace una introducción general del sprint y demuestra el funcionamiento
de las partes construidas.
3. Se abre un turno de preguntas y sugerencias. Esta parte genera información
valiosa para que el propietario del producto y el equipo en general, puedan mejorar
la visión del producto.
4. El Scrum Master, de acuerdo con las agendas del propietario del producto y el
equipo, cierra la fecha para la reunión de preparación del siguiente sprint.

2.13. Retrospectiva de Sprint (Sprint Retrospective)

Con el objetivo de mejorar de manera continua su productividad y la calidad del
producto que está desarrollando, el equipo analiza cómo ha sido su manera de
trabajar durante la iteración, por qué está consiguiendo o no los objetivos a que se
comprometió al inicio de la iteración y 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
27
Cuáles son los problemas que podrían impedirle progresar adecuadamente. El
Facilitador se encargará de ir eliminando los obstáculos identificados que el propio
equipo no pueda resolver por sí mismo.
Notar que esta reunión se realiza después de la reunión de demostración al cliente
de los objetivos conseguidos en la iteración, para poder incorporar su feedback y
cumplimiento de expectativas como parte de los temas a tratar en la reunión de
retrospectiva
Se realiza en un timebox de cómo máximo 3 horas (si la iteración es mensual).
Beneficios
Incrementa la productividad en el proyecto, la calidad del producto (cosa que
permite hacerlo crecer de manera sostenida) y potencia el aprendizaje del equipo
de manera sistemática, iteración a iteración, con resultados a corto plazo.
Aumenta la motivación del equipo dado que participa en la mejora de proceso, se
siente escuchado, toma decisiones consensuadas (y más sostenibles) para ir
eliminando lo que molesta e impide que sea más productivo.
Restricciones
En necesario que el Equipo y el Facilitador dispongan de autoridad, mecanismos y
recursos para ir mejorando su forma de trabajar y el contexto del proyecto. Es
frustrante encontrar sistemáticamente los mismos obstáculos y no poder
solucionarlos.

2.14. Artefactos de Scrum

Backlog de Producto
El Backlog de Producto es un listado dinámico y públicamente visible para todos los
involucrados en el proyecto.

28
En él, el Dueño de Producto, mantiene una lista actualizada de requerimientos
funcionales para el software. Esta lista, representa "qué es lo que se pretende"
pero sin mencionar "cómo hacerlo", ya que esta última, como vimos en el capítulo
anterior, será tarea del Scrum Team.

El Backlog de Producto, es creado y modificado únicamente por el Dueño de

Producto. Durante la ceremonia de planificación, el Scrum Team obtendrá los items
del producto, que deberá desarrollar durante el Sprint. Formato del Backlog de
Producto

El Backlog de producto, es una lista de items que representan los requerimientos

funcionales esperados para el software.
Para cada uno de estos ítems, será necesario especificar:
❖ El grado de prioridad
❖ Esfuerzo que demanda
❖ Granulidad
❖ Criterios de aceptación

Priorización de los ítems del Backlog de Producto

Los ítems del backlog de producto, deben guardar un orden de prioridad, cuya base
se apoye en:
Beneficios de implementar una funcionalidad
Pérdida o costo que demande posponer la implementación de una
funcionalidad
Riesgos de implementarla
Coherencia con los intereses del negocio
Valor diferencial con respecto a productos de la competencia
Estimación de esfuerzo
A diferencia de las metodologías tradicionales, Scrum, propone la estimación de
esfuerzo y complejidad que demanda el desarrollo de las funcionalidades, solo para
aquellas cuyo orden sea prioritario.

29
Estas estimaciones, no se efectúan sobre items poco prioritarios ni tampoco sobre
aquellos donde exista un alto grado de incertidumbre.
De esta manera, se evita la pérdida de tiempo en estimaciones irrelevantes,
postergándolas para el momento en el cual realmente sea necesario comenzar a
desarrollarlas.
Granulidad de los ítems
Los items del Backlog de Producto no necesariamente deben tener una granulidad
pareja. Es posible encontrar ítems tales como "es necesario contar con un módulo
de control de stock y logística" o uno tan pequeño como "Modificar el color de fondo
de los mensajes de error del sistema, de negro a rojo".

Ítems de tan baja granulidad, suelen agruparse en un formato denominado

"Historias de Usuario" mientras que los de alta granulidad, son los denominados
Temas o Epics.

Una historia de usuario es aquella que puede escribirse con la siguiente frase
Como [un usuario], puedo [una funcionalidad] para [un beneficio]
Como usuario registrado, puedo cargar un voucher para calcular mi descuento en
la compra.

Criterios de Aceptación
Cada ítem del Backlog de Producto, es necesario que especifique cuales son los
criterios de aceptación (o test de aceptación que debe superar), para considerar
cumplido el requisito.

Backlog de Sprint
es la recopilación sintética de items del Backlog de Producto, negociados entre el
Dueño de Producto y el Scrum Team en la ceremonia de planificación,
reunión que se realiza al comienzo del Sprint.

30
Esta recopilación, que durante la planificación ha sido propuesta por el Dueño de
Producto y ya negociada, es aquella que el Scrum Team se compromete a
construir durante el Sprint en curso.
El Backlog de Sprint, generalmente (y muy recomendado), se visualiza mediante
tableros físicos – también llamados Scrum Taskboard - que hacen visible el
proceso de construcción, a toda persona que ingrese al área de desarrollo.
Para armar el Backlog de Sprint, el Scrum Team, divide los items en tareas – tasks
– de que no demanden una labor superar a una jornada de trabajo. Es decir, que
una tarea, no debería superar las 8 horas de trabajo.
Estas tareas, serán divididas en pendientes, en curso y terminadas y cada una de
ellas, debe permitir visualizar, como mínimo, el esfuerzo que demanda su
construcción y el nombre del miembro del equipo que se ha asignado dicha tarea.

Dividiendo un ítem del Backlog de producto en tareas

La estrategia consiste en desmembrar el ítem a la mínima expresión posible,
encuadrada en un mismo tipo de actividad. El desmembramiento debe hacerse "de
lo general a lo particular, y de lo particular al detalle".
Retomando el ejemplo anterior, intentaremos desmembrar, el primer ítem del
Backlog de Producto:

Como administrador quiero poder administrar las secciones del sistema para poder
establecer el orden de visualización de las mismas
Otro detalle a considerar, es el tiempo que demanda cada tarea. Por ejemplo,
correr un ORM lleva solo algunos minutos, pues no puede ser considerado una
única tarea. Entonces, puede "sumarse como detalle" a la tarea "crear modelos".
De manera contraria, documentar en el manual del usuario, llevará todo un día de
trabajo. Por lo cual, debe asignarse a una única tarea.

31
Tableros de Scrum
Con la lista de tareas ya armada, estamos en condiciones de crear el tablero
Un Scrum Taskboard, básicamente se divide en 3 columnas: pendientes, en curso
y terminadas y se complementa la información con un Diagrama de Burndown que
mostrará el esfuerzo restante para concluir el Sprint.

Incremento de Funcionalidad

El incremento de funcionalidad, es el que el equipo entrega al finalizar el Sprint. El

mismo debe asemejarse a un "software funcionando", permitiendo implementarse
operativamente sin restricciones en un ambiente productivo.

2.15. Lista de Productos (Product Backlog)

La lista de objetivos/requisitos priorizada representa la visión y expectativas

del cliente respecto a los objetivos y entregas del producto o proyecto. El cliente es
el responsable de crear y gestionar la lista (con la ayuda del Facilitador y del
equipo, quien proporciona el coste estimado de completar cada requisito). Dado
que reflejar las expectativas del cliente, esta lista permite involucrarle en la
dirección de los resultados del producto o proyecto.

❖ Contiene los objetivos/requisitos de alto nivel del producto o proyecto, que

se suelen expresar en forma dehistorias de usuario. Para cada
objetivo/requisito se indica el valor que aporta al cliente y el costo
estimado de completarlo. La lista está priorizada balanceando el valor que
cada requisito aporta al negocio frente al coste estimado que tiene su
desarrollo, es decir, basándose en el Retorno de la Inversión (ROI).

32
 ❖ En la lista se indican las posibles iteraciones y las entregas (releases)
esperadas por el cliente (los puntos en los cuales desea que se le entreguen
los objetivos/requisitos completados hasta ese momento), en función de la
velocidad de desarrollo del (los) equipo(s) que trabajará(n) en el proyecto.
Es conveniente que el contenido de cada iteración tenga una coherencia, de
manera que se reduzca el esfuerzo de completar todos sus objetivos.
❖ La lista también tiene que considerar los riesgos del proyecto e incluir los
requisitos o tareas necesarios para mitigarlos.

2.16. Lista de Pendientes del Sprint (Sprint Backlog)

Lista de tareas que el equipo elabora en la reunión de planificación de la iteración
(Sprint planning) como plan para completar los objetivos/requisitos seleccionados
para la iteración y que se compromete a demostrar alcliente al finalizar la iteración,
en forma de incremento de producto preparado para ser entregado.
Esta lista permite ver las tareas donde el equipo está teniendo problemas y no
avanza, con lo que le permite tomar decisiones al respecto.
Para cada uno de los objetivos/requisitos se muestran sus tareas, el esfuerzo
pendiente para finalizarlas y la auto asignación que han hecho los miembros del
equipo.

2.17. Incremento
El incremento es la parte de producto producida en un sprint, y tiene como
característica el estar completamente terminada y operativa, en condiciones de ser
entregadaalcliente.

33
No se deben considerar como Incremento a prototipos, módulos o sub-módulos, ni
partes pendientes de pruebas o integración. Idealmente en scrum:
❖ Cada elemento de la pila del producto se refiere a funcionalidades
entregables, no a trabajos internos del tipo “diseño de la base de datos”.
❖ Se produce un “incremento” en cada iteración.

Sin embargo es una excepción frecuente el primer sprint. En el que objetivos del
tipo “contrastar la plataforma y el diseño” pueden resultar necesarios, e implican
trabajos de diseño o desarrollo de prototipos para contrastar las expectativas de la
plataforma o tecnología que se va a emplear. Teniendo en cuenta esta excepción
habitual:
Incremento es la parte de producto realizada en un sprint potencialmente
entregable: terminada y probada.
Si el proyecto o el sistema requiere documentación, o procesos de validación y
verificación documentados, o con niveles de independencia que implican procesos
con terceros, éstos también tienen que estar realizados para considerar que el
incremento está “hecho”.

2.18. Transparencia de los Artefactos

Scrum se basa en la transparencia. Las decisiones para optimizar el valor y
controlar el riesgo se toman basadas en el estado percibido de los artefactos. En la
medida en que la transparencia sea completa, estas decisiones tienen unas bases
sólidas.
En la medida en que los artefactos no son completamente transparentes, estas
decisiones pueden ser erróneas, el valor puede disminuir y el riesgo puede
aumentar. El Scrum Master debe trabajar con el Dueño de Producto, el Equipo de
Desarrollo y otras partes involucradas para entender si los artefactos son
completamente transparentes. Hay prácticas para hacer frente a la falta de
transparencia; el Scrum Master debe ayudar a todos a aplicar las prácticas más
apropiadas si no hay una transparencia completa.

34
Un Scrum Master puede detectar la falta de transparencia inspeccionando
artefactos, reconociendo patrones, escuchando atentamente lo que se dice y
detectando diferencias entre los resultados esperados y los reales. La labor del
Scrum Master es trabajar con el Equipo Scrum y la organización para mejorar la
transparencia de los artefactos.
Este trabajo usualmente incluye aprendizaje, convicción y cambio. La transparencia
no ocurre de la noche a la mañana, sino que es un camino.

2.19. Definición de “Terminado”

La Definición de Hecho (Definition of Done) permite:
Establecer un criterio de calidad, define qué entregables y mínimos de calidad
tienen se tienen que cumplir en TODOS los objetivos / requisitos que se van a ir
aceptando durante cada iteración del proyecto.
Tener siempre un producto “potencialmente entregable” al Product Owner (cliente)
al finalizar cada iteración, no dejar trabajo pendiente para el final, escondido
“debajo de la alfombra”, que pueda impedir utilizar los resultados del proyecto lo
antes posible.
Esto permite saber claramente en qué punto real se está del proyecto y tomar
buenas decisiones al respecto sobre lo que se ha conseguido hasta ese momento y
lo que todavía no se sabe con certeza cuándo estará acabado. Con una buena
Definición de Hecho, el cliente podrá tomar decisiones correctas cuando al final de
cada iteración el equipo le haga una demostración de los requisitos
completados: cambiar las prioridades en función de la velocidad de desarrollo,
solicitar una entrega del producto desarrollado hasta ese momento, etc.
Por otro lado, lo peor que podría suceder es que, aunque el equipo haya ido
presentando todos los objetivos / requisitos completados durante el proyecto (en
cada iteración), se podría dar el caso de que los días previos a una entrega de
repente se den cuenta de que hay que hacer mucho trabajo de integración y
finalización (que podría haberse ido haciendo antes, durante el proyecto). Esto
también les dificultaría estimar cuándo tiempo necesitan para acabar de terminar el
producto (lo cual pondría en peligro la fecha de entrega).
35
La Definición de Hecho se acuerda entre el Product Owner (cliente) y el Equipo de
desarrollo al principio del proyecto y se puede ir mejorando durante su transcurso
(si es necesario precisar más las expectativas en cuanto a calidad global o del
proceso de trabajo o, simplemente, tras una Retrospectiva, para ir consiguiendo
una mejor la calidad del producto final).

2.20. Ventajas y Desventajas

La Metodología Ágil (SCRUM) tiene las siguientes:

2.20.1. Ventajas
❖ Entregables en tiempo y forma, puedes ir enviando entregables al cliente
mientras vas atacando los objetivos más sencillos, eso te hace ganar tiempo
para atacar los objetivos más complejos.
❖ El ScrumMaster tiene el conocimiento necesario para lograr el objetivo
primario y secundario por lo cual puede ir controlando el proyecto y
delegando roles.
❖ Cada persona sabe que es lo que tiene que hacer y no es necesario estar
reorganizando una y otra vez los Tracks de cada persona.
❖ Se involucra desde un principio y se da un rol a todos los stakeholders
(personas que van a participar en el proyecto incluyendo cliente final, QA,
Testers, etc.)

2.20.2. Desventajas
❖ Algunos miembros de tu equipo pueden saltar pasos importantes en el
camino rápido para llegar al “sprint” final.
❖ El cliente siempre va a esperar los informes con la fecha exacta, y muchas
veces los va a pedir antes, cuando capaz no pudiste avanzar en
nada.Demasiadas reuniones para poco avance, a veces es muy cansador y
estresante reunirse demasiadas veces por el mismo tema, algunos van
perdiendo el interés en el proyecto.

36
Si una persona renuncia o hay algún cambio es complicado remplazar ese rol ya
que es la persona que se lleva el conocimiento específico y afecta a todo el
proyecto.

2.21. Valores de Trabajo

Scrum se construye sobre cinco pilares:

1.- FOCO
Los equipos Scrum se enfocan en un conjunto acotado de características por vez.
Esto permite que al final de cada Sprint se entregue un producto de alta calidad y
adicional mente se reduce el time-to-Marquet.

2.-CORAJE
Debido a que los equipos Scrum trabajan como verdaderos equipos nos apoyamos
entre compañeros para así asumir compromisos desafiantes.

3.- APERTURA
Nos permite una discusión abierta de los problemas que tenemos al realizar el
proyecto, la información está disponible para todos.

4.- COMPROMISO
Cada integrante del equipo debe tener un compromiso para lograr el éxito del
grupo.
Ya que el grupo trabaja en forma conjunta compartiendo éxitos y fracasos se
fomenta el respeto mutuo.

5.- RESPETO
Ya que el grupo trabaja en forma conjunta compartiendo éxitos y fracasos se
fomenta el respeto mutuo.

37
2.22. Herramientas de trabajo

Herramienta #1 – JIRA
JIRA es una aplicación, basada en el estándar J2EE, para la administración de
proyectos que ofrece flexibilidad y adaptabilidad para satisfacer las necesidades
particulares de los distintos modelos de gestión de los mismos. Esto le permite
adaptarse fácilmente a métodos propios del agilismo como Scrum o Kanban.
Documentación de US (y gestión del conocimiento) en Confluence y transformarse
en tareas en JIRA. Facilitar el flujo de trabajo de desarrollo actualizando
automáticamente los issues de JIRA cuando un desarrollador introduce código en
Stash o Bitbucket haciendo “Commit”. Implementar Continuous integration
mediante Bamboo y supervisar el estado de los builds desde dentro de JIRA.

Herramienta # 2 – SeeNowDo
SeeNowDo ofrece una interfaz de usuario simple y sencilla para la creación y
especificación de US, así como también para la generación de sprints, y la
correspondiente asignación de US a sprints. Si bien provee funcionalidad para
estadísticas y generación de charts, posee dos grandes limitaciones: por un lado,
no existe el concepto de backlog. Todo debe desarrollarse dentro de sprints, lo cual
hace difícil el manejo y gestión de US. Por otro lado, su performance no es buena.
Aún con proyectos chicos de pocas US la herramienta se vuelve lenta. Su principal
ventaja es que en la versión gratuita tiene disponible toda su funcionalidad y no es
necesario abonar por features adicionales.

Herramienta #3 AgileFant
AgileFant es de las herramientas que mayor crecimiento registra en cuanto a
popularidad y cantidad de usuarios. Es bastante completa, incluye generación de
estadísticas, velocity, burndown charts y utilización de métricas. Una característica
interesante es que brinda la posibilidad de definir US generales (denominadas
también EPIC Stories) y luego ir refinándolas, agregándoles más detalle a medida
que el proyecto avanza.
38
Entre sus puntos débiles se puede mencionar la poca flexibilidad para personalizar
la herramienta, y su inexistente integración con otros sistemas, lo cual puede
atentar contra su utilización en ambientes corporativos.

Herramienta #4 RallyDev
RallyDev es también una poderosa herramienta para la gestión de proyectos ágiles.
Posee características avanzadas entre las cuales se destaca la generación
automática de los distintos diagramas de seguimiento y la posibilidad de
exportarlos a diferentes formatos. Esto es particularmente útil para la generación
automática de reportes. Brinda también la posibilidad de control de cambios y
revisiones para el manejo de US. Finalmente, dentro de cada US es posible definir
criterios de aceptación como casos de tests, lo cual facilita la interacción con la
fase de testing. Entre sus puntos débiles se puede mencionar una interfaz poco
amigable, y bajo rendimiento en cuanto al tiempo esperado de respuesta para
algunas características.

Herramienta #5 Trello
Trello es un servicio en la nube muy recomendable para gestionar proyectos o
tareas y coordinar a un equipo de trabajo. Con este servicio dispondremos de una
pizarra digital (o board) en la que podremos abrir columnas en las que ir agrupando
tarjetas (o cards) con las tareas que tenemos que asignar. Dicho de otra forma, si
por ejemplo tuviésemos un flujo de trabajo con tareas abiertas, tareas en ejecución,
tareas en espera y tareas finalizadas (muy cercano a GTD), podríamos ir moviendo
las tarjetas entre estos estados y, de un vistazo, ver el estado de nuestras tareas.
¿Y qué tiene que ver Trello con Scrum? Pizarra y tarjetas, dos componentes que se
incluyen en Trello y que podemos aplicar para ayudarnos a realizar la planificación
de los sprints de nuestro proyecto.

39
3. PERSONAS Y ROLES DEL PROYECTO
ROL ENCARGADO TAREAS

Coordinar con el cliente y el

PRODUCT OWNER Cardona Chavez Alex
equipo.

Gestionar la pila del producto

(Product Backlog).

SCRUM MASTER Hurtado Gutiérrez Erasmo Realizar el seguimiento de los

procesos.
Cuarto

Garantizar el cumplimiento de
roles y responsabilidades.

Mejorar el trabajo en equipo.

Avisa Mamani Alexander Transformar la pila del sprint

TEAM
Colque Orellana Nicolas
(Sprint Backlog).
Limachi Sarzuri Grover
Fernando
Responsables de aspectos
Portugal Hurtado Maguin
técnicos.

40
4. MODELOS USADOS PARA EL DESARROLLO DE SCRUM
4.1. Reunión de planeamiento del Sprint (Sprint Planning)
ABRIL
SPRINT 0 SPRINT 1 SPRINT 2 SPRINT 3
TERMINADO
ACTIVIDAD 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
ESTABLECIMIENTO DE
LOS OBJETIVOS
GENERALES Y
ESPECIFICOS X
ESTABLECIMIENTO DEL
ALCANCE X
PLANIFICACION DEL
CRONOGRAMA DE
TRABAJO X
DESARROLLO DEL
PRODUCT BACKLOG X
ESTABLECIMIENTO DE
ROLES X
ANALISIS DE
REQUISITOS X X X X X
DESARROLLO DEL
LOGIN DE USUARIO X X X X
REUNION DEL SPRINT X
DESARROLLO DEL
PAQUETE
ADMINISTRACION DE
USUARIOS X X X X X X

41
REUNION DEL SPRINT X
DESARROLLO DEL
PAQUETE ADMINISTRAR
ALMACEN Y
PROVEEDORES X X X
REUNION DEL SPRINT X
DESARROLLO DEL
PAQUETE ADMINISTRAR
PRODUCTO Y
CATEGORIA X
DESARROLLO DEL
PAQUETE ADMINISTRAR
VENTA X X
REUNION DEL SPRINT X

42
4.2. Pila de Sprint (Sprint Backlog 0)

ID PRIORIDAD TAREA TIPO ESTADO RESPONSABLE

HU0-1 Alta Entrevista con ProductOwner Análisis Terminado Erasmo
Explicar al ProductOwner como Erasmo
HU0-2 Alta Análisis Terminado
funciona la metodología a usar
Crear un perfil que explique la Erasmo, Alex
HU0-3 Alta Diseño Terminado
finalidad del proyecto
Asignación de roles a los miembros Grover
HU0-4 Alta Análisis Terminado
del equipo
Capacitación de los miembros del Grover, Nicolas,
HU0-5 Alta equipo en las herramientas a Capacitación Terminado Maguin, Alexander
utilizar
Diseñar un modelo de base de Grover, Nicolas,
HU0-6 Alta Diseño Terminado
Datos Maguin, Alexander
Encontrar y desarrolar los casos de Erasmo
HU0-7 Alta Análisis En curso
Uso funcionales
Preparación del entorno de Grover, Nicolas,
HU0-8 Alta Preparación Terminado
desarrollo de programación Maguin, Alexander

43
 4.3. Elementos: Pila del Sprint

02-abril
03-abril
04-abril
05-abril
06-abril
07-abril
08-abril
Sprint Inicio Duración
0 06-sep 7 dias
Tareas Pendientes 10 7 6 6 2 1 1
Horas de trabajo Pendientes 10 2 6 19 4 2 1
Pila Del Sprint
ESFUERZO
Código Tarea Tipo Estado Responsable
Entrevista con Análisis Terminado Hurtado Gutiérrez
HU0-1 ProductOwner Erasmo Cuarto
1 1 1 2 1 1 1
Explicar al Análisis Terminado Hurtado Gutiérrez
ProductOwner como Erasmo Cuarto
HU0-2
funciona la
metodología a usar 1 1 1 2 1 1 1
Crear un perfil que Preparación Terminado Hurtado Gutiérrez
explique la finalidad Erasmo Cuarto
HU0-3 del proyecto Cardona Chávez
Alex
1 1 1 2 1 1 1
Asignación de roles a Análisis Terminado Avisa Mamani
los miembros del Alexander
Colque Orellana Nicolás
HU0-4 equipo LimachiSarzuriGrover
Fernando
Portugal Hurtado Maguin 1 1 1 2 1 1 1
Capacitación de los Capacitación Terminado Avisa Mamani
miembros del equipo Alexander
Colque Orellana Nicolás
HU0-5 en las herramientas a LimachiSarzuriGrover
utilizar Fernando
Portugal Hurtado Maguin 1 1 1 2 1 1 1
Diseñar un modelo de Diseño Terminado Avisa Mamani
base de Datos Alexander
Colque Orellana Nicolás
HU0-6 LimachiSarzuriGrover
Fernando
Portugal Hurtado Maguin 1 1 1 2 1 1 1
Encontrar los casos de Análisis Terminado Hurtado Gutiérrez
HU0-7 Uso funcionales Erasmo Cuarto
1 1 1 2 1 1 1
Preparación del Preparación Terminado Avisa Mamani
entorno de desarrollo Alexander
Colque Orellana Nicolás
HU0-8 de programación LimachiSarzuriGrover
Fernando
Portugal Hurtado Maguin 1 1 1 2 1 1 1

44
4.4. Sprint Review
Durante el Sprint 0, se realizó la planificación necesaria a través de la
información recopilada previamente con la misión de cumplir con la
metodología elegida SCRUM definiendo que el sistema será dirigido al
desarrollo del B2C de un sistema E-commerce. Para cumplir con lo establecido
se realizó una capacitación a todo el equipo de trabajo y se definió un plan de
desarrollo por Sprints designando diferentes roles por cada etapa del proyecto;
En la cual hubieron cerca de 4 reuniones por semana con 2 horas por reunión
y un continuo trabajo por realizar las tareas asignadas. Hubo bastante
colaboración entre todos los compañeros del grupo teniendo en cuenta nuestro
inicio tardío como grupo.

4.5. Sprint Retrospective

Durante el HU0-1 no tuvimos ningún inconveniente ya que conocíamos

bastante sobre el tema más al contrario pudimos escoger con facilidad el tipo
de e-comerce que desarrollaríamos.

En el HU0-3 el trabajo fue bastante duro debido a que esos momentos solo
eramos 2 personas en el grupo a pesar de eso pudimos desarrollar las tareas
con éxito y precisión.

Ya en el HU04 pudimos asignar con más facilidad tareas debido a que ya

pudimos tener un grupo de integrantes completo.

En la Capacitación del HU0-5 no hubo discusión sobre las herramientas que

utilizaríamos y pudimos hacer la entrega de ellas en una reunión.

En el diseño de la base de datos en el HU0-6 hubo bastante confusión por

parte del equipo de desarrollo el cual no pudo completar correctamente la base
de datos, pero esto ya fue solucionado, corregido y mejorado por parte de ellos
cuando se pudo explicar y solucionar los errores.

En el HU0-7 fue bastante sencillo encontrar los requisitos funcionales debido a

que teníamos una comprensión bastante clara del alcance.
Pata finalizar en el HU0-8 con bastante dificultad pudimos completar la tarea de
acomodar el entorno de desarrollo en todos los integrantes.

45
4.6. Proceso Scrum (Roles, componentes, reuniones y pilas de
producto por sprint)

En el proceso de Scrum se tienen los siguientes puntos, que desarrollaremos

para el siguiente proyecto:

Product Backlog: En el Sprint 0 se definieron 8 Historias principales las cuales

establecen lo requerido por el Product Owner.

Sprint Planning: Para realizar el Product Backlog previamente establecido se

realizó una reunión con todos los miembros del equipo para informarles sobre
las historias de usuario que se realizaran con vista al desarrollo del proyecto.

Sprint Backlog: Para el Sprint 0 se hicieron las siguientes tareas:

Recopilación de Fuentes de Información

Planeamiento del Proyecto
Metodología
Definir la Visión del Sistema
Capacitación del equipo (TEAM)
Designación de roles
Definir el plan de desarrollo del Sistema
Elección de herramientas
Diseño de la base de datos
Definir el plan de entrega

Demostración y Retrospectiva: Realizado el Sprint Backlog se agendo una cita

con el Product Owner para informarle sobre el avance realizado hasta el
momento entregando una documentación para que el analice las posibles
falencias de la planeación del proyecto, para que con este análisis realizado se
organice una reunión con el equipo y se corrijan las fallas que se tuvieron así
mejorando le producto final.

46
 4.7. Ejecución de la Iteración

ID Prioridad Tipo Tarea Responsable Estado Estim.

Entrevista
Scrum Master
HT1 Alta Análisis con Product Terminado 6 Horas
(Erasmo)
Owner
Explicar al
Product
Owner como Scrum Master
HT2 Alta Análisis Terminado 6 Horas
funciona la (Erasmo)
metodología
a usar
Crear un
Product Owner
perfil que
(Alex) Scrum
HT3 Alta Diseño explique la Terminado 6 Horas
Master
finalidad del
(Erasmo)
proyecto
Equipo
Asignación
(Grover,
de roles a los
HT4 Alta Análisis Nicolas, Terminado 6 Horas
miembros del
Maguin,
equipo
Alexander)
Capacitación
Equipo
de los
(Grover,
miembros del
HT5 Alta Capacitación Nicolas, Terminado 6 Horas
equipo en las
Maguin,
herramientas
Alexander)
a utilizar
Equipo
Diseño de la (Grover,
HT6 Alta Diseño base de Nicolas, Terminado 6 Horas
datos Maguin,
Alexander)
Encontrar los
Scrum Master
HT7 Alta Análisis casos de Uso Terminado 6 Horas
(Erasmo)
funcionales
Preparación Equipo
del entorno (Grover,
HT8 Alta Preparación de desarrollo Nicolas, Terminado 6 Horas
de Maguin,
programación Alexander)

47
4.8. Diagrama de Clase

48
4.9. Lista de Casos de Uso y Diagrama de Casos de Uso
4.9.1. Lista de Casos de Uso

Numero # - Caso de Uso Nombre del Caso de Uso

CU1 Gestionar Usuario
CU2 Gestionar Privilegios
CU3 Gestionar Acciones
CU4 Gestionar Perfil
CU5 Gestionar Rank de Comprador
CU6 Gestionar Mensajes
CU7 Gestionar Almacén
CU8 Gestionar Proveedor
CU9 Gestionar Empresa
CU10 Gestionar Tipo de Empresa
CU11 Gestionar Producto
CU12 Gestionar Categoría
CU13 Gestionar Subcategoria
CU14 Gestionar Descuento
CU15 Gestionar Venta
CU16 Gestionar Estado
CU17 Gestionar Pago
CU18 Gestionar Promociones de Descuento
CU19 Gestionar Promociones por Puntos
CU20 Gestionar Venta Mayor
CU21 Gestionar Moneda

49
4.9.2. Diagrama General de Casos de Uso

50
4.10. Paquetes de Casos de Uso
4.10.1. Paquete Usuario

51
4.10.2. Paquete Inventario

52
4.10.3. Paquete Venta

53
4.10.4. Paquete Promociones

54
4.11. Artefacto
4.11.1. Product Backlog

ID Descripción Prioridad Estado Estimación Responsable

1 Gestionar Usuario Baja Pendiente 8 Alexander
2 Gestionar Normal Pendiente 6 Alexander
Privilegios
3 Gestionar Acciones Normal Pendiente 6 Alexander
4 Gestionar Perfil Normal Pendiente 6 Alexander
5 Gestionar Rank de Alta Pendiente 4 Alexander
Comprador
6 Gestionar Mensajes Alta Pendiente 4 Alexander
7 Gestionar Almacén Normal Pendiente 6 Nicolás
8 Gestionar Normal Pendiente 6 Nicolás
Proveedor
9 Gestionar Empresa Alta Pendiente 4 Nicolás
10 Gestionar Tipo de Alta Pendiente 4 Nicolás
Empresa
11 Gestionar Producto Baja Pendiente 8 Nicolás
12 Gestionar Alta Pendiente 4 Nicolás
Categoría
13 Gestionar Alta Pendiente 4 Nicolás
Subcategoria
14 Gestionar Alta Pendiente 4 Nicolás
Descuento
15 Gestionar Venta Baja Pendiente 8 Erasmo
16 Gestionar Estado Alta Pendiente 4 Erasmo
17 Gestionar Pago Alta Pendiente 4 Erasmo
18 Gestionar Baja Pendiente 8 Maguin
Promociones de
Descuento
19 Gestionar Baja Pendiente 8 Alex
Promociones por
Puntos
20 Gestionar Venta Alta Pendiente 4 Erasmo
Mayor
21 Gestionar Moneda Alta Pendiente 4 Erasmo

55
4.11.2. Scrum Taskboard

Stories To Do On Progress Done

• Gestionar Usuario
• Gestionar Privilegios
• Gestionar Acciones
• Gestionar Perfil
• Gestionar Rank de
Comprador
• Gestionar Mensajes
• Gestionar Almacén
• Gestionar Proveedor
• Gestionar Empresa
• Gestionar Tipo de
Empresa
• Gestionar Producto
• Gestionar Categoría
• Gestionar
Subcategoria
• Gestionar Descuento
• Gestionar Venta
• Gestionar Estado
• Gestionar Pago
• Gestionar
Promociones de
Descuento
• Gestionar
Promociones por
Puntos
• Gestionar Venta
Mayor
• Gestionar Moneda

56