Scrum - Desenvolvedores que trabalham fora do Sprint

11

Equipe Scrum

3 x Desenvolvedores
2 x testadores
1 x Analista de Teste de Automação

Não somos uma equipe multifuncional, pois os desenvolvedores não testam e os testadores não desenvolvem. Acredito que essa seja a causa raiz do problema.

Atualmente, fazemos sprints de duas semanas.

No início do sprint, todos estão ocupados, os desenvolvedores estão começando o trabalho de desenvolvimento e os testadores estão fazendo sua preparação (escrevendo casos de teste etc.)

Depois que os testadores terminam sua preparação, eles aguardam a conclusão do trabalho de desenvolvimento OU o trabalho de desenvolvimento está concluído e os desenvolvedores aguardam comentários / bugs.

Os desenvolvedores ficam com coceira aqui e começam a trabalhar nos itens do backlog que estão fora do sprint atual. Isso criou um efeito estranho, pelo qual estamos sempre desenvolvendo os próximos sprints no sprint atual. Para mim, isso não parece certo.

Do ponto de vista da gerência, eles preferem que os desenvolvedores trabalhem do que se sentam em suas mesas, sem fazer nada, mas ao mesmo tempo sinto que o objetivo e o foco da equipe de scrum deveriam estar apenas no sprint atual. Desejo que nossa equipe seja multifuncional, mas infelizmente não é possível. Os testadores não possuem as habilidades necessárias para realizar o trabalho de desenvolvimento e a maioria dos desenvolvedores acredita que os testes estão abaixo deles.

Isso é considerado um problema no scrum? Existe uma solução para isso? O scrum funciona apenas com equipes multifuncionais?

Gostaria de conhecer as experiências de outras pessoas com isso, se possível :)

agile scrum

— fml
fonte

3

Eu concordo com a gerência. Ter pessoas sentadas por causa de um período arbitrário de duas semanas é uma péssima idéia. Talvez as responsabilidades de sua equipe sejam muito rígidas; em equipes tão pequenas, não é incomum que todos os membros da equipe sejam "multifuncionais", permitindo que eles entrem onde necessário no sprint atual.

— Robert Harvey

... ou talvez você não esteja colocando o suficiente nos seus sprints para manter a equipe ocupada por duas semanas.

— Blrfl

3

Um mashup de desenvolvimento / teste de par híbrido é prático? Em certo sentido, o processo é igual ao ciclo de testes unitários; escreva um pouco de teste um pouco. Nós não tínhamos isso formalmente, mas os testadores tinham o hábito de vir diretamente até nós, pois um ou dois erros foram encontrados. Não nos comunicamos por meio de relatórios formais de erros. No momento em que "meu testador" terminou o teste, eu já havia terminado de corrigir. Ser um aplicativo da Web tornou a correção eficiente. Mas pelo menos experimente. E, francamente, mesmo que não seja melhor ou pior, a MGT perceberá menos tempo de espera individual.

— Radarbob

3

O trabalho inicialmente planejado para um sprint geralmente é concluído com qualidade suficiente? Ou você também fica com histórias semi-acabadas fora do planejamento original?

— Bart van Ingen Schenau,

2

Você pode simplesmente manter seu processo, mas chamá-lo de 'kanban' em vez de 'scrum', e então não precisa se preocupar se o seu processo está certo com o scrum. / um tanto sarcástico, mas não realmente

— Eric Rei

16

Esse é um problema bastante comum, causado pela tubulação . A equipe é multifuncional, mas é claro que existem silos internos que diminuem o desempenho.

Em primeiro lugar, gostaria de observar algumas coisas que considero importantes:

Se seus desenvolvedores trabalharem com uma iteração antecipadamente, eles estão impedindo sua reunião de planejamento. Seu gerente de produto e a equipe precisam discutir o que é mais valioso para a próxima iteração corretamente. A priorização não deve ser efetivamente feita pelos desenvolvedores, porque eles não têm nada melhor para fazer.
Não importa como você divide e organiza as iterações, não é possível manter todos ocupados o tempo todo e ter uma única equipe com uma única reunião de planejamento, desde que sua equipe tenha especialistas trabalhando em silos. Mesmo com uma abordagem pura em cascata, você ainda precisa "jogar coisas por cima do muro" e aguardar feedback.
Você também tem o problema de que muitas vezes uma única história precisa ter uma fase de desenvolvimento, seguida por uma fase de teste, seguida por uma fase de correção de erros, seguida por ... isso pode realmente tornar sua equipe ineficiente - especialmente se eles trabalharem com antecedência , porque eles precisam alternar de contexto.

Claramente, há um custo muito real para esta situação: a equipe não está colaborando. Eu encontrei isso toda vez que havia uma equipe de controle de qualidade envolvida, por isso tive um pouco de tempo para experimentar soluções diferentes.

O que funcionou muito bem para mim são essas duas ferramentas:

Saliente o princípio de que toda a equipe é responsável por fazer as coisas. Recuse as histórias "dev done", pois elas são uma maneira de os desenvolvedores dizerem "não é mais meu problema", o que não é construtivo nem é patentemente falso. Se uma equipe não entrega uma história que eles aceitaram, é toda a equipe que não entregou.
Para ocupar o tempo dos desenvolvedores e do controle de qualidade, emparelhe-os . Essa é de longe a melhor maneira de compartilhar experiência e conhecimento de domínio que você pode escolher. Os desenvolvedores podem ajudar os testadores a automatizar suas tarefas. Os testadores podem mostrar aos desenvolvedores onde é importante testar o código porque é quebradiço. Ambos colaboram e trabalham mais rápido do que não.

Usando essas duas técnicas, a equipe deve ficar menos isolada e com melhor desempenho. Embora seja improvável que testadores e desenvolvedores consigam trocar de trabalho, eles poderão trabalhar em equipe e resolver o problema internamente, em vez de se culparem.

— Sklivvz
fonte

1

Obrigado pela sua resposta. Eu realmente gosto da ideia de emparelhar o desenvolvedor e o recurso de controle de qualidade. Vou sugerir isso em nossa próxima reunião e espero que possamos testar isso no próximo sprint. Vou atualizar a pergunta e informar como ela vai!

— fml

@ Sklivvz Isso acontece com mais frequência do que quando existe um departamento de controle de qualidade. Isso acontece sempre que o controle de qualidade é uma função que apenas "certas pessoas" podem desempenhar. Em vez de o recurso inativo pegar a "próxima" tarefa de alta prioridade, o desenvolvedor fica inativo e depois trabalha mais enquanto o controle de qualidade está perpetuamente reagindo à saída do desenvolvedor.

— Edwin Buck

1

Se ele não estava claro acima, a "próxima tarefa de alta prioridade seria 'reduzir o atraso QA assim que os artigos podem ser enviados' não a próxima tarefa de desenvolvimento de alta prioridade do backlog.

— Edwin Buck

1

Os conselhos, como toda a equipe, são responsáveis, embora pareçam bons, na realidade, não servem à equipe. Isso sugere que todo mundo é intercambiável e é a falta de todo mundo que não está participando. Isso está errado. Cada pessoa no SDLC tem um papel específico e passou ANOS aprimorando suas habilidades. Pedir a um engenheiro de software que faça testes é prejudicial à qualidade, pois eles não têm a experiência necessária para testar a qualidade e provavelmente farão uma tentativa tímida. Mesmo se o engenheiro de controle de qualidade os orientar, a orientação levaria um tempo para os testes e tornaria o trabalho ainda mais demorado.

— Chuck Conway

1

@ChuckConway ninguém está sugerindo o que você diz. O emparelhamento não é substituto ou mentoring. Idealmente, você confia na equipe para encontrar a melhor maneira de minimizar o tempo de inatividade, e isso só pode começar com as pessoas entendendo as funções e necessidades uma da outra. As melhores e mais eficientes equipes se auto-organizam (verdadeiro ou não, é um princípio básico do ágil).

— Sklivvz

2

Não há problema com a maneira como você está trabalhando relacionado ao SCRUM e aos sprints, desde que seja registrado no momento da avaliação que o trabalho do desenvolvedor foi concluído em menos tempo (e em quanto tempo) planejado. Isso permitirá que a equipe ganhe mais pontos na história para o próximo sprint. Afinal, o objetivo dos sprints é melhorar o planejamento. Obviamente você ainda tem espaço para melhorias.

estamos sempre desenvolvendo próximos trabalhos de sprints no sprint atual

Uau! Isso não é tecnicamente possível no Scrum. Você não sabe quais itens da lista de pendências serão no próximo sprint, que serão estabelecidos no início do próximo sprint em uma sessão de planejamento do sprint.

Ainda é interessante aprender sobre as novas formas criativas que as organizações inventam para sabotar o Scrum.

— Martin Maat
fonte

3

O problema com declarações como "Whoa! Isso tecnicamente não é possível no Scrum" e "... novas formas criativas de organização das organizações para sabotar o Scrum" é que elas implicam que existe uma maneira correta de "fazer o Scrum". Para que haja uma maneira correta, o Scrum precisa ser proscritivo, ou seja, colocar os processos diante das pessoas. Portanto, o Scrum não é um processo ágil se houver uma maneira correta de executar o Scrum.

— David Arno

@ David Arno Isso é legal, você está basicamente dizendo que qualquer metodologia é, por definição, não-ágil. Até o manifesto ágil. Apenas o caos imprevisível seria ágil. Mas espere .. quem está me dizendo para ser caótico? Sério agora: o adágio ágil "pessoas antes dos processos" está lá para resolver conflitos. Se alguém tem que escolher, deve fazer o que faz sentido, não necessariamente o que as regras dizem. Parece-me que a equipe do OP poderia seguir o livro Scrum sem problemas. E talvez o façam, a questão principal parece ser o quão transparente eles são.

— Martin Maat

1

@DavidArno, na verdade, isso implica apenas que existem maneiras erradas específicas de fazer o Scrum, e isso parece incontroverso. Por exemplo, qualquer coisa que contradiga o Manifesto Ágil parece objetivamente incorreta.

— Sklivvz

1

O Scrum otimiza para a equipe , não para o indivíduo. O ponto principal do scrum é que a equipe se torne eficiente. Se os desenvolvedores estão começando a trabalhar em coisas fora do sprint atual, estão prestando um desserviço à equipe. Também mostra que você está falhando um pouco no processo de planejamento, se não planejar o trabalho suficiente para preencher a primavera.

Se os desenvolvedores acabarem com as tarefas de desenvolvimento, eles absolutamente devem contribuir e ajudar os testadores, os escritores de tecnologia ou os designers - qualquer pessoa da equipe. Eles não precisam necessariamente escrever testes reais ( deveriam ), mas ainda podem participar do processo de teste. Eles podem escrever scripts que ajudam os testadores a serem mais eficientes ou podem simplesmente discutir com os testadores quais são seus desafios e ajudá-los a superá-los (por exemplo: adicionando atributos de identificação aos elementos da página da web, fornecendo ganchos ou APIs que os testadores pode usar em seus testes, etc).

Eu acho que o cerne do problema é que, se seus desenvolvedores nem sempre estão trabalhando no sprint atual, eles ainda não estão trabalhando em equipe. Seu scrum master deve prestar atenção e trabalhar para que a equipe trabalhe como uma unidade, e não como uma coleção de indivíduos.

Sugiro também que este é um problema de gerenciamento. Se eles estão pressionando os desenvolvedores a permanecerem ocupados, eles não adotaram completamente o scrum. Essa é outra coisa com a qual o scrum master pode ajudar. Eles podem trabalhar com a gerência para ajudá-los a entender como o scrum funciona, para ajudar a apoiar e incentivar as equipes de desenvolvimento, em vez de subvertê-las.

— Bryan Oakley
fonte

0

Eu acho que o principal problema aqui é o seguinte:

a maioria dos desenvolvedores tem a opinião de que os testes estão abaixo deles

A maneira como lidamos com isso em nossa empresa é que perguntamos aos desenvolvedores como eles podem dizer que realmente terminaram seu trabalho se não puderem provar isso. Obviamente, a única maneira de provar isso é demonstrar que o código que eles escreveram realmente funciona, e isso é feito através de testes. Deve-se ressaltar que, se eles concordarem em participar dos testes, os testes serão feitos mais rapidamente e terão mais tempo para codificar funcionalidades adicionais (que também precisam ser testadas).

Lembre-se de que o teste do seu código não está abaixo do nível dos desenvolvedores. É parte integrante do processo de desenvolvimento. Não pode ser separado apenas da codificação. Qualquer um pode codificar. Nem todo mundo pode codificar e provar que o que eles codificaram realmente funciona.

Outra maneira de manter os desenvolvedores ocupados é fazê-los trabalhar na codificação de testes automatizados para as funcionalidades que eles desenvolveram no sprint. Esses testes poderiam ser usados para testes de regressão que seriam executados periodicamente.

De qualquer maneira, fazer algo que não foi planejado no início do sprint é um grande não-não. É melhor não fazer nada do que fazer algo que não foi planejado. A funcionalidade que eles escrevem nesses casos provavelmente não atende aos critérios do DoD (Definição de Concluído), pois provavelmente não foi testado bem, pois os testadores estavam ocupados testando o que foi planejado originalmente. Esta é uma maneira infalível de introduzir bugs e deteriorar a qualidade do produto, que envia a equipe para uma espiral descendente de problemas de regressão e mudança de contexto, resultando em estresse, velocidade reduzida e, finalmente, deixando a equipe por causa disso.

— Vladimir Stokic
fonte

Eu diria que os programadores estão testando o código, eles simplesmente não criam testes automatizados. Há uma grande diferença.

— JeffO 9/01/19

Nesse caso em particular, estou disposto a apostar que o único teste que esses programadores fazem é o do IDE. Na verdade, muitos desenvolvedores não compilam a solução em um pacote de instalação, implantam o pacote do zero como o usuário final faria e, em seguida, testam a solução. Na maioria dos casos, isso não é suficiente e é um motivo de deterioração significativa da qualidade.

— Vladimir Stokic

0

Em teoria, todos os membros de uma equipe do SCRUM devem ter o mesmo conhecimento, para que cada membro possa executar todas as tarefas de qualquer outro membro. Caso contrário, você deve espalhar o conhecimento.

Mas, na prática, sempre há algum tipo de especialização. O software pode ser complexo, o membro da equipe possui habilidades diferentes etc. Dividir a equipe em desenvolvedores e testadores é apenas um exemplo (muito comum) de especialização.

Difundir o conhecimento pode levar mais tempo do que a gerência deseja aceitar.

Na minha experiência, você poderia fazer várias coisas:

Não faça a equipe pequena demais. Se, por exemplo, você tem 4 desenvolvedores e 4 testadores, é muito mais fácil mover uma tarefa para outro desenvolvedor ou testador, tendo apenas 2/2 como neste exemplo.
Tente dividir tarefas maiores. Se você tiver mais tarefas menores, será mais flexível.
Defina algumas tarefas opcionais que podem ser realizadas se houver tempo restante.

Essas sugestões podem não ser 100% da teoria SCRUM, mas primeiro você precisa manter o desenvolvimento funcionando. SCRUM é apenas uma caixa de ferramentas.

— Bernie
fonte

0

Parece que você precisa descriptografar sua equipe. Curtiu isso:

   Test.   -------s1 -----------s2
   Dev.        --------s1 -----------s2

Se eu entendi, os caras da automação de teste precisam começar alguns dias antes.

Mas sinto um problema na sua equipe: tenho um problema com os desenvolvedores que não testam seu próprio código. Se o pessoal do teste preparar o teste sem revisar o código, provavelmente estará fazendo apenas testes de caixa preta que não levam em consideração os pontos de decisão do programa desenvolvido. Você está satisfeito com a qualidade do seu software?

— Lucas
fonte