Scrum for BI
22
-
Upload
diego-fernando-robledo -
Category
Data & Analytics
-
view
205 -
download
0
Transcript of Scrum for BI
¿Qué se necesita?◦ Usuarios
◦ Product owner
◦ Scrum master
◦ Team members
Product Owner
ScrumMaster
TeamUsuario
final
¿Cómo se hace?
Resultado◦ Usuarios felices
◦ Equipo comprometido
◦ Organizaciones disfrutando resultados
◦ ¿Gente más feliz?
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?
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?
Fácil◦ Hagamos un sprint de modelamiento
◦ Otro para ETL
◦ Y uno final para “Visualización”
Tableros
Reportes
Etc.
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?
Se encuentran tres elementos fundamentales para el desarrollo de BI
Arquitectura◦ Modelamiento dimensional
Data Integration◦ ETL
Data Visualization◦ Reportes
◦ Dashboards
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
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
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
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
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
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:
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
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
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
Al finalizar un sprint de Data Integration◦ Potencialmente entregables a nivel de presentación
Tablas de data
Tablas agregadas
Tablas materializadas
“Capa semántica”
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
HU
HU
HU
HU
HU
HU HU
HUHU
HU
HD
ProductBacklog
ArquitecturaModelamiento
HD
HD HD
HDHD
HDHD
Data Integration
HU HU
HUHU
HU
Data Visualization
Sprint 3
Sprint 3
Sprint 3
Sprint 2ArquitecturaModelamiento
Data Integration
Data Visualization
Sprint 2Sprint 1
