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, de Eric Ries, traz alguns tipos de pivots 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.

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. Esse 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.

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.

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.

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

Ele 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 artigo 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 artigos vamos abordar os conceitos de métricas e como os testes A/B podem ser integrados para release.