Quantidade de trabalho de rotina no desenvolvimento de software e seu efeito na estimativa


11

Estou convencido de que a quantidade de trabalho rotineiro no desenvolvimento de software é - e deve ser - relativamente pequena, se não desprezível, e que esse é o problema fundamental da estimativa de software.

Deixe-me descrever como chego a essa conclusão e me diga se a argumentação tem alguma falha séria:

  1. Tudo o que pode ser estimado com alta precisão é um trabalho de rotina, ou seja, coisas que foram feitas antes. Todos os outros tipos de trabalho que envolvem pesquisa e criatividade não podem realmente ser estimados, pelo menos não com uma precisão de, digamos, +/- 20%.

  2. O desenvolvimento de software visa evitar tarefas repetitivas. Um de seus princípios básicos é SECO (não se repita). Sempre que um programador se vê fazendo coisas repetitivas, é hora de encontrar uma abstração que evita essa repetição. Essas abstrações podem ser coisas simples, como extrair o código repetido em uma função ou colocá-lo em um loop. Eles também podem ser mais complexos, como criar um idioma específico do domínio. De qualquer forma, implementá-las envolverá pesquisa (alguém já fez isso antes?) Ou criatividade.

Destes dois pontos, chego à conclusão acima.

Na verdade, eu me pergunto há bastante tempo por que esse relacionamento não é mencionado em todas as outras discussões, post de blog ou artigo sobre estimativa de software. Isso é teórico demais? Minhas suposições estão erradas? Ou é muito trivial - mas então, por que a maioria dos desenvolvedores que conheço acredita que pode fazer estimativas com uma precisão de +/- 20% ou melhor?


7
99% de todo o desenvolvimento de software fora de áreas como kernels foram feitos milhares de vezes antes. Muitos desenvolvedores só querem fazer tudo de uma maneira nova e sofisticada, reinventando os mesmos problemas antigos repetidamente.
Bent

@ Bent: Então você está dizendo que o desenvolvimento de software é principalmente copiar e colar? Eu sei que muitos desenvolvedores trabalham dessa maneira e frequentemente descobrem que isso leva a um código não sustentável. Mas essa é uma história diferente. Mesmo que alguém trabalhe dessa maneira, ele precisa descobrir o que copiar e de onde. Isso é algo que eu também consideraria como trabalho de pesquisa.
Frank soprador

1
@rwong: Claro que faz sentido usar bibliotecas. Mas encontrar a função correta em uma biblioteca e a maneira correta de usá-la é um trabalho de pesquisa (se a biblioteca é complementar e / ou você não a conhece bem) ou trivial (se você já conhece essa função). O que você chama de "código de cola" é, na minha experiência, muitas vezes complexo. Implementá-lo não é um trabalho de rotina necessário.
Frank soprador

1
@ JohnR.Strohm: Eu não li esses livros específicos, mas estou familiarizado com o básico do COCOMO - no entanto, nunca o usei na prática. Também li outros dois ou três livros de DeMarco. Você poderia dar uma dica sobre qual conteúdo específico está relacionado à minha pergunta?
31816 Frank Puffer

2
@FrankPuffer, "Economia de engenharia de software" da Boehm é leitura obrigatória para estimativa de software. O livro de Demarco não está muito atrás. A RESPOSTA RESUMIDA é esta: Se você está familiarizado o suficiente com o que o software deve fazer para estimar tudo, é familiar o suficiente para considerá-lo relativamente rotineiro.
John R. Strohm

Respostas:


11

Em qualquer projeto, isso pode ser verdade. No entanto, se você trabalha em vários projetos semelhantes para empresas diferentes ao longo dos anos, pode se 'resolver' basicamente o mesmo problema muitas vezes com apenas pequenas variações.

Por exemplo, eu escrevi camadas de acesso a dados tantas vezes que agora prefiro fazê-lo 'mão longa' do que usar o ORM popular do mês. É mais rápido e fácil lidar com os 'problemas de rotina' com soluções conhecidas do que encontrar e resolver novas peculiaridades em componentes de terceiros.

Obviamente, eu poderia escrever meu próprio ORM para simplificar o código repetitivo sem adicionar as peculiaridades desconhecidas no sistema de outra pessoa, mas esse código pertenceria à empresa para a qual trabalhava na época e outros desenvolvedores o achariam tão peculiar quanto qualquer outro ORM de terceiros.

Da mesma forma, na minha experiência, a maior parte da programação é a automação de processos de negócios e, embora cada empresa goste de pensar que seus processos são exclusivos para eles; Na realidade eles não são.

Para não dizer que a estimativa é fácil! É mais fácil, mas acho que hoje em dia o problema de estimativa se deve à inadequação dos requisitos e não ao tempo gasto na codificação.

Os requisitos tendem a se dividir em três categorias:

  1. Vagas, detalhes deixados para o desenvolvedor.

"Faça de mim um site, tem que ser legal e vender meus widgets"

Eles tendem a ser os mais fáceis de estimar, pois quando ocorre um problema inesperado, você pode simplesmente mudar os requisitos para algo funcionalmente equivalente e evitar o problema.

  1. Muito específico

"Tornar a cor de fundo do cabeçalho # ff1100"

Super rápido de fazer e, novamente, fácil de estimar. Mas! o requisito está sujeito a alterações. "Hmm, não pensando duas vezes, tente este outro vermelho" ou "Espere! Eu quis dizer apenas nessa página!" portanto, o tempo real de "quanto tempo até eu ficar feliz com a cor do cabeçalho" não tem nada a ver com as estimativas de codificação

  1. Vaga, detalhes assumidos

"Faça de mim um site (assim como o facebook)"

Aqui a multidão de suposições não declaradas "é claro que você deseja um logotipo diferente", "ele deve ter rolagem infinita", "deve ser escalável para 1 bilhão de usuários!" controlar efetivamente a estimativa. O desenvolvedor pensa em tudo e eleva a estimativa além das expectativas "1 milhão de horas-homem", ou pensa / assume que apenas os recursos básicos são necessários e fornece uma estimativa muito baixa. "ah, uma semana ou duas, presumo que você só queira colocar o facebook em um iframe, certo?"

Com a experiência, a codificação é muito rápida, mas os requisitos de design são (geralmente) os mais difíceis, e isso é cada vez mais repetido nos não codificadores. Com metodologias ágeis, aumentando a velocidade de codificação, movendo essa responsabilidade para 'o negócio', e não para os desenvolvedores.


Concordo plenamente com o que você escreveu sobre requisitos inadequados, mas essa é uma história diferente. Na primeira parte da sua resposta, você diz que costuma continuar usando técnicas conhecidas, para que grande parte do seu trabalho se torne rotina. Você deliberadamente fica sem abstrações adicionais. Isso provavelmente funciona bem por um curto período de tempo, talvez de 2 a 5 anos, dependendo das tecnologias que você está usando. Mas então você pode perceber que não melhorou seu processo tanto quanto alguns de seus concorrentes. Além disso, outros desenvolvedores que manterão seu código posteriormente poderão ter um problema.
Frank soprador

Obviamente, não é como se eu nunca usasse coisas de terceiros. O ponto é, se você sabe como fazer algo já com a ferramenta X a estimativa é fácil
Ewan

Não apenas a estimativa, mas também a implementação se torna fácil neste caso. Se todo o seu projeto for assim, você terá sorte. Mas, na minha experiência, isso só acontece em pequenos projetos. Todos os projetos maiores (> 10 dias) nos quais eu participei exigiram alguns novos conceitos ou tecnologias e foi isso que causou a maior parte do trabalho, tornando o esforço para o material padrão insignificante.
Frank soprador

Não vamos entrar em guerra de chamas 'quem é o melhor programador'. Tudo o que estou dizendo é que quanto mais você fez antes, menos coisas novas existem. Se todos os seus projetos exigir o uso da nova tecnologia para a maioria das características embora ... Isso parece estranho
Ewan

@Ewan "conceitos ou tecnologias". Para mim, o primeiro tende a se relacionar com as regras de negócios e / ou com o que o designer deseja. Não se trata apenas de novas tecnologias.
Izkata 16/08

6

por que a maioria dos desenvolvedores que conheço acredita que pode fazer estimativas com uma precisão de +/- 20% ou melhor?

Porque estimamos nossa paciência com o problema muito mais do que o problema real.

Se eu vou animar uma bola quicando, poderia passar um dia, uma semana, um mês ou um ano nela e ainda assim ter uma animação de uma bola quicando. Espero que pareça melhor quanto mais tempo passo, mas em um determinado momento estou sendo ridículo.

Quanto esforço eu dedico para fazer a bola quicar é uma função do tempo que é razoável gastar nela. Se meu nível de habilidade não estiver diminuindo, posso acabar com uma bola que fica lá. Mas quando o prazo chegar, devo deixar o prazo passar ou pelo menos colocar uma bola na tela? Waterfall insistiu que a bola saltasse e o cronograma caiu. O Agile diz que é só pegar a bola. Pelo menos, descobriremos o quanto as pessoas se importam com saltos. Então a qualidade caiu.

Eu tento ter certeza de que minhas bolas balançam, mas quando o prazo chegar, é melhor produzir uma bola estática do que nada. Portanto, estimo o tempo com base no que parece uma quantidade razoável de tempo para gastar em um problema antes de falar sobre alternativas. Às vezes a bola não vai saltar. Às vezes tudo bem. Desaparecer por um mês não está OK.


Bom ponto, basicamente você está dizendo que a estimativa deve se basear no valor que um determinado recurso tem para o cliente (ou o proprietário do produto). Pessoalmente, gosto dessa abordagem, mas, na minha experiência, não é assim que a estimativa de software é geralmente compreendida, mesmo em um ambiente ágil. Uma desvantagem é que muitas vezes você não tem essas informações sobre o valor do cliente para um recurso. Outra desvantagem é que ele não pode lidar com pacotes de trabalho que não resultam diretamente em um recurso visível ao cliente.
Frank soprador

@FrankPuffer Não concordo que métodos ágeis não deixem isso claro. O SCRUM, em particular, nem pede aos desenvolvedores para estimar até que o valor do recurso seja tão alto que esteja realmente programado para ser feito, ou seja, apenas na estimativa de tempo. Os métodos ágeis são particularmente adequados para isso: primeiro identifique os recursos com o maior valor comercial, depois avalie-os, depois faça-os e veja quanto tempo realmente levou. Ensaboar enxaguar repetir. Após alguns ciclos, você terá uma boa ideia da estimativa versus o tempo real de desenvolvimento.
precisa saber é o seguinte
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.