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.
Work items –com– Work items
Imagem: 
Imagem: 
Figura: 
Figura: 
Figura: 
Figura: 
Digital Strategy and IT Innovation 