Enquanto os requisitos são especificações que um produto deve ter para atender o cliente (geralmente descritos pelo 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:

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 devem 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 constantemente, 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.

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.

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 e 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:

• A funcionalidade que será desenvolvida para testar nossa hipótese:

We believe <this capability>

• O resultado esperado do experimento:

Will result in <this outcome>

• Os indicadores que indicarão se o experimento foi bem-sucedido e que servirá de base para avançar nos testes:

We will know we have succeeded when <we see a measurable signal>

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