Como capturar e documentar requisitos para projetos de BI gerenciados por métodos ágeis?
Ágil, Não Rápido
Quando Kent Beck, Martin Fowler, Ken Schwaber, Jeff Sutherland e toda patota declararam o Manifesto Ágil, eles não estavam preocupados com a velocidade do desenvolvendo de software, mas sim com a dificuldade cada vez maior em escrever bons produtos. Até início dos anos 2000, o paradigma de desenvolvimento de software era espelhado no paradigma de construção civil: ninguém assentava um tijolo até tudo estar absolutamente calculado e verificado.
É o mesmo que dizer que Romeu e Julieta foi escrito de uma vez, em algumas semanas, depois de Shakespeare passar alguns anos detalhando os personagens e a história. Não que eu seja especialista no processo criativo shakespeareano, longe disso! O que eu quero dizer é que construir paredes e escrever algo são atividades muito diferentes. Meu melhor exemplo são meus posts como exemplo: eu reescrevo cada post – inteirinho – pelo menos uma vez.
Imagine construir e derrubar uma parede até ela ficar perfeita. Imaginou? Bom, vá além: imagine construir e demolir uma casa inteira, até ficar como você quer. Ou pior: construir e vê-la desabar sobre o próprio peso vezes sem conta, até acertar a posição das vigas e conseguir que a centésima vigésima terceira encarnação da casa não caia só porque alguém bateu a porta da frente com força.
É ruim, hein! :-P
O cerne do conceito de desenvolvimento ágil não é a velocidade, mas a melhoria contínua.
Por isso no manifesto eles dizem que vêem valor em “processos, ferramentas, documentos etc.”, mas que vêem ainda mais valor em “indivíduos, colaboração, resultados etc.” Está lá, com todas as letras: trabalhar para obter um bom resultado é o que interessa. E não adianta trabalhar a toque de caixa, fazendo tudo nas coxas, só para chegar rapidamente ao final. O que interessa é avançar, melhorando continuamente e sem comprometer o futuro com decisões apressadas ou serviço mal-feito.
Inteligência de Negócios Ágil?
E como você trabalha melhoria contínua em Inteligência de Negócios? Como casamos BI com Ágil?
Eu venho estudando essa questão, meio que sem querer, já há alguns anos. Como sempre, tudo começou porque eu queria aplicar Scrum de qualquer maneira, custasse o que custasse! Eu havia acabado de ler Agile Project Management with Scrum, do Ken Schwaber, e estava louco para pôr em prática aquelas idéias. Era tudo tão simples, tão elegante, tão poderoso que eu precisava tocar um projeto com Scrum.
Tive uma sorte danada: havia acabado de receber um projeto e ele servia como uma luva em todas aquelas idéias. Aprendi tudo de Scrum, botei em prática, e o projeto funcionou muito bem.
Quer dizer, praticamente. Algums detalhes não deram muito certo:
- Automação de Testes: como você testa um ETL ou um relatório, continuamente? Como montar testes de regressão em um modelo dimensional?
- Histórias: como eu transformo a necessidade do cliente em uma história, e depois mapeio isso nas atividades típicas de um projeto de BI, como desenhar o modelo dimensional, desenvolver o ETL e construir um relatório ou painel?
- Refactoring: sério, refatorar um banco de dados?? Freaking how??
Ainda não encontrei uma resposta satisfatória para os testes. Já refatorar bases de dados, por incrível que pareça, é um problema que já foi resolvido: o livro Refactoring Databases disseca o assunto completamente. Estou lendo esse livro agora mas, pelo pouco que eu já li, posso dizer que ele é essencial para qualquer DBA que seja membro de uma equipe de desenvolvimento de software – ou BI – contemporânea. Leia!
Senta que Lá Vem História…
O que nos deixa no assunto deste post: levantamento de requisitos ágeis para Inteligência de Negócios.
Existem várias técnicas de levantamento de requisitos para projetos ágeis. A mais famosa, provavelmente, é o conceito de História: o cliente e a equipe de desenvolvimento constroem uma narrativa que incorpora a necessidade do cliente na forma de uma ação, de uma história. Por exemplo: “como gerente de vendas, eu quero poder ver as vendas deste mês dia-a-dia, quebradas por vendedor, produto e cliente”.
Essa foi a minha abordagem para aquele projeto. Funcionou, no sentido em que permitiu organizar o trabalho, quebrá-lo em partes e controlar a entrega. Por outro lado criou outros problemas. Exemplo? O tamanho, para começar. Quem já está acostumado com projetos de BI vê imediatamente que o cliente precisa de 1) um cubo OLAP com três dimensões, de vários níveis cada, ligadas a uma fato, tudo isso carregado por 2) um processo de ETL que leva os dados da origem a um 3) modelo dimensiona. Ou seja, uma única história dá origem a um Data Mart inteiro! É muito grande!
Outro problema é o que a própria história conta: há tantas formas de construir a apresentar esses dados que umas poucas linhas de texto é um canal muito “estreito” para enfeixar tantas possibilidades. Como adicionar detalhes? Escrevendo mais? E como fazer o cliente entender o que foi prometido e o que está sendo desenvolvido?
Eu cheguei a escrever sobre um problema relacionado à essa imprecisão: Cruel Sucesso. Para te poupar do esforço de lê-lo, resumidamente, quando você acerta na mosca, o cliente muda a demanda. Depois de algumas iterações acontecendo isso, o cliente desenvolve a sensação contrária, e passa a acreditar que o projeto nunca acerta! E, na minha opinião, isso acontece porque ele só entende claramente o que pediu quando recebe. E é neste momento que ele reavalia sua necessidade a refina. Entendeu? Não? Bom, então leia aquele post antes de continuar, hehe. :-)
Requisitos Para Gestão Ágil
Enquanto eu batia cabeça com isso eu tomei contato com outra técnica fantástica: Data Vault. Se você acompanha meu blog sabe o quanto eu sou apaixonado por DV.
De novo, louco para construir um DV e testar todas aquelas idéias, eu consegui um projeto perfeito. Não apenas pude aplicar Data Vault, mas o fiz com Scrum, o que foi duplamente satisfatório aliás. O resultado desta experiência virou o Primeiro Curso de Data Vault do Brasil. Estou evoluindo aquele material e em 2016 eu espero lançar uma versão definitiva, completa.
E foi deste material que eu puxei uma coisa muito interessante: uma técnica para levantamento de requisitos para projetos de BI. Não apenas qualquer projeto de BI, mas principalmente projetos gerenciados com alguma técnica Ágil, como Scrum ou Kanban.
Funciona assim: ao invés de escrevermos uma história, e depois quebrá-la em modelo de dados, ETL, apresentação etc., começamos anotando cruamente o que o cliente diz que precisa. Essas anotações são transformadas em protótipos que são revisados pelo cliente e ajustadas e revisadas e ajustadas etc. etc. … Em algum momento o cliente vai se dar por satisfeito e o último protótipo vira o requisito! Daí o resto é história: montar um documento que combine protótipo e a demanda do cliente em uma forma que ajuda a equipe de desenvolvimento e comunica claramente a expectativa do cliente.
4Shot Agile BI com Pentaho
Eu contei para vocês que eu comprei um apartamento? ;-) Agora eu tenho uma dívida de quarenta anos, e preciso fazer caixa. Por isso, quando uns meses atrás a 4Linux me apresentou o conceito de Shot e me perguntou se eu tinha alguma proposta, na hora eu apresentei a idéia acima.
Um Shot é um curso de curta duração (tipicamente um dia), focado sobre um único assunto e, em geral, voltado para um público específico. A 4Linux é, com certeza, o maior fornecedor de treinamentos em Software Livre e eu tenho a honra de ter produzido o treinamento Pentaho que eles oferecem (e de vez em quando ministro uma turma.)
Eu produzi um vídeo explicando melhor a idéia.
Semana que vem, dias 1, 2 e 3 de Setembro de 2015, ocorrerá a primeira turma deste Shot. As vagas são muito limitadas porque as turmas são propositalmente pequenas, de no máximo oito alunos. A idéia é oferecer um curso reforçado, intenso, e uma turma maior não permitiria isso. Também não é um assunto para principiantes. Não é nada esotérico, mas se esse vai ser seu primeiro curso em BI, bom, se prepare. ;-)
O curso inclui apostila e dois DVDs, com uma máquina virtual preparada para os exercícios, os exercícios resolvidos, templates, SQLs, backup de bancos e cópias de todos os softwares usados e mais alguns. E apesar de a propaganda dizer que ele é 80% prático, eu acabei fazendo um pouco mais – você não vai ter folga! Mas nem tudo será suor e teclados massacrados: como serão turmas presenciais, teremos o famoso coffee-break da 4Linux. :-)
Os leitores do blog que desejarem se inscrever terão um preço especial: R$199,00 contra R$299,00 do site. Para isso você precisa entrar em contato diretamente com Daniela Araújo (e-mail daniela.araujo@4linux.com.br) e contar que descobriu sobre o Shot no blog Geek BI.
Compre! :-D
Geek BI 