You are on page 1of 43

Grupo

16

Facultad de Ingeniería
en Ciencias de la
Computación y
Telecomunicaciones

Sistema de Información

INTEGRANTES: Cardona Chávez Alex


Hurtado Gutiérrez Erasmo C.

MATERIA: SISTEMAS DE INFORMACIÓN II

INF 412 – SA

DOCENTE: Ing. Angélica Garzón Cuellar


INDICE
1.1. INTRODUCCIÓN .................................................................................................................................... 3
1.2. OBJETIVOS .......................................................................................................................................... 4
1.2.1. Objetivo General ......................................................................................................................... 4
1.2.2. Objetivos Específicos ................................................................................................................. 4
1.3 DESCRIPCIÓN DEL PROBLEMA ................................................................................................................ 5
1.4. ALCANCE ............................................................................................................................................ 7
2. MARCO TEORICO METODOLOGÍA ÁGIL ................................................................................ 12
2.1. PROPÓSITO DE SCRUM....................................................................................................................... 12
2.2. VISIÓN GENERAL DE SCRUM ............................................................................................................... 15
2.3. EL EQUIPO DE SCRUM (SCRUM TEAM) ................................................................................................ 16
2.4. EL DUEÑO DE PRODUCTO (PRODUCT OWNER) .................................................................................... 16
2.5. EL EQUIPO DE DESARROLLO (DEVELOPMENT TEAM)............................................................................ 17
2.6. EL SCRUM MASTER ............................................................................................................................ 19
2.7. EVENTOS DE SCRUM .......................................................................................................................... 20
2.8. EL SPRINT ......................................................................................................................................... 20
2.9. REUNIÓN DE PLANIFICACIÓN DE SPRINT (SPRINT PLANNING MEETING) ................................................. 20
2.10. OBJETIVO DEL SPRINT (SPRINT GOAL) .............................................................................................. 22
2.11. SCRUM DIARIO (DAILY SCRUM) ......................................................................................................... 22
2.12. REVISIÓN DE SPRINT (SPRINT REVIEW) ............................................................................................. 23
2.13. RETROSPECTIVA DE SPRINT (SPRINT RETROSPECTIVE) ..................................................................... 25
2.14. ARTEFACTOS DE SCRUM .................................................................................................................. 26
2.15. LISTA DE PRODUCTOS (PRODUCT BACKLOG) ..................................................................................... 29
2.16. LISTA DE PENDIENTES DEL SPRINT (SPRINT BACKLOG) ...................................................................... 30
2.17. INCREMENTO ................................................................................................................................... 30
2.18. TRANSPARENCIA DE LOS ARTEFACTOS .............................................................................................. 31
2.19. DEFINICIÓN DE “TERMINADO” ............................................................................................................ 32
2.20. VENTAJAS Y DESVENTAJAS ............................................................................................................... 33
2.20.1. Ventajas .................................................................................................................................. 33
2.20.2. Desventajas ............................................................................................................................ 33
2.21. VALORES DE TRABAJO ..................................................................................................................... 34
2.22. HERRAMIENTAS DE TRABAJO............................................................................................................. 35
3. PERSONAS Y ROLES DEL PROYECTO ...................................................................................... 37
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.

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.
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.

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.

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)

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)

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.

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.

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

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.

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.

 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.

 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.

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; y,

 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.
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; y,

 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. 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.

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.

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.

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.

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.

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.

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.

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

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.

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 ítem, 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 items 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.

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.

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 item 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.

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 costeestimado 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).

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 autoasignació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
entregada al cliente.
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.

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).

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.

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.
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. 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.
3. PERSONAS Y ROLES DEL PROYECTO

ROL ENCARGADO TAREAS

PRODUCT OWNER Cardona Chavez Alex Coordinar con el cliente y el equipo.

Gestionar la pila del producto


(Product Backlog).

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


procesos.

Garantizar el cumplimiento de roles


y responsabilidades.

Mejorar el trabajo en equipo.

TEAM Avisa Mamani Alexander Transformar la pila del sprint


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

You might also like