A gestão do BI através de todo ciclo de vida de produto já apresenta inúmeros desafios em si, onde os métodos tradicionais pré-descritivos, também conhecidas por cascata, “ciclo de vida clássico”, “BIG BANG”, “plan-driven”, “single-pass”, “Big Design Up Front” (BDUF) ou simplesmente por “abordagem de entrega única”, embora intuitivas e de fácil gerenciamento, não são suficientes, expondo uma série de problemas críticos decorrentes dessa abordagem.

Em resposta, a prática ágil de BI prima por um processo de entrega baseado em melhoria contínua, através de uma abordagem iterativa temporizada que encoraja uma resposta rápida e flexível à mudança. Essa reduz os problemas críticos, ao passo que acelera a captura do valor percebido de uma solução de BI de qualidade entregue de forma iterativa, incremental e evolutiva.

De acordo com a Forrester Research, o BI ágil trata-se de:

“uma abordagem que combina processos, metodologias, ferramentas e tecnologias, ao mesmo tempo em que incorpora estrutura organizacional, para ajudar os decisores estratégicos, táticos e operacionais a serem mais flexíveis e mais receptivos aos requisitos comerciais e regulamentares em constante mudança“.

Dada a abrangência e complexidade da definição anterior, noto que de fato embora existam muitas abordagens de BI ágil já publicadas, não conheço até a elaboração deste artigo, nenhuma proposta que realmente cuide de todo o ciclo de vida do produto de BI.

Com isso em mente, a cerca de pouco mais de 7 anos, venho estudando e aplicando tais conceitos e métodos, e por experiência, afirmo que antes que você possa adotar metodologias ágeis com sucesso a seus projetos de BI e analíticos, faz-se necessário conhecer e identificar o que há de melhor e mais novo sobre adaptação de metodologias ágeis para BI, buscando combinar e conciliar diferentes abordagens, compreendendo onde cada uma funciona e não, e então adaptar a sua própria realidade.

Para ajuda-lo nessa jornada, dou início aqui 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.

Para começar, vamos lançar um olhar sobre a perspectiva da gestão de projetos de BI de acordo a adaptação do método Scrum. A melhor adaptação que encentrei e pratiquei é a da obra de Ralph Hughes (Agile Data Warehouse Project Management: Business Intelligence System Using Srum).

Nela, o autor estabelece os pilares de sua abordagem, através de um conjunto de práticas á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 usuários de negócio daquilo que de fato desejam ter, até que vejam algum produto disponível em produção.

Partindo do fato de que quanto maior for à complexidade das demandas de integração e tratamento de dados, maior será a complexidade de adequação de métodos ágeis ao BI, Hughes subdivide sua obra em três partes:

  • Na primeira parte são apresentados os alicerces dos métodos iterativos e incrementais, de que forma esses se diferenciam dos métodos tradicionais e como um Scrum genérico pode ser aplicado diretamente a projetos mais simples de BI, desde que esses compreendam apenas os objetos de interação direta com o usuário, como relatórios e painéis. Desta forma, Hughes busca introduzir o leitor na aplicação prática do método Scrum a um projeto simples de BI, sem muitas adequações a serem empregadas ao método.
  • Já na segunda parte, o autor estabelece uma série de adaptações que visam tratar dos projetos que apresentam demandas de integração e tratamento de dados de baixa complexidade, conduzindo-os através da decomposição de histórias de usuário, provenientes da aplicação do método Scrum genérico, em histórias de desenvolvimento e essas, por sua vez, em tarefas de desenvolvimento, que são, então, empacotadas em uma série incremental de entregas aceitáveis pelos usuários.
  • A parte três conclui a obra através da exposição de uma abordagem de adaptação que torna o processo colaborativo ágil mais aderente a projetos que apresentam grandes desafios de integração e tratamento de dados, assim como de sua evolução.

No entanto, Hughes não detalha os aspectos técnicos de BI, declarando que praticamente nada muda neste campo, sendo apenas necessário o emprego de técnicas de monitoramento e tratamento de eventuais débitos técnicos, assim como maior ênfase aos testes, que tem de ser mais integrados ao processo de desenvolvimento, portanto mais padronizados, automatizados e aplicados desde o início do clico de desenvolvimento e não apenas ao seu final como ocorrem nos métodos tradicionais.

Estes débitos técnicos são comumente decorrentes de escolhas de desenho de solução inadequados às necessidades futuras em função da eventual falta de uma visão abrangente ou por erros técnicos da equipe de projeto, sobretudo, na condução de especificações que não atendem as exigências de uma cobertura 80/20, erros no desenvolvimento identificados tardiamente ou quando pressões por prazo ou performance são privilegiadas em detrimento da qualidade.

A fim de tratar destas questões, recomendam a adoção do TDD (Test-Driven Development) para a integração dos testes ao processo de desenvolvimento, assim como a sua automação, tornando possível a abordagem evolutiva ao fornecer meios confiáveis e eficientes para suportar a solução de BI, permitindo que defeitos não se acumulem, reduzir o débito técnico, tornar a verificação da qualidade do produto e sua comunicação um processo frequente.

Para tal, Hughes incorpora em sua abordagem processos voltados a monitoração, identificação, priorização e correção o mais breve possível dos débitos técnicos ao longo das iterações, estabelecendo técnicas e ciclos de procedimentos para a condução de sua correção de acordo com as premissas ágeis, tratando-os de acordo com a sua complexidade e momento dentro de cada iteração.

Outra abordagem interessante vem de Ken W. Collier (Agile Analytics: A Value-Driven Approach to Business Intelligence and Data Warehousing), que recomenda a dedicação de iterações especificas para tratamento dos débitos técnicos, ou alocar uma porcentagem de tempo em cada iteração para este fim.

A figura a seguir permite visualizar um diagrama que resume a abordagem Hughes para adaptação do método ágil na condução de projetos de BI.

Fonte: Hughes (2012, p.326)

Neste diagrama, à direita, podem ser vistos os principais desafios de projetos de BI, que dizem respeito aos problemas críticos e típicos de projetos de BI conduzidos sobre técnicas tradicionais. O primeiro desafio diz respeito à percepção de que os projetos de BI são muito lentos e caros. O segundo está relacionado à dificuldade dos usuários em definir o que realmente desejam antes de terem visto algo em produção.

A esquerda dos desafios, o diagrama apresenta os principais objetivos a serem atingidos na aplicação de sua adaptação de técnicas ágeis. Os objetivos definidos dizem respeito a:

  • Maior rapidez na inicialização de projetos;
  • Elevar a participação do cliente em revisões frequentes;
  • Falhar rápido e corrigir rapidamente;
  • Atingir elevados níveis de qualidade;
  • Elevar a precisão das estimativas;
  • Elevar a agilidade de percepção de valor;
  • Promover a melhoria continua;
  • Entregar constantemente e frequentemente;
  • Melhorar a produtividade dos programadores;
  • Reduzir os custos de desenvolvimento.

Através deste diagrama, nota-se ainda, que esses objetivos apresentam inter-relações, o que deixa claro a dificuldade em atingi-los sem um adequado planejamento e um prazo razoável e suficiente para que os mesmos possam ser calibrados e atingidos ao longo do tempo.  O próprio autor destaca que as três primeiras iterações deverão apresentar grande dificuldades, sendo necessário um forte patrocinador que compreenda e possa advogar favoravelmente pela adaptação frente as questões que surgiram, assim como uma forte gestão de mudanças, sobretudo junto a equipe e sua aceitação de adaptação ao método.

Finalmente, à esquerda estão destacadas as respectivas técnicas ágeis sugeridas para atingimento de cada um destes objetivos.

A partir deste ponto, fica claro que o requisito por maior agilidade impacta na adoção de uma série de inovações e técnicas ágeis. Contudo, Hughes destaca que não é possível atingir a maior velocidade possível de entrega das soluções de BI de uma só vez. Por este motivo, o autor inclui noções como melhoria contínua e entregas constantes e frequentes, o que sugere a adoção de uma abordagem iterativa, incremental e evolutiva.

Além disso, o autor ressalta que o requisito de maior velocidade nas entregas impacta diretamente no desenho e condução da solução, dada as dependências técnicas e de dados, agravando a necessidade de estimativas ainda mais precisas, o que nos conduz ao um objetivo de busca contínua por maiores níveis de qualidade.

Hughes ainda apresenta, neste mesmo diagrama, algumas sugestões de métricas para medir a eficácia e eficiência da aplicação da sua proposta de adaptação, relacionando-os ao que ele considera serem os principais objetivos e práticas ágeis. A seguir é apresentado o resumo das definições de tais métricas:

Qualidade da passagem de bastão (Quality of hand-offs)

Mede a qualidade da transferência de conhecimento e trabalho entre as partes envolvidas. Dois aspectos importantes levam a necessidade desta medição:

  • As características de especialização dos recursos, comuns aos projetos de BI, que resulta em uma condução do pipeline por frentes de trabalho;
  • O requisito de maior velocidade para inicialização do desenvolvimento, que orienta a equipe a produzir especificações mais leves e focadas em apenas 80% dos aspectos mais importantes de cada módulo.

Comparação entre os métodos:

“Praticantes de métodos ágeis sugerem pelo menos 40% de vantagem sobre a produtividade obtida através dos métodos tradicionais para um primeiro projeto, apesar de poder ser atingido 70% caso a equipe de liderança tenha significante experiência com os métodos de warehousing ágeis. ” (HUGHES, 2012, p.334).

O autor ressalta que as primeiras iterações podem vir a apresentar dificuldades que impeçam de observar tais resultados. Por estes motivos, é importante estabelecer uma medida do comparativo entre os dois métodos, sendo a “quantidade de horas de programação por objeto de dados de destino” a mais fácil de obter.

Defeitos por Iteração:

O tempo necessário para a correção de alguns defeitos pode ser superior ao restante do prazo para finalização da iteração. Neste sentido, o autor sugere a adoção de gráfico de barras acumulativas para rastreamento destes defeitos, que devem ser agrupados pela iteração em que foram identificados, atribuindo assim maior visibilidade a gestão destes defeitos e criando as condições para que a equipe busque a melhoria continua, reduzindo tanto o número de defeitos quanto o tempo de sua correção.

Qualidade das Estimativas:

“Esta métrica é definida pelo número total de horas de trabalho originalmente estimado, para as tarefas contidas nas histórias aceitas em cada demonstração de usuário, divididas pelo total de horas realizadas por todas as atividades incluídas na iteração, após subtrair do numerador as horas estimadas para cuidar de qualquer débito técnico na próxima iteração.“ (HUGHES, 2012 p.330).

Distribuição de Pontos de Histórias:

Indica o número de histórias contidas no project backlog para cada nível de pontuação das respectivas histórias de desenvolvimento. Com este indicador, a equipe pode maximizar a sua velocidade otimizando seu processo para a pontuação que apresentar maior concentração, assim como verificar o quão consistente a mesma está sendo ao definir as suas histórias de desenvolvimento,  a partir da confrontação com os resultados obtidos.

Distribuição dos Prazos dos Ciclos:

Mede o número de dias desde o momento em que a equipe pega uma história 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 nível mínimo para cada tamanho de história de desenvolvimento, que passa a ser referência do tempo necessário para que equipe, já em alta velocidade, transforme um pedido de funcionalidade em software funcionando.

Prazo de Liberação:

Mede o número de dias desde o momento em que uma história é inserida no product backlog e a mesma passa pelo teste integrado.

Burn-up Chart:

Gráfico de barras verticais acumulativas que demostra o número de pontos entregues por iteração, mais o total de pontos de histórias de desenvolvimento que ainda estão em progresso na mesma iteração.

Quanto a formação da equipe de projeto, para Hughes os papéis, como definidos no Scrum, são insuficientes, sobretudo dado a abrangência de conhecimentos e tecnologias envolvidas em projetos de BI, assim como pelas especializações dos recursos disponíveis no mercado. De acordo com Hughes são necessários os seguintes papéis adicionais:

Arquiteto do Projeto:

Responsável pela entrega da solução dentro do prazo e custo esperados, pela criação e manutenção da visão geral da solução, atuando como um facilitador do projeto comunicando-se tanto com as áreas de negócio quanto com a equipe técnica.  Dito isto, fica claro que o Arquiteto do Projeto pode também desempenhar as funções do Scrum Master,  porém ele deve ir além, focando no adequado levantamento e entendimento dos requisitos, desenho da solução e na verificação da qualidade dos artefatos produzidos pela equipe, responsabilizando-se por toda a equipe e todo o projeto.

Embora os métodos ágeis enfatizem equipes auto-organizadas e colaborativas, dadas as características únicas de projetos de BI, este recurso deve ter algum nível de poder sobre os demais integrantes, preferencialmente não por uma hierarquia formal e declarada, mas sim devido a sua experiência e conhecimento. De acordo com Hughes, esta característica é fundamental, sobretudo quando as equipes não trabalham como esperado, o que é comum nas primeiras iteração de projetos, requerendo um liderança mais forte do Arquiteto de Projetos, o que também seria facilitado caso haja uma formalização 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 experiência em métodos de arquitetura para desenho e análise de dados. Antes mesmo de projetar o modelo de dados de cada uma das camadas técnicas de bancos de dados necessárias, o modelador de dados deve atentar para que o desenho da camada semântica esteja claro e que tenha tratado de todos os conflitos entre as definições de negócios das diversas áreas, dado que esta camada deve ser construída de acordo com a visão e definições do negócio e será a camada que de fato será acessada diretamente pelos usuários.

Este recurso deve atuar como um consultor especialista, capaz de orientar a equipe no adequado balanceamento dos aspectos técnicos de modelagem de dados entre o paradigma de um único DW (data warehouse), como a visão do todo e a sua composição por modelos distintos, porém complementares, distribuídos em camadas de arquiteturas com funções especificas de estagio, integração, apresentação/dimensional, semântica e consumo/ dashboards.

Além disso, ao detalhar o papel do modelador de dados, Hughes deixa claro que é necessário a atuação de um especialista no ramo de modelagem de DW, não apenas de dados, visto as suas considerações quanto a correta definição de granularidade e a necessidade deste profissional estar atualizado em relação ao emprego de novas e avançadas técnicas, 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:

Responsável pela especificação das transformações 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, a fim de promover análises de perfis de dados em porções relevantes dos sistemas de origem. O mesmo é responsável por compreender as histórias de negócio e os seus desdobramentos em transformações que conduzam os dados de uma camada da arquitetura para a outra, gerando assim as especificações de mapeamento de origens para destinos. Este profissional ainda deve estar atento ao ciclo de vida da informação nos sistemas de origem e as questões que afetam a qualidade de dados.

Analistas de Testes:

Responsável por detalhar o plano de testes de alto nível gerado pelo Arquiteto do Projeto. O mesmo deve atentar ao fato de que em projetos ágeis deve haver apenas o mínimo de documentação, portanto, este recurso deverá levantar junto aos demais integrantes da equipe os corretos casos de testes, como por exemplo, testes unitários junto aos programadores, histórias de testes junto ao Product Owner e testes funcionais e não funcionais junto aos demais membros da equipe. De fato, este recurso acaba por ser o responsável pela padronização.

Quanto aos problemas do processo de adaptação do BI ao método ágil em si, o principal problema a ser considerado dever ser a adequada escolha da equipe, sua adaptação e a adaptação da organização as profundas mudanças que se farão necessárias.

Em relação à equipe, de maneira análoga às dificuldades encontradas pelos métodos ágeis em outras aplicações, as pessoas detêm formações culturais diferentes e costumam oferecer resistência a utilizar novas ideias que fujam aos conceitos tradicionais, formados a longa data, normalmente denominadas por “melhores práticas”, dado o reconhecimento de que “funcionam”, embora, como visto, apresentem grandes taxas de insucesso.

Na medida em que o volume de soluções entregues cresça, a designação dos recursos específicos ao BI se auto justificará. Contudo, caso a organização promova uma montagem insuficiente da equipe, ou deixe a alocação de algum recurso para mais tarde, pode haver dificuldades significativas na condução dos projetos, assim como será certo que haverá dificuldades na operação e sustentação das soluções.

Tais problemas podem ser, mas não se restringem a:

  • Perda do conhecimento desenvolvido no projeto;
  • Perda do prazo;
  • Perda da confiabilidade da solução devido a débitos técnicos;
  • Débitos técnicos graves ou em grande número, devido a um processo de identificação e monitoração falho ou de baixa continuidade e periodicidade.

Neste sentido, sugere-se que os mesmos sejam designados desde cedo, fazendo uso do tempo livre nas primeiras interações para desenvolvê-los nos potências gaps de conhecimento.

Por fim, uma vez que a obra de Hughes pressupõe que já existem histórias de usuários a serem desdobradas em histórias de desenvolvimento, fica difícil para o leitor imaginar um processo de adaptação do BI ágil, sem antes prever a adaptação da própria organização a cultura ágil, assim como por gerir as mudanças que se farão necessárias para introduzir o BI na organização e/ou elevá-lo a maiores níveis de maturidade.

Não obstante ao fato anterior, devemos ainda ter atenção às necessidades de adaptação em termos de Brasil. Deve-se observar que muitas organizações brasileiras ainda consideram a implementação de um projeto de BI como muito complexo, havendo ainda muitas empresas nos dois primeiros níveis de maturidade. Além disso, a adoção de métodos ágeis e de refatoração de modelo de dados pelas organizações brasileiras também ainda é tímida.

Para concluir, 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.