1. FDWS: Uma Metodologia para Gerˆ ncia e Desenvolvimento
e
´
de Projetos Ageis de Business Intelligence
Mauricio Cesar Santos da Purificacao1 , Vaninha Vieira1
¸˜
1
¸˜
Departamento de Ciˆ ncia da Computacao – Universidade Federal da Bahia (UFBA)
e
40.170-110 – Salvador – BA – Brazil
mauricioc@ufba.br, vaninha@dcc.ufba.br
Abstract. The development of Business Intelligence(BI) solutions is an arduous
task because of the highly complex Information Technology (IT) enviroment and
large volumes of non-integrated data coming from different databases. More-
over, traditional approaches of BI solutions like Kimball do not enable man-
agers to experience its benefits and many projects finish without any useful re-
sult. This paper describes the specification of a methodology for management
and development of agile BI projects using combined practical methodologies
of Extreme Programming (XP), Scrum and Feature Driven Development (FDD).
This methodology was employed in two case studies in order to validate its ap-
plicability.
Resumo. A construcao de solucoes de Business Intelligence (BI) e geralmente
¸˜ ¸˜ ´
uma miss˜ o dif´cil devido a ambientes de TI altamente complexos e grandes
a ı
volumes de dados n˜ o-integrados. Al´ m disso, as abordagens tradicionais de
a e
construcao de solucoes de BI como Kimball n˜ o possibilitam que os gestores
¸˜ ¸˜ a
experimentem seus benef´cios a curto prazo e muitos projetos encerram-se sem
ı
ter havido nenhum resultado vis´vel aos mesmos. Este trabalho descreve a
ı
especificacao de uma metodologia para gerˆ ncia e desenvolvimento de proje-
¸˜ e
tos ageis de BI derivada das metodologias ageis Extreme Programming (XP),
´ ´
SCRUM e Feature Driven Development (FDD). Esta metodologia foi aplicada
em dois estudos de caso reais de modo a avaliar sua aplicabilidade.
¸˜
1. Introducao
Inteligˆ ncia de Neg´ cios (BI, do inglˆ s Business Intelligence) pode ser visto como um
e o e
¸˜ ¸˜
processo sistem´ tico de aquisicao, tratamento e an´ lise de informacoes em que os dados
a a
¸˜ a ¸˜
internos e externos de uma organizacao s˜ o integrados para gerar informacao pertinente
¸˜ ´
para o processo de tomada de decis˜ es gerenciais [Petrini et al. 2006]. Esta integracao e
o
feita atrav´ s do processo de Extract, Transform and Load (ETL).
e
No processo de ETL, os dados operacionais s˜ o uniformizados, selecionados,
a
¸˜
transformados, e carregados no Data Warehouse (DW) da solucao de BI. A partir do DW
os dados podem ser analisados por meio de ferramentas de consultas on-line (ferramentas
OLAP), relat´ rios dinˆ micos, paineis de indicadores (dashboards) ou tamb´ m com o uso
o a e
¸˜
de ferramentas de mineracao de dados (data mining).
¸˜
As solucoes de BI possibilitam ent˜ o uma melhora significativa no processo de-
a
¸˜ ¸˜ ´
cis´ rio das organizacoes ao oferecer informacoes uteis, de modo r´ pido e facilitado, a
o a
` ¸˜ ¸˜
partir de dados internos ou externos a organizacao. Por isso, estas solucoes s˜ o cada
a

2. vez mais priorit´ rias para os gestores das empresas e seus respons´ veis de Tecnologia
a a
¸˜
da Informacao (TI) [N´ brega 2010]. Por´ m, muitos destes projetos tˆ m falhado em con-
o e e
a ´
seguir seus objetivos. Este fato n˜ o e estranho tratando-se de sistemas de suporte a decis˜ o
a
e da imaturidade da disciplina de BI com uma diversidade de enfoques metodol´ gicos o
diferentes [Preston 2003].
De acordo com [N´ brega 2010] no relat´ rio da Forrester Research intitulado
o o
”Agile BI Out of the Box”, realizado a partir de um estudo com empresas dos Estados
a ¸˜
Unidos, os usu´ rios empresariais das aplicacoes de BI est˜ o largamente insatisfeitos com
a
¸˜
a falta de agilidade e flexibilidade das solucoes desenvolvidas.
o ´
Segundo o relat´ rio, e necess´ rio criar uma nova forma de conceber e construir as
a
¸˜ ¸˜
aplicacoes de BI, defendendo que o processo tradicional de recuperacao de informacoes ¸˜
¸˜ ¸˜
sobre todas as fontes de dados, documentacao de todos os atributos, criacao do Data
¸˜ ¸˜
Warehouse (DW) baseado nos dados coletados e compilacao de especificacoes para as
¸˜ ´
aplicacoes de BI nem sempre e uma abordagem suficiente para enfrentar os desafios colo-
cados pelos complexos ambientes de TI dos dias de hoje e pelas necessidades dos seus
usu´ rios.
a
¸˜ ´
Este artigo apresenta a especificacao do FDWS que e uma metodolo-
´
gia para gerˆ ncia e desenvolvimento de projetos ageis de BI derivada das
e
´
metodologias ageis SCRUM [Schwaber 2004], Feature Driven Development (FDD)
[Palmer and Felsing 2002] e Extreme Programming (XP) [Teles 2005]. Para tanto, este
¸˜
artigo est´ organizado da seguinte forma: A Secao 2 discute algumas diretivas rela-
a
` ¸˜ ´ ¸˜
cionadas a adaptacao de m´ todos ageis para projetos de BI. A Secao 3 apresenta os tra-
e
` ¸˜
balhos relacionados a metodologia proposta. A Secao 4 detalha a metodologia FDWS e
` ¸˜ ¸˜ ´ ¸˜
discute as principais decis˜ es relativas a sua especificacao. Na Secao 5 e feita a descricao
o
¸˜ ´
do estudo de caso e a an´ lise dos resultados e na Secao 6 e realizada a conclus˜ o deste
a a
trabalho e a an´ lise dos poss´veis trabalhos futuros.
a ı
´
2. Metodologias Ageis e BI
¸˜
De acordo com o apresentado na Secao 1, podemos listar alguns fatores que tem moti-
¸˜ ´
vado a aplicacao de metodologias ageis em BI devido aos problemas enfrentados com as
abordagens tradicionais:
• Pouco envolvimento com clientes, usu´ rios e patrocinadores do projeto;
a
• Mal dimensionamento do escopo dos projetos e ciclos de desenvolvimento resul-
tando em projetos caros, dif´ceis de implementar e projetos encerrados sem que
ı
os gestores tenham tido resultados satisfat´ rios;
o
• Planejamento do projeto em desacordo com as necessidades emergentes do
neg´ cio;
o
• Falta de tempo para experimentacao e avaliacao do conjunto de ferramentas a ser
¸˜ ¸˜
`
utilizado que se adeque as necessidades dos usu´ rios;
a
• Ferramentas anal´ticas pouco flex´veis e que n˜ o atendem as reais necessidades do
ı ı a `
neg´ cio;
o
• Dificuldades em lidar com mudancas de requisitos, incorporacao de funcionalida-
¸ ¸˜
¸˜
des e integracao de bases de dados distintas;
Devido a este cen´ rio, o relat´ rio da Forrester Research defende uma abordagem
a o
¸˜ ¸˜
definida como ”Agile BI”para a construcao de solucoes de BI. O conceito de ”Agile

3. ´
BI”n˜ o difere muito das metodologias ageis de desenvolvimento de software, o que de-
a
¸˜ ¸˜
manda a criacao de solucoes em pequena escala [N´ brega 2010] com uma maior proximi-
o
a ´
dade dos clientes e resultados efetivos mais r´ pidos. O uso de metodologias ageis tamb´ m
e
´
e defendido por [Hughes 2007] no que pode ser chamado de ”Agile Data Warehousing”,
como forma de tornar as equipes de desenvolvimento de DW mais r´ pidas e eficazes.
a
¸˜ ´
O uso e a melhor forma da aplicacao de metodologias ageis em projetos de BI e ´
`
um campo aberto, devido, principalmente, as caracter´sticas diferenciadas desse tipo de
ı
´
projeto e as variadas metodologias ageis existentes. Um dos parˆ metros que podem ser
a
´
utilizados para avaliar como as metodologias ageis podem ser utilizadas em projetos de
´ ´
BI e a an´ lise dos itens contidos no ”Manifesto Agil”[Beck et al. 2001] que nos confere
a
algumas diretivas listadas abaixo [Graziano 2010]:
• Duas definicoes devem ser feitas em um projeto de BI: Quem e o cliente e o que
¸˜ ´
´
e software com valor agregado em BI. Estes dois itens devem estar bem definidos
¸˜
para a execucao dos trabalhos, pois os clientes dever˜ o participar do projeto como
a
¸˜
membros do time e a definicao de software com valor agregado em BI permite
a ¸˜
definir o que ser´ entregue a cada iteracao e como o modelo do DW ir´ evoluir a
durante o projeto;
• O projeto de BI inicia-se com uma pequena lista de funcionalidades que ser´ in- a
crementada a partir do uso da primeira entrega do produto pelos usu´ rios finais;
a
• Deve-se escolher uma area priorit´ ria e a partir dela definir as funcionalidades e o
´ a
¸˜ ´
plano de desenvolvimento. O escopo de cada iteracao e reduzido justamente para
permitir entregas frequentes do produto;
• Projetos de BI necessitam da presenca das pessoas de neg´ cio. O ideal e que sejam
¸ o ´
¸˜
feitas interacoes di´ rias com os times de desenvolvimento;
a
• O time do projeto tem que estar motivado e deve ser treinado continuamente se
necess´ rio. Al´ m disso, pequenas unidades de trabalho ajudam a manter uma
a e
¸˜
atmosfera de sucesso e facilitam a comunicacao entre os membros do time;
• O time deve possuir um relacionamento di´ rio. Reuni˜ es di´ rias devem ser uti-
a o a
¸˜
lizadas para monitorar o processo e a execucao das tarefas realizadas;
• Entregas cont´nuas de funcionalidades devem ser feitas no mesmo intervalo de
ı
tempo;
• Projetos de BI duram muito tempo, por isso n˜ o se deve cansar os times com
a
prazos irracionais e escopos inating´veis. Deve-se implementar a menor unidade
ı
de trabalho com valor de neg´ cio para os clientes. Ao usar um m´ todo agil, o
o e ´
`
mesmo deve ser avaliado e adaptado as necessidades particulares do projeto e do
time;
• Deve-se ter um cuidado extremo com o design da solucao para evitar re-trabalhos e
¸˜
¸˜ ¸˜
impossibilidades de implementacoes. Al´ m disso as solucoes mais simples devem
e
ser priorizadas no projeto;
• A equipe de trabalho deve assumir as responsabilidades como um time, tendo ma-
turidade para se auto policiar e definir em conjunto as tarefas e responsabilidades
¸˜
de cada membro. Encontrar a solucao de um problema, torna-se o problema do
time. Al´ m disso, frequentemente o time deve avaliar e refletir sobre seu trabalho.
e
3. Trabalhos Relacionados
¸˜ ´
Antes de realizar a especificacao de uma nova metodologia agil para projetos de BI
foram investigadas algumas metodologias propostas tanto no ambiente acadˆ mico como
e

4. no comercial (Agile Data Warehousing [Hughes 2007], Extreme Scoping [Moss 2007],
¸˜ ´
Agile BI - Pentaho [Corporation 2010] e Aplicacao de Pr´ ticas Ageis em Projetos de BI
a
[de Carvalho 2009]).
Foram considerados trabalhos que envolvessem tanto o termo BI quanto o termo
Data Warehousing (estes termos foram considerados como sinˆ nimos no escopo deste
o
¸˜ ´
trabalho), pois desenvolver uma solucao de Data Warehousing e tamb´ m desenvolver
e
¸˜ ¸˜
uma solucao de BI, caso esta solucao seja destinada ao processo de tomada de decis˜ es o
a partir das an´ lises gerenciais realizadas. A s´ntese da an´ lise realizada destes trabalhos
a ı a
pode ser visualizada na Figura 1.
´ ´
Figura 1. Analise Comparativa de Metodologias Ageis para BI
De acordo com esta an´ lise, os pontos que motivaram a proposta de uma nova
a
´ ¸˜
metodologia agil para projetos de BI foram: Falta de adequacao das metodologias anali-
sadas com as etapas definidas pela literatura para gerˆ ncia e desenvolvimento de projetos
e
de BI, abordagens gen´ ricas e processos de levantamento de requisitos deficientes e/ou
e
¸˜ ´
pouco intuitivos e a composicao com as metodologias ageis SCRUM e XP apenas.
4. Metodologia FDWS
´ ¸˜ ´
A metodologia FDWS e uma composicao de pr´ ticas dos m´ todos ageis SCRUM, XP e
a e
´ ¸˜
FDD para o gerenciamento e desenvolvimento de projetos ageis de BI atrav´ s da definicao
e
de processos, pr´ ticas, pap´ is e artefatos.
a e
a ´
O FDWS promove o reuso de pr´ ticas ageis consolidadas com pr´ ticas de
a
´
metodologias de gerenciamento de projetos de BI ageis (Extreme Scoping [Moss 2007]
e Agile Data Warehousing [Hughes 2007] ) e tradicionais (Kimball [Kimball 2002] e S´
a
[de Oliveira e S´ 2009]). Seu nome e baseado nas abreviaturas FDD, DW e SCRUM. A
a ´
¸˜ ¸˜
descricao completa da mesma pode ser encontrada em [da Purificacao and Vieira 2010].
´
O FDWS e uma metodologia centrada em processos, de modo que a solucao de ¸˜
¸˜
BI possa ser constru´da iterativamente e incrementalmente a partir da definicao de quais
ı
funcionalidades s˜ o priorit´ rias e agregam o maior valor de neg´ cio aos clientes.
a a o
¸˜
O processo de levantamento de requisitos e a definicao do esquema do DW s˜ o a
baseados na abordagem h´brida citada por [de Oliveira e S´ 2009], relacionando assim a
ı a
¸˜ ¸˜ ¸˜
orientacao a dados, orientacao aos objetivos organizacionais, orientacao aos usu´ rios e a
a
¸˜
orientacao aos processos organizacionais.

5. Uma funcionalidade no FDWS pode ser definida como uma consulta OLAP, um
o ¸˜
relat´ rio, um dashboard, a aplicacao de uma t´ cnica de Data Mining entre outras. Estas
e
funcionalidades podem ser dos seguintes tipos:
• Construcao: S˜ o funcionalidades novas referentes a uma area de neg´ cio ou pro-
¸˜ a ´ o
¸˜
cesso ainda n˜ o explorado durante a execucao dos trabalhos;
a
• Manutencao: Referem-se a funcionalidades existentes no ambiente de producao
¸˜ ¸˜
que dever˜ o ser ajustadas mediante a necessidade dos clientes;
a
• Evolucao: S˜ o funcionalidades novas referentes a uma area de neg´ cio ou pro-
¸˜ a ´ o
a ¸˜
cesso que j´ foi explorado durante a execucao dos trabalhos e por conseguinte j´a
¸˜
possue itens em producao.
4.1. Pap´ is
e
A estrutura de pap´ is do FDWS origina-se das metodologias SCRUM e FDD. O SCRUM
e
define a seguinte estrutura de pap´ is:Product Owner, Scrum Master e Time. No FDWS, a
e
figura do Product Owner transforma-se em um grupo de pessoas denominado de Gerˆ ncia
e
¸˜
de Neg´ cio. A aglutinacao do Time com o Scrum Master, que no FDWS chama-se
o
Treinador, deu origem ao grupo denominado N´ cleo de Desenvolvimento. Neste grupo,
u
tamb´ m foi adicionada a figura de um Coordenador T´ cnico do Projeto.
e e
¸˜ `
O grupo denominado Gerˆ ncia de Aplicacao foi criado devido a necessidade que
e
e ¸˜
projetos de BI tˆ m da participacao direta dos usu´ rios finais para seu pleno sucesso. A
a
e ¸˜
Gerˆ ncia de Aplicacao pode ent˜ o interagir diretamente com o N´ cleo de Desenvolvi-
a u
mento ou com a Gerˆ ncia de Neg´ cio.
e o
¸˜
Do FDD vem a concepcao do time, onde os membros possuem pap´ is e funcoes
e ¸˜
bem definidas. Al´ m disso, a figura do Treinador ganha no FDWS responsabilidades
e
¸˜
adicionais em comparacao com as do Scrum Master. Al´ m de gerenciar o processo e
e
´
trabalhar para potencializar o trabalho realizado pelo time, o mesmo e respons´ vel pelas
a
o ¸˜
sess˜ es de coleta de requisitos, documentacao e gerˆ ncia do conhecimento. A listagem
e
abaixo descreve a estrutura de pap´ is definida para a metodologia FDWS:
e
• Gerˆ ncia de Aplicacao: Este grupo ser´ formado pelos futuros usu´ rios das
e ¸˜ a a
¸˜ ¸˜
aplicacoes de BI (gestores da organizacao, chefes de departamentos e outros).
Seus membros participar˜ o de todo o processo de desenvolvimento da solucao
a ¸˜
de BI experimentando e validando as entregas dos ciclos de desenvolvimento. O
a ´ e
tamanho deste grupo n˜ o e pr´ -definido, sendo aconselh´ vel que exista um repre-
a
´ ¸˜
sentante de cada area de neg´ cio da instituicao e um poss´vel suplente;
o ı
• Gerˆ ncia de Neg´ cio: Devem fazer parte deste grupo os membros da equipe de
e o
¸˜
TI da organizacao, pois s˜ o estes que conhecem o neg´ cio ao n´vel operacional,
a o ı
¸˜ `
contribuindo assim na elicitacao de requisitos e oferecendo a equipe de trabalho
o conhecimento necess´ rio a respeito do ambiente operacional e do neg´ cio da
a o
¸˜ e o a ¸˜
organizacao. A gerˆ ncia de neg´ cio, participar´ ativamente das definicoes do pro-
¸˜
jeto, dos testes e da validacao dos produtos desenvolvidos;
• Nucleo de Desenvolvimento: O n´ cleo de desenvolvimento e formado por trˆ s
´ u ´ e
elementos:
e ´
– Coordenador T´ cnico: E respons´ vel por gerenciar o trabalho dos
a
treinadores dos times e o processo de desenvolvimento como um todo. Na
existˆ ncia de apenas um time, o treinador do mesmo pode ser considerado
e
como coordenador t´ cnico do projeto;
e

6. – Treinador: O treinador gerencia o processo do FDWS no ambito de seu
ˆ
´ ¸˜
time de trabalho. Seu principal objetivo e auxiliar o time na realizacao de
suas tarefas potencializando assim o desempenho do mesmo;
– Time: O time (equipe de trabalho) dever´ ser composto idealmente por um
a
n´ mero par de membros. Recomenda-se um tamanho entre 4 ou 8 mem-
u
¸˜
bros a depender dos recursos humanos da organizacao. O time dever´ ser a
a a a ¸˜
auto-organizado, auto-gerenci´ vel e respons´ vel pela divis˜ o e alocacao
¸˜
das tarefas dentro das iteracoes. Os membros do time devem possuir res-
¸˜
ponsabilidades e funcoes espec´ficas, a saber: Arquiteto de ETL, Gerente
ı
¸˜
de Modelagem, Gestor do Ambiente de Aplicacao, Gestor do Ambiente de
¸˜
Configuracao e Gestor do Ambiente de Teste.
4.2. Ciclo de Vida
´ ¸˜
O ciclo de vida do FDWS e uma composicao dos ciclos de vida do SCRUM, FDD e
¸˜ ¸˜ ¸˜
XP. Do XP vem a realizacao das releases e iteracoes, do SCRUM vem a concepcao do
¸˜
planejamento do projeto e a construcao do backlog do produto. O FDWS possui as etapas
de planejamento do projeto e planejamento da release bem definidas com o apoio do
esquema de planejamento definido pela FDD e o uso adaptado da Feature Breackdown
Structure (FBS) [Version-One 2010] para o mapeamento das funcionalidades, atividades,
´
processos e areas de neg´ cio.
o
¸ ´
O processo do FDWS comeca com um mapeamento das areas de neg´ cio da o
¸˜ ´
organizacao. Esta e a vis˜ o inicial do produto que ser´ desenvolvido. Para cada area
a a ´
de neg´ cio, ser´ realizada uma release e os processos e atividades de neg´ cio ser˜ o ma-
o a o a
peados para que as funcionalidades sejam coletadas. Um modelo abrangente da release e ´
´
feito e a sequˆ ncia de desenvolvimento e planejada com base na lista de funcionalidades
e
ı ¸˜
constru´da. A cada iteracao, o modelo abrangente e as funcionalidades ser˜ o detalhadas e
a
implementadas.
´
Este e basicamente o ciclo definido pela FDD: Desenvolver um modelo
abrangente, construir a lista de funcionalidades, planejar por funcionalidades, detalhar por
¸˜
funcionalidades e construir por funcionalidades. A iteracao no FDWS incorpora pr´ ticasa
a o ¸˜
do SCRUM como as reuni˜ es di´ rias, reuni˜ es de demonstracao do produto, reuni˜ es de
o o
¸˜
retrospectiva e backlog do produto e da iteracao. Al´ m destes, alguns itens do XP s˜ o uti-
e a
¸˜
lizados, como a programacao em par, design incremental, propriedade coletiva do c´ digoo
e o desenvolvimento dirigido por testes.
´
O ciclo de vida da metodologia FDWS e ilustrado na Figura 2, o qual e com- ´
posto por quatro processos principais: Planejamento do Projeto, Planejamento da Release,
¸˜ ¸˜
Iteracao e P´ s-Iteracao.
o
• Planejamento do Projeto: Este processo e respons´ vel por oferecer uma vis˜ o
´ a a
¸˜
geral sobre a solucao de BI que ser´ desenvolvida mediante o mapeamento de
a
´ ¸˜ ¸˜
todas as areas de neg´ cio existentes na organizacao e a definicao dos objetivos e
o
e a ´
crit´ rios de sucesso do projeto. A vis˜ o inicial do produto e estabelecida e a partir
´
dela e realizado um planejamento alto-n´vel de todo o projeto. O plano de projeto
ı
¸˜
gerado dever´ ser reavaliado a cada finalizacao das releases planejadas;
a
• Planejamento da Release: Este processo e respons´ vel por aprimorar a vis˜ o
´ a a
do produto estabelecida no planejamento do projeto. No planejamento do pro-
a ´
jeto s˜ o definidas diversas releases a fim de cobrir as areas de neg´ cio existentes.
o

7. ˜
Figura 2. FDWS - Ciclo de Vida - Visao Geral
a ´
Preferencialmente, cada release atender´ a uma area de neg´ cio, ou dependendo
o
´ ¸˜
da prioridade, a duas areas de neg´ cio que tenham alguma relacao de consultas
o
gerenciais e indicadores de neg´ cio. No planejamento da release, os processos
o
´
de neg´ cio da area alvo s˜ o mapeados e os requisitos de usu´ rio s˜ o coletados.
o a a a
Com a lista de funcionalidades populada, pode-se definir a sequˆ ncia de execucao
e ¸˜
¸˜ ¸˜ ´
das iteracoes. A cada iteracao realizada, o planejamento da release e revisto e a
´ ´
lista de funcionalidades e atualizada. E esperado que durante o processo novos
requisitos sejam coletados;
• Iteracao: Na iteracao ocorre a implementacao de uma parte da solucao de BI que
¸˜ ¸˜ ¸˜ ¸˜
agregue valor de neg´ cio ao cliente.
o
• P´ s-Iteracao: Na p´ s-iteracao, e realizada a implantacao do produto na area de
o ¸˜ o ¸˜ ´ ¸˜ ´
¸˜ ¸˜
producao assim como a reuni˜ o de retrospectiva da iteracao para que o time, o
a
treinador e o coordenador t´ cnico (caso exista) possam avaliar o trabalho do time
e
¸˜
durante a iteracao e propor melhorias. O planejamento da release dever´ ser re-
a
visto e a lista de funcionalidades poder´ ser alterada. Nesta etapa ser´ avaliado se
a a
¸˜
o planejamento inicial das iteracoes ser´ seguido ou modificado. Opcionalmente
a
a a ¸˜
ser´ realizado o treinamento dos usu´ rios da aplicacao de DW, desenvolvimento
do manual de uso e acompanhamento dos primeiros dias de sua utilizacao. ¸˜
¸˜
5. Estudo de Caso e Avaliacao
Para avaliar a proposta deste trabalho foram realizados dois estudos de casos. Estes es-
¸˜
tudos de caso serviram ainda para aprimorar a especificacao da metodologia. O primeiro
estudo de caso foi realizado entre os meses de marco e julho de 2010 como parte de um
¸
Projeto Permanecer denominado DW-UFBA. O time do projeto foi composto por trˆ s e
bolsistas da Universidade Federal da Bahia (UFBA), sendo um deles considerado como o
t´ cnico do time. Neste projeto trabalhou-se com o banco de dados de Pessoal da UFBA.
e
¸˜
Este projeto possibilitou a maturacao das id´ ias em torno do FDWS e o refina-
e
¸˜
mento da sua especificacao, a qual foi finalizada no segundo estudo de caso realizado
nos trabalhos da disciplina T´ picos em Banco de Dados do Departamento de Ciˆ ncia da
o e
¸˜
Computacao da UFBA (DCC-UFBA) no semestre de 2010-2.
Neste estudo de caso foram desenvolvidos dois projetos: o primeiro para o Centro
de Processamento de Dados da UFBA (CPD-UFBA) e o segundo para a Santa Casa de

8. ¸˜
Miseric´ rdia da Bahia envolvendo um total de 12 alunos de graduacao, a professora da
o
¸˜ ¸˜
disciplina e 6 analistas das instiuicoes participantes. Uma avaliacao qualitativa foi real-
¸˜
izada com a aplicacao de um question´ rio aos participantes de ambos projetos (apenas os
a
¸˜
alunos de graduacao e a professora da disciplina e orientadora deste trabalho).
O FDWS foi aplicado sem que o pessoal envolvido tivesse conhecimento sobre
o mesmo. No projeto Permanecer, foi realizada uma reuni˜ o no qual foram discutidos
a
¸˜ ¸˜
alguns aspectos relacionados a especificacao da metodologia proposta e sua relacao com
o framework SCRUM.
Durante as aulas da disciplina T´ picos em Banco de Dados, os alunos tiveram uma
o
e ´
palestra sobre M´ todos Ageis e BI onde tiveram acesso a uma vis˜ o geral da proposta do
a
´
FDWS e detalhamentos de como os m´ todos ageis podem ser aplicados a projetos de BI.
e
Al´ m disso, membros de ambos projetos participaram de uma palestra na qual foi feita a
e
¸˜ ¸˜ ´
avaliacao da experiˆ ncia da adocao de m´ todos ageis em projetos de BI de acordo com a
e e
¸˜
execucao dos trabalhos no Projeto Permanecer DW-UFBA.
¸˜
Antes da execucao dos question´ rios, participantes de ambos os projetos assis-
a
¸˜
tiram a uma apresentacao detalhada sobre o FDWS e como a metodologia proposta foi
o ı ¸˜
aplicada no projeto da disciplina T´ picos em Banco de Dados. A s´ntese das licoes apren-
didas nestes estudo de caso s˜ o detalhadas na lista abaixo:
a
´
1. M´ todos ageis s˜ o simples por´ m dif´ceis de implementar, pois dependem muito
e a e ı
da maturidade e disciplina dos envolvidos e al´ m disso seu pleno sucesso depende
e
da existˆ ncia de uma equipe auto-organizada e auto-gerenci´ vel;
e a
e ´
2. M´ todos ageis foram feitos para gerˆ ncia e desenvolvimento de projetos de soft-
e
¸˜
ware e n˜ o de projetos de integracao de dados. As estimativas das tarefas rela-
a
¸˜
cionadas a integracao de dados exigem bastante cuidado pois algumas vezes ul-
trapassam o custo inicialmente estipulado;
¸˜
3. O escopo da iteracao deve ser tang´vel ao seu tamanho, o que implica em um bom
ı
¸˜
planejamento da sequˆ ncia de iteracoes a serem realizadas;
e
¸˜ ¸˜ ´
4. Para a aplicacao da programacao em par, e necess´ rio que o time seja de tempo
a
integral e que os hor´ rios de seus membros tenham plena coalis˜ o;
a a
a ´
5. N˜ o e poss´vel ter sucesso no trabalho realizado sem que a gerˆ ncia de neg´ cios
ı e o
¸˜
seja considerada parte do time e tenha participacao ativa no processo;
¸˜
6. Itens como o Kanban, gr´ ficos de medicao de velocidade da equipe, pontos de pro-
a
jeto consumidos e esforco restante s˜ o de extrema importˆ ncia para a visibilidade
¸ a a
do projeto e devem ser utilizados na iteracao; ¸˜
´
7. E importante que o processo seja documentado de modo que possa existir um
o ¸˜
registro hist´ rico das licoes aprendidas e das decis˜ es do projeto. Este pode ser
o
considerado como um dos pontos fracos do estudo de caso;
8. Entre as atividades esperadas do treinador do time (ou coach) est˜ o a vigilˆ ncia
a a
¸˜ ¸˜ ´ ¸˜
a adocao e aplicacao da metodologia agil no projeto e a interacao com a gerˆ ncia
e
o e ´
de neg´ cios. Al´ m disso, e interessante que o mesmo possa treinar o time com
¸˜ ´
relacao a metodologias ageis e as pr´ ticas a serem adotadas durante o processo.
a
De um modo geral, a metodologia FDWS foi avaliada positivamente pelo conjunto
de avaliadores que observaram nela um grande potencial, necessitando esta de algum
¸˜
refinamento adicional, mais estudos de caso e avaliacoes, de modo que a mesma possa ser

9. considerada ou n˜ o como um padr˜ o de desenvolvimento e suas vulnerabilidades sejam
a a
avaliadas e contornadas.
A divergˆ ncia de opini˜ es em algumas respostas indicam que a curva de apren-
e o
´ a ´ a
dizagem da metodologia proposta e realmente alta e a mesma n˜ o e t˜ o simples de ser en-
¸˜
tendida com apenas uma apresentacao como foi feito. A falta de entendimento da mesma
¸˜
dificulta sua avaliacao e, al´ m disso, a falta de conhecimento e experiˆ ncia em m´ todos
e e e
´
ageis dificulta a compreens˜ o das pr´ ticas adotadas na metodologia FDWS e como ela foi
a a
composta.
6. Conclus˜ o e Trabalhos Futuros
a
¸˜ ´ ´ ´
A aplicacao de metodologias ageis em BI e uma area de pesquisa em expans˜ o devido a
a
´ ¸˜
diversidade de metodologias e pr´ ticas ageis existentes e suas possibilidades de aplicacao.
a
e ¸˜
Al´ m disso, projetos de integracao de dados s˜ o bastante diferentes dos projetos de de-
a
senvolvimento de software.
Espera-se que problemas como a alta taxa de insucesso dos projetos, falta de flex-
ibilidade de ferramentas, lentid˜ o na entrega de resultados significativos aos gerentes
a
¸˜
envolvidos e insatisfacao dos clientes sejam minimizados com esta nova concepcao do¸˜
¸˜ ´
desenvolvimento de solucoes de BI baseada nos pr´ncipios descritos no manifesto agil.
ı
o a ´
A metodologia FDWS prop˜ e-se a realizar o alinhamento de pr´ ticas ageis com
as etapas de gerˆ ncia e desenvolvimento de projetos de BI j´ consagradas pela literatura
e a
¸˜ ´
a partir da composicao das metodologias ageis XP, SCRUM e FDD. Destina-se a ser um
a e ´
guia de boas pr´ ticas para a gerˆ ncia e desenvolvimento de projetos ageis de BI atrav´ s
e
¸˜
da definicao de um conjunto de processos, atividades, artefatos e p´ peis que podem ser
a
adaptados a times, projetos e realidades espec´ficas.
ı
a ¸˜
O diferencial do FDWS est´ na incorporacao das pr´ ticas de FDD em seu processo
a
¸˜ ¸˜ ¸˜ ´
de planejamento. Al´ m disso, a partir da P´ s-Iteracao, o plano de execucao das iteracoes e
e o
¸˜ ¸˜
reavaliado, o que permite ao time realizar operacoes de manutencao, melhorias e evolucao¸˜
¸˜ ¸˜
na solucao de BI existente em producao. Basta apenas que as gerˆ ncias do projeto definam
e
¸˜ ¸˜
funcionalidades do tipo manutencao ou evolucao. Tanto o Extreme Scoping como o Agile
Data Warehousing n˜ o definem claramente como essas atividades s˜ o feitas.
a a
O FDWS incorpora ainda a id´ ia trazida no trabalho de [de Carvalho 2009]. O
e
modelo do DW evolui a partir das funcionalidades que s˜ o disponibilizadas aos usu´ rios
a a
¸˜
finais e as atividades de back-end e front-end s˜ o realizadas em paralelo durante a iteracao.
a
Os seguintes itens constituem-se como possibilidades de trabalhos futuros: Refi-
¸˜
nar e validar a metodologia a partir de estudos de casos com organizacoes sem maturidade
em projetos de BI e com perfis diferentes, melhorar o processo de estimativas de custo
¸˜
das tarefas de ETL, incorporar a realizacao de testes automatizados, revisar e melhorar a
¸˜
documentacao, especificar templates dos artefatos, verificar a avaliar conjunto m´nimo de
ı
atividades a serem realizadas no uso da metodologia.
Referˆ ncias
e
Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M.,
Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R. C.,
Mellor, S., Schwaber, K., Sutherland, J., and Thomas, D. (2001). Manifesto for agile

10. software development. Dispon´vel em http://agilemanifesto.org/. Aces-
ı
sado em 26/09/2010.
Corporation, P. (2010). Introduction to agile bi. Dispon´vel em http://
ı
wiki.pentaho.com/display/AGILEBI/Documentation. Acessado em
02/10/2010.
¸˜
da Purificacao, M. C. S. and Vieira, V. (2010). Fdws: Uma metodologia para gerˆ ncia
e
´
e desenvolvimento de projetos Ageis de business intelligence. Dispon´vel em http:
ı
//www.oxenti.net/fdws. Acessado em 03/03/2011.
¸˜ ´ ¸˜
de Carvalho, G. T. (2009). Aplicacao de pr´ ticas ageis na construcao de data warehouse
a
evolutivo. Master’s thesis, Universidade de S˜ o Paulo, S˜ o Paulo.
a a
de Oliveira e S´ , J. V. (2009). Metodologia de Sistema de Datawarehouse. PhD thesis,
a
Universidade do Minho, Portugal.
Graziano, K. (2010). Agile methods and data warehousing. Dispon´vel em
ı
http://www.rmoug.org/TD2010Pres/graziano_01.pdf. Acessado em
25/03/2011.
Hughes, R. (2007). Agile Data Warehousing: Delivering World-Class Business Intelli-
gence Systems Using Scrum and XP. iUniverse.com, Incorporated.
Kimball, R. (2002). Data Warehouse toolkit: o guia completo para modelagem multidi-
mensional. Campus.
Moss, L. (2007). Extreme scoping - an agile project management ap-
proach. Dispon´vel em http://www.eiminstitute.org/library/
ı
eimi-archives/volume-1-issue-5-july-2007-edition/
extreme-scoping-an-agile-project-management-approach.
Acessado em 02/10/2010.
N´ brega, J. (2010).
o Forrester defende novo modo de desenvolver bi.
Dispon´vel
ı em http://www.computerworld.com.pt/2010/04/29/
forrester-defende-novo-modo-de-desenvolver-bi/. Acessado em
25/09/2010.
Palmer, S. R. and Felsing, J. M. (2002). A Practical Guide To Feature Driven Develop-
ment. Prentice Hall PTR.
Petrini, M., Freitas, M. T., and Pozzebon, M. (2006). Inteligˆ ncia de neg´ cios ou in-
e o
teligˆ ncia competitiva? noivo neur´ tico, noiva nervosa.
e o
Preston, R. (2003). Down to business: Business intelligence still in its infancy.
Dispon´vel em http://www.informationweek.com/news/business_
ı
intelligence/showArticle.jhtml?articleID=196801521. Acessado
em 25/09/2010.
Schwaber, K. (2004). Agile Project Management with Scrum. Microsoft Press.
¸˜
Teles, V. M. (2005). Um estudo de caso da adocao das pr´ ticas e valores do extreme
a
programming. Master’s thesis, Universidade Federal do Rio de Janeiro, Rio de Janeiro.
Version-One (2010). Feature estimation. Dispon´vel em http://www.versionone.
ı
com/Agile101/Feature_Estimation.asp. Acessado em 05/12/2010.