[Rio-pm] Pair Programming

Blabos de Blebe blabos em gmail.com
Domingo Março 11 07:54:31 PDT 2012


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


Mais detalhes sobre a lista de discussão Rio-pm