Em agosto de 2005 eu lancei um mini-curso sobre como fazer levantamento de requisitos para projetos de Business Intelligence. O que diferenciava aquele curso da prática tradicional era ser voltado para projetos ágeis. Você pode ver aquele post clicando aqui, conhecer o curso aqui e assistir ao vídeo promocional seguindo este link.
O assunto é interessante por demais da conta. Nestes dois últimos anos eu tenho me dedicado a estudar como melhorar a implementação de projetos de BI e DW usando técnicas ágeis. Tenho visitado palestras, lido artigos pela web, conversado com inúmeros profissionais. O resultado desse envolvimento todo apareceu na minha palestra do Pentaho Day 2017, BI E.V.A., que teve uma boa recepção junto à comunidade Pentaho.
Hoje eu recebi um e-mail da TDWI, um respeitado instituto de Data Warehousing. O assunto? É óbvio, né?
Agile BI.
Claro que eu tinha que ver do que se tratava. Eis o conteúdo prometido:
- Agile modeling values and principles
- Techniques for determining the right level of up-front design
- How to avoid overbuilding solutions by designing for what is needed
- Domain modeling
- Data model patterns
- Data smells and the impact of technical debt
- Continuous integration
- Safe refactoring techniques for making incremental design changes
- How to determine the right level of design documentation that is needed
- Effective collaborative modeling practices for cross-functional teams
- How to minimize the amount of unnecessary rework through reference and conceptual designs
- How to establish iteration zero as an agile practice that gives teams the runway to start delivering
Hmm… Interessante. Uma das coisas que eu comento no BI E.V.A. é que há muito sendo discutido sobre como se transformar o processo de modelagem de dados, em especial Modelagem Dimensional, em um processo “ágil”. No fundo, o que muito da literatura tem pregado é como incorporar Scrum ao processo tradicional.
Eu já fiz isso, e não adianta.
Pense um pouco: o cerne de ser ágil é prover melhoria contínua. Mas o cerne de um processo de modelagem dimensional é entender a necessidade do cliente. Não é muito evidente, mas o fato é que essas motivações são incompatíveis. Ainda não tenho um argumento finalizado e por enquanto eu recomendo a leitura das notas da apresentação BI E.V.A. – é o melhor que eu consigo no estágio atual.
Ainda não é uma Conclusão
Voltando ao curso do TDWI, o que é que eles oferecem? Uma outra abordagem ao processo de modelagem de dados? Não.
Um outro modelo de dados? Não.
Uma outra forma de tratar os levantamentos de requisito? Não. (Meu curso faz isso.)
Eles propõe “modelar apenas o suficiente para galvanizar o cliente e desenvolvedores ao redor de uma compreensão compartilhada do domínio do problema, arquitetura e modelo de dados”.
Ou seja: adotemos ágil e, na hora de construir o modelo de dados, vamos fazer apenas o mínimo para começar. Do que se depreende que desenvolvimento incremental, aqui, deve ser “uma dimensão por história”, “uma estrela por épico” ou coisa do tipo!
Foi exatamente o que eu tentei. Deu resultado, mas ainda não me permitiu os fantásticos ganhos de produtividade que Scrum normalmente proporciona. Leia “Scrum: a arte de fazer o dobro do trabalho na metade do tempo” para saber do que é que eu estou falando. ;-)
O que eu acabei descobrindo é que o que atrapalha o desenvolvimento ágil – incremental – é a dificuldade de expressar a necessidade do cliente de modo que permita correções e ajustes, o que acabou me levando a rever o problema por outro ângulo.
Então este é o estado do BI Ágil, hoje?
Claro, existe mais sendo feito por aí. Quem leu o Building a Scalable Data Warehouse with Data Vault 2.0, por exemplo, viu uma outra abordagem. Mas ainda não nasceu algo que verdadeiramente habilite a construção de projetos de BI e DW calcados nos fundamentos ágeis – melhoria contínua, incremental, articulada.
A busca continua! :-)
Geek BI 