Seja ágil, abandone alguma coisa! #ágil

Bruno Brandes
Dec 20, 2017 · 5 min read

Há alguns anos, eu e minha equipe de desenvolvimento, decidimos abandonar estimativas de ponto e parar de medir velocidade com o intuito de experimentar uma solução de fluxo contínuo.

Gostaria de compartilhar com vocês, alguns dos resultados positivos que obtivemos com a decisão de abandonar alguma coisa e como nosso processo acabou ficando mais leve, simples e rápido.

Não jogamos mais baralho no trabalho ♦ ️ ♣ ️ ♥ ️

Planning Poker

A técnica Planning Poker foi definida em 2002 por James Grenning, e popularizada no livro Agile Estimating and Planning escrito por Mike Cohn no qual foi registrado o termo Planning Poker.

O grande erro aqui, é a mania de alguns desenvolvedores com largo histórico de criticas, que estão cansados de tomar bronca por atrasos ou que gostam de entregar “sempre antes”, querendo mostrar que são “eficientes”, com discurso de não iludir o cliente e acabam dando uma estimativa irreal, dizendo que algo trivial de se fazer, demora 2 anos pra ficar pronto.

Além disso, já vi vários times perdendo tempo estimando algo que no dia seguinte, foi re-priorizado e nem deve mais ser feito.

Paramos de converter pontos em frutas 🥝 🍓 🍎 🍌 🍍

Se você lida diretamente com um cliente interno ou externo que não entende pra que serve os pontos, provavelmente já ouviu:

Poxa, mas o time A esta com uma produtividade maior que o time B. Eles entregaram 50 pontos na última sprint e vocês apenas 40.

Para começar a explicar para essa pessoa, que não deve ser feito essa comparação, você já tem a árdua tarefa de explicar o que é fibonacci.

Sequencia Fibonacci

Alguns dias depois 😀, com a sequência fibonacci clara para seus cliente(s) e/ou gestor(es), você explica que não podemos comparar o time A com o time B com o argumento de que banana 🍌 é diferente de maçã 🍎.

O uso de story points para medir a produtividade é uma má idéia, pois isso levará gradualmente o time a inflar o significado de um ponto — Michael de la Maza

Produtividade

Não acredito que o desenvolvedor de software ou trabalhador do conhecimento tenha uma produtividade constante - Rodrigo Yoshima

Pontos de história foi criado para determinar a capacidade de um time e muitas vezes, é usado de forma errada para medir produtividade.

3 ° Métricas sem camada de abstração 📊

Se você está procurando melhorar seu processo, você já sabe que as métricas são essenciais para alcançar esse objetivo.

William Thomson

Muitas vezes pessoas criam muitas camadas de abstração para algo que elas esperam responder.

Quantos dias ou horas equivalem aqueles pontos da história ?

Para entender e melhorar o nosso fluxo de trabalho, passamos a lidar com dados científicos removendo as camadas de abstração.

Como não estimamos mais o esforço (pontos ) e a capacidade (velocidade) das atividades, passamos a extrair métricas do nosso próprio fluxo trabalho.

Lead Time

Informações do período em dias entre o início e o fim da implementação de uma funcionalidade/requisito.

Tempo de espera

Cycle Time

Quantidade de tempo em que uma equipe passa realmente trabalhando em uma funcionalidade/requisito.

Tempo de ciclo

Com estas duas métricas, extremamente simples, passamos a lidar melhor com as estimativas e conseguimos olhar para o nosso fluxo e questionar a nós mesmos o que atrapalhava a nossa agilidade.

Responder a uma das perguntas mais feitas em projetos

Quando fica pronto?

passou a ser algo natural já que a resposta é extraída do nosso próprio fluxo de trabalho.

Criamos um gráfico que nós da uma probabilidade do tempo que vamos demorar para entregar aquele item.

Lead Time Probability

No exemplo demostrado acima, temos um total de 16 bugs, sendo que 7 deles foram resolvidos em 1 dia, o que nos dá 44% certeza de que demoramos 1 dia para resolver um bug.

Não queria que você focasse no tipo de métrica que utilizamos, mas sim, como removemos as camadas de abstração para nossas métricas.

Conclusão

Muitas vezes, você utiliza uma mistura de métodos e abordagens, criando uma sopa de papéis, rituais, regras e ferramentas. Seu time está praticando o método Spotify com os famosos squads, e também adotou características de Kanban, Scrum ou XP.

O movimento ágil começou com profissionais de software que não estavam de acordo com abordagens waterfall e experimentaram métodos de maior velocidade e adaptativos. Eles se questionaram sobre o que poderia ser feito com menos processo, menos cerimônias e uma abordagem muito diferente do que o modelo cascata sugeria.

Não, eu não estou falando pra você criar uma nova metodologia, meu convite é apenas pra você refletir sobre quão simples esta seu processo hoje?

Então, fica aqui o meu convite: abandone alguma coisa!

Abra mão de um papel, uma regra ou uma ferramenta. Abandone algo por um período, colete métricas e veja se aquilo refletiu de forma positiva em seu processo e se não, volte mude algo e tente novamente.

E você, como tem lidado com os desafios de ser ágil? Deixe o seu comentário ai pra trocarmos ideias.

Curtiu esse seu conteúdo?

Recomende ele para que outras pessoas tenham acesso 👏.

Bruno Brandes

Written by

Software & Product Developer

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade