Agile

3 jan, 2019

Desenvolvimento orientado por hipóteses no Azure DevOps – HDD

Publicidade

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.