Fornecendo estimativas ao trabalhar com tecnologia desconhecida?

19

Recentemente, fui apresentado a um novo problema, para fornecer uma estimativa para um projeto no qual devo usar uma estrutura (e potencialmente partes de outra estrutura) com as quais não estou familiarizado. É muito mais fácil fornecer estimativas quando tenho liberdade de usar o que estou familiarizado, mas era como se uma paralisia paralisante pela análise tivesse surgido quando uma estimativa foi solicitada para trabalho em território desconhecido.

Minha solução, em retrospecto, estava errada. Eu apenas comecei a trabalhar.

Como posso estimar melhor projetos e tarefas quando sou obrigado a trabalhar com linguagens / tecnologias / estruturas desconhecidas?

estimation

— Sampson
fonte

2

Fazer uma estimativa de algo que você nunca fez é, com toda a praticidade, impossível de fazer com precisão. Recentemente, fiz essa analogia quando perguntado quanto tempo levaria algo quando houvesse muitas incógnitas: "Imagine que você está andando no campo à noite. Está escuro como breu. Você precisa caminhar uma milha por terra. Você sabe em qual direção você precisa ir, mas você só tem uma lanterna que ilumina três metros.Você não tem ideia do que está à sua frente: campo, rio, montanha.Nada disso, você pode fazer suposições educadas, mas, no final das contas, está sujeito a coisas fora de seu controle "

— Nemi

Isso também depende do objetivo da estimativa. Você está estimando o caso mais provável? Pior caso? Existem prazos rígidos envolvidos?

— precisa

@ David Eu acredito que este seria um caso "mais provável".

— Sampson

18

A resposta padrão do livro ágil é executar um pico. Um pico é uma tarefa pontual para explorar o desconhecido, para que no final você tenha (esperançosamente) informações suficientes para fornecer uma estimativa útil ou tenha uma idéia melhor de quanto tempo precisará para chegar a esse ponto .

Os picos podem durar de 1 hora a vários dias ou até mais. Uma vez que eles são pontuais, não há riscos envolvidos para nenhuma das partes e as despesas são estritamente limitadas.

Idealmente, durante o pico, você identificaria algumas coisas simples que precisavam ser alcançadas com essa nova estrutura e definiria soluções muito simplistas para usá-la. À medida que avança, você aprende, e é disso que se trata os picos.

— wolfgangsz
fonte

Talvez seja uma boa ideia acrescentar que "pico" é uma terminologia do Scrum .

— Jesper

1

Parece uma boa abordagem. No meu caso particular, meu "pico" consistia no próprio projeto. Parecia um uso valioso do meu tempo para realmente usar a tarefa como minha porta de entrada para a familiaridade, em vez de uma tarefa não relacionada.

— Sampson

10

A maneira clássica de fazer isso é por refinamento. Na primeira reunião de planejamento, você diz;

"Eu não tenho idéia - estamos basicamente fazendo pesquisa de software aqui. No entanto, terei uma estimativa melhor até a próxima reunião, dentro de alguns meses"

Então você vai embora e faz a pesquisa. Próxima reunião:

"Parece que vai demorar de dois a quatro quartos. Vamos construir um protótipo que nos permitirá refinar ainda mais os números".

Próxima reunião:

"O protótipo foi mais fácil de construir do que pensávamos. Parece que podemos fazê-lo em 2 quartos, mais ou menos por mês".

e assim por diante. Em cada estágio, a empresa tem a opção de conservar o projeto ou deixá-lo continuar, obtendo estimativas cada vez melhores da data de conclusão.

Isso está descrito muito bem no grande livro de Steve McConnell, Rapid Development , que merece ser bem mais conhecido. Certamente é muito superior a qualquer um dos livros sobre "ágil" que li.

— Neil Butterworth
fonte

+1 Obrigado pela compreensão, @Neil. Também examinarei a sugestão do livro.

— Sampson

2

Você pode fazer pesquisas e ainda apresentar estimativas erradas. Consulte Limites da estimativa de software da JP Lewis e os materiais que acompanham os limites matemáticos da estimativa de software . Não estou dizendo que você não deve se preocupar em estimar ou pesquisar, apenas que você não pode fazer uma estimativa objetivamente precisa e precisa dizer isso junto com a estimativa que chegar.

— Bruce Ediger
fonte

3

As estimativas são, por definição, imprecisas, e parece que muitos gerentes e / ou clientes enfrentam essa realidade.

— wolfgangsz