Scrum - Com o que os membros da equipe estão ocupados durante um sprint


33

Portanto, um scrum sprint é um período de tempo fixo durante o qual um conjunto específico de recursos deve ser implementado. E uma equipe de scrum consiste em todas as pessoas comprometidas com o fornecimento desses recursos, a maioria delas geralmente como desenvolvedores e testadores.

Depois de estabelecer essas regras, pode-se perguntar como manter todas essas pessoas ocupadas durante todo o sprint. No início do sprint, ainda não há nada a ser testado e, no final do sprint, normalmente não resta nada ou muito pouco para desenvolver / corrigir.

Eu já vi duas abordagens para lidar com isso, mas nenhuma delas parece resolver adequadamente o problema.

1) Deixe os membros da equipe decidirem o que fazer sempre que ficarem sem tarefas.

Contras:

  • Se o que eles fizerem não for totalmente planejado (ou seja, refatoração importante, mudança para uma nova estrutura de teste), o trabalho deles poderá ser inútil ou ficar parado no meio do caminho
  • Por outro lado, planejar esse trabalho pode levar bastante tempo, e o cliente pode ficar desapontado ao ver a equipe perder tempo com algo que não traz valor imediato
  • Essas tarefas geralmente não podem ser estimadas completamente, por isso é muito fácil para trabalhadores sem princípios passarem seu tempo assistindo a gatos do YouTube sem que isso se refletisse no quadro de scrum ou em qualquer outro lugar

2) Abra espaço no sprint apenas para desenvolvimento e inicie os testes após o término do sprint (quando os desenvolvedores começarem a trabalhar nos recursos do próximo sprint)

Contras:

  • Ao desenvolver recursos para o sprint atual, os desenvolvedores se distraem corrigindo bugs do anterior e podem falhar na execução da quantidade de trabalho estimada para ser realizada durante o sprint atual
  • São necessárias duas placas de scrum: uma para os recursos atuais do sprint e outra para os erros anteriores do sprint

Portanto, minha pergunta é: como distribuir adequadamente o trabalho durante o sprint entre desenvolvedores e testadores, para que ninguém fique sobrecarregado com o trabalho ou acabe sem tarefas a qualquer momento? Existem maneiras de melhorar as abordagens descritas acima? Ou existem abordagens melhores?


9
Você parece estar caindo para o mito de utilização
Nathan Cooper

1
@holdenmcgrohen Como são feitas as estimativas - planejando poker ou algo mais?
Robbie Dee #

3
Os testadores devem escrever casos de teste no primeiro dia. Tudo o que eles precisam fazer são as histórias. Se os desenvolvedores tiverem um tempo de inatividade significativo durante o sprint, isso significa que você não está recebendo histórias suficientes. Além disso, presumivelmente, se seus testadores forem bons, eles manterão seus desenvolvedores ocupados com relatórios de bugs perto do final do sprint. Além disso, idealmente, você tem as principais histórias da lista de pendências, portanto, na pior das hipóteses, os desenvolvedores podem trabalhar em um dos principais pares da lista de pendências.
Gort the Robot

1
@holdenmcgrohen, também enfrentamos problemas semelhantes em nosso projeto. Começamos a adicionar histórias do Stretch (não devem ser ' must have ') como parte do sprint e são selecionadas apenas quando os desenvolvedores estão sem tarefas. Agora, essa abordagem nos ajuda a manter o testador ocupado nos dias iniciais do próximo sprint.
user6005214

1
Lembre-se de que, na maioria dos sprints, você está selecionando um subconjunto de tarefas de um backlog . Se você concluir tudo o que se comprometeu, obtém uma vantagem no próximo sprint, começando a trabalhar em mais itens do backlog - assim como se você atropelar, você puxa menos itens do backlog no próximo sprint. pode terminar os que não foram terminados. Dogma de despejo; perceba que o objetivo da ferramenta é atendê-lo, não para você atendê-lo.
precisa saber é

Respostas:


49

No início do sprint, ainda não há nada para testar

Sério? Você não tem requisitos para validar? Não há discussões a ter com seu cliente? Sem armações de arame para avaliar? Não há planos de teste para pensar?

no final do sprint, normalmente não resta nada ou muito pouco para desenvolver / corrigir

Eu nunca estive naquele lugar em um projeto. Não há mais trabalho a fazer? Sempre tem alguma coisa. Todos os seus testes são totalmente automatizados? Como está o seu IC? A camada de acesso ao banco de dados poderia ser refatorada para ser mais simples? E nunca trabalhei em nada com uma lista de erros e um backlog vazios. O que seus desenvolvedores costumavam fazer na fase de testes em cascata?

Eu sei que algumas pessoas ficam muito religiosas sobre o que é e o que não é 'SCRUM'. Eu não poderia me importar menos com isso. Mas acho que você tem dois problemas aqui:

  1. Um departamento de controle de qualidade 'tradicional' que testa o código depois que ele é 'finalizado' pelos desenvolvedores, em vez de trabalhar com clientes e desenvolvedores para garantir que você esteja criando a coisa certa e correta. Dê uma olhada nos quadrantes de testes ágeis de Lisa Crispin. Os melhores testadores estão envolvidos em todas as etapas do ciclo de vida de desenvolvimento de software e os melhores desenvolvedores escrevem seus próprios testes.

  2. Tentando manter-se muito próximo a um cronograma SCRUM de sprints de 1 semana / 2 semanas sem ter uma lista de pendências priorizada e dimensionada, dividida em tarefas fáceis o suficiente para concluir em um curto período de tempo em um único sprint. Se você tivesse isso, sempre haveria mais trabalho para continuar. Talvez o último recurso em que você trabalha neste sprint não chegue ao lançamento deste sprint, mas sempre pode ir para o próximo.

A parte, de lado. Se você tem uma equipe pequena e coesa, os papéis são menos importantes. Em vez de ter alguém com o testador de etiquetas que não tem permissão para escrever código de produção ou alguém rotulado como desenvolvedor que acha que está acima dos testes, todos devem fazer o que for necessário para que a equipe tenha sucesso, incluindo as temidas tarefas de gerenciamento de projetos quando eles são necessários, isso é chamado de equipe multifuncional.

Um ponto extra levantado por @Cort Ammon nos comentários. O manifesto ágil fala sobre a colaboração do cliente sobre a negociação de contratos. Você diz que:

o cliente pode ficar desapontado ao ver a equipe perder tempo com algo que não traz valor imediato

Pode ser difícil de explicar e às vezes entendo que os clientes podem ser muito difíceis, mas isso seria uma grande bandeira vermelha para mim. Eles confiam em você com o código fonte / relacionamento com o cliente / empresa / o que você estiver desenvolvendo para eles. Se eles não podem confiar em você para agir profissionalmente em seu melhor interesse, então você tem um problema ou eles o fazem.

Eu escrevi um post que fala sobre desenvolvedores de software não serem considerados profissionais. Um médico profissional, advogado, engenheiro civil confrontado com um cliente que alterou os requisitos a meio do processo não apenas reduziria a qualidade e lamentaria. Eles diziam a seus clientes que isso seria um problema. Se o cliente pressionasse, um profissional não o faria apenas cegamente para um padrão perigosamente inferior, porque seria responsável. Não fazemos exames de admissão profissionais e, portanto, não somos responsáveis. Isso não significa que não devemos tentar melhorar.

Em resumo, eu não me preocuparia muito em tentar fazer com que as pessoas fossem mais eficientes no início e no final de um sprint, mas o consideraria um sintoma de um problema mais amplo dentro da equipe. Você já ouviu falar da eXtreme Programming (XP) . Eu diria que os princípios do XP para aplicar aqui são comunicação e respeito:

  • Respeite sua equipe para fazer o que achar melhor. Eu diria que, se houver muitos vídeos de gatos, você tem desenvolvedores ruins ou os está tratando mal.
  • Comunicação. Se seus desenvolvedores estão conversando entre si, com os testadores, com a gerência e com o cliente, todos provavelmente devem ter uma boa noção do que virá a seguir e, se não o fizerem, podem apenas perguntar.

Sim sim e sim. Encontre respostas em todos os sentidos.
David Arno

Boa resposta - o último parágrafo precisa de trabalho. Levante e explique os pontos aqui em vez de apontar para algum tomo.
Robbie Dee

1
O que seus desenvolvedores costumavam fazer na fase de testes em cascata? - Não pretendia comparar o scrum com o watefall, mas com as abordagens do tipo kanban, onde sempre há uma lista de tarefas a fazer, que já são avaliadas e priorizadas. O backlog do scrum contém recursos que não foram examinados adequadamente pela equipe; portanto, se um único desenvolvedor (que atualmente não possui recursos para trabalhar) decidir começar a implementar um deles no meio do sprint, isso poderá levar a consequências inesperadas. .
precisa saber é o seguinte

@holdenmcgrohen justo o suficiente. Minha estimativa é sempre terrível, o que tento explicar, então gosto sempre de ter algo a seguir. Eu acho que os standups diários e o emparelhamento podem ajudar aqui, se seus desenvolvedores não ficarem sozinhos por muito tempo, eles não poderão se afastar muito.
precisa saber é o seguinte

@Encaitar Great stuff +1 #
Robbie Dee #

20

O primeiro ponto é que o Scrum visa otimizar a equipe , não cada indivíduo. Se a equipe é produtiva e eficiente, não importa muito se alguém está ocioso no início ou no final da tarefa.

No entanto, em todas as equipes em que participei, sempre há muito trabalho. Deixe-me abordar algumas de suas preocupações específicas:

No início do sprint, ainda não há nada para testar,

Embora isso possa ser verdade no sentido literal, isso implica que você acha que o único trabalho para um testador é "testar". Há muito o que fazer antes de começarem a testar. Por um lado, eles podem se reunir com o proprietário do produto e os desenvolvedores para entender completamente os requisitos. Eles podem estar ocupados trabalhando em um plano de teste, reunindo dados de teste e assim por diante. Se eles tiverem o luxo de uma boa estrutura, poderão começar a escrever testes automatizados com antecedência.

no final do sprint, normalmente não resta nada ou muito pouco para desenvolver / corrigir

Ainda estou para ver uma equipe de desenvolvimento que ficou sem muitas coisas para corrigir. No entanto, não é isso que eles deveriam fazer no final do sprint. No final do sprint, eles devem ajudar os testadores a testar o produto. Eles podem ajudar a escrever testes automatizados, podem fazer testes de revisão de código e acessórios / palavras-chave / etc escritos pelos testadores. Eles podem trabalhar com a equipe de documentação para ajudá-los a concluir seu trabalho, etc.

Vi duas abordagens para lidar com isso ... 1) Deixe os membros da equipe decidirem o que fazer sempre que ficarem sem tarefas.

A falha em seu pensamento é que os indivíduos ficam sem tarefas. As tarefas pertencem à equipe como um todo. Eles não devem fazer outro trabalho enquanto houver histórias ou tarefas restantes para a equipe no sprint atual.

Abra espaço no sprint apenas para desenvolvimento,

Essa abordagem não está dentro da definição tradicional de scrum ou ágil. O ponto principal do ágil é que uma equipe inteira está envolvida no trabalho em direção a um objetivo comum. Isso significa que todo o trabalho necessário para terminar uma história deve ser representado em um sprint - design, desenvolvimento, testes, documentação etc.

Finalmente, essa não é a única outra solução viável. Você negligencia a verdadeira solução, que é que todos os membros da equipe participem conforme necessário para ajudar a terminar as histórias em um sprint.

O objetivo é um objetivo da equipe , mas você está escrevendo como se cada pessoa tivesse objetivos individuais ("termine minhas tarefas"). Se alguém não tiver nada para fazer, poderá ver o que está sendo trabalhado no momento e oferecer ajuda. Ou eles podem pegar a próxima tarefa ou história e começar a trabalhar nela.


1
+1. Processos ágeis exigem folga. Para otimizar um sistema, você geralmente precisa des otimizar os subprocessos. Nesse caso, você disse o melhor em "otimizar a equipe". Qualquer outra coisa é um sintoma da falácia da utilização.
CodeGnome 2/16/16

No início de minha carreira, enfrentei algumas empresas que esperavam que os candidatos trabalhassem em PHP, Java, C #, aplicativos de desktop (VB), controle de qualidade (automatizado, manual), Photoshop, CSS e assim por diante. Naquela época, a indústria considerava essas empresas menos profissionais por causa do valor da especialização. Eu me pergunto se o mesmo padrão ganha aceitação (até se torna necessidade) no Agile.
precisa saber é o seguinte

1

Em todas as lojas ágeis em que trabalhei, os testadores são considerados galinhas, para que não fiquem dentro do prazo, como os desenvolvedores. Antes de colocar as mãos no software, os testadores devem escrever planos e garantir que os ambientes estejam configurados corretamente para receber o software. Como parte disso, eles devem examinar todos os documentos de design como eles são.

Em seguida, você deve procurar preencher o sprint. Não deve haver nenhum tempo livre no final do sprint se as estimativas forem boas, embora a estimativa, obviamente, seja uma arte negra, por isso raramente preenche exatamente .

Se um desenvolvedor tiver tempo livre no final do sprint, esse tempo ainda deverá ser rastreado para garantir que esteja agregando valor (aprendendo uma nova estrutura, fazendo análises, testes adicionais etc.).

A correção de bugs é uma atividade perfeitamente aceitável para ser colocada em um sprint. Contribui para um recurso e agrega valor. Isso não deve ser visto como tempo roubado do próximo sprint - finalizando mais adequadamente um recurso.


8
Leia o Guia do Scrum . Talvez você encontre a parte em que diz que não há problema em dividir a equipe de desenvolvimento em testadores e desenvolvedores (dica, você não vai).
Nathan Cooper

3
O documento não diz que você tem membros da equipe de desenvolvimento com especialidades, mas você não pode dividir um grupo para tratar como "galinhas".
Nathan Cooper

5
Para os eleitores derrotados, que parte do treinamento em Agile você perdeu, onde especifica que você deve adotar uma estratégia que funcione para sua equipe ? A equipe de Robbie Dee adotou o que funcionava para eles em suas circunstâncias únicas, com seu projeto exclusivo e restrições ambientais. Toda empresa possui barreiras ambientais e "danos" que precisam ser roteados. Parece uma abordagem perfeitamente aceitável para a pergunta que foi feita . A pergunta não era sobre a melhor maneira de organizar testadores e esforços de teste em sua equipe de sprint.
Maple_shaft

4
Não. O OP perguntou especificamente sobre Scrum. Você não pode fazer o que quiser e chamar de Scrum. Pode ou não ser ágil, mas ter partes da sua "equipe" multifuncional tratadas como recursos externos ou como qualquer coisa que não sejam membros de primeira classe da equipe de desenvolvimento não é Scrum.
precisa saber é

2
O @CodeGnome está absolutamente correto e aborda um ponto que sempre trago à tona: Agile é uma filosofia, Scrum é uma implementação dessa filosofia. Os dois não são a mesma coisa e cumprem regras separadas. (Sim, Scrum veio primeiro, mas foi mais tarde adaptado para ser uma implementação Agile)

-2

Em um mundo ideal, sua equipe seria multifuncional . Todo mundo tem sua especialização, mas todos também podem trabalhar como outra especialização. Se seus testadores não puderem codificar as tarefas mais simples, você não terá uma equipe multifuncional.

A maneira do SCRUM seria permitir que sua equipe fosse multifuncional. De qualquer forma, seus testadores devem ter habilidades para automação de testes; é um pequeno passo para codificar algumas das coisas menos complexas.


6
Pessoas em forma de T são uma coisa, fazer com que os testadores escrevam código (a menos que falemos em automação de teste) é outra.
Robbie Dee #

2
Isso apenas pressupõe que apenas os testadores têm tempo de inatividade no sprint? Os desenvolvedores também têm tempo de inatividade.
Maple_shaft

Presumo que os Devs possam fazer testes sem treinamento adicional. Onde moro, isso faz parte da educação e do trabalho.
Nvoigt 02/03
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.