Estimativa de tempo de uma investigação de bug complexa (não direta) [duplicado]

14

(Não é uma duplicata: a investigação de bugs é muito mais não-determinística do que uma tarefa de desenvolvimento definida onde as coisas a serem feitas são especificadas. A investigação é sobre restringir um enorme espaço de pesquisa, que é diferente Não é possível comparar erros de corrupção de memória , C / C ++ comportamentos indefinidos e corridas de dados de vários segmentos para tarefas de desenvolvimento com escopo limitado ).

Não é a primeira vez que meus superiores pedem uma estimativa quando se trata de investigação de erros. Assim como foi uma tarefa de desenvolvimento delimitada.

Eu costumo preferir uma escala de complexidade. Algo como: Fácil , Não tão fácil , Obscuro , Difícil e Muito Difícil . E dar uma estimativa de tempo apenas para investigações fáceis.

Para investigações simples, eu concordo que é viável. Mas não tenho sucesso em explicar-lhes que uma investigação complexa é um processo de ciclagem:

  1. Razão sobre os fatos, o código, o problema
  2. Crie hipóteses
  3. Encontre maneiras de medir a hipótese por fatos (rastreios, logs, depuração ...)
  4. Se os fatos forem claros e a hipótese for falsa, reinicie em 1.

É um processo bastante científico / racionalista, de fato.

Que outros argumentos eu poderia contar, para explicar a incerteza no próprio processo de investigação de bugs?

    
por Stephane Rolland 02.06.2015 / 15:07
fonte

6 respostas

8

Isto não é praticamente útil para você, mas eu não iria afundar ao nível de explicar para colegas de trabalho não técnicos porque certas tarefas técnicas são mais difíceis do que outras. O ponto de contratar especialistas para tarefas de programação que são melhores em coisas técnicas e piores em negócios ou em gerenciamento do que seus empregadores é que eles são melhores neles. Em grande parte, entender por que um defeito surge é capaz de consertá-lo e, em menor grau, de evitar erros semelhantes no futuro.

Brevemente e brutalmente, se os seus superiores pudessem entender por que algumas tarefas de depuração são tão difíceis, elas seriam capazes de executar essas tarefas sozinhas - o que elas não são, desde que elas contrataram você. É difícil para qualquer um aceitar que existem distinções que eles não podem apreciar, então não há razão para explicar a um gerente que você está tendo dificuldades que você não pode explicar para ele. A melhor coisa que você pode fazer é subir ao seu nível de visão e dizer a ele: "Olha, eu sei que isso soa coxo, mas não posso te dizer muito bem quanto tempo isso levará não importa qual seja o incentivo" . Uma vez que você disse isso nos casos em que é verdade, e eles viram que é verdade (porque o seu esforço fez variar imprevisivelmente), talvez < Eles vão começar a acreditar em você quando você disser que você não sabe alguma coisa. Mas eu não iria segurar minha respiração. Dizer "não sei" a algo em um ambiente competitivo é muito difícil de fazer, e muitos profissionais evitam fazê-lo a todo custo; e assim eles tendem a acreditar que não é verdade quando alguém está dizendo isso também. Estranho, mas (na minha experiência anterior) é verdade demais.

    
por 02.06.2015 / 15:14
fonte
10

Dependendo da gravidade do problema e da urgência de corrigi-lo, veja se eles concordarão com um esforço "time-boxed". Diga, dois dias investigando / tentando recriar o problema. Se você não tem até lá, você relatará o que você eliminou como problema e verá se eles querem que você continue cavando.

Para problemas menores, eles provavelmente concordarão com um curto período de tempo, contanto que o trabalho continue em outros assuntos ou recursos. Para os principais, especialmente aqueles com maior visibilidade, o cronograma permite que eles recebam relatórios regulares sobre seu esforço.

    
por 02.06.2015 / 19:04
fonte
6

Combine duas abordagens: a "estimativa de tempo fixo" e a abordagem "não sei" sem dizer literalmente que não sei. Vamos enfrentá-lo, se você soubesse exatamente o que está causando o bug que você não teria escrito dessa forma em primeiro lugar (sim, eu sei que nem sempre corrigir o nosso próprio código, mas não está limpando a bagunça de outra pessoa ainda pior?).

Adquira o hábito de responder às solicitações de cotação de tempo do bug com: "Vou dar uma olhada e informar quanto tempo levará." As pessoas querem saber que você se importa o suficiente, demonstrando que está tomando medidas para resolver o problema e priorizando a tarefa de forma adequada. Fazer promessas (e elas são promessas em sua mente) que você não pode cumprir diminuirá seu nível de confiança em você.

Não se esqueça de reorganizar seus outros compromissos. Em termos simples, não posso corrigir seu novo bug encontrado e entregar um novo recurso ao mesmo tempo. Qual deles você quer que eu faça primeiro? Com sorte, eles vão tirar o vírus do caminho, mas você nunca sabe.

Eles não querem uma explicação técnica. Quando usuários não técnicos perguntam: "Por que isso vai demorar tanto?" eles não querem necessariamente uma resposta técnica e eles realmente não querem detalhes. Ao dedicar um tempo para investigar o erro e depois fornecer uma estimativa de tempo, você também pode resumir a solução. Pode haver várias áreas do aplicativo que precisam ser alteradas (a dívida técnica já está vencida), a atualização de outras tecnologias, etc.

    
por 02.06.2015 / 15:38
fonte
2

Eu sugiro dar um intervalo como estimativa.

Por exemplo, para questões fáceis, pode ser "entre 15 minutos e três horas", para problemas difíceis, pode ser "entre duas horas e uma semana".

Isso deve mostrar seu ponto de vista. Se eles perguntarem por que sua melhor e melhor estimativa de caso é tão diferente, você pode começar a explicar as coisas que mencionou em sua pergunta (processo cíclico, etc.) e até mesmo dar exemplos para o melhor e pior caso. / p>     

por 02.06.2015 / 20:49
fonte
1

A procura de uma solução para um problema pode ser muito parecida com a procura de qualquer outra coisa que esteja faltando. Pegue as chaves do carro, por exemplo. Se os meus não estão na prateleira onde eles pertencem, eu verifico o outro lado da prateleira & um par de bolsos e geralmente encontrá-los em minutos.

Quando minha esposa perdeu as chaves um tempo atrás, tivemos que esperar que a neve caísse primeiro. Isso levou alguns meses.

Eu acho que você acertou com "easy", "hazy" e "hard". É fácil encontrar um bug quando você pode restringir rapidamente seu espaço de pesquisa a algo razoável. É difícil quando você não pode.

Todos os seus superiores realmente precisam saber que essa é uma prioridade, você está trabalhando metodicamente / você tem um plano de pesquisa e ainda não está sem ideias.

    
por 02.06.2015 / 15:51
fonte
0

A estimativa de tempo para conclusão de tarefas no desenvolvimento de software é de fato uma arte obscura. Eu acho que seus argumentos são bons, mas você esqueceu um crítico:

Por mais que você pense que vai demorar, multiplique isso por dois.

Eu descobri que isso funciona muito bem. As coisas sempre levarão mais tempo do que você pensa, especialmente no desenvolvimento de software.

    
por 02.06.2015 / 15:12
fonte