Você pensa antes de sair programando?

Gostei bastante da pergunta que o Plentz sentiu falta no post Teste: você é um desenvolvedor ágil?. Como não consegui decidir se ela deveria entrar lista, resolvi escrever um pouco sobre o assunto antes.

Acredito que o ato de pensar antes de se programar por si só não garante um bom código como resultado. Muitos ficam pensando horas antes de escrever a primeira linha de código inútil, enquanto outros conseguem sair programando e gerar ótimos resultados sem mal saber do que o problema tratava no início.

Um dos objetivos do desenvolvimento ágil é obter feedback rápido para melhorar a solução continuamente. E assim como isso é feito através de entregas constantes do software para avaliação dos usuários, também deve ser possível fazê-lo enquanto se está programando.

Eu normalmente penso o suficiente para escrever a primeira especificação do problema na forma de código (teste), e a partir daí o raciocínio vai fluindo conforme novos testes vão surgindo. Não sei se esta é a melhor forma, mas pelo menos me permite criar um jogo mental de “perguntas e respostas” para o problema que estou tentando solucionar. Eu parto de uma pergunta (mesmo que já tenha outras na cabeça) e procuro a resposta. Durante esta procura novas perguntas vão surgindo e desta forma que o programa evolui.

A questão é que isto só funciona quando posso me comunicar com alguém que possa me dar mais informações sobre o problema quando as dúvidas aparecerem. Vale lembrar que dúvidas aparecem por mais que se tente pensar antes de programar. Então isto significa que comunicação, assim como feedback, é vital para desenvolver um software.

Em resumo, ao meu ver o que importa não é o quanto se pensa antes de programar, e sim a quantidade de informação disponível antes de se começar. E no caso de desenvolvimento ágil creio que uma das vantagens é justamente não se exigir um detalhamento completo do problema antes do início da sua solução. São os “baby steps” que garantem que o desenvolvimento vai caminhar na direção certa.

Talvez a pergunta fique melhor assim: “Você busca o mínimo de informação antes de programar?”. Porque quem não pensa antes de sair programando provavelmente vai fazer besteira, mas quem pensa demais também pode estar perdendo um tempo precioso…

Ping Pong Programming

Pra quem quer experimentar um pouco de Pair Programming e TDD, este é o exercício:

De preferência em dois programadores (talvez com mais também funcione, se alguém conseguir me avise), definam um problema simples para ser resolvido. Agora sigam o processo:

1. Programador A escreve um novo teste que falha;
2. Programador B faz o teste passar;
3. Programador B escreve um novo teste que falha;
4. Programador A faz o teste passar;
5. Repita.

Simples, não? Seguindo estes passos já deve ser possível sentir a maioria das dificuldades e benefícios que ambas as práticas apresentam, e ainda pode servir como um passatempo para quem gosta de programar.

Esse exercício foi proposto em 2003, no Wiki da C2. Estou pensando em fazer uma sessão dele na próxima reunião do Dojo. Neste caso acho que vou precisar de um teclado sem fio

Qual a sequência de passos para fazer um software?

Se você está acostumado com a sequência:

1. Identifica a funcionalidade
2. Analisa
3. Programa
4. Testa
5. Entrega

Está na hora de aprender uma maneira diferente:

1. Identifica a funcionalidade
2. Testa (ou melhor: especifica a funcionalidade através de testes)
3. Programa (ou melhor: faz o teste passar)
4. Refatora (ou melhor: deixa a solução mais elegante)
5. Volta ao passo 2 quantas vezes for preciso!
6. Entrega

Essa é maneira XP de fazer as coisas. Maneira muito bem descrita pelo Thiago Arrais no seu post Andando de Costas, se referindo ao fato de como essa nova sequência pode parecer “invertida” para quem ainda não está acostumado. Recomendo a leitura

Reuniões diárias

Pra quem ainda não conhece a técnica (Daily Scrum Meeting ou Stand-up Meeting no caso de eXtreme Programming), a idéia de se ter reuniões diárias durante o desenvolvimento do software é para que cada membro da equipe responda:

• O que eu fiz ontem;
• O que eu pretendo fazer hoje;
• Quais são os impedimentos que estou enfrentando.

O objetivo da reunião é deixar todos a par do progresso do projeto e permitir que o coach (ou Scrum Master) possa trabalhar para remover possíveis obstáculos que a equipe esteja enfrentando. É uma prática que deve consumir no máximo 15 minutos, e ajuda a testar o foco e a disciplina da equipe diariamente.

Embora simples, esta é uma das técnicas que costuma enfrentar resistência das equipes, talvez porque necessita de um compromentimento com a pontualidade e a disposição de expor seu trabalho e suas dificuldades para o grupo, o que pode ser muito difícil para algumas pessoas.

Para se conhecer um pouco mais da técnica, e principalmente estas dificuldades, segue um vídeo encenado por Scrum Masters mostrando um pouco do que seria uma reunião diária problemática. Este vídeo conta com a participação do Boris Gloger, treinador da primeira equipe de Scrum Masters do Brasil, atuando como um membro que mais atrapalha do que ajuda no andamento da reunião: