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
fonte
Respostas:
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.
fonte
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.
fonte
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.
fonte
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ê?
fonte
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.
fonte
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.
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 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.
fonte
Parece que você está fazendo duas perguntas diferentes:
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.
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.
fonte
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.
fonte
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.
fonte
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.
fonte
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:
fonte