Você está na página 1de 33

ESTUDO BIBLIOGRFICO DA ADAPTAO DE MTODOS GEIS AO CICLO DE VIDA DO BI

Marcelo Gomes Marques1 e Arnaldo Lyrio Barreto2


RESUMO:

ABSTRACT:

A gesto do BI em uma organizao


atravs de todo ciclo de vida de produto j
apresenta inmeros desafios em si, onde
os mtodos tradicionais,
embora
largamente empregados,
no so
suficientes,
expondo uma srie de
problemas crticos decorrentes desta
abordagem.

The management of BI in an organization


through the entire life of product cycle
already has many challenges in itself,
where traditional methods, although widely
used, are not enough, and are exposing a
number of critical issues arising from this
approach.

A prtica gil de BI trata-se de um conjunto


de princpios, comportamentos e tcnicas
que provem aos stakeholders a reduo
destes problemas crticos, ao passo que
acelera a captura do valor percebido de
uma soluo de BI de qualidade entregue
de forma iterativa, incremental e evolutiva.
No entanto,
dada a abrangncia e
complexidade das solues de BI, existem
mais de uma abordagem publicada, porm
no se conhece at a elaborao deste
artigo, nenhuma proposta que cuide de
todo o ciclo de vida do produto de BI.
Este trabalho visa apresentar o estudo
bibliogrfico do que h de mais novo na
proposio de abordagens de adaptao
de mtodos geis a conduo do ciclo de
vida de produtos de BI nas organizaes,
assim como oferecer um uma proposta
unificada de diferentes abordagens e uma
definio de indicadores qualitativos e
quantitativos de sua aplicao.
Com isso,
podemos observar que a
adaptao da abordagem de mtodos
geis conduo de programas, projetos
e sustentao de solues de BI
contribuem para a melhora do ambiente e
nas condies para a sua conduo,
possibilitando tambm as justificativa em
termos dos custos envolvidos em seu
desenvolvimento pela rpida apresentao
de resultados,
atraindo a ateno e
investimento por parte dos usurios finais.
Palavras-Chaves:
BI,
Business
Intelligence, gil, Priorizao, Adaptao
de Mtodos, Cadeia de Valor, Gesto de
Programas e Projetos, Ciclo de Vida do
Produto, histrias de dados, histrias de
desenvolvimento, refatorao, Modelagem
Evolutiva, Iterativa e Incremental.

The Agile BI practice it is a set of principles,


behaviors and techniques that prove to
stakeholders a reducing these critical
issues while accelerating the capture of
perceived value of a quality BI solution
delivered through iterative, incremental and
evolutionary process.
However, given the scope and complexity
of BI solutions, there are more than one
approach published. However it doesn't
exist any proposal that addresses the entire
life cycle of the BI products in an
organization, until the writing of this article.
This article presents a study about of the
newest proposals approaches for adapting
agile to driving all life cycle of BI products in
organizations, as well as offer a unified
approach and definitions of KPIs to
measure qualitative and quantitative its
application.
With this picture in mind, we can observed
that the adaptation of the agile approach to
conduct of programs, projects and support
BI solutions should contribute to improved
environmental conditions and to your
driving, also enabling the justification in
terms of the costs involved in its
development by the rapid presentation of
results, must be able to attracting attention
and investment on the part of end users.
Key-Words: BI, Business Intelligence,
Agile, Prioritization, Methods Adaptation,
Value Chain, Program and Project
Management, Product Lifecycle, Data
Stories, Developer Stories, Refactoring,
Evolutionary, Iterative and Incremental
Modeling.

Marcelo Gomes Marques, MBA em Gesto Integrada de Negcios e e-Business pela Universidade
Federal do Rio de Janeiro mgm2000@terra.com.br
2

Arnaldo Lyrio Barreto Barreto, Universidade Federal do Rio de Janeiro, Doutor em Epistemologia pelo
programa HCTE, Cidade Universitria Ilha do Fundo Centro de Tecnologia, Bloco A, 7 andar C.P.
68563, CEP 21.945- 970, Rio de Janeiro, RJ, Brasil, arnaldo.barreto@ufrj.br.

INTRODUO:
A abordagem de mtodos geis so muito
aplicadas
com
sucesso
no
desenvolvimento
de
software,
j
comprovada como uma alternativa vivel
aos mtodos tradicionais. Contudo, para a
sua adequada aplicao em projetos de BI
(Business Intelligence) necessria a
adaptao de um conjunto de prticas,
valores e princpios geis utilizados na
construo de software,
dada a sua
complexidade e caractersticas que tratam
de todo o processo de coleta, organizao,
anlise,
compartilhamento
e
monitoramento de informaes, atravs de
um conjunto de aplicaes e tecnologias
que oferecem suporte gesto de
negcios.
Segundo Hughes (2011), a construo de
uma soluo de BI corporativa trata-se de
um projeto bastante complexo, visto a sua
abrangncia
e
caracterstica
multidisciplinares,
envolvendo
muitas
tecnologias e pessoal, de diferentes nveis
e reas da organizao, traduzindo-se em
um grande esforo conjunto para construir
esperada viso nica para a tomada de
deciso.
Alm disso, Camargo (2007) afirma que
mudanas fazem parte do processo
evolutivo, sobretudo no mbito competitivo
do ambiente de negcios atual, onde
emergem cada vez mais rapidamente
novas estratgias,
e por conseguinte,
novos requisitos, sobretudo com foco em
inovao,
tratamento de ameaas e
oportunidades oriundas de fatores externos
em constante mudana.
No contexto do BI, para Hughes (2012), o
processo tradicional de construo de
solues falha ao buscar atender a esta
demanda, sobretudo quanto h tendncia
atual de se perceber projetos de trs (3)
meses como muito longos. Soma-se a isso
o fato de ser comum a contratao do
projeto sob o modelo de preo fixo,
tendendo ao escopo fechado.
Alm disso, segundo Collier (2011), a
abordagem de projetos de BI atravs de
mtodos tradicionais conduz a um aumento
dos seguintes riscos do projeto:

Instabilidade e mutabilidade nos


requisitos;

Desconexo entre usurios e


desenvolvedores;

Incapacidade dos processos de


desenvolvimento de responder a
mudanas;

O produto final apresenta pouco ou


nenhum valor ao usurio.

Por fim, o mtodo muitas vezes visto


como burocrtico e distanciador do cliente
daquilo que deveria ser a sua principal
entrega, o cdigo funcional, visto que o
cliente envolvido nas fases de desenho
funcional e depois apenas apresentada
novamente a soluo na fase de
homologao. Com isso, muito tempo se
passou at que funcionalidades sejam
entregues aos clientes,
no sendo
nenhuma surpresa o nmero de projetos
malsucedidos e a baixa a taxa de utilizao
das funes implementadas, com menos
de 40% de suas funes em uso, segundo
Johnson (2002).
Para Collier (2011), esta adaptao s
abordagens geis no muda radicalmente
o modo de se construir sistemas BI, ou
mesmo invalida as melhores prticas que
foram estabelecidas por muitos autores
como Imon (1991) ou Kimball (2002), mas
sim traduz-se em um modo ou estilo
alternativo de desenvolvimento, que se
prope a suprir as diversas carncias das
abordagens tradicionais, e permitem que o
desenvolvimento de sistemas de BI seja
abordado de uma maneira evolutiva.
Segundo Collier (2011),
os principais
objetivos de uma abordagem gil aplicada
a projetos de BI se traduz em:

Entregar continuamente software


de qualidade que agregue valor ao
cliente;

Reduzir o grau de risco em projetos


deste tipo.

De acordo como Beck et all (2012), os


mtodos geis tm uma abordagem que
valoriza o respeito s pessoas, a contnua
colaborao com o cliente e o aumento da
produtividade, reduzindo o tempo gasto
com atividades que no agregam valor ao
projeto
e
fazendo
com
que
as
funcionalidades mais importantes do
software
sejam
desenvolvidas
e
disponibilizadas
para
os
usurios
rapidamente.
Devemos ainda ressaltar que os mtodos
geis tm slida sustentao em conceitos
de engenharia de software, com pouca
nfase burocrtica e ignorando a ideia de
que a especificao inicial deva atender um
sistema completo,
defendendo um
desenvolvimento em ciclos curtos, com
qualidade e de maneira organizada.

Tendo todos os pontos ora exposto,


observa-se que a adaptao da abordagem
de mtodos geis ao ciclo de vida de
solues de BI nas organizaes
contribura para a melhora do ambiente e
das condies para a sua conduo,
possibilitando tambm a sua necessria
justificativa em termos dos custos
envolvidos em seu desenvolvimento pela
rpida
apresentao
de
resultados,
atraindo a ateno e investimento por parte
dos usurios finais.
Este trabalho visa apresentar o estudo
bibliogrfico do que h de mais novo na
proposio de abordagens de adaptao
de mtodos geis a todo o ciclo de vida de
solues de BI,
resultando em uma
proposta de modelo de abordagem e da
avaliao
quantitativamente
e
qualitativamente de sua aplicao, com
foco na garantia de que todo trabalho
necessrio para a concluso bem-sucedida
seja considerado.
Para o atingimento do objetivo geral acima
exposto, o trabalho seguiu a abordagem
metodolgica de um estudo bibliogrfico da
adaptao de mtodos geis a solues de
BI, tendo incio com a apresentao de
uma introduo terica, seguido do estudo
da bibliografia selecionada, destacando o
que h melhor e mais novo sobre o tema.
Na sequncia sero apresentadas as
definies de um processo de adaptao e
dos respectivos parmetros de medio
quantitativa e qualitativa a ser aplicada na
soluo do problema a luz das teorias.
Por fim, tecida uma concluso dos
resultados do estudo, assim como a
sugesto para continuidade e elaborao
de trabalhos futuros.

FUNDAMENTAO TERICA:
Hughes (2012) afirma que o mtodo em
cascata, assim como outras metodologias
pr-descritivas,
tambm conhecidas por
ciclo de vida clssico,
BIG BANG,
plan-driven, single-pass, Big Design Up
Front (BDUF) e abordagem de entrega
nica,
so intuitivas e de fcil
gerenciamento, mas apresentam diversos
problemas decorrentes de sua estrutura,
que prope um desenvolvimento em fases
sequenciais,
com uma fase inicial de
levantamento e detalhamento exaustiva de
requisitos,
posteriormente um longo
perodo de desenvolvimento sem a

participao ativa dos usurios,


que
somente so envolvidos novamente a partir
da fase de homologao.
Segundo Hughes (2012), o mtodo em
cascata,
mesmo apresentado tais
problemas, veio a se tornar um padro
mundial para indstria de software, graas
a influncia do Departamento de Defesa
Americano (DOD). Em 1985, o DOD,
pressionado a obter melhores resultados
de seus provedores de servios de
integrao de sistemas, lanou uma srie
de processos padres com o objetivo de
estabelecer
uma
uniformizao
da
especificao de requisitos. Dentre estes
padres temos a DOD-STD-2167, que
estabelece o mtodo em cascata o seu
padro de mtodo para o desenvolvimento
de sistemas.
Hughes (2012,
p.12) comenta que,
ironicamente, a DOD-STD-2167 pode ser
vista apenas como uma grave falta de
leitura completa do artigo de Royce.
Segundo Hughes (2012, p.12), Royce
(1970), logo na abertura de seu artigo,
descreve o mtodo em cascata apenas
como os passos comuns essenciais para o
desenvolvimento de qualquer sistema,
salvo as limitaes do mtodo ao tamanho
e complexidade do projeto. Na segunda
parte deste artigo, Royce (1970, p.3)
defende um caminho iterativo para o
progresso do projeto atravs desses
passos,
dado que se o mtodo
conduzido em uma nica passada um
grande risco e um convite a falhas, o
prprio autor sugere que tal mtodo
funciona,
na maior parte dos casos,
apenas para projetos de escopo simples.
Ainda de acordo com Hughes (2012), a
construo de uma soluo de BI
corporativa trata-se de um projeto bastante
complexo,
visto a sua abrangncia e
caracterstica
multidisciplinares,
envolvendo muitas tecnologias e pessoal,
de diferentes nveis e reas da
organizao, sendo comum que este tipo
de projeto seja bastante burocrtico, com
documentaes extensas e traduzindo-se
em um grande esforo conjunto para
construir esperada viso nica para a
tomada de deciso.
Dada estas questes,
Kimball (2002)
prope o mtodo que busca construir, de
forma iterativa, diversos DM (data marts),
que devem ser gradualmente integrados
atravs do conceito de conformidade entre
dimenses e indicadores em uma

arquitetura,
por ele denominada Bus
Architecture, estabelecendo com isso uma
viso nica da empresa.
Segundo Corr et all (2011), dimenses
conformes tratam-se de componentes
fundamentais e reutilizveis da modelagem
dimensional,
viabilizando
anlises
cruzadas entre fatos e comparaes de
medidas de mltiplos processos de
negcios. Para isso, Corr et all (2011)
recomendam a adoo da DW Bus
Architecture de Kimball (2002), por esta
suportar o desenvolvimento incremental e
realmente gil de DM integrados.
Para Corr et all (2011, p.99), tambm
importante atentar para a conformidade de
medidas e indicadores de performance,
garantindo que mtricas relacionas, ou
mesmo redundantes em outras fatos
apresente os mesmos conceitos e tenham
unidades de medidas comuns ou
compatibilizadas.
Contudo, Hughes (2012) afirma que este,
e outros mtodos que prope um processo
iterativo, no na prtica uma proposta
gil, mas sim uma resposta natural, aps
o volumoso insucesso de projetos de
software
conduzidos
sob
mtodos
tradicionais,
sobretudo
nos
que
apresentam um escopo muito grande.
Segundo Hughes (2012),
neste caso o
mtodo continuam exigindo todo o conjunto
de burocracias de um grande projeto de
software tradicional, porm conduzido de
acordo com um cascateamento de
iteraes focadas no detalhamento mximo
dos requisitos. Essa a limitao pode
ainda ser observada na proposta de
Kimball et all (2008), pois, para ele, o DM
deve ser inteiramente desenvolvido, antes
que um novo ciclo se inicie.
De acordo com Corr et all (2011) e Hughes
(2012),
qualquer evoluo requer
adaptao, e esse elemento alcanado
atravs da contnua maturao de
funcionalidades inicialmente simples que,
de forma incremental e ao longo das
iteraes,
adquirem um nvel de
complexidade mais elevado.
Para Collier (2011), o mtodo incremental
baseia-se na entrega de funcionalidades
parciais aos usurios, a cada iterao.
Hughes (2012), destaca que sobre este
mtodo fcil observar que cada etapa
subsequente depender intrinsecamente
das fases anteriores,
ou seja,
a
implementao se baseia completamente
no que j foi desenvolvido. Da surge

necessidade de prticas que deem suporte


a cada fase do projeto para que o
desenvolvimento evolutivo seja vivel e
sustentvel.
De acordo com Hughes (2012), o DOD
veio a substituir a DOD-STD-2167 por um
padro que promovia a mtodo incremental
e iterativo apenas em 1994. Infelizmente,
mesmo com os casos de insucesso de sua
aplicao pelo prprio DOD, com os nove
anos de vigor da a DOD-STD-2167, a
mesma j havia sido absorvida e
estabelecida como um padro de
referncia da indstria, e utilizada na base
de outros padres das empresas e
governos mundo a fora, inclusive na
formao da sua fora de trabalho, tanto
dos gestores quanto dos respectivos
tcnicos, o que dificulta at hoje a adoo
de outros mtodos e padres.
De acordo com Collier (2011) e Hughes
(2012), projetos de BI apresentam diversas
caractersticas
que
os
tornam
particularmente complexos, dentre elas:

A necessidade de uma equipe


ampla,
dada as caracteres e
amplitudes de ferramentas e
plataformas utilizadas na soluo,
que
foram
naturalmente
a
especializao
dos
mesmos
(modelam
de
dados,
desenvolvimento de ETL, limpeza
de dados, design em ferramentas
de consumo/anlise,
dentre
outras);

Tendem
a
almejar
o
desenvolvimento
ao
nvel
organizacional, ou com elevada
amplitude de funes, o que
aumenta a complexidade e dificulta
a determinao correta do escopo;

Expectativas irreais em relao a


este tipo de tecnologia;

Com
o
ganho
de
melhor
entendimento
por
parte
dos
usurios,
seus desejos
ou
necessidades mudam;

O BI comumente expe problemas


na qualidade dos dados, o que leva
a desconfiana e exigncia por
parte dos usurios finais sob a
prpria soluo de BI;

A taxa de projetos de BI que


falham gira em torno de 50%.
Estas falhas se caracterizarmos
por:

5
o Extrapolam custos e prazos
o Apresentam funcionalidades
esperadas que no foram
implementadas
o Deixam usurios insatisfeitos
o Possuem
performance,
disponibilidade
ou
escalabilidade inaceitveis
o Exibem dados sem valor (so
pobres aos olhos do usurio).
Dadas estas caractersticas, para Collier
(2011), abordar um projeto de BI atravs
dos mtodos em cascata leva a um
aumento no risco do projeto por diversas
razes:

Instabilidade e mutabilidade nos


requisitos;

da conduo do processo de seu


desenvolvimento que se prope a suprir as
diversas carncias das abordagens em
cascata.
Com isso exposto, Collier (2011), sem
propor uma grande mudana nestes
fundamentos e prticas,
foca a sua
proposio na adoo de uma srie de
prticas geis dentro das atividades tpicas
de elaborao de uma soluo de BI, onde
estas so repetidas a cada iterao, e
quando aliadas as prticas geis, permitem
que o desenvolvimento seja abordado de
uma maneira evolutiva.
Para Collier (2011), essas atividades so:

Especificao dos requisitos do


Negcio;

Criao dos modelos dimensionais;

Projeto
de
ETL
(Extraction,
Transformation and Loader), que
tratam dos processos automao
de extrao, transformao e carga
de uma origem de dados a outro
destino;

Desconexo entre
desenvolvedores;

Incapacidade dos processos de


desenvolvimento de responder a
mudanas;

Devido aos fatores acima o produto


final apresenta pouco ou nenhum
valor ao usurio.

Implementao fsica do modelo


(carregar dados para as tabelas
multidimensionais);

Collier (2011) ento afirma que o emprego


de um mtodo gil de desenvolvimento
busca atuar em cima destes pontos crticos
de modo que o objetivo de uma
metodologia gil dentro do mbito de
projetos de BI se traduz em:

Implantao.

usurios

Entregar continuamente software


de qualidade que agregue valor ao
cliente;

Reduzir o grau de risco em projetos


deste tipo.

Segundo Collier (2011), a fim de viabilizar


estes objetivos, um conjunto de prticas,
valores e princpios geis utilizados na
construo de software devem se adaptar
ao ambiente de solues de BI norteando e
permeando
todo
o
ciclo
de
desenvolvimento.
Para Collier (2011), a adoo de tais
elementos no muda radicalmente os
fundamentos do desenvolvimento de
solues de BI, to pouco invalidam as
melhores prticas que foram estabelecidas
por muitos autores altamente considerados
pela comunidade de BI como Imon (1991)
ou Kimball (1996 e 2002). Collier (2011)
ressalta que a adoo de um mtodo gil
estabelece um modo ou estilo alternativo

J para Corr et all (2011) e Hughes (2012)


os mtodos geis, ou simplesmente os
mtodos incrementais somado mtodo
iterativo, tratam-se de uma alternativa mais
adequada a projetos de software. Contudo,
segundo os autores adoo de qualquer
mtodo gil em BI ainda requer adequao,
pois os seus requisitos tcnicos de
arquitetura e integrao de dados, atravs
de processo de extrao, transformao e
carga de dados ao longo de camadas com
propsitos especficos no so facilmente
traduzidos em histrias de negcio, visto
que comumente apenas a ltima camada
que acessada, e portanto percebida, pela
rea de negcio. Alm disso, dependendo
da complexidade da integrao a ser
desenvolvida, h histrias de negcio que
simplesmente no cabero em uma nica
iterao.
Entende-se que a prtica gil
de Data Warehousing trata-se
de um conjunto de princpios,
comportamentos e tcnicas
que provem aos nossos
clientes uma reduo do
tempo necessrio para captura

do valor percebido de uma


soluo de BI de qualidade,
atravs da inicializao rpida
dos
projetos,
elevado
envolvimento das reas de
negcio,
incrementos
frequentes
de
valor
e
atualizao/comunicao
regulares de informaes a
respeito do planejamento.
(HUGHES, 2012, p.327),
Sobre este contexto,
Hughes (2012)
sugere a adaptao do mtodo gil
denominado
Srum
para
ao
desenvolvimento de solues de BI, sob
uma abordagem evolutiva que objetiva
construir o sistema em ciclos de iteraes
limitadas por um perodo de tempo, na
maioria das vezes de 2 a 4 semanas, onde
ao final de cada iterao so resultadas
novas
funcionalidades,
que
so
implementadas tendo como base as
"histrias de usurios".
Hughes (2012), ao descrever a adaptao
do mtodo Scrum, descreve que estas
funcionalidades
so
levantadas
e
documentadas atravs
histrias dos
usurios, que devem ser breves textos do
ponto de vista do usurio, a respeito das
funcionalidades do sistema a serem
entregues, com contexto suficiente para
que estas sejam nicas, possveis de
serem testadas e aceitadas, estando elas
concludas dentro de uma nica iterao e
prontas para integrar-se ao resto do
sistema.
Uma vez que Hugnes (2012), Corr et all
(2011) e Collier (2011), dentre outros,
adotam o Srcum e o XP como mtodos
base para a adaptao de uma abordagem
gil a projetos de BI, a seguir resumo
apenas os conceitos mais relevantes
destes mtodos presentes nas obras
destes autores, visualizados na Figura 1 e
utilizados ao longo deste trabalho:
Product Backlog: lista do contendo
de
todas
as
funcionalidades
desejadas para um determinado
produto. O contedo desta lista
definido pelo Product Owner e no
precisa estar completo no incio de
uma iterao. Pode-se comear com
tudo aquilo que conhecido at
aquele momento, com o tempo, a
lista cresce e muda medida que se
aprende mais sobre o produto e seus
usurios.

Sprint Backlog: lista de tarefas que


a equipe de Scrum se compromete a
fazer em uma iterao (Sprint). Os
itens do Sprint Backlog so extrados
do Product Backlog, pela equipe,
com base nas prioridades definidas
pelo Product Owner e a percepo
da equipe sobre o tempo que ser
necessrio para completar as vrias
funcionalidades.
Product Owner: pessoa que define
os itens que compem o Product
Backlog e os prioriza o Sprint
Backlog nas sees de Sprint
Planning Meetings.
Sprint Planning Meeting: trata-se
da reunio de planejamento do
Sprint que ser iniciado, nela esto
presentes o Product Owner, o Scrum
Master e todo a equipe Scrum, bem
como qualquer pessoa interessada
que esteja representando a gerncia
ou o cliente.
Durante o Sprint
Planning Meeting, o Product Owner
descreve as funcionalidades de
maior prioridade para a equipe, que
deve formular perguntas de modo a
compreender as funcionalidades e
quebra-las em tarefas tcnicas,
aps a reunio.
Scrum Team, ou Equipe Scrum:
composta
pela
equipe
de
desenvolvimento, na qual no existe
uma diviso funcional ou hierarquias,
mas sim todos atuado de forma
interativa, colaborativa e de autoorganizadas, trabalham juntos para
completar todo o trabalho com o qual
se comprometeram.
Sprint Review Meeting: reunio
conduzida ao final de cada iterao,
onde o projeto avaliado em relao
aos objetivos da iterao. Para isso
a equipe de Scrum apresenta o que
foi alcanado durante a iterao.
Tipicamente, isso tem o formato de
um prottipo funcional das novas
funcionalidades.
Prototipao: com base em uma
viso evolutiva do desenvolvimento
de
software,
esta
abordagem
envolve o desenvolvimento de
verses iniciais, denominadas de
prottipos,
das funcionalidades
contidas em uma interao, com o
objetivo
de
avalia-las
tanto
individualmente, quanto em como
estas afetaram toda a soluo,

antes que a nova funcionalidade


venha realmente a ser implementada
e
integrada
definitivamente
a
soluo.
Daily Scrum:
a cada dia da
iterao, a equipe faz uma reunio
diria, chamada Daily Scrum, que
tem como objetivo disseminar
conhecimento sobre o que foi feito
no
dia
anterior,
identificar
impedimentos e priorizar o trabalho a
ser realizado no dia que se inicia.
Estas reunies devem ter curta
durao,
cerca de 15 minutos,
normalmente so realizadas no
mesmo lugar, na mesma hora do
dia. Idealmente so realizados na

Scrum Master:
responsvel por
assegurar que a equipe respeite e
siga os valores e as prticas do
Scrum.
Ele tambm protege a
equipe assegurando que ela no se
comprometa excessivamente com
relao quilo que capaz de
realizar durante uma iterao. Alm
disso, o Scrum Master atua como
facilitador do Daily Scrum e torna-se
responsvel por remover quaisquer
obstculos que sejam levantados
pela equipe durante essas reunies.
Dado as caractersticas de arquitetura e
complexidades de integrao inerentes aos
projetos de BI, Hughes (2012) subdivide
estes projetos em dois grandes grupos:

No primeiro, so tratadas apenas


demandas que envolvam apenas
ferramentas
e
funcionalidades
voltadas ao desenvolvimento da
camada de apresentao ao usurio,
ou seja,
os painis,
relatrios

Figura 1. Diagrama do Processo Scrum

Fonte: Blog MCruz Treinamentos TI

parte da manh,
para ajudar a
estabelecer as prioridades do novo
dia de trabalho. Durante a reunio
no se deve discutir detalhadamente
ou tratar da resoluo de problemas.
Os problemas levantados devem ser
tratados
aps
a
mesma,
normalmente por um grupo menor de
pessoas que
tenham a
ver
diretamente com o problema ou
possam contribuir para solucion-lo.

e outros objetos de consumo. Para


esta o autor afirma que a adoo
do mtodo Scrum pode ser
conduzida
com
praticamente
nenhuma adaptao.

No segundo,
so delineadas
adaptaes mais profundas ao
Scrum,
que visam tratar as
demandas
que
requerem
integrao
de
dados
mais
complexas e ao logo das camadas.

A esta adaptao destaca-se a


definio de uma arquitetura de
referncia,
que sustentar e
orientar todos os projetos sobre a
tica evolutiva;
a adoo de
alguns
papeis
tcnicos
permanentes
a
equipe,
fundamentados pela necessidade
de especializao intrnsecas aos
projetos que envolvem integraes
complexas
e
empregos
de
ferramentais de BI especficas,
assim como pela sugesto de a
adoo de developer stories.
Hughes (2012, p.178) esclarece que
developer stories so essencialmente
quebras hierrquicas das histrias de
usurios em requisitos tcnico, descritas
igualmente de forma textual,
sob um
modelo voltado a compreenso e a
demonstrao de valor ao product owner,
proporcionando portanto a conduo das
iterao sob a perspectiva destas
developer stories, ao invs de ao nvel
das respectivas histrias de usurios.
J para Corr et all (2011) a abordagem de
adaptao de mtodos geis para BI deve
focar na proposio de um mtodo gil de
modelagem dimensional.
Baseado em
uma abordagem top-down de levantamento
dos requisitos informacionais e analticos,
este mtodo induz tcnicas colaborativas
para concepo de um modelo de negcio
construdo de forma incremental e iterativa.
Alm disso,
Corr et all (2011, p.24)
ressaltam que sua proposta de adaptao
e mtodo suporta valores geis como
Interaes e indivduos acima de
processos e ferramentas,
Software
funcionado acima de documentaes
abrangentes e Colaborao com o cliente
mais que negociao de contratos. Corr et
all (2011, p.24) ainda vai alm no que diz
respeito ao principio de Simplicidade: a
arte de maximizar a quantidade de trabalho
que no precisou ser feito., ao encorajar
que os profissionais de BI trabalhem
diretamente junto aos stakeholders para
produzir colaborativamente modelos de
dados compreensveis e compilveis, ao
invs de documentos de requerimentos,
assim como em prottipos de relatrios/
dashboards ao invs de mockups.
No segundo captulo de sua obra, Corr et
all (2011) propem a adoo de data
stories, que identificam os eventos de
negcio sob uma narrativa desenvolvida
atravs da explorao dos 7Ws (Who,

What, Where, When, hoW many, Why e


Who).
Para viabilizar um mtodo
colaborativo e gil de modelagem, Corr et
all (2011) definem estruturas tabulares
simples junto a alguns padres de
nomenclatura e organizao,
que
permitem que tais histrias de dados sejam
criadas conjuntamente com o cliente, com
uso de simples quadros brancos,
permitindo assim a captura de exemplos de
forma colaborativa.
Para tal, Corr et all (2011) estabelecem
com detalhes um conjunto de passos que
orienta todo este processo, e afirma que
com poucas sees possvel identificar
os principais requisitos informaes em
forma de data stories, e estabelecer suas
conexes e desdobramentos atravs da
modelagem de processos de negcio via
matriz de eventos, que viabilizam a
modelagem e encadeamento de mltiplos
eventos de negcio e conformidade junto
as dimenses.
De acordo com Hughes (2012), Collier
(2011) e Corr et all (2011), um dos maiores
riscos da aplicao de mtodos geis a
projetos de BI esta na no gesto dos
eventuais dbitos tcnicos. De acordo com
os autores, dbitos tcnicos compreendem
os aspectos tcnicos negativos da
implementao de uma soluo, que por
existirem, acabam por dificultar qualquer
tipo de alterao, ou adio de nova
funcionalidade. Neste campo, ao contrrio
de Hughes (2012), Corr et all (2011)
buscam evitar a exposio direta aos
usurios a complexidade tcnica, que para
ele tem de ser avaliada preliminarmente
pela equipe de projeto.
Para Corr et all (2011),
seu mtodo
proporciona a captura do nvel de
complexidade suficiente para a priorizao,
j o aprofundamento e confirmao, sero
feito apenas para as data stories que
foram priorizadas, atravs da anlise de
data profiles das origens de informao.
neste passo que o modelo desenhado junto
aos stakeholders validado, convertido
em modelo dimensional, o que viabiliza o
desenho final e a estimativa da equipe de
integrao de dados responsvel pelo
desenvolvimento dos processos de ETL.
A resultante permite a estimativa de
esforos e a captura de valor sob a
perspectiva de negcio, o que viabiliza a
prioriz-los e permitir a conduo dos
projetos de BI de forma evolutiva, sob a
perspectiva de um programa conduzido

pela viso nica que criada de forma


colaborativa e incremental. Neste sentido,
Corr et all (2011) alinham sua abordagem
aos conceitos da cadeia de valor de Porter
(1995).
Porter (1985) prope a decomposio de
uma organizao em suas atividades de
relevncia estratgica, torna-se possvel
analisar o comportamento de gerao e
destruio de valor, assim como potenciais
de diferenciao em cada processo de
negcio, identificando o valor agregado e o
otimizando.
J Braga (2010) ressalta que a cadeia de
valor permite a compreenso do fluxo de
agregao de valor entre unidades de
negcio interdependentes at consumidor
final, que sob uma perspectiva mais
ampla, retrata uma cadeia de atividades
situadas em uma ou mais organizaes
independentes.
Para Braga (2010),
o conceito de
Arquitetura de Processos representa o
detalhamento, ou o desdobramento de
uma cadeia de valor para os nveis ttico e
operacional.
Esta
definio
esta
diretamente relacionada aos conceitos das
abordagens
de
Business
Process
Management e de Business Performance
Management,
que por sua vez do
robustez a proposio de abordagem de
modelagem e priorizao de Corr et all
(2011).
Neste sentido, para os casos em que a
concepo da soluo de BI passa pela
modelagem dimensional, Hughes (2012)
surge como um complemento a abordagem
proposta por Corr et all (2011) e vice-versa.

O QUE EXISTE DE MELHOR / MAIS


NOVO NO MUNDO SOBRE ADAPTAO
DE METODOS GEIS A BI
A seguir apresento um estudo
bibliogrfico do que se encontro de melhor
e mais novo sobre adaptao de
metodologias geis para BI, buscando
conciliar
diferentes
abordagens
e
fundamentar a definio da abordagem a
ser aplicada, assim com a proposio do
modelo de avaliao qualitativa e
quantitativa a sua aplicao.

Aplicao de Mtodos geis a Projeto


de BI/DW:
Iniciamos analisando a obra de Hughes

(2012), que trata das questes de gesto


de projetos de BI de acordo a adaptao do
mtodo Scrum.
O autor inicia a adaptao estabelecendo
os pilares de sua abordagem, atravs de
um conjunto de prticas geis, que visam
atender a certos objetivos na busca de
resolver problemas crucias respectivos a
natureza singular de projetos de BI
relacionados,
sobretudo,
ao elevado
custo, baixa velocidade de entregas e ao
desconhecimento dos usurios de negcio
daquilo que de fato desejam ter, at que
vejam algum produto disponvel em
produo.
De acordo com a Figura 2, partindo do fato
de que quanto maior for complexidade
das demandas de integrao e tratamento
de dados maior ser a complexidade de
adequao de mtodos geis ao BI,
Hughes (2012) subdivide sua obra em trs
partes:
Na primeira parte so apresentados os
alicerces dos mtodos iterativos e
incrementais, de que forma estes se
diferenciam dos mtodos tradicionais e
como um Scrum genrico pode ser
aplicado diretamente a projetos mais
simples de BI,
desde que estes
compreendam apenas os objetos de
interao direta com o usurio, como
relatrios e painis.
Desta forma
Hughes (2012) busca introduzir o leitor
na aplicao prtica do mtodo Scrum
a um projeto simples de BI, sem
muitas
adequaes
a
serem
empregadas ao mtodo.
J na segunda parte,
o autor
estabelece uma srie de adaptaes
que visam tratar dos projetos que
apresentam demandas de integrao
e tratamento de dados de baixa
complexidade, conduzindo-os atravs
da decomposio de histrias de
usurio, provenientes da aplicao do
mtodo Scrum genrico, em histrias
de desenvolvimento e estas, por sua
vez, em tarefas de desenvolvimento,
que so ento empacotadas em um
srie
incremental
de
entregas
aceitveis pelos usurios.
A parte trs conclui a obra atravs da
exposio de uma abordagem de
adaptao que torna o processo
colaborativo gil mais aderente a
projetos que apresentam grandes
desafios de integrao e tratamento de
dados, assim como de sua evoluo.

10
Figura 2. Exigncias de adequao do mtodo X Complexidade de integrao de dado

Fonte: Hughes (2012, p.21)

De fato, Hughes (2012) busca definir uma


abordagem mais abrangente para a
adaptao de mtodos geis a todo o ciclo
de vida de um projeto de BI. O autor ainda
esboa a ideia e estrutura de uma segunda
obra, ainda no publicada, que visa
abordar o ciclo de vida do produtos de BI
tratando de todos os aspectos da
adaptao do mtodo para toda a
organizao.
No entanto, Hughes (2012) no detalha os
aspectos tcnicos de BI, declarando que
praticamente nada muda neste campo,
sendo apenas necessrio o empregos de
tcnicas de monitoramento e tratamento de
eventuais dbitos tcnicos, assim como
maior nfase aos testes, que tem de ser
mais
integrados
ao
processo
de
desenvolvimento,
portanto
mais
padronizados, automatizados e aplicados
desde o inicio do clico de desenvolvimento
e no apenas ao seu final como ocorrem
nos mtodos tradicionais.
De acordo com Hughes (2012), Collier
(2011) e Corr(2011),
estes dbitos
tcnicos so comumente decorrentes de
escolhas de
desenho
de
soluo
inadequados as necessidades futuras em
funo da eventual falta de uma viso
abrangente ou por erros tcnicos da equipe
de projeto, sobretudo, na conduo de
especificaes que no atendem as
exigncias de uma cobertura 80/20, erros
no
desenvolvimento
identificados

tardiamente ou quando presses por prazo


ou performance so privilegiadas em
detrimento da qualidade.
Tanto Hughes (2012) e Collier (2011)
recomendam a adoo do TDD (TestDriven Development) para a integrao dos
testes ao processo de desenvolvimento
assim como a sua automao, tornando
possvel a abordagem evolutiva ao fornecer
meios confiveis e eficientes para suportar
a soluo de BI, permitindo que defeitos
no se acumulem, reduzir o dbito tcnico,
tornar a verificao da qualidade do
produto e sua comunicao um processo
frequente.
Para tal,
Collier (2011) recomenda a
dedicao de iteraes especificas para
tratamento dos dbitos tcnicos, ou alocar
uma porcentagem de tempo em cada
iterao para este fim. J Hughes (2012)
incorpora em sua abordagem processos
voltados a monitorao,
identificao,
priorizao e correo o mais breve
possvel os dbitos tcnicos ao longo das
iteraes, estabelecendo tcnicas e ciclos
de procedimentos para a conduo de sua
correo de acordo com as premissas
geis, tratando-os de acordo com a sua
complexidade e momento dentro de cada
iterao.
A seguir a Figura 3 permite visualizar um
diagrama que resume a abordagem
Hughes (2012) para adaptao do mtodo
gil na conduo de projetos de BI.

11
Figura 3. Viso Geral da Proposta de Adaptao de Mtodos gil a Projetos de BI
Problemas Crticos
Especificaes 80/20

Rapidez na Inicializao

Qualidade da passagem de basto

Comparao entre os mtodos

Test-Driven Development e
Teste Integrado Contnuo

Defeitos por Iterao

Elevar Qualidade
Parceria com o Negocio
Integrada e Colaborativa

Falhar Rpido e
Corrigir Rapidamente

Revises do Cliente
Frequentes
1

Preciso das
Estimativas

Estimativas Baseadas
por Tamanho

Agilidade na
Percepo de Valor

Distribuio de Pontos de Histrias


Qualidade das Estimativas

Pacotes de Trabalho
Pequenos e Homogneos

Iteraes por Time-Box

Distribuio dos Prazos dos Ciclos

Melhorar a Produtividade
dos Programadores

Equipes Auto Organizadas

Burn-up Chart

Prazo de Liberao

Entregar
Constantemente e
Frequentemente

Melhoria Continua

Reduzir os Custos
de Desenvolvimento

Comparao entre os mtodos

Legenda:
Prtica gil

1
Objetivos

Problema Crtico

DW/BI
Muito
Caros
Conector
2 e
Demorados

Mtrica - KPI

Conector 3

Dificuldade
de definir
requisitos
antes de ter
visto algo
em produo

Fonte: Hughes (2012, p.326)

Neste diagrama, direita, podem ser


vistos os principais desafios de projetos de
BI, que dizem respeito aos problemas
crticos e tpicos de projetos de BI
conduzidos sobre tcnicas tradicionais. O
primeiro desafio diz respeito percepo
de que os projetos de BI so muito letos e
caros, j o segundo esta na relacionada
dificuldade dos usurios em definir o que
realmente desejam antes de terem visto
algo em produo.
A esquerda dos desafios, o diagrama
apresenta os principais objetivos a serem
atingidos na aplicao de sua adaptao
de tcnicas geis. Os objetivos definidos
dizem respeito a:

Maior rapidez na inicializao de


projetos;

Elevar a participao do cliente em


revises frequentes;

Falhar rpido e corrigir


rapidamente;

Atingir elevados nveis de


qualidade;

Elevar a preciso das estimativas;

Elevar a agilidade de percepo de


valor;

Promover a melhoria continua;

Entregar constantemente e
frequentemente;

Melhorar a produtividade dos


programadores;

Reduzir os custos de
desenvolvimento.

Atravs deste diagrama, nota-se ainda que


estes objetivos apresentam inter-relaes,
o que deixa claro a dificuldade em atingi-los
sem um adequado planejamento e um
prazo razovel e suficiente para que os
mesmos possam ser calibrados e atingidos
ao longo do tempo.
O prprio autor
destaca que as trs primeiras iteraes
devero apresentar grande dificuldades,
sendo necessrio um forte patrocinador
que compreenda e possa advogar
favoravelmente pela adaptao frente as
questes que surgiram, assim como uma
forte gesto de mudanas, sobretudo junto
a equipe e sua aceitao de adaptao ao
mtodo.
Finalmente, esquerda esto destacadas
as respectivas tcnicas geis sugeridas
para atingimento de cada um destes
objetivos.
A partir deste ponto, fica claro que o
requisito por maior agilidade impacta na
adoo de uma srie de inovaes e
tcnicas geis. Contudo, Hughes (2012)
destaca que no possvel atingir a maior
velocidade possvel de entrega das
solues de BI de uma s vez. Por este
motivo,
o autor inclui noes como
melhoria contnua e entregas constantes e

12

frequentes, o que sugere a adoo de uma


abordagem iterativa,
incremental e
evolutiva.
Alm disso, o autor ressalta que o requisito
de maior velocidade nas entregas impacta
diretamente no desenho e conduo da
soluo, dada as dependncias tcnicas e
de dados, agravando a necessidade de
estimativas ainda mais precisas, o que nos
conduz ao um objetivo de busca contnua
por maiores nveis de qualidade.
Hughes (2012) ainda apresenta, neste
mesmo diagrama, algumas sugestes de
mtricas para medir a eficcia e eficincia
da aplicao da sua proposta de
adaptao, relacionando-os ao que ele
considera serem os principais objetivos e
prticas geis. A seguir apresentado o
resumo das definies de tais mtricas:

Qualidade da passagem
basto (Quality of hand-offs)

de

Mede a qualidade da transferncia de


conhecimento e trabalho entre as
partes envolvidas. De acordo com
Hughes (2012, p.329), Uma melhor
abordagem est em medir o nvel de
satisfao entre as partes envolvidas
com a transferncia do que tentar
definir o que cada transferncia deve
ser. Dois aspectos importantes levam
a necessidade desta medio:
o

As
caractersticas
de
especializao
dos
recursos,
comuns aos
projetos de BI, que resulta
em uma conduo do
pipeline por
frentes de
trabalho;
O requisito de maior
velocidade
para
inicializao
do
desenvolvimento,
que
orienta a equipe a produzir
especificaes mais leves
e focadas em apenas 80%
dos
aspectos
mais
importantes
de
cada
modulo.

Comparao entre os mtodos:


Praticantes de mtodos geis
sugerem pelo menos 40% de
vantagem
sobre
a
produtividade obtida atravs
dos mtodos tradicionais para
um primeiro projeto, apesar de
poder ser atingido 70% caso a

equipe de liderana tenha


significante experincia com
os mtodos de warehousing
geis.
(HUGHES,
2012,
p.334).
No entanto, em outras passagens o
autor ressalta que as primeiras
iteraes podem vir a apresentar
dificuldades que impeam de observar
tais resultados.
Por estes motivos,
importante
estabelecer
uma
medida
do
comparativo entre os dois mtodos,
sendo a quantidade de horas de
programao por objeto de dados de
destino a mais fcil de obter.

Defeitos por Iterao:

Para Hughes (2012),


o tempo
necessrio para a correo de alguns
defeitos pode ser superior ao restante
do prazo para finalizao da iterao.
Neste sentido,
o autor sugere a
adoo
de
grfico
de
barras
acumulativas para rastreamento destes
defeitos, que devem ser agrupados
pela
iterao
em
que
foram
identificados, atribuindo assim maior
visibilidade a gesto destes defeitos e
criando as condies para que a
equipe busque a melhoria continua,
reduzindo tanto o nmero de defeitos
quanto o tempo de sua correo.

Qualidade das Estimativas:


Esta mtrica definida pelo
nmero total de horas de
trabalho
originalmente
estimado,
para as tarefas
contidas nas histrias aceitas
em cada demonstrao de
usurio, divididas pelo total de
horas realizadas por todas as
atividades
includas
na
iterao,
aps subtrair do
numerador as horas estimadas
para cuidar de qualquer dbito
tcnico na prxima iterao.
(HUGHES, 2012 p.330).

Distribuio
Histrias:

de

Pontos

de

Indica o nmero de histrias contidas


no project backlog para cada nvel de
pontuao das respectivas histrias de
desenvolvimento. Com este indicador,
a equipe pode maximizar a sua
velocidade otimizando seu processo
para a pontuao que apresentar maior

13

concentrao, assim como verificar o


quo consistente a mesma est sendo
ao definir as suas histrias de
desenvolvimento,
a partir da
confrontao com os resultados
obtidos.

Distribuio
Ciclos:

dos

Prazos

dos

Mede o nmero de dias desde o


momento em que a equipe pega uma
histria de desenvolvimento do pipeline
ao dia em que a mesma passa pelo
teste integrado. Na medida em que a
equipe amadurece, este prazo deve
diminuir progressivamente, at que ele
atinja um nvel mnimo para cada
tamanho
de
historia
de
desenvolvimento, que passa a ser
referncia do tempo necessrio para
que equipe, j em alta velocidade,
transforme
um
pedido
de
funcionalidade
em
software
funcionando.

Prazo de Liberao:

Mede o nmero de dias desde o


momento em que uma histria
inserida no product backlog e
a
mesma passa pelo teste integrado.

Burn-up Chart:

Grfico
de
barras
verticais
acumulativas que demostra o nmero
de pontos entregues por iterao, mais
o total de pontos de histrias de
desenvolvimento que ainda esto em
progresso na mesma iterao.

Equipes de Projeto de BI/DW gil:


Quanto a formao da equipe de projeto,
para Hughes (2012)
os papeis como
definidos no Scrum so insuficientes,
sobre tudo dado a abrangncia de
conhecimentos e tecnologias envolvidas
em projetos de BI, assim como pelas
especializaes dos recursos disponveis
no mercado.
De acordo com Hughes
(2012),
so necessrios os seguintes
papeis adicionais:

Arquiteto do Projeto:

Responsvel pela entrega da soluo


dentro do prazo e custo esperados,
pela criao e manuteno da viso
geral da soluo, atuando como um
facilitador do projeto comunicando-se
tanto com as reas de negcio quanto

com a equipe tcnica. Dito isto, fica


claro que o Arquiteto do Projeto pode
tambm desempenhar as funes do
Scrum Master,
porm ele deve ir
alm,
focando no adequando
levantamento e entendimento dos
requisitos, desenho da soluo e na
verificao da qualidade dos artefatos
produzidos
pela
equipe,
responsabilizando-se por toda a equipe
e todo o projeto.
Embora os mtodos geis enfatizem
equipes
auto-organizadas
e
colaborativas, dadas as caractersticas
nicas de projetos de BI, este recurso
deve ter algum nvel de poder sobre os
demais integrantes, preferencialmente
no por uma hierarquia formal e
declarada, mas sim devido a sua
experincia e conhecimento.
De
acordo com Hughes (2012),
esta
caracterstica

fundamental,
sobretudo quando as equipes no
trabalham como esperado, o que
comum nas primeiras iterao de
projetos,
requerendo um liderana
mais forte do Arquiteto de Projetos, o
que tambm seria facilitado caso haja
uma formalizao de sua autoridade no
que diz respeito ao rumo do projeto ou
de todo o programa de BI, inclusive
sobre o Product Owner.

Modelador de Dados:

Deve possuir vasto conhecimento e


experincia em mtodos de arquitetura
para desenho e anlise de dados.
Antes mesmo de projetar o modelo de
dados de cada um das camadas
tcnicas de bancos de dados
necessrias, o modelador de dados
deve atentar para que o desenho da
camada semntica esteja claro e que
tenha tratado de todos os conflitos
entre as definies de negcios das
diversas reas, dado que esta camada
deve ser construda de acordo com a
viso e definies do negcio e ser a
camada que de fato ser acessada
diretamente pelos usurios.
Este recurso deve atuar como um
consultor especialista,
capaz de
orientar a equipe no adequado
balanceamento dos aspectos tcnicos
de modelagem de dados entre o
paradigma de um nico DW (data
warehouse), como a viso do todo, e
a sua composio por modelos

14

distintos,
porem complementares,
distribudos
em
camadas
de
arquiteturas com funes especificas
de
estagio,
integrao,
apresentao/dimensional, semntica
e consumo/ dashboards como descritos
em Hughes (2012, p.187).
Alm disso, ao detalhar o papel do
modelador de dados, Hughes (2012)
deixa claro que necessrio a atuao
de um especialista no ramo de
modelagem de DW, no apenas de
dados, visto a suas consideraes
quanto a correta definio de
granularidade e a necessidade deste
profissional estar atualizado em relao
ao emprego de novas e avanadas
tcnicas,
que
continuam em
desenvolvimento,
a exemplo da
abordagem hipernormalizada, como
as propostas sexta forma normal, data
vaulting e a modelagem por ncora.

Analistas de Sistemas:

Responsvel pela especificao das


transformaes a serem aplicadas
tanto sobre a origem quanto sobre o
destino dos dados. Para isto, este
recurso deve compreender os sistemas
de origem e seus requisitos afim de
promover analises de perfis de dados
em pores relevantes dos sistemas de
origem.
O mesmo e responsvel
compreender as histrias de negcio e
os
seus
desdobramento
em
transformaes que conduzam os
dados de uma camada da arquitetura
para a outra,
gerando assim as
especificao de mapeamento de
origens
para
destinos.
Este
profissional ainda deve estar atento ao
ciclo de vida da informao nos
sistemas de origem e as questes que
afetam a qualidade de dados.

Analistas de Testes:

Responsvel por detalhar o plano de


testes de alto nvel gerado pelo
Arquiteto do Projeto. O mesmo deve
atentar ao fato de que em projetos
geis dever haver apenas o mnimo
de documentao,
portanto,
este
recurso dever levantar os junto aos
demais integrantes da equipe os
corretos casos de testes, como por
exemplo, testes unitrios junto aos

programadores,
histrias de testes
junto ao Product Owner e testes
funcionais e no funcionais junto aos
demais membros da equipe residente
do projeto de BI gil. De fato, este
recurso acaba por ser o responsvel
pela padronizao dos testes e por
liderar a equipe a atender tais padres.

Segundo Hughes (2012),


embora se
afirme que os projetos possam ser feitos
com equipes de menor maturidade, o autor
deixa claro que tais papeis adicionais
devem ser preenchidos por pessoal com
vasta experincia em projetos de BI, assim
como
nas
respectivas
tecnologias
envolvidas, sendo mais fcil trabalhar no
aprendizado da adaptao do mtodo em
si do que no profundo conhecimento
tcnico. Com isso, o autor acredita que
seja possvel obter maior xito desta
adaptao,
conseguindo
melhores
resultados em velocidade de entrega,
reduo do dbito tcnico e integridade
entre as solues a serem desenvolvidas.
Hughes (2012) ainda ressalta que no h
necessariamente um indivduo para cada
um destes papeis, mais sim que cada
papel diz respeito a um perfil e conjunto de
funes muito especificas no que diz
respeito aos projetos de BI. Segundo o
autor, tais descries servem mais como
um guia para a seleo da equipe e para a
inicializao da adaptao dos projetos aos
mtodos geis. O autor chama a ateno
ainda para a questo da disposio do
indivduo para a adaptao mudana,
ressaltando que j foram relatados casos
de sabotagem de um dos integrantes, por
relutar em aceitar que projetos de BI
possam ser conduzidos sobre tais
mtodos.
De acordo com Hughes (2012), os papeis
anteriormente descritos junto ao Project
Owner compreende a equipe de liderana
do projeto gil, j os mesmos junto
equipe de desenvolvedores representam a
equipe de projeto e todos compe a equipe
residente.
Embora os projetos geis no definam a
participao de recursos externos, Hughes
(2012) reconhece que existem outros
papeis necessrios ao projeto de BI, mais
que comumente j existem em outras reas
da TI da organizao, compreendendo
funes como DBA,
engenheiro SOA,
Lder de operao e administradores de
plataformas. Tais recursos, denominados

15

pelo autor como Visitantes, devem ser


identificados antes de iniciado o projeto, a
fim de ter a sua participao planejada e
devidamente acordada.

tcnicas geis a fim de se obter


uma modelagem enxuta (sem
trabalho desnecessrio) e eficiente;

Modelagem gil de DW/BI:


Outra linha de pensamento d mais foco
aos aspectos da arquitetura de soluo e
ao desenho fsico do modelo de banco de
dados,
com o objetivos de reduzir e
controlar o dbito tcnico. Neste caso mais
de uma autor, apoia-se em Martin Fowler,
um dos criadores do manifesto gil. Fowler
(1999) ressalta que a atividade de desenho
no tratada, dentro de um framework
gil,
como sendo uma etapa do
desenvolvimento anterior a construo. Ela
tida como sendo um processo contnuo,
o qual inter-relacionado construo,
testes e entrega do software.
A partir desta definio, o processo de
construo do esquema de bases de dados
deve ento ocorre ao longo das iteraes,
onde mudanas neste esquema so feitas
gradativamente,
de uma maneira
controlada, atravs da utilizao de uma
srie de tcnicas crticas que do suporte a
este modo de desenvolvimento:

Uso de histrias de usurios na


especificao de requisitos

Modelagem de dados evolutiva

Configurao de ambientes
desenvolvimento (Sandboxes)

Administrao dos artefatos de


Banco de Dados

Refatorao de banco de dados

Testes

de

Tanto Ambler (2003),


quanto Collier
(2011), no definem a modelagem gil
como sendo uma metodologia substituta as
existentes,
mas sim uma srie de
complementos
e
suplementos
as
metodologias existentes, tratando-se mais
de
uma
abordagem
colaborativa,
incremental e evolutiva guiada por valores
e princpios geis. Collier (2011, p.151)
destaca, A modelagem gil mais uma
questo de atitude e estilo, no se
caracteriza por ser um processo prdescritivo. Com isso a modelagem gil
tem como principais objetivos:

Definir um meio de colocar em


prtica
valores,
princpios e

Adequar construo de modelos


em metodologias geis que se
baseiam
em
iteraes
e
incrementos funcionais.

A modelagem gil de Ambler (2003) se


apoia nos seguintes princpios:

Entrega de software de valor


funcionando o principal objetivo:
Portanto qualquer atividade que no
contribua
diretamente
com este
objetivo deve ser questionada e
evitada, caso no possa ser justificada
de maneira adequada. Na viso de
Ambler (2003), ao contrrio das de
Corr et all (2011), os modelos no so
produtos a serem entregues,
so
artefatos
que
suportam
o
desenvolvimento,
o que pode ser
estendido a qualquer documentao,
logo, no servem com indicadores de
progresso em um projeto.

Viabilizar a prxima iterao deve


ser um objetivo secundrio:
A soluo de BI/DW deve ser
desenvolvida com os olhos para o
futuro, contudo no deve tentar cobrir
todas as possibilidades deste futuro,
mas sim focar em uma soluo robusta
e extensvel.

Leveza no desenvolvimento:
Neste caso,
deve-se modelar e
documentar apenas o suficiente para
que o desenvolvimento possa ocorrer.
Qualquer documentao que mantida
dentro do projeto deve sofrer
manuteno com o tempo,
pois
ocorrem mudanas no ambiente, o
qual estes artefatos representam.
Neste ponto, Ambler (2003) ressalta
que deve ser mantido um equilbrio
entre a perda de agilidade e a
vantagem de dispor de um modelo que
representada a informao de uma
maneira mais abstrata.

Mudanas so bem vindas:


Neste ponto Collier (2011, p.151)
destaca, Mudanas so inevitveis!
Antecipe-as e modele para isso. No
espere que o seu desenho esteja
completamente certo da primeira vez e
nem por todo o tempo.

16

Uma abordagem incremental permite


que o processo de desenvolvimento
seja
adaptvel
a
mudanas,
viabilizando o tratamento de grandes
mudanas atravs de uma srie de
pequenas
modificaes
nas
funcionalidades de uma soluo. No
que tange a modelagem,
Ambler
(2003) ressalta que primordial que ao
modelar no se tente representar toda
o problema de uma s vez, ou se ater
a todos os detalhes inicialmente,
criando um modelo que englobe todos
esses aspectos. Ao invs disso, o
autor sugere o desenvolvimento de um
modelo pequeno e detalhado que
possam evoluir com o tempo.

Crie mltiplos
necessrio:

modelos

quando

Para Collier (2011), o modelador deve


estar preparado para prover mltiplos
modelos em paralelo,
caso seja
necessrio,
a fim de atender
comunicar um determinado pblico, ou
cobrir uma tcnica de modelagem
especifica necessria tecnicamente ou
para uma melhor comunicao,.

Simplicidade:
Neste ponto, Ambler (2003) apoia-se
na viso de simplicidade de Beck
(1999), onde ele afirma que, na
maioria das vezes, a soluo mais
simples funciona da melhor maneira,
devido a ela ser simples, de fcil
implementao.
Portanto
a
modelagem no deve sobrecarregar o
sistema
com
esquemas
de
complexidade elevada. Esse princpio
se traduz na prtica de modelar da
maneira mais simples os requisitos
existentes e refatorar o sistema no
futuro para acomodar os requisitos que
evoluram.

Certifique-se
da
qualidade
trabalho executado:

do

Collier (2011,
p.151) destaca,
Modelos de alta qualidade so
elegantes e ricos de informaes uteis,
no sendo aceitvel que sejam
incompletos,
inconsistentes
ou
desleixados.

compreensveis.
Ou seja,
na
modelagem deve ser respondida a
questo se para modelar para
entender ou modelar para comunicar
algo.

Modelagem Incremental:

Modelar com propsito:


Aqui o foco esta em privilegiar software
funcionado
a
documentaes

Maximize o investimento junto aos


Stakeholders:
Envolva os stakeholders o mximo
possvel em todo o processo de
modelagem, isto trar transparncia e
maior eficincia em atingir as
necessidades dos mesmos.

Obtenha feedback rapidamente:


Compartilhe o modelo o mais sedo e
frequentemente quanto possvel. A ter
uma verso estvel,
publique
formalmente e pea feedback.

J para Corr et all (2011), a modelagem


gil comea por abandonarmos as prticas
de Big Design Up Front (BDUF), tpicas
dos mtodos tradicionais, e passaremos a
adotar uma abordagem que visa capturar
apenas o nvel de complexidade suficiente
a desenvolvimento da soluo,
sem
perder a viso nica,
ou do todo,
comumente denominadas por Just Enough
Desing Upfront (JEDUF), durante o inicio
das iteraes, e por Just-In-Time (JIT) ao
longo de cada interao.
Para tal, Corr et all (2011) iniciam se
apoiando
nas
definies
anteriores
descritas de Ambler (2003) e transcorre
com os benefcios de sua adoo ao
projeto de DW/BI, Corr et all (2011, p.20)
ressaltam que:
o grande objetivo da
modelagem gil deve ser balancear a
modelagem sob a perspectiva JEDUF e JIT
de forma a reduzir o retrabalho no desenho
de soluo, buscado assim minimizar
potencias dbitos tcnicos, ao passo que,
tambm acelere e proporcione constncia
ao processo de entregas das solues.

Refatorao Aplicada ao BI/DW:


Fowler (1999, p.85) descreve a tcnica de
refatorao como sendo: Uma maneira
disciplinada de reestruturar o cdigo em
pequenos passos de cada vez. Portanto,
a prtica de refatorao suporta a
abordagem evolutiva de desenvolvimento,
evoluindo o cdigo fonte de uma aplicao
atravs da implementao de pequenas
mudanas nele, feitas no decorrer das
iteraes do projeto.

17

Para Collier (2011), a refatorao serve a


dois propsitos bsicos: Evoluir de modo
seguro design e modelos da soluo; e
eliminar o Dbito Tcnico sem danificar
funcionalidades e componentes que
estavam funcionando previamente. Isso
demonstra
maior
preocupao
com
desenvolvimento iterativo, do que em o
trabalho em andamento apresentar efeitos
adversos no que j foi construdo.
J para Ambler et all (2006, p.130), o
principal aspecto da refatorao diz
respeito ao fato do cdigo manter o
comportamento
semntico
aps
as
modificaes, de modo que, no so
adicionadas ou removidas funcionalidades,
objetivando apenas a melhoria do design
do cdigo j existente.
Contudo, a refatorao de banco de dados
um processo mais complexo se
comparado a de cdigo-fonte,
j que a
semntica dos dados existentes deve-se
manter inalterada. Isso se torna um fator
crtico quando somada a possibilidade de
uma base de dados poder possuir um
elevado grau de acoplamento com outras
aplicaes que a utilizam,
sendo que
qualquer mudana nessa base se refletiria
no funcionamento destas aplicaes.
Com isso, segundo Ambler et all (2006),
uma refatorao de banco de dados deve
preservar o funcionamento de qualquer
aplicao que utilizem a base,
sendo
muitas vezes necessrio um perodo de
transio, onde os esquemas atualizados
e antigos de banco de dados funcionem em
paralelo, e, onde a mudana de acesso
feita gradativamente.
Collier (2011) ainda ressalta que as
prticas de refatorao de banco de dados
estabelecidas por Ambler (2003) so
aplicadas diretamente ao conceito de DM
evolutivo.
Visto isso,
a prtica de
refatorao aplicada as bases de dados a
serem estruturadas,
para permitir o
desenvolvimento adaptativo e incremental
dessas solues.
Collier (2011)
acrescenta que a refatorao no se
aplicam apenas ao desenvolvimento, mas
tambm em solues em produo.
Neste sentido, Ambler et all (2006) deixam
mais claro alguns fatores que indicam a
possvel necessidade de refatorao de
esquemas de dados em produo:
Resistncia
a
mudanas
nos
esquemas, por parte da equipe, de
um dbito tcnico corrigvel;

Duplicidade de dados com possveis


inconsistncias;
Colunas com
diferentes;

vrios

propsitos

Colunas
inteligentes
podem
apresentar complexas regras de
decodificao para gerar valores com
significado;
Tabelas utilizadas para armazenar
tipos diferentes de entidades podem
significar vulnerabilidades no modelo
de dados;
Tabelas com nmero excessivo de
linhas, acarretando em problemas de
desempenho;
Tabelas com nmero excessivo de
colunas, faltando coeso, tornado a
tabela sem propsito definido e
armazena
dados
de
diversas
entidades.
Especificamente para o ambiente de
DW/BI, Collier (2011, p.163), acrescenta
os seguintes fatores que indicam a possvel
necessidade de refatorao de esquemas
de dados em produo:
Objetos de ETL complexos, com
muitos caminhos e complexos ns de
transformao, dificultando a sua
manuteno
e
identificao
de
problemas;
Longos mdulos de SQL, PL/SQL e
similares;
Dimenses no conformes gerando
sobreposio
de
informaes,
inconsistncias e redundncia;
Uso
indiscriminado
de
views
materializadas, pois podem ofuscar o
modelo do DW/BI, distanciando os
usurios do modelo implementado e
dificultando sua compreenso;
Solues de BI/DW que acesso
apenas diretamente as tabelas,
subutilizando materializadas views,
apresentam
grandes
riscos
de
fragilidades. A recomendao fazer
uso de uma seleo de views
materializadas de forma a balancear
performance, custos para mante-las
e flexibilidade de acesso as tabelas;
Excesso
de
confiana
na
documentao da soluo de BI, que
no so facilmente compreendidas
sem o suporte das mesmas.

18
Figura 4. Processo iterativo de refatorao
1. Confirmar a necessidade da refatorao

10. Anunciar a concluso


da refatorao

2. Escolher a soluo de refatorao


mais adequada

9. Controlar a verso do trabalho


3. Elaborar a transio do
esquema original
8. Executar todos os testes
de regressivas
4. Testar antes, durante e depois
7. Refatorao de programas externos
que acessam o banco de dados
5. Alterar o esquema do
banco de dados

6. Migrar dados
Migrao
necessria?

Fonte: Ambler et all (2006)

A Figura 4 acima apresenta o diagrama do


processo de refatorao iterativo proposto
por Ambler et all (2006), descrito a seguir:
1. Confirmar
a
refatorao:

necessidade

da

Toda e qualquer refatorao tem de ser


justificada por necessidade de negcio e
o custo de sua mudana deve ser
inferior ao benefcio gerado para
atendimento a referida necessidade.
2. Escolher a soluo de refatorao
mais adequada:
Dado que sempre a mais de uma
soluo possvel, deve-se avaliar qual a
refatorao mais adequada para cada
caso. Alm disso, deve-se garantir que
a nova funcionalidade j no exista em
alguma outra parte do sistema.
3. Elaborar a transio do esquema
original:
Este passo opcional.
Quando a
soluo de BI/DW j esta em produo
a muito tempo, podem haver mltiplas
solues
acessando
o
mesmo
esquema, banco, ou camada semntica,
o que dificulta a transio das solues
para o novo desenvolvimento alvo da
refatorao,
sendo necessrio um
perodo de transio para o esquema
que est sendo alterado, durante o qual
deve coexistir ambas as solues,
antiga e refatorada, para que os

desenvolvedores tenham tempo para


alterar/refatorar todas as solues.
4. Testar antes, durante e depois:
Um conjunto de testes deve ser
elaborado e executado at que a
refatorao
de
banco
seja
completamente implementada, sendo
necessrio testar todos os aspectos
relacionados alterao, inclusive os
programas externos que tenham acesso
ao esquema de dados refatorado, tendo
ou no sido alterados.
5. Alterar o esquema do banco de
dados:
Trata-se de efetivamente construir a
refatorao do esquema de banco de
dados.
6. Migrar dados:
Muitas das refatoraes de dados
requerem algum processo especial de
tratamento nos dados j armazenados
no banco, eliminar inconsistncias ou
simplesmente mover dados de um local
para outro.
7. Refatorao de programas externos
que acessam o banco de dados:
Alteraes no esquema do banco de
dados podem exigir alteraes nos
programas que acessam a parte
alterada do esquema.

19

8. Executar todos
regressivas:

os

testes

de

Trata-se de proceder com os testes


regressivos, garantido que a refatorao
esta corretamente implementada, ou
identificando at que ponto/parcela da
mesma j se encontra correto, sem
gerar anomalias as funes e dados
pr-existentes.
9. Controlar a verso do trabalho:
Para toda a soluo importante que
haja um eficiente controle de verses de
todos os artefatos envolvidos.
10.Anunciar a concluso da refatorao:
Todas as equipes que utilizam o banco
precisam ser comunicadas sobre o
trmino da refatorao e qual foi o seu
escopo/resultado.
Para a implementao da refatorao,
Ambler (2003, p.182) prope que seja feito
uso de um ambiente de desenvolvimento
especifico, para cada equipe de projeto e
para cada refatorao, onde,
tanto
aplicao quanto o banco de dados devem
estar presentes,
permitindo tanto
desenvolvimentos e testes unitrios para
cada
modificao,
quanto
testes
integrados e regressivos.

Aplicao de Mtodos geis as Fases


que Antecedem o Projeto:
Na adaptao de um mtodo gil ao
planejamento do programa de BI/DW e
conduo dos seus projetos, Corr et all
(2011) tambm fazem uso do Scrum e do
XP,
inserindo aos mesmos a sua
abordagem de modelagem colaborativa,
incremental e iterativa,
viabilizando a
aplicao destes mtodos as fases
anteriores ao projeto em si.

Identificando e Desdobrando Histrias


de Usurios:
Quanto estratgia a ser adotada para
identificao das histrias de usurios,
segundo Hughes (2012, p.139):
A estratgia mais comum da
comunidade
de
desenvolvedores geis ao
escrever as histrias de
usurios esta baseada em no
se aventurar muito longe de
quem, o qu e por que,

uma vez que onde e quando


deveria ter precedido o projeto
e como deve ser adiado at
que a histria entra em
desenvolvimento..
Hughes (2012, p.140) embasa sua posio
ressaltando a complexidade de se tratar
estas questes dentro do ciclo de
desenvolvimento, onde nem sempre o
product owner ter conhecimento de todo o
processo de negcio,
desconhecendo
onde e quando, ou fazendo com que a
equipe cai rapidamente em discusses
interminveis de como, sendo um esforo
mais adequado a projetos de reengenharia
de processos de negcio. O autor finaliza
reconhecendo que uma dupla de lideres da
equipe pode vir a trabalhar na modelagem
de alto nvel destes pontos durante as story
confereces, mas refora que isto deve ser
um objetivo secundrio, mantendo-se o
foco em Who, What e Why.
Em uma abordagem de modelagem mais
nova,
Corr et all (2011) tratam da
adaptao do mtodo gil aplicada
inclusive aos estgios anteriores ao dos
projetos em si.
A base da proposta de Corr et all (2011)
recai sobre o desenho de BI/DW a luz de
tcnicas de modelagem dimensional
colaborativa, o que permite a descoberta e
priorizao das
iteraes sob a
perspectiva de histrias de dados, que
descrevem os eventos e dimenses de
negcio capturados diretamente em um
quadro branco, sob a forma de exemplos
de dados dos de acordo com uma
sequncia e logica definida pelos 7Ws ou
5W2H (Who, What, When, Where , How
Many , Why e How).
Corr et all (2011) descrevem em detalhes
seu mtodo de Business Event Analysis &
Modeling (BEAM), que tem por foco uma
abordagem gil para a modelagem
dimensional, com a finalidade de melhorar
a comunicao entre os designers de DW,
equipe de projeto e todas as demais partes
interessada, tornando-as mais interativas
atravs de um processo de modelagem
mais inclusivo e colaborativo. Com isso,
Corr et all (2011, p.21) afirmam que O
resultado que todo mundo pensa
dimensionalmente desde o incio!.
A seguir a Tabela 1 resume cada um dos
7Ws, e as Figuras 5 e 6 demonstram os
diagramas com a sua sequencia lgica e
layout para uma conduzir a modelagem
dimensional de forma consistente:

20
Tabela 1. Descrio dos 7Ws
7Ws

Tipo de dado

Exemplo

Who (Quem)

Pessoas e Organizaes.

Empregados e Clientes.

What (O que)

Coisas.

Servios, produtos e insumos.

When (Quando)

Tempo

Datas, horas e momentos.

Where (Onde)

Localizaes.

Endereos e estabelecimentos

Why (Por Que)

Razes e causalidades.

Promoes e temporadas

How (Como)

Identificadores de transaes
e cdigo de status.

Nmero da ordem de pedidos e status


das ligaes

How Many (Quanto)

Medidas e indicadores de
performance

Faturamento, Volume de vendas e


quantidade de clientes

Fonte: Corr et all (2011, p.31)


Figura 5. Fluxograma com a sequncia dos 7Ws

dimensional, o mesmo no aprofunda nas


questes da arquitetura, deixando isso
para Kimball et all (2004) em referncia
direta a sua obra.
A partir desta referncia, Corr et all (2011,
p.96), afirmam que:

Fonte: Corr et all (2011, p.32)


Figura 6. Layout para modelagem dimensional
consiste

Fonte: Corr et all (2011, p.155)

Construo Iterativa Requer Ateno


Arquitetura:
Como Corr et all (2011) focam
essencialmente nas questes tcnicas do
processo colaborativo de modelagem

A busca por atingir o principio


gil de entregas de valor
frequentes e antecipadas de
software em funcionamento,
frequentemente faz com que
arquitetos e designers geis
sejam tentados a limitar o
escopo de cada release aos
termos respectivos a somente
os processos e reas de
negcios envolvidas".
Infelizmente,
apesar dessa prtica
conduzir a entregas rpidas e de valor,
departamento a departamento,
essas
conduzem o desenho da soluo para
formao de silos de DMs, representados
na Figura 7,
que posteriormente se
apresentam como dbitos tcnicos e
solues no sustentveis.
Para evitar a formao de DM em silos e
para a reduo do dbito tcnico, Corr et
all (2011) determina que os designers e
arquitetos devem estar atentos a que o
modelo atenda tanto o desenvolvimento da
iterao atual quanto das futuras. Para
isso, Corr et all (2011, p.97) acreditam que
ser suficiente a adoo dos conceitos de
conformidade e da arquitetura definidos por
Kimball (2002),
sendo necessria a
identificao e definio de todas as
dimenses e mediada conformes, como
pode ser visualizado atravs da Figura 8.

21
Figura 7. Dbito Tcnico Gerado por Silos de DMs

Fonte: Corr et all (2011, p.96)


Figura 8. Reapresentao da Bus Architecture de KIBALL (2002)

Fonte: Corr et all (2011, p.101)

Alavancando Princpios e Valores geis


na Modelagem Dimensional:
Para
o
cumprimento
do
princpio
maximizao do trabalho no feito, assim
como no atendimento do valor gil de
Software
funcionado
acima
de
documentaes abrangentes, Corr et all
(2011, p.25) propem o emprego de cinco
(5) tipos de diagramas e os apresenta em

detalhes, especificando o seu uso, nvel


do tipo de modelo de dados empregado,
audincia e principal captulos onde os
mesmos so detalhados em sua obra. A
Tabela 2 a seguir apresenta apenas os
diagramas e respectivo resumo de seu
emprego.

22

Tabela 2. Diagramas propostos pelo mtodo BEAM

Diagrama
Tabela BEAM

Grfico de Hierarquia

Emprego
Modelagem dos eventos de negcio e suas dimenses de anlise,
uma por vez, fazendo uso de exemplos de dados que documentam
os seus detalhes atravs da exposio dos 7Ws.
Descoberta dos padres de hierarquias e sua relao com as
dimenses e atributos para a anlise dimensional.
Contribui tambm para a identificao de requisitos tcnicos para a
definio de percursos de anlise (drill) e nveis de agregao.

Linha do Tempo

Matriz de Eventos

Esquema em Estrela
Aprimorado

Descoberta a cerca dos aspectos relacionado s sequencia dos


processos,
ou relacionamento entre eventos,
identificando
medidas de tempo como a durao e de performance.
Documenta a relao entre os eventos e as dimenses de anlise,
atravs de uma matriz onde os eventos so dispostos de acordo
com a sequncia da cadeia de valor. A mesma viabiliza a viso
geral de todo o DW, ou de mltiplos DMs, permitindo o reuso das
dimenses de anlise e o registro de seu grau de conformidade.
Permite a visualizao dos modelos em fora dimensional, assim
como a gerao do seu respectivo modelo fsico.
Por aprimorado, compreende-se o emprego das abreviaturas de
definies das propriedades dimensionais e de tcnicas de desenho
propostas em BEAM e no suportadas pelos pacotes de
modelagem de dados.

Fonte: Corr et all (2011, p.25)

Gesto do Programa de BI/DW:


Quanto aplicao da adaptao do
mtodo gil aos estgios anteriores a
definio do projeto de BI em si, ressaltase que a matriz de eventos proposta por
Corr et all (2011) trata-se de uma
ferramenta de modelagem e planejamento,
que documenta as relaes entre os
eventos de negcios e as dimenses de
anlise. A mesma atua como story boards
para o desenho de todo o DW,
apresentando
apenas
os
detalhes
suficientes para auxiliar a identificao dos
processos de maior valor agregado e as
respectivas dimenses deste processo,
assim como o seu uso por outros
processos.
Em virtude do reuso e necessria
harmonizao,
as
dimenses
e
indicadores requerem ateno para a
modelagem em conformidade, o que pode
ser trabalhado na mdia em decorrncia da
priorizao dos eventos de maior valor para
o seu desenvolvimento.

Alm disso, ao listar os eventos nessa


matriz de acordo com uma sequncia de
tempo em que estes ocorrem, assim como
ao registrar as respectivas medidas de
criao e destruio de valores, fica claro
o alinhamento desta abordagem aos
pressupostos da cadeia de valor de Porter
(1985), permitindo tambm a descoberta
de eventos ausentes,
devido
identificao de grandes gaps de valor,
tempo ou aes no fluxo de processos.
Com isso, os arquitetos e designers do
projeto conseguem controlar e melhor
desenvolver as solues de forma alinhada
aos processos de negcio, facilitando o
processo de priorizao das iteraes a
serem desenvolvidas, tanto por critrios
mais objetivos de valor agregado, quanto
por subjetivos relacionados a identificao
de alinhamento com a estratgia do
negcio.

23

De acordo com Corr et all (2011, p.118,


pargrafo 2),
no caso da adoo do
Scrum, a equipe tende a supor que toda a
priorizao deve ser conduzida apenas
junto ao product owner, que gerencia o
respectivo product backlog. Entretanto
essa
abordagem
no
supre
as
necessidades de priorizao de um
programa de BI que contemple toda a
organizao. Por esse motivo, Corr et all
(2011)
sugerem
que
um
time
representativo, com reconhecida liderana
e poder na organizao atue como um
representante do product owner.
Para a priorizao das iteraes, Corr et
all (2011, p.117 p.119) estabelecem um
conjunto de regras a serem conduzidas
atravs de uma reunio, por ele
denominada de jogo de ranqueamento de
eventos.
Esta reunio tem incio
questionando-se aos stackholders
importncia de cada evento, segundo as
seguintes regras:

Todos os eventos devem receber


notas;

As notas seguem uma pontuao


incremental de 100 em 100,
permitindo gaps de pontuao que
viabilizaram o desempate atravs
de notas obtidas por outros
critrios;

A distncia revelar apenas a


diferena de importncia atual
entre os eventos, no sendo uma
medida relativa de valor ao negcio
em si;
Todos os eventos devem possuir
uma nota diferente uns dos outros,
exceto:
o

Eventos
que
j
foram
entregues
em
iteraes
anteriores recebem nota zero;

Eventos cuja importncia atual


no significativa devem
receber nota 100.

Segue-se a mesma questionando-se a


atribuio de notas de importncia para
cada dimenso envolvida com os eventos
identificados,
atravs das seguintes
regras:

As notas devem ser incrementais


na ordem de 5 ou 10 pontos de
importncia;

As dimenses conforme devem,


obrigatoriamente,
receber notas
maiores do que s no conformes;

As
dimenses
devem
ser
ranqueadas com notas superiores
a nota de importncia do respectivo
evento relacionado;

Qualquer dimenso deve ser


ranqueada com uma nota de
menor importncia do que a maior
nota do evento no utilizado mais
prxima da nota do respectivo
evento associado dimenso em
questo;

atribuda nota zero as dimenses


que j tenham sido entregues em
iteraes anteriores;

Caso a importncia do evento


mude,
todas as notas de
dimenses a ele relacionadas
devem ser alteradas.

Ao final,
obtm-se a priorizao dos
eventos em respectivas dimenses de
forma ordenada em um nico product
backlog.
Aps essa reunio, um product owner,
designado para a iterao priorizada, pode
ainda promover ajustes na mesma baseado
nos resultados dos data profiling e no
retorno das estimativas e da execuo das
atividades da equipe de desenvolvimento.
Corr et all (2011) ainda determinam que a
essa lista tambm deve ser acrescido a
lista de requerimentos de relatrios e
painis,
que devem tambm sofrer
priorizao. Essa priorizao pode vir a ser
conduzida pelo comit anterior ou apenas
pelo product owner responsvel pela
iterao devidamente priorizada pelo
processo anterior. De acordo com Corr et
all (2011, p.119),
a priorizao dos
requisitos de relatrios e paineis deve ser
atribuda
antes
do
incio
de
desenvolvimento,
para a qual so
concedidas notas decrementais a nota do
respectivo evento a ela associados, na
ordem de 5 ou 10 pontos de importncia.
Antes de conduzir o incio do planejamento
da interao priorizada, o autor indica a
necessidade de se proceder antes com
uma reviso minuciosa do modelo e da
matriz de eventos,
iniciando pela
identificao de suas origens de dados,
seguindo-se pela aplicao de tcnicas
geis de data profiling e confirmao dos
resultados com a adequao do modelo. O

24

resultado servir de base tanto para


estimativas, atravs de planning poker,
quanto reviso das prioridades,
caso
necessrio, assim como para dar cincia
aos stakeholders do que ser realmente
possvel obter com a prxima iterao.
De posse do modelo,
estimativas e
prioridades revisadas a equipe deve definir
o Sprint backlog, conduzindo um Sprint
planning meeting a fim de gerar uma lista
de tarefas para conduo do projeto,
revisando junto a equipe as estimativas
com base nos detalhamentos destas
tarefas,
com as quais a equipe se
comprometer a entrega-las nesta iterao.
Sobre a perspectiva do princpio de
maximizao do trabalho no feito e para
o atendimento ao valor de Software
funcionado acima de documentaes
abrangentes, Corr et all (2011) tambm
recomendam que toda a soluo seja
prototipada o mais breve possvel, j com
o objetivo de viabilizar a validao do
desenho atravs da anlise de dados reais,
disponibilizados atravs da ferramenta de
BI.
Como Corr et all (2011, p.159)
ressaltam, No perca tempo elaborado
especificaes e mocking up de relatrios e
paineis em Word ou Excel, quando voc
dispuser do esquema de dados, amostra
de dados,
ferramentas de BI e
stakeholders para avaliar os resultados
como opo..

RESOLVENDO O PROBLEMA LUZ


DAS TEORIAS
Dadas
as
consideraes
expostas
anteriormente, a proposio de adaptao
de mtodo a ser aplicada aos projetos de
BI passa principalmente pela combinao
das proposies de Corr et all (2011) e
Hughes (2012), somadas as definies do
desenho e desenvolvimento evolutivo de
Ambler (2003) e Collier (2011).
O diagrama apresentado pela Figura 9 na
pgina seguinte, busca apresentar o que
essencial para a formulao de uma
abordagem de adaptao que unifique de
forma
estruturada
as
anteriores,
apresentando os problemas crticos a
serem tratados, as respectivas prticas
geis, os objetivos a serem atendidos junto
aos indicadores de mensurao qualitativa
e quantitativa dos resultados ao buscar
equacionar
os
problemas
cruciais
identificados em projetos de BI.

A primeira parte do diagrama trata-se de


uma sntese as proposies de Corr et all
(2011),
com foco na adaptao de
mtodos geis as etapas antecedentes ao
projeto,
promovendo s atividades
necessrias a gesto do programa de
projetos de BI.
Iniciamos este diagrama pelo tratamento do
problema crtico referente percepo de
Burocracia
e
Distanciamento
do
Cliente,
que tanto as abordagens
tradicionais de desenvolvimento de BI
quanto os processos formais de gesto de
demanda e portflio costuma causar.
Para tal, prope-se o emprego de um
mtodo Modelagem Dimensional gil,
proposta por Corr et all (2011), induzindo o
processo
a
empregar
tcnicas
colaborativas para concepo de uma
soluo de BI construda de forma
incremental e iterativa,
suportando os
objetivos de identificao e modelagem
de eventos de negcio e das respectivas
dimenses associadas, capturados na
forma de data stories atravs de sees
de trabalho colaborativas e incrementais, e
medidas pela nmero de eventos e
dimenses identificados.
Ainda sob esta perspectiva, prope-se
tambm o uso da prtica gil de
Prototipao,
que no apenas busca
resolver a este problema crtico, mas
tambm ao problema dos stakeholders
terem Dificuldade de Visualizar e Validar
a Soluo na Fase de Desenho.
Seguindo as recomendaes de Corr et all
(2011), os objetivos de prototipao foram
divididos e sequencializados em ETL,
Desenho e Soluo.

ETL: Tendo identificado alguns


eventos e dimenses atravs de
exemplos, pode-se promover a
anlise orientada das fontes de
dados e a prototipao dos
processos de ETL, permitindo os
testes unitrios e integrados ao
desenvolvimento, que por sua vez
podem ser validados junto aos
stakeholders
atravs
da
confirmao dos resultados dos
dados obtidos contra os exemplos
informados.

Desenho:
Quando a iterao
dispuser do modelo dimensional,
novos prottipos de ETL podem
carregar o modelo de dados o mais
breve possvel,
permitindo a

25

avaliao e validao do desenho


atravs da anlise de seus
resultados em termos de dados,
ao invs da analise do modelo em
si, assim como viabiliza o desenho
final e a estimativa da equipe de
integrao de dados responsvel
pelo
desenvolvimento
dos
processos de ETL.

Soluo: Uma vez tendo sido


validado o desenho, um prottipo
da camada semntica da soluo
pode ser diretamente construdos
sob
a
ferramenta
de
BI,

possibilitando a validao junto aos


stakeholders com apenas foco nos
dados e no seu comportamento
com base nas funcionalidades de
agregao e anlise ad-hoc da
ferramenta. Alm disso, para os
casos
em
que
se
tenha
identificado e priorizado os
requisitos
de
relatrios
e
painis, atravs da tcnica de
Sprint
Planning
Meeting,
prottipos especficos para este fim
podem ser construdos ao invs da
elaborao de mockups para
posterior construo

Figura 9. Adaptao gil unificada a todo o Ciclo de Vida de Solues de BI

26

Os indicadores de prototipao propostos,


medem estes objetivos tanto de forma
qualitativa quanto quantitativa,
sendo
respectivamente o nmero de prottipos
validados, o nmero de interaes com os
stakeholders necessrias para a respectiva
validao assim como o a quantidade de
iteraes decorridas para a sua validao
desde a liberao da primeira verso do
respectivo prottipo.
Outro problema crtico a ser tratado diz
respeito a Identificar Demandas de BI e
Capturar o Nvel de Complexidade
Suficiente sem Perder a Viso nica e
de
Futuro.
Neste
caso,
complementamos a tcnica de Modelagem
Dimensional gil com a tcnica da Matriz
de Eventos e de Matriz DW, a fim de
estabelecer as conexes entre eventos e
dimenses,
verificar
os
seus
desdobramentos e harmonizar os conceitos
a fim de maximizar a conformidade de
dimenses e indicadores.
Aqui
os
principais
objetivos
so
estabelecer a adoo dos conceitos de
conformidade e a adoo de uma
arquitetura de referncia, a fim de que o
modelo atenda tanto o desenvolvimento da
iterao atual quanto das futuras. Para
medir o atingimento destes objetivos
propem-se os indicadores Quantidade de
no Conformidades e Quantidade de
Eventos Afetados por no Conformidades,
que tambm podem ser verificadas contra
os respectivos totais de dimenses e
eventos.
Sendo estas medidas de
caracterstica quanto menor melhor, elas
podem contribuir com a sensibilizao dos
stakeholders para a diminuio das no
conformidades, provendo assim medidas
qualitativas e quantitativas de todo o
processo.
Cabe ressaltar que as tcnicas de Sprint
Planning Meeting e de Planning Poker,
assim como a de Estimativa por Tamanho
tambm so recomendadas para conduo
de todas as sees de estimativas e de
revises de estimativas da equipe tcnica
do projeto.
Sendo a principal medida
qualitativa desta etapa a definio do Sprint
Backlog, e como medidas quantitativas a
medida da Qualidade das Estimativas e de
Burn-up Chart,
tal qual proposto por
Hughes (2012), mas que so aferidas
apenas na etapa de projeto.
No que diz respeito dificuldade de
Priorizar Demandas de BI Atravs de
Critrios Quantitativos e Qualitativos,

sugerimos principalmente a adoo da


tcnica gil de Jogo de Ranqueamento de
Eventos de Negcio, proposta por Coor et
all (2011), seguindo os procedimentos por
ele definidos, que foram transcritos na
seo anterior, para a determinao da
importncia de cada evento de negcio e
de cada dimenso associada.
Os
indicadores primrios de desempenho
desta tcnica, consiste na verificao de
xito da priorizao do product backlog de
acordo com os preceitos desta tcnica.
Uma vez o product backlog priorizado,
tomamos suporte da tcnica de Data
Profiling gil,
com a finalidade de
examinarmos o mais rpido possvel todas
as fontes de dados identificadas dos
respectivos eventos e dimenses que
foram priorizados, tanto para promover a
reviso do modelo de dados e da matriz de
eventos, quanto para que a equipe de ETL
possa prover as estimativas iniciais de
ETL, sendo que para isso, tambm deve
ser feito uso da tcnica de Planning
Poker.
No data profiling, tanto a qualidade dos
dados quanto os comportamentos, regras,
situaes e relaes entre os dados, tal
qual foram informados nas sees de
modelagem colaborativa, devem ser
verificados. O resultado deste objetivo
deve ser medido tanto pela eficincia do
processo de data profiling em si, medindose o tempo decorrido de sua execuo por
unidade de informao,
quanto da
qualidade dos modelos obtidos pelo
processo colaborativo,
verificando-se o
ndice de reviso do modelo, ou seja,
Quantidade de Ajustes/Quantidade total de
objetos
informacionais
modelados
(eventos, dimenses, atributos, regras,
comportamentos e situaes esperadas).
No caso das estimativas, os indicadores
de desempenho devem medir a agilidade
em prover as estimativas na etapa de
anteprojeto, assim como a qualidade das
estimativas na etapa de projeto, de acordo
com o que foi definido em Hughes (2012).
J na segunda parte do diagrama,
apresentada a abordagem de adaptao do
mtodo gil ao BI a etapa do ciclo de vida
de projetos de acordo com Hughes (2012).
No so necessrias muitas alteraes
abordagem de Hughes (2012), apenas
algumas ressalvas e pontos de ateno
que viso tratar da inter-relaes que se
fazem necessrias junto s demais
abordagens.

27

Como principal ponto de entrada na


integrao
entre
as
abordagens,
destacamos a questo de as histrias de
dados poderem ainda ser desdobradas em
histrias de desenvolvimento, de acordo
com as definies de Hughes (2012),
atravs das diferentes camadas da
arquitetura de referencia adotada pela
organizao, com o intuito de prover maior
clareza aos stakehorders quanto aos
requisitos e respectiva complexidades de
integrao e tratamento de dados.
Ainda na viso de Hughes (2012),
o
segundo problema tpico a ser tratado diz
respeito a Dificuldade dos usurios
definirem requisitos antes de ter visto algo
em produo. Deve-se observar que este
problema crtico surge tanto quando
solues de BI so novas para a
organizao, quanto quando so inseridos
novas funcionalidades, ferramentas ou
novos usurios chaves ao programa de BI
j em andamento.
De fato, esta situao est melhor descrita
sob a perspectiva dos desenvolvedores do
BI do que na perspectiva dos usurios. No
entanto, mesmo aps a maturao do BI e
dos seus usurios,
ainda podemos
observar este fenmeno, isto porque o
mesmo tambm se deve a instabilidade e
inovaes do prprio cenrio e processos
de negocio, o que afeta diretamente os
requisitos e a percepo dos usurios,
sendo um fenmeno presente e ainda mais
acelerado nos dia de hoje. Neste sentido,
optamos por alterar este problema crtico
para a perspectiva dos usurios, alinhada
a viso da equipe tcnica, renomeado o
mesmo
para
Instabilidade
e
Mutabilidade de Requisitos.
Esta mudana de nome tambm serve ao
proposito de expandir a questo as
mudanas de requisitos, que afetam as
solues que j se encontram em operao
na produo a longa data, servido assim
tambm como um dos pilares de problemas
crticos a serem tratados na prxima etapa,
de ps-projeto,
A parte final do diagrama, representa a
proposta de adaptao do mtodo gil a
etapa ps-projeto, focada na conduo da
sustentao da soluo assim como de
pequenas melhorias nas solues j em
produo. A mesma visa ainda atender
tambm
a
etapa
de
projetos,
estabelecendo o foco na adoo ordenada
de aes de correo do modelo da
soluo do projeto devido a mudanas nos

requisito. Esta abordagem baseia-se na


sntese das propostas de modelagem gil
de Ambler (2003) e de Corr et all (2011),
somada a sntese das proposies de
refatorao de Collier (2011) e Ambler et all
(2005).
Na medida em que um projeto avana, ou
que o programa de BI avana com a
concluso de seus projetos, os problemas
crticos que tomam maior importncia so
os referentes
a Instabilidade e
Mutabilidade de Requisitos o de que
as Mudanas so Caras e Difceis,
Para tal, a primeira tcnica gil a ser
aplicada
consiste
na
Modelagem
Evolutiva, Incremental, Colaborativa e
com Proposito, de Ambler et all (2005),
com foco no objetivo de obter uma
Modelagem Enxuta e Eficiente, o que de
fato tambm se alinha a tcnica de
Modelagem Dimensional gil proposta
por Corr et all (2011). Para que a mesma
tambm se alinhe a tcnica de Parceria
com
o
Negocio
Integrada
e
Colaborativa, da etapa de projeto, foram
includos os objetivos de Obter Feedback
Rapidamente e o de Adequar e Manter
Soluo,
o que exige que haja
colaborao e um proposito para a
modelagem.
Na medio do desempenho destes
objetivos foram propostos trs indicadores:

Tempo Mdio de Adequao a


Mudana: que mede o tempo
mdio desde a solicitao da
mudana do requisito at o seu
atendimento com xito com a
liberao da refatorao em
produo.

Nmero de Mudanas com xito/


Total de Mudanas Solicitadas:
mede o nvel de adequao as
mudanas

Nmero de Mudanas com xito/


Total de Tentativas:
mede a
assertividade do processo de
subida da refatorao ao ambiente
de produo,
sendo afetado
quando houver necessidade de
reverte-la, total ou parcialmente, e
reprograma-la em outra janela de
subida.

A outra tcnica gil a ser adota consiste na


Refatorao, que visa tanto suportar o
objetivo de Adequar e Manter Soluo,
quanto o de Reduzir Dbito Tcnico,
sendo que para o segundo necessrio

28

tambm estabelecer o
Identificar e Monitorar
Tcnicos.

objetivo de
os Dbitos

Uma vez que a questo de dbitos tcnicos


se diferenciam da questo de instabilidade
e mutabilidade dos requisitos, faz-se
necessrio
incluir
indicadores
de
desempenho especficos a este fim:

Dbitos Tcnicos por Iterao:


para o qual a equipe deve ter
ateno a sua reduo ao logo das
interaes, na medida em que a
equipe e a organizao ganham
experincia com as tcnicas e
conhecimento das solues. Caso
ocorra uma elevao, pode ser um
indicativo de necessidade de
restruturao da equipe, ou da
resoluo
de
gaps
de
conhecimento tcnicos, devido a
por exemplo uma mudana em
alguma tecnologia adotadas.

Dbitos Tcnicos Reduzidos /


Total e Tempo Decorrido at a
Soluo do Dbito Tcnico:
estes indicadores serviram para um
possvel acordo de nvel de servio
operacional, entre a equipe de
projeto, equipe de sustentao e o
Project Owner. Os mesmo faram
com que equipe tenha interesse
em manter os nveis de dbitos
tcnicos baixos e sobre controle.

Quanto aos papeis para composio da


equipe de liderana,
para melhor
integrao das abordagens de Corr et all
(2011) e Hughes (2012),
sugere-se
integrao dos papeis de Arquiteto de
Projeto e de Arquiteto de Dados de Hughes

(2012), junto aos papeis de Analista de


Negcio e Modelador de Dados de Corr et
all (2011),
ento aqui nomeados de
Arquiteto de Soluo e Arquiteto de
Integrao e Dados respectivamente, uma
vez que o mesmos deve atuar em todo o
ciclo de vida dos produtos de BI, e
dependendo das dimenses do programa
de BI, podem liderar outros especialistas.
Caso a organizao disponha de maiores
recursos, ela pode vir a conceder parte
destas
responsabilidades
a
outros
membros da equipe, contudo, recomendase que dentro do possvel exista ao menos
um recurso de maior senioridade em
projetos de BI, que congregue todos estes
conhecimentos e habilidades, de forma a
estabelecer a liderana por mrito e ainda
sim atribuir uma liderana formal ao
mesmo, responsabilizando-o por todo o
programa e respectivos projetos de BI,
como recomendado em Hughes (2012).
Dado os requisito de especializao em
refatorao e nas ferramentas de
integrao da organizao,
tambm
sugere-se a nomeao de recursos
especficos de DBA e de desenvolvedores
de integrao, contrariando a viso de
Hughes (2012) de que estes recursos
sero
apenas
Visitantes.
Esta
recomendao tem por base o fato de que
os mesmos no somente atuaram nos
projetos do Programa de BI, mas que
tambm atuaram na sustentao das
solues entregues, requerendo que estes
desenvolvam tcnicas especificas voltadas
para o BI, assim como as tcnicas geis
de BI, modelagem e refatorao aqui
descritas.

29

CONCLUSO:

Como vimos, as dificuldades na adaptao


dos mtodos geis ao BI existem, mas os
seus benefcios compensam muito as suas
dificuldades, pois h muitos problemas
crticos na sua conduo atravs dos
mtodos tradicionais que so superados
devido a adoo de princpios e valores
geis.

maximizar a quantidade de trabalho que


no precisou ser feito., assim como do
suporte aos valores geis de Interaes e
indivduos
acima
de
processos
e
ferramentas, Colaborao com o cliente
mais que negociao de contratos e
Software
funcionado
acima
de
documentaes abrangentes.

Em primeiro lugar, como visto, Corr et all


(2011) estabelecem o conjunto necessrio
de referncias e prticas que induzem ao
emprego de tcnicas colaborativas para
concepo de uma soluo de BI a ser
construda de forma incremental, iterativa
e evolutiva.

Em terceiro lugar, a contnua seleo de


conjuntos reduzidos e priorizados de
informaes e funcionalidades atravs dos
jogos de ranqueamento de eventos de Corr
et all (2011), oferece uma maior garantia
de que o tempo e os recursos gastos na
sua implementao tero uma melhor
relao de custo / benefcio, j que o
conjunto de informaes e funcionalidades
pouco utilizadas dever ser mnima e os
benefcios tero sido adequadamente
mapeados.

Em segundo lugar,
o processo de
desenvolvimento iterativo obriga uma
seleo constante das informaes e
funcionalidades prioritrias, o que ajuda a
minimizar o problema da equipe gastar
tempo e recursos em desenvolvimentos
que nunca,
ou raramente,
sero
utilizadas, como comumente acontecem
com as abordagens com base em BDUF.
Para isso, essencial o emprego das
tcnicas de modelagem gil e de
prototipao,
uma vez que estas
promovem a ruptura das barreiras entre os
profissionais de BI e stakeholders, que
passam a focar na elaborao colaborativa
de modelos de dados compreensveis e
compilveis, ao invs de documentos de
requerimentos, assim como em prottipos
de relatrios e paineis ao invs de
mockups.
Os pontos anteriores, quando somados
proposta de emprego das tcnicas geis de
data profiling,
permitem no somente
melhorar estimativas, mas acabam por
contribuir para a melhoria da qualidade da
soluo como um todo, visto que regras,
comportamentos e caractersticas dos
dados capturadas na formas de exemplos
podem ser conferidos diretamente contra
os dados reais das origens da futura
soluo.
Alm disso, a proposta colaborativa de
Corrr et all (2011) com o devido emprego
de seus diagramas e ateno a
conformidade de indicadores e dimenses,
contribuem para a captura dos requisitos
essenciais, ao passo que atendem ao
principio de Simplicidade: a arte de

Desta maneira, a abordagem de Corrr et


all (2011) contribuem para a soluo dos
problemas crticos referentes percepo
de Burocracia e Distanciamento do
Cliente e da Dificuldade de priorizar
demandas de BI atravs de critrios
quantitativos e qualitativos, que tanto
as
abordagens
tradicionais
de
desenvolvimento de BI quanto os
processos formais de gesto de demanda e
portflio costumam enfrentar.
Cabe ressaltar que a proposta de 7Ws de
Corr et all (2011) e sua tcnica para
captura de suas histrias de dados viabiliza
a captura de mais detalhes, em menor
tempo e de forma mais estruturada do que
as histrias de desenvolvimento propostas
por Hughes (2012), que cobrem apenas
3W (Who, What e Why) e que so escritas
apenas depois das historias de usurios
terem sido criadas.
Alm disso, os diagramas propostos pelo
mtodo BEAM tambm trazem mais
clareza ao nvel de especificaes 80/20
desejado por Hughes (2012), consistindo
em importantes aceleradores para os
projetos de desenvolvimento de solues
de BI, servindo mais ao propsito de
rapidez na inicializao.
Por outro lado, Hughes (2012) prope a
quebra das histrias de desenvolvimento
em tarefas de desenvolvimento, que por
sua vez devem ser agrupadas em pacotes

30

que permitam quebrar os requisitos de


dados em entregveis aceitveis pelos
usurios nas diversas camadas de
arquitetura necessrias, sendo esta mais
uma complementaridade entre os dois
autores, elevando o emprego de mtodos
geis a projetos de BI.
Deve-se ressaltar que toda a abordagem
de Hughes (2012) da maior cobertura a
conduo do projeto em si, oferecendo
estratgias de conduo assim como
medidas qualitativas e quantitativas do
processo de conduo, da performance
das equipes e dos resultados obtidos com
os projetos.
Portanto, possvel adotar a abordagem
de Hughes (2012) a conduo do ciclo de
vida do projeto sem grandes requisitos de
mudana, reduzindo o tempo de entrega
de verses funcionais da soluo, porm
mantendo-se a ateno conformidade,
as mudanas de requisitos e ao controle
efetivo dos dbitos tcnicos, com isso,
acelerando-se a percepo de valor
atravs da captura de benefcios parciais
rapidamente.
Neste sentido, observa-se que a obra de
Corr et all (2011) pode ser encarada
exatamente como o elo necessrio entre a
fase de gesto do programa de BI e a
conduo do projeto em si, atravs de um
mtodo
adequado
que
permite
a
identificao e priorizao de demandas de
BI, assim com das respectivas iteraes a
serem conduzidas sob a perspectiva de
modelagem de dados dimensional.
Em quarto lugar, a fim de sustentar este
crescimento contnuo das solues atravs
do processo iterativo e incremental, as
metodologias geis tm fundamentos muito
fortes que devem estar presentes no
ambiente de trabalho, pois a experincia
destes mtodos pode ajudar a minimizar os
dbitos tcnicos que podem ocorrer na
implementao de sistemas evolutivos.
Neste sentido, destaca-se que Hughes
(2012) incorpora em sua abordagem
processos
voltados
a
monitorao,
identificao,
priorizao e correo o
mais breve possvel dos dbitos tcnicos
ao longo das iteraes, estabelecendo
tcnicas e ciclos de procedimentos para a
conduo de sua correo de acordo com
as premissas geis, tratando-os de acordo
com a sua complexidade e momento dentro
de cada iterao.

Alm disso, a evoluo da soluo de BI


tem um problema adicional relacionado as
dimenses das tabelas e ao crescimento
de seu modelo e assim como dos seus
dados, tornando as suas evolues mais
difceis e demoradas. Neste sentido, as
tcnicas de bancos de dados evolutivos a
refatorao com base em Ambler et all
(2003 e 2005) tm grande importncia para
todo o ciclo de vida de solues de BI,
onde se faz necessrio grande cuidado
com os dados do banco diante de
evolues em seu modelo, mesmo em
evolues que necessitam de recuperao
de histrico, uma vez que estas podem ser
tratadas em separado de maneira
estruturada e com o devido perodo de
transio.
Por fim,
quanto aos problemas do
processo de adaptao do BI ao mtodo
gil em si, o principal problema a ser
considerado dever ser a adequada escolha
da equipe, sua adaptao e a adaptao
da organizao as profundas mudanas
que se faro necessrias.
Uma vez que a obra de Hughes (2012)
pressupe que j existem histrias de
usurios a serem desdobradas em histrias
de desenvolvimento, fica difcil para o leitor
imaginar um processo de adaptao do BI
gil, sem antes prever a adaptao da
prpria organizao a cultura gil, assim
como por gerir as mudanas que se faro
necessrias para introduzir o BI na
organizao e/ou elev-lo a maiores nveis
de maturidade.
No obstante ao fato anterior, devemos
ainda ter ateno s necessidades de
adaptao em termos de Brasil. Deve-se
observar
que
muitas
organizaes
brasileiras
ainda
consideram
a
implementao de um projeto de BI como
muito complexo, havendo ainda muitas
empresas nos dois primeiros nveis de
maturidade. Alm disso,
a adoo de
mtodos geis e de refatorao de modelo
de dados pelas organizaes brasileiras
tambm ainda tmida.
Neste sentido, uma vez que as histrias de
dados de Corr et all (2011) esto inseridas
no seu mtodo iterativo, incremental e
colaborativo, e
so mais ligadas ao
processo de modelagem dimensional,
estas contribuem tanto para a formao da
cultura de BI,
fazendo com que a
organizao pense dimensionalmente,
quanto promovem o elo de ligao e devido

31

processo de inicializao aos projetos de BI


a serem conduzidos sob a perspectiva gil.
Em relao equipe, de maneira anloga
s dificuldades encontradas pelos mtodos
geis em outras aplicaes, as pessoas
detm formaes culturais diferentes e
costumam oferecer resistncia a utilizar
novas ideias que fujam aos conceitos
tradicionais, formados a longa data,
normalmente denominadas por melhores
prticas, dado o reconhecimento de que
funcionam,
embora,
como visto,
apresentem grandes taxas de insucesso.
Na medida em que o volume de solues
entregues cresa,
a designao dos
recursos especficos ao BI se auto
justificar. Contudo, caso a organizao
promova uma montagem insuficiente da
equipe, ou deixe a alocao de algum
recurso para mais trade,
pode haver
dificuldades significativas na conduo dos
projetos,
assim como ser certo que
haver dificuldades na operao e
sustentao das solues.
Tais problemas podem ser, porm no se
restringem a:

Perda
do
conhecimento
desenvolvido no projeto;

Perda do prazo;

Perda da confiabilidade da soluo


devido a dbitos tcnicos;

Dbitos tcnicos graves ou em


grande nmero,
devido a um
processo
de
identificao
e
monitorao falho ou de baixa
continuidade e periodicidade.

Neste sentido, sugere-se que os mesmos


sejam designados desde cedo, fazendo
uso do tempo livre nas primeira interaes
para desenvolv-los nos potncias gaps de
conhecimento.
Dados os limites de escopo deste trabalho,
sugerem-se os seguintes estudos futuros
para a sua complementao:

Gesto de mudanas aplicadas ao


desafio da adaptao de equipes
auto-organizadas e da prpria
organizao ao BI, aos mtodos
geis e a sua adaptao a todo
ciclo de produtos de BI a serem
desenvolvidos na organizao;

Estudo profundo das abordagens


hipernormalizadas como a sexta
forma normal, data valulting e a
modelagem por ncora;

Estudo
e
catalogao
das
possveis categorias de dbitos
tcnicos especficos de BI, assim
como de suas tcnicas soluo.

Tendo todos os pontos ora expostos,


observa-se que a adaptao da abordagem
de mtodos geis conduo de
programas,
projetos e sustentao de
solues de BI oferece diversas vantagens
em relao aos mtodos tradicionais,
sobretudo, contribuindo para a melhora do
ambiente e das condies para a sua
conduo,
evoluo e sustentao,
possibilitando tambm a sua necessria
justificativa em termos dos custos
envolvidos em seu desenvolvimento pela
rpida
apresentao
de
resultados,
atraindo a ateno e investimento por parte
dos usurios finais.

32

BIBLIOGRAFIA:
Ambler,S ; Sadalage P. Refactoring
Databases :Evolutionary Database
Design. Boston, MA, Estados Unidos:
Addison-Wesley Professional, 2006.

Collaborative Dimensional Modeling,


from Witeboard to Star Schema.
Burwwod House, Leeds, UK: DecisionOne
Press, 2011.

Ambler,S. Agile Modeling:Effective


Practices for extreme programming and
the Unified Process. New York, NY,
Estados Unidos: John Wiley & Sons, Inc.,
2003.

Fowler M. Evolutionary Database


Design.2003. Disponvel em
http://martinfowler.com/articles/evodb.html.
Acessado: 30 mai. 2013

BECK, Kent. Extreme Programming


Explained: Embrace Change. Boston,
MA, Estados Unidos: Addison-Wesley
Professional, 1999.
BECK, Kent; BEEDLE, Mike;
BENNEKUM, Arie Van; COCKBURN,
Alistair; CUNNINGHAM, Ward; FOWLER,
Martin ; GRENNING , James; HIGHSMITH
. Jim; HUNT , Andrew; JEFFRIES, Ron;
KERN, Jon; MARICK, Brian; MARTIN,
Robert C.; MELLOR, Steve; SCHWABER,
Ken; SUTHERLAND, Jeff ; THOMAS ,
Dave. Manifesto for agile software
development, Disponvel em:
www.agilemanifesto.org. Acesso: 22 out.
2012.
BRAGA, Bruno da Rocha. Uma
metodologia de modelagem da
arquitetura de processos para a gesto
da estrutura de custos e aplicao aos
negcios do Banco Central do Brasil.
Revista UNIABEU Belford Roxo V.5
Nmero 10 maio- agosto 2012. Disponvel
em:
http://www.uniabeu.edu.br/publica/index.ph
p/RU/article/viewFile/441/pdf_218. Acesso:
30 abr 2013
CAMARGO, Marcelo Nicolas. Inovao e
a estratgia das empresas: uma
proposta para criao de modelo que
permita a integrao entre ambas. 121f.
Dissertao (Mestrado profissionalizante
em administrao) - Faculdade de
Economia e Finanas IBMEC, Rio de
Janeiro.
COLLIER, Ken W.. Agile Analytics: A
Value-Driven Approach to Business
Intelligence and Data Warehousing.
Boston, MA, Estados Unidos: AddisonWesley Professional, 2011
CORR, Lawrence; STAGNITTO, Jim .
Agile Data Warehouse Desing:

GARTNER. More than 50 percent of data


warehouse projects will have limited
acceptance or will be failures through
2007. Disponvel em:
http://www.gartner.com. Acesso: 22 out.
2012.
HUGHES, Ralph. Agile Data Warehouse:
Delivering World-Class Business
Intelligence System Using Srum and XP.
Bloomington, IN, Estados Unidos:
IUniverse, 2008.
______. Agile Data Warehouse Project
Management: Business Intelligence
System Using Srum. Waltam, MA,
Estados Unidos: Morgan Kaufmann, 2012.
INMON, W. H.. Building the data
warehouse. MA, Estados Unidos:
Wellesley, 1991.
JOHNSON, Jim. Keynote speech xp.
Sardinia, Italy: Standish Group, 2002. In:
ABRAHAMSSON, Pekka. Fact corner The AGILE ITEA Project website.
Disponvel em:
http://www.google.com.br/url?sa=t&rct=j&q
=&esrc=s&frm=1&source=web&cd=4&cad=
rja&ved=0CEcQFjAD&url=http%3A%2F%2
Fwww.agileitea.org%2Fpublic%2Fpapers%2FITEASymposium_oct05.pdf&ei=8PmvUJKAKpDK9QSH9ICAAw
&usg=AFQjCNFBQnQiVXOljK_qyxilbcUSA
_EYtg. Acesso: 25 out. 2012
KIMBALL, Ralph. The Data Warehouse
Toolkit: Practical techniques for building
dimensional data warehouses. New
York, NY, Estados Unidos: John Wiley &
Sons, Inc., 1996.
______. The Data Warehouse Toolkit:
Practical techniques for building
dimensional data warehouses. 2nd ed.

33

New York, NY, Estados Unidos: John Wiley


& Sons, Inc., 2002.
KIMBALL, Ralph; Caserta, Joe. Data
Warehouse ETL Toolkit. New York, NY,
Estados Unidos: John Wiley & Sons, Inc.,
2004.
KIMBALL,
Ralph;
Reeves,
Laura;
Thornthwaite,
Warren; Ross, Margy ;
Thornwaite, Warren; Becker, Bob. The
Data Warehouse Lifecycle Toolkit. 2nd
ed. New York, NY, Estados Unidos: John
Wiley & Sons, Inc., 2008.
MCRUZ, Consultoria, Desenvolvimento de
Software, Cursos e Treinamentos. Curso
Desenvolvimento de Software com

SCRUM. Rio de Janeiro, RJ, Brasil.


Disponvel em:
http://www.mcruztecnologia.com.br/BlogTre
inamentosTI/wpcontent/uploads/2013/03/SCRUM.jpg.
Acessado: 02 de mai. 2013
PORTER, Michael. Competitive
Advantage: Creating and Sustaining
Superior Performance. New York, NY,
Estados Unidos: The Free Press, 1985
ROYCE, Winston W.. Managing the
Development of Large Software
Systems. New York, NY, Estados Unidos:
Proc. IEEE WESCON. Disponvel em:
http://leadinganswers.typepad.com/leading
_answers/files/original_waterfall_paper_win
ston_royce.pdf. Acesso: 23 mar. 2013

Você também pode gostar