•
Programação em par é uma das práticas mais polêmicas que posso pensar quando falamos em desenvolvimento ágil de software. É difícil explicar para pessoas que vivem fora do mundo ágil como é que 2 pessoas focadas na mesma tarefa conseguem ser muito produtivos, até mais do que quando as duas trabalham em tarefas diferentes. É também difícil fazer qualquer tipo de tutoria ou treinamento para ensinar pessoas à programarem em par, mas para nos ajudar nessas duas frentes, o Luciano Félix e o André Faria escreveram dois artigos muito bons, que certamente serão muito úteis:
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 [...] .
•
O pessoal do InfoQ Brasil traduziu recentemente um artigo muito bom do Mark Levinson, sobre como melhorar retrospectivas (original em inglês aqui). O artigo detalha algumas técnicas e dá várias recomendações sobre como conduzir retrospectivas eficientes e proveitosas – e não correr o risco de fazer uma retrospectiva morosa e monótona.
Esther Derby, co-autora do “Agile Retrospectives: Making Good Teams Great”, escreveu recentemente sobre algumas técnicas para melhorar as retrospectivas:
- 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.
- 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.
- 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.
- 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.
- 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.
•
Recentemente, saiu no site da ScrumAlliance uma dica a respeito da ferramenta criada pela TangyOrange. A ferramenta é simples, e não tem pretensões: a idéia é ser um ScrumBoard para times distribuídos. Sem muitos enfeites, a ferramenta cumpre muito bem o seu papel: ser um ScrumBoard totalmente online. Simples assim! O custo da ferramenta é US$ 5.00 a cada 40 dias (não entendi essa de 40 dias…), um preço bastante justo.
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!