Venho testando há 12 anos, trabalhei na Naumen e Yandex. Agora, lidero o departamento de testes de 150 pessoas no circuito e continuo trabalhando como testador em uma das equipes.
Após uma análise de desempenho de seis meses, gerentes de equipes diferentes informaram quais objetivos estabeleceram para seus testadores. Um em cada cinco teve o seguinte: "Aprenda a avaliar os prazos para as tarefas de teste". Muitas vezes, essa "avaliação de prazo" é desejada não apenas pelos testadores, mas também pelos desenvolvedores.
Estimativa de termos em 95% dos casos. Obrigado xkcd .
Considero absolutamente prejudicial praticar quando o contratante avalia os prazos para uma tarefa separada. Isso está diretamente relacionado à falta de educação do sistema e aos baixos requisitos para os gerentes.
Agora vou explicar como isso funciona.
Sobre os trabalhos dos clássicos
Maxim Dorofeev - O efeito dos prazos de endireitamento
Cito o livro " Jedi Techniques ", embora se possa citar a lei de Parkinson :
Um homem vem até nós, coloca uma tarefa e pergunta quanto tempo pode levar para completá-la. Avaliando a tarefa, é claro, queremos nomear o período em que chegaremos a tempo, com certeza, e como muita coisa pode acontecer (e suspeitamos que algo acontecerá com certeza), colocamos uma certa margem de tempo na avaliação.
Em vez de começar imediatamente a concluir a tarefa, estamos “lidando com o urgente”, uma vez que “essa tarefa ainda não está queimando” - também temos o estoque acima mencionado.
A tarefa começa a "fumar" e prosseguimos. Se nada aconteceu, então o fazemos a tempo, mas se algo aconteceu ... Já gastamos a reserva nesse "algo" e, como resultado, estamos atrasados.
Como resultado, qualquer prazo nomeado como prazo se torna um prazo antes do qual a tarefa não será concluída. Isso leva a conseqüências particularmente desagradáveis durante o trabalho em equipe, quando é necessária a cooperação de diferentes especialistas e diferentes departamentos para concluir uma tarefa ou projeto.
O homem como retificador (e diodo) é uma ilustração das Técnicas Jedi. Há um vídeo também.
Na quinta parte do primeiro capítulo, há links para estudos sobre a dependência da produtividade daquele que realizou a avaliação do tempo.
Em resumo: o fato da avaliação afeta os termos para pior em cerca de 40%.
Eu recomendo a leitura. Todos os fatores listados no quinto capítulo ainda são relevantes.
No ano passado, ouvi duas vezes dos gerentes: "Aprendemos a cumprir prazos para avaliar tarefas, agora esse programador ou testador não viola os prazos que nomeei".
Eu acho que esse é um problema extremamente sério, pois isso significa que esse programador ou testador exagera sistematicamente e deliberadamente os prazos, trabalha com relaxamento e mente para o gerente . No mundo, existem variações e a não violação de estimativas de tarefas específicas significa que a avaliação dessa pessoa está sempre à direita da curva de distribuição do termo real do trabalho.
Os autores mencionados no título afirmam que a única maneira verdadeira de estimar os prazos é através de métodos estatísticos. Um pacote de tarefas típicas deve ser avaliado. "Temos tarefas diferentes?" Isso é mentira. No intervalo de um ano, não haverá tantas tarefas diferentes. Como regra geral, essa afirmação é um sinal de falta de reflexão sobre o processo e falha na execução de exercícios: decomposição, MVP, protótipos, padronização.
Sobre clientes que exigem prazos
Em primeiro lugar, deve-se notar que na maioria das vezes - e isso por si só é engraçado - nada depende da resposta do contratante, porque já existem prazos. O gerente não está interessado em quanto tempo faremos a tarefa , mas se chegaremos a tempo dentro do prazo e o que chegaremos a tempo . Essas são perguntas diferentes e precisam ser respondidas de maneiras diferentes.
Como regra, a resposta para a pergunta “chegaremos a tempo no prazo” é analytics e MVP, uma infraestrutura de desenvolvimento de alta qualidade e o tamanho da dívida técnica, ou seja, a dificuldade de refatoração e a presença de testes de regressão automática.
Mais uma vez: a estimativa de tempo evita que o artista alcance o prazo.
Em segundo lugar, há uma série de exercícios em desenvolvimento. Nem todos eles são simples. Eles não fornecem diretamente uma resposta para a pergunta "quando o recurso estará pronto". No entanto, eles reduzem o tamanho da entrega, reduzem a complexidade do desenvolvimento e teste e, finalmente, reduzem a variabilidade dos termos.
- MVP
- decomposição de tarefas
- limitação do trabalho inacabado (o programador não assume novas tarefas até que as antigas sejam publicadas)
- versões separadas de refatoração e recursos subsequentes
- liberação separada do backend, frontend e outras partes do produto
- lançamentos canários
- uso de sinalizadores de recursos
- capacidade dos testadores de separar defeitos importantes de não importantes
- capacidade de uma equipe se libertar com defeitos sem importância
Se a equipe executar esses exercícios e o gerente estiver qualificado, para responder aos clientes, ele não precisa exigir que os executores especifiquem um prazo. Se os exercícios não forem realizados, provavelmente qualquer termo especificado pelo gerente será uma mentira.
Sobre gerentes incompetentes
É muito fácil confundir a estimativa de termos (quando a tarefa será concluída) e a estimativa dos custos de mão-de-obra (quanto tempo leva para desenvolver um recurso). Estimativa de termos, como já descobrimos, se não for prejudicial, pelo menos inútil. Mas a avaliação dos custos do trabalho é um exercício bastante útil.
A necessidade de avaliar os custos de mão-de-obra quando a tarefa é concluída nos faz os exercícios úteis acima: principalmente, a decomposição dessa tarefa.
Mas devemos lembrar que a avaliação dos custos de mão-de-obra em uma equipe com um gerente incompetente se transforma muito facilmente em uma estimativa dos termos . Envolve um milhão de distorções cognitivas e uma falta de compreensão de como as cadeias de produção funcionam.
Exemplo de vida:
- Quanto tempo você gastará nesse recurso?
- Vou escrever uma semana e meia e corrigir bugs por três dias.
- Ou seja, em 3-4 semanas estará pronto?
Ou seja, a diferença entre “eu passarei o dia nessa tarefa” e “a tarefa estará pronta em um dia” é múltipla e fundamental.
Você ensina a vida e o que você conseguiu?
Sim, vamos falar sobre mim e minha equipe. Realizamos com êxito alguns dos exercícios listados, alguns aprendem a fazer. Alguns não são, e isso é triste.
Penso que aprendemos a limitar o trabalho inacabado, a executar versões preliminares de refatoração e a separar os erros importantes dos sem importância.
Estimativa de termos para teste, fazemos isso. Dividimos as tarefas em pequenas, grandes e outras. Cerca de metade das pequenas tarefas são realizadas pelo testador em serviço nas horas vagas. Uma pequena tarefa é marcada no YouTrack com a tag "por uma hora" e é realizada em uma abordagem (de meia hora a duas horas), se não houver complicações.
Grandes tarefas são marcadas com a tag "projeto" e fica imediatamente claro que isso simplesmente não acontecerá. Cada tarefa grande possui um lead de recurso, cuja tarefa é garantir que os exercícios da lista acima sejam concluídos.
As tarefas restantes não são marcadas de forma alguma. Os exercícios da lista começam a ser realizados se o tempo necessário para o trabalho exceder uma margem arbitrariamente escolhida e variada de 2 semanas.
Se uma tarefa urgente estiver na fila, você precisará descartar tudo e fazê-lo. Não há necessidade de avaliar. No entanto, será útil esclarecer o prazo para entender quais defeitos e defeitos podem ser liberados. Existem menos de dez por cento dessas tarefas urgentes.
A última vez que fui atrasado no trabalho, a pedido de um gerente, para liberar uma tarefa urgente, há mais de dois anos. Antes disso, algumas vezes, em 2015 e em 2016.
PS Uma das habilidades mais importantes em nosso trabalho é não fazer lixo desnecessário. Incluindo não se envolver em "estimativa de termos" e auto-engano. O que também desejo a você.
(Assine nosso canal no Telegram , é legal por lá.)