Kenneth Freitas

 Bora conhecer alguns antipatterns de arquitetura, desenvolvimento e até gestão de projetos, que são um pouco conhecido, mas que acontecem várias vezes no dia-dia. Form de feedbacks

Pair Programming é uma prática que eu a-do-ro fazer. É um momento em que temos 2 profissionais juntando forças para criar o melhor resultado de alguma tarefa, seja um algoritmo complexo ou algo grandioso, onde um acelera o outro. Porém, na realidade (ahh a realidade…) não é bem assim, e na grande maioria das vezes gastamos tempo, não de um dev, mas de dois. Então, bora trocar uma ideia sobre como tocar um pair programming maneiro com o mínimo de desvios possíveis e, com sorte, não gastar muito dinheiro com dois devs. Antes de tudo, precisamos deixar algumas coisas extremamente alinhadas para que tais práticas deem certo, são elas: Pessoas: Não adianta querer implementar tais atividades colaborativas se as pessoas envolvidas não são tão colaborativas assim. Nisso, nem entra o fato da pessoa ser mais fechada ou não, mas é muito comum que, diante de um problema ou algo que necessite de esforço, fazer sozinho aumenta a concentração e não adianta tirar a pessoa da linha de raciocínio. Porta...

Dando continuidade ao nosso papo sobre a daily , hoje vamos falar de review. Uma cerimônia muito importante e que muitos times enxergam apenas como uma entrega do trabalho realizado durante a sprint. Enfim, não é chato quando você entra na review e cada desenvolvedor, um após o outro mostrando o que fez, sendo que geral já sabe (ou deveria saber, né), fazendo com que mais uma cerimônia fique com cara de report... A partir do momento que o time possui um DoD definido e está de fato entregando um incremento potencialmente utilizável, muuuuuito provavelmente ele já vai ter passado pelo QA e ter sido homologado antes da review. Se ele está chegando na review sem ter passado por essas etapas, está na hora de repensar seu DoD urgentemente, mas isso é papo pra outra hora, estamos aqui na premissa que a entrega são itens prontos, para que a review não seja uma cerimônia onde vamos homologar todos os itens de uma vez novamente em grupo. Também não é o momento de entrega para o PO, porque ele já...

É tão chato quando você chega em um time e a daily da galera é "Fulano, o que você fez ontem?", "Fulano, o que você vai fazer hoje?" e claro "Fulano, você tem algum impedimento?". E assim vai, depois do fulano, o mesmo se repete para o ciclano e continua, um por um, de forma robotizada, aquela “cobrança” de um status report. A daily tem como principal objetivo alinhar e realinhar (se necessário e quantas vezes for preciso) o time em direção ao objetivo da sprint. Esse padrão das 3 perguntinhas, além de desatualizado (não está mais no Scrum Guide, versão mais recente de 2020), já está até meio batido por não ser lá a coisa mais eficiente do mundo, já que na prática não traz muito valor. Não permite que o time se questione sobre o objetivo da sprint, não fomenta a colaboração e por fim (mas não menos importante) não permite que o time trace um plano para concretizar uma entrega de valor. E aí vai a sugestão, que tal adotar uma abordagem mais “Kanbanizada” j...