Gerenciamento de processos Scrum - dicas, armadilhas, ideias [fechado]

Question

Já faz algum tempo que faço scrum com uma equipe, mas as coisas parecem complicadas por alguns motivos.Estive pensando em como eles poderiam ser alterados e tenho algumas perguntas que gostaria de levantar aqui.

Primeiro, qual deveria ser o papel dos testadores, designers e não desenvolvedores como um todo no processo Scrum?Se eles forem iguais aos outros membros da equipe, surgirão alguns problemas.Designers e testadores geralmente trabalham em uma tarefa após a conclusão do desenvolvimento, portanto, eles não podem planejar adequadamente um sprint devido a essa dependência.

Em segundo lugar, temos prazos.Eles são rígidos e têm muito impacto na priorização.O resultado final são alterações no backlog no meio de um sprint devido a alterações de prazo ou resultados ruins no final do sprint.Também temos muito trabalho não técnico, como suporte ao cliente, que deve ser feito entretanto e não pode ser planeado, pois varia muito.Então, estou pensando que a estrutura, a cultura e as práticas da equipe não são compatíveis com o Scrum.Scrum para mim é uma ferramenta de gerenciamento de processos para equipes que trabalham no desenvolvimento de um único produto de software.

O que vocês acham de aplicá-lo em cenários mais específicos e complicados?Você tem alguma experiência para compartilhar?

Answer 1

Em geral, testadores e documentadores (e outros não-desenvolvedores) são todos membros iguais de uma equipe scrum.A ideia por trás disso é minimizar o risco.

Exigir uma definição de pronto, que inclua um produto potencialmente entregável, totalmente testado e documentado, força o projeto a ser reunido no final de cada sprint.

Se o teste não começar até APÓS o desenvolvimento.feito, o que acontece é que muitos bugs são descobertos depois que os desenvolvedores concluem uma tarefa.Então agora você tem que consertar esses bugs, e isso é muito lento e caro porque os bugs interagem e porque a regra geral é:"A despesa de consertar um bug cresce exponencialmente com o tempo". Os insetos que você pega cedo são baratos e fáceis de corrigir, os bugs tardios são um pesadelo.

É por isso que você deseja que os testes (e a documentação) acompanhem o desenvolvimento.E agora você deveria estar se perguntando como!O teste é lento, como diabos ele pode acompanhar o desenvolvimento?

A resposta é automação, ou seja, o SCRUM sempre fica em cima do XP ou Agile, ambos exigem excelente cobertura de testes unitários e TDD.Aqui está outra pegadinha a ser observada.Os desenvolvedores de recursos devem ser aqueles que escrevem testes de unidade e de sistema.Toda automação de testes deve ser feita pelo desenvolvedor de recursos.equipe.Alguns lugares dividem o desenvolvimento de recursos.do desenvolvedor de automação.e isso é ruim.

OK, agora você tem ótimos testes automatizados e os executa PELO MENOS uma vez por dia.E obviamente você pratica integração contínua, certo?Isso reduz enormemente a carga de trabalho dos testadores.E é assim que os testes podem acompanhar o desenvolvimento.Mais uma coisa, os testadores agora trabalham em coisas realmente difíceis e criativas que são impossíveis ou muito difíceis de automatizar. Cada vez que encontram um bug dessa forma, tudo o que for necessário para expor o bug é automatizado e se torna parte dos testes diários de regressão. .Ufa, essa é uma resposta longa!

Agora vamos à segunda parte da sua pergunta.Scrum é uma questão de disciplina.Sprints são curtos e alterações no backlog durante um sprint NÃO devem acontecer.O trabalho não técnico deve ser ramificado para uma equipe de suporte ao cliente e eles podem fazer Scrum em torno disso.Você está certo quando diz que parece que sua cultura e práticas são incompatíveis com o scrum.

Na minha experiência, a transição para Scrum/Agile é um processo muito doloroso e estressante e a maioria das tentativas de transição falham.Uma das chaves para o sucesso é ser um defensor do Scrum/Agile na equipe executiva.Pela sua descrição parece que você não tem um.

Existem custos e benefícios no Scrum, mas se você estiver fazendo isso mal, poderá incorrer em custos com pouco ou nenhum benefício.Se você está praticando o Scrum de maneira errada e errada, talvez seja melhor não praticar o Scrum.

Answer 2

Primeiro, qual deveria ser o papel dos testadores, designers e não desenvolvedores como um todo no processo scrum?Se eles forem iguais aos outros membros da equipe, surgirão alguns problemas.Designers e testadores geralmente trabalham em uma tarefa após a conclusão do desenvolvimento, portanto, eles não podem planejar adequadamente um sprint devido a essa dependência.

Se os designers e testadores não conseguem planejar um sprint devido a uma dependência de desenvolvimento, isso significa que seu desenvolvimento não está sendo planejado corretamente.Esse é um problema que precisa ser corrigido.

Sua equipe deve ser capaz de dizer “A Tarefa B exige que a Tarefa A seja realizada primeiro.A tarefa A levará 8 horas e a tarefa B levará 4 horas".Se as estimativas de suas tarefas forem precisas, as dependências não serão um problema.

Em segundo lugar, temos prazos.Eles são rígidos e têm muito impacto na priorização.O resultado final são alterações no backlog no meio de um sprint devido a alterações de prazo ou resultados ruins no final do sprint.Também temos muito trabalho não técnico, como suporte ao cliente, que deve ser feito entretanto e não pode ser planeado, pois varia muito.

Se isso estiver acontecendo, o problema é que você não está praticando Scrum.A única maneira de o Scrum funcionar é se a administração aderir completamente ao processo.Isso significa deixar seus desenvolvedores sozinhos por 30 dias enquanto trabalham em seu sprint planejado e adicionar novos trabalhos por meio dos métodos que o Scrum possui para fazer isso.Você adiciona itens da lista de desejos ao backlog do produto e, durante o planejamento do sprint, os desenvolvedores e as partes interessadas concordam sobre o que será trabalhado no próximo sprint.

Se você consistentemente tem problemas de suporte ao cliente interrompendo o desenvolvimento normal, então você deve considerar seriamente dividir a equipe e ter um grupo dedicado a trabalhar no desenvolvimento em Scrum e outro grupo que cuida dos problemas de suporte ao cliente.Você poderia então alternar as pessoas para frente e para trás no final de cada sprint.

Answer 3

Você realmente não deve adicionar alterações ao backlog do Sprint com base nas alterações levantadas no meio do Sprint; elas devem apenas ir para o backlog do produto e serem ignoradas até que o Sprint termine.

Você deve alinhar seus prazos com os Sprints.Acho aceitável retirar uma tarefa no meio do Sprint, mas não introduzir uma nova.

Se você descobrir que está adicionando muitas tarefas no meio do Sprint, seus Sprints provavelmente serão muito longos.Lembre-se de que você pretende cerca de 20 dias de trabalho em cada Sprint, ou mais, e você começará a ter os problemas que está descrevendo!

Os testadores são importantes para qualquer processo Agile, mas não se enquadram no Scrum, onde a teoria é que qualquer pessoa sem uma tarefa ativa escolhe a próxima tarefa.Tentar escolher associações entre tarefas e pessoas começa a entrar no agendamento, o que tudo estava tentando evitar!

Os testadores, se trabalharem próximos aos desenvolvedores, podem ajudar a determinar se um item de trabalho está realmente concluído!

Answer 4

em primeiro lugar, você não está usando Scrum, pode estar usando algumas práticas de Scrum, mas não todo o processo.

Designers e testadores geralmente trabalham em uma tarefa após a conclusão do desenvolvimento, portanto, eles não podem planejar adequadamente um sprint devido a essa dependência.

Não há relação entre dependência de tarefas, o que raramente ocorre, e capacidade de planejar adequadamente.No planejamento do sprint, a equipe deve estimar as histórias referentes à Definição de Feito.Se incluir, e realmente deveria, projetar e testar a história, a estimativa do esforço necessário para cumprir os critérios de aceitação da história deve incluir tarefas de design e teste.

O resultado final são alterações no backlog no meio de um sprint devido a alterações de prazo ou resultados ruins no final do sprint.

Parece que a duração do seu sprint é maior do que o necessário.Por que você não tenta torná-lo mais curto?Uma boa duração do sprint é aquela que você pode comprometer para manter as alterações fora do sprint.Acho que 1 semana funcionaria.

E esse comportamento demonstra que o seu Scrum Master não está fazendo seu trabalho corretamente, pois não está removendo os impedimentos.