Caracas, 10 de Marzo de 2018

TALLER METODOLOGÍA AGIL, SCRUM

Objetivo del Taller: Al finalizar el taller los participantes estarán en capacidad de aplicar
la metodología Scrum como herramienta de soporte para el desarrollo de productos
(software) que apoyen las estrategias de CoinSpree en los distintos niveles
organizacionales.

FUNDAMENTOS TEÓRICOS
 Scrum (rugby)

Es una formación ordenada de los jugadores de futbol americano, utilizada para reiniciar
el juego. Es una puja frente a frente, un grupo de cada equipo se enfrenta agazapado y
agarrado entre sí. La pelota es lanzada en el scrum y los jugadores empiezan a empujar
con el fin de obtener el balón que ha sido lanzado en medio de ellos para poder patear
hacia atrás, hacia su propio lado.

 Origen de Scrum

Fue definido en 1986 por Hirotaka Takeuchi y Ikujiro Nonaka como un nuevo marco de
desarrollo de productos como “una estrategia de desarrollo de producto flexible y
holístico, donde un equipo de desarrollo trabaja como una unidad para alcanzar un
objetivo común, como oposición al enfoque tradicional donde se establece el desarrollo
como una secuencia de fases “independientes” entre ellas”.

Los autores describen Scrum como una nueva aproximación al desarrollo de producto
que incrementaría la velocidad y flexibilidad. Para llevar a buen término este proceso
este debería ser llevado a cabo por un equipo multifuncional a lo largo de todas las fases,
en lugar del enfoque más tradicional que sugiere especialistas por cada una de las fases
(analista funcional, orgánico, tester, etc.).

 Definición de Scrum

Un marco de trabajo por el cual las personas pueden abordar problemas complejos
adaptativos, a la vez que entregar productos del máximo valor posible productiva y
creativamente.
 Características de Scrum:

 Liviano
 Fácil de entender
 Difícil de llegar a dominar

 Principal ventaja de Scrum

Podemos obtener productos operativos (funciones básicas) a corto plazo y gradualmente

vamos incorporando nuevas funcionalidades, para perfeccionar el producto final que
deseamos.

MANIFIESTO SCRUM
Son los 12 principios ágiles en los que se basa Scrum:

1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua

de software con valor.

2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los
procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
3. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con
preferencia al periodo de tiempo más corto posible.

4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana

durante todo el proyecto.

5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno
y el apoyo que necesitan, y confiarles la ejecución del trabajo.

6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre

sus miembros es la conversación cara a cara.

7. El software funcionando es la medida principal de progreso.

8. Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y

usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.

9. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.

10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.

11. Las mejores arquitecturas, requisitos y diseños emergen de equipos autoorganizados.

12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a
continuación ajustar y perfeccionar su comportamiento en consecuencia.

EQUIPO SCRUM
En el equipo Scrum se identifican los siguientes roles
principales: Product Owner, Scrum Master y
Development Team.

-Product Owner (dueño del producto): representa

la voz del cliente y del resto de interesados no
implicados directamente en el proyecto. Este perfil es
el encargado de definir los objetivos del proyecto y
de garantizar que el equipo trabaja del modo
adecuado para alcanzar dichos objetivos. Asegura la
visión del proyecto y maximiza el valor del producto.

-Scrum Master (facilitador): Aseguran el Proceso y

maximiza el uso de Scrum.
 -Development Team (desarrolladores): es el equipo encargado de desarrollar y entregar
el producto. Su trabajo es imprescindible, su estructura horizontal auto-organizada capaz de
auto-gestionarse a sí misma. Asegura el producto y maximiza la entrega del producto

Entre otros roles con los que deben interactuar se tienen:

-Stakeholders (parte interesada): en el ámbito empresarial, significa parte interesada, y se
refiere a todas aquellas personas u organizaciones afectadas por las actividades y las
decisiones de una empresa. Comprende aquellos perfiles interesados en el producto:
directores, dueños, comerciales.

-Business Owner (dueño del negocio): El dueño del negocio busca el mejor interés de la
compañía, que al final es el mismo objetivo del dueño del producto, sin embargo, la mayoría
del tiempo buscará lograr una línea de tiempo agresiva y reducir el número de revisiones
por producto.

FASES DE SCRUM
a. Lista de productos - Product BackLog
Se trata de un archivo genérico que recoge el conjunto de tareas, los requerimientos y las
funcionalidades requeridas por el proyecto. Cualquier miembro del equipo puede modificar este
documento pero el único con autoridad para agregar prioridades es el Product Owner,
responsable del documento.

b. Refinamiento
De la guía de Scrum se indica que: “El refinamiento (refinement) de la Lista de Producto es el
acto de añadir detalle, estimaciones y orden a los elementos de la Lista de Producto. Se trata de
un proceso continuo en el cual el Dueño de Producto y el Equipo de Desarrollo colaboran acerca
de los detalles de los elementos de la Lista de Producto. Durante el refinamiento de la Lista de
Producto, se examinan y revisan sus elementos. El Equipo Scrum decide cómo y cuándo se hace
el refinamiento. Este usualmente consume no más del 10% de la capacidad del Equipo de
Desarrollo.

c. Sprint: El corazón de Scrum es el Sprint, es un bloque de tiempo de entre una semana y un

mes durante el cual se crea un incremento de producto “Terminado” utilizable y potencialmente
desplegable, es decir, que se pudiera utilizar por parte de los usuarios y clientes. Es más
conveniente si la duración de los Sprints es fija a lo largo del tiempo. De esta manera se
conseguirá ritmo sostenido. Cada nuevo Sprint comienza inmediatamente después de la
finalización del Sprint Anterior.

d. Reunión de planificación - Sprint planning

Tiene una duración de 8 horas para sprints de un mes. Para sprints más cortos la duración es
severamente más corta. El objetivo de la reunión es el de planificar la cantidad de trabajo a la
que el equipo se va a comprometer a construir durante el próximo sprint. La reunión de
planificación responde a dos preguntas: ¿Qué puede entregarse en el incremento de Sprint que
comienza?, ¿Cómo se conseguirá realizar el trabajo necesario para entregar el incremento?
e. Reunión diaria – Daily Scrum meeting
Tiene como objetivo la comunicación entre los miembros del equipo resulta fundamental, por
eso, para conseguir que esta no se pierda y el equipo pueda sincronizarse en su trabajo diario
existe esta reunión diaria o daily stand-up en inglés. El objetivo es que el equipo establezca un
plan para las próximas 24 horas. Debe realizarse en el mismo lugar y a la misma hora. Todos
los miembros del equipo comentan lo que hicieron el día anterior, lo que van a hacer hoy y si
tienen algún impedimento o dependencia de algún tipo para conseguirlo. Es una reunión rápida,
de apenas 15 minutos por lo que se suele realizar de pie y en frente del tablero de tareas.

f. Retrospectiva - Retrospective
El objetivo de esta reunión es el de inspeccionar como ha estado el Equipo Scrum y cada una
de las personas que lo componen. En la reunión se analizan mediante diferentes técnicas que
se hizo bien y que se puede hacer diferente para el próximo sprint. El objetivo es que el equipo
reflexione y saque como resultado posibles acciones de mejora. Debe asistir todo el Equipo
Scrum (Dueño de Producto, Equipo de Desarrollo y Scrum Master). Es una de las reuniones
más importantes ya que es un espacio de reflexión y mejora continua.

g. Revisión - Review
En la guía oficial de Scrum se indica: “Al final del Sprint se lleva a cabo una Revisión de Sprint
para inspeccionar el Incremento y adaptar la Lista de Producto si fuese necesario. Durante la
Revisión de Sprint, el Equipo Scrum y los interesados colaboran acerca de lo que se hizo durante
el Sprint. Basándose en esto y en cualquier cambio a la Lista de Producto durante el Sprint, los
asistentes colaboran para determinar las siguientes cosas que podrían hacerse para optimizar
el valor. Sin embargo, los elementos de la Lista de Producto pueden actualizarse en cualquier
momento por el Dueño de Producto o a criterio suyo.”

ÉPICA E HISTORIA DE USUARIO

 Una épica refleja una idea abstracta de lo que se quiere obtener y está
conformado por historias de usuarios. Es una descripción amplia de un requisito.

 Una historia de usuario es una representación de un requisito (funcional o no

funcional) escrito en una o dos frases utilizando el lenguaje común del usuario.

REQUISITOS FUNCIONALES Y NO FUNCIONALES

 Requisito Funcional: función del sistema de software o sus componentes, tales
como: ejecución de cálculos, detalles técnicos, manipulación de datos y otras
funcionalidades específicas.

 Requisito no funcional: los referidos a atributos de calidad, tales como: la

eficiencia, seguridad, usabilidad del sistema, entre otros.
EJEMPLOS DE CÓMO SE PUEDEN SUBDIVIDIR LAS ÉPICAS EN
HISTORIAS

Ejemplo 1: Reportes de desempeño de ventas

Como Vicepresidente de mercadeo y ventas, quiero revisar el desempeño histórico de
las ventas, para poder identificar las regiones geográficas y productos de mejor
desempeño
Esta épica se puede subdividir en:
 Como VP de Mercadeo, quiero seleccionar el período de tiempo en el cual
realizaré la revisión de las ventas.
 Como VP de Mercadeo, puedo clasificar la información de ventas por región
geográfica y productos.

Ejemplo 2: Maximizar los ingresos de un hotel

Como un operador hotelero, quiero establecer las tarifas óptimas para las habitaciones
de mi hotel.
Esta épica se puede subdividir en:
 Como un operador hotelero, quiero establecer la tarifa óptima para las
habitaciones en base a los precios del año anterior.
 Como un operador hotelero, quiero establecer la tarifa óptima para las
habitaciones en base a las tarifas de otros hoteles comparables con el mío.

EJEMPLO DE HISTORIAS DE USUARIOS

Ejemplo 1: Autogestión de T.V. por suscripción
 Como Cliente, quiero suscribirme a un nuevo plan de T.V. por cable por medio del
sitio web.
 Como Cliente, quiero pagar mi suscripción mensual vía sitio web por medio de
transferencia bancaria o tarjeta de crédito.
 Como Cliente, quiero suscribirme a un canal de T.V Premium por períodos
flexibles de tiempo por medio del sitio web.
 Como Cliente, quiero consultar un listado de las suscripciones de Pay per View
que se han realizado en mi cuenta.

Ejemplo 2: Sistema de ventas y distribución

 Como Vendedor, quiero registrar los productos y cantidades que me solicita un
cliente para crear un pedido de venta.
 Como Supervisor de ventas, quiero consultar un listado de los pedidos de venta
que han sido registrados y aún no han sido procesados.
  Como Gerente de ventas, quiero consultar los pedidos de venta procesados
clasificándolos por vendedor, región y líneas de producto.
 Como Analista de logística, quiero seleccionar un pedido de venta y enviarlo al
almacén para que procedan con su preparación.
 Como Analista de almacén, quiero listar todos los pedidos de venta recibidos que
debo preparar.
 Como Analista de logística, quiero poder consultar todos los pedidos preparados
listos para ser despachados.
 Como Analista de logística, quiero que el sistema me sugiera la ruta más corta en
base a una serie de despachos de mercancía y un transporte.

Ejemplo 3: Sistema de compras

 Como Analista de compras, quiero crear una nueva solicitud de cotización.
 Como Analista de compras, quiero definir si una solicitud de cotización es de
adjudicación directa o de licitación.
 Como Gerente de compras, quiero que el sistema requiera de mi aprobación para
toda solicitud de cotización de adjudicación directa con monto mayor a USD 5.000.
 Como Analista de compras, quiero que el sistema notifique vía correo electrónico
a los proveedores cuando se ha enviado una cotización de licitación.
 Como Representante de proveedor, quiero poder consultar los procesos de
licitación que están en curso.
 Como Representante de proveedor, quiero ofertar una cotización para un proceso
que esté abierto por licitación.

SCRUM BOARD
La Scrum Board o pizarra Scrum es uno de los elementos más importantes en
SCRUM ya que sirve como punto de unión entre todos los integrantes del grupo de
trabajo y el Product Owner y es donde el Scrum Master va representando diariamente
el estado del flujo de trabajo del Sprint en curso. Las reuniones diarias deberían hacerse
frente a la Scrum Board y, si es posible, el resto de reuniones también.