O Luciano Félix escreveu em seu blog um excelente artigo com várias dicas, voltadas para o par, para ajudar a melhorar a experiência de ambos enquanto programadores.

Já o André escreveu um artigo explicando o que é programação em par, e como ela pode mudar a sua vida. É um bom recurso também para que você tente convencer aquele seu gerente que continua cético a respeito de pair programming.

Vou fechar com uma citação da Mary Poppendieck, que peguei do artigo do André:

Programação em Par não é para todos, nem para todas as situações, porém, a programação em par cria sinergia: Duas pessoas vão frequentement entregar um código mais integrado, testado e sem defeitos, trabalhando juntas [...]. A Programação em par é uma das melhores formas de se atingir os beneficíos de revisões de código [...] .

Esther Derby, co-autora do “Agile Retrospectives: Making Good Teams Great”, escreveu recentemente sobre algumas técnicas para melhorar as retrospectivas:

1. Deixar os membros da equipe trabalharem - ficar em frente da sala e fazer todo o trabalho de escrever desencoraja os mebros da equipe de tomarem a iniciativa das idéias. Em vez disso faça-os escrevem tudo grandes post-it (usando marcadores escuros) – isso mantém todos envolvidos e encoraja ainda mais as pessoas quietas a participarem.
2. Anotar fielmente – um facilitador (ou ScrumMaster) está aí para capturar idéias do grupo e não filtrar ou injetar sua própria idéia.
3. Usar processamento paralelo – quando houver mais que uma ou duas áreas problemáticas para debater, quebre o grupo em dois ou três e faça uma análise das causas. Além de acelerar as coisas isso reduz a influência de uma ou duas vozes barulhentas na equipe.
4. Deixar os membros da equipe tirarem conclusões – ocasionalmente os facilitadores (ou ScrumMaster) vão olhar para os dados brutos gerados pela equipe e dizer quais são suas conclusões sem permitir que a equipe faça seu próprio trabalho. Na verdade o facilitador está dizendo que não valoriza o feedback da equipe. Apesar de que pode levar algum tempo para que a equipe analise os dados por si só, eles chegam a melhores conclusões e tomam posse dos resultados e das ações a serem executadas.
5. Teste de entendimento – após um curto período de debate é útil testar para ver se a equipe alcançou um entendimento comum (nem sempre na decisão final, algumas vezes apenas em algum ponto no meio do caminho). Uma decisão deve ser proposta e uma vez que todos tenham feito perguntas esclarecedoras, nós testamos isso usando o “Fist of Five“. Com esta técnica o número de dedos indica o grau de apoio: Cinco – eu gostaria que essa idéia fosse minha pois vou ajudar a mudar; Três – eu posso viver com isso. É a vontade da equipe; Um – existem questões que eu preciso discutir; Mão fechada – Ausência de voto, eu quero impedir o consenso e forçar mais discussão.

Para ver o artigo completo, clique aqui.

Introduzir uma nova metodologia de desenvolvimento de software tem seu próprio conjunto de desafios que podem ir de ‘resistência a mudança’ a ‘técnicas de adoção falhas’ resultando então em fracasso. Em uma série de artigos no Agile Journal, Cesário Ramos e Eelco Gravendeel falam sobre os desafios que eles vivenciaram enquanto trabalhavam com Scrum e suas observações, quando introduziram Scrum em várias organizações. Os autores sugerem que o conhecimento desses desafios e uma estratégia para superá-los faria o processo de adoção mais fácil para organizações planejando adotar Scrum.

Veja o artigo completo no InfoQ Brasil.

Esse post foi feito originalmente no InfoQ USA, e traduzido para português pela equipe do InfoQ Brasil.

Vale à pena conferir, para ver o site da ferramenta, clique aqui. Para testar e brincar num demo, clique aqui.

Dica: abra duas máquinas (ou dois browsers) lado a lado e mova um post-it de uma área à outra do quadro para ver a interação. Muito bom!

Tenho certeza que isso vai deixar muito ScrumMaster na vontade de colocar um monitor de 42″ na sala do time!