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