Feature vs. Function [chiuso]

Spesso ascolto PM (Project Manager) che parlano di caratteristiche e funzioni. E sono così perplesso nel differenziarli. A volte penso che una funzionalità sia equivalente a una user story. Qualcosa del tipo "Come utente, Bob dovrebbe essere in grado di vedere un elenco dei suoi pagamenti" e lo chiamano funzionalità. A volte diventa grande come un sottosistema, qualcosa come "la capacità di inviare SMS tramite un'applicazione Web". La funzione d'altra parte a volte diventa piccola come un'attività, "implementando il raggruppamento delle cifre per gli input numerici", mentre ci sono casi in cui diventa grande come un'intera operazione CRUD.

La mia domanda è: come possiamo differenziare la funzionalità dalla funzione?

Le caratteristiche sono ciò che i venditori vendono.
Le funzioni sono ciò che i programmatori sviluppano.

Le funzioni non si adattano bene al contesto di una user story e sono per lo più trasparenti per l'utente. Possono essere un processo back-end o un tipo di funzionalità applicazione unica o comune che consente di implementare in modo appropriato altre funzionalità o eventualmente altre funzioni.

Le attività invece sono singole unità di lavoro che devono essere completate per fornire una caratteristica o una funzione.

Nei miei progetti tendo a non distinguere tra una caratteristica e una funzione e scrivo storie utente per caratteristiche e aggiungo funzioni o sforzi di refactoring come Compiti per completare una singola funzione.

Questo a volte fa sembrare alcune funzioni inutilmente gonfiate nel piano di progetto, ma questo va bene, perché se ho bisogno di rifattorizzare le funzioni 1 e 2 e la funzione 3 per consegnare correttamente la caratteristica 1, forse il mio unico risultato per quello sprint sarà la caratteristica 1, oppure probabilmente nessun risultato.

Finché alla fine dello sprint ho ancora un software funzionante, il mio progetto è Agile.

Le caratteristiche sono ciò che il tuo programma può fare. Le funzionalità sono il risultato diretto dei requisiti dell'utente e degli obiettivi aziendali. Pertanto le funzionalità di un programma esistono principalmente per soddisfare le esigenze degli utenti .

La funzionalità, d'altra parte, è il modo in cui le funzionalità di cui sopra sono effettivamente implementate .

Per un PM, "Funzione" è lo scopo e "Funzione" è un comportamento del prodotto con cui un utente può interagire. Tuttavia le persone spesso ottengono i due all'indietro (cosa che penso sia il caso nella tua domanda).

Portarmi dal posto A al posto B è una funzione chiave di un'auto. È la ragione (scopo) che esiste. Il volante è una caratteristica, così come la leva del cambio. Il conducente interagisce con più funzionalità per ottenere la funzione di arrivare da qualche parte.

La "funzione" qui non deve essere confusa con una funzione del linguaggio di programmazione (metodo) che parla dell'implementazione di un software di funzionalità. Molto probabilmente non è ciò di cui un PM parlerebbe quando si riferirà a "Caratteristiche e funzioni".

Non esiste una bella gerarchia di funzioni e caratteristiche, poiché una funzione può essere utilizzata per supportare più funzioni del prodotto.

Credo che si debba tracciare una distinzione corretta per una metodologia specifica o una cultura dei requisiti specifici. Quella che segue è la mia interpretazione.

Funzione: un requisito fondamentale che influisce notevolmente sul valore del software, che l'utente deve avere a una versione specifica. Esempio: funzione di salvataggio su un editor di testo.

Funzionalità: una funzionalità interessante del software, che aggiunge valore al software ma non è un must assoluto per il corretto funzionamento del software e l'esecuzione delle sue funzioni. Ad esempio, avere una funzione di annullamento in un modulo di immissione dati o salvare un documento come file gif per un editor di testo (cablato!).

Dietro ogni funzione è la funzionalità necessaria per fornire all'utente lo scopo previsto della funzione.

Esempio: il sistema di registrazione di un'università avrebbe una funzione "registri degli studenti per le classi". Questa attività richiede un bel po 'di funzionalità e l'accesso a un database. Il design per la funzionalità implicherebbe la comprensione del compito effettivo dell'utente: la registrazione per le lezioni. Questo sarebbe un prerequisito per il "progetto di interazione" necessario per facilitare l'attività degli utenti. La funzionalità sarebbe progettata per implementare i requisiti di interazione.

I programmatori sono alla ricerca di funzioni da codificare. I progettisti di interazioni sono alla ricerca del modo migliore per fornire questa funzionalità necessaria attraverso la progettazione dell'interazione del software con l'utente. La comprensione di come l'utente può raggiungere al meglio il proprio obiettivo viene prima di tutto. Segue l'identificazione della funzionalità necessaria.

Quanto sopra non è scientifico, è solo la mia opinione.

È importante ricordare la distinzione tra funzioni e caratteristiche del prodotto. Le funzioni sono la "risposta del prodotto all'insieme delle attività dell'utente"; le caratteristiche sono gli "strumenti utente" inerenti al prodotto utilizzato per eseguire le funzioni. Effettuare una chiamata è una funzione; il tono di composizione e la tastiera a toni sono funzioni utilizzate per eseguire la funzione.

Concordo sul fatto che non valga la pena ossessionarsi poiché i termini sono spesso usati in modo intercambiabile in alcuni contesti. Tuttavia, nel più ampio contesto di gestione, penso che ci siano alcuni punti importanti. In primo luogo, PM può anche significare product manager. Qualcuno deve assumersi la responsabilità di decidere ciò che il mercato supporterà in termini di prezzo, data di consegna e caratteristiche. In genere trovo che questa funzione sia preferita quando ci si trova in un contesto di marketing. Il ruolo del project manager è di gestire il progetto in modo tale che il prodotto desiderato sia consegnato in tempo e nel rispetto del budget. All'architetto e ai progettisti, la funzione viene fornita e può essere considerata come funzioni fornite nell'organizzazione umana che offre trasformazione e archiviazione dei dati, ma deve essere modificata fino a quando il progetto non è stato ridotto a unità di lavoro delegabili che possono essere assegnate agli sviluppatori . Accade spesso che una funzione non si associ in modo pulito a una serie di funzioni nel sistema della macchina. Ad esempio, veloce e sicuro sono le funzionalità desiderate dai consumatori ma non possono essere separate nel codice. Queste proprietà emergenti sono ciò che rende i requisiti non funzionali così difficili da soddisfare.