[MÚSICA] [MÚSICA] Olá a todos. Meu nome é Eduardo Guerra e estamos aqui no curso de Princípios de Desenvolvimento Ágil de Software, falando mais uma vez sobre Pair Programming para vocês e hoje vamos falar aí sobre umas questões sobre a programação pares. Eu sei que a programação pares é uma técnica, digamos assim, tanto polêmica pela questão da produtividade, a dinâmica de trabalho, das pessoas e tal. Tira, digamos assim, as pessoas da zona de conforto. Então hoje aqui nessa aula vou falar para vocês pouco mais sobre algumas das questões aí para que você consiga implantar com sucesso a programação pares na sua equipe. Então, vamos ter esse nosso amigo aqui fazendo umas perguntinhas, que eu sei que são perguntas que muitos de vocês talvez tenham, ou mesmo que vocês não tenham essas perguntas, se você quiser implantar programação pares, muito provavelmente algumas delas provavelmente você vai escutar de pessoas que têm uma certa resistência. A primeira questão é relação à privacidade. Ora poh, mas eu vou estar sempre com cara ali do meu lado? Será que eu não vou perder a minha privacidade, não? Como é que eu vou ver minhas mensagens? Como é que vou checar meu e-mails? Tem cara olhando ali do meu lado. Então, assim, uma das vantagens da programação pares é justamente a questão do foco. De você não perder o foco enquanto você está programando. Obviamente que essa atividade não precisa ser 100% do tempo. Você pode ter os momentos de que são das tarefas de desenvolvimento, onde alí os desenvolvedores estão 100% focados e você pode ter momentos onde as pessoas vão fazer outras coisas. O que eu já vi acontecer, por exemplo, ter ambiente onde a programação pares aconteça e ter, por exemplo, algumas baias individuais, ou compartilhadas ou individuais, onde os desenvolvedores podem estar indo para checar os seus e-mails, responder, a trabalhar cima das suas mensagens pessoais. Então, essa opção é de prover esse ambiente mais individual separado do ambiente onde acontece a programação pares, ajuda você inclusive a planejar, a ter uma noção de quanto tempo que a sua equipe efetivamente gasta com as tarefas do projeto e quanto tempo ela efetivamente gasta, às vezes, com as tarefas secundárias. Não estou dizendo que está fazendo coisas que não é do trabalho mas, às vezes, responder e-mail, resolver uma questão de RH e etc., que também a gente sabe que faz parte. Uma outra questão relação à privacidade é que assim, a gente não pode esquecer que a gente não está mais só no nosso canto. A gente está agora junto com outra pessoa, então, não podemos esquecer questões de educação, comunicação, então vou falar que o cara errou alguma coisa, eu acho que ali o nome da variável que você está querendo acessar é outra. Eu não vou falar, seu idiota, está errada a variável. Eu não vou falar assim. Com certeza isso aí não vai ser saudável. Da mesma forma eu tenho que cuidar da minha higiene, tenho que escovar os dentes, passar o desodorante, porque poxa, aquilo ali vai causar, se eu não tiver ali a higiene, eu vou causar desconforto na pessoa que está do meu lado, então, tudo isso passa a ser importante, as pessoas observarem a questão da comunicação, da educação, da higiene, para que, digamos assim, o invadir o espaço físico da outra pessoa, de estar próximo ali, programando junto, não seja desagradável para as pessoas. Outra coisa, poxa, mas será que eu tenho que palear sempre com a mesma pessoa? Esse cara aí poh, todo o dia esse cara do meu lado? Será que não dá para trocar pouquinho? Então, a pergunta é essa. Os pares devem trocar? Devem ser sempre os mesmo? Então, a resposta é, os pares têm que trocar, devem trocar. É muito saudável que haja essa rotação para que não crie vícios, que todo o mundo trabalhe junto com todo o mundo diferentes tipos de tarefas. Isso vai facilitar aí que o conhecimento transite livremente dentro da sua equipe. Outra coisa importante disso é não gerar ilhas de conhecimento. O que acontece? Às vezes, vamos supor, você tem uma equipe de dez desenvolvedores, aí vai ficar só três ali alternando nos pares para trabalhar numa determinada parte do sistema. Isso aí vai criar uma ilha de conhecimento e vai chegar ponto que só aqueles caras que vão conseguir trabalhar naquela parte do código. Enquanto se, de repente, eu manter esses três caras sempre envolvidos com aquela parte mas, rotacionar o resto da equipe, eu já vou estar fazendo com que aquele conhecimento flua mais para outras pessoas fora daquela ilhazinha, Outra coisa, essa é a questão chave. Será que com a programação pares eu não estou perdendo produtividade? Meus desenvolvedores não estão produzindo menos porque eu tenho dois trabalhando uma tarefa só? Então, isso daí é mito. É o nosso amigo aqui, é o Saci Perere aí igual isso aí. Isso é grande mito. Se você fizer a programação pares certinha, a gente já viu, a questão é a seguinte, se você pega os estudos, os experimentos que foram feitos a respeito da programação pares, você vai ver que se você testar isso numa tarefa só, realmente o tempo, se você dividir ali pelo tempo de duas pessoas, realmente você perde pouco, mas isso num curto prazo porque o ganho que você vai ter qualidade, o ganho que você vai ter garantir aquela disciplina, os testes, o ganho que você vai ter reduzir a quantidade de bugs, isso aí lá na frente vai fazer uma grande diferença. O ganho que você vai ter ter o conhecimento mais uniforme, tendo essa troca de conhecimento, você vai de repente, prevenir que o cara não fique agarrado porque está trabalhando com uma coisa que ele nunca fez, ou que determinado recurso, ele vire gargalo porque só ele é que sabe mexer numa determinada parte do sistema que está demandando muita coisa agora. Então, assim, a verdade é que se você for pensar só no agora, você realemente vai perder pouco. Mas se você pensar no médio, longo prazo, essas vantagens da programação pares, elas vão compensar essa pequena perda imediata que você tem. E aí o que eu posso te falar, tem vários artigos. Programação pares é uma técnica bastante explorada pela comunidade acadêmica na área de engenharia de software. Existem vários estudos que mostram tarefas mais longas, tarefas mais simples, tarefas mais curtas, mais complexas, pareamento entre diferentes tipos de pessoa, diferentes personalidades. A grande maioria desses estudos tem essa conclusão de que é uma técnica que vale a pena. Como toda a técnica, ela não é perfeita, ela tem alguns pontos que realmente tem essa perda inicial de produtividade. Talvez para algumas pessoas tarefas mais simples não valha tanto a pena, vale mais a pena quando é uma tarefa mais complicada. Mas, geral, as pesquisas mostram que é uma técnica que vale a pena, que o seu balanço é que vale a pena ser utilizada, vale a pena utilizar o Pair Programming. E aí okay, se eu conseguir convencer você que Pair Programming é uma técnica que vale a pena, como é que você introduz isso na equipe? Okay, me convenceu. Como é que eu coloco esse negócio para funcionar? Bom, a sugestão que eu te dou, principalmente se você é desenvolvedor e está ali na parte mais baixa da equipe, é você tem que de uma certa forma convencer a gerência de que isso aí vale a pena e isso aí causa muitas controvérsias. O que você pode fazer, de repente, pega projeto pequeno, mais restrito que, de repente, não tenha muito risco e, fala assim, vamos pegar esse pedacinho, esse projetinho aqui e vamos fazer piloto, vamos experimentar a programação pares e aí você vê como que isso aí vai funcionar dentro da sua empresa. Obviamente tenta medir os resultados, tenta mostrar, tenta mostrar a questão da produtividade, a questão da quantidade de defeito. O pessoal lá de cima quer ver números. Então, você tem que de alguma forma quantificar esses resultados para mostrar que aquele piloto pode ser usado como exemplo de que aquilo ali vale a pena ser utilizado. Outro fator importante na implantação da programação pares é que algumas pessoas são realmente tímidas. E, às vezes, por exemplo, ela está como copiloto, às vezes, vai até prestar atenção mas vai ficar pouco sem graça. Ou na hora de estar ficar programando vai ficar pouquinho sem graça de ficar falando. Então, nisso daí cabe pouco de conhecimento da sua equipe de sensibilidade, de você ter alguns desenvolvedores mais experientes do seu lado para te ajudar nessa implantação. Então, poxa, vamos pegar aquele cara que talvez é pouco mais extrovertido, que entende pouco mais, vamos colocar ele com aquele cara tímido para que ele puxe o cara para dentro da dupla. E aí, o quê que você acha? O que você está pensando? Ou deixa o cara programar, e pergunta, e aí, me descreve o quê que você está fazendo, porquê que você criou aquilo? E aí a pessoa vai entendendo e aos pouquinhos vai-se soltando e vai-se sentindo mais à vontade. Então assim, não é fácil, não vou dizer, mas é esforço que pode valer bastante a pena de você ter na sua equipe. Eu espero que com essa aula eu tenha conseguido esclarecer alguma dessas questões que são comuns, alguma dessas dúvidas comuns relação à programação pares. E na próxima aula a gente vai falar sobre algumas variações que a gente tem aí dessa técnica. Certo? Muito obrigado! Espero vocês lá. [MÚSICA] [MÚSICA]
