Um desenvolvedor deve aceitar uma estimativa de carga de trabalho feita por uma macro do Excel?

12

Em um novo projeto, um amigo precisava escrever testes nos quais o tempo necessário para escrevê-los era calculado por uma macro do Excel escrita por seu gerente não desenvolvedor.

Em tais circunstâncias, um desenvolvedor deve aceitar a responsabilidade de escrever e executar os testes no tempo calculado? Os resultados desses testes são confiáveis?

Para obter informações, meu amigo se recusou a ser responsável pelas estimativas que não fez, pediu para ter sucesso em outro projeto e foi substituído por um cara inexperiente e inexperiente fora da escola.

project-management productivity testing

— Nelstaar
fonte

7

O que significa "aceitar" uma "estimativa"? Se você estima que levarei 30 dias para fazer algo, o que acontecerá se eu "aceitar"? Por que me importo quanto tempo você estima que levará para fazer alguma coisa? Você pode estimar que eu farei isso em um minuto por tudo que me importo, você estará errado, não eu.

— David Schwartz

2

@ David Aceitar uma estimativa geralmente se refere a revisar as estimativas e garantir consenso. Por exemplo, se uma ferramenta de estimativa paramétrica for usada, os engenheiros de projeto revisarão esses dados para garantir consistência, talvez usando uma segunda metodologia, como Wideband Delphi.

— Thomas Owens

12

Parece algo que deve ser enviado a Scott Adams para um desenho de Dilbert.

— MetalMikester 31/08

1

Contanto que haja uma revisão. Eu neste exemplo particular não havia nenhum.

— Nelstaar

5

Lembre-se: uma estimativa, um compromisso, uma meta e um plano para atingir uma meta são quatro coisas diferentes. Certifique-se de que todos estejam claros sobre o que são essas coisas e quais dessas quatro são as saídas do Excel.

— Nlawalker 31/08/11

14

Depende de como eles parecem sensatos ao desenvolvedor e em que dados / lógica eles se baseiam. (eles podem se basear em dados estatísticos coletados ao longo de vários anos sobre quanto tempo foi necessário - pelo próprio desenvolvedor e / ou por outros - para resolver tarefas semelhantes no passado ... ou eles podem se basear inteiramente no gerenciamento de seu gerente - correto ou incorreto - suposições.)

Idealmente, ele deve discutir com seu gerente que não se pode esperar que se comprometa e assuma a responsabilidade por uma tarefa estimada por outra pessoa.

Recusar-se claramente a se comprometer com as estimativas pode realmente resultar em sua imediata substituição; portanto, é melhor ter uma abordagem mais suave e evitar confrontos diretos, se possível.

— Péter Török
fonte

7

Presumivelmente, a macro está operando em algum tipo de dado de entrada, não é apenas um gerador de números aleatórios? Portanto, para responder sua pergunta, precisamos saber quais são os dados de entrada e o que a macro faz. Sem isso, qualquer resposta é sem sentido.

Ou sua pergunta é realmente sobre aceitar estimativas produzidas por um gerente que não possui experiência relevante? Nesse caso, a resposta é não, você (ou seu amigo) deve produzir suas próprias estimativas e enviá-las ao gerente. Se as duas figuras não corresponderem, elas precisam trabalhar juntas para descobrir o melhor caminho a seguir - talvez concordando em escrever menos testes ou talvez demorando mais para escrevê-las todas.

A recusa em branco não vai ajudar ninguém, e trabalhar em uma escala de tempo que você não pode encontrar também não é divertido, a solução está em adotar uma abordagem profissional e chegar a um compromisso que permita que o trabalho prossiga.

— Steve
fonte

Os testes são fatiados em sub-sub-partes (quase atômicas) e obtém-se uma pequena estimativa.

— Nelstaar

Eu acho que usando esse método, o testador final não vê / testa o quadro geral.

— Nelstaar

1

"Presumivelmente, a macro está operando em algum tipo de dado de entrada, não é apenas um gerador de números aleatórios". Também pode ser aleatório, porque não há como capturar TODAS as variáveis que tornariam esse algoritmo preciso.

— maple_shaft

1

@ maple_shaft: é por isso que eles chamam de estimativa - não é (ou não deveria ser) esperado que seja preciso. Se você estimar usando alguns cálculos no Excel ou com lápis e papel, não faz diferença. Usando o Excel para estimativas faz muito mais sentido do que algumas outras 'técnicas' que tenho visto em uso ...

— Treb

As estimativas do @Treb devem ser tão precisas quanto os dados fornecidos e o status atual do projeto permitirem, considerando o Cone de incerteza.

— Thomas Owens

5

Definitivamente NÃO.

Um programa pequeno, mesmo um programa grande e complicado, não pode estimar quanto tempo levará um trabalho de programação. Consulte Limites matemáticos à estimativa de software para saber os motivos. Um artigo mais longo, revisado por pares, Grandes limites à estimativa de software também está disponível.

Eu também reconsideraria minha opinião sobre o gerente em questão: por que ele ou ela acredita que uma macro de planilha não foi tentada no passado, dado que todo o resto foi tentado para estimar a duração das tarefas de software no passado.

— Bruce Ediger
fonte

1

Ainda não li esses documentos na íntegra (ainda), mas os métodos paramétricos têm sido amplamente utilizados para estimar projetos de software em 15% há mais de 20 anos, assumindo que os dados de entrada são válidos. Além disso, métodos colaborativos como o Wideband Delphi podem (e foram usados) para confirmar a precisão dos modelos paramétricos. Veja Economia de Engenharia de Software (Boehm) para uma discussão sobre métodos paramétricos e aplicação do Wideband Delphi em projetos de software (com e sem modelos paremétricos também).

— Thomas Owens

Eu concordo com Thomas. Embora você não possa prever com precisão todas as tarefas de um projeto inteiro, ao longo de um projeto e usando dados históricos para uma organização específica, você pode entrar no estádio. Algumas tarefas demoram mais e outras mais curtas, mas no final elas são calculadas em média. Especialmente se o projeto for semelhante ao já realizado pela organização. Dito isso, as estimativas não podem dar conta de coisas inesperadas muito ruins, como o hardware / software não funciona como anunciado, novas tecnologias são muito mais difíceis do que o previsto, falta de desenvolvedores, liderança e gerenciamento ruins.

— Dunk

1

Vocês precisam ler e compreender o artigo. Uma macro de planilha simples não tem uma chance de estimar corretamente. Software é matemática, e os sistemas matemáticos às vezes estão sujeitos a um pequeno problema conhecido como incompletude. Garanto que o gerente em questão está enganando a si próprio e que os resultados da macro não se correlacionam com a realidade.

— precisa

1

@Bruce: Tendo usado as fórmulas (incluindo planilhas do Excel) para a estimativa do projeto com sucesso, posso certamente afirmar que nem Thomas, o gerente ou eu estamos necessariamente nos enganando. Como afirmei, cada tarefa individual varia, mas ao longo de um projeto elas tendem a se equilibrar. Descobri que o uso de fórmulas (desenvolvidas e modificadas ao longo do tempo) tem sido muito mais preciso do que as estimativas de desenvolvedores individuais. Geralmente, os desenvolvedores são excessivamente otimistas ou excessivamente pessimistas. Obviamente, as fórmulas só funcionam quando dados razoáveis, a habilidade é certamente um fator.

— Dunk

Eu li esses jornais ontem à noite. Eles vão contra mais de 40 anos de evidência em gerenciamento de projetos e mais de 30 anos de evidência em gerenciamento de projetos de software. Veja iiasa.ac.at/Admin/PUB/Documents/RM-75-071.pdf e sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html

— Thomas Owens

4

Ugh!

Este é um gigantesco "cheiro de trabalho". Essa é uma microgestão incrível.

Se eles não podem confiar em seus funcionários para fazer uma estimativa, em que mais eles não confiam em você?

— ozz
fonte

1

99% dos desenvolvedores não conseguem nem apresentar estimativas ruins com base em algo objetivo e muito menos em estimativas precisas. Portanto, não vejo nada indicando "cheiro de trabalho" porque outra pessoa apresentou uma estimativa. Especialmente se eles usassem dados reais para justificar seus números. Se as pessoas são responsabilizadas pelo cumprimento da estimativa em todas as tarefas, isso é um problema de cheiro no trabalho. No entanto, se a ferramenta subestimou amplamente todas as tarefas, todos os desenvolvedores perderiam as estimativas. OTOH, se todos os demais parecem atender a quase todas as estimativas e outro desenvolvedor nunca atender, esse é um problema de odor do desenvolvedor.

— Dunk

@ Dunk - meu ponto de vista é que o microgerenciamento nesse nível de desenvolvimento de software é um "cheiro de trabalho" e eu não gostaria de trabalhar lá.

— ozz

1

o que você chama de microgerenciamento é a única maneira de fazer negócios em muitos setores. Se você não conseguir apresentar estimativas de custo e cronograma razoáveis para grandes projetos, sua empresa terá um trabalho muito difícil de obter contratos. Ao contrário do ideal ágil, os clientes de muitas indústrias não se comprometerão com dezenas de milhões de contratos em dólares se não souberem o que receberão no final. Eles não ficariam felizes com a idéia de que seu dinheiro acabou, eles têm um produto funcional, mas isso representa apenas 50% do que eles precisam ou desejam.

— Dunk

@dunk - Se você está satisfeito com a administração produzindo estimativas para você, vá em frente. Prefiro que a equipe de desenvolvimento produza estimativas. As estimativas de gerenciamento lúdicas (juntamente com as solicitações em constante mudança, toda uma outra discussão) são o motivo pelo qual muitos projetos de software não conseguem entregar no prazo e no orçamento agendados. Prefiro confiar nas pessoas que fazem o trabalho.

— ozz

Não é uma questão de a gerência fazer estimativas ou as pessoas que fazem o trabalho apresentando as estimativas. É uma questão de extrair estimativas do seu alvo ou tentar basear suas estimativas em alguns dados objetivos. Foi minha experiência que, ao comparar estimativas de gerenciamento com estimativas de desenvolvedor, você descobriria que as estimativas de gerenciamento tendem a resultar em tempos mais longos para serem concluídas. Os desenvolvedores tendem a ser otimistas .....

— Dunk

3

Absolutamente não.

Prometo que o gerente não está tão iludido ao pensar que sua macro do Excel pode prever com precisão estimativas. Não estou nem discutindo o que deveria ser um fato bem conhecido de que existem muitas variáveis envolvidas para prever com precisão algo assim em um algoritmo. Se ele inventou esse algoritmo, deveria patentear e ganhar milhões na minha opinião.

O que realmente está acontecendo aqui é que o gerente está usando essa suposta macro do Excel como um disfarce mal disfarçado para esconder o fato de que ele está forçando expectativas irrealistas e pressão indevida sobre seus desenvolvedores.

Ele sabe que é BS e não se importa, é uma desculpa para reservar recursos em excesso e tentar fazer as coisas mais rapidamente, tornando todos os seus desenvolvedores "sem valor" perpetuamente "ATRASADOS".

Esse gerente parece um idiota explorador.

— maple_shaft
fonte

1

Ah, só porque o gerente está gerando estimativas para os desenvolvedores não significa que eles sejam imprecisos e realmente não podemos tirar essa conclusão sem mais informações. Se o gerente for competente, ele deve reconhecer as configurações realistas e irrealisticamente com bastante facilidade.

— rjzii

1

@ Rob, você está esquecendo o ponto principal que o OP fez, que está sendo mantido com essas estimativas (assumido estritamente porque o desenvolvedor anterior da equipe mencionou "não queria ser mantido com as estimativas" e foi reatribuído). Não há nada de errado com os modelos de estimativa, mas eles devem ser uma diretriz grosseira e nada para "manter os desenvolvedores", o que, infelizmente, eu já vi a gerência fazer para MUITAS pessoas.

— maple_shaft

2

Aqui o problema era que essas estimativas eram movidas diretamente na fatura do cliente. Por que alguns gerentes continuam chamando de estimativas?

— Nelstaar

@ maple_shaft - Sem saber quais são as estimativas, é difícil dizer se elas não eram razoáveis e, portanto, as objeções a serem mantidas contra elas eram válidas. Se fossem estimativas justas (ou seja, "Oito horas para escrever Hello World"), não haverá problema em manter-se além da filosofia.

— rjzii

3

Em um novo projeto, um amigo precisava escrever testes nos quais o tempo necessário para escrevê-los era calculado por uma macro do Excel escrita por seu gerente não desenvolvedor.

Existem modelos paramétricos de estimativa para estimar o tempo de conclusão dos projetos, incluindo projetos de software. Geralmente, a estimativa é para código de produção, mas não vejo por que não pode ser extrapolado para estimar quanto tempo levará para escrever o código de teste. Essas estimativas são tão boas quanto os dados que são alimentados nelas.

Supondo que o método usado seja um modelo de estimativa válido e os dados sejam precisos e válidos, não há razão para que uma boa estimativa não possa vir de uma macro do Excel escrita por um gerente não desenvolvedor.

Em tais circunstâncias, um desenvolvedor deve aceitar a responsabilidade de escrever e executar os testes no tempo calculado?

Nenhuma estimativa deve ser cegamente aceita, sob nenhuma circunstância. Nenhuma estimativa é perfeita, independentemente de como é gerada. Cabe ao engenheiro revisar quaisquer estimativas, identificar possíveis problemas, avaliar seu impacto, discutir e refinar a estimativa conforme necessário.

Os resultados desses testes são confiáveis?

Os testes são tão bons quanto o esforço despendido para projetá-los e implementá-los. Se um testador produzir testes de baixa qualidade, os defeitos passarão pelos testes e chegarão a uma fase posterior do projeto. É lógico que a pressão do cronograma levará a testes de baixa qualidade; portanto, se o tempo for insuficiente para projetar os casos de teste apropriados e depois implementá-los, os testes não serão tão úteis.

— Thomas Owens
fonte

3

Parece que você está fazendo duas perguntas diferentes:

Os resultados desses testes são confiáveis?

O Excel é uma ferramenta como qualquer outra com a qual trabalhamos e em que os cálculos foram escritos não deve realmente afetar os resultados do próprio algoritmo. O fato de a estimativa ser proveniente de uma macro do Excel é irrelevante para saber se os resultados do cálculo (ou seja, a validade da estimativa) são válidos ou não. Se você tem suposições ruins no modelo subjacente, não importa o que você usa para fazer o cálculo, pois as suposições subjacentes estão incorretas.

Em tais circunstâncias, um desenvolvedor deve aceitar a responsabilidade de escrever e executar os testes no tempo calculado?

Se o requisito de que o desenvolvedor faça o trabalho no tempo indicado estiver em contato, não haverá muito o que fazer para argumentar, desde que as estimativas sejam razoáveis. O que leva ao próximo ponto: se os cálculos estão dando um tempo razoável e são semelhantes às estimativas que o desenvolvedor se daria, não há razão para não se opor às linhas de tempo fornecidas. De fato, isso pode ser uma vantagem para os desenvolvedores, pois eles podem influenciar as suposições usadas no módulo, em vez de receberem uma linha do tempo arbitrária.

Se as linhas do tempo parecerem inviáveis para a quantidade de trabalho necessária, obviamente, eles devem levantar essa preocupação e tentar trabalhar com o gerente para obter linhas de tempo mais realistas, mas se a linha do tempo for viável, eles terão dificuldade em se opor a elas.

Em termos de gerenciamento de projetos e estimativa de cronogramas, sim, isso pode ser feito, mas é altamente dependente da natureza do trabalho que está sendo realizado. Você provavelmente verá estimativas mais precisas do tempo necessário para escrever o código de teste de unidade (supondo que o desenvolvedor entenda a estrutura e a tenha escrito antes) do que você para escrever um novo código nos casos de uso em que o código de teste está sendo gravado. para.

— rjzii
fonte

Concordo que este método pode / poderia ser usado desde que exista um diálogo entre os atores do projeto.

— Nelstaar 31/08/11

1

@ Nelstaar - Praticamente tudo o que eu já li sobre gerenciamento e estimativa de projetos envolve um diálogo em andamento e ajustes das coisas com o passar do tempo. Geralmente, as estimativas mais confiáveis têm uma probabilidade associada a elas em relação às chances de atingir o objetivo indicado (ou seja, 90% de chance da tarefa levar 8 horas).

— rjzii

2

Não quero subestimar os testes de escrita, mas o projeto provavelmente já teve vários desenvolvedores escrevendo antes. Se as estimativas são baseadas nesses dados, elas podem ser mais precisas do que o seu amigo assumiu. Desde que seu amigo saiu do projeto, não fez nenhuma tentativa de criar estimativas opostas ou ver se elas poderiam ser concluídas como previsto, nunca saberemos.

Tudo o que ele precisava fazer era concluir um ou dois testes para verificar a precisão da estimativa e retornar ao gerente com um argumento legítimo. Pode haver outros membros da equipe que poderiam ter fornecido feedback sobre a confiabilidade das estimativas ou as consequências de ficar para trás. Às vezes, um gerente precisa dar algo ao seu chefe para manter todos felizes. Os desenvolvedores veem isso como uma falsa sensação de segurança. Talvez se houvesse um movimento para os desenvolvedores fornecerem estimativas e mostrarem vontade de fazer as coisas, o gerenciamento pode desenvolver mais confiança.

O que eu acho é que, se ele pudesse concluir os testes em menos tempo, ele não diria nada sobre isso. Por outro lado, se desculpar de uma prática em que não acredita, pode indicar um alto nível de integridade.

— JeffO
fonte

+1 por fornecer feedback ao trabalhar com as tarefas em relação às estimativas.

— rjzii

1

Resposta fácil e curta:

Você não se importa de onde vem a estimativa.

O que você realmente se importa é a própria estimativa. Concorde ou discorde e explique por que e quanto você estimaria. Isso é o mais importante.

— Clement Herreman
fonte

1

Você deve se importar de onde vem a estimativa. Um modelo paramétrico com entradas válidas e razoáveis, um gerador de números aleatórios, um estudante de ciências da computação no primeiro ano, um engenheiro de software com 5 anos de experiência e menos de 6 meses no domínio e um engenheiro de software que virou gerente de projetos com 25 anos de experiência no domínio, todos têm uma capacidade diferente de produzir uma estimativa efetiva. Isso também remonta a um comentário que fiz sobre uma resposta anterior sobre a responsabilidade ética / profissional de um engenheiro de software em representar, defender e contestar estimativas adequadamente.

— Thomas Owens

Exatamente: o mais importante é discutir a estimativa. É com prazer que aprovo o uso de macros do Excel se as estimativas feitas com mais freqüência estiverem corretas do que um engenheiro de 25 anos de experiência. O importante é a estimativa e a explicação que a leva (carga de trabalho, recursos disponíveis, dificuldade), não por quem ou o que foi anunciado.

— Clement Herreman

Você concorda comigo dizendo que sua resposta está errada? Dadas as mesmas informações (como carga de trabalho, recursos, dificuldade etc.), quem é tão importante quanto o quê e por quê. Tudo se resume a um fator de confiança. Confio no COCOMO (criado e mantido por algumas mentes líderes em estimativa de custos de software) mais do que em uma macro do Excel (feita por alguém com experiência e conhecimento limitados em estimativa de custos, muito menos no domínio do aplicativo). É tudo sobre o quadro geral para estabelecer o quão confiável é essa estimativa.

— Thomas Owens

Não, não, acho que não sou clara o suficiente. Realmente não é importante quem fez a estimativa. O que é importante é a precisão da estimativa. Sempre que recebo uma estimativa, comparo-a com o que estimaria e, em seguida, discuto-a com meu gerente de projeto, se eu concordo ou não. Se o argumento deles for bom o suficiente, concordo com eles e aceito a estimativa. Vejo? Eu nunca falei nem pensei sobre quem estimou.

— Clement Herreman

Como você determina a precisão se não sabe quem estimou e quais métodos eles usaram? Eu poderia fornecer os mesmos dados para duas pessoas - uma é a primeira vez que um estudante de engenharia de software está cursando seu primeiro curso de ciência da computação e o outro é um engenheiro de software sênior com 15 anos de experiência e 5 no domínio. Ambos usam os mesmos métodos de estimativa (não esqueça - muitas vezes, as entradas também são estimativas). O aluno pode dizer que levará 6 meses com 95% de confiança. O engenheiro sênior pode dizer que levará 15 meses com 80% de confiança. Eu confiaria mais no engenheiro sênior.

— Thomas Owens

1

Em teoria, um desenvolvedor nunca deve aceitar uma estimativa feita por qualquer outra pessoa, não importa como foi feita. Um dos motivos é que fornecer uma estimativa mais longa do que seu gerente pode expor imediatamente expõe um possível problema de cronograma ou talvez um mal-entendido sobre o escopo do trabalho a ser realizado.

As pessoas geralmente acham a estimativa do tempo de programação ainda mais difícil do que a própria programação; portanto, se o gerente pode escrever uma macro do Excel para resolver esse problema, ele provavelmente pode criar uma macro para escrever o código (improvável).

Agora, na prática , se você entende o trabalho e as estimativas parecem razoáveis, faz sentido simplesmente expressar alguma preocupação sobre a metodologia de passagem, mas depois concordar provisoriamente em ver se você pode encontrá-las. Mais tarde, se o trabalho estiver demorando mais do que as estimativas, leve isso à atenção dos seus gerentes o mais rapidamente possível. Esteja preparado para discutir os motivos exatos com base em sua experiência real de implementação. Esperamos que, nesse ponto, seu gerente não seja razoável e continue insistindo para que você trabalhe com estimativas geradas mecanicamente.

— PeterAllenWebb
fonte

-1

Uma das mais recentes metodologias de desenvolvimento de software é o ágil , e uma das estruturas ágeis conhecidas é o scrum . Mas nessa metodologia, os desenvolvedores (equipe de scrum) são responsáveis por calcular o tempo necessário para executar uma tarefa ou implementar uma história de usuário.

Eu definitivamente digo NÃO . Porque:

Um gerente não desenvolvedor não pode estimar o tempo necessário para realizar um trabalho
A estimativa do tempo necessário para realizar qualquer trabalho precisa de alguma inteligência humana, que o Excel não possui
Ao aceitar essas práticas de trabalho, o gerente se acostuma progressivamente para substituir os desenvolvedores na estimativa dos tempos. Isso pode resultar em catástrofe. Considere este cenário em que seu gerente diz:

Quero iniciar um novo projeto de venda de bicicletas on-line e sei que leva três semanas para você e John concluí-lo.

— Saeed Neamati
fonte

5

O OP não menciona a equipe de seu amigo usando métodos ágeis. Não acho que as regras ágeis tenham relevância para as equipes que usam outros métodos (ou nenhum método). O senso comum deveria, no entanto :-) Além disso, é óbvio que não foi o Excel quem decidiu sobre as estimativas; ele apenas executou algum cálculo com base em algumas suposições e dados (desconhecidos para nós) e dados (cada um dos quais pode estar correto ou incorreto) . Se eu inserir estimativas para uma determinada tarefa por cada membro da nossa equipe, defina o Excel para calcular a média delas, o Excel está fazendo a estimativa?

— Péter Török 31/08

3

1 e 2 são flagrantemente falsos. Modelos paramétricos de estimativa são amplamente aceitos no gerenciamento de projetos de software e já existem há mais de 20 anos, e qualquer pessoa com treinamento em gerenciamento de projetos (engenheiro de software ou não) pode ser treinado para usar essas ferramentas, assumindo que eles (ou, de preferência, os engenheiros de projeto) ) são capazes de fornecer estimativas precisas das entradas.

— Thomas Owens

3

-1 - Isso não responde à pergunta, possui erros óbvios ("... as mais recentes metodologias de desenvolvimento de software são ágeis") e não parece adicionar nada de relevante. Não sei para que servem os votos positivos ou a resposta aceita.

— Morgan Herlocker

1

certamente não sabemos da questão se a estimativa paramétrica é a norma nesta empresa e / ou se é baseada em um bom histórico para seus negócios; se for esse o caso, por mais que eu odeie dizê-lo, a recusa em fazer o trabalho de acordo com os procedimentos operacionais aceitos pela organização (sem seguir um caminho razoável de questionamento) é imprudente.

— precisa saber é o seguinte

2

@ Thomas, eu concordo, acho que há muito que não sabemos sobre a situação para responder categoricamente Sim ou Não. De qualquer forma, uma recusa direta sem uma boa discussão para garantir que a situação e o raciocínio sejam entendidos raramente é uma boa carreira.

— precisa saber é o seguinte