[Rio-pm] Pair Programming

Domingo Março 11 10:20:50 PDT 2012

Concordo com tudo que foi dito. 
Antes de vir pra Flórida apliquei um curso sobre Agile no PRODERJ. 2 semanas. Palestras pela manhã, com uns 50 a 80 pessoas no auditório, programadores, gerentes, sysops, dbas, etc. E laboratório à tarde, com 20 programadores, os mais experientes. Nas palestras eu apresentava as teorias do Agile, Scrum, Pair Programming etc e os frameworks e ferramentas que seriam utilizados nos projetos em questão. 

Nos laboratórios testamos as teorias e as preferências e realizamos aplicativos reais em produção no PRODERJ, "Hands On". Na verdade os pares já estavam mais ou menos formados. Esta forma de trabalhar em duplas é bem intuitiva, as pessoas se juntam naturalmente por suas compatibilidades.

Mas as técnicas de programar por testes e o revezamento constante não era praticado nem conhecido. Foi uma experiência muito boa para todos e as preferências logo se firmaram. 
Criamos então 4 equipes e realizamos uma competição: qual equipe implementaria um aplicativo simples em menor tempo e com menos erros. 
A competição isolou algumas pessoas, que preferiram não se colocar em prova. Trabalhar em duplas, para alguns é muito difícil, até impossível. E quase todos a princípio consideraram a programação por testes uma bobagem, uma perda de tempo. Só perceberam o valor da coisa no decorrer do curso. A equipe que venceu a competição foi a que aplicou o Pair programming e implementação por testes. 
Entretanto no decorrer do curso ficou claro que esta equipe não conseguia manter o ritmo por muito tempo e logo se cansava, perdia o foco e tal. E os programadores isolados acabavam ajudando mais que os pares em alguns momentos. 

No final do curso estava claro que 2 programadores, mais experientes nos frameworks, se destacavam muito dos outros e ficaram então orientando o resto da equipe que desenvolvia por testes, alguns em pares e outros isolados. Isto foi o que deu certo neste grupo. Foram 2 semanas pra descobrir esta dinâmica. 

Cada equipe, cada grupo tem suas características e pra um trabalho ser bom é preciso entender como as pessoas são e respeitar as individualidades. 
Sem muita receita de bolo. Mas claro que as metodologias são muito importantes pra nortear o projeto, sem radicalismos. Cada trabalho exige uma ferramenta que é a melhor naquele momento.

>________________________________
> De: Blabos de Blebe <blabos em gmail.com>
>Para: Perl Mongers Rio de Janeiro <rio-pm em pm.org> 
>Enviadas: Domingo, 11 de Março de 2012 10:54
>Assunto: Re: [Rio-pm] Pair Programming
> 
>Opa,
>
>Nem 8 nem 80.
>
>Eu acho pair programming um pé no saco quando meu par não tem
>aproximadamente o mesmo nível técnico que eu para aquele problema,
>justamente porque a gente perde mais tempo com um explicando pro outro
>o que está fazendo do que realmente programando.
>
>Programação precisa ser fluida.
>
>Além disso, pra mim é muito incômodo ser interrompido no meio de um raciocínio.
>
>Por outro lado, quando a dupla está sincronizada, pair programming
>funciona muito bem.
>
>Eu tenho a sorte de trabalhar com uma equipe especialmente bem
>qualificada (não temos estagiários ainda), o que facilita em muito meu
>trabalho. Quando quero paz ligo meus fones num nível abafante-seguro e
>fico na minha. Quando preciso de apoio não tenho problema em trabalhar
>em par, porque eu sei que eu não vou precisar explicar o que é aquele
>join de map.
>
>...
>
>Falando de metodologias, eu não estou com o livro aqui, se estivesse
>citaria *AS* páginas do Pressman sobre Engenharia de Software, onde
>ele diz várias vezes que as técnicas e métodos que ele apresenta,
>devem ser sempre *ADAPTADAS*, ao projeto, à organização e *À EQUIPE*.
>
>Ou seja, ele apresenta um conjunto de ferramentas e você deve analisar
>o contexto, escolher as que atendem aos seus requusitos e adaptar. É
>isso que um PM deve ser capaz de fazer, e não simplesmente chegar e
>falar SCRUM, CMMI, MVC.
>
>O problema é que quem ensina Engenharia de Software por aqui, não
>entendeu essa essência e aí quer empurrar metodologias apenas porque
>funcionou na HP e na IBM. Aí pega aquele projeto que não tem nada a
>ver com isso e dá uma de pica-pau: tenta colocar o cubo no buraco
>redondo.
>
>Isso vale pra todas as metodologias de desenvolvimento que eu
>acompanhei. Sabendo que o mundo é dinâmico e as pessoas diferentes, os
>autores (pelo menos os que sabem do que estão falando) das
>metodologias sempre frisam na flexibilidade, adaptação e bom senso.
>
>Outro dia em uma aula sobre métricas de software, estávamos falando
>sobre LOC. Pra mim é muito óbvio que estimar o custo de um software
>por linhas de código é o mesmo que estimar o custo de um prédio pelo
>número de tijolos.
>
>Tem prédio que nem tem tijolo.
>
>A resposta da professora foi que 1) isso é uma *estimativa*; 2) só
>vale para mesmo tipo de projeto; 3) só vale para a mesma equipe; 4) só
>vale se você tiver um bom *histórico*; 5) você, cientista da compuação
>tem que usar o bom senso pra saber se vale ou não.
>
>...
>
>Eu gosto de comparar ciência da computação com Engenharia Civil. Esta
>última tem uns 10 mil anos de idade, tem um puta histórico então é
>razoavelmente fácil estabelecer uma estimativa baseada em exemplos
>anteriores. Qualquer bom pedreiro faz isso direito. Ainda assim tem
>prédio caindo por erros de projeto, de engenheiros.
>
>Um pedreiro sênior tem *domínio* sobre tipos de argamassa e concreto,
>tijolos, técnicas de fundação, técnicas para erguer estruturas,
>paredes, piso, teto, portas, janelas, pintura, acabamento,
>encanamento, sistema elétrico, e mais uma gama enorme de coisas.
>
>Meu tio que só estudou até a 4ª série sabe tudo isso.
>
>Quando eu trabalhei com isso encontrei pessoas que sabiam se o ponto
>da argamassa estava correto ou não, pelo cheiro. Fodinha, não?
>
>E o que sabemos nós? Dominamos uma? duas linguagens? Sabemos fazer um,
>dois diagramas? Otimizar um banco de dados? O quanto sabemos realmente
>sobre *todo* o processo de desenvolvimento de software?
>
>Pessoal, sinto em informar, mas um desenvolvedor sênior, pode ser
>comparado no máximo a um ajudante de pedreiro. Imaginem os não-sênior!
>
>Falta humildade pra entender que nossas técnicas são primitivas,
>nossas abordagens incompletas e que ainda estamos descobrindo como a
>ciência da computação funciona. A engenharia civil passou por isso há
>9900 anos. A gente chega lá!
>
>Enquanto não chega, bom senso e canja de galinha!
>
>[]'s
>
>2012/3/11 Aureliano Guedes <guedes_1000 em hotmail.com>:
>> Frase otima, eun mesmo prefiro fazer a parte de programação em casa, onde eu
>> fico sozinho e meu rendimento é maior.
>>
>> ________________________________
>> From: creaktive em gmail.com
>> Date: Sun, 11 Mar 2012 10:21:21 -0300
>> To: rio-pm em pm.org
>> Subject: Re: [Rio-pm] Pair Programming
>>
>>
>> Não me lembro da fonte, mas considero essa frase perfeita: "nove mães não
>> vão gerar o bebê em um mês".
>>
>> ABS()
>>
>>
>>
>> On Sun, Mar 11, 2012 at 08:58, Thiago Glauco <thiagoglauco em ticursos.net>
>> wrote:
>>
>> Bem, Vamos lá, Breno.
>> Olá pessoal da Rio-pm.
>>
>> Primeiro o artigo usa diversos outros artigos para se basear, que são:
>>
>> "The  rise of new group thinking":
>> http://www.nytimes.com/2012/01/15/opinion/sunday/the-rise-of-the-new-groupthink.html?_r=1
>>
>> Uma palestra de um médico:
>> http://blog.ted.com/2012/02/28/atul-gawande-at-ted2012-2/
>>
>> O que na minha opinião acontece muito com as empresas, além da busca
>> irracional por um lucro absurdo que a faz demitir profissionais
>> qualificados em troca de inexperientes e depois dizer na tv que faltam
>> vagas para TI, é a adoção de técnicas, metodologias e modismos como se
>> fossem os mandamentos bíblicos da salvação empresarial. Eu acho um
>> programador no meu ombro como papagaio de pirata muito ruim e incômodo
>> (vamos frisar o "eu acho" aqui). Eu prefiro que o segundo programador
>> trabalhem em outra parte do sistema e em curtos períodos de tempo nós
>> passamos o código desenvolvido um para o outro e revisamos e discutimos
>> o código um do outro.
>>
>> Por quê? Além do incômodo, pessoas perdem concentração com o tempo vendo
>> outra pessoa digitar. Isso se agrava se um dos pares tem períodos de
>> concentração curtos. Além de fatores individuais e psicológicos que
>> podem atrapalhar, como rivalidades e disputas por promoção ou maior
>> destaque na empresa.
>>
>> Mas isso sou eu, outras pessoas e outras equipes podem prefirir
>> trabalhar de maneiras diferentes.
>>
>>
>> Existem Diversas Metodologis de Desenvolvimento. Porém sempre que uma
>> metodologia nova surge vemos pessoas inexperientes tentando adaptar a
>> empresa ou o time à metodologia, e o contrário que deve ser verdadeiro,
>> devemos adptar a metodologia a empresa ou ao time.
>>
>> Trabalho em equipe é importante e fundamental. Pessoas precisam de
>> reuniões de tempos em tempos, trocas de ideias e bater papo no café, mas
>> a privacidade e a manutenção da individualidade também.
>>
>> Em Dom, 2012-03-11 às 03:33 -0300, breno escreveu:
>>> Pessoal,
>>>
>>> li recentemente um artigo muito interessante chamado "Pair Programming
>>> Considered Harmful?"
>>>
>>> http://techcrunch.com/2012/03/03/pair-programming-considered-harmful/
>>>
>>> O artigo apresenta pesquisas que sugerem que as pessoas são mais
>>> criativas quando desfrutam de privacidade e ausência de interrupções.
>>> Ele chega a discutir que grupos de brainstorming costumam ter menos
>>> idéias do que o mesmo número de pessoas trabalhando sozinha e depois
>>> compartilhando idéias. A questão de escritórios sem baia (open-plan)
>>> também é criticada, por ser uma grande fonte de distração e
>>> interrupções.
>>>
>>> Segundo o autor, insistir em 100% pair programming é um dogma
>>> irracional e extremamente contra-produtivo, e que a melhor solução é
>>> uma combinação dinâmica de trabalho isolado, em par e em grupo,
>>> dependendo do contexto e seguindo o bom senso.
>>>
>>> O que vocês acham?
>>>
>>> []s
>>>
>>> -b
>>> _______________________________________________
>>> Rio-pm mailing list
>>> Rio-pm em pm.org
>>> http://mail.pm.org/mailman/listinfo/rio-pm
>>
>>
>> _______________________________________________
>> Rio-pm mailing list
>> Rio-pm em pm.org
>> http://mail.pm.org/mailman/listinfo/rio-pm
>>
>>
>>
>> _______________________________________________ Rio-pm mailing list
>> Rio-pm em pm.org http://mail.pm.org/mailman/listinfo/rio-pm
>>
>> _______________________________________________
>> Rio-pm mailing list
>> Rio-pm em pm.org
>> http://mail.pm.org/mailman/listinfo/rio-pm
>_______________________________________________
>Rio-pm mailing list
>Rio-pm em pm.org
>http://mail.pm.org/mailman/listinfo/rio-pm
>
>
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/rio-pm/attachments/20120311/85b08840/attachment-0001.html>