Temos uma equipe "típica" do SCRUM e nos comprometemos a trabalhar para um sprint, além de manter uma lista de pendências. Recentemente, encontramos um problema ao tentar integrar / gerenciar o trabalho de um desenvolvedor com desempenho excedente que trabalha fora da banda (optando por trabalhar fora do horário normal de trabalho / sprint).

Para dar um exemplo, se a equipe receber 50 pontos de trabalho, digamos que eles concluirão todo esse trabalho dentro da estrutura SCRUM até o final do sprint e eles e a empresa ficarão felizes. Um dos membros da equipe decide trabalhar por conta própria, em um item da lista de pendências, em seu tempo livre. Eles não fazem check-in neste trabalho, mas salvam-no (usamos o TFS e ele está em uma prateleira).

Como lidar com isso? Alguns dos problemas ..

• Durante o próximo sprint, os membros dessa equipe dizem que o trabalho de programação está 99% concluído e precisa apenas de revisão e teste de código. Como você lida com isso na metodologia SCRUM e ágil?
• Outros desenvolvedores reclamam de não estar envolvido nas decisões de design relacionadas a essas histórias, pois o trabalho foi feito fora da banda.
• Nosso proprietário do produto é tentado a realizar esse trabalho "gratuito" e os membros com superação provavelmente o fazem de propósito, a fim de obter mais recursos no produto que a equipe de outra forma não seria capaz de realizar no sprint (s). Há uma visão de que isso está quebrando o "processo". Obviamente, o controle de qualidade, a interface do usuário e o trabalho de documentação ainda precisam ser feitos nesse trabalho.

Eu vejo muita discussão sobre não forçar uma equipe do SCRUM a trabalhar horas extras, mas e quanto a um membro da equipe que trabalha acima e além das expectativas apresentadas durante o planejamento e a execução de sprints? Eu hesitaria em reinar com essa pessoa e dizer que você não pode trabalhar extra (alertando para a queimadura, é claro), mas, ao mesmo tempo, parece estar causando alguns problemas com certos membros da equipe (mas não todos).

Como integrar o trabalho realizado por um membro com superação no processo SCRUM e ágil para desenvolvimento de software?

Tudo bem, então alguém está entusiasticamente escrevendo um ótimo código que precisa ser feito, mas não em ordem. Com toda a devida ênfase:

DEIXE ELES

Está causando algumas complicações nos seus sprints. Isso realmente importa no grande esquema das coisas? Se ele está realizando o que deveria, deixe-o continuar e construir grandes coisas para você.

Conheço vários programadores incríveis que deixaram empresas porque não deixaram os programadores fora das restrições de um sistema artificial como o Scrum (eu mesmo deixei meu último emprego depois de ser tratado como nada mais do que um QA glorificado). Se houver reclamações de outros desenvolvedores sobre contribuições (queixas perfeitamente válidas, devo acrescentar), talvez seja melhor introduzir um programa de "20% de tempo" para permitir que ele (e outros) façam o que fazem melhor com o mínimo de interferência.

Em vez de histórias futuras (que podem exigir informações de outras pessoas), permita que o desenvolvedor experimente novas tecnologias ou recursos. Você pode encontrar uma grande oportunidade nova que nunca teria sido explorada de outra maneira. Tenho certeza de que esse desenvolvedor tem algumas coisas que gostaria de experimentar se você permitir.

Acho que você deve considerar duas coisas aqui:

1. Não atrapalhe o fluxo criativo de alguém.
   • Se um desenvolvedor quiser trabalhar fora de horas, deixe-o.
2. Não crie trabalho para os outros.
   • Se um desenvolvedor deseja trabalhar fora de horas, é melhor não criar mais trabalho para os outros .

É provável que o ponto 2 preocupe os outros desenvolvedores.

Como você mencionou, eles não gostam do fato de o código ser escrito sem a entrada de toda a equipe. Isso pode ser porque, em termos de design, acaba sendo inferior. E código com design inferior tem uma maneira de infectar outro código ao seu redor.

Então o que você pode fazer?

Deixe o código de desenvolvimento ambicioso no conteúdo de seu coração, mas deixe claro que não há razão para supor que seu código extracurricular será usado .

Afinal, ele faz parte de uma equipe e, portanto, a equipe deve se envolver em como todo o código é desenvolvido.

Se, no entanto, o trabalho dele for bom e se encaixar no design acordado pela equipe, ele poderá usar muito do que já escreveu (bônus!). Caso contrário, forçá-lo-á a pensar mais sobre seu projeto na próxima vez que ele decidir começar.

Dessa forma, ninguém recebe o NÃO , e ninguém cria um trabalho extra para eles.

Coloque-o de volta na equipe

Você deve se perguntar (ou melhor, a equipe, incluindo a superação):

Por que esse comportamento é um problema?

Como você rotula o desenvolvedor como um supervisor, acho que o trabalho dele é de boa qualidade, então vou assumir que isso não é um problema.

Mas parece haver outros problemas:

• O trabalho extra não foi testado corretamente
• não está documentado
• o resto da equipe não sabe disso
• o desenvolvedor decide a próxima coisa a implementar, não o pedido
• o desenvolvedor não recebe nenhum feedback das várias partes interessadas para incorporar em seu trabalho.

O próximo Por que eu faria como é:

Por que o desenvolvedor faz isso?

• Se no final do sprint não houver trabalho suficiente, deve haver uma decisão da equipe (incluindo a OP) sobre o que enfrentar a seguir. Por que o desenvolvedor evita essa decisão?

Depois de responder a essas perguntas, você pode começar a responder sua própria pergunta:

• se não for um problema, deixe-o fazer o que quiser. Embora algumas pessoas tratem o SCRUM como uma religião, não deve ser assim.
• É mais provável que você tenha dois problemas na equipe: o (s) causado (s) pelo desenvolvedor não autorizado e o (s) acionador (es) do comportamento do desenvolvedor não autorizado. Encontre uma maneira de resolver o posterior e o primeiro desaparecerá.

Por mais que eu goste da ideia de que adicionar trabalho gratuito ao mix é uma coisa boa, isso não é trabalho gratuito - a menos que o desenvolvedor único também seja o testador, o controle de qualidade e o responsável pela construção, o designer e tudo mais. Se o trabalho dele puder ser colocado no próximo sprint sem nenhum impacto, então ... vá em frente. Mas acho que nunca é esse o caso. Todos os outros, no mínimo, precisam entender o que fizeram e que impacto isso tem sobre eles. Eles precisam entender que as mudanças dele estão acontecendo e, portanto, não duplicar seus esforços - é difícil dizer a alguém que eles trabalharam duro em uma tarefa apenas para encontrar o cara desonesto que fez isso na semana passada.

Você está trabalhando em um ambiente ágil, e uma coisa que eu sei sobre o ágil é que ele foi projetado para funcionar para você, não contra você. Então, você precisa mudar a maneira de trabalhar para permitir que esse tipo de atividade extra-curricular ocorra. Isso significa obter a contribuição e o consentimento de todos, você não pode fazer isso sem a participação deles. É vital. Se a equipe não gostar, o cara desonesto pára de fazer isso. Fim do. Não é um cara que faz o que gosta, não importa quão bom seja seu trabalho, é um esforço de equipe o tempo todo. A equipe vem em primeiro lugar.

Portanto, você precisa sentar todos na próxima reunião de planejamento e discutir isso, todos os membros da equipe precisam decidir permitir ou alterar seu processo para gerenciar melhor esse tipo de atividade.

Talvez você obtenha uma solução em que todos trabalhem em seus projetos favoritos e os leve à mesa (você pode imaginar o caos na sua entrega que causaria :), que destaca o problema com isso em primeiro lugar) ou pode exigir A área em que cada desenvolvedor tem automação para desenvolver qualquer solução que ele goste é a 'contribuição' da mesma forma que quantos projetos de código aberto funcionam, ou você pode dar a todos tempo livre para experimentar (o antigo tempo de 20%).

Esse desenvolvedor escreve testes e código limpo / sólido ou está apenas enviando o que pode ser feito rapidamente? Pessoalmente, não permitiria que ninguém trabalhasse fora do horário definido, pois isso atrapalha suas estimativas e, como você apontou, ocorrem outros problemas.

No entanto, você nunca deve ser rígido em seu processo. O Scrum é apenas uma estrutura para que você possa sempre ajustar o processo para incluir o tempo extra (mas, novamente, é difícil planejar o que alguém pode fazer).

Você também pode pedir que ele trabalhe em outras coisas além do projeto. Olhando para novas tecnologias ou criando treinamento sobre as coisas que ele faz de maneira diferente. No final das contas, qualquer coisa feita fora do cronograma planejado destruirá suas estimativas e eu não deixaria isso acontecer.

também enfrentamos a mesma coisa, basicamente cometemos algo como 20 pontos, mas na semana passada ou mesmo no meio do sprint ficamos sem tarefas de codificação, no entanto, por causa dos testes e do restante do processo, não corremos o risco de escolher outro PBI. Os programadores fizeram foi examinar o backlog e começar a desenvolver PBIs futuros (silenciosamente!) e informar o restante da equipe no planejamento de que o PBI está pronto para revisão e teste de código! como você disse.

Na verdade, suscitou alguma preocupação de nossos OPs de que parece que somos mais capazes, mas não utilizamos totalmente o potencial de nossa equipe, o que era parcialmente verdadeiro, mas sim, talvez nossos programadores pudessem fazer mais, mas nossos testadores não conseguiam acompanhar essa velocidade. havia o risco de falhar no sprint. Depois de pensar sobre esta questão, descobrimos que precisamos mudar nossa visão sobre scrum e a questão principal é que as pessoas não querem correr esse risco é porque nós Commit PBIS tão equipe não se sentir bem para correr esse risco de picking novos PBIs, caso tenhamos programador gratuito.

Simplesmente começamos a previsão PBIS em vez de compromisso make. Previsão significa basicamente que escolhemos 25 pontos no planejamento e no início do sprint. E quando o programador fica livre no meio do sprint, porque não há mais tarefas de codificação, ele escolhe um dos PBIs futuros e o coloca no Current Sprint e começa a trabalhar. nele, se o PBI puder passar todo o processo (teste, mesclagem e etc.) dentro do mesmo sprint, é um ponto de bônus para a equipe se NÃO não falharmos no sprint por causa do PBI e apenas continuar o trabalho restante ( teste ou meging ou etc) para o próximo sprint e re-poker para o trabalho restante. Portanto, isso pode ser feito em dois sprints diferentes no pior cenário. Eu sei que pode parecer o Scrumbut, mas na verdade melhorou a maneira como trabalhamos. Apenas posso resumir seus benefícios como abaixo:

• Derrota a fobia da falha do sprint por correr o risco de tomar mais PBI
• Torna visível o trabalho extra de seus programadores e equipe
• Aumenta a velocidade da sua equipe

No entanto, talvez para uma equipe com menos experiência, talvez reduza o esforço que o compromisso dá à equipe para concluir os PBIs

Algumas das outras respostas sugeriram que o desenvolvedor "superado" é "desonesto" ou "violando os princípios do Scrum". Isso está incorreto e esse desenvolvedor deve ser incentivado (embora você não deva pedir às pessoas que trabalhem em algo específico nesse período extra, mas você pode fazer sugestões e ajudar a promover idéias).

Não há nada no Scrum para prescrever como as pessoas trabalham e qualquer coisa extra que ele faça naturalmente seria incorporada à velocidade da equipe.

Seu trabalho deve ser trazido para o backlog do produto e estimado na próxima reunião de planejamento. Se você não pode prever qual é o esforço restante imediatamente, deve reservar um tempo do sprint para descobrir (ou seja, um Spike).

Interessante você descrever o desenvolvedor como "superação", presumo que isso significa que ele está agregando muito mais valor do que os outros membros da equipe.

As dificuldades que um trabalho extra cria implica que há algo abaixo do ideal (ou talvez até disfuncional) em sua equipe.

Se for esse o caso, você deve se perguntar por que ele está conseguindo muito mais, presumivelmente com apenas um pouco de esforço extra?

É possível que você permita que o restante da equipe alcance mais?

Vi a situação em que as equipes foram microgerenciadas, potencialmente sobre histórias de usuários prescritivas, definição de done, que acaba sendo sufocante para os desenvolvedores. Este desenvolvedor está fazendo o trabalho que ele deseja? Estou assumindo que ele está tomando boas decisões. Trabalhar dessa maneira na semana de trabalho também ajudaria o resto da equipe?

Peça que eles também sejam professores

É ótimo que você tenha um desenvolvedor estrela com as melhores e mais avançadas habilidades do grupo. Gostaria de elogiar e elogiar isso. Muitas vezes, essas pessoas são a "cola" que mantém as organizações unidas.

Eu consideraria o desafio como 'como aproximar desenvolvedores menos experientes da produtividade do desenvolvedor mais avançado'.

Uma ótima maneira de fazer isso é se concentrar em fazer com que o desenvolvedor estrela gaste mais tempo ensinando, treinando e orientando os membros da equipe menos experientes e mais lentos. Gostaria de discutir isso primeiro em um 1 para 1 com o desenvolvedor estrela para que eles saibam o que você está fazendo e por quê. Por outro lado, pode ser encarado com suspeita como uma agenda oculta / mau gerenciamento

Quando você faz standups, uma ou duas vezes por dia, se essa pessoa ficar sem trabalho e outras ainda estiverem fazendo tarefas, procure programar em pares para que ela possa emparelhar com os membros juniores e transmitir seu grande conhecimento e experiência. Certifique-se de fazer a pergunta "alguém precisa de ajuda? Alguém está procurando um par?"

Você também pode encontrar um trabalho secundário para o melhor desenvolvedor quando ele estiver desempregado, como aprimorar o conjunto de ferramentas que está sendo usado por todos, administrar um grupo de discussão do clube técnico ou envolver-se em outros projetos organizacionais.

Vou responder uma pergunta diferente. Eu acho que lidar com essa situação no Scrum não é realmente importante. O Scrum é mais como uma diretriz de qualquer maneira. Se você quiser que isso aconteça, encontre uma maneira simples de adaptar seu processo, como simplesmente assumindo que o trabalho já está feito.

A verdadeira questão é se você deseja que esse desenvolvedor faça o que ele está fazendo. Eu acho que vários aspectos desempenham um papel fundamental na resposta a essa pergunta:

1. O programador está fazendo um bom trabalho?
2. Todo mundo está bem com ele fazendo seu trabalho por conta própria (seja bom ou ruim). Afinal, ele está se esquivando do processo de design!
3. As horas extras são pagas ou não.

Tudo isso influencia se faz sentido para o seu produto que ele esteja fazendo o que está fazendo. Novamente, incorporar sua decisão no processo de design não é realmente um problema. Apenas seja flexível.

Isso viola um inquilino do Scrum porque a equipe não está decidindo o trabalho no sprint. Esta é uma equipe de scrum . A equipe precisa disciplinar esse programador para que a disciplina seja distribuída.

Outra questão que isso cria é que ele estraga a velocidade da equipe. O trabalho fora da banda não conta para a velocidade e queima. Portanto, esse trabalho fora de banda é feito, a equipe está em média 50 pontos em velocidade, mas mais de 50 pontos são feitos. O proprietário do produto verá isso e exigirá maior velocidade no próximo sprint. Velocidade que pode não ser possível.

A equipe (não o PO ou o ScrumMaster) precisa resolver isso com o programador invasor.