Usando o desenvolvimento orientado a hipótese com Azure DevOps

Lembrando que o HDD é um processo orientado a hipótese com foco principal em validação das ideias sob a perspectiva de geração de ROI e satisfação dos usuários. Para isso, um processo maduro de CI (Continuous Integration) e CD (Continuous Deployment) habilita a esteira de validação de ideias e suporte imediato.

Ao formular as hipóteses, utiliza-se os conceitos da experimentação, e por isso a user story é insuficiente para verificar se a hipótese está correta. Na HDD criada, existe uma validação de hipótese referente a uma campanha promocional que pode aumentar a taxa de conversão.

Iniciando a implementação do HDD em um time cross functional – Desenvolvedores, UX, SM (Scrum Master), PO (Product Owner) e QA, precisando validar uma ideia de plataforma de inscrição online para um evento. Algumas discussões surgiram durante a fase de inception para criação do produto:

  • E se uma campanha promocional estiver disponível durante 2 semanas? Talvez melhore a taxa de conversão? Os usuários que não aproveitarem a promoção podem repercutir negativamente?
  • E quanto isso custa? Você consegue estimar?
  • E se ao invés de estimar, checarmos se vale a pena implementar? Acredito que realizando testes A/B podemos verificar a aceitação do público. E se aumentarmos a conversão em 10% já valeria a pena implementar.

E como ficaria tudo isso criando histórias de hipóteses (ao invés de histórias de usuários):

HDD-azure-devops-01

We believe that uma campanha promocional de 2 semanas
Will result in
melhoria na conversão da inscrição
We will know we have succeeded when evoluirmos a taxa de conversão em 10% do início ao final da campanha promocional.

E assim, o Product Owner prioriza este desenvolvimento com o time e a implementação deve ocorrer em breve para confirmar se a hipótese irá gerar o valor idealizado. O time começa então a execução do backlog em gestão ágil com práticas CI/CD e apoio total do time de UI/UX para criação dos layouts e experiência do usuário. O resultado do primeiro protótipo foi aprovado e esta é a versão colocada em produção:

prototipo-marven

E após as duas semanas, verificando o progresso diariamente da conversão, o objetivo foi alcançado. Nesta jornada, foi muito importante o mindset ágil da empresa, operando com práticas DevOps e arquitetura bem estruturada que possibilitam a inovação de produtos. Ao confirmar a hipótese, podemos adotar um exemplo de aumento em receita de R$ 78.000, justificando assim um desenvolvimento na plataforma de 160 horas para implementação desta funcionalidade.

 

Cases de sucesso

A empresa Hello Group apresentou o uso do HDD com outras técnicas como Google Design Sprints e os livros Lean UX e The Innovator’s Hypothesis para validar hipóteses no mercado, aplicando quatro etapas: 1- Verbalize as hipóteses de que sua ideia é baseada 2- Definir a hipóteses mais críticas que pode ser testada com o menor esforço 3- Faça um plano de como testar sua hipótese 4- Descarte ou ajuste sua ideia.

Outra case de Desenvolvimento Orientado a Hipóteses é da empresa Lastminute.com, divulgado pelo CEO Tom Klein da Sabre Holdings, em que a taxa de conversão aumentou 400% em uma semana devido ao retorno da hipótese que considerava a aquisição da hospedagem premium por usuários em um hotel, de acordo com o período do dia em que eles efetuavam a reserva. A combinação das práticas HDD e CD (Continuous Delivery) amplificam o conhecimento validado, acelerando a experimentação e inovação.

Testes canários (A/B) e integração de releases – Feature Toggles

As práticas de implementação contínua – CD (Continuous Deployment) são fundamentais no mundo digital, principalmente em empresas inovadoras com foco em time to market e criação de produtos. A esteira de publicação destas empresas realiza então o deploy de releases automático em produção.

Os testes canários (ou testes A/B) habilitam estas funcionalidades para um grupo controlado de usuários, mantendo em produção duas comunidades (A/B) para minimizar, por exemplo, o risco de negócio em liberar novas releases para comunidades de usuários. Talvez seja necessário um experimento em um número reduzido de usuários para decidir se aquela funcionalidade será mantida ou removida.

Há estratégias para escolher a liberação da nova versão, desde a liberação interna para funcionários da própria empresa, até usuários escolhidos com base em seu perfil ou informações demográficas. A aceitação da funcionalidade vai direcionando o aumento de infraestrutura e dos usuários para este ambiente. E assim, possibilitam os testes A/B por restringir as novas funcionalidades a um grupo reduzido de usuários. Um ponto de atenção para o uso dos testes canários é gestão de várias versões da aplicação em produção.

A empresa (Eletronic Arts Inc.) divulgou um caso de sucesso utilizando teste A/B na página de pré-vendas do jogo SimCity 5. Após remover um banner promocional da página, aumentou em 43% as conversões de venda.

O padrão de desenho Feature Toggles é uma técnica que pode ser utilizada para estas implementações, permitindo os times modificarem o comportamento do sistema sem alteração de código. A proposta é ter uma alternativa para a manutenção de várias branches de código fonte (features branches), e assim conseguir manipular a funcionalidade em tempo de execução.

Na figura abaixo, elaborada por Martin Fowler, inicia-se pela inclusão dos toggle points no código-fonte para manipular o comportamento da funcionalidade. O toggle router determina o estado delas, considerando o toggle context. O toogle configuration controla o toggle router naquele ambiente.

martin-fowler

Figura xxFeature Toggles

Métricas de HDD (Hypothesis-Driven Development) no Azure DevOps

As métricas são essenciais quando trabalhamos com HDD (Hypothesis-Driven Development), pois direcionam as decisões e proveem visibilidade sobre a aceitação dos produtos ou serviços. Há algumas recomendações na adoção de métricas para não se tornarem irrelevantes ao seu negócio.

Actionable metrics são exemplos de métricas consideradas importantes, pois resultam em ações específicas e repetíveis no apoio a tomada de decisão e cumprimento dos objetivos. A abordagem HDD pode ser utilizada neste contexto para desenvolver e experimentar implementações que adicionem valor ao negócio. Comece com poucas métricas e que façam sentido para o seu time.

O metrics that matter, definido por Dave McClure como AARRR Pirate Funnel Metrics, possui as seguintes métricas para acompanhamento:

  • Acquisition: número de usuários que visitam o serviço ou produto. Esta métrica precisa garantir o acompanhamento correto da fase de aquisição e quantidade de conversão de clientes. Por exemplo, qual o maior volume nos canais de venda? Qual a melhor performance entre os canais?
  • Activation: mensura como está a resposta inicial dos usuários em relação a ativação do serviço. Como foi a experiência do usuário na sua primeira visita? Tempo de permanência, page views, cliques, entre outros são boas métricas. Os testes A/B podem apoiar com landing pages e conteúdo para obter melhor experiência.
  • Retention: a retenção dos clientes, mantendo por perto as pessoas que se inscreveram e utilizam um dos serviços. A automação de e-mails, por exemplo, baseada em eventos ou atividades podem apoiar de forma simples.
  • Revenue: número de pessoas engajadas com a geração de receita.
  • Referral: referências de usuários que encorajam outros a utilizarem seus produtos e serviços. Os testes qualitativos são aplicáveis a um número menor de usuários para depois disseminar o produto a um número maior de usuários.

AARRRFigura: AARRR Pirate Funnel Metrics

Com o uso do AARRR, um dashboard de acompanhamento para cada categoria é importante para dar visibilidade as áreas: quantitativa (análise de tráfego e engajamento), qualitativa (teste de usabilidade e monitoramento da sessão), comparativa (testes A/B) e competitiva (monitoramento e rastreamento do mercado). Veja no dashboard abaixo algumas métricas desde a etapa de acquisition até a revenue.

AARRR-Pirate.jpgFigura: AARRR Pirate Funnel Metrics

Um outro exemplo de utilização do AARRR pela Apptentive, que demonstra o funil aplicado a um produto de Mobile App. Na fase de Acquisition, mensura-se a quantidade de downloads, instalações e visitas na página. Em Activation, mais direcionado ao uso – tempo de permanência e telas visualizadas. A Retention verifica a permanência, considerando usuários ativos por mês e frequência do uso. Em Referral, além das referências, as avaliações e revisões dos usuários sobre o produto. Por fim, Revenue considera a monetização como a receita média por usuário e compras do App.

mobile-app-funnel.pngFigura: The Mobile App Customer Purchase Funnel Cheat Sheet

Em uma visão adicional do AARRR, também de Dave McClure, fica bem claro o exemplo da aplicabilidade para cada métrica. Começando com a conversão de tráfego, seguida da análise pós inscrição e assinatura. A retenção verifica os usuários que interromperam o uso, e a referência avalia métricas como NPS de satisfação e lealdade dos clientes. Por fim, a receita direciona a dados monetários como o custo de aquisição do cliente e o valor do tempo de vida do cliente.

conversion-metrics.pngFigura: Conversion Metrics Example

Em um post anterior, demonstramos a criação das HDDs e como gerenciar o desenvolvimento no Azure DevOps. Para representar as métricas de acompanhamento das HDDs, crie inicialmente uma query em Boards > Query. No exemplo abaixo, criamos três gráficos:

  • Status: visualiza as HDDs por status; o intuito é verificar o WIP e possíveis gargalos
  • Owner: incluído story points e o proprietário da tarefa, afim de acompanhar a capacidade dos recursos
  • Validadas*: sim ou não. O experiment framework sugere marcar como “validated” ou “falsified” quando a tarefa passa para a coluna Completed Experiments, afim de determinar se aquela hipótese foi válida ou não.

This slideshow requires JavaScript.

* para possibilitar isso, precisamos incluir um novo campo na User Story (ou HDD), acessando “Organization Settings > Boards | Process >  Processo utilizado >  Work item type”. No exemplo abaixo, criamos um novo campo do tipo Picklist. 

edit-field-vsts

E o resultado final com os gráficos e as métricas de acompanhamento das HDDs:

graficos-hdd-vsts

Por que utilizar Hipóteses em vez de Requisitos?

Por que utilizar Hipóteses em vez de Requisitos?
Enquanto os requisitos são especificações que um produto deve ter para atender o cliente, geralmente descritos pelo PO (Product Owner) em user stories, as hipóteses são ideias que precisam ser testadas e validadas no mercado. A tabela abaixo compara o formato utilizado na user story, BDD (Behavior driven development) e HDD (Hypothesis-Driven Development).

A tabela abaixo realiza a comparação entre User Story x BDD x HDD:

comparacao-hdd-us

Com as constantes evoluções e mudanças no mercado, as empresas precisam de um modelo extremamente dinâmico para criar produtos e validar hipóteses no mercado, como os testes A/B por exemplo. Também viabilizar o time-to-market, trabalhando com entregas contínuas e criando MVPs (Minimum Viable Product) para validar as principais premissas do negócio.

Sem esta validação de hipóteses e suposições, as empresas podem estar desperdiçando tempo e recursos, criando soluções indesejadas pelos clientes. Por isso, experimente cedo e constante, solicitando feedbacks dos clientes e tomando decisões orientadas a dados. O diagrama HDD (Hypothesis-Driven Development) da IBM demonstra as etapas propostas, desde a definição da ideia, formulação da hipótese, construção do MVP, mensuração até o aprendizado baseado em feedback do cliente.

hdd-diagramFonte: IBM

Incorporar o mindset de experimentação contínua é fundamental nesta jornada. Mesmo em hipóteses não aprovadas, pode se obter insights valiosos para direcionar o negócio. Quando as hipóteses são confirmadas, recomenda-se aplicar testes A/B, dividindo os usuários com a opção A (função atual) e opção B (nova função). Os testes A/B podem ser aplicados através de formulários, pesquisas, entrevistas ou qualquer outro meio que permita coletar os dados. A análise dos dados coletados evidenciará qual será a melhor opção de escolha.

As práticas de Continuous Delivery apoiam a realização dos testes por criar esteiras de publicação frequente, colocando o tempo todo novas releases em produção. Inicialmente, este processo pode ser contra intuitivo para a área de infraestrutura, considerando procedimentos de rollback e outros problemas emergenciais em change management. Porém, evoluindo o processo de CD, trará menos risco e problema nas implementações, devido ao processo confiável e repetível de publicação frequente de releases.

publicacao-releases

Formato das hipóteses
Os fundamentos da experimentação são utilizados como base, e assim, de forma sistemática, define-se os passos necessários para atingir um resultado esperado. Também, os indicadores para checar se aquela hipótese é válida ou não. As hipóteses quando alinhadas ao MVP podem fornecer um ótimo mecanismo de teste para prover informação e melhorar a confiança nas áreas incertas de seu produto e serviço. O modelo Barry O’Reilly é estruturado da seguinte forma:

We believe <this capability>
A funcionalidade que será desenvolvida para testar nossa hipótese.

Will result in <this outcome>
O resultado esperado do experimento.

We will know we have succeeded when <we see a measurable signal>
Os indicadores que indicarão se o experimento foi bem-sucedido e que servirá de base para avançar nos testes.

 

Veja um pouco mais sobre HDD (Hypothesis-Driven Development) e como criar hipóteses utilizando o Azure DevOps no seguinte artigo: Desenvolvimento Orientado por Hipóteses no Azure DevOps – HDD (Hypothesis-Driven Development)

Desenvolvimento Orientado por Hipóteses no Azure DevOps – HDD (Hypothesis-Driven Development)

O Desenvolvimento Orientado por Hipóteses (Hypothesis-Driven Development) baseia-se no conceito da experimentação, criando uma hipótese para explicar um determinado resultado. No âmbito de desenvolvimento de sistemas e criação de produtos, por exemplo, quando estamos desenvolvendo novas releases e precisamos validar uma ideia no mercado, a hipótese é criada, e se o resultado é confirmado, comumente isso sinaliza a continuidade da evolução do produto. Quando não há boa aceitação, a tendência é o pivot, mudando o produto ou características que permitem testar novas hipóteses.

O conceito do Build-Measure-Learn Loop, apresentado no livro Lean Startup do Eric Ries, traz alguns tipos de pivot que apoiam a decisão de mudar a estratégia e criar novas hipóteses. Entre os principais estão:

  • Zoom-in Pivot: uma feature torna-se o produto completo.
  • Zoom-out Pivot: o produto completo torna-se uma feature de um produto maior.
  • Customer Segment Pivot: a hipótese é parcialmente confirmada, mas para um público diferente do planejado.
  • Customer Need Pivot: altera para uma linha de negócios totalmente diferente, baseado na relação com o cliente.
  • Channel Pivot: o aprendizado de que a mesma solução pode ser entregue em um canal diferente com maior eficácia.
  • Technology Pivot: inovação tecnológica para atrair e reter clientes.

Por isso, coletar os resultados de validação da hipótese são tão importantes, principalmente em startups que dispõem de baixo capital e precisam de ideias que tragam retorno ao investimento. Neste cenário, não há espaço para soluções custosas, estoque de código e releases com pouca aceitação dos usuários.

A primeira fase recomendada então é a de Build, dedicando-se a criar o produto mínimo viável (MVP – minimum viable product), que é a versão mais simples do produto com um mínimo de esforço. A fase de Measure provê visibilidade do desenvolvimento e o progresso em relação aos objetivos. Em Learning, o processo empírico gerado pelo validated learning traz afirmações valiosas sobre a aceitação dos produtos e perspectivas de negócio, evitando assim, executar com sucesso um plano que não leva a lugar nenhum.

build-measure-learn-loop

Entre os principais benefícios da experimentação:

  • Aprendizado contínuo
  • Investimento direcionado
  • Validação de hipóteses são mais valiosas que previsões de mercado ou business plan

O experiment framework, criado por Beni Tait e derivado do hypothesis driven development e Lean Startup, representa um modelo visual de explorar, criar protótipos e experimentar novas ideias. Este modelo surgiu da necessidade do time (UX, Research, tecnologia, etc.) em alinhar se o desenvolvimento de novos produtos, baseado em hipóteses, tinham correspondência com o idealizado.

Era necessário ter visibilidade dos experimentos, acompanhar a evolução e gerar aprendizado para direcionar sua continuidade. Organizar também ideias de qualquer área, fortalecendo o mecanismo para visualizar, discutir e priorizar os experimentos para aplicar de volta ao fluxo de criação de produtos.

Utilizando o Azure DevOps, podemos criar o board do experiment framework para acompanhar a validação das hipóteses. Acesse a área de processos (Boards > Process) em Organization Settings. Crie um novo work item e nomeie como HDD (Hypothesis-Driven Development). O layout pode ser configurado com campos similares ao da User Story.

HDD-process

Criamos a estrutura “Epic > Feature > HDD” no time de projeto. A HDD (Hypothesis-Driven Development) está no mesmo nível da User Story e será utilizada para formular as ideias e colocar no backlog de desenvolvimento para criação de MVPs.

HDD-pb

E o seguinte formato das hipóteses:

We believe <this capability>
A funcionalidade que será desenvolvida para testar nossa hipótese.
Will result in <this outcome>
O resultado esperado do experimento.
We will know we have succeeded when <we see a measurable signal>
Os indicadores que indicarão se o experimento foi bem-sucedido e que servirá de base para avançar nos testes.

HDD-campanha

Após a criação da estrutura, acesse Boards e adicione as colunas do experiment framework: Assumptions | Hypothesis | Active Experiments | Completed Experiments | Presented Findings.

HDD-Azure-DevOps

Como os status (colunas adicionadas) que acabamos de criar não existem no Azure DevOps por padrão, precisamos customizar. Acesse a área Boards > Process > User Story (ou HDD criado) e adicione os status que criamos anteriormente.

HDD-custom

De volta ao Board (Boards > Board) do projeto, associe as colunas criadas com os status (State mapping) que acabamos de criar. Assim, podemos visualizar corretamente os status de cada HDD.

HDD-custom-settings

O experiment framework possui seis processos básicos:

  • Document Assumptions: permite que todos na organização contribuam com ideias e experiências, utilizando cartões para expor sua hipótese.
  • Formulate a hypothesis: preparação para a jornada, envolvendo o time na criação da hipótese a ser validada.
  • Design the experiment: elaborar como o experimento deve ocorrer.
  • Develop the experiment: o time trabalha no desenvolvimento das funcionalidades, condições e parâmetros.
  • Run the experiment: a execução é monitorada para obter as conclusões e opiniões no final do experimento.
  • Share the findings: compartilhar os resultados e conhecimento obtidos para direcionar os próximos experimentos.

É isso! Neste post introduzimos os conceitos de experimentação e hipóteses, utilizando o HDD (Hypothesis-Driven Development) e Azure DevOps para organizar o Board de desenvolvimento e criação de MVPs. Nos próximos posts, vamos abordar os conceitos de Métricas e como os testes A/B podem ser integrados para release.

Análise de causa e efeito em projetos ágeis com Fishbone (Ishikawa) e Azure DevOps

Quando executamos projetos ágeis no âmbito de desenvolvimento de sistemas, trabalhamos com algumas técnicas que ajudam a evitar deploys de novas releases com bugs em produção. Algumas práticas de CI/CD nas práticas DevOps, por exemplo, mitigam os riscos por gerenciar todo o ciclo de vida da aplicação – gestão de configuração, integração contínua, estratégia de testes, build e release pipeline, etc.

Mesmo com publicações frequentes e pacotes menores para diminuir os riscos, lidamos com algumas implementações complexas e inúmeras dependências entre os times. Nem sempre temos o “estado da arte” na nossa empresa, contando com os investimentos adequados em ferramentas ou até mesmo a maturidade do time no uso de práticas e processos de desenvolvimento.

E assim, alguns antipatterns podem surgir neste âmbito de implementação:

  • Correções frequentes durante a implementação de releases
  • Confiança em testes manuais para validação das aplicações
  • Resultados imprevisíveis na publicação de novas releases, e ainda muitas vezes apresentam problemas e precisam ser revertidas

Quando isso acontece, uma boa orientação é atuar na causa real dos problemas afim de evitar a recorrência (o mesmo problema apareça novamente) e até mesmo não resolver em definitivo aquele bug. Já falamos anteriormente sobre o uso do 5 Porquês (5-Why). Neste post, vamos abordar o Diagrama de Ishikawa, também conhecido como Espinha de Peixe ou Causa e Efeito, ferramenta de qualidade para identificar a relação de causa e efeito dos problemas. É muito utilizada por gestores na área de TI para descobrir a causa raiz daquele bug apresentado na aplicação em produção.

O uso do diagrama é bem simples. Na “cabeça” do peixe colocamos o problema a ser resolvido. Uma frase como “por que este <problema> aconteceu?” é mais recomendado do que apenas escrever o problema. A “espinha do peixe” serve para descrevermos a causa dos problemas. Por fim, agrupe pelo tipo da causa. Os grupos recomendados no Ishikawa são os 6M: Método, Meio ambiente, Medida, Mão de Obra, Material e Máquina. Em TI trabalhamos com o diagrama adaptado do fishbone. Veja o modelo:

fishbone

Download do template (PPTX): fishbone template

No meu exemplo, estou utilizando o Azure DevOps (da Microsoft) como solução de ALM e assim registrar os erros encontrados nas aplicações. Para relacionar os bugs em aberto, acesse a área Boards > Work Items > faça o filtro do work item tipo “Bug”.

azure-devops-bugs.png

No work item (do tipo Bug) existe o campo de classificação (Classification) que possui uma lista de valores a ser escolhido como a causa do problema. Este pode ser utilizado como o grupo de problemas na construção do Ishikawa. Customize se necessário. Adicionalmente, deve haver o preenchimento da causa do problema no campo  symptom. Oriente seu time para realizar o preenchimento correto dos campos.

azure-devops-bugs-wi.png

Após coletar todos os erros da aplicação, chegou a hora de analisar a causa raiz do problema, agrupando conforme as causas em grupos. Com os principais erros relacionados, podemos atuar na causa e resolver o problema em definitivo. Em processos de melhoria contínua, este aprendizado certamente trará melhorias, sendo o input para implementações futuras.

fishbone-ti

 

Gerenciando testes manuais e automatizados da aplicação no Azure DevOps

Como está a publicação de suas aplicações? Os testes estão sendo executados? Incluindo os testes manuais e automatizados? As boas práticas como BDD (behavior driven development) ou TDD (test driven development) estão incorporadas no seu time de desenvolvimento? Há prática de teste unitário e verificação de cobertura do código no Build? E o engajamento? Os desenvolvedores já possuem uma visão clara dos benefícios? Ou a gamificação ajudou a alavancar a cultura de testes?

Vamos falar aqui sobre o Plano de Testes do Azure DevOps e como utilizar os testes exploratórios e automatizados no ciclo de vida da aplicação. Antes, sugiro a leitura destes artigos (links marcados) para melhorar o entendimento e aplicabilidade dos recursos.

Acessando o Azure DevOps, na área de Test Plans, podemos ver todos os planos de testes criados e a associação com os work items. A opção Run permite executar os roteiros e sinalizar se cada etapa foi bem sucedida ou não. Ainda no Test Case (tipo do work item criado quando trabalhamos no Test Plans), podemos abrir tarefas do tipo bug associado ao work item e encontrado durante a realização do teste.

test-plan-vsts.png

Veja o Test Case criado com cada etapa que será testada. A ferramenta armazena o resultado de cada etapa. Basta confirmar como pass | fail | block durante a execução dos testes. Também é possível visualizar a qual work item o Test Case está associado (Related Work). No exemplo abaixo, abrimos o work item para visualizar a tarefa e o plano de teste associada a ela.

work-item-test-case.png

Após a execução dos testes, seja manual como mostramos, ou automatizados, a área de Test Plans > Runs demonstra o resultado da execução destes testes. Além do resumo, podemos visualizar o resultado de cada etapa dos testes, adicionar comentário e anexo ao Test Case.

test-lans-runs.png

A configuração dos testes automatizados (considerando os testes unitários do projeto) foi feita nas etapas do Build Pipeline, referenciando o caminho do projeto de testes.

build-test

E o resultado do teste automatizado (vinculado ao processo de Build) também fica disponível em Test Plans > Runs. A guia Test Results exibe o status dos testes que foram criados no projeto de teste durante o desenvolvimento.

test-runs-vstest