Regra noventa e noventa na prática


24

Os primeiros 90% do código representam os primeiros 90% do tempo de desenvolvimento. Os 10% restantes do código representam os outros 90% do tempo de desenvolvimento.

- Tom Cargill, Bell Labs

O que isso significa exatamente na prática? Que os programadores realizam uma quantidade substancial de trabalho e estão dando 180% de si mesmos ou?


2
Todos sabemos que 100% é redefinido excedendo-o ou 1,8 vezes a quantidade conhecida. Nesse caso, no entanto, eu diria que é provavelmente exagero. O segundo noventa por cento existe para torná-lo memorável e adicionar um final ao final da citação.
precisa saber é o seguinte

11
A estimativa para o tempo de desenvolvimento muda no meio da frase.
precisa

180% é a quantidade de tempo e orçamento que o projeto acaba custando.
Agent_L 8/16

11
Eu acho que é perfeitamente claro o que esta pergunta está fazendo, apesar da sentença final embaraçosa.
Matthew James Briggs

2
Esta citação deve ser lida como uma piada, nesse contexto, faz sentido. É dizer os últimos 10% vai demorar muito mais tempo do que você imaginou
Richard Tingle

Respostas:


40

Imagine o seguinte: quando você começa a trabalhar em software, pode escrever grandes quantidades de código em relativamente pouco tempo. Esse novo código pode adicionar uma enorme quantidade de novas funcionalidades. O problema é que, muitas vezes, essa funcionalidade está longe de ser "concluída", pode haver erros, pequenas alterações (pequenas em pequenas empresas) e assim por diante. Portanto, o software pode parecer que está quase pronto (90% pronto), porque suporta a maioria dos casos de uso. Mas o software ainda precisa de trabalho. O objetivo desta regra é que, apesar de o software parecer estar quase pronto, a quantidade de trabalho para colocar o software no estado de funcionamento adequado é tão grande quanto chegar ao estado "quase pronto". Isso ocorre porque a correção de erros geralmente consome tempo, mas não produz muito código.

O problema é que a maioria dos desenvolvedores estima colocar o software no estado "quase pronto", porque isso é relativamente simples comparado à estimativa do esforço total que o software levará.


3
Uma grande parte do motivo da ilusão 90-90 é que os engenheiros de software costumam visualizar o caminho do sucesso - entregar os casos de erro e exceção é uma reflexão tardia. Se o design original não levar em conta os casos de erro de baixa probabilidade, provavelmente precisará de revisão antes que o software possa ser chamado de concluído.
Rumbleweed

11
+1 mas eu sinto o segundo parágrafo precisa de algum texto em negrito, porque essa é a parte realmente importante da lição :)
Bob Tway

20

É uma referência a um cenário comum, que infelizmente ainda ocorre hoje:

  1. A equipe é solicitada a estimar (ou seja, adivinhar) a quantidade de trabalho necessária para escrever todo o código,
  2. O projeto prossegue com inúmeras pressões internas e externas para "manter o tempo e o orçamento",
  3. Portanto, para uma porcentagem significativa do projeto, "no alvo" é relatado. Isso geralmente é agravado ao escolher as tarefas fáceis primeiro para garantir um bom progresso.
  4. Então, em algum momento, chega-se a um ponto crítico em que a realidade precisa ser aceita: o projeto não será concluído no prazo e a data de lançamento será adiada (muitas vezes muitas vezes).

"90%" é uma cifra arbitrária, mas mostra bem o ponto: estimativas são suposições e provavelmente estarão erradas (geralmente muito erradas) e a natureza humana garante que quase sempre subestimamos, de modo que as coisas excedam.


14
O que está sendo chamado de "ágil" não ajuda a resolver o problema; simplesmente o distribui entre itens menores, onde exatamente a mesma proporção ocorre em uma escala absoluta menor, mesmo se a Cargill estivesse sendo ridícula. O ponto principal é que todo projeto tem algumas pequenas coisas que consomem muito do tempo de desenvolvimento.
Blrfl

3
@Blrfl A resposta não implica que o ágil resolva o problema de as estimativas serem difíceis, mas atenua suas conseqüências fazendo estimativas menores.
Eric

Acho que não é apenas um problema de gerenciamento de recursos. É muito fácil criar protótipos rápidos e sujos dos 90% de um projeto, mas os 10% restantes levarão muito tempo, porque geralmente é aqui que nos preocupamos em estar em total conformidade com os requisitos iniciais. Estou em sistemas embarcados e posso dar uma demonstração de um produto ao vendedor meses antes do lançamento do produto, e ele quase não vê diferença entre a demonstração e o produto final, mas com certeza a demonstração não pode ser entregue. Bugs, otimização, recursos avançados, consumo de energia, esse é oother 90%
Tim

Confie em mim mesmo com a merda do Agile que bate no ventilador e explode!
Jonh

2
Removida a reflexão tardia sobre o ágil, pois está claramente distraindo as pessoas do ponto principal da resposta.
David Arno

7

Eu ouvi uma versão diferente disso (também chamada de "regra 90-90") que fica assim:

Depois de implementar 90% da funcionalidade, ainda tenho que implementar os outros 90% .

Ambas as versões se referem à dificuldade de estimar corretamente os esforços para o desenvolvimento de produtos de software e às armadilhas comuns em que as pessoas tendem a cair:

  • lançando estatísticas quando as estimativas são necessárias e, essencialmente, adivinhando ("Estou 80% concluído")
  • foco na complexidade algorítmica do código a ser gravado, em detrimento do volume de trabalho (subestimando o esforço necessário para tarefas comuns)
  • etapas ausentes ("fora da vista, fora da mente")
  • subestimar o esforço para manter e alterar o código existente
  • subestimar o esforço necessário para o código padrão / "cola"

6

Esta regra complementa a regra 80-20. Agora, existem muitas interpretações diferentes da regra 80-20, mas as duas que eu mais gosto são:

  1. O primeiro desenvolvimento de produto de 80% exige 20% de esforço.
  2. 80% dos erros estão em 20% do código.

Na prática, isso significa o seguinte: o desenvolvimento começará e seguirá até certo ponto em que os primeiros atrasos serão notados. Os atrasos podem ser de várias naturezas:

  • Controle de qualidade ruim, resultando em erros
  • Requisitos adicionais que o cliente apresentou ao longo do caminho (e os motivos para isso também podem ser múltiplos)
  • Requisitos pouco claros desde o início, que resultam na eliminação de partes do desenvolvimento anterior (que também podem resultar em erros de regressão)
  • Subestimações iniciais devido a escopo pouco claro, erro humano ou circunstâncias imprevisíveis. Essas circunstâncias imprevisíveis podem ser licenças médicas, demissões, falhas de hardware ou, em casos extremos, erupções vulcânicas (uma vez que tivemos que adiar um projeto porque não podíamos voar no local devido a uma erupção vulcânica na Islândia).

Resumindo, é muito mais fácil chegar perto da meta do que realmente alcançá-la.


11
A regra 80-20 também é conhecida como en.wikipedia.org/wiki/Pareto_principle
Peter M. - significa Monica

4

Acho a explicação da Wikipedia bastante esclarecedora:

Isso soma 180% de uma alusão irônica à notoriedade de projetos de desenvolvimento de software que excedem significativamente seus cronogramas (consulte a estimativa do esforço de desenvolvimento de software). Ele expressa a alocação aproximada de tempo para partes fáceis e difíceis de um projeto de programação e a causa do atraso de muitos projetos como falha na antecipação das partes difíceis. Em outras palavras, leva mais tempo e mais codificação do que o esperado para fazer um projeto funcionar.


1

O que isso significa exatamente na prática? Que os programadores realizam uma quantidade substancial de trabalho e estão dando 180% de si mesmos ou?

Não, os programadores sempre fazem a mesma quantidade de trabalho por unidade de tempo. A cotação é sobre subestimação de custos e excedentes. Os 180% são a quantidade de tempo e dinheiro que o projeto acaba custando.

Isso significa aproximadamente "Levará o dobro do tempo que você pensa" e "Você pensará que está indo bem até que seja tarde demais (o prazo está próximo)".


1

O que isso significa na prática é que as pessoas mentem para si mesmas.

Se um programador disser "estamos 90% concluídos", significa que 90% do esforço para criar os recursos foi gasto.

Se um gerente de projeto disser "estamos 90% concluídos, só preciso que alguém termine", significa que eles são 90% do orçamento (e provavelmente 50% concluídos). Este é um cliente sem dinheiro, grandes expectativas e uma atitude ruim.

A diferença é que é preciso mais esforço do que os recursos de codificação para concluir um projeto: qa, correções de bugs, edições de cópias, implantação.

Essas coisas precisam ser gerenciadas no projeto e são de responsabilidade do gerente do projeto. Isso muitas vezes surpreende os novos PMs que chegam a "90% do recurso concluído" apenas para perceber que estão a meio caminho do "projeto concluído".

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.