Brainless
2015-07-01 07:54:23 UTC
Durante nosso último projeto, nossa equipe composta por jovens engenheiros de software fez um produto que contém muito mais bugs do que outras equipes. Temos um engenheiro sênior que fazia parte da equipe, mas não está muito envolvido no processo de desenvolvimento, pois foi promovido a gerente. Ele acabou de revisar o código da equipe pela primeira vez e encontrou muitos problemas.
Esta equipe mostrou grandes capacidades no passado, mas o resultado do nosso último projeto me deixou preocupado. O que os membros da equipe disseram sobre este último projeto:
- É mais complicado do que os anteriores: muitas mudanças de requisitos, interações complexas com o banco de dados, UI complexa, novas tecnologias ...
- Tempo insuficiente, muita pressão
- Difícil de entender o requisito (no entanto, garantimos que todos entendessem os requisitos completamente durante o projeto)
I confie na minha equipe, eles são pessoas muito boas. O que posso fazer para melhorá-los?
Como você está gerenciando bugs? Como você está gerenciando o ciclo de desenvolvimento? Qual é a prioridade da qualidade? Se você não consegue medir, você não consegue administrar.
A maioria dos bugs apareceu no final do projeto. O engenheiro sênior disse que era devido a um código ruim.
Você está fazendo revisões de código? Programação em pares? Talvez a utilização de uma metodologia como o Agile também possa ajudar, se você ainda não estiver. Em vez de um esforço de teste monolítico no final, você pode testar após cada iteração e enviar os bugs de volta ao backlog para serem resolvidos.
Estamos usando o Agile. A equipe tem feito revisões de código regularmente (sem o engenheiro sênior). A opinião deles sobre o código contradiz a opinião do engenheiro sênior. Para eles, o código está ok. Teste de controle de qualidade a cada iteração e, como eu disse, é somente no final que aparecem muitos bugs.
Você precisa demitir seu controle de qualidade ou testadores. Por que eles não detectaram os bugs durante cada iteração? Ou sua equipe apressou a última iteração e apresentou os bugs?
Eu prefiro acreditar que a última iteração foi apressada. O controle de qualidade fez um ótimo trabalho no passado, encontrando bugs não triviais. Eles foram elogiados por outras equipes.
Você pode rastrear quando esses bugs foram introduzidos? Isso deve lhe dar uma indicação da causa para que você possa tentar planejá-la. Não tenha medo de gerenciar para cima (o mais cedo possível) se os prazos forem muito curtos e apresentar o risco de bugs adicionais!
O que você prefere acreditar não é a questão. Os testes podem ter sido inadequados - geralmente são. Você precisa voltar e ver o que os insetos eram, quando foram introduzidos e por que não foram detectados. E se você estiver realmente usando o Agile de maneira adequada, sempre deve haver um último bem conhecido que você pode lançar quando chegar a data de lançamento, mesmo que não tenha todos os recursos - ou você pega a data e desliza; .
Você tem um Analista de Negócios na equipe responsável pelos requisitos e casos de uso? Você também tem um gerente de projeto na equipe atribuindo as tarefas e controlando o cronograma (bem como reportando à gerência sobre o quão bem a equipe está cumprindo o prazo)?
Observe que a linha de assunto realmente deve ser como _ajudá-los_ a melhorar a qualidade, especialmente se você está argumentando que não foi inteiramente culpa deles ...
Eu sugeriria que "faça-os melhorar" é o tom errado. Se você garantiu que todos entendessem os requisitos completamente durante o projeto, por que a equipe está dizendo que os requisitos são difíceis de entender? O engenheiro sênior revisou o código apenas recentemente. Esta equipe demonstrou fortes capacidades no passado. Parece que você quer culpar a equipe em vez de consertar o processo. Vejo que você está em Pequim, então pode ser apenas uma questão de idioma. Faça é força.
Resposta irônica: P: "Como você faz os jovens engenheiros melhorarem a qualidade de sua produção?"R: "Da mesma forma que você faz os engenheiros antigos melhorarem a qualidade de sua produção."Outros aqui estão dando a entender que você está colocando a culpa no lugar errado, mas vou direto ao ponto: a idade não é o problema.É possível que a * experiência * seja um fator;a experiência geralmente tem uma correlação com a idade, mas não culpe os juniores só porque eles são juniores.Isso costumava me irritar muito quando era mais jovem, e geralmente provava que meu trabalho não era o problema.