Software de estimativa de velocidade e precisão

Question

Vamos dizer que você tem um projeto que vai envolver dois aplicativos web (que vai compartilhar DAL/DAO/BO montagens e algumas OSS bibliotecas):

• um ponto complexo de gerenciamento de aplicativo que usa o Windows Live ID para autenticação e também é capaz de se comunicar com vários notificador de serviços (e-mail, sms, twitter, etc.), alvo notificantes sendo cerca de 10% de funcionalidade
• um baixo semi complexo aplicativo de usuário com menos funcionalidades, mas mais robustez que também usa o Windows Live ID para autenticação

Existem dois de nós, com média de estimativa de recursos e podemos não ser capazes de fazê-lo em dois dias, mesmo se quiséssemos ter/para.Pelo menos seria um longe estimativa.

Perguntas

1. Quanto tempo faria/faz normalmente levá-lo para fazer uma confiança/valiosas estimativa?
2. O que você sugeriria para acelerar a estimativa, sem sacrificar o rigor?
3. Quanto a folga (em termos de custo/tempo) você gostaria de adicionar, dependendo da estimativa de velocidade (quando você gostaria de dizer: Eu poderia estimar-lo um pouco mais, porque eu acho que ainda é bastante)

Answer 1

Pergunta interessante. Receio que a resposta seja "realmente depende!" Eu sei que isso não é muito útil (embora seja verdade), então aqui estão alguns fatores:

1) Qualidade e integridade dos requisitos e suas especificações. Isto é, para mim, na maioria das vezes, o assassino de estimativa do projeto. Se você não possui requisitos de qualidade, não possui uma base razoável para uma estimativa. Utilizamos um estilo de desenvolvimento de produtos "Rup-Lite" aqui; portanto, como gerente de engenharia, não darei nada além da estimativa de grão mais grosso até que concluímos nossa fase de "elaboração" e obtemos assinatura do gerenciamento de produtos que Os 80% dos recursos do produto são de fato cobertos com precisão.

2) O escopo e a natureza do produto. Maior/mais caro/mais complicado = substancialmente mais longo para estimar. Passei anos trabalhando em terras de transportadora de telecomunicações entregando soluções que possuem os requisitos normais de transportadora robusta ("5 9" de tempo de atividade exigidos pelo SLA significa que você deve realmente fazer um bom trabalho no design de soluções e na recuperação de falhas!). Nesse tipo de ambiente, com todas as partes móveis em áreas funcionais dos negócios, a estimativa do trabalho dependerá de obter o quadro inteiro ... especificamente, dependências multifuncionais e dependências externas podem ser um assassino real aqui. Dito isto, também construí muitos softwares encolhidos e corporativos também. Nesses ambientes, é muito mais fácil, pois o escopo é tipicamente substancialmente menor; portanto, é mais fácil estimar.

3) Quão "novo" é esse projeto? Quão "novo" é a equipe deste produto ou tecnologia? Quanto mais recente o produto ou equipe, mais e mais buffer você deve alocar.

4) Quão específicos precisamos ser? Se isso é um "palpite", então eu vou me apoiar na minha engenharia leva para fornecer uma estimativa conservadora, então vou fazer isso. Se precisarmos de uma estimativa "real" (por exemplo, uma que é usada pelo meu chefe e que serei responsável por acertar), eu precisaria da contribuição de vários gerentes e membros da equipe diferentes, que precisarão de tempo para analisar os requisitos e conferir entre si.

Isso pode levar apenas alguns dias ou semanas ... tudo depende do tamanho. "Dois ou três dias" é, francamente, não o suficiente para dimensionar nada além do mais trivial dos projetos.

A melhor coisa que você pode fazer para melhorar a qualidade de suas estimativas para melhorar a qualidade de seus requisitos e ser implacável na identificação de dependências ocultas.

Uma coisa final: FWIW, eu tenho feito isso desde 81 e considero que a duração/custo de um projeto mais difícil/confuso com parte perigosa do gerenciamento de engenharia.

Answer 2

Como usamos métodos Agile (Scrum, especificamente), leva cerca de uma hora a mais do que os usuários para priorizar.

Mais tempo não leva a mais precisão.

A parte difícil, então, está fazendo com que os usuários priorizem. Ouvimos essa discussão o tempo todo "Se tudo não estiver concluído a tempo, tudo é inútil". "Exceto pelo componente Xyzzy, que tem algum valor." Esse argumento pode continuar por horas até que seja resolvido que Xyzzy deve ser o primeiro.

Geralmente, tentamos criar sprints de 4 semanas. Os primeiros são complicados porque sempre há algo novo. Após os dois primeiros (ou três), parecemos definir um ritmo constante.

Cada caso de uso tem uma avaliação subjetiva relativamente simples de como o esforço será necessário para finalizá -lo. Qualquer coisa acima de um sprint completo em duração deve ser decomposto. Na maioria das vezes, alguns casos de uso são agrupados em um único sprint.

São maneiras formais de pontuar cada caso de uso para lidar melhor com os problemas de custo e agenda. Não os usamos porque o esforço extra não ajuda.

Após os dois primeiros sprints,

1. Há funcionalidade nova e diferente,

2. Todas as prioridades mudaram,

3. Os detalhes de cada caso de uso foram dramaticamente revisados.

O que significa "precisão" quando você está tentando estimar mudanças no final de cada sprint?

---

Uma lição aprendida. Partes da minha empresa gastam um grandes tempo definindo totalmente exatamente O que será entregue e, em seguida, medindo que eles estão entregando com precisão o que querem.

Os clientes notam isso, e um disse que "gastamos muito tempo entregando o que o contrato diz, mas não é o que precisávamos".

O problema com as estimativas iniciais da empresa é que elas assumem a vida própria. Quanto mais você "investe" na estimativa, mais as estimativas parecem ser uma entrega útil. Eles não são úteis porque geralmente estão totalmente errados. Eles são baseados em suposições iniciais que estão totalmente erradas.

É uma política ruim investir mais tempo na estimativa. As respostas "precisas" não são mais precisas, mas são mais valorizadas por todas as camadas de gerenciamento. À medida que você e o cliente aprendem, você invalida inúmeras suposições e absolutamente deve restabelecer constantemente.

Não faça isso na frente. Se o seu contrato exigir que você o faça com antecedência, verifique se você tem uma provisão de controle de alterações e informe ao cliente que você absolutamente fará alterações à medida que avança. Como Ambas você e o cliente aprendem, vocês dois devo faça mudanças.

Answer 3

Para fazer uma estimativa fiável você realmente precisa para criar uma lista de tarefas a ser feito.Quebrá-lo em histórias/tarefas (mesmo que você não use agile) e avaliá-los.Isso pode levar muito tempo já, especialmente a quantidade de pesquisa (procurar por bibliotecas para fazer isso notificador de material para reduzir o custo).Eu levaria pelo menos 3 dias - no entanto 1-2 semana(s) de som mais razoável para mim.Este não parece ser um projeto pequeno.

Eu não ousaria para acelerar o processo de estimação se você wan não ter um pouco razoável resultados.Estimativas nunca são precisas e que você só vai piorar as coisas.

Uma opção seria fazer um totalmente áspero acho que dentro de algumas horas e, em seguida, começar a trabalhar no que já (por uma semana ou assim).No final da semana, você pode ser capaz de dar uma melhor estimativa com base no seu progresso atual.No entanto, é importante criar uma boa protótipo (que parece uma porcaria, mas tem um pouco de código em todas as regiões).

Answer 4

Bem, uma cotação comum é "o preço estará entre 50% e 400% de nossas estimativas iniciais". A razão pela qual essa citação cresceu é que é verdade. A precisão da estimativa depende em grande parte do seu conhecimento de domínio. Se esta é a 100ª vez que você vendeu um determinado tipo de motor de blog, você tem certeza das estimativas. No entanto, na maioria das vezes, você não tem esse conhecimento aprofundado do domínio (se o aplicativo já existe, por que criar um novo?).

O desenvolvimento ágil se tornou popular porque as pessoas reconhecem amplamente que o tradicional tipo de pensamento "cachoeira" simplesmente não funciona para a maioria dos projetos do mundo real. Você deve aplicar a mesma maneira de pensar em suas estimativas. Obviamente, você precisa de algum tipo de ponto de venda, mas não se esqueça de informar aos clientes que essas informações são muito vagas (e que não importa o que qualquer concorrente dirá a eles, suas estimativas também são vagas).

Você precisa vender iterações e, portanto, também estimar iterações. Tenho certeza de que algum marketing-guy em qualquer empresa saberá como lidar com a papelada e as coisas legais para isso, por isso não deve ser um grande negócio.

Considere um projeto de 5 iterações:

• Comece colocando marcos. Eles estão sujeitos a alterações, mas fornecerão as primeiras estimativas do Vargue para o produto final.
• Iteração do plano #1.
• Estimativa iteração nº 1, ajuste as estimativas totais de acordo.
• Faça iteração #1
• Enxágue / repita até a iteração #5
• Você Terminou :)
• Refletir sobre o seu projeto. Como suas estimativas evoluíram? Razões? Aprender fazendo :)

A maioria dos clientes prefere ter estimativas de parte e entrega de peças do que algum objetivo irrealista que algum processo os vendeu :)

Answer 5

Strayando um pouco da sua pergunta original, mas também é importante aprender com as estimativas que você produziu no passado, mantendo as informações sobre quanto tempo realmente demorou para fazer as coisas que você estimou.

Estimamos 5 dias para produzir essas páginas, na verdade levou 10 dias e etc.

Nas informações de longo prazo como essa (esperançosamente!) Permitirá que você produza estimativas mais precisas.