Like A Girl

Pushing the conversation on gender equality.

Code Like A Girl

Peço desculpa, não peço licença

Um relato sobre parar de fazer ágil e começar a ser ágil.

A gente entra no projeto, e percebe de cara: estamos “fazendo ágil”. Temos sprints, temos dailies, plannings, reviews e retrospectivas. Ágil, certo?

Já na daily aparece o porquê de terem falado que era um “projeto trouble”. Cada membro do time fala “ontem eu fiz isso, hoje vou fazer isso, sem impedimento”. Nenhum dos outros membros do time chega sequer a cruzar o olhar com quem está falando. Se alguém diz que está impedido, o time não reage, e os poucos que escutam fazem cara de “atá”. A daily é um status report para ouvidos moucos.

Alguns dias depois, chega a Review. O time, derrotado, não conseguiu entregar a sprint. Qual era o objetivo da sprint? Ninguém sabe, mas aposto que se eu perguntar, vou ouvir que era “entregar todos os itens da sprint”. O incremento é apresentado para o PO. Não há um único usuário ou stakeholder num raio de quilômetros.

Vamos para a retrospectiva, que se arrasta por 4 horas, enquanto os membros do time lambem as feridas e buscam um pouquinho de empatia. O que foi bom, o que pode melhorar… O time já nem tem mais ânimo de montar um plano de ação. Nada muda. Nada melhora.

Na planning descubro que há toneladas de bugs para tratar, e os itens de backlog de maior valor estão no final, pois representam o fim de um processo cronológico completo, com todos os fluxos alternativos e de exceção. Não há qualquer tipo de mensuração do valor, nem alinhamento com os objetivos da companhia. Aliás, que objetivos da companhia?

Já viu isso antes?

Se a resposta é sim, não se sinta só. A maioria das empresas que encontro hoje está “fazendo ágil”: um escopo completo, mapeado de forma cascata, que não pode ser mexido para não impactar a data que já está definida para lançamento (que todos sabem que é inviável, mas ninguém quer falar), e um planejamento sprint a sprint para a mera execução deste escopo definido na data definida. Escopo, prazo e custo fixos.

Estas empresas estão “fazendo ágil”, mas ágil não é algo que se faz; ágil é um estado de ser, um mindset. Neste cenário, com ou sem sprints, o projeto vai pelos ares. Primeiro a qualidade vai pro saco. Em seguida o custo. Depois o prazo. Por último, a data tendo sido postergada várias vezes, finalmente o escopo é cortado, e se coloca no ar o que estiver pronto até ali. Com sorte.

Com sorte, este produto que foi testado com absolutamente zero usuários vai servir para alguma coisa. Com sorte, os clientes não vão achar mais cômodo simplesmente continuar fazendo as coisas à moda antiga. Mais um produto vai pra prateleira, engordando a métrica de software que jamais ou raramente será usado.

Ou a gente pode começar a fazer direito. A ser ágil. A olhar para o Backlog e perguntar: o que eu quero testar com meu usuário daqui a duas semanas? Qual é o mínimo que o meu time tem que desenvolver para eu testar isso?

Podemos começar a descartar itens. Sabe todos aqueles fluxos de exceção? Que tal deixar o usuário dar com a cara na parede *antes* de sair salpicando alertas por todo o sistema como se o seu cliente fosse de vidro e jamais pudesse encontrar um erro? Vamos testar, e ver o que ele vai fazer. Aquele fluxo alternativo cabuloso que o time levou duas sprints para desenvolver é inútil se o usuário nunca clicar ali. E, se muitos usuários clicarem ali, questione a eles sobre o que eles esperavam que acontecesse, e aí sim desenhe um processo leve, com base na resposta.

E não tenha medo de arriscar. Me acostumei a falar que é melhor pedir desculpa do que pedir licença. É importante que haja transparência, que todos saibam o que a gente está fazendo e porque, mas sempre, SEMPRE precisamos confiar mais nos dados do que em achismos. E, para conseguir os dados, vamos ter que iterar rápido. Para iterar rápido, vamos ter que testar e arriscar, e isso torna inviável pedir aprovação de cada teste que precisamos fazer.

Nessas horas, eu sou aloka que compra as brigas.

Aceitemos de coração que o mercado, o desejo dos stakeholders, as restrições orçamentárias, a situação econômica do país e, principalmente, a cabeça do nosso usuário são todos imprevisíveis. Mas isso é ótimo! A imprevisibilidade é a mãe da inovação. E qual de nós não quer ser inovador?

Se já soubéssemos de tudo, inovar seria impossível.

Inspirado nesse artigo aqui.

Siga a tag codelikeagirlBR para ver nossos posts! 😀

Quer escrever ou traduzir artigos em português para a Code Like A Girl? Se você já faz parte do time de escritoras(es) da Code Like A Girl basta enviar seu artigo diretamente para nossa publicação. Se você ainda não faz parte do nosso time, envie uma mensagem direta para a conta de twitter CodeLikeAGirlBr. Nós avaliaremos seu artigo e ajudaremos a refiná-lo para publicação.