CURSO DE AGILE EN

DATA Y ANALYTICS

1
1. ¿POR QUÉ LOS PROYECTOS Y TAREAS DE
ANALYTICS NECESITAN METODOLOGÍAS
ÁGILES?
Escenario actual
Los métodos de innovación de la empresa han revolucionado
la tecnología de la información.
En los últimos 25 o 30 años han aumentado enormemente las
tasas de éxito en el desarrollo de software han mejorado la
calidad y la velocidad y han aumentado la motivación y la
productividad de los equipos informáticos.

Ahora las metodologías ágiles - que implican nuevos valores,

principios, prácticas, etc. son una alternativa radical al estilo de
gestión de mando y control y se están extendiendo por una
amplia gama de sectores y funciones.

2
1. ¿POR QUÉ LOS PROYECTOS Y TAREAS DE
ANALYTICS NECESITAN METODOLOGÍAS
ÁGILES?
Escenario actual
Esta es la teoría, pero…

¿Cómo es en la práctica?
- Desorganización
- Conflictos
- Ineficiencias
- Burocracia
- Retrasos
- Frustracción…

3
1. ¿POR QUÉ LOS PROYECTOS Y TAREAS DE
ANALYTICS NECESITAN METODOLOGÍAS
ÁGILES?
Escenario actual
Tradicionalmente, este enfoque se ha aplicado más a
proyectos en los que el componente de 'desarrollo' tiene un
peso muy importante y se hace muy difícil aplicarlo al BI/DW,
donde los requisitos, el manejo de datos de negocio y la
participación de perfiles de interlocutores muy diversos lo
hace muy difícil.

Cuál es el enfoque tradicional de planificación en BI/DW:

- La planificación de proyectos en cascada (con diagramas de
Gantt) que todos conocéis (lleva usándose más de 70 años) se
ha demostrado imperfecto a la hora de conseguir que un
proyecto BI sea exitoso.

¿Qué quiere decir 'un proyecto BI exitoso’? Quiere decir 'que

se use' por la mayor parte de la organización y es porque les
ofrece 'lo que necesitan’.

- Los diferentes planteamientos teóricos de construcción

(Kimball, Inmon, Data Vault...) se han demostrado muy útiles
para reflejar el diagrama de modelos y almacenes de datos,
pero la ejecución en el día a día, nos ha demostrado que se
requieren enfoques ágiles para llevarlos a la práctica.

4
1. ¿POR QUÉ LOS PROYECTOS Y TAREAS DE
ANALYTICS NECESITAN METODOLOGÍAS
ÁGILES?

Diccionario de Arquitecturas de Datos 5

2. IDENTIFIQUEMOS TODO AQUELLO QUE
SE PUEDE MEJORAR

a. Análisis de riesgos e impactos

Cuando usamos un método de planificación ‘tradicional’, los
problemas surgen pues 'Cómo se había hecho una planificación',
'con muchos meses por delante', cuando surge un problema de
arquitectura, de volumen, cambio de requerimientos, mejoras de
software... el encaje y respuesta rápida se hace imposible.

Al ser proyectos con un alcance ya cerrado y difícil de cambiar,

'proyectos caja negra', los usuarios e interesados en el proyecto
no lo sienten como suyo generando reticencias sobre su uso, al no
sentirse partícipes pues sus propuestas y sugerencias, 'suelen
llegar tarde’.

6
2. IDENTIFIQUEMOS TODO AQUELLO QUE
SE PUEDE MEJORAR

b. Comunicación vertical
El equipo no se siente implicado desde el momento inicial y
no sienten que sus opiniones cuentan.

La tradicional batalla entre usuarios-IT-Consultores, por sus

diferentes prioridades, se agudiza al no colaborar desde
momentos muy tempranos y con la tranquilidad de que
'hay tiempo para corregir errores’.

En este tipo de proyectos, encontrar un 'product owner' es

complicado, pero lo tenéis que hacer. Debe ser de negocio.

Solventad cuanto antes los puntos de fricción 'top-down',

'down-top', desde la importancia de la calidad del dato, los
procesos ETL y los metadatos a los análisis de negocio en
tiempo real, KPIs, etc... (en el punto intermedio, todos los
participantes deberán alinearse).

Necesitas un Project Manager (el que está al tanto de

todo, conoce a todos, convoca y resume las reuniones,
etc...). Necesitas una cabeza visible y clara que todos
'identifiquen con el proyecto’.

7
A. CÓMO SELECCIONAR LA TECNOLOGÍA
ADECUADA

Escenario actual

▪ Las personas de la organización no están actualizadas

en conocimiento de las últimas Tecnologías.

▪ ¿Soluciones propietarias u Open Source? ¿Cómo

conocer los precios reales?

▪ Almacenamiento relacional, columnar, Big Data,

Híbrido, Cloud…?

▪ ¿Qué tecnologías y herramientas pueden formar parte

del mismo stack?

▪ Criterios ‘objetivos’ de evaluación y selección de

herramientas.

▪ Cómo conocer experiencias en organizaciones similares

de uso de cada tecnología.

▪ Business Intelligence, Big Data, Machine Learning, AI..?

8
B. CÓMO FORMAR AL PERSONAL (TÉCNICOS Y DE
NEGOCIO)

Escenario actual

▪ El equipo se ha quedado obsoleto con las tecnologías

recientes.

▪ Temor a formaciones poco prácticas y poco orientadas a

resultados medibles.

▪ No se quiere implicar a los usuarios de negocio en las

formaciones.

▪ Formaciones no basadas en datos reales de la compañía ni

casos propios.

▪ No hay apoyo y soporte periódico tras la formación (cuando

se ponen los conocimientos en práctica).

9
C. PODER CREAR SOLUCIONES QUE SEAN ÚTILES
AL NEGOCIO (360º)

Escenario actual

▪ Business Intelligence, Machine Learning, Big Data… son

iniciativas que no se orientan a negocio.

▪ Negocio no le ve valor para: vender más, ahorro de costes,

mejora medible de competitividad o productividad…

▪ Frustración y rivalidad entre IT y Negocio al no invertir y crear

soluciones ´útiles’ para la compañía.

▪ Se usa lenguaje exclusivamente técnico en las reuniones. No

se centran en KPIs de negocio.

▪ Analytics se considera un fin en sÍ mismo y no un medio para

mejorar la rentabilidad de la compañía.

10
D. PODER TESTEAR APLICACIONES Y DEMOS
REALES DE CADA TECNOLOGÍA

Escenario actual

▪ Se recibe la información de las herramientas y

tecnologías a través del ‘comercial de toda la vida’.

▪ Webs y papers comerciales que nadie se lee ni

entiende.

▪ Para las demos de producto se pide un contacto

comercial previo.

▪ Muchas demos apenas funcionan y están

desactualizadas.

▪ No explican el funcionamiento y características de

administración.

▪ No permiten testearla con datos propios de la

compañía.

▪ Machine Learning y Big Data son tecnologías

complicadas para crear demos.

11
E. NO CONOCER LO QUE HACEN LAS
ORGANIZACIONES DEL MISMO SECTOR

Escenario actual

▪ Desconocimiento de las soluciones, tecnologías, KPIs y

procesos que usan organizaciones del mismo sector.

▪ Se aborda desde cero proyectos, al no conocer ‘buenas

prácticas’ y ‘errores frecuentes’.

▪ Se desconoce que existen datos abiertos e información de

asociaciones del sector que se pueden utilizar.

▪ Se vive en una ‘isla tecnológica’, con el riesgo de ser menos

eficientes que las organizaciones del sector.

12
F. NO TENER SOPORTE Y ACOMPAÑAMIENTO DE
EMPRESAS DE GARANTÍA

Escenario actual

▪ Cuando surgen problemas con las herramientas y

tecnologías no se sabe a quién acudir.

▪ Internamente no se tienen los skills suficientes para

abordarlo.

▪ Se paralizan iniciativas cuando hay puntas de trabajo,

bajas, vacaciones, nuevas prioridades, etc…

▪ Se solicitan trabajos y soporte ‘adhoc’ a compañías

generalistas que no solventan los problemas.

▪ Inseguridad a la hora de afrontar retos y nuevas

soluciones a largo plazo.

13
G. NO ESTAR ACTUALIZADO CON PAPERS,
TUTORIALES Y NOTICIAS

Escenario actual

▪ Cómo distinguir papers ‘comerciales’ de análisis objetivos e

independientes.

▪ Demasiada ‘infoxicación’ con noticas sobre tecnologías, que

no aportan claridad.

▪ Tantos eventos, meetups, seminarios y poco tiempo para

acudir.

▪ Falta de tutoriales (actualizados, de calidad, en formato

video…) suficientemente completos.

▪ Las personas de la organización que leen papers, van a

meetups, realizan webinars… no son los que deberían.

14
H. NO SE CREAN PROTOTIPOS Y PILOTOS CON
DATOS PROPIOS REALES

Escenario actual

▪ Antes de abordar una nueva iniciativa con datos no

siempre se crean pilotos previous.

▪ Cuando se realizan, no incluyen datos reales y no son

de mucha utilidad.

▪ Cuando se realizan, sólo se hacen de una de las

tecnologías identificadas y no de varias a evaluar.

▪ Los pilotos no involucran a los usuarios finales y son

meros ‘escaparates’ de funcionalidades.

▪ Una vez comenzados los proyectos, no se crean pilotos o

desarrollos previos de forma ágil hasta muy avanzando
el proyecto.

15
I. NO SE MIDE EL ROI EN LOS PROYECTOS DE
DATOS

Escenario actual

▪ Incertidumbre sobre el resultado de los proyectos e

iniciativas en los proyectos de datos.

▪ No se mide el ROI de los mismos.

▪ Difícil de conocer y evaluar el ‘éxito o fracaso’ de un

proyecto.

▪ No se ‘aprende’ de cara a abordar nuevas soluciones,

proyectos, evolutivos, etc. similares.

▪ Frustración de los equipos al desconocer el valor,

resultado y rentabilidad de su trabajo y esfuerzo.

▪ Se establece un ROI de ‘forma manual’, sin ningún criterio

metodológico o matemático.

16
3. DEFINICIÓN DE ACTORES E HISTORIAS

▪ Piensa en silencio de manera individual ¿Qué es para

ti la agilidad?

▪ Escribe en un post-it qué te sugiere la agilidad.

▪ Comparte tus respuestas con las de tus compañeros.

17
3. DEFINICIÓN DE ACTORES E HISTORIAS

MVP: 3 MESES
▪ Definición del alcance previo bien definido. Análisis de
requerimientos. Historias de Usuarios (Épicas), Product
Backlog…

▪ Reunión de arranque con usuarios, developers, Product

Owner y Scrum Master.

▪ Desarrollo ágil (reuniones diarias (¿?), semanales..).

▪ Presentación de resultados, siempre positivos, mejor

postponer si negativos.

▪ Revisión Backlog y nuevo alcance para nueva iteración.

▪ Fijación de prioridades y disponibilidad de equipos.

1ª ITERACIÓN: 1 MES

▪ Nuevos requerimientos, correctivos, errores, evolutivos,

SLAs…

…N ITERACIÓN: 1 MES

18
3. DEFINICIÓN DE ACTORES E HISTORIAS

PUNTOS CLAVE

▪ Alcance

▪ Roles

▪ Prioridades

▪ Documentación

▪ Producto/Proyecto entregado (No servicio,

ni soporte)

19
3. DEFINICIÓN DE ACTORES E HISTORIAS

¿Qué es el MANIFIESTO ÁGIL?

El Manifiesto Ágil es un documento redactado en

2001 por 17 expertos en programación que
supuso un cambio radical en la forma de
desarrollar software.

Estos gurús propusieron 4 valores y 12 principios

que inspiran las diferentes metodologías ágiles
que han surgido desde entonces.

20
3. DEFINICIÓN DE ACTORES E HISTORIAS

21
3. DEFINICIÓN DE ACTORES E HISTORIAS

22
4. PRIORIZACIÓN Y DEPENDENCIAS

Agile se aplica en entornos de alta

incertidumbre y cambiantes

23
4. PRIORIZACIÓN Y DEPENDENCIAS

24
4. PRIORIZACIÓN Y DEPENDENCIAS

25
5. CONSTRUCCIÓN DEL PRODUCT/PROJECT
BACKLOG

Simplicidad.

Construyamos el mínimo producto viable:

▪ Anticipar valor

▪ Reducir complejidad y riesgo

▪ Fallar barato

26
5. CONSTRUCCIÓN DEL PRODUCT/PROJECT
BACKLOG

Simplicidad.

27
6. SCRUM, KANBAN Y OTRAS
METODOLOGÍAS AGILES

28
6. SCRUM, KANBAN Y OTRAS
METODOLOGÍAS AGILES

Scrum es un marco de trabajo ágil que ayuda a personas, equipos

y organizaciones a generar valor a través de soluciones adaptables
para problemas complejos.

Scrum se basa en el empirismo y el pensamiento lean. El

empirismo sostiene que el conocimiento proviene de la
experiencia y la toma de decisiones basada en lo observado. El
pensamiento lean reduce el desperdicio y se enfoca en lo esencial.
Scrum emplea un enfoque iterativo e incremental para optimizar
la predictibilidad y controlar el riesgo.

Scrum involucra a grupos de personas que, colectivamente, tienen

todas las habilidades y experiencia necesarias para realizar el
trabajo y comparten o adquieren esas habilidades según sea
necesario. defined in the Scrum Guide

Transparency Inspection Adaptation

The emergent process and work must be The Scrum artifacts and the progress If any aspects of a process deviate outside
visible to those performing the work as well toward agreed goals must be inspected acceptable limits or if the resulting product
as those receiving the work. With Scrum, frequently and diligently to detect is unacceptable, the process being applied
important decisions are based on the potentially undesirable variances or or the materials being produced must be
perceived state of its three formal artifacts. problems. adjusted. The adjustment must be made
as soon as possible to minimize further
Transparency enables inspection. deviation.
Inspection without transparency is Inspection enables adaptation. Inspection
misleading and wasteful. without adaptation is considered
pointless.

29
6. SCRUM, KANBAN Y OTRAS
METODOLOGÍAS AGILES

Scrum se basa en 5 valores, 3 roles, 5 eventos y 3

artefactos.

30
6. SCRUM, KANBAN Y OTRAS METODOLOGÍAS
AGILES

31
6. SCRUM, KANBAN Y OTRAS
METODOLOGÍAS AGILES

El Product Owner es responsable de maximizar el valor del producto resultante del

trabajo del Equipo Scrum. Cómo se logra esto puede variar ampliamente entre
organizaciones, Equipos Scrum y personas.
El Product Owner también es responsable de la gestión efectiva del Backlog del
Producto, lo cual incluye:

▪ Desarrollar y comunicar explícitamente el Objetivo del Producto.

▪ Crear y comunicar claramente los elementos del Backlog del Producto.
▪ Ordenar los elementos del Backlog del Producto.
▪ Asegurarse de que el Backlog del Producto sea transparente, visible y
comprendido.
Los desarrolladores son las personas en el Equipo Scrum que se comprometen a
crear cualquier aspecto de un Incremento utilizable en cada Sprint.
Las habilidades específicas necesarias para los desarrolladores suelen ser amplias y
variarán según el dominio de trabajo. Sin embargo, los desarrolladores siempre son
responsables de:

▪ Crear un plan para la Sprint, el Backlog de la Sprint.

▪ Infundir calidad al adherirse a una Definición de Terminado.
▪ Adaptar su plan cada día hacia el Objetivo de la Sprint.
▪ Responsabilizarse mutuamente como profesionales.

El Scrum Master es responsable de establecer Scrum tal como se define en la Guía de

Scrum. Lo hace ayudando a todos a comprender la teoría y la práctica de Scrum,
tanto dentro del Equipo Scrum como en la organización.

El Scrum Master es responsable de la efectividad del Equipo Scrum. Esto lo logra

permitiendo al Equipo Scrum mejorar sus prácticas dentro del marco de Scrum.

Los Scrum Masters son verdaderos líderes que sirven al Equipo Scrum y a la
organización en su conjunto.

32
6. SCRUM, KANBAN Y OTRAS
METODOLOGÍAS AGILES

The Sprint
Los Sprints son el latido de Scrum, donde las ideas se convierten en valor. Son
eventos de duración fija de un mes o menos para crear consistencia. Una nueva
Sprint comienza inmediatamente después de la conclusión de la Sprint anterior. Todo
el trabajo necesario para lograr el Objetivo del Producto, incluyendo la Planificación
de la Sprint, las Daily Scrums, la Revisión de la Sprint y la Retrospectiva de la Sprint,
ocurre dentro de las Sprints.

Sprint Planning
La Planificación del Sprint inicia el Sprint al establecer el trabajo que se realizará
durante la Sprint. Este plan resultante se crea a través del trabajo colaborativo de
todo el Equipo Scrum.

Daily Scrum
El propósito del Daily Scrum es inspeccionar el progreso hacia el Objetivo de la Sprint
y adaptar el Backlog de la Sprint según sea necesario, ajustando el trabajo planeado
próximo. El Daily Scrum es un evento de 15 minutos para los Desarrolladores del
Equipo Scrum.

Sprint Review
El propósito de la Revisión del Sprint es inspeccionar el resultado de la Sprint y
determinar las adaptaciones futuras. El Equipo Scrum presenta los resultados de su
trabajo a las partes interesadas clave y se discute el progreso hacia el Objetivo del
Producto.

Sprint Retrospective
El propósito de la Retrospectiva del Sprint es planificar formas de aumentar la
calidad y la efectividad. El Equipo Scrum inspecciona cómo transcurrió la última
Sprint en lo que respecta a individuos, interacciones, procesos, herramientas y su
Definición de Terminado. Los elementos inspeccionados a menudo varían según el
ámbito de trabajo.

33
6. SCRUM, KANBAN Y OTRAS
METODOLOGÍAS AGILES

Product Backlog

The Product Backlog is an emergent, ordered

list of what is needed to improve the product.
It is the single source of work undertaken by
the Scrum Team.

Sprint Backlog

The Sprint Backlog is composed of the Sprint

Goal (why), the set of Product Backlog items
selected for the Sprint (what), as well as an
actionable plan for delivering the Increment
(how).

Increment

An Increment is a concrete stepping

stone toward the Product Goal. Each
Increment is additive to all prior
Increments and thoroughly verified,
ensuring that all Increments work
together. In order to provide value, the
Increment must be usable.
34
6. SCRUM, KANBAN Y OTRAS
METODOLOGÍAS AGILES

Kanban es un método lean para gestionar y mejorar el trabajo en sistemas

humanos. Este enfoque tiene como objetivo gestionar el trabajo
equilibrando las demandas con la capacidad disponible y mejorando la
gestión de cuellos de botella a nivel del sistema.

Conceptos clave de Kanban:

▪ Flujo de trabajo: Todos los pasos que deben realizarse, desde una solicitud
hasta su implementación y disponibilidad para el cliente.

▪ Tablero Kanban: Un tablero que representa el flujo de trabajo con

columnas delimitadas para cada paso.

▪ Sistema de arrastre (Pull system): En oposición al sistema de empuje

clásico, Kanban utiliza un enfoque en el que el "arrastre" proviene de la
demanda y los productos se fabrican a medida que se solicitan.

▪ Límites de trabajo en progreso (WIP Limits): Límites establecidos en pasos

específicos del flujo de trabajo para evitar un exceso de trabajo concurrente
y forzar un sistema de arrastre.

▪ Tiempo de ejecución (Lead Time): El tiempo promedio que se tarda en

completar una tarea, calculado desde que el equipo recibe una solicitud del
cliente.

▪ Tiempo de ciclo (Cycle Time): El tiempo promedio que se tarda en

completar una tarea, calculado desde que el equipo comienza a trabajar en
una tarea.

35
6. SCRUM, KANBAN Y OTRAS
METODOLOGÍAS AGILES

36
6. GLOSARIO

37
7. HERRAMIENTAS A USAR EN AGILE
ANALYTICS

38
8. PRÁCTICA DIARIA (LA TEORÍA DE LA
VENTANA ROTA)
“Si una ventana rota no se arregla pronto, inmediatamente
todas acabarán siendo destrozadas”

Durante la década de los 60, en Estados Unidos, el psicólogo Philip Zimbardo

realizó una serie de experimentos sociales concluyendo que la percepción de
desorden y el crimen suelen estar vinculados, siendo el último un producto
del desarrollo libre del primero. Fruto de estos experimentos nace la Teoría de
las ventanas rotas, que postula que, si una ventana de un edificio se rompe y
no se repara, el resto de las ventanas del edificio pronto se romperán, dando
esta sensación de desorden, que da lugar a la comisión de delitos. En cambio,
un mayor cuidado y mantenimiento del entorno urbano, por lo general,
disminuye el vandalismo y la criminalidad.
En una organización ocurre lo mismo. Por ello, es importante que la función de
Agilidad trabaje la percepción del control buscando producir una sensación de
orden y de tolerancia cero con las infracciones por insignificantes que estas
sean.

39
9. CÓMO MEDIR Y ACTUAR SOBRE:

A. WORK IN PROGRESS

DevOps es un conjunto de prácticas que combina el desarrollo

de software (Dev) y las operaciones de tecnología de la
información (Ops). Su objetivo es acortar el ciclo de vida del
desarrollo de sistemas y proporcionar entrega continua con
alta calidad de software. DevOps es complementario con el
desarrollo de software ágil; varios aspectos de DevOps
provienen de la metodología ágil.

40
9. CÓMO MEDIR Y ACTUAR SOBRE:

B. ESTIMACIONES
Las Leyes de la estimación:

1. Ley de Parkinson: el trabajo se expande hasta agotar el tiempo

disponible (si estimamos más tiempo del necesario... se
consumirá en la tarea más tiempo del necesario. Si estamos un
mes y medio en algo que podría hacerse en un mes, se tardará
un mes y medio)

2. Ley de la Deuda Técnica: Si lo haces mal, lo harás más rápido, sí,

pero… generas Deuda Técnica.

3. Ley del Error: toda estimación tiene un error.

4. Ley de la precisión: la precisión de la estimación aumenta según

avanza la tarea (o, dicho de otra manera, la precisión es menor
cuanto más lejos estemos de la finalización de la tarea).

5. La Ley de la probabilidad: toda estimación lleva una

probabilidad de cumplirse o no cumplirse.

6. Ley de Brooks: añadir gente a una actividad con retraso hace

que se retrase más

7. La del Albañil: comparar estimaciones software con el trabajo

de un albañil… es absurdo (o populismo tecnológico).

41
10. LOS 20 CONSEJOS PARA APLICAR
METODOLOGÍAS ÁGILES EN ANALYTICS

1. Haz prototipos (antes, durante y después). No dejes de

hacerlos, son la mejor herramienta para garantizar que se
va en el buen camino.

2. Ten un entorno preparado para los prototipos rápidos

(entorno en la nube, componentes predefinidos, procesos
automatizados...).

3. Usa metodologías ágiles. Hay muchas, lo más importante

es el cambio de mentalidad y empezar a usarlas.

4. La regla de oro: mejor rehacer un 30% ahora que un 100%

dentro de 6 meses. No tengas miedo a que te hagan
cambios en los prototipos. Siempre será mejor que ir a
ciegas.

5. Que todo el equipo se sienta implicado desde el momento

inicial. Y sienten que sus opiniones cuenten, aunque haya
éstas sean diversas.

42
10. LOS 20 CONSEJOS PARA APLICAR
METODOLOGÍAS ÁGILES EN ANALYTICS

6. La tradicional batalla entre usuarios-IT-Consultores, por

sus diferentes prioridades, se minimiza al colaborar desde
momentos muy tempranos y con la tranquilidad de que
'hay tiempo para corregir errores’.

7. En este tipo de proyectos, encontrar un 'product owner'

es complicado, pero lo tenéis que hacer. Debe ser de
negocio y debe estar ‘implicado-motivado’.

8. Solventa cuanto antes los puntos de fricción 'top-down',

'down-top', desde la importancia de la calidad del dato,
los procesos ETL y los metadatos a los análisis de negocio
en tiempo real, KPIs, etc... (en el punto intermedio, todos
los participantes deberán alinearse).

9. Haz los planes de pruebas no al final, sino al día siguiente

de empezar.

10. Necesitas un Project Manager (el que está al tanto de

todo, conoce a todos, convoca y resume las reuniones,
etc...) Necesitas una cabeza visible y clara que todos
'identifiquen con el proyecto’.

43
10. LOS 20 CONSEJOS PARA APLICAR
METODOLOGÍAS ÁGILES EN ANALYTICS

11. Mide y cuenta los avances, genera satisfacción con lo

conseguido.

12. Reuniones breves al principio de cada día y más amplias

cada semana.

13. Nunca pongas la presentación de un hito, avance, etc..

un lunes por la mañana (es de malos gestores, contar con
el fin de semana de colchón) y genera ansiedades.

14. Usa el BI (modelos de datos, dashboards..) de forma ágil

para validar rápidamente la calidad de los datos, tiempos
de ejecución, etc... BI por partida doble.

15. Deja que los usuarios se acerquen al BI. Desde las fases
iniciales pierde el miedo a que accedan, toquen, rompan,
se frustren, se sorprendan, se quejen de lo que van
viendo, etc.

44
10. LOS 20 CONSEJOS PARA APLICAR
METODOLOGÍAS ÁGILES EN ANALYTICS

16. No dejes el diseño y usabilidad para el final. Aunque

pienses que es secundario y posterior, debe ir paralelo al
desarrollo. Si no lo haces, la implicación de usuarios
decaerá enormemente.

17. Con AgileBI vas a tener que seguir documentando (de

otra forma, con herramientas online (trello, podio, etc...),
pero lo harás.

18. Con AgileBI se necesita más disciplina, no menos. Esto es

muy importante. Se asocia a cierto caos y es todo lo
contrario. Se trata de trabajar como los mecánicos que
cambian las ruedas en Fórmula 1.

19. Como responsable (Negocio, IT…) tienes que tener a la

gente motivada en el proyecto (esto se consigue con todo
lo anterior), pero si haces todo lo anterior y no están
motivados, 'el problema eres tú’.

20. Un proyecto BI/DW nunca, nunca, nunca se acaba. Si lo

das por acabado, también será un fracaso.

45
¡Gracias!

@Emilio Arias

46