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:

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.

Fonte: 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.

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)