Workflow de desenvolvimento com frameworks ágeis


Como eu gosto de organizar o workflow de desenvolvimento no modelo ágil

A proposta que vou apresentar aqui, já utilizei em no mínimo 4 diferentes times de desenvolvimento, e em todos eles foi possível observar bons resultados. Entre os resultados que busquei refletir, posso destacar: autonomia, poder de decisão, engajamento, organização, padronização, clareza, redução de retrabalho e principalmente assertividade.

Vou apresentar desde como descrevo os épicos que apresento ao time, quando apresento e o que busco extrair, até como isso reflete na entrega de valor.

Épico

Sempre busquei tratar o épico como a entrega de valor, mas como fazer isso? Por muito tempo testei diferentes formatos e apenas quando tive a oportunidade de trabalhar com um time de produto e não apenas um time de desenvolvimento que executa demandas é que consegui encontrar um modelo que busco apresentar para todos que trabalham comigo, e quem me apresentou esse modelo foi um grande colega, Renato Passero. O modelo apresenta um padrão de escrita que nos ajuda a direcionar a entrega de valor e garantir que essa será validada.

Formato:

#EPI-02
Observamos que o usuário do sistema não mantem os dados de endereço atualizado e isso está gerando problemas na entrega
Acreditamos que destacar o endereço atual no momento da compra vai garantir que o usuário busque atualizar os dados sempre que necessário
Saberemos que isso é verdade quando o número de incidentes relacionados a endereço incorreto reduzir em 90%
Esse formato é o que apresentamos ao time de produto/desenvolvimento, buscando consulta-los para nos ajudar a entender qual o trabalho deve ser feito. Como PO/PM/Analista ou seja lá qual for seu papel, não devemos jamais vir com a solução, pois nunca seremos capazes de apresentar a melhor solução para um problema se nos compararmos a um time inteiro composto por UX, desenvolvedor, Especialista, Tech Lead, entre outros (duas cabeças pensam melhor que uma, imagine um time inteiro).

A lição nesse momento é juntar o time todo em uma reunião de refinamento e fazer exercícios buscando ouvir a sugestão de todos: O que eles acreditam que deve ser feito para resolver o problema?. Mas cuidado, dar a palavra para uma ou outra pessoa apenas, ou estabelecer uma ordem para ouvir as sugestões, pode gerar o efeito que não queremos, que é limitar as sugestões, pois um pode acabar apenas concordando com a sugestão apresentada anteriormente. Então, minha sugestão aqui é criar dinâmicas, por exemplo, pedindo para que cada um desenhe algumas possíveis soluções e apresentem ao mesmo tempo o rascunho, e só então comecem a explicar o que desenharam (agora de um em um).

Outra prática que pode ser usada para "descobrir a solução do épico" é o processo de design thinking chamado double diamond.  

Para enriquecer e criar um processo lógico no artigo, vou descrever algumas coisas que poderiam sair dessa reunião. E eu gosto de chamar essas "coisas" de "action itens":
    • Apresentar o endereço atual no próximo ao botão confirmar compra
    • Permitir editar o endereço na confirmação da compra
    • Após clicar em confirmar compra, perguntar se o endereço está correto

Histórias

As histórias de usuário possuem esse nome pois deveriam ser exatamente isso, mas não é o que observamos e geralmente o resultado disso é retrabalho, falta de entendimento, baixa performance e, por fim, a culpa acaba sendo do desenvolvedor. Outro ponto importante nas histórias de usuário é que elas não devem ser sobre a funcionalidade, mas sim fragmentos que combinados geram a entrega de valor como um todo (o épico), porém, ainda assim, cada história deve acrescentar algum pequeno valor para colaborar na conclusão do épico. Então, como devo escrever minhas histórias de usuário?

Formato:

História de exemplo: Após clicar em confirmar compra, perguntar se o endereço está correto

#HIS-123
Como o usuário do sistema efetivando minha compra
Quero ser lembrado de atualizar meu endereço
Para evitar que eu conclua minha compra e não receba o produto no endereço onde espero receber
[Critérios de aceite]
  • O Alerta deve aparecer seguindo o padrão de mensagem do sistema
  • Deve ser possível fechar o alerta e o usuários deve ficar na mesma página
  • Dentro do alerta deve existir o botão "cancelar" e "o endereço está correto"
  • Clicando no "o endereço está correto, deve direcionar para a página de conclusão de compra

Algo muito importante para ajudar o time de desenvolvimento a exigir um certo nível de qualidade do que o PO/PM entrega para o time, é definirem um definition of ready.

*Sério, isso muda sua vida, Dev! 

Gestão do código fonte

Gosto de trabalhar com branch Master, Developer, Feature/* seguindo o fluxo:
  • Branch main é atualizada apenas pelo CI/CD e só recebe merge da developer.
  • Branch developer só pode receber PR das branchs feature/*.
  • Branch feature/* é criada pelo desenvolvedor, com base na developer e segue o padrão: feature/his-123 (de acordo com nossa história)
Três coisas importantes que colaboram com processo de desenvolvimento e podem ser observados durante o code review de cada PR (sempre tenha etapa de code review). O primeiro é definir um definition of done e validar nessa etapa, o segundo é validar o seu guia de desenvolvimento e por fim, validar os critérios de aceite descritos na história de usuário para garantir que cada requisito está sendo atendido.

Validação

Caso esteja usando scrum, é muito importante definir objetivo na sprint e não criar sprints com um monte de histórias que não buscam entregar um valor ou que não se conectam.

Agora que todas as etapas anteriores se conectam

Veja bem, criando épicos que focam em entrega de valor, facilitará seu trabalho de definição de objetivo da sprint e o requisito aqui é criar sprints que possuem conjunto de histórias de um mesmo épico e não historias soltas. Dessa forma você da pro time uma visão, um valor para ser entregue, quais os passos para entregar esse valor e ainda, usando a priorização no momento da planning, você consegue definir o que o time deve atacar primeiro (mais importante) e por último (menos importante - costumo colocar coisas mais individuais, pequenas melhorias ou ajustes que não geram tanto valor, mas que eu gostaria que fossem feitos - caso não sejam feitos, não será um problema muito grande).

*O time deve respeitar a ordem das histórias e jamais pegar aquilo que possuem preferência por 2 motivos: A ordem da sprint está definindo que as primeiras histórias são mais importantes e seguindo o ordem, colaboramos com a melhoria contínua pois eventualmente os desenvolvedores vão sair da área de conforto (e nesse momento podemos usar o pair programming para distribuir o conhecimento e garantir o sucesso na entrega).

Na conclusão da sprint, cada história terá gerado uma branch feature, que por sua vez foi feito PR para developer e na conclusão do teste na branch developer (geralmente ambiente de homologação), podemos gerar PR para a main ou deixar por conta de alguma aprovação que dispara a esteira CI/CD para que a esteira automatizada faça esse trabalho (é bom que ninguém tenha acesso a main, apenas seu processo CI/CD).

Tudo em produção, é hora de validar o valor entregue pelo nosso épico, lembra? (Saberemos que isso é verdade quando o número de incidentes relacionados a endereço incorreto reduzir em 90%). É agora que vamos (todo o time e o PO/PM é o principal ator aqui). Não importa como, mas você precisa entender os seus dados e (para esse caso), registrar o momento atual (antes dessa entrega de valor) e medir por algum tempo para conseguir entender se você atingiu seu objetivo de reduzir em 90% os incidentes relacionados a endereço incorreto. Basta pegar a média de um intervalo passado e comparar com o mesmo intervalo após a entrega de valor, e caso observe essa redução nos incidentes, seu épico pode ser considerado como concluído.

--

Eu busquei ser bem objetivo para não gerar um conteúdo muito grande, espero que a leitura seja agradável. Não entrei em detalhe de coisas como (pair programming, definition of done e definition of ready, critério de aceite e objetivo de sprint) mas deixei links para te direcionar.

E para você que fez a leitura até aqui, espero te ajudar, espero que coloque em prática e caso goste do resultado, compartilhe esse material para melhorarmos a forma como desenvolvemos software e usamos os frameworks ágeis.

Abraço e sucesso ;)