Pair Programming – como você pratica? #xp #programming

Daniel Wildt escreveu um texto legal e compartilho-o abaixo.

——– Mensagem original ——–

Assunto: Re: [XP-RS] Pair Programming – como vocâ pratica?
Data: Sun, 8 Nov 2009 11:58:48 -0200
De: Daniel Wildt <[email protected]>
Para: [email protected]

 

Minha visão é que peer review é um processo reativo.

Calma.

Mais, que o trabalho em par consegue ser um processo preventivo
(quality built in).

Mas…

Para isto ocorrer, o trabalho deve ser multidisciplinar ou com pessoas
que conseguem criticar o trabalho do outro.

Se as pessoas pareando tem muita diferença técnica ou de visão de
negócio, o trabalho em par se torna preventivo no sentido de trabalhar
na transferência de conhecimento do time, estimulando a posse coletiva
do código ou do artefato sendo trabalhado naquele momento.

Você consegue prevenção fazendo:

A) 100% pair programming (considerando o que comentei antes)
B) Pareamento no início de algum ciclo para determinar o que vai ser
construído e como vai ser testado.
C) uso de ferramentas de auditoria de código para guiar boas práticas,
na visão do time.
D) trabalhar em ciclos de desenvolvimento em par, para estimular
transferência de conhecimento.

A questão de fazer pair programming para fazer um crud… Se é uma
tarefa simples e repetitiva, vamos automatizar então. :-)

Em tarefas simples, parear no início para confirmar o caminho + peer
review no final resolve o problema.

Das opções acima tenho sido a favor da B, C e D.

Na FDD existe o design inspection e code inspection. O design
inspection é em parte a (B), porque alguém fez o design e será
inspecionado. Se busca a inspeção para evitar débito técnico e falhas.

Assim, cada metodologia tem seu modelo, e eles servem como opções para
os problemas que os times vivem no dia a dia. Getting real vai sugerir
que não se precisa de um backlog, FDD vai sugerir que refactoring é
design mal feito, lean vai sugerir que iteração é uma disfunção, que o
fluxo deve ser contínuo.

Mas…

Cabe a pessoa que está acompanhando o time trazer estas opções e
ajudar na melhoria.
Conforme o contexto.

Em 2004 falava que eu indicava XP e escrevia use cases (user story) +
cenários (critérios de aceitação) para usar use case points para dar
uma estimativa inicial de algo a ser construído. Participava de um
grupo que estudava a iso 12207 e queria sugerir um processo de
contratação de fornecedores de software.

Como eu falava que era XP, para quem usava XP, era muitas vezes criticado.

Se eu falasse que era Crystal Clear, estaria tranquilo. :-)

De novo, são opçöes.

O importante é dar e receber feedback continuamente, construir com
qualidade, entregar valor ao final de cada ciclo (valor na visão do
cliente), e melhorar continuamente.

Acho que os princípios do manifesto ágil dão conta de lembrar estes
pontos importantes.
http://www.agilemanifesto.org/principles.html

Em 07/11/09, Julio Viegas<[email protected]> escreveu:
> Luiz,
>
> Eu continuo com a mesma opiniao. As vezes eh mais interessante deixar um
> desenvolvedor realizar determinada atividade sozinho do que adicionar a ele
> um “papagaio de pirata”. Isso eh chamado “alone time” no livro “getting
> real”, se o proposito aqui eh citar livros como se fossem a biblia. Nao
> existe uma unica pratica que dita a verdade. Cada time possui uma realidade,
> e vc deve usar as praticas conforme a necessidade.
>
> Em times de alta performance, por exemplo, muitos iriam rir de coisas
> como testing-all-the-fucking-time(que eh imposto por um dos caras
> agile-rails-im-so-cool), ou mesmo PP ou PR(que a proposito sao coisas
> distintas) o tempo todo. Tem sentido PP para fazer CRUD? Isso eh como ter
> que mandar duas pessoas sempre para, sei lah, trocar o galao de agua da
> cozinha…
>
> Eu vejo um problema com parte da comunidade agile, onde se vc emite uma
> opniao que consegue funcionar melhor quebrando um dos ditos mandamentos,
> entao vc eh uma aberracao. Eu vi isso acontecendo contra um ex-colega meu ha
> pouco, onde um artigo que ele escreveu possuia alguns pontos validos e
> varios outros nao mas, ei, nao tinha citacoes ao Martin Fowler, entao algo
> estava errado. Nos precisamos exterminar esse cara, quem eh ele, quais sao
> seus seguidores no twitter? :)
>
> Eu conheco grandes desenvolvedores que normalmente seriam coaching na
> maioria das situacoes, ou mesmo que gostam de fazer sozinho e funcionam
> melhor dessa forma, e realmente eh isso! Qual o problema? Se eles precisarem
> de ajuda eles irao pedir e chegar na pessoa certa para isso. E vai funcionar
> muito bem pois o historico dessa pessoa demonstra isso.
>
> Eu tb discordo que haja distincao entre atividades de producao e nao em
> uma empresa. Tudo que se constroi na sua empresa tem a finalidade de ir a
> producao ou estah relacionado a isso de alguma forma. Principalmente se for
> algo relacionado a arquitetura, ha um impacto em grande parte do sistema. Eu
> separo as coisas em mais ou menos criticas e mais ou menos prioritarias. E
> as mais criticas devem ser definidas por mais de uma cabeca.
>
> PP tem valor quando os membros possuem skills diferenciados. Se um membro
> tem mais skill que outro na mesma area, isso eh coaching.
>
> 100% do tempo? Acho que vc tem problemas com sua equipe ou estah jogando
> for a horas de desenvolvimento. De qq forma, eh um problema gerencial(o que
> nao eh surpresa) pq bons times normalmente possuem um gerente eleito(ou com
> moral) pelo time e que nao herdou um feudo, com as devidas competencias para
> identificar e corrigir essas falhas.
>
> Abs,
> JV — http://julioviegas.com
>
> On 7 Nov 2009 17:21, “Luiz Esmiralha” <[email protected]> wrote:
>
>
>
> Julio,
>
> A motivação de pair programming full-time é bem clara na 1a edição do
> XP Explained: se peer review é uma boa prática, por que não fazer peer
> review 100% do tempo?
>
> Além disso, pair programming apóia a prática de Propriedade Coletiva
&g
t; do Código, já que todo
> o código é escrito por pelo menos duas pessoas da equipe.
>
> A recomendação de Kent Beck é que todo *código de produção* seja
> escrito por um par. Spikes arquiteturais, protótipos, provas de
> conceito, testes de aceitação e qualquer outro código que não faça
> parte do produto em si podem ser escritos por um deenvolvedor “solo”.
>
> As práticas de XP são sinérgicas, ou seja apóiam-se umas nas outras.
> Remover ou reduzir drasticamente uma prática é algo que deve ser
> conduzido por alguém experiente em XP. A recomendação geral se você
> está iniciando em XP e não tem um coach experiente é implementar todas
> as práticas “by the book” e ganhar experiência para depois mexer em
> algo.
>
> Abraço,
> Luiz Esmiralha
>
> 2009/11/6 Julio Viegas <[email protected] <julioviegas%40gmail.com>>:
>> Pair programming pode e deve ser utilizado quando um desenvolvedor possui
>> alguma dificuldade de entregar sua atividade.
>>
>> Segue um ditado antigo: duas cabecas pensam melhor que uma.
>>
>> Se um desenvolvedor sozinho consegue fazer a atividade dentro do prazo e
> com
>> certa qualidade, nao ha necessidade de PP. Normalmente PP eh composto de
> um
>> desenvolvedor mais experiente e outro menos experiente. Ou, em outros
> caso,
>> dois desenvolvedores de modulos distintos desenvolvendo algum tipo de
>> integracao. Precisa haver uma motivacao para fazer pair/group programming,
>> entende?
>
>> > Abs, > JV — http://julioviegas.com >
>
>> On 6 Nov 2009 10:02, “Rafael Fuchs” <[email protected]> wrote: > > > >
> Pessoal > > Vejo que um…
>> [email protected] <rafaelfuchs%40gmail.com> <rafaelfuchs%40gmail.com>
>
>> +55 51 9993-8953 > http://www.linkedin.com/in/rafaelfuchs > > [Non-text
> portions of this message …
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ————————————
>

 

__,_._,___

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *