Anteriormente, todo sprint parecia bem nos primeiros dias, depois, de repente, alguns PRs ficavam presos, alguém sobrecarregado, uma funcionalidade pela metade, e então começava a correria de última hora. Agora, no meio do sprint, já fico sabendo que, cara, esse problema vai acontecer... PRs demorando mais, muito trabalho em um desenvolvedor, problema de qualidade de código em um lugar. Vimos um cara mesclando a maioria dos PRs sozinho, corrigimos isso, e nossos tempos de mesclagem melhoraram. Não há mais pânico de última hora.

Um grande desafio em identificar gargalos é descobrir exatamente onde no SDLC o problema ocorreu. Quando ele surgiu, por que está preso e quem está segurando? Era manual e demorado. Eu realmente aprecio o recurso de ciclo de vida de PR e issues. Isso torna as coisas muito mais fáceis ao mostrar exatamente onde e por que um problema está sendo atrasado. Nada mais de idas e vindas ou suposições!

Antes de usar o Signals, o planejamento de sprint muitas vezes parecia um palpite, e no meio do caminho, as coisas começavam a desmoronar. Eu não notava problemas como muitos pull requests (PRs) ou membros da equipe sobrecarregados até que fosse tarde demais para corrigi-los. Com o Signals, recebo alertas instantâneos quando algo não está certo, como PRs se acumulando ou alguém com trabalho demais. Uma vez que realmente se destacou foi quando o Signals me mostrou que um desenvolvedor estava lidando com a maioria das fusões de PRs. Não era algo que eu teria notado por conta própria, e não era sustentável. Distribuímos o trabalho de forma mais equilibrada, e imediatamente, as coisas ficaram mais suaves e menos caóticas. Outra grande ajuda é o relatório por e-mail no meio do sprint. Ele me dá uma visão clara se estamos no caminho certo ou se precisamos fazer mudanças. Em vez de lidar com problemas depois que eles saíram do controle, podemos corrigi-los cedo. A equipe fica menos estressada, e temos mais tempo para nos concentrar no trabalho real.