Programação em pares com Scrum

Estou em uma equipe que atualmente usa o Scrum e estamos pensando em adicionar programação de pares para ajudar a melhorar as habilidades interfuncionais da equipe, além de ajudar a reduzir defeitos com uma filosofia de "duas cabeças são melhores que uma".

Em nossa equipe, cada membro da equipe normalmente se inscreve para uma carga de trabalho completa durante o planejamento do sprint (com "full" sendo um número inferior a 40 horas por semana, permitindo reuniões, colaboração etc.), com um único proprietário dedicado para cada tarefa. Acredito que isso seja bastante comum nas equipes do Scrum, mas pode não ser necessariamente pelo livro.

Em particular, estou procurando evitar uma situação em que os membros da equipe hesitem em fazer o par porque têm suas próprias tarefas para trabalhar, o que, provavelmente, acontecerá se a equipe simplesmente se auto-organizar sem tempo reservado para o emparelhamento. .

Dado isso, qual é a melhor maneira de explicar os esforços / horas / histórias em um cenário de emparelhamento, para garantir que tenhamos tempo alocado adequadamente para o emparelhamento?

Algumas opções consideradas são:

1. Permita que duas pessoas se inscrevam para cada tarefa e (aproximadamente) duplique o número estimado de horas
2. Somente o membro da equipe "hands on keyboard" se inscreve em cada tarefa, estimada com base nas horas estimadas dessa pessoa. Qualquer pessoa da equipe que apoiará o emparelhamento se inscreverá em menos tarefas no sprint para permitir tempo para dar suporte ao emparelhamento.

A opção mais comum que eu vi quando a programação de pares é empregada no scrum é dobrar as estimativas de desenvolvimento.

Ou seja, se estima-se que a tarefa leve 3 horas para uma pessoa, o tempo alocado será de 6 horas para o par.

Substitua horas por pontos, se isso faz você se sentir mais limpo;)

Acho que outras pessoas já deram boas respostas, mas adicionarei as minhas apenas porque acho que sua equipe acabou de fazer a transição para o Scrum e agora vocês estão em uma posição muito semelhante à que estávamos quando começamos.

Primeiro, nossa introdução ao Agile e, mais especificamente, ao Scrum não foi muito fácil. Basicamente, a gerência desceu e disse: a partir de hoje você fará o Scrum e este é um processo que todos seguirão. Tanta coisa para Pessoas acima do Processo .

O processo que seguimos originalmente (cegamente, devo acrescentar) acabou muito parecido com o que você descreveu. As pessoas recebem tarefas atribuídas, todos são contratados e todos voltamos para nossas mesas e nos desligamos. Então temos uma reunião de stand-up chata todos os dias.

A chave para perceber é que o Agile, e o Scrum incluído, são realmente pessoas. Quando a equipe entrar no planejamento da iteração, não deixe seu Scrum master (que provavelmente é seu gerente) atribuir horas, histórias e tarefas. É completamente ATÉ A EQUIPE. Eu acho que, para muitas pessoas, esse é um conceito muito difícil de superar, porque, anos antes, eles vinham trabalhar e tinham um chefe (gerente, líder técnico ...) que simplesmente designava trabalho. Eles mergulham no Scrum, mas todos (incluindo o próprio Scrum Master) continuam operando no mesmo modo.

Um dia, você ficará cansado disso, então começará a ler livros, blogs e continuará fazendo perguntas como essa na troca de pilhas. A percepção de que você obterá é que você, como desenvolvedor e seus colegas de equipe, deve ser a força motriz por trás do comprometimento com histórias e atribuição de tarefas. Se vocês sentirem que se beneficiarão da programação em pares, crie 2 tarefas para cada um dos engenheiros e atribua as duas horas. A única coisa que o scrum master deve fazer é medir a velocidade em relação às histórias concluídas que você entregou como equipe na iteração anterior.

Outra coisa que me incomoda é como as pessoas dizem que sua capacidade SEMPRE é de 75% do total de horas, então é com isso que elas se comprometem e, durante toda a duração da iteração, reclamam que a) elas não podem ajudá-lo ou b) eles não podem fazer a coisa certa porque receberam muitas horas. As pessoas não devem saber quantas horas cometer e certamente devem recuar se o scrum master estiver tentando puxar algo assim! Todos devem se comprometer exatamente com o que estão confortáveis. Por exemplo, eu sou líder de equipe e frequentemente acabava em uma discussão aleatória não planejada de design, ou ajudando alguém com código ou com a solução de problemas de coisas estranhas, para que minha capacidade nunca esteja acima de 50%.

Foram necessários quatro ciclos de lançamento para nossa equipe para aprender a não fazer as coisas que acabei de mencionar e mesmo que tenhamos melhorado definitivamente, se você perguntar aos especialistas, não somos nem meio ágeis. Ainda há muito a aprender a fazer.

Atualização 1: Resposta ao comentário de Cliff Bem, você ofereceu seus ouvidos, então aqui está ...

Você está certo, a mudança cultural é fundamental, mas essa mudança não precisa acontecer no nível executivo. Seu próprio gerente de grupo pode mudar a cultura dentro de sua equipe e isolar vocês do BS corporativo com o qual ele tem que lidar. O que você está descrevendo foi EXATAMENTE de 2007 a 2010. Nossa equipe (e outras equipes também) fracassou de lançamento em lançamento. Em um dos lançamentos, usando o "processo de ser ágil" da gerência, conseguimos que nove pessoas produzissem o trabalho que normalmente seria feito por uma única pessoa e levamos o dobro do tempo. Eu tinha tanto tempo livre que até atualizei meu currículo.

Então, conversei com meu chefe e expliquei a ele todas essas coisas sobre a agilidade das pessoas e que, se você quiser que se preocupem com o produto, tomemos decisões que afetam a maneira como trabalhamos e entregamos o produto. Eu acho que ele decidiu fazer disso um experimento, ele fez todas as mudanças que nós ... bem, principalmente eu, mas converso muito com o restante da equipe, daí 50% da capacidade :) ... proposta. É possível que ele tenha pensado que, se fizer todas as mudanças que estamos pedindo e ainda falharmos, ele voltará com um vitorioso "Eu te disse".

Então, nos últimos 12 meses, eliminamos tantas "idiotas" que nem sequer é engraçado. Nossas reuniões de stand-up realmente fazem sentido agora, porque trabalhamos juntos, não isoladamente. Ainda temos a propriedade (pelo menos por enquanto) de partes específicas do produto, mas também cruzamos com muita frequência o código um do outro. Fazemos constantemente análises de código para que não apenas os membros da equipe aprendam outro código, mas também aprendam melhores técnicas de codificação e design. Dividimos uma equipe monolítica e gigante "ágil" em três equipes diferentes, de modo que o planejamento e outras reuniões são muito mais curtas e as pessoas realmente se preocupam com elas, porque não ficam sentadas e escutam coisas sobre as quais não se importam. EU' Vimos noites em que quatro de cada cinco membros (uma das equipes) ficavam on-line às 23h e ninguém nos disse que precisamos trabalhar duro ou nos pressionou a trabalhar por mais de 40 horas. Pessoas que não se importam menos de meio ano atrás, de repente, estão envolvidas e empolgadas com o trabalho que estão realizando. E tudo o que foi necessário para o nosso gerente fazer foi dizer: "vocês decidem o que é certo e fazem o que precisam fazer, e vou manter o BS corporativo fora da equipe o máximo que puder".

Tudo começou como um experimento (minha suspeita, ele nunca me disse isso), mas agora nosso grupo está chutando o traseiro em comparação com outros grupos de desenvolvimento do departamento e ainda temos outros desenvolvedores que agora estão tentando se juntar a nós.

O maior obstáculo para nós desde que essa mudança aconteceu (e ainda é um problema hoje) foi o fato de que os engenheiros no ambiente corporativo normal são como ratos experimentais em uma gaiola. Mesmo quando seu gerente decide ser verdadeiramente "ágil" e remove a gaiola, todos estão nessa gaiola há tanto tempo que nem percebem que são livres. Assim, mesmo com toda a liberdade, eles continuam agindo como se ainda estivessem constrangidos. Eu acho que o que ajudaria é ter pelo menos poucas pessoas na equipe (como você), que vão além dos limites do grupo e procuram maneiras melhores de fazer as coisas. Depois volte para o grupo e mexa um pouco.

No seu caso, talvez a programação emparelhada não seja uma solução se você estiver procurando outra força externa para entrar na equipe e dizer a eles como trabalhar. Em vez disso, jogue fora as regras, sente-se com elas, sem gerenciamento, e pergunte-lhes o que elas querem fazer? O que os fará felizes? Produtivo? Identifique os maiores problemas e pergunte à EQUIPE qual eles pensam que a solução deveria ser.

O Scrum não exige que tarefas sejam atribuídas a indivíduos - longe disso. A responsabilidade pelas tarefas a serem realizadas recai sobre a equipe como um todo. Se a equipe quiser fazer a programação de pares, onde cada par escolhe uma tarefa, certamente deve fazê-lo.

No Guia Scrum :

A Equipe de Desenvolvimento geralmente começa projetando o sistema e o trabalho necessário para converter o Backlog do Produto em um incremento do produto em funcionamento. O trabalho pode ter tamanho variável ou esforço estimado. No entanto, está sendo planejado trabalho suficiente durante a reunião de Planejamento da Sprint para a Equipe de Desenvolvimento prever o que acredita que pode fazer na próxima Sprint. O trabalho planejado para os primeiros dias do Sprint pela equipe de desenvolvimento é decomposto em unidades de um dia ou menos no final desta reunião. A Equipe de Desenvolvimento se auto-organiza para realizar o trabalho no Backlog da Sprint , durante a Reunião de Planejamento da Sprint e conforme necessário em toda a Sprint.

Atribuir tarefas na reunião de planejamento é exatamente o que vai contra as decisões e o empoderamento da equipe. Isso também contraria a agilidade do sprint porque, desde o primeiro dia de cada sprint, todo desenvolvedor alinha exatamente o que deve fazer. Isso também significa que todas as tarefas devem ser estimadas corretamente, o que quase nunca ocorre.

Imho estimar tarefas é redundante. Você se comprometeu com o conjunto de histórias e o planejamento da reunião 2 é tempo suficiente para dividir essas histórias em tarefas e criar cartões para essas tarefas (ou preenchê-las em algum sistema). Não há tempo suficiente para estimar cada tarefa e essas estimativas não devem consumir tempo para desenvolvimento real.

Por quê? A estimativa é um lixo. Como pode ser um lixo? Porque fazer mais estimativas não trará mais valor comercial = é lixo e deve ser reduzido ao mínimo necessário. O mínimo é estimar / dimensionar histórias, o que ajuda você a se comprometer. Depois de fazer um compromisso, você não precisa de nenhuma outra estimativa. Você apenas sabe que fixou a data para entregar algo que comprometeu. Você poderá entregar histórias comprometidas ou não. A estimativa de tarefas não o ajudará nessa entrega.

Ignorar a estimativa da tarefa não afetará a visibilidade do progresso do sprint, porque a única medida real do progresso é o número de histórias concluídas (pontos da história) e isso ainda pode ser mostrado no gráfico de queima do sprint.

Apenas para deixar claro. Compromisso significa = Vamos fazê-lo . Não vamos tentar fazer isso ou qualquer outra coisa. Sim, você pode deixar de entregar o que comprometeu, mas seu compromisso deve basear-se na crença de que, com o seu conhecimento atual, você fornecerá histórias selecionadas. Se você tem essa crença, não precisa de outra estimativa.

Eu sempre usei o Scrum da maneira como o desenvolvedor escolhe uma nova tarefa, uma vez que ele completa sua última. Os desenvolvedores costumam dizer qual deles escolherá na reunião de pé. Geralmente não há regras sobre qual tarefa ele deve escolher. Cabe à auto-organização da equipe e à discussão entre os membros da equipe (fora da reunião stand-up). Isso é adiar a decisão para o ponto mais recente possível, onde você pode reagir a algumas mudanças e problemas sem afetar seu plano imaginário. A tarefa em si pode até mudar de proprietário se alguém tiver alguns problemas para concluí-la - alternativamente, essa tarefa pode ser desenvolvida em pares.

Como a programação de pares pode estar envolvida nisso? Facilmente. A equipe se compromete e deve abrir caminho para todas as técnicas de desenvolvimento necessárias para fornecer o incremento de trabalho do produto. Você estima uma tarefa ou desenvolvimento de tarefas e teste de tarefas? A última abordagem está completamente errada. O teste faz parte do desenvolvimento e da mesma forma que a revisão ou o emparelhamento de código faz parte do desenvolvimento, se necessário.

Fazer a programação em pares deve resultar na conclusão da tarefa mais rapidamente, com menor quantidade de erros e melhor qualidade do código. Como não será duas vezes mais rápido, ainda haverá alguma sobrecarga, mas o impacto real no comprometimento causado pelo emparelhamento ocasional deve ser muito pequeno. Este não é um caso para orientação ou ensino. Se você tiver um desenvolvedor que precise ser orientado ou ensinado, não planeje a capacidade dele para sprints nos quais ele aprenda a base de código do produto ou alguma tecnologia.