XP: Você é um coach?

Todos que me conhecem bem sabe que sou fanático por métodos ágeis, especialmente por Extreme Programming. Evangelizo o XP, dou palestras sobre esse assunto e , principalmente, procuro aplicar da melhor maneira possível essas práticas durante meu dia-dia. O livro que sempre recomendo é o Extreme Programming do Vinícius Teles e, obviamente, a bibliografia do Kent Beck sobre esse assunto.

A teoria, após a leitura desse livro a uns anos atrás, de imediato me ajudou na questão profissional, principalmente nas tomadas de decisões e como montar um esquema de trabalho que funciona para desenvolvimento de software. Porém, só a teoria não é o suficiente para dizer-se conhecedor do assunto. No dia-dia aparecem várias situações adversas e depende da capacidade do time conseguir aplicar esse conhecimento de boas práticas. A leitura de uma bibliografia nos dá informação , mas de nada adianta se ignorado na prática. A informação só se torna conhecimento quando aplicado naturalmente.

Definição de coach retirada do livro Extreme Programming (Vinícius Teles), pag 29:

O coach é o responsável técnico do projeto. O XP recomenda que um profissional tecnicamente bem preparado seja destacado para orientar a equipe de modo que ela siga as boas práticas recomendadas pelo XP. Embora também possa atuar na implementação do sistema, sua tarefa principal é assegurar o bom funcionamento do processo e buscar formas de melhorá-lo continuamente.

Em métodos ágeis o time precisa ser auto-gerenciável e todos precisam estar preocupados com a qualidade do projeto, boas práticas, métricas e cobertura de testes. Todos precisam buscar melhorar o processo de desenvolvimento, pesquisar sobre novas ferramentas de testes, automatizar tarefas, acompanhar e manter a integração contínua do projeto. O coach precisa ter um bom conhecimento técnico para ajudar o time no desenvolvimento e, principalmente direcionar a equipe a cumprir essas práticas importantes. Ele ajuda a manter o foco na qualidade e no processo de desenvolvimento. Busca motivar as pessoas para desempenharem a cada dia o melhor de si.

Quando a interação, ou se preferir sprint, não está caminhando bem, o coach precisa auxiliar o time a identificar o que pode ser melhorado. É preciso identificar esses pontos e definir um plano de ação e indicar responsáveis por melhorar o processo. O time não pode encarar essa divisão de responsabilidade como uma cobrança top-down. O objetivo do coach não é cobrar pois assim o time deixa de ser auto-gerenciável.

Vejo que práticas do XP já são muito bem conhecidas mas as vezes não tão bem compreendidas. Algo que sempre recomendo em toda equipe que trabalho é a programação em par. Já escutei de tudo sobre essa prática e dificilmente vejo que as pessoas entenderam o real benefício disso. Definição do livro:

No XP, os desenvolvedores implementam as funcionalidades em pares, ou seja, diante de cada computador, existem sempre dois desenvolvedores que trabalham junto para produzir o mesmo código. Essa prática, que recebe o nome de programação em par permite que o código seja revisado permanentemente, enquanto é construído. Também contribui para que a implementação seja mais simples e eficaz, já que os desenvolvedores se complementam e tem mais oportunidade de gerar soluções inovadoras.

Tanto para tarefas simples como para mais complexas, se exige desenvolvimento, o trabalho sai melhor se feito por duas pessoas. Problemas de design são melhor identificados se o desenvolvimento é em par. A revisão de código é feita no ato evitando bugs mais obscuros. O foco na tarefa é maior tendo em vista que a “internet” pode desviar a atenção. Conhecimentos técnicos e de negócio são compartilhados entre a dupla a todo momento.

Eu particularmente gosto muito de parear, pois sempre aprendo coisas novas com outra pessoa. Nessa prática procuro sempre passar todo meu conhecimento para quem parea comigo. Gosto sempre de trocar duplas justamente para que a equipe evolua integralmente. Parear com devs de backend, interface, testadores, independente da especialidade.

Considerando a importância de parear, mesmo  dentro de uma equipe entrosada e experiente, vejo ser imprescindível parear com pessoas novas na equipe mesmo já tendo um bom conhecimento técnico. Conhecimentos de negócio vem com o andamento do projeto e a aceleração de aprendizagem é muito maior quando realizado o pair. Se por algum motivo o código não foi desenvolvido em pair, é necessário que haja a revisão do código entregue, preferencialmente por outra pessoa que não o autor.

O XP procura transmitir idéias através de metáforas. “Se você está mudando de casa, prefere carregar o sofá sozinho ou carrega em dois?” Apenas para concluir essa questão, pair programming não é só quando um desenvolvedor precisa de ajuda, é para realizar o trabalho mais bem feito. :)

Outra questão bastante polêmica é a integração contínua. Regra básica: Nunca PUSH sem BUILD. Ou seja, não integre seu código se for quebrar o build. E se quebrar, o foco é totalmente em arrumar o build e não continuar comitando ou fazendo novas features. Quando o build está quebrado os outros desenvolvedores perdem toda a confiança em fazer alterações no código. Outros vão querer descobrir porque quebrou o build e todo o time é prejudicado com isso. Em algumas equipes na Gonow, se um código quebra o build ou não tem cobertura de testes, o commit é desfeito até que haja cobertura ou que o build seja arrumado. Eu sou totalmente a favor dessa prática pois obriga que o time tenha a cultura de não descuidar da qualidade do projeto.

É normal em um time ocorrer argumentações sobre design como nomes de attributos, métodos, responsabilidades de modelos. Discussões sobre o design são sempre sadias pois visam melhorar a qualidade final. O XP fala de simplicidade e coragem. Simplicidade para fazer apenas o necessário para satisfazer o que vai trazer Valor para o cliente. Coragem entre outros para fazer refatorações sem medo de quebrar regras importantes no sistema. Recomendo fortemente a leitura dos livros Refactoring do Martin Fowler e o Código Limpo de Bob Martin.

O importante em equipes é que aconteça a inspeção e adaptação no processo em busca da melhoria contínua. Todas essas práticas do XP tem o objetivo de atingir os seguintes Valores:

Feedback, Comunicação, Coragem, Simplicidade e Respeito

A reflexão que quero deixar sobre o tema desse post é: O que um lider técnico precisa para se tornar um coach? O que você faz no dia-dia para conseguir direcionar sua equipe a obter o sucesso?

Publicado em design, metodologia. Tags: , . 5 Comments »

O Evento Ruby on Rails no Mundo Real

O Evento Ruby on Rails no Mundo Real (http://www.temporealeventos.com.br/?area=130), organizado pelo Guru-SP, ocorreu nesse sábado dia 29/05. Essa foi a segunda edição do evento inspirado pelo sucesso do primeiro em 2009. Foram mais de 200 pessoas no evento interessadas em Ruby, fazer contatos e reencontrar amigos.

É sempre interessante citar que o Guru-SP começou em um primeiro encontro de 3 pessoas (Pothix, Marcelo Castellani e Hugo Borges) e hoje encontros menores ocorrem mensalmente reunindo em torno de 50 pessoas.

Não faltou elogios para as palestras e os comentários estão no twitter com as hashtags #rubyreal2010 e #horaextra

Após o termino dos sorteios e encerramento, é hora do já consagrado #horaextra. A galera se reuniu no O’ Malleys não demorou para aparecer
uma bandeja de pint de Guinness. Até código rolou no bar quando encontramos Tomas D’Stefano comentando sobre seu projeto Morpheus
(http://github.com/tomas-stefano/morpheus)

Alguns slides já foram disponibilizados:

Cassio Marques:
http://www.slideshare.net/cassiomarques/refatorao-design-patterns-em-ruby
Marcelo Castellani:
http://www.slideshare.net/mfcastellani/aplicacoes-para-celular-com-ruby

Hugo Barauna:

http://www.slideshare.net/hugobarauna/o-que-h-de-novo-no-rails-3

Douglas Campos e Thiago Scalone:

http://www.slideshare.net/qmx/batch-escalando-um-sistema-sem-fermento

Todo evento foi filmado e Hugo Borges (http://twitter.com/agaelebe) disponibiizará os vídeos no blip.tv

Fotos estão disponíveis aqui:
http://picasaweb.google.com/gurusp.org/Rubyreal2010#

Dev In Sampa – Retrospectiva

Esse final de semana estive no evento Dev In Sampa e gostei muito das palestras. Principalmente o fato de rever amigos e trocar informações com o pessoal da comunidade.

O @josevalim fez uma apresentação muito interessante sobre classificação de textos.

O @rodrigoy deu uma boa aula de design de software e técnicas importantes de desenvolvimento de software. E ressaltou que técnicas de agilidade como TDD , BDD e CI são esquecidas por muitas equipes.

@rferraz mostrou ter muitos conhecimentos em linguagens de programação e explicou como criar sua própria linguagem.

João Bueno fez uma palestra de jogos em Python e mostrou alguns demos e bastante código.

@lfcipriani fez a apresentação de uma aplicação em tempo Real que usa Ruby e XMPP para marcar pontuação de jogos de Basquete.

@fnando mostrou como testar com Jspec, um “rspec way” para javascript.

O @guilhermecaelum e @adrianoalmeida7 falaram da importância de conhecer bem o protocolo HTTP e seus verbos.

O Radamés fez uma ótima apresentação com sobre Arduino, e mesmo com os problemas nos slides mostrou muito bom humor e improviso. Ele fez a galera rir bastante.

E para finalizar o @fabiokung fez mais uma ótima apresentação sobre Cloud Computing, mostrando uns vídeos bem ingraçados de pessoas metralhando servidores porque agora a solução é Cloud!

Minha palestra foi sobre “Buscas poderosas com Solr”. Os slides estão disponíveis aqui:

Para mais informações sobre o acts_as_solr_reloaded vejam esse post aqui e esse do Diego Carrion.

Quero agradeçer mais uma vez o pessoal da Abril, a Gonow, o Diego Carrion e o Renato Elias por fornecer algunas informações do case deles no Apontador.

Outros posts sobre o assunto:

http://blog.plataformatec.com.br/2009/11/classificacao-de-textos-no-dev-in-sampa-2009/

http://www.rubyinside.com.br/cobertura-do-dev-in-sampa-2009-2536

Vídeos estão disponíveis aqui:

http://agaelebe.blip.tv/

Fotos do Evento:

http://www.flickr.com/photos/devinsampa

Dev in Sampa


Dia 28 de setembro estarei palestrando no Dev in Sampa e vou falar de buscas com Solr em Ruby on Rails. As palestras estão bem legais e o evento custará 35 reais. São apenas 100 vagas, então assim que abrir a inscrição corram para confirmar presença.

Slides da palestra na Fatec

Estou disponibilizando os slides que eu e o Rafael Rosa Fu (twitter @rafaelrosafu) usamos nas palestras que fizemos na Fatec. Interessante é que assuntos como TDD, Testes Automatizados, Métodos Ágeis e outras coisas importantes do mercado ainda não estão sendo difundidos da maneira adequada para os que estão entrando na área. Quero agradecer a Gonow pela oportunidade de me apresentar nas Fatecs de São Paulo, Mogi das Cruzes e Ourinhos.

Os Slides estão no SlideShare

Publicado em eventos. 2 Comments »

Palestra na Fatec-SP

Hoje eu e o Rafael Rosa (@rafaelrosafu) estaremos palestrando na Fatec sobre Ruby On Rails e Agilidade. Será uma introdução à linguagem Ruby e o Ruby on Rails. Também falaremos de nossas experiências com a tecnologia aqui na Gonow. Mais tarde disponibilizaremos o vídeo da palestra para quem não puder comparecer. Acompanhem o InfoQ Brasil e o Ruby Inside Brail para
mais informações.

Mais informações estão na página da Gonow.

Retrospectiva

A Retrospectiva é muito importante em equipes ágeis porque proporciona uma reflexão sobre o sprint, com o intuito de inspecionar e adaptar em futuras iterações. É um momento de aprendizado pois são expostas as coisas boas e o que pode ser melhorado num futuro próximo.


Parece ser fácil fazer uma retrospectiva, mas para que ela seja objetiva é necessário que o dia-dia seja muito envolvido nesse processo. Na retrospectiva normalmente nos lembramos apenas do que foi bastante ruim e esquecemos de falar de coisas boas, que quando ditas podem ser um forte ponto motivacional para o time. A mente humana é muito seletiva e esquecemos facilmente o que aconteceu durante a semana, a não ser o que foi realmente marcante. Por isso existe uma técnica que ajuda na retrospectiva que é usar post-its coloridos em cada acontecimento diário. O fato de usar post-its vermelhos quando acontece algo ruim do sprint, amarelos quanto surgem idéias e verde quando acontece algo bom, causa um efeito visual em nossa mente e a equipe trabalha mais proativamente. Esses post-its diários ajudam bastante pois são discutidos na retrospectiva e não perdemos tempo tentando lembrar o que aconteceu na semana.


Importante! A retrospectiva não é o momento de se achar os culpados, e sim uma solução para o que pode ser melhorado. Portanto não se deve falar nomes nessa reunião, porém um elogio é sempre bem vindo!


De nada adianta a retrospectiva se não for documentada e não houver um plano de ação após essa reunião. Após a retrospectiva, são definidos os responsáveis pelos itens que precisam ser melhorados e como será o plano de ação. A documentação pode ser uma simples foto do quadro de discussão e que fique de fácil acesso a todo o time. Isso é importante para que se tenha uma Linha do Tempo de todas retrospectivas do time para acompanhamento do progresso.


Escrevi outro artigo sobre isso no link:

http://manifestonaweb.wordpress.com/2009/03/20/qcon-london-2009-retrospectivas/

Publicado em metodologia. 3 Comments »
Seguir

Obtenha todo post novo entregue na sua caixa de entrada.