Feature creep
Il feature creep, o creeping featurism o ancora featuritis, è l'eccessiva ed incontrollata aggiunta di funzionalità in un prodotto[1], soprattutto nell'ambito dei software e dell'elettronica di consumo. Le funzionalità aggiunte non sono quelle basilari del prodotto e non sono necessarie. Ciò può portare anche al software bloat e all'eccessiva complicazione del prodotto, cioè l'opposto dell'approccio Keep It Simple, Stupid, che mira a mantenere semplice i progetti.
Cause modifica
La causa più comune di un feature creep è il desiderio di fornire ai clienti un prodotto più utile o desiderabile, aumentando le vendite. Quando il prodotto è pronto per svolgere la funzione per cui è stato progettato, si può scegliere di aggiungere funzionalità non necessarie, causando riduzione dell'efficienza oppure mancanza di aggiornamenti alle versioni successive, costringendo gli utenti a rimanere fermi ad una vecchia versione.
Un'altra importante causa del feature creep è la presenza di un gruppo di progettisti che non riesce a trovare un accordo su quali debbano essere i casi di utilizzo e le funzionalità base del prodotto, volendo così aggiungerli tutti. Più funzionalità sono aggiunte, più sarà necessario far sì che si interfaccino tra loro, complicando l'assetto generale del software.
Controllare il fenomeno modifica
Ci sono differenti modi di limitare il feature creep, tra cui limitare le funzionalità del prodotto che si deve creare ed eliminare le funzioni in eccesso.
La tentazione di aggiungere sempre più funzionalità può essere evitata, fino ad un certo punto, con una solida progettazione. Può essere anche controllata attivamente con un rigoroso change management e rimandando i cambiamenti più importanti ad una successiva fase di sviluppo del progetto.[2]
Conseguenze modifica
Il feature creep causa costi aggiuntivi e ritardi nella roadmap.[3] Mette in pericolo e fa cancellare prodotti e progetti.
Allontanamento dall'obbiettivo modifica
Ogni tanto, il feature creep incontrollato può portare i prodotti lontano dai casi d'uso per i quali erano stati progettati. Questo fenomeno si può chiamare anche scope creep.
Ritardi modifica
Spesso, un progetto ragionevolmente completo di funzionalità oppure uno con un feature creep moderato può sopravvivere, ma la distribuzione delle versioni successive subirà sempre gravi ritardi quando si prenderà la decisione di riscrivere l'intero codice per utilizzare nuove tecnologie.
Per esempio, Windows Vista doveva essere una release minore tra Windows XP e Windows 7, nome in codice Blackcomb, ma dopo che Microsoft aggiunse sempre più funzionalità previste per Blackcomb (molte furono anche cancellate), Vista divenne una release maggiore e richiese cinque anni di sviluppo.
Un simile destino ha avuto Netscape 6, inizialmente pianificato come Netscape 5. La decisione del 1998 di Netscape Communications di rendere open-source Netscape Navigator fece notare che il codice di base fosse troppo difficile e ne richiese una completa riscrittura. Ciò portò a ritardi significativi, Netscape 5 venne saltato e l'intera società venne comprata da AOL. La release che ne venne fuori nel 2000 fu molto criticata per il suo essere simile ad un'alpha ed infatti raggiunse la stabilità solo nel 2001 con Netscape 6.1, ben tre anni dopo la decisione di riscrivere il browser e l'internet suite ad esso collegata. In quel lasso di tempo Internet Explorer aveva avuto la possibilità di superare enormemente Netscape come percentuale di utilizzo.
Anche dopo aver raggiunto la piena stabilità ed aver acquisito nuove funzionalità, il nuovo Mozilla Application Suite, sul quale AOL costruì Netscape, fu visto come software bloat.
Appena un anno dopo, un gruppo di sviluppatori Mozilla decise di scindere la componente browser in Firefox.
Il videogioco Broken Age è un altro esempio di progetto rallentato dal feature creep. Originariamente previsto per ottobre 2012, la prima metà del gioco è stata distribuita nel gennaio 2014 e la seconda parte l'ha seguita nell'aprile 2015. Il gioco ha quindi richiesto complessivamente due diversi round di finanziamento per essere completato.[4]
Feeping creaturism modifica
Il feature creep unito a delle scadenze ristrette porta spesso ad una soluzione alla buona.
I cambiamenti che devono essere fatti potrebbero essere così grandi da necessitare una riprogettazione dalle fondamenta del progetto, ma la scadenza che si avvicina porta gli sviluppatori a dover far funzionare il tutto in breve tempo. Il gioco di parole inglese "feeping creaturism" è stato creato per enfatizzare l'avversione di uno sviluppatore contro la situazione[5], il prodotto eccessivamente complicato diventa una "creatura malforme di soluzioni improvvisate... che si aggira nell'oscurità"[6][7] ("Feeping" è un sinonimo gergale della parola inglese "beeping".)[8]
Note modifica
- ^ J.M. Sullivan, Impediments to and incentives for automation in the Air Force, in 2005 International Symposium on Technology and Society, 8–10 giugno 2005, pp. 101–110, DOI:10.1109/ISTAS.2005.1452719.
- ^ Kenneth S. Norton, Applying Cross-Functional Evolutionary Methodologies to Web Development, in paper in Web Engineering: Managing Diversity and Complexity of Web published by Springer, 2001, ISBN 3-540-42130-0.
- ^ Davis, F.D. e Venkatesh, V., Toward preprototype user acceptance testing of new information systems: implications for software project management, in IEEE Transactions on Engineering Management, 51, issue 1, n. 1, IEEE Transactions on Engineering Management, Febbraio 2004, p. 31, DOI:10.1109/TEM.2003.822468, ISSN 0018-9391.
- ^ (EN) Kris Ligman, Double Fine splits Broken Age in half to fund completion, su gamasutra.com, 2 luglio 2013.
- ^ feeping creaturism, 2016-05-27, FOLDOC.org - The Free On-line Dictionary of Computing
- ^ catb.org, http://catb.org/jargon/html/F/feeping-creaturism.html.
- ^ catb.org, http://catb.org/jargon/html/F/feeping-creature.html.
- ^ catb.org, http://catb.org/jargon/html/F/feep.html.
Voci correlate modifica
Collegamenti esterni modifica
- Creeping Featuritis, su Content Creation Wiki (archiviato dall'url originale il 30 novembre 1996).
