Impressões sobre o Sun Tech Days Florianópolis

Para começar, fiquei impressionado com a quantidade de pessoas que não conheciam Desenvolvimento Orientado a Testes! De cerca de 100 pessoas presentes, somente umas 10 conheciam a técnica. Por outro lado, estas 10 pessoas disseram usar TDD no seu dia-a-dia, o que já é algo animador!

Isso também me fez pensar: como essas 90 pessoas constróem seus softwares afinal? Somente uns 3 ou 4 disseram usar diagramas UML. E o resto? Vai na base do code-and-fix mesmo? Sinceramente não faço idéia.

Outra coisa que pude notar é que a maneira mais fácil de explicar TDD é na prática mesmo. Durante meia hora me foquei retirar a “cara de interrogação” de muitos dos presentes com alguns poucos slides explicando o ciclo vermelho-verde-refatoração, e as coisas fluíram bem melhor quando chamei uma pessoa da platéia para resolver um exercício no Eclipse com o jUnit. Aí sim as dúvidas práticas começaram a surgir e a maioria pôde entender do que TDD se trata exatamente.

Este exercício também me confirmou outra coisa que venho notado nas reuniões do Dojo: programadores realmente não gostam de programar na frente de outras pessoas. Não sei até que ponto é timidez ou receio de ter suas habilidades colocadas à prova, mas oras, se é isso que vocês sabem fazer, por que não mostrar para os outros?

Quanto a organização do evento, senti falta de internet sem fio para publicar este post direto do próprio evento, e de um coffe break, que se teve eu sequer vi. Ah! E apresentaram a minha palestra como sendo de “Test Drive” (!). Tirando estes detalhes, acredito que a organização fez bem seu papel.

E espero que o público tenha aproveitado o tanto quanto eu. Se alguém que participou estiver lendo, fique a vontade para dar sua opinião também!

Sun Tech Days JUGs Edition – Florianópolis

Amanhã (19/04) acontecerá o Sun Tech Days JUGs Edition em Florianópolis:

Através de uma parceria entre a Sun Microsystems, o SouJava e a Unisul, o GU Java SC/SUCESU-SC traz até você as informações mais relevantes do evento Sun Tech Days, que acontece em São Paulo nos dias 18, 19 e 20 de Abril.

Além da retransmissão das palestras de São Paulo, a parte da tarde do evento trará apresentações locais, e eu participarei ministrando um minicurso de Test-Driven Development.

Minha intenção é seguir um pouco dos moldes das reuniões do Coding Dojo, apresentando um pouco da teoria de TDD e depois abrindo a discussão e apresentando um exemplo prático da técnica. Desta vez provavelmente não será possível fazer todo o exercício revezando as duplas, mas espero que apareçam voluntários na hora para me ajudar na programação

Para quem estiver interessado no evento, a inscrição é gratuita (vagas limitadas) e pode ser feita no site do evento. Até lá!

Abrace as mudanças no seu software

Um dos maiores fatores de estress em projetos de software é a mudança desordenada no escopo. As funcionalidades mudam durante o projeto com mais frequencia do que a equipe gostaria, e isso se reflete negativamente por todos os lados.

A questão é que a maioria das pessoas que já se envolveram com projetos de software sabem que as mudanças fazem parte (e a minoria se engana achando que não), porém dificilmente as pessoas se preparam para quando isso acontece. E os resultados mais comuns disso são: cliente insatisfeito, desenvolvolvedores frustrados e prazos/custos estourados. Isso sem mencionar a qualidade do produto final.

Por isso proponho 2 tarefas para melhorar este cenário:

• Defina datas para as mudanças acontecerem

Duas coisas que incomodam os desenvolvedores são: interrupções e trabalho jogado fora. Uma maneira fácil de evitar isso é educar o cliente* para que faça seus pedidos apenas em datas pré-definidas. Obviamente o cliente vai continuar pedindo alterações a qualquer momento, mas é preciso deixar claro quando que estas alterações serão trabalhadas e o qual será o impacto delas.

Se o cliente começar a ficar insatisfeito com o quanto ele precisa esperar para ter suas mudanças, é sinal que estas datas precisam estar mais próximas uma das outras.

• Automatize seus testes

Agora é a vez dos desenvolvedores fazerem a sua parte. Uma vez que as mudanças do cliente já são esperadas, é preciso fazer com que estas mudanças no software não signifiquem queda na qualidade. E é aí que entram os testes automatizados. Poder verificar facilmente todas as funcionalidades do sistema a qualquer momento é o que dá confiança para um desenvolvedor mudar qualquer coisa a qualquer momento.

O impacto de uma mudança de requisito pode ser maior ou menor, e os testes permitem verificar com mais clareza como a mudança se reflete no resto do sistema. Isto acontece porque uma vez que uma parte do software é modificada e todos os testes são executados, todos os pontos onde esta mudança causou problema são descobertos na hora. E com este feedback rápido os desenvolvedores poderão verificar se suas estimativas estavam corretas e se a implementação está correndo como o planejado.

Em resumo

Permitir que mudanças de escopo sejam bem-vindas num projeto de sofware precisa ser um esforço tanto de cliente quanto desenvolvedores e a palavra-chave para diminuir o estress é disciplina. Quanto mais previsíveis forem os clientes e mais testes automatizados forem escritos, melhor serão aceitas as mudanças.

* Definição de cliente: aquele que define os requisitos do software, não necessariamente aquele que está pagando.