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.

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.

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.

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.

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.

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.