código Ágil

Agile, Scrum, Extreme Programming , Java e mais

Archive for janeiro \29\UTC 2009

David Anderson em Recife

Posted by Luciano Félix em 29 janeiro, 2009

Ontem estive presente na palestra do David Anderson, sobre Agile + CMMI promovida pelo CESAR.EDU como parte da programação do Recife Summer School. A palestra foi bem interessante, David falou um pouco sobre o contexto histórico em que o Manifesto Ágil foi criado e a motivação por trás dos seus valores. Mais uma vez foi mostrado que o CMMI e o Movimento Ágil tem os mesmos objetivos, apenas diferem nas aplicações. David continuou a apresentação mostrando essas diferenças, não concordo com tudo que ele disse, mas mesmo assim foi enriquecedor participar da palestra.

Um dos grandes problemas que vejo no adoção de CMMI com Agile, e isso ficou claro na palestra do David, é o grande desconhecimento e preconceito por parte dos avaliadores do CMMI sobre o que é Agile. Encontrar algum auditor que aceite evidências que são comumente usadas pela comunidade ágil ainda é muito difícil, o próprio SEI reconhece o problema e tenta buscar uma solução, mas acredito que esse cenário não vá mudar assim tão rápido.

Além da palestra de ontem, o David vai ministrar o curso Zen of Agile Management, hoje e amanhã, também dentro da programação do Recife Summer School.

Anúncios

Posted in Uncategorized | Leave a Comment »

Certified Scrum Practitioner

Posted by Luciano Félix em 28 janeiro, 2009

Na segunda feira (26/01/2009) recebi uma grande notícia da Scrum Alliance, fui aprovado no processo de seleção de Certified Scrum Practitioner. Um passo importante para alcançar meu objetivo de me tornar um CST.

Queria agradecer aos amigos da Solver Ltda. que me ajudaram implantar o processo na empresa e ao Boris Gloger que tem me ajudado constantemente, permitindo que eu o auxilie nos treinamentos de CSM e claro a minha esposa que aguenta me ouvir falar sobre Scrum o tempo inteiro.

Grande abraço a todos !!

Wuff !!

Posted in Uncategorized | Etiquetado: , | 6 Comments »

Dicas sobre Pair Programming

Posted by Luciano Félix em 21 janeiro, 2009

O Patrick Kua publicou em seu blog algumas dicas interessantes que ele usa quando está trabalhando em pares. Traduzo aqui o texto para vocês.

Entender o estilo de trabalho de cada um

Gosto de entender como a pessoa com quem estou pareando gosta de trabalhar e eu gosto de explicar a maneira como prefiro trabalhar. Entender as preferências de cada um ajuda a não criar conflitos quando o par precisa fazer algo diferente, Alguns gostam de desenhar diagramas, outros gostam de analisar código, etc. Torne as coisas implícitas em explícitas.

Relaxe e conte até 3

Eu digito rápido mas reconheço que preciso ser paciente em relação a coisas como, erros de digitação ou sintaxe quando estou trabalhando com alguém que não digita tão rápido quanto eu. Nada diz mais “Não confio em você” do que ficar constantemente chamando atenção sobre essas coisas quando seu parceiro ainda está traduzindo o design em código. Eu confio no meu parceiro para perceber esses problemas e espero um longo intervalo antes de aponta-los. Quando tenho o impulso de interromper, paro e conto até 3 para dar um espaço ao par. Claro, erros de digitação são chatos, mas são corrigidos facilmente e não são o fim do mundo.

Troque de posições constantemente

Trocar posições frequentemente ajuda a criar um senso de posse coletiva do código, no entanto fazer isso de forma excessiva pode quebrar o fluxo de trabalho. Quando começo a trabalhar em pares tento organizar o tempo de teclado, sugerindo os momentos apropriados para a troca (fim de um teste, fim de uma funcionalidade).

Assegure-se que o par entenda por que está pareando

Pair Programming traz vários benefícios, mas, as vezes, pode ser difícil entender por que estamos trabalhando em pares. Veja se o trabalho em par está trazendo benefícios como, entendimento compartilhado, revisão de código contínua, opções de design, etc. Sem entender porque estamos pareando, muitas pessoas não conseguem atingir os resultados esperados.

Reconhecer que PP não é a solução para tudo

Me incomoda quando ouço, “Preciso de um par para resolver isso”, sem descobrir qual o problema de fato. As vezes problemas são melhor resolvidos pela equipe, ou padrões precisam ser acordados com a equipe, não com apenas um parceiro. Por outro lado, não acredito que todas as tarefas precisam de duas pessoas, coisas como ler uma documentação, ou pesquisar na web a solução de uma dívida. Pode ser difícil perceber quando e quando não trabalhar em pares. Entender o por que pode ajudar.

O navegador deve ver  além da tarefa atual

O valor do navegador é pensar além do que está sendo codificado, o que vem a seguir. Quando estou no papel do navegador penso nas consequências da tarefa atual nas outras partes do sistema, considerando tarefas que podemos ter nos esquecido ou pensando em diferentes cenários de teste que ainda são necessários criar. Também penso se a tarefa que estamos fazendo é realmente válida para o contexto do sistema, se isso nos leva mais próximo do nosso objetivo e se essa é a melhor forma de fazer.

O texto original pode ser lido aqui.

Posted in Uncategorized | 3 Comments »

“Testes são superestimados”

Posted by Luciano Félix em 12 janeiro, 2009

Na semana passada o InfoQ publicou uma apresentação do Luke Francl, especialista em Ruby, sobre como alguns conceitos que temos sobre nossos testes podem estar equivocados.

Luke apresenta idéias bastante interessantes para criar uma estrutura de testes que seja de fato efetiva, vale a pena dar uma olhada.

A apresentação pode ser vista aqui

Posted in Uncategorized | Etiquetado: | Leave a Comment »