Agile Data Warehousing Framework

 Motivação
 Manifesto Ágil
 Princípios Ágeis e Data Warehousing
 Aplicação de Práticas Ágeis na Construção de
Data Warehouse Evolutivo
 Extreme Scoping
 Agile Data Warehousing
 Framework FDWS

13/10/2010 ©2010 | Mauricio Cesar Santos da Purificação | Grupo DW-UFBA 2

 Segundo estudo da Forrester Research
realizado com empresas dos Estados Unidos,
o Business Inteligence (BI) continua no topo
da lista de desejos dos gestores de negócio e,
não coincidentemente, também do
departamento de TI.


 O relatório intitulado “Agile BI Out Of The
Box”criado a partir do estudo realizado pelo
especialista Boris Evelson da Forrester,
aponta alguns problemas relacionados a
projetos de BI.

 Para muitos CIOs, apesar do desejo das
corporações, conseguir empregar aplicativos
novos e inovadores de BI ainda é um desafio.

 Isso porque, hoje, na rede das empresas
existem grandes volumes de dados inseridos
em ambientes complexos de TI que não
conversam entre si.

 Além disso, os utilizadores empresariais de
aplicações de BI estão largamente insatisfeitos
com a falta de agilidade e flexibilidade das
soluções existentes.

 Embora algumas delas tenham vindo ajudar as
empresas com algumas funções de negócio
específicas, no geral não conseguem
responder a todas as necessidades.

 De acordo com o especialista da Forrester,
uma das alternativas para melhorar esse
cenário está na adoção do conceito que a
consultoria classifica como Agile BI.

 “Não é diferente de qualquer metodologia de
desenvolvimento ágil”, ressalta Evelson, ao
explicar que isso demanda a criação de
soluções em pequena escala.

 Mas, a metodologia Agile BI difere de outras
abordagens na medida em que implica novas e
diferentes tecnologias e arquiteturas para
suporte.

 Nossa maior prioridade é satisfazer os
clientes através de rápidas e contínuas
entregas de software com valor agregado.

 Quem é o cliente ?
 O que é software com valor agregado em Data
Warehousing ?
▪ Relatórios ?
▪ Dashboards ?
▪ Código de ETL funcionando ?


 Mudanças de requisitos são bem vindas, até
mesmo tarde no desenvolvimento. O
processo Ágil assume a mudança como parte
da vantagem competitiva de seus clientes.

 O processo deve ser flexível e adaptável


 Entregar software funcionando
freqüentemente, em algumas semanas ou
meses, com a preferência ao menor tempo
possível.

 O processo deve ter um bom controle de escopo.
 Um tema de cada vez.
▪ O que é uma tema ?


 Homens de negócios e desenvolvedores
devem trabalhar juntos durante todo o
projeto.

 Projetos de DW necessitam da presença das
pessoas de negócio
▪ Um dos grandes motivos de falha dos projetos
 Isso se aplica a geração de relatórios
▪ Iterações diárias seriam ótimas


 Construa projetos através de indivíduos
motivados. Dê à equipe um ambiente que
atenda suas necessidades, e confie em sua
capacidade para realizar o trabalho.

 Necessita-se de pessoas que querem estar no
projeto
 Treinar a equipe, se necessário
 Manter pequenas unidades de trabalho para criar
uma atmosfera de sucesso

 A forma mais eficiente e efetiva de circular,
criar consenso, uma informação para a
equipe de desenvolvimento é através da
comunicação cara-a-cara.

 O time possui um relacionamento diário
 Realização de reuniões diárias para
monitoramento e controle


 Software em funcionamento é a primeira
medida de progresso.

 Aplicado a DW:
▪ O que é um software trabalhando ?
▪ Relatórios de BI ?
▪ Definições de tabelas ?
▪ Código ETL em funcionamento ?


 O processo Ágil promove o desenvolvimento
sustentável. Os clientes, desenvolvedores e
usuários devem ser capazes de manter uma paz
constante indefinidamente.

 Projetos de BI duram muito tempo, não cansar a
equipe com prazos irracionais.
 Bom planejamento e controle de escopo.
 Menor unidade de trabalho com valor de negócio.
 Estudo dos métodos ágeis e adaptação do que for
adequado a seu time.


 Atenção contínua a excelência técnica e bom
design inspira Agilidade.

 Design e Arquiteturas ruins = Problema
▪ Simtoma: Não é possível desenvolver tal data mart


 Simplicidade - a arte de maximizar a
quantidade de trabalho não feito - é
essencial.


 As melhores arquiteturas, requisitos e
designs surgem a partir de equipes auto-
gerenciáveis.

 Equipe de pessoas inteligentes e motivadas =
sucesso
 Somos bem-sucedidos (ou não) como uma
EQUIPE
 Incentivar o trabalho e o pensamento em equipe

 Em intervalos regulares a equipe reflete sobre
como tornar-se mais eficiente, então adaptando
seu comportamento de acordo.

 O modelo de decisão
▪ Modo de debate
▪ Pontos de Verificação

 Equipes auto-organizadas
▪ Encontrar a solução para um problema torna-se o problema
da equipe


 Refatoração de banco: Permite a evolução gradual
de um esquema de dados, aprimorando o projeto do
esquema sem alterar sua semântica.

 Modelagem de dados evolutiva: Permite que o
modelo de dados evolua gradual e iterativamente,
acompanhando sistemas que utilizem o banco.

 Testes de regressão no banco de dados: Testes que
garantem que o esquema do banco de dados
funciona como deve.

 Gerenciamento de configuração de artefatos no
banco: Os modelos, os dados de teste e os bancos de
testes são importantes “artefatos” que devem ser
corretamente gerenciados, como parte integrante do
projeto.

 Ambientes de desenvolvimento: Os
desenvolvedores precisam de ambientes de trabalho
locais, para que possam modificar, testar e executar o
sistema antes que suas versões sejam integradas em
um ambiente comum, para que somente então a
versão integrada seja passada para produção.

 Uma refatoração de banco de dados pode
ser definida como a realização de uma
alteração simples no esquema do banco, com
o objetivo de otimizar o projeto, mas
preservando sua semântica informacional e
sua semântica comportamental.


 A semântica informacional está relacionada
com a visão externa ao banco, ou seja, como
os usuários enxergam as informações do
ponto de vista de negócios. Neste caso, uma
informação que existia antes da refatoração
deve continuar existindo após a refatoração.


 A semântica comportamental está
relacionada com a manutenção das
funcionalidades existentes antes da alteração
ser efetuada. Desta forma, programas que
utilizavam o banco de dados antes da
refatoração devem ter seus códigos
atualizados para que continuem funcionando
após a refatoração.


 Combinação de práticas das metodologias
SCRUM E FDD adaptadas e aplicadas ao
domínio de projetos de Data Warehouse.

 Propõe o desenvolvimento iterativo e
incremental de Data Warehouse a partir da
cobertura de Áreas/Atividades de Negócio.


 Todo o desenvolvimento é dirigido a
“Features”

 O que é uma feature ?
▪ Uma consulta
▪ Um dashboard
▪ Um relatório

 Desenvolvimento de back-end, front-end e
metadados integrado.

 Requirements Bank
 Banco dos requisitos coletados durante as sessões com
especialistas de negócio e stakeholders.

 Project FBS
 Mapeamento das áreas de negócio da instituição.

 Project Plan
 Documento de identificação do projeto, devendo conter
estimativas de custos, detalhamento da equipe
responsável, identificação de stakeholders, papéis,
detalhamento das ferramentas e ambiente técnico,
objetivos e metas do projeto.


 Release Plan
 Definição do seqüenciamento de releases por área
de negócio mapeada no Project FBS e priorizada
pelos especialistas de negócio.

 Project Map
 Mapeamento dos itens implementados durante o
projeto. Deve oferecer uma visão geral do que foi
feito, as principais features e a arquitetura
utilizada.


 Release FBS
 Expansão do Project FBS para a área de negócio alvo
da Release.

 Release TDM
 Mapeamento das tabelas das bases de dados pelas
atividades de negócio definidas da Release FBS.

 Feature Release Backlog
 Lista de Features (consultas, relatórios, dashboards)
definidos para a Release.

 Sprint Plan
 Definição do seqüenciamento de sprints por
atividades de negócio mapeada no Release FBS e
priorizada pelos especialistas de negócio.

 Release Map
 Mapeamento dos itens implementados durante a
release. Deve oferecer uma visão detalhada do
que está sendo feito, os itens validados pelos
stakeholders e a arquitetura da solução.


 Sprint Backlog
 Lista de Features (consultas, relatórios, dashboards) definidos para
a Sprint.

 Impediment List
 Lista de impedimentos da Sprint.

 Kanban
 Quadro para acompanhamento do status das atividades da Sprint.

 Diagrams
 Diagramas de acompanhamentos definidos para o projeto: Ex:
BurnDownChart, Parking Lot e etc...


 Não existe uma fórmula concreta para a
aplicação de metodologias/práticas ágeis em
BI.

 Os dados merecem um cuidado especial pois
métodos ágeis não foram desenhados para
projetos de integração de dados.

 Use, inove, adapte o processo.

 AGILE BI. 2010. Http://www.pentaho.com/agilebi
Últimoacessoem02deOutubrode2010:

 CARVALHO, G. T. de. Aplicação de Práticas Ágeis na
Construção de Data Warehouse Evolutivo.
Dissertação (Mestrado) —Universidade de São Paulo,
São Paulo, Junho 2009.

 DIAS, M. V. B. Um Novo Enfoque para o
Gerenciamento de Projetos de Desenvolvimento de
Software. Dissertação (Mestrado) —Universidade de
São Paulo, São Paulo, 2005.

 HUGHES, R.; TEAM the C. D. M. Agile Data
Warehousing - Delivering World-Class
Business Intelligence Systems Using Scrum
and XP. [S.l.]: iUniverse, Inc., 2007. ISBN
0978-0-595-91447-0.

 KIMBALL, R. Data Warehouse toolkit: o guia
completo para modelagem
multidimensional. Campus, 2002.

 MOSS, L. EXTREME SCOPING: An Agile Approach to
Data Warehousing and Business Intelligence. 2010.
Http://www.datamanager.it/news/business-
intelligence/extreme-scopingagile-approach-data-
warehousing-and-business-intelligence. Último
acesso em 02 de Outubrode 2010.
 MOSS, L. Extreme Scoping - An Agile Project
Management Approach. 2007.
Http://www.eiminstitute.org/library/eimiarchives/volu
me-1-issue-5-july-2007-edition/extreme-scoping-an-
agile-project-management-approach. Último acesso
em 02 de Outubro de 2010.

 NÓBREGA, J. ao. Forrester defende novo modo de
desenvolver BI. [S.l.]: Computerworld,2010.
Http://www.computerworld.com.pt/2010/04/29/forres
ter-defende-novo-modo-dedesenvolver-bi/. Último
acesso em 25 de Setembro de 2010.

 PRESTON, R. Down To Business: Business Intelligence
Still In Its Infancy. [S.l.]: InformationWeek, 2003.
Http://www.informationweek.com/news/businessintel
ligence=showArticle: jhtml?articleID =
196801521:ltimoacessoem25deSetembrode2010:


 SÁ, J. V. de Oliveira e. Metodologia de Sistema
de Datawarehouse. Tese (Doutorado) —
Universidade do Minho, Portugal, 2009.

 WAILGUM, T. BI representa desafio para
empresas, aponta Forrester: CIO/EUA,2010.
Http://cio.uol.com.br/gestao/2010/04/26/bi-
representa-desafio-para-empresas-
apontaforrester/. Último acesso em 25 de
Setembro de 2010.


Agile Data Warehousing Framework

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Agile Data Warehousing Framework

Semelhante a Agile Data Warehousing Framework (20)

Mais de Mauricio Cesar Santos da Purificação

Mais de Mauricio Cesar Santos da Purificação (20)

Agile Data Warehousing Framework