O que a gente faz está distante do por que a gente faz.

Com essa frase do meu amigo Henrique Bastos, começo esse post de hoje.

O que um programador faz? Programa, testa, descobre erros, resolve erros. Por que a gente faz? Pra alguém usar o que a gente construiu com um sorriso no rosto.

Então, desde o início, que é programar, até o destino final, que é o usuário usando algo com um sorriso no rosto, tem um processo grande de ações.

A solução para nunca ter problema ao entregar um projeto (contém ironia)

Muitas empresas, principalmente as de tecnologia, resolvem aplicar metodologias ágeis nas equipes com a promessa de entregar software com qualidade e no prazo, por exemplo.

Metodologias ágeis são práticas para aplicar em demandas de um projeto para realizá-las com eficiência e agilidade. Agilidade, aqui, não é necessariamente ser rápido, mas poder mudar de direção rapidamente, caso necessário.

Por exemplo: uma agência vai criar um site para a Taylor Swift. O prazo é de 1 mês. É melhor que a cada semana a agência mostre o site em funcionamento, mesmo incompleto, para que, caso haja alguma mudança, possa já ajustar no momento oportuno, ao invés de entregar tudo de uma vez 1 mês depois (com sorte de não atrasar) e ver que precisa mudar algo em cima da hora.

Scrum

• Um método ágil famoso e muito utilizado é o Scrum.
• Resumidamente — bem resumidamente — consiste em:
• Uma pessoa vira dono do projeto, o chamado PO (Product Owner);
• O PO assume a bucha e divide o projeto inteiro em funcionalidades;
• Cada funcionalidade é dividida em “cartões”;
• Para melhor visualização, todas as funcionalidades são colocadas em um quadro, físico ou online, numa coluna chamada Backlog, dividida por prioridades, onde geralmente a funcionalidade com maior prioridade fica em cima;
• Há também outras colunas como TO DO (Fazer), DOING (Fazendo) e DONE (Feito) — podendo ter variações disso;
• O projeto é dividido por blocos ou ciclos. Cada ciclo é chamado de sprint. Cada sprint geralmente dura 1 ou 2 semanas;
• Há algumas reuniões durante as sprints:
  • Uma por dia, de 15 minutos para ver se há algum problema, se alguém precisa de ajuda, etc;
  • Uma para iniciar, de mais ou menos 1 hora e definir o que cada pessoa do time fará;
  • Uma para fechar, de mais ou menos 1 hora para discutir como foi a sprint.

É possível, claro, fazer mudanças nesse método e ajustar conforme a empresa ou o projeto precisa.

Vai dar merd*

Para utilizar o Scrum, o time precisa estar muito maduro.

Falando no contexto que vivo, como software sempre dá problema, é possível — bem possível! — que no meio do caminho seja preciso pausar o que o time está fazendo e começar a atender uma demanda urgente.

Com o backlog de Scrum, pode ser que o time fique muito ansioso ao olhar as tasks a serem feitas e o tempo passando. Sendo assim, pode acontecer muito de chegar ao fim de uma sprint com grandes chances de não entregar todo o combinado.

Na verdade, isso acontece demais. Aconteceu na empresa americana que eu trabalho.

Apesar de não impactar nos projetos e comprometer nas entregas — o time é excelente e sempre entrega muito valor — as sprints quase sempre acabavam sem concluir tudo o que foi combinado nas reuniões iniciais (às vezes até mais do que o previsto porque precisou adicionar mais coisas no meio do caminho).

Kanban para salvar

Uma outra metodologia ágil famosa é o Kanban, originário do sistema de produção da Toyota.

A promessa dele também é ser eficiente, mas com o objetivo de minimizar desperdícios.

Resumidamente, consiste em:

As tarefas são visualizadas em um quadro, seja físico ou online;

Há 3 colunas: TO DO (Fazer), DOING (Fazendo) e DONE (Feito);

Cada tarefa é representada em um cartão que se move pelo quadro;

Pode haver reuniões conforme alinhamento de cada time.

Bem parecido com o Scrum, certo?

Pra mim, a principal diferença é que não há esse “fechamento” de ter determinadas tasks para cada sprint. Agora não há sprint. Há prioridades.

O time todo pode ver o progresso de forma flexível e intuitiva.

Erre rápido, ajuste rápido

Sou fã da cultura americana no trabalho.

“Se trabalho, foco totalmente naquilo.”

Lá na empresa, não havia Scrum. Há uns 6, 7 meses, se não me engano, tentamos essa metodologia. Não deu certo. Numa das reuniões, uma pessoa apontou que isso poderia melhor, explicou o que sentia — e todo mundo também — e um dos líderes, na hora, já resolveu começar a fazer a mudança propondo o Kanban. No meio de dezembro. Esperar janeiro pra quê?

Não precisa esperar janeiro

Isso me fez refletir. Se uma coisa precisa melhorar, por que esperar mais?

Meu temperamento é melancólico. É aquela pessoa que, pela natureza, demora para tomar uma ação; precisa internalizar aquilo, fazer os prós e contras na cabeça, analisar dados, refletir e, aí sim, agir. É a pessoa profunda, intensa, que contempla.

Pra muita coisa isso é bom. Pra outras, nem tanto.

Essa é uma das coisas que tenho feito o esforço de melhorar.

Não preciso esperar janeiro. É agora.

O que você pode mudar ainda hoje? Eu já sei o que vou mudar.

E o que você quer mudar ano que vem? Quais são suas metas? Nos últimos 2 anos, tenho usado um livreto para me guiar e me ajudar a definir metas: Year Compass. Se quiser conferir e também usar, é gratuito: https://yearcompass.com/br/

Para este ano vou fazer o possível para ser mais direto ainda. Ao invés de ter uma meta “ir ao Jiu Jitsu o máximo que conseguir”, será, por exemplo, “ir ao Jiu Jitsu ao menos 15 vezes por mês”.

Mas deixe também um espaço para a flexibilidade. A gente não pode controlar tudo. Hoje, acho importante ter metas, mas também precisa ter espaço pra mudança, se necessário.

Como diria meu outro amigo Augusto Goulart, reproduzindo um ditado popular:

O homem planeja e Deus ri.

Boa sorte com suas metas. Espero que você alcance seus objetivos.

Não deixe nada do que pode fazer ainda hoje para depois.

Planeje. E ria com Deus também.