4. Resultado
◦ Usuarios felices
◦ Equipo comprometido
◦ Organizaciones disfrutando resultados
◦ ¿Gente más feliz?
5. Hay algo que no cuadra
No funciona igual
◦ No se logran los objetivos del sprint
Ampliemos el sprint!!!
Comprometámonos a menos
Aun así, ¿por qué no llegamos?
6. Si el 60% al 70% en un proyecto tradicional de
BI se va solo en ETL, ¿por qué no tenemos eso
en cuenta?
◦ Y qué tal si hacemos sprints solo para ETL?
◦ ¿Pero quién nos entrega modelo?
◦ ¿Y cómo hacemos para los reportes? ¿En otro
sprint?
7. Fácil
◦ Hagamos un sprint de modelamiento
◦ Otro para ETL
◦ Y uno final para “Visualización”
Tableros
Reportes
Etc.
8. Finalmente el ciclo para presentar un
producto potencialmente entregable era
demasiado largo
◦ Con sprints de 2 semanas, el resultado final sería a
6 semanas
◦ ¿Y el tiempo de pruebas?
◦ ¿Y la aceptación de las H.U?
9. Se encuentran tres elementos fundamentales
para el desarrollo de BI
Arquitectura
◦ Modelamiento dimensional
Data Integration
◦ ETL
Data Visualization
◦ Reportes
◦ Dashboards
10. La idea es
◦ Entregar valor de negocio en cada uno de los
niveles fundamentales anteriores
Arquitectura
Modelo dimensional. Iterativo e incremental
Data Integration
ETL. Iterativo e incremental
Data Visualization
Iterativo e incremental
11. Debe delinearse por el product owner.
◦ TI debería apoyarlo ojalá con un arquitecto
◦ Permitirá tener una visión de alto nivel de diseño
◦ Dependencias con otros sistemas o proyectos
◦ Permite asegurar que las HU futuras sean
coherentes con lo planeado en el PB
12. Sprint inicial
◦ Inicia el equipo de arquitectura
Tomar las HU del Product Backlog
Realizar modelamiento de acuerdo con HU
Paradigma: El modelo tiene que estar completo antes de
hacer Data Integration.
◦ Entrega de valor:
Primera iteración del modelo de datos
13. Primera iteración del modelo
◦ Comienzo de Data Integration
Paradigma: HU y Criterios INVEST
I ndependent
N egotiable
V aluable
E stimable
S mall
T estable
14. Para BI una HU
◦ Demasiado genérica o muy grande
◦ No se alcanza a cumplir en un sprint
◦ Difícil realizar las pruebas de aceptación
Historias de desarrollador
◦ Punto intermedio entre HU y Tareas
◦ Puede ser cumplida en un sprint
◦ Representa avance en la entrega de valor
◦ Es entendible por el PO
15. D emonstrable
I ndependent
L ayered
B usiness valued
E stimable
R efinable
T estable
S mall
I ndependent
N egotiable
V aluable
E stimable
S mall
T estable
• Dilberts en vez de Invest:
16. Demonstrable
◦ Cada entregable debe ser algo que se pueda mostrar
al PO
◦ Pueden haber varios entregables demostrables para
poder completar una HU
Independent
◦ Al comenzar una historia de desarrollador no puede
depender de otras
◦ Secuencializarlas para asegurar independencia
17. Layered
◦ La historia debe pertenecer a una única capa
Extracción/Stage
Integración
Presentación
Business Valued
◦ Asegurar que la historia entrega valor de negocio.
◦ Es el criterio más complejo
18. Estimable
◦ Heredado directamente de INVEST
Refinable
◦ Concentrarse en el qué
◦ El cómo es lo que se permite refinar
Testable
◦ Heredado directamente de INVEST
Small
◦ Inherente a las historias de desarrollador
19. Al finalizar un sprint de Data Integration
◦ Potencialmente entregables a nivel de presentación
Tablas de data
Tablas agregadas
Tablas materializadas
“Capa semántica”
20. Finalizadas entregas de sprints de Data
Integration, inicio de explotación.
◦ Se pueden tomar HU para explotación o
visualización
◦ Se trabaja con HU; las HD son para Data Integration
◦ Los reportes, tableros, vistas, etc., pueden ser
iterativos e incrementales