[MÚSICA] Olá a todos! Esse é o curso de Princípios de Desenvolvimento Ágil de Software. Meu nome é Eduardo Guerra e, hoje, no módulo de programação pares, vamos estar falando aqui sobre pareamento com qualidade. Então, como eu falei na outra aula, programação pares não é só sentar junto. Então, vamos ver aí algumas técnicas, algumas coisas que você pode fazer, algumas coisas para você prestar atenção para que você realmente consiga extrair todos os benefícios dessa técnica da programação pares. Então, como eu falei, programação pares é muito mais do que sentar junto. Eu vejo muita gente: " nós vamos começar aqui na empresa a fazer programação pares". Aí, pega, bota uma cadeirinha do lado, né? Bota o cara sentado ali e deu. Obviamente, isso, muitas vezes, não vai dar certo porque programação pares não é só botar o cara ali do lado. O cara vai ficar ali perdido, vai ficar mexendo no celular... Então, da mesma forma que, aí você fala assim: " não. Mas e o cara que tá programando?". Ele também pode ter uma atitude que vai prejudicar. Então, vamos ver aí. Por exemplo, o copiloto, o cara que está ali do lado, a ideia dele é que ele fique atento ao código, que ele preste atenção. Se ele é cara menos experiente, ele procura entender o que está acontecendo, procura dar a contribuição dele. Ele não é cara para ficar passivo. Não é cara pra ficar dormindo ali do lado. Está o cara lá programando e está o outro lá. [SOM] Ou, então, está o cara lá no celular. Não! O copiloto tem que estar atento ao que está acontecendo e buscando oportunidades de contribuir. Por outro lado, o piloto também tem que dar oportunidade do copiloto contribuir. Não é o cara pegar ali o teclado e [SOM] Quase rosna, baba ali cima: [SOM "Meu programa!" [SOM]. E nem olha para o lado. Que liberdade, que tipo de abertura ele está dando para o colega contribuir? Então, da mesma forma, o piloto também não pode abraçar o teclado e querer fazer sozinho enquanto o colega fica ali do lado. Às vezes, mesmo prestando atenção, o cara fica perdido e não consegue ali uma brecha para falar alguma coisa ou, quando fala, o cara ignora, dá patada. Não é assim. Lembra que ali vocês estão trabalhando conjunto. Não é nem para o cara que está trabalhando como copiloto deixar o outro fazer e ficar "passivão", nem para o cara que está programando querer dominar tudo e ignorar o que o outro está falando. Se tivermos dois com esse tipo de atitude, aí pronto. Aí realmente você está jogando recursos fora com esse preprogramming bizarro. Então, o primeiro passo quando uma dupla vai se reunir para fazer alguma coisa é ela pegar e discutir como que vai fazer. Vamos supor: " tem uma funcionalidade que, por exemplo, vai ter que armazenar uma nova informação". Aí, por exemplo, a dupla pode começar já falando: "Olha, onde no banco de dados essa informação vai ficar? Vamos dar uma olhada nas tabelas. Olha, tem essa, tem aqui. Pode criar uma nova tabela. Pode criar uma coluna nessa tabela. Para criar uma tabela nova tem que criar relacionamento. Onde vai estar esse relacionamento? Agora, temos que criar as classes. Como que a gente vai criar? Onde que vai ficar esse método? Que pacote? Que classe?". Então, a ideia da dupla é você, antes de sentar na máquina, ir discutir. Às vezes, você pegar quadro branco e fazer pequeno desenho ou numa folha de papel e tal, mais para orientar vocês, criar checklist para vocês terem entendimento comum de qual é a solução que vocês vão adotar. Uma experiência que eu tenho como professor é que muitas vezes, quando a gente para para explicar uma coisa, aquela ideia amadurece na nossa cabeça. Não sei se já aconteceu com vocês. Às vezes, você chega e começa a explicar uma coisa, uma ideia que você teve, para alguém: "Ô, fulano! Tive uma ideia! Então, se a gente fizer assim, assim, assado." Aí você já fala: "Não, não vai dar certo". Ou seja, o fato de você pegar aquela ideia que na sua cabeça pode até fazer sentido, mas ainda é uma coisa meio abstrata, o fato de você ter que, digamos, serializar aquilo palavras, uma explicação que outra pessoa pode entender, faz com que você amadureça aquela ideia. Às vezes, na hora que você está elaborando isso, você vê uma inconsistência ou, às vezes, na hora que está elaborando, você se questiona ou até mesmo você tem outras ideias, ou você às vezes, percebe que tem algum aspecto ali que, às vezes, não invalida a sua ideia, mas que você não tinha considerado. Então, você explicar uma ideia para alguém faz com que ela amadureça na sua cabeça. " eu acho que aqui a gente podia fazer isso com o loop assim, assado." E aí, você, às vezes, tinha na sua cabeça mais ou menos como ia ser aquilo, mas não tinha elaborado ainda. Na hora que você para para elaborar, para poder explicar para outra pessoa, aquilo se torna muito mais claro para você mesmo. Às vezes, a outra pessoa vai, te questiona, você elabora pouco mais, você explica pouco mais. Então, isso daí vai contribuindo, essa discussão dos dois lados, você tendo que elaborar suas ideias, a pessoa questionando ou dando outras ideias cima, essa troca de experiências faz com que vocês, na hora de sentar no computador para começar a fazer o código, já comecem com uma ideia bem legal do que vocês vão fazer e isso já tenha sido mais ou menos validado pela outra pessoa que está trabalhando com você. Então, explicar alguma coisa para alguém ajuda muito a amadurecer aquelas ideias. Então, assim, se você estiver como piloto, você tem que se preocupar tentar ir narrando pouco. Você não está criando o código sozinho mais, você está criando com alguém. Então, você fala assim: "Estou criando essa variável aqui para guardar contador para o loop. Olha, essa variável aqui vai guardar o nome do usuário". Aí, o cara pode falar assim: "Acho que esse nome aí para mim não ficou claro". Aí, vai lá e arruma. Então, o piloto tem que tentar ir narrando, tem que tentar ir explicando o que ele está fazendo: "Olha, aqui eu estou chamando esse método aqui da lista que faz tal coisa". " tem tal outro método que pode ser melhor por conta disso". Então, a pessoa tem que ir narrando porque, no momento que ele está falando com a outra pessoa, ele dá oportunidade da outra pessoa também estar contribuindo. Por outro lado, o copiloto ele tem que procurar ali, também ele tem que lembrar que o piloto está concentrado, então, não tem que ficar: "Esqueceu uma letra! Esqueceu ponto e vírgula! Esqueceu não sei o quê! Bota pontinho ali! Apaga espaço que ficou ali! Olha, ficou desalinhado!". Não, ele, às vezes, deixa o cara ir pouco mais. Tem que haver nas pausas ou simplesmente na conversa ali, ele vai procurando momentos oportunos ali, onde ele pode questionar, onde ele pode sugerir, onde ele pode dar uma dica. Então, aquilo que o cara botar vermelhinho já pode dar uma olhadinha no que ficou e tal e, na hora que o cara for contar: "Olha, isso aí ou tal coisa ali está errado". Isso seria uma contribuição. Então, tem que ter, tanto da parte do piloto, de tentar narrar o que está acontecendo para dar oportunidade para essa pessoa contribuir, quanto do copiloto, também evitar tirar a concentração do piloto de forma desnecessária e também procurar oportunidades ali onde ele pode tentar contribuir, dando sua opinião e, justamente, saber tudo o que o piloto está falando ajuda bastante nesse sentido. E não é tentar ali e ficar o dia inteiro como piloto e o outro como copiloto. A ideia é que haja uma rotação entre esses pares. Momento, quem era o piloto vira o copiloto. Exemplo clássico: num momento que, por exemplo, o piloto tem pouca experiência numa parte e o copiloto está praticamente narrando para que ele vá digitando o código, está praticamente digitando ali o que ele está fazendo, talvez é uma boa hora do copiloto assumir como piloto e o piloto assumir a posição de copiloto. E é saudável, também, mesmo que isso não aconteça, que eles tenham desempenho suas tarefas, façam essa rotação para que todo mundo tenha a oportunidade de programar, todo mundo tenha a oportunidade de aprender e contribuir de diferentes formas. Essa parte da rotação dos pares é muito importante. Então, espero que essa aula tenha mostrado pouco mais sobre como o pareamento com qualidade não é fácil porque envolve pessoas. Pessoas com diferentes personalidades, com diferentes facilidades e dificuldades, tanto do ponto de vista técnico quanto do ponto de vista social, mas essas atitudes, explicar isso para a equipe é extremamente importante se você quer botar isso na prática e não simplesmente botar essas pessoas sentadas uma do lado da outra e falar: "Te vira aí". Certo? Então, é isso. Continuamos na próxima aula com mais detalhes sobre a programação pares. Muito obrigado! [MÚSICA] [MÚSICA]
