Técnica INVEST – como quebrar User Stories de microsserviços

Há várias formas de quebrar User Stories, uma delas é com a técnica INVEST. A partir do entendimento da teoria de microsserviços e a experiência prévia que eu tinha de quebra de user stories utilizando a técnica INVEST comecei a testar alguns modelos para aplicar o conceito a este novo contexto. 

Neste artigo abordamos alguns exemplos sobre como podemos aplicar a técnica INVEST no dia a dia.

Um pouco sobre a minha experiência de quebra de user stories utilizando a técnica INVEST

Durante uma boa parte da minha carreira na área de engenharia e gestão de produtos trabalhei em contextos onde sempre havia uma jornada front-end para ser entregue para o usuário final. 

E durante todo este tempo toda técnica que aprendi para escrita de user story foi com foco no detalhamento dos requisitos das regras que deveriam estar contidas no front-end e nas regras aplicadas ao executar alguma ação.

Iniciei na área de desenvolvimento em 2008 e durante este período trabalhei com Windows Form no VB6, front-end no ASP Clássico, telas do Delphi e a famosa tela preta das aplicações em Cobol. E é incrível ver como a tecnologia avança rápido e a maneira como trabalhamos muda radicalmente.

Em 2018 comecei a trabalhar no papel de Project Manager e me deparei com cenários onde o escopo das squads eram exclusivos de back-end através de microsserviços. Acabando de sair de um projeto feito em Salesforce tive que mudar muito da maneira que eu atuava para definir os requisitos para me adaptar a este novo cenário.

O ponto de partida foi dedicar uma boa parte do meu dia estudando, consumindo muitos tutoriais de blogs e YouTube para aprender mais sobre este cenário. Dentre as pesquisas:

• O que são microsserviços?.
• JSON em 6 minutos
• Introdução ao postman
• AWS SQS – Saiba como usar um serviço de fila. 

Recomendo fortemente que estudar temas relacionados a este contexto seja um hábito. Tenha curiosidade e procure reservar pelo menos 30 minutos do seu dia para adquirir novos conhecimentos. Acredito que o melhor caminho para acumular conhecimento é seguir as etapas:

• Estudar a teoria.
• Praticar.
• Repetir.
• Ensinar.

Afinal, o que é a técnica INVEST?

Uma técnica que aprendi durante a minha carreira para quebra de história (user stories) é o INVEST que na minha visão é uma diretriz para tentar padronizar a quebra de histórias para alimentar a cadeia de valor da squad. De maneira bem resumida seria:

• Independent (independente): As histórias podem ser desenvolvidas de maneira independente uma da outra.
• Negotiable (negociável): O conhecimento do escopo evolui desde a sua concepção inicial até depois da implantação. Ela deve ser negociável para permitir a evolução do detalhamento do escopo durante toda a cadeia de valor.
• Valuable (valor): A história deve gerar algum tipo de valor para o cliente final. Precisamos ter clareza sobre qual é este valor agregado à solução.
• Estimable (estimável): Precisamos analisar o escopo proposto e conseguir estimar o tempo necessário para finalizar o desenvolvimento.
• Small (pequena): A história deve ser pequena. Se o tempo de desenvolvimento passar de 2 semanas considere a possibilidade de quebrar em mais de uma história.
• Testable (testável): Ao finalizar o desenvolvimento da história deve ser possível realizar testes automatizados e/ou manuais que validem que os critérios de aceite foram implementados com sucesso.

Mas e aí? Como aplicar este conceito em um contexto de microsserviços? 

Como usar a técnica INVEST na prática

Dentre os principais itens que entendo como importante termos como resultado no final de um Discovery destaco Product Backlog e o Diagrama de arquitetura.

Vou explicar os dois a seguir:

Product Backlog

Através de técnicas como entrevistas, lean inception e outras é importante que seja mapeado o Product Backlog. Eu gosto de montar uma planilha com uma aba com os épicos e outra aba com histórias identificadas durante o processo. 

Exemplo fictício de mapeamento de epics:

Exemplo fictício de mapeamento de user stories:

Diagrama de arquitetura

Em paralelo ao mapeamento do Product Backlog fazer uma proposta inicial do diagrama de arquitetura mapeando todos os microsserviços que pretendemos criar, banco de dados, filas, integrações com outros domínios, etc. 

Vale reforçar aqui que é uma proposta beta para nortear o início do projeto e que esta arquitetura será refinada com o decorrer dos próximos ciclos. 

Exemplo fictício de um diagrama de arquitetura:

Começando a trabalhar com a técnica INVEST

Dado o mapeamento inicial de escopo e a proposta de arquitetura alvo, agora é hora de refinar mais um pouco os temas mapeados realizando as quebras utilizando a diretriz INVEST. 

Vamos acompanhar como isso funciona na prática?

Independent (independente)

Vamos começar pelo conceito Independent (Independente).

Em uma arquitetura de microservices provavelmente teremos uma separação de domínios e responsabilidades. Esta é a hora de realizar cortes da solução para gerar as primeiras histórias. 

No exemplo abaixo temos o início de um processo de Onboarding onde temos a peça Onboarding API que será responsável por expor o endpoint para que um aplicativo mobile, por exemplo, consiga acessar.

Esta é uma peça que pode ser desenvolvida de maneira independente das próximas etapas de um fluxo de Onboarding.

Em uma próxima história poderíamos recortar a etapa de validação de fraudes.

Esta etapa também pode ser desenvolvida de maneira independente.

É importante colocar aqui que poucos microsserviços vão funcionar de forma independente em produção. Neste caso, por mais que alguns microsserviços sejam desenvolvidos de maneira independente, a solução completa só funcionará quando a solução completa estiver pronta. Neste caso tentar priorizar o desenvolvimento em uma ordem cronológica. 

Negotiable (negociável)

A ideia de uma user story ser negociável é que devemos ser flexíveis para alterar a proposta inicial da história durante todo o ciclo de vida dela na cadeia de valor. O aprendizado é contínuo e temos que nos adaptar para criar a melhor solução para os problemas que queremos resolver.

Um exemplo seria uma consulta de um payload para listagem de produtos para uma vitrine de benefícios de um aplicativo mobile. Em uma proposta inicial podemos pensar que o melhor caminho seria realizar a consulta em um back-end que consolida as informações dos produtos cadastrados em uma plataforma versus para listar as informações no aplicativo.

Porém ao finalizar o desenvolvimento e realizar os testes podemos chegar a conclusão que a solução não ficou performática. Neste caso uma possível solução seria implementar um cache dado que a vitrine de benefícios é alterada poucas vezes na semana. Neste caso, negociamos a alteração do escopo proposto inicialmente em tempo de desenvolvimento para que seja implementado o cache.

Isso vale para todas as etapas da cadeia de valor, inclusive após o deploy em produção. Não temos todas as respostas ao fazer o refinamento de escopo de novas features. Aprendemos com o uso dos serviços que colocamos em produção. Precisamos constantemente avaliar o resultado do seu uso e negociar para que as regras de negócios e arquitetura sejam alteradas para atender novos cenários ou para termos uma performance melhor, por exemplo.

Valuable (valor) 

As histórias devem gerar algum tipo de valor para o cliente final. Ao realizar a quebra das user stories procure criar pedaços da solução que acrescentem valor a solução.

Por exemplo, em um cenário onde estamos criando uma solução de onboarding em um aplicativo deverão ser criadas diversas etapas de validação.

Neste caso, cada uma destas etapas poderia ser uma história. Por exemplo:

• Microsserviço responsável pela validação dos dados cadastrais.
• Microsserviço responsável pela validação de fraudes.
• Microsserviço responsável pela persistência dos dados do cliente no banco de dados.
• Microsserviço responsável pela criação das credenciais de acesso.

Em alguns momentos você pode pensar que uma User Story isolada não gera um valor real para o cliente final. Por exemplo, se eu fizer uma validação de fraudes sem abrir a conta para o cliente, não geramos valor. Neste caso, pense que a proposta da User Story deve ser adicionar algum valor à solução completa final que será entregue ao usuário final. 

O ponto principal aqui é explorar o valor que vamos gerar. Evite User Stories que não gere nenhum valor ao usuário como por exemplo criar uma classe de persistência de dados do status das etapas do onboarding porém em um cenário que nenhum outro fluxo está utilizando esta classe ainda. Este tipo de User Story não agrega valor se a classe não for utilizada por ninguém. Neste caso, tente adicionar este escopo da criação desta classe junto com outra história que juntos adicionem uma capacidade que gera valor a solução final. 

Estimable (estimável) 

Assim que a história estiver definida precisamos conseguir estimar o tempo necessário para conseguir implementar a solução proposta. Se não fizermos a menor ideia do tempo que vamos levar para terminar, pare e avalie:

• A especificação do que precisa fazer está clara?
• Todos os impedimentos para iniciar o desenvolvimento da história foram resolvidos?
• A história está small (pequena)? É possível quebrá-la mais um pouco em mais histórias?

Small (pequena) 

Não criei histórias que levem mais que uma sprint de 10 dias para serem desenvolvidas. Se puder quebrar a história seguindo a técnica INVEST para ser desenvolvido em três dias ótimo, mas se não for possível quebrar neste nível não ultrapasse 10 dias. 

Acredite, user stories mal definidas e grandes podem se estender por meses.

Testable (testável) 

Ao finalizar o desenvolvimento de uma user story deve ser possível testá-la. No contexto de microsserviço geralmente um entregável deve permitir fazer um request e ter um response com o resultado do processamento. Logs, bancos de dados ou postagem em filas podem ser caminhos para conseguirmos realizar os testes.

Por exemplo, não crie histórias que criam uma classe que nenhum serviço vai utilizar. Ao finalizar o desenvolvimento, um teste automatizado ou um teste manual devem conseguir garantir que os critérios de aceite foram atendidos com sucesso.

Os ganhos de usar a técnica INVEST

Já tive a oportunidade de trabalhar em diversas empresas e clientes de vários segmentos. Há entendimentos muito diferentes entre as pessoas sobre como realizar a quebra de histórias e muitas vezes ela ocorre sem uma técnica específica.

Adotar a técnica INVEST como uma diretriz para a escrita de user story vai te ajudar a ter histórias padronizadas e com mais qualidade. Dentre outras vantagens de adotar essa técnica, podemos citar, por exemplo:

• O escopo e os requisitos de cada uma das peças estarão melhor detalhados. 
• A equipe terá flexibilidade para negociar o escopo ao ter novos aprendizados durante toda a cadeia de valor. 
• A cada entrega de parte do escopo vai gerando novas capacidades e a solução terá cada vez mais valor. 
• As histórias serão desenvolvidas em curto espaço de tempo dado que elas serão pequenas. 
• Será possível ter previsibilidade dado que será possível estimar o tempo de entregas das demandas. 
• A cada parte entregue será possível testar manual ou de forma automatizada se os critérios de aceite foram atendidos. 

Desafios na adoção da técnica INVEST

A proposta do INVEST é uma diretriz para seguirmos para ter uma padronização na quebra de User Stories. Mas na prática do dia a dia vamos enfrentar situações onde não será possível atender todos os requisitos. Neste caso não há problema em não atendermos todas as diretrizes. A ideia é sermos flexíveis no dia a dia. A dica é fazer o máximo para seguir o small para não termos no dia a dia temas muito longos e complexos.

Para que a técnica seja absorvida pelo seu time é necessário investir tempo para ensinar a técnica com os integrantes da equipe além de ter um processo de repetição do método para que o conceito seja assimilado.

Faça uma proposta de template de User Storie com tópicos como por exemplo Visão do Usuário, Narrativa de Negócio, Critério de Aceite, Cenário de Testes, Solução Técnicas e Tasks. É importante ter um modelo de trabalho padronizado acordado com a equipe para que o output gerado ao aplicar a técnica INVEST esteja estruturado. De uma forma onde todos envolvidos com a demanda consigam entender o contexto e escopo do que precisa ser desenvolvido.

Conclusão

Adotar a técnica INVEST vai ajudar sua cadeia de valor a ter uma fluidez maior e consequentemente um lead time cada vez menor. Te convido a experimentar o modelo. 

Ficou com alguma dúvida ou tem uma sugestão de formas de aplicar a técnica INVEST para quebra de User Stories no contexto de microsserviços? Então conta para a gente nos comentários!