Deslocamento de recurso - Feature creep

O deslocamento de recursos é a expansão contínua excessiva ou adição de novos recursos em um produto, especialmente em software de computador , videogames e produtos eletrônicos de consumo e comerciais . Esses recursos extras vão além da função básica do produto e podem resultar em inchaço e supercomplicação do software , em vez de um design simples.

A definição do que se qualifica como "aumento de recursos" varia entre os usuários finais, onde o que é percebido como tal por alguns usuários pode ser considerado funcionalidade prática por outros.

Causas

A causa mais comum de deformação de recursos é o desejo de fornecer ao consumidor um produto mais útil ou desejável, a fim de aumentar as vendas ou distribuição. No entanto, quando o produto atinge o ponto em que faz tudo o que foi projetado para fazer, o fabricante fica com a escolha entre adicionar funções que alguns usuários podem considerar desnecessárias (às vezes à custa da eficiência) e manter a versão antiga (ao custo de uma percepção de falta de melhoria).

Outra causa importante de aumento de recursos pode ser um acordo de um comitê que decide implementar vários pontos de vista diferentes ou casos de uso no mesmo produto. Então, conforme mais recursos são adicionados para dar suporte a cada abordagem, pode ser necessário ter recursos de conversão cruzada entre os vários paradigmas, complicando ainda mais os recursos totais.

Características

O aumento de recursos é uma das fontes mais comuns de estouros de custo e cronograma. Portanto, ele põe em perigo e pode até matar produtos e projetos.

Ao controle

Existem vários métodos para controlar o deslocamento de recursos, incluindo: limites estritos para recursos permitidos, variações múltiplas e remoção de recursos em excesso.

Separação

A tentação de creep de recurso posterior pode ser evitada até certo grau baseando o design inicial em fundamentos de software sólidos, como separação lógica de funcionalidade e acesso a dados, por exemplo, usando submenus que são opcionalmente acessíveis por usuários avançados que desejam mais funcionalidade e maior detalhamento de informações . Ele pode ser controlado ativamente com gerenciamento de mudanças rigoroso e atrasando as mudanças para as fases posteriores de entrega de um projeto.

Variações e opções

Outro método de controlar o aumento de recursos é manter múltiplas variações de produtos, onde os recursos são mantidos limitados e reduzidos nas variações mais básicas, por exemplo, edições do Microsoft Windows . Para interfaces de usuário de software , modos de visualização ou modos de operação podem ser usados ​​(por exemplo, modo básico ou modo especialista), entre os quais os usuários podem selecionar para atender às suas próprias necessidades.

Tanto em muitas interfaces gráficas de usuário quanto em interfaces de linha de comando , os usuários podem optar por um detalhamento maior manualmente. No último caso, em muitos programas de linha de comando, adicionar uma opção -vou --verbosemanualmente mostra informações mais detalhadas que podem ser menos relevantes para usuários mínimos, mas úteis para usuários avançados ou para fins de depuração e solução de problemas.

Como a adição cada vez maior e cada vez maior de novos recursos pode exceder os recursos disponíveis, uma versão "básica" básica mínima de um produto pode ser mantida separadamente, para garantir a operação em ambientes operacionais menores. Usando a " regra 80/20 ", as variações de produto mais básicas podem atender às necessidades da maioria (por exemplo, ~ 80%) dos usuários, de modo que não estariam sujeitos à complexidade (ou despesa extra) dos recursos solicitados pelo avançado 20% dos usuários. Os recursos extras ainda estão disponíveis, mas opcionais e prontos para serem utilizados por aqueles que os solicitam, mas eles não foram implementados nas versões básicas dos produtos.

Modularidade

Outra solução para aumento de recursos é a modularidade. Usuários avançados que exigem mais funcionalidade podem atualizar os recursos necessários baixando módulos de software, plug-ins , complementos (também conhecidos como complementos) e temas personalizados para atender às suas necessidades pessoais.

Poda

Em algum ponto, o custo de manutenção de um determinado subconjunto de recursos pode se tornar proibitivo e a poda pode ser usada. Uma nova versão do produto poderia simplesmente omitir os recursos extras, ou talvez um período de transição seria usado, onde recursos antigos foram descontinuados antes da eventual remoção do sistema. Se houver várias variações de produtos, alguns deles podem ser descontinuados gradualmente. Um grande exemplo é o Samsung Galaxy S6 , lançado em março de 2015, do qual muitos recursos de software / menu e também alguns recursos de hardware foram removidos. Uma variação “mais funcional” dele não foi lançada.

Consequências

Expansão de escopo

Ocasionalmente, o deslocamento de recurso não controlado pode levar a produtos muito além do escopo do que foi originalmente planejado; isso é conhecido como aumento de escopo . No entanto, uma consequência mais comum do deslocamento de recurso é um atraso ou cancelamento do produto, que pode se tornar mais caro do que o planejado originalmente.

Atrasos

Muitas vezes, um projeto de software razoavelmente completo, ou com quantidades moderadas de aumento de recursos, pode sobreviver e até mesmo prosperar por meio de muitas iterações, mas seu lançamento sucessor pode sofrer atrasos substanciais uma vez que seja tomada a decisão de reescrever toda a base de código, além de introdução de novas tecnologias. Por exemplo, o Windows Vista da Microsoft foi planejado para ser uma versão secundária entre o Windows XP e seu sucessor de codinome Windows "Blackcomb" , mas depois de adaptar mais e mais recursos do Blackcomb (muitos dos quais foram eventualmente cancelados), o Vista acabou se tornando um importante lançamento que levou cinco anos de desenvolvimento.

Um destino semelhante foi sofrido pelo Netscape 6 , que originalmente deveria ser o Netscape 5 . A decisão de 1998 da Netscape Communications de abrir o código-fonte do navegador Netscape Navigator e do pacote Communicator Internet (ambos com o codinome Mozilla) logo tornou óbvio que o código subjacente era muito difícil e exigia uma reescrita completa do Mozilla, o que estimulou a criação do a estrutura de aplicativos Mozilla . Isso causou atrasos significativos, o Netscape 5 foi ignorado e a empresa foi comprada pela AOL. O lançamento subsequente do Netscape 6.00 em 2000 foi amplamente criticado como código de nível alfa, e o projeto alcançou estabilidade pelo Netscape 6.1 em 2001, três anos após a decisão de retrabalhar o pacote de Internet. Naquela época, o navegador Internet Explorer da Microsoft havia eclipsado o Netscape em compartilhamento de uso, que havia diminuído para um dígito.

Mesmo depois de atingir a estabilidade e obter alguns novos recursos necessários, o Mozilla Application Suite de código aberto (então chamado apenas de Mozilla), no qual a AOL construiu o Netscape, foi visto como " inchado ". Apenas um ano depois, um grupo de desenvolvedores do Mozilla decidiu separar o componente do navegador, que acabou se tornando o Firefox .

O projeto Broken Age da Double Fine Adventures para o Kickstarter é outro exemplo de um projeto que está sendo atrasado por recurso creep. Originalmente deveria ter uma data de lançamento de outubro de 2012, a primeira metade do jogo foi lançada em janeiro de 2014, enquanto a segunda metade seguiu no final de abril de 2015, e exigiu duas rodadas de financiamento separadas para ser concluído.

Feeping criaturismo

A distorção de recursos combinada com prazos curtos geralmente leva a uma "solução hacky" . A mudança desejada pode ser grande o suficiente para garantir um redesenho da base do projeto existente, mas a pressão do prazo exige que os desenvolvedores apenas "façam funcionar" com uma abordagem menos elegante. O Bem humorado spoonerism "feeping creaturism" foi cunhado para enfatizar antipatia de um desenvolvedor desta situação, personificando o produto alcance-rastejou como "uma criatura disforme de hacks ... rondando no escuro", e o prenúncio de mais fluência para vir. ("Feeping" é um sinônimo jargão de "beeping".)

Veja também

Referências

links externos