Como Modelar BI de Forma Colaborativa, Incremental e Iterativa

Você busca por mais agilidade em seus projetos analíticos e de BI? Está pensando em adotar metodologias ágeis a estes projetos? Atenção, para ter sucesso antes faz-se necessário conhecer e identificar o que há de melhor e mais novo sobre adaptação de metodologias ágeis neste campo, buscando combinar e conciliar diferentes abordagens, compreendendo onde cada uma funciona ou não, e então adaptar a sua própria realidade.

Para ajudá-lo nessa jornada, dei início a uma série de artigos sobre o tema, apresentando diferentes práticas ágeis de BI e Analíticas comprovadas, sobre as quais baseio o método que utilizamos aqui na Vitarts e que abrange todo o ciclo de vida do produto de BI.

O primeiro artigo lançou um olhar sobre a perspectiva da gestão de projetos de BI de acordo com a adaptação do método Scrum. Agora vamos um pouco mais fundo, tratando da aplicação de métodos ágeis às fases que antecedem ao projeto.

Neste campo, a melhor adaptação, que considero leitura obrigatória sendo um verdadeiro livro de cabeceira, é a de Lawrence Corr e Jim Santiago (Agile Data Warehouse Desing: Collaborative Dimensional Modeling, from Witeboard to Star Schema.  Burwwod House, Leeds, UK:  DecisionOne Press, 2011). Nela, os autores também fazem uso do Scrum e do XP, inserindo aos mesmos a sua abordagem de modelagem colaborativa, incremental e iterativa, viabilizando a aplicação destes métodos as fases anteriores ao projeto em si.

Comecemos falando sobre a estratégia a ser adotada para identificação das histórias de usuários. Sobre isto, Ralph Hughes (2012, página 139), autor do livro base do artigo anterior, diz:

“A estratégia mais comum da comunidade de desenvolvedores ágeis ao escrever as histórias de usuários está baseada em não 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 história entra em desenvolvimento.”.

Hughes embasa sua posição ressaltando a complexidade de se tratar estas questões dentro do ciclo de desenvolvimento, onde nem sempre o product owner terá conhecimento de todo o processo de negócio, desconhecendo “onde” e “quando”, ou fazendo com que a equipe caia rapidamente em discussões intermináveis de “como”, sendo um esforço mais adequado a projetos de reengenharia de processos de negócio.  O autor finaliza reconhecendo que uma dupla de líderes da equipe pode vir a trabalhar na modelagem de alto nível destes pontos durante as story confereces, mas reforça que isto deve ser um objetivo secundário, mantendo-se o foco em Who, What e Why.

Contrariando Hughes, Corr e Santiago apresentam uma proposta de desenho de BI/DW a luz de técnicas de modelagem dimensional colaborativas, o que permite a descoberta e priorização das iterações sob a perspectiva de histórias de dados, que descrevem os eventos e dimensões de negócio capturados diretamente em um quadro branco, sob a forma de exemplos de dados de acordo com uma sequência lógica definida pelos 7Ws ou 5W2H (Who, What, When, Where , How Many , Why e How).

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

Os autores descrevem em detalhes seu método de Business Event Analysis & Modeling (BEAM), que tem por foco uma abordagem ágil para a modelagem dimensional, com a finalidade de melhorar a comunicação entre os designers de DW, equipe de projeto e todas as demais partes interessadas, tornando-as mais interativas através de um processo de modelagem mais inclusivo e colaborativo, afirmando que:

“O resultado é que todo mundo pensa dimensionalmente desde o início! ”.

Como os autores focam essencialmente nas questões técnicas do processo colaborativo de modelagem dimensional, eles não se aprofundam nas questões da arquitetura, deixando isso para outros já consagrados autores neste campo, em referência direta a obra de Ralph Kimbal e Joe Caserta (Data Warehouse ETL Toolkit.  New York, NY, Estados Unidos: John Wiley & Sons, Inc., 2004)

A partir desta referência, Corr e Santiago afirmam que:

“A busca por atingir o princípio á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 negócios envolvidas”.

Infelizmente, apesar dessa prática conduzir a entregas rápidas e de valor, departamento a departamento, essas conduzem o desenho da solução para formação de silos de DMs, que posteriormente se apresentam como débitos técnicos e soluções não sustentáveis.

Para evitar a formação de DM em silos e reduzir débitos técnicos, Corr e Santiago determinam que os designers e arquitetos devem estar atentos a que o modelo atenda tanto o desenvolvimento da iteração atual quanto das futuras.  Para isso, eles acreditam ser suficientes a adoção dos conceitos de conformidade e da arquitetura definidos por Kimball (The Data Warehouse Toolkit: Practical techniques for building dimensional data warehouses. 2nd ed.  New York, NY, Estados Unidos: John Wiley & Sons, Inc., 2002), sendo necessária a identificação e definição de todas as dimensões e mediada conformes.

Para a alavancagem de princípios e valores ágeis na modelagem dimensional, Corr e Santiago tratam do cumprimento do princípio “maximização do trabalho não feito”, assim como no atendimento do valor ágil de “Software funcionando acima de documentações abrangentes”, através do emprego de cinco (5) tipos de diagramas os apresentando em detalhes, especificando o seu uso, nível do tipo de modelo de dados empregado, audiência e os principais capítulos onde os mesmos são detalhados em sua obra.

Diagramas propostos pelo método BEAM

Diagrama	Emprego
Tabela BEAM®	Modelagem dos eventos de negócio e suas dimensões de análise, uma por vez, fazendo uso de exemplos de dados que documentam os seus detalhes através da exposição dos 7Ws.
Gráfico de Hierarquia	Descoberta dos padrões de hierarquias e sua relação com as dimensões e atributos para a análise dimensional. Contribui também para a identificação de requisitos técnicos para a definição de percursos de análise (drill) e níveis de agregação.
Linha do Tempo	Descoberta acerca dos aspectos relacionados à sequência dos processos, ou relacionamento entre eventos, identificando medidas de tempo como a duração e de performance.
Matriz de Eventos	Documenta a relação entre os eventos e as dimensões de análise, através de uma matriz onde os eventos são dispostos de acordo com a sequência da cadeia de valor. A mesma viabiliza a visão geral de todo o DW, ou de múltiplos DMs, permitindo o reuso das dimensões de análise e o registro de seu grau de conformidade.
Esquema em Estrela Aprimorado	Permite a visualização dos modelos em forma dimensional, assim como a geração do seu respectivo modelo físico. Por aprimorado, compreende-se o emprego das abreviaturas de definições das propriedades dimensionais e de técnicas de desenho propostas em BEAM® e não suportadas pelos pacotes de modelagem de dados.

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

Note que a matriz de eventos proposta trata-se de uma ferramenta de modelagem e planejamento, que documenta as relações entre os eventos de negócios e as dimensões de análise.  A mesma atua como story boards para o desenho de todo o DW, apresentando apenas os detalhes suficientes para auxiliar a identificação dos processos de maior valor agregado e as respectivas dimensões deste processo, assim como o seu uso por outros processos.

Em virtude do reuso e necessária harmonização, é preciso atenção a conformidade na modelagem das dimensões e indicadores, o que pode ser atingido através da priorização dos eventos de maior valor para o seu desenvolvimento.

Além disso, ao listar os eventos nessa matriz de acordo com uma sequência de tempo em que estes ocorrem, assim como ao registrar as respectivas medidas de criação e destruição de valores, fica claro o alinhamento desta abordagem aos pressupostos da cadeia de valor de Michael Porter (Competitive Advantage: Creating and Sustaining Superior Performance. New York, NY, Estados Unidos: The Free Press, 1985), permitindo também a descoberta de eventos ausentes, devido à identificação de grandes gaps de valor, tempo ou ações no fluxo de processos.

Com isso, os arquitetos e designers do projeto conseguem controlar e melhor desenvolver as soluções de forma alinhada aos processos de negócio, facilitando o processo de priorização das iterações a serem desenvolvidas, tanto por critérios mais objetivos de valor agregado, quanto por subjetivos relacionados a identificação de alinhamento com a estratégia do negócio.

De acordo com Corr e Santiago, no caso da adoção do Scrum:

“A equipe tende a supor que toda a priorização deve ser conduzida apenas junto ao product owner, que gerencia o respectivo product backlog”.

Entretanto essa abordagem não supre as necessidades de priorização de um programa de BI que contemple toda a organização.  Por esse motivo os autores sugerem que um time representativo, com reconhecida liderança e poder na organização atue como um representante do product owner.

Então, para a priorização das iterações, eles estabelecem um conjunto de regras a serem conduzidas através de uma reunião, por eles denominada de jogo de ranqueamento de eventos.  Esta reunião tem início questionando-se aos stackholders a importância de cada evento, segundo as seguintes regras:

• Todos os eventos devem receber notas;
• As notas seguem uma pontuação incremental de 100 em 100, permitindo gaps de pontuação que viabilizam o desempate através de notas obtidas por outros critérios;
• A distância revelará apenas a diferença de importância atual entre os eventos, não sendo uma medida relativa de valor ao negócio em si;
• Todos os eventos devem possuir uma nota diferente uns dos outros, exceto:
  • Eventos que já foram entregues em iterações anteriores recebem nota zero;
  • Eventos cuja importância atual não é significativa devem receber nota 100.

Segue-se a mesma questionando-se a atribuição de notas de importância para cada dimensão envolvida com os eventos identificados, através das seguintes regras:

• As notas devem ser incrementais na ordem de 5 ou 10 pontos de importância;
• As dimensões conforme devem, obrigatoriamente, receber notas maiores do que as não conformes;
• As dimensões devem ser ranqueadas com notas superiores a nota de importância do respectivo evento relacionado;  Qualquer dimensão deve ser ranqueada com uma nota de menor importância do que a maior nota do evento não utilizado mais próxima da nota do respectivo evento associado à dimensão em questão;
• É atribuída nota zero as dimensões que já tenham sido entregues em iterações anteriores;
• Caso a importância do evento mude, todas as notas de dimensões a ele relacionadas devem ser alteradas.
• Ao final, obtêm-se a priorização dos eventos em respectivas dimensões de forma ordenada em um único product backlog.

Após essa reunião, um product owner, designado para a iteração priorizada, pode ainda promover ajustes na mesma baseado nos resultados dos data profiling e no retorno das estimativas e da execução das atividades da equipe de desenvolvimento.

Corr e Santiago ainda determinam que a essa lista também deve ser acrescido a lista de requerimentos de relatórios e painéis, que devem também sofrer priorização.  Essa priorização pode vir a ser conduzida pelo comitê anterior ou apenas pelo product owner responsável pela iteração devidamente priorizada pelo processo anterior.  Para eles a priorização dos requisitos de relatórios e painéis deve ser atribuída antes do início de desenvolvimento, para a qual são concedidas notas decrementais a nota do respectivo evento a ela associados, na ordem de 5 ou 10 pontos de importância.

Antes de conduzir o início do planejamento da iteração priorizada, ressalta-se a necessidade de se proceder antes com uma revisão minuciosa do modelo e da matriz de eventos, iniciando pela identificação de suas origens de dados, seguindo-se pela aplicação de técnicas ágeis de data profiling e confirmação dos resultados com a adequação do modelo.  O resultado servirá de base tanto para estimativas, através de planning poker, quanto revisão das prioridades, caso necessário, assim como para dar ciência aos stakeholders do que será realmente possível obter com a próxima iteração.

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 condução do projeto, revisando junto a equipe as estimativas com base nos detalhamentos destas tarefas, com as quais a equipe se comprometerá a entregá-las nesta iteração.

Sobre a perspectiva do princípio de “maximização do trabalho não feito” e para o atendimento ao valor de “Software funcionando acima de documentações abrangentes”, Corr e Santiago também recomendam que toda a solução seja prototipada o mais breve possível, já com o objetivo de viabilizar a validação do desenho através da análise de dados reais, disponibilizados através da ferramenta de BI.

“Não perca tempo elaborando especificações e mocking up de relatórios e painéis em Word ou Excel, quando você dispuser do esquema de dados, amostra de dados, ferramentas de BI e stakeholders para avaliar os resultados como opção.”.

Em segundo lugar, o processo de desenvolvimento iterativo obriga uma seleção constante das informações e funcionalidades prioritárias, o que ajuda a minimizar o problema da equipe gastar tempo e recursos em desenvolvimentos que nunca, ou raramente, serão utilizados, como comumente acontecem com as abordagens com base em BDUF.

Para isso, é essencial o emprego das técnicas de modelagem ágil e de prototipação, uma vez que estas promovem a ruptura das barreiras entre os profissionais de BI e stakeholders, que passam a focar na elaboração colaborativa de modelos de dados compreensíveis e compiláveis, ao invés de documentos de requerimentos, assim como em protótipos de relatórios e painéis ao invés de mockups.

Os pontos anteriores, quando somados à proposta de emprego das técnicas ágeis de data profiling, permitem não somente melhorar estimativas, mas acabam por contribuir para a melhoria da qualidade da solução como um todo, visto que regras, comportamentos e características dos dados capturados na forma de exemplos podem ser conferidos diretamente contra os dados reais das origens da futura solução.

Além disso,  a sua proposta colaborativa com o devido emprego de seus diagramas e atenção a conformidade de indicadores e dimensões,  contribuem para a captura dos requisitos essenciais,  ao passo que atendem ao princípio de “Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.”,  assim como dão suporte aos valores ágeis de “Interações e indivíduos acima de processos e ferramentas”, “Colaboração com o cliente mais que negociação de contratos” e “Software funcionado acima de documentações abrangentes”.

Em terceiro lugar, a contínua seleção de conjuntos reduzidos e priorizados de informações e funcionalidades através dos jogos de ranqueamento de eventos, oferece uma maior garantia de que o tempo e os recursos gastos na sua implementação terão uma melhor relação de custo/benefício, já que o conjunto de informações e funcionalidades pouco utilizadas deverá ser mínima e os benefícios terão sido adequadamente mapeados.

Desta maneira, a abordagem de Corr e Santiago contribuem para a solução dos problemas críticos referentes à percepção de “Burocracia e Distanciamento do Cliente” e da “Dificuldade de priorizar demandas de BI através de critérios quantitativos e qualitativos”, que tanto as abordagens tradicionais de desenvolvimento de BI quanto os processos formais de gestão de demanda e portfólio costumam enfrentar.

Além disso, os diagramas propostos pelo método BEAM também trazem mais clareza ao nível de especificações 80/20 desejado por Hughes, consistindo em importantes aceleradores para os projetos de desenvolvimento de soluções de BI, servindo mais ao propósito de rapidez na inicialização.

Por outro lado, Hughes propõe a quebra das histórias de desenvolvimento em tarefas de desenvolvimento que, por sua vez, devem ser agrupadas em pacotes que permitam quebrar os requisitos de dados em entregáveis aceitáveis pelos usuários nas diversas camadas de arquitetura necessárias, sendo esta mais uma complementaridade entre os autores, elevando o emprego de métodos ágeis a projetos de BI.

Deve-se ressaltar que toda a abordagem de Hughes da maior cobertura a condução do projeto em si, oferecendo estratégias de condução assim como medidas qualitativas e quantitativas do processo de condução, da performance das equipes e dos resultados obtidos com os projetos.

Portanto, é possível adotar a abordagem de Hughes a condução do ciclo de vida do projeto sem grandes requisitos de mudança, reduzindo o tempo de entrega de versões funcionais da solução, porém mantendo-se a atenção à conformidade, as mudanças de requisitos e ao controle efetivo dos débitos técnicos, com isso, acelerando-se a percepção de valor através da captura de benefícios parciais rapidamente.

Já a obra de Corr e Santiago pode ser encarada exatamente como o elo necessário entre a fase de gestão do programa de BI e a condução do projeto em si, através de um método adequado que permite a identificação e priorização de demandas de BI, assim como das respectivas iterações a serem conduzidas sob a perspectiva de modelagem de dados dimensional, contribuindo para a formação da cultura de BI, fazendo com que a organização “pense dimensionalmente”.

Com isso, conclui-se que as duas obras são complementares, provendo maior abrangência a adaptação de metodologias ágeis aos projetos de BI e Analíticos. Além disso, como vimos Corr e Santiago de fato estabeleceram um conjunto necessário de referências e práticas que induzem ao emprego de técnicas colaborativas para concepção de uma solução de BI a ser construída de forma incremental, iterativa e evolutiva.

Por fim caro leitor, você deve ter percebido que ambos os autores não lidam diretamente com as questões técnicas. Onde Huges afirma que nada muda e Corr e Santiago se apoiam sobre suas recomendações baseadas nas obras de Kiball. De fato, a adoção de um método ágil deve sobretudo impactar mais o comportamental e a cultura já que, em excelência, trata-se principalmente de uma abordagem de gestão. No entanto, como pudemos ver, ambos os autores se preocupam como os débitos técnicos e dão ênfase a sua gestão e tratamento, sendo este o tema para nosso próximo artigo onde, então, passamos a aprofundar um pouco mais nas questões técnicas.

Até lá…!