Uma funcionalidade nova é solicitada e é passada ao time de desenvolvimento, uma pessoa pega essa atividade e começa a trabalhar nela. Nas primeiras das famigeradas daily meetings/standup meetings são reportados os avanços esperados: “Ontem criei os modelos e hoje vou fazer a tela de listagem” ou “Ontem implementei os testes da tela de cadastro e hoje vou integrar o novo editor de texto”. Passam duas semanas, três semanas, um mês, ou até meses (sim, meses) e os relatórios diários se tornam repetitivos, algo como “Ontem eu continuei investigando o problema no editor, e hoje vou continuar nessa investigação, mas tá perto, falta só isso e aquilo, acho que próxima semana termino”. Essa próxima semana nunca chega e a gestão vive perguntando no canal de comunicação: “Como tá essa atividade? Tem algum prazo?”. Finalmente quando a atividade é finalizada, é aberto um pull request/merge request de dezenas (até centenas) de arquivos, com as modificações mais abrangentes possíveis misturando novas funcionalidades, refatorações e correções. A revisão de código se arrasta por mais alguns dias ou semanas, e em muitos casos só é aprovado porque daria um trabalho imenso apontar onde e como melhorar e também ficaria feio falar “Joga fora e faz de novo totalmente diferente”, que talvez fosse até a melhor opção.

Já presenciei as cenas narradas acima algumas vezes e acredito que a maioria de nós que trabalha com desenvolvimento de software já passou por uma situação similar em algum momento da carreira ou ainda vai passar, seja como a pessoa que desenvolve, seja como colega de time, líder dessa pessoa, gerente de projeto, scrum master e etc. Os motivos pra situações como essa acontecerem podem ser vários, pode ser que a tarefa era ambiciosa demais, que a pessoa não tinha capacidade técnica pra executá-la, que a pessoa estava assistindo vídeo fingindo que estava trabalhando, a pessoa estava passando por problemas, que o escopo não era claro e mudava muito durante a implementação, que as prioridades mudavam constantemente, a base de código estava deteriorada, enfim, há inúmeras possíveis causas.

Pra evitar passar por mais situações como essa, eu venho incentivando os times em que trabalho a encararem as atividades recebidas como projetos e quebrar ao máximo essas atividades em atividades menores. Apesar do título do artigo falar em pull requests, isso vai além, é toda uma cultura de trabalho, é um processo de entrega que envolve o time de produto e tecnologia, e que traz benefícios amplos. A adoção de pequenas tarefas tem se provada uma ótima decisão pra todos os envolvidos e explico meus pontos a seguir.

Revisão de código mais eficiente

Com pull requests com menos arquivos, e com mudanças mais focadas, as revisões ficam mais rápidas e, principalmente, ganham qualidade, pois é mais fácil entender as mudanças e sugerir novas ideias. Em um PR muito grande, a qualidade exigida durante a revisão de código cai bastante. Há um ditado que fala: A qualidade de uma revisão é inversamente proporcional ao tamanho do pull request.

Facilidade no QA/Homologação

Seguindo a mesma ideia do ponto anterior, uma mudança menor é mais fácil de ser testada e homologada, e caso algum erro apareça, mais rápido o erro será corrigido.

Facilidade no deploy/rollback

Uma mudança menor também tem menos chances de causar problema, por alterar menos arquivos, por ter passado por uma revisão mais criteriosa de código e de funcionamento, e caso aconteça algum problema, na maioria dos casos é mais fácil reverter a mudança.

Menos tempo com PR aberto

Com as revisões sendo mais rápidas, as mudanças têm menos chances de terem conflitos com as mudanças de outras atividades, e a pessoa que está executando tem menos troca de contexto. Quando uma pessoa tem vários outros PRs abertos, ela vai precisar ficar indo e voltando neles durante vários dias para corrigir comentários, conflitos, erros de homologação e etc.

Melhor planejamento

Para quebrar um projeto em atividades menores, a pessoa vai precisar raciocinar e ter pelo menos uma visão mais ampla do que será necessário fazer para entregar aquele objetivo, levando a um planejamento prévio antes de sair escrevendo código.

Melhora ritmo de entrega

A pessoa quando está executando uma atividade muito longa, ela tem maior facilidade de perder o ritmo e a produtividade, pois ela está afundada em vários arquivos que ela modificou há dias, sem saber fácil o que foi feito e o que falta fazer. Com atividades pequenas, todo dia a pessoa está iniciando e entregando uma, duas, três atividades ou até mais.

Facilita o acompanhamento do progresso

A gerência não precisa ficar mais jogando mensagem no canal de comunicação: "Como tá essa atividade?", "Conseguimos entregar essa semana?". Aliando esse melhor planejamento com um quadro de tarefas atualizado, é fácil acompanhar como está o progresso de uma entrega, pois dará para ver que, por exemplo, das 9 atividades, 6 já foram concluídas e que outras duas estão em andamento.

Facilita detectar problemas individuais

Nem todo mundo está 100% em 100% do tempo, há períodos de baixa e é necessário entender isso. Adotando as atividades pequenas, é fácil entender quando uma pessoa do time está repetidamente demorando várias semanas para entregar duas ou três atividades, enquanto o resto do time entrega 5 a 10 atividades por semana. Isso ajuda a liderança detectar situações assim e iniciar conversas para entender o que a pessoa está passando e ter uma alinhamento mais claro.

Mas como dividir melhor as atividades?

Primeiro é importante entender o que é necessário pra colocar isso em prática e eu penso que há 4 pontos:

Capacidade de planejamento

A pessoa que vai executar a tarefa, precisa saber dividir, ordenar e priorizar bem as atividades. Essa habilidade é possível aprender praticando no dia a dia e com ajuda do time que vai revisar suas entregas. A própria pessoa também vai saber quando um pull request ficou grande e tentará melhorará na próxima oportunidade. Também é possível durante a execução de uma atividade, perceber que algo ficou muito extenso, dividir o que foi feito em duas ou mais atividades e criar pull requests pra cada uma e isso servirá de aprendizado para os próximos planejamentos.

Boa estratégia de deploy

Adotando essa estratégia, muitas vezes uma atividade não estará completa a ponto de ser disponbilizada aos usuários, então é necessário escondê-la e tomar cuidado para ela não impactar as coisas que estão funcionando corretamente. Isso pode ser feito com a estratégia de feature flag, por exemplo. Também é importante termos um deploy pra produção e staging facilitado, pois aumenta o volume de entregas, e qualquer atrito nesse processo pode não dar os resultados esperados.

Contornar gargalos

Como pode acontecer de uma atividade depender da outra, por exemplo: A atividade de listagem pode depender da atividade de criação do modelo, é importante saber sinalizar e contornar essas dependências, seja tendo outras atividades na fila pra serem iniciadas, seja priorizando a entrega da atividade dependente.

Alinhamento com as pessoas de produto

O time de produto precisa estar alinhado com essa estratégia, sabendo que nem toda atividade entregará valor ao usuário final. Também aproveitar que a atividade está bem dividida pra colocar em prática a redução de escopo quando os prazos não forem possíveis de ser alcançados.

Exemplo

Agora vou mostrar um exemplo de como gosto de fazer o planejamento de uma atividade/projeto. Vamos supor que eu preciso entregar a funcionalidade de permitir que o usuário publique uma newsletter para os seus seguidores, os requisitos são:

1. O usuário pode listar, criar, editar e apagar posts
2. O usuário pode editar o corpo do post com um editor de texto avançado
3. O usuário pode salvar um post como rascunho
4. As modificações feitas no corpo devem ser salvas automaticamente
5. O post deve ser enviado aos seguidores do usuário por e-mail
6. O post deve estar visível publicamente na página do usuário

Geralmente eu vejo as pessoas fazendo isso em uma, duas, três atividades, mas eu dividiria isso em pelo menos umas 20 atividades, sem exagero. Resumindo um pouco, ficaria algo mais ou menos assim:

1. Criar modelo Post
2. Criar componente do design system para ser usado na listagem de posts
3. Criar tela de listagem de posts
4. Criar tela de cadastro de post (com um textarea simples para o corpo)
5. Criar tela de edição de post
6. Permitir apagar um post
7. Enviar post para os seguidores após a criação
8. Criar tela pública de listagem de post
9. Permitir que um post possa ser salvo como rascunho
10. Aplicar editor de texto avançado na criação/edição de post
11. Permitir upload de imagens no editor de texto avançado
12. Configurar salvamento automático no editor de texto
13. etc..

Perceba que com essas atividades bem divididas, eu já consigo entregar a funcionalidade pro usuário com as 8 primeiras atividades finalizadas, facilitando a diminuição do escopo de entrega e entregando valor mais rápido, permitindo validar a ideia e iterar em cima dela com as demais atividades. E voltando pros pull requests, vai ser melhor revisar a criação do modelo, com suas validações e relacionamentos, do que revisar essa mesma coisa mas junto e misturado com 4, 5 telas, controllers, testes e etc.

E uma forma que não recomendo fazer, que já vi dividirem as atividades assim e NÃO funcionou porque não conseguiu tirar os proveitos listados nesse texto:

1. Implementar modelos
2. Implementar use cases
3. Implementar controllers
4. Implementar páginas
5. Implementar testes

Conclusão

Adotar essa divisão de atividades em atividades bem menores é uma mudança que no começo é difícil, por ainda estar em fase de adaptação, não ter certeza se está dividindo as atividades da forma certa, se as atividades estão grandes ou pequenas demais, mas com o tempo essa prática ficará confortável e trará os benefícios esperados.

Também é necessário uma mudança de mentalidade de todos que fazem parte do processo de entrega, não adianta quebrar as atividades em atividades menores, e essas atividades demorarem uma vida pra serem revisadas, aprovadas e integradas, pois ao invés de facilitar, só criará gargalos no processo.

Mesmo que no fim, o tempo de entrega não se altere, ou até aumente um pouco, essa prática não é apenas sobre isso, tem toda uma questão de manter-se num ritmo contínuo de entrega, que em atividades longas, esse ritmo é muito mais fácil quebrar, mais difícil de detectar que quebrou e entender as causas.

E claro, isso é só um relato das minhas observações do que funcionou pra mim, mas pra você algo não pode funcionar, então é bom ficar atento pra fazer os ajustes necessários pra se adaptar ao seu contexto.