Angels Orphanage

Angels Oprhanage

Esse post sai um pouco dos assuntos habituais do blog, mas nem por isso trata de algo menos importante. Pelo contrário, trata de um assunto muito mais relevante do que como desenvolver software.

Contextualizando, eu estou atualmente participando da ThoughtWorks University, em Bangalore, na Índia. Ontem, devido à inspiração fornecida pelo Roy, que é o dono da empresa (e tambem um cara excepcional), e devido a organização realizada por alguns outros colegas (aos quais eu sou extremamente agradecido :-) ), nós fomos visitar o Angels Orphanage, um orfanato aqui da cidade, onde 70 crianças vivem em um espaço que deve ser um pouco maior do que os quartos onde nós costumamos dormir.

Essa foi a minha primeira visita a um orfanato, e também foi a primeira vez que eu percebi a alegria que pode ser proporcionada a essas crianças somente dando pequenos presentes, como uma bola de futebol, ou oferecendo um pouco de tempo e atenção durante uma tarde, como fizemos ontem.

De certa forma fiquei um pouco pra baixo por essa ter sido a minha primeira vez, principalmente pq eu venho do Brasil, um lugar onde também existem milhares de crianças nessa situação que eu poderia ter ajudado de alguma forma. Mas por outro, também fiquei contente por ter finalmente feito isso, e espero que consiga continuar e não ter que esperar outros 25 anos por uma nova oportunidade.

E se eu tiver sorte, espero poder influenciar alguma pessoa que venha a ler esse post, para que ela também possa vir a ajudar.

Um abraço.

Duas Cabeças Pensam Melhor Que Uma?

A fagulha necessária para a criação de um post surgiu na leitura de alguns posts por aí (como esse), que me fizeram lembrar de um assunto sobre o qual eu tenho vontade de escrever a algum tempo: programação em pares.

Uma das razões para eu escrever sobre isso é o fato de eu já ter experimentado a programação em pares em duas oportunidades, a primeira na minha empresa no Brasil, e a segunda agora na ThoughtWorks University, e nesses dois períodos eu tenho percebido muito mais vantagens do que desvantagens nessa prática.

Programar em duplas, embora possa parecer anti-econômico à primeira vista, resulta em código muito melhor, aumenta a produtividade dos desenvolvedores (que não tem tempo para ficar lendo e-mails e falando no msn) e, principalmente, propicia o compartilhamento de informações e habilidades entre todos os membros da equipe, um dos problemas abordados nesse outro post.

Por sinal, o compartilhamento de informações é auxiliado por uma outra prática, que é a troca freqüente de pares, o que é detalhado no artigo Promiscuos Pair Programming, de Arlo Belshee, que também incentiva uma terceira prática, que é de o driver da dupla (o desenvolvedor que está efetivamente teclando) , seja aquele que possui menos experiência no que está sendo feito, para que assim este aprenda novos conceitos o mais rápido possível. Citando o artigo acima:

Promiscuity, it turns out, is a good way to spread a lot of information through a group quickly. Rapid partner swapping ensures that a good idea, once envisioned, is soon practiced by every pair. Replacing individual accountability with team accountability empowers each person to do those tasks at which he excels – and allow someone else to take over for his weaknesses.

E colocando o chapéu de desenvolvedor, para mim o principal benefício da programação em pares é um ambiente de trabalho muito melhor, e uma maior integração entre todos os membros da equipe. Faz diferença trabalhar ao lado de alguém, podendo conversar, trocar idéias e criar um relacionamento, ao invés de simplesmente chegar na empresa, sentar na frente de um computador e ficar lá até a hora de sair, sem falar com ninguém, como eu já vi em alguns ambientes onde eu trabalhei.

É claro que podem também surgir problemas na programação em pares, como é ressaltado nesse post, onde a troca excessiva de pares pode ser um problema. No entanto, ainda acho que esse e outros problemas podem ser resolvidos com bom senso, e os benefícios da prática são muito maiores.

Mas o que me incomoda um pouco (e também é uma das razões desse post), é que no Brasil pouco se tem falado sobre a utilização de programação em duplas. Em todas as listas e blogs que eu acompanho, essa prática era ressaltada a algum tempo atrás, mas parece que foi perdendo força aos poucos e hoje quase não é citada. Além disso, não tenho ouvido muitas notícias de empresas no Brasil adotando essa prática, ao contrário do que acontece no exterior.

Espero que eu esteja errado, e que as empresas estejam percebendo as vantagens de programar em duplas, e de como essa prática pode ser fundamental na formação de uma boa equipe de desenvolvimento de software.

Então, o que vcs acham, duas cabeças pensam melhor do que uma?

Abraços.

Behaviour Driven Development

Para os que não sabem, atualmente eu estou em Bangalore, na Índia, participando do treinamento que a Thoughtworks oferece aos seus novos graduates, a ThoughtWorks University.

Bom, ontem, depois de assistir a uma sessão opcional do curso, apresentada pela Liz Keogh, eu finalmente posso dizer que entendo o que é Behaviour Driven Development, o famoso BDD. Essa é uma das buzzwords do mundo do software que circula ha algum tempo, mas devo confessar que nunca consegui parar para verificar o que era, e sempre imaginei que fosse mais uma metodologia ágil, tipo o FDD.

Acontece que o Behaviour Driven Development é algo talvez até mais simples, mas nao por isso menos interessante :-) .

BDD nada mais é do que uma “otimização” do desenvolvimento orientado a testes, que tem como sua principal característica, e ainda mais importante, benefício, o fato de codificar as aplicações em uma linguagem voltada para o que é mais importante e muitas vezes esquecido, o resultado que a aplicação tem para o cliente.

Olhando por aí, uma justificativa interessante que eu achei foi a seguinte, no blog do Dan North:

As a final thought, while I was thinking about this I realised the term “behaviour-driven” contrasts with “test-driven” in a similar way. My goal as a developer is to deliver a system that behaves in a particular way. Whether or not it has tests is an interesting metric, but not the core purpose. “Test-driven” development will cause me to have lots of tests, but it won’t necessarily get me nearer the goal of delivering business value through software. So you can use goal-oriented vocabulary in your development process as well as your code to help maintain perspective on what you are trying to achieve.

Já que todos (todos?) concordamos que entregar valor de negócio para o que cliente é o que realmente importa no desenvolvimento de uma aplicação, porque não desenvolver essa aplicação de acordo com a linguagem do cliente, de forma que até ele possa entender (mesmo que em um nível básico) o que a aplicação está fazendo, e para que serve aquele código.

É claro que não é só esse o benefício, já que muitos de vcs devem estar pensando: para que diabos o meu cliente que ver o código-fonte do software?

Mas desenvolver código-fonte de acordo com a linguagem do negócio também auxilia o desenvolvedor a entender e discutir as funcionalidades que ele está desenvolvendo, e realmente saber qual é o objetivo de ele sentar na frente do computador 8 horas por dia, o que invariavelmente resulta em código de melhor qualidade.

Comentários?

Um abraço.