Tudo que tenho para falar é como trabalhamos com os principios Ágeis. Eu começei em XP em 2000 e trabalhei com isso por muito anos… já são 10 anos de experiência. Nós buscamos a melhor maneira de desenvolver software. Começando sobre princípios e iterações sobre processos e ferramentas. Isso nos diz que a coisa deve estar em busca das pessoas. Como a programação em par impacta na produtividade? Isso parece contra a intuição, mas duas pessoas trabalhando em um computador pode ser mais produtivo que duas pessoas trabalhando em dois computadores. A melhoria do design no desenvolvimento em par é melhorado, além de ser mais gostoso. Pair programming não é uma coisa natural pois não é naturalmente usado em grandes empresas, mas é preciso aprender… e leva um certo tempo.

Eu acho muito importante ter dois teclados e dois mouses pois dessa maneira, uma só pessoa que tenha um perfil dominante não trabalha sozinha. Um dos princípios que melhora a produtividade é a revisão de código automática. Ao trabalhar em par isso é natural. Quando está trabalhando em par se trabalha o dia todo. Pois ao trabalhar sozinho, você vê o seu e-mail, lê blogs e etc. E essas coisas não acontecem com programação em par. Ao fim de um dia de programação em par você está cansado. Pois você realmente pensou e trabalhou o dia todo, mas você fica contente, pois sabe que teve o trabalho realizado.

É comum entre nós desenvolvedores, muitos de vocês mais inteligentes do que eu trabalham muito bem. Então dizem que demoram uma hora para realizar o trabalho, mas ficam horas escrevendo no blog e no twitter, fazem o trabalho em 5 minutos e depois vão para o almoço. O pair programming elimina isso. Ele te dá muita produtividade. Para as pessoas farerem pares é preciso contratá-las. Quando eu contrato pessoas para a minha empresa eu faço um post no meu blog e espero as respostas. Você diz as suas habilidades e é convidado a trabalhar por uma semana para nós sabermos se você é bom de verdade fazendo pair programming num projeto de verdade. Então nós contratamos as pessoas sem entrevistas, mas com elas trabalhando num projeto real por uma semana. Só por que alguém vai bem numa entrevista não tem relação em como ela é no dia-a-dia do trabalho. Em times pequenos é mais fácil de manter a felicidade de todas as pessoas. Times de 2 a 4 pessoas são boas opções. Além disso vocês podem ter problemas de comunicação.

Mais um principio que se pode utilizar ao ter um time de 2 a 4 pessoas é ter um time auto-organizado. Na nossa empresa a gente não tem chefes. Todos os times são auto-gerenciados. Pois se você tem um time desse tamanho de apenas pessoas boas e você tem um lema “todo mundo junto” as coisas simplesmente funcionam.

Software funcionando em contrário a uma extensiva documentação. Uma maneira de trabalhar desse jeito é usando rspec, nós somos fãs de rspec. É uma ferramenta tão eficiente, ela não somente ajuda você a trabalhar com o software, mas também para gerar uma documentação, que nós entregamos para o nosso cliente. Isso com certeza agrega valor ao nosso trabalho.

Eu me importo em ser real e essa uma razão pelo o qual eu estou envolvido por tanto tempo com Rails. Nós participamos do Rails Ramble de 2007, isso foi antes da formação do Rails Rocket, e isso mostrou pra gente que é possivel com Rails fazer um trabalho muito grande com pouco tempo. Foi muito bom trabalhar com essas restrições, pois na nossa área é comum o tamanho de um projeto expandir para caber no tempo total disponível para o desenvolvimento.

Nós trabalhamos com um conceito chamado 3-2-1. Que significa colocar um software no ar em 3 dias, onde temos 4 desenvolvedores, 2 da nossa equipe e mais 2 que chamamos para uma semana de trabalho.

Colaboração do cliente em frente a negociação de contratos. Isso tudo tem relação com transparência em relação ao cliente. Isso leva confiança ao seu cliente. Nós gostamos dos clientes com o qual trabalhamos.

Uma coisa importante é que você precisa ter um designer dentro da equipe que saiba fazer todo o visual do nosso projeto. Pois sem um projeto visual acabado, nós não temos o que mostrar para o nosso cliente. É bom ver exatamente como vai ficar e eu posso construir isso em 3 dias se você me mostrar como vai ficar.

Por outro lado, quando já temos um design, não temos muito o que divergir da maioria é que nós gostamos de user stories, que para nós significam a aceitação do cliente. Nós trabalhamos com cartões e com projeções para atividades que duram de 0 até 8 pontos de desenvolvimento. Com isso nós medimos o desenvolvimento de nosso equipe e quantos pontos podemos fazer por semanas. Na nossa equipe é comum fazer algo em torno de 25 pontos por semana. Em 0 pontos nós temos coisas que duram apenas alguns minutos e em 4 pontos nós temos coisas que duram uma semana.

Antes nós perdíamos muito tempo com negociação de contrato. Então nós desenvolvemos um documento, que serve como nosso contrato, que não exije que o cliente nos pague caso ele não esteja satisfeito. Esse contrato tem um termo especial que diz que ele não pode te processar por mais dinheiro que ele iria te pagar. O nosso contrato também estabelece que nós podemos contribuir com o mundo opensource com o código desenvolvido para eles, mas só as coisas que não são específicas do cliente, como plugins e gems que você desenvolveu para trabalhar naquele projeto.

E a última parte do manifesto ágil é responder a mudanças em vez de seguir um plano. Nós usamos um serviço chamado pivot tracker e ele é muito bom pois ele nos mostra muitas informaçõe sobre o nosso projeto, incluindo gráficos de burndown entre outros. A stand up meeting é outra coisa essencial para nós sobre como anda o nosso projeto e nos ajuda a dar mais uma previsão sobre quanto tempo esse projeto ainda vai demorar. Todos falam sobre o que fizeram ontem, o que farão hoje e sobre o que está atrapalhando o trabalho. Quando estamos com mais pessoas, como nós que já estamos com 20 pessoas, temos que mudar um pouco a dinamica do standup meeting, mas a essencial é a mesma.

Tenho mais uma coisa para falar, que coloquei no final, que é a parte mais importante do Hashrocker, a nossa empresa, é que nós achamos que a coisa mais importante é se divertir no trabalho. Sem diversão não há produção. Nós fazemos algumas coisas em conjunto para diversão.

E nós bebemos bastante para nos divertir e pulamos na piscina quando todos estão bêbados!