Extreme Programming e Agile Development

Assuntos Gerais
#1

Bem, num tópico que não tinha nada ha ver, acabou caindo neste tema, e resolvi criar um específico para esta discussão - principalmente até para sanar minhas dúvidas a respeito-.

Eu tô lendo esse livro do Kent Beck, mas queria experiências de quem trabalhar com o negócio já. Por exemplo, um par está implementando determinada feature, aí depois de um certo tempo, sai um da dupla, entra outro, e eles continuam implementando a feature? Tipo se o baguio pra implementar for trabalhoso/complicado e levar alguns dias, cada um vai implementar um pouco, é isso?

Isso é o que mais encano.
Como disseram atrás, o que mais me faz pensar é o aspecto humano nisso tudo. Por exemplo se eu tiver cansado ou de saco cheio de fazer algo, eu posso simplesmente largar tudo e ir ouvir uma música, tomar café, passear na internet? Mas como ficaria a questão da dupla nesse caso, e se for no meio da implementação de algo?

#2

Cross-posting…

Eu tô lendo esse livro do Kent Beck, mas queria experiências de quem trabalhar com o negócio já. Por exemplo, um par está implementando determinada feature, aí depois de um certo tempo, sai um da dupla, entra outro, e eles continuam implementando a feature? Tipo se o baguio pra implementar for trabalhoso/complicado e levar alguns dias, cada um vai implementar um pouco, é isso?
[/quote]

A minha experiência é de ficar trocando a cada 3 horas, mais ou menos. Mas eu, por exemplo, não me importaria em ter alguém do meu lado o dia todo (acho até legal, dá segurança e me ajuda a manter o foco).

Sobre o desenvolvimento de um certo requisito do software, isso vai muito de como sua equipe se organiza. O que pode acontecer é: eu estou desenvolvendo algo e o Zé fica comigo durante as primeiras horas. Se eu estiver de saco cheio e estiver na hora de trocar de pares, o Zé vai desenvolver o que ele tiver que fazer e eu vou procurar alguém para ajudar. No dia seguinte ou mais tarde, eu volto a desenvolver o que eu estava fazendo com outra pessoa (ou até mesmo com o Zé, caso o seja possível).

[quote=Rafael Nunes]

Isso é o que mais encano.
Como disseram atrás, o que mais me faz pensar é o aspecto humano nisso tudo. Por exemplo se eu tiver cansado ou de saco cheio de fazer algo, eu posso simplesmente largar tudo e ir ouvir uma música, tomar café, passear na internet? Mas como ficaria a questão da dupla nesse caso, e se for no meio da implementação de algo?[/quote]

Ué? Vira para o camarada do seu lado e fala: “bora tomar café!”.

#3

Ótimo tópico, eu bem que queria tirar umas dúvidas sobre o assunto também. :slight_smile:

Como é feita a distribuição das tarefas entre os pares na hora da troca? Por exemplo, supondo uma situação como a seguinte:

Desenvolvedores: A, B, C, D, E e F.
Tarefas: Alfa, Beta, Gama, Delta, Pi, Omega, Phi, Zeta (preguiça de pensar em mais letras gregas…)

No início do dia:
A e B cuidam de Alfa;
C e D cuidam de Beta;
E e F cuidam de Gama;

Supondo que, na hora da troca de pares, A e B ainda não terminaram Alfa, como ficaria a situação? A e o próximo parceiro dele, digamos D, cuidam de Alfa? B e E? Todos cuidam de uma tarefa diferente? Quando A e B se reunirem de novo, continuam Alfa? Depende do humor e do conhecimento de cada um?

#4

[quote=#@®®¡$]Ótimo tópico, eu bem que queria tirar umas dúvidas sobre o assunto também. :slight_smile:

Como é feita a distribuição das tarefas entre os pares na hora da troca? Por exemplo, supondo uma situação como a seguinte:

Desenvolvedores: A, B, C, D, E e F.
Tarefas: Alfa, Beta, Gama, Delta, Pi, Omega, Phi, Zeta (preguiça de pensar em mais letras gregas…)

No início do dia:
A e B cuidam de Alfa;
C e D cuidam de Beta;
E e F cuidam de Gama;

Supondo que, na hora da troca de pares, A e B ainda não terminaram Alfa, como ficaria a situação? A e o próximo parceiro dele, digamos D, cuidam de Alfa? B e E? Todos cuidam de uma tarefa diferente? Quando A e B se reunirem de novo, continuam Alfa? Depende do humor e do conhecimento de cada um?[/quote]

Na verdade, cada desenvolvedor fica responsável por um conjunto de tarefas (vou usar números). Por exemplo:
Desenvolvedores: A, B, C, D, E, F, G, H
Tarefas: 1, 2, 3, 4, … , 12, 13, 14

Cada desenvolvedor fica responsável por algumas tarefas:
A(1, 2, 3)
B(4)
C(5, 6)
D(7, 8, 9)
E(10)
F(11)
G(12, 13)
H(14)

Quem pegar tarefas mais complicadas e que demandem mais tempo, acaba abraçando um conjunto menor de tarefas a serem feitas. Quando você vai fazer o pareamento, faz-se assim:
[A, B] -> desenvolve tarefa do peer A
[F, C] -> desenvolve tarefa do peer F

E assim por diante.

Mas aí o desenvolvedor A fica de saco cheio das tarefas dele mas ainda quer ajudar alguém, então ele troca:
[G, A] -> desenvolve tarefa do peer G

E é isso.

#5

[quote=Daniel Quirino Oliveira][A, B] -> desenvolve tarefa do peer A
[F, C] -> desenvolve tarefa do peer F
[/quote]

E quando o B e C desenvolvem as suas tarefas? Só deopis que terminarem as tarefas dos pares que estão trabalhando?

E o B vai acabar desenvolvendo a do A -que se encheu e foi trampar com o G- e também as suas próprias -que ainda não havia começado pois estava desenvolvendo a de A-?

#6

[quote=Rafael Nunes][quote=Daniel Quirino Oliveira][A, B] -> desenvolve tarefa do peer A
[F, C] -> desenvolve tarefa do peer F
[/quote]

E quando o B e C desenvolvem as suas tarefas? Só deopis que terminarem as tarefas dos pares que estão trabalhando?
E o B vai acabar desenvolvendo a do A -que se encheu e foi trampar com o G- e também as suas próprias -que ainda não havia começado pois estava desenvolvendo a de A-?[/quote]

Não não. B e C vão desenvolver suas atividades quando eles quiserem/precisarem. E eles vão desenvolver com a ajuda de algum colega. E, quando o par [A, B] for desfeito, cada um vai para o seu lado. Talvez se forme um par [B, H] e outro [C, A], ou [B, C]/[A, E] … e assim por diante.

#7

Na verdade o primeiro par é o responsável pelo cumprimento da atividade.

Não costumo colocar minha equipe full-time trabalhando em PP. Cada um sabe o momento de “ajudar” alguem em uma atividade ou pedir “ajuda” a alguem. Para as atividades bem simples ele pode desenvolver sozinho. As atividades que julga mais complexa e que é bom uma segunda opinião, uma revisão constante e alguem para chorar junto qdo não dá certo, ele chama alguem para ser um par.

#8

Pelo que entendi então no Pair Programming você pode desenvolver o tempo todo com alguém do teu lado pra te auxiliar, como pode também só iniciar o design da coisa com alguém, mas deopis cada um pode levar suas tarefas adiante sozinho, certo?

#9

Isso tudo que vocês estão falando contempla a “troca de papéis” ( :shock: ) entre o cara que digita e o cara que “olha”, ou em geral o primeiro elemento do par é o que digita, sempre?

(Eu lembrava que “o cara que digita” era chamado de “condutor”, mas o outro eu esqueci. :oops: )

#10

No meu caso quem fica na “frente” do computador vai se alternando de acordo com o humor dos pares.

#11

Achei uns links interessante sobre o Pair Programming em específico:

http://c2.com/cgi/wiki?PairProgramming
http://c2.com/cgi/wiki?PairProgrammingQuestions
http://c2.com/cgi/wiki?PairProgrammingBenefits

#12

Olá,

gente desculpa desviar um pouco a discussão, mas que tenho uma dúvida.

O escopo de grandeza de um projeto pode limitar o uso da metodologia ágil, ou seja, ela só é utilizada em projetos pequenos ? com equipe de 10-12 pessoas ? Ou não … ?

#13

Acho que não,

A chrysler usou XP para desenvolver um sistema enorme deles, não sei o tamanho da equipe.

No livro que eu li sobre XP, as tarefas eram atribuídas à dupla e não as pessoas, nao mencionava sobre troca de duplas.

Eu adoraria fazer dupla com alguem que vai me ensinar alguma coisa. Odiaria ter que fazer dupla com alguem de genio incompativel com o meu e;ou que nao me acrescentasse em nada. Como as pessoas sao diferentes umas das outras, isso certamente aconteceria algum dia. E invés de ter 2 programadores, a empresa teria 0,5.

É normal e humano as pessoas não se darem bem juntas. Nao depende de conhecimento nem nada disso, acontece. Quem algum dia nao foi com a cara de uma pessoa sem razao relevante que atire a primeira pedra.

#14

Quanto menor o time, menos pontos de comunicacao existem (lembrando que adicionar uma pessoa a um time de 10 pessoas faz com que os pontos de comunicacao subam de 1010 pra 1111, uma diferenca de 21 pontos).

Da pra fazer projetos com mais gente que isso (e aqui na ThoughtWorks tem times de 30, 40 e ate 100+ pessoas num projeto), mas gerenciar a comunicacao e tarefas requer bem mais cuidado.

#15

Ensinar alguem tambem traz otimas ideias novas sobre como fazer as coisas - por mais que alguem seja inexperiente, pontos de vista diferentes sempre sao uteis.

Por um tempo, sim - depois, se o seu par for uma pessoa de cabeca aberta e aprender rapido, a coisa volta ao normal.

Nao se dar bem nao quer dizer que voces nao vao conseguir trabalhar juntos - e um pouco de tato e paciencia sempre vao bem. Na pior das hipoteses, promiscuous pairing (onde vc troca de par a cada 2, 3 horas) tambem resolve.

#16

Para o pessoal q trabalha com pair programming: existe alguma métrica para avaliar se pair programming está tendo o resultado q deveria ?

[]s

#17

Qual a métrica que você usa para avaliar se uma pessoa trabalhando sozinha está tendo o resultado que deveria?

#18

Trabalho dentro do prazo, sem bugs e a satisfação dos clientes?

Sendo que uma pessoa está no descrito acima, como com duas pessoas será melhor?

#19

[quote=Thiagosc]Trabalho dentro do prazo, sem bugs e a satisfação dos clientes?

Sendo que uma pessoa está no descrito acima, como com duas pessoas será melhor?[/quote]

Supondo que essa pessoa nunca se demita, tenha caganeira, precise levar a avoh na musculacao, renovar a carteira de motorista, faca uma obturacao, quebre o braco, tenha um ataque de flatulencia incontrolavel ou, pior das hipoteses, se vicie em foruns de internet, voce esta certo.

Mas ainda temos um probleminha: quantos projetos vc ve por ai onde tem so uma pessoa programando? Nos que eu costumo participar, o tamanho da equipe varia entre 4 e 40 desenvolvedores. E fazer com que eles se comuniquem direito eh um problema que pair programming resolve bem, especialmente quando o design da aplicacao, ferramentas, requisitos, processos e o projeto em si mudam.

Resumindo, pair programming aumenta significativamente a chance de a sua equipe enfrentar qualquer tipo de adversidade.

#20

Carlos,

você poderia definir melhor como se resolve a comunicação de forma eficiente utilizando Pair Programming em equipes com muitas pessoas ?