Priorità

Di Mitch Lacey. Titolare di Mitch Lacey & Associates, Inc, una società di consulenza specializzata nell'adozione e nell'ottimizzazione di framework di sviluppo di tipo Agile e Scrum.

Gennaio 2012

In questo articolo Mitch Lacey illustrerà tre metodi che si sono rivelati molto utili per molti team Agile: il modello Kano di soddisfazione dei clienti, una serie di Innovation Games di Luke Hohmann e il modello di ponderazione relativa di Karl Weigers. Tutti e tre questi metodi consentono di spostarsi da un'assegnazione di priorità approssimativa del backlog a un ordine esatto che valuta in modo soddisfacente il rischio, la priorità e la soddisfazione dei clienti.

Si applica a

Application Lifecycle Management e Team Foundation Server

Contenuto dell'articolo:

• Introduzione

• Modello Kano di soddisfazione dei clienti

• Innovation Games

  • Potare l'albero dei prodotti

  • Acquistare una funzionalità

• Ponderazione relativa – Karl Weigers

• Conclusione

Per mantenere il team Agile in efficienza, è necessario ordinare gli elementi nel backlog di prodotto in base alla priorità e aggiornare tali priorità man mano che il progetto viene sviluppato. Tutti i backlog di prodotto devono essere classificati in ordine di priorità in base al valore aziendale e al rischio. Riconoscendo l'ordine di priorità, il team può concentrarsi meglio sulle funzionalità che dovranno verosimilmente contribuire al successo del prodotto. Un backlog ben organizzato e con classificazione in ordine di priorità ripaga non solo in termini di soddisfazione del team e dei clienti ma anche in termini di bilancio aziendale. Per informazioni sui backlog, vedere Creare e gestire il backlog di prodotto, Creare il backlog e Pulire e stimare il backlog.

Nell'organizzare e classificare in ordine di priorità il backlog di prodotto, è necessario considerare molti fattori nonché essere in grado di giustificare le proprie decisioni. Quando si inizia a creare un backlog di prodotto da zero, il processo può apparire estremamente impegnativo. Fortunatamente, non è necessario ordinare perfettamente ogni elemento nel backlog immediatamente. Nell'articolo Stima descrivo una tecnica denominata "The Big Wall", ovvero un modo efficiente per stimare rapidamente un backlog di prodotto da zero e lavorare con le parti interessate ottenendo una classificazione in ordine di priorità approssimativa.

La classificazione approssimativa in ordine di priorità è un buon punto di partenza e in alcune circostanze potrebbe anche essere sufficiente. In alcuni casi, tuttavia, è possibile ridefinire tali priorità o ottenere un backlog classificato in ordine di priorità in modo più scientifico. È possibile adottare molte tecniche per raggiungere questo risultato. Nell'articolo seguente illustrerò tre metodi che si sono rivelati molto utili per molti team Agile: il modello Kano di soddisfazione dei clienti, una serie di Innovation Games di Luke Hohmann e il modello di ponderazione relativa di Karl Weigers. Tutti e tre questi metodi consentono di spostarsi da un'assegnazione di priorità approssimativa del backlog a un ordine esatto che valuta in modo soddisfacente il rischio, la priorità e la soddisfazione dei clienti.

Modello Kano di soddisfazione dei clienti

Il modello Kano di soddisfazione dei clienti è stato sviluppato negli anni '80 dal professor Noriaki Kano della Tokyo Rika University. Tale modello fornisce uno schema semplice di classificazione che distingue tra attributi essenziali e discriminanti. Usando un approccio basato su questionario, il modello rappresenta un metodo efficace di visualizzazione delle caratteristiche del prodotto e di stimolo per un dibattito all'interno del gruppo addetto alla progettazione.

Secondo il modello Kano poniamo una serie di domande in due moduli diversi: funzionale e disfunzionale. Supponiamo, ad esempio, di porre ai clienti domande riguardo un sistema di navigazione GPS per automobili. Usiamo innanzitutto il modulo funzionale della domanda:

• Cosa ne penserebbe se questa automobile avesse a disposizione un sistema di navigazione GPS?

Limitiamo la scelta tra le risposte seguenti:

• Mi piacerebbe

• Me lo aspetterei

• Mi è indifferente

• Lo accetterei

• Non mi piacerebbe

Supponiamo che per questo esempio i clienti fittizi abbiano risposto "Mi piacerebbe".

Successivamente usiamo il modulo disfunzionale della domanda:

• Cosa ne penserebbe se questa automobile non avesse a disposizione un sistema di navigazione GPS?

I clienti fittizi possono scegliere tra le risposte elencate. Tuttavia, spesso la risposta può essere diversa, e in genere lo è. Supponiamo che per questo esempio i clienti fittizi abbiano risposto "Me lo aspetterei" al modulo disfunzionale della domanda.

Quando prepariamo queste domande per un progetto reale, possiamo porre l'elenco di domande contrapposte a più gruppi di clienti, vale a dire gruppi diversi di persone che rappresentano le diverse funzioni dell'organizzazione del cliente. Si potrebbe avere un gruppo marketing, un gruppo contabilità, un gruppo produzione e così via. Ai fini della comprensione del modello, tuttavia, immaginiamo di fare una sola domanda a un solo gruppo di clienti. Dopo aver compilato la coppia di risposte (le risposte al modulo funzionale e disfunzionale), ne eseguiremo il mapping in una griglia, come mostrato nella tabella 1.

Tabella 1 - Mapping del modello Kano

Si noti che nell'esempio i clienti fittizi hanno risposto Mi piacerebbe alla domanda funzionale e Me lo aspetterei alla domanda disfunzionale. Quando eseguiamo il mapping di tale coppia nella griglia, possiamo vedere che l'intersezione di questi due attributi è una E, come indicato dal quadrato evidenziato in giallo. Vediamo cosa significa per il nostro backlog classificato in ordine di priorità.

• E = Requisiti di attrattività. Si tratta di funzionalità che il cliente non si aspettava e che differenziano effettivamente un prodotto dalla concorrenza. Sono difficili da identificare, in particolare all'inizio, poiché può essere difficile ideare domande che evidenziano le funzionalità interessanti. Per questo motivo, le funzionalità attrattive tendono a emergere e a far aumentare la priorità man mano che il progetto si sviluppa e iniziano i commenti e i suggerimenti dei clienti.

  • I clienti sono molto soddisfatti di queste funzionalità e sono disposti a pagare un prezzo premium per averle. Ad esempio, i clienti hanno apprezzato l'iPod della Apple per la capacità intuitiva di ruotare il contenuto in base all'orientamento dello schermo. Tuttavia, l'assenza di tale funzionalità non avrebbe ridotto la soddisfazione del cliente poiché non se l'aspettava.

  • Nell'esempio avere la navigazione GPS rappresenta una funzionalità interessante. L'esplorazione di questa funzionalità, almeno per quanto riguarda la ricezione di commenti e suggerimenti del cliente, è una priorità relativamente alta.

• B = Requisiti di base. Queste funzionalità devono essere incluse nel prodotto. Si tratta di funzionalità necessarie che hanno una priorità elevata.

  • Indipendentemente da come questi attributi di base vengono realizzati, il cliente rimane indifferente rispetto al prodotto. Un elaboratore di testo deve avere, ad esempio, le funzioni di "creazione" e "salvataggio" di un documento. Si tratta di funzioni essenziali.

  • Se avessimo posto al gruppo di clienti domande sulle cinture di sicurezza, la maggior parte delle persone avrebbe risposto di aspettarsi che una nuova auto fosse dotata di cinture di sicurezza e che, in caso contrario, non l'apprezzerebbero. Se di queste due risposte venisse eseguito il mapping nella griglia, vedremmo che le cinture di sicurezza sono un requisito base (B), ovvero una funzionalità imprescindibile.

• L = Requisiti lineari. Noti anche come requisiti prestazionali, le funzionalità lineari sono direttamente correlate alla soddisfazione del cliente. In ordine di priorità vengono subito dopo le funzionalità di base ma devono essere bilanciate con i costi.

  • Il miglioramento della funzionalità o della qualità di esecuzione aumenta la soddisfazione del cliente. Una diminuzione della funzionalità ne riduce la soddisfazione.

  • Il prezzo del prodotto è correlato spesso a questi attributi.

• I = Requisiti indifferenti. Queste funzionalità sono meno importanti per il cliente e, di conseguenza, devono essere meno importanti per il prodotto. Probabilmente restituiranno un valore aziendale minimo o nullo.

La tabella 1 mostra anche D e R.

• Q: Dubbio. La domanda è probabilmente errata o la risposta è ambigua.

• R: Inverso. La combinazione di risposte non viene calcolata. Nel caso del sistema di navigazione GPS, se una persona risponde che si aspetta che sia presente ma che preferirebbe anche che non lo sia, tale risposta viene classificata come R.

Se una coppia di risposte viene classificata come Q o R, è necessario analizzare più approfonditamente le domande o la coppia di risposte.

Innovation Games

Gli Innovation Games sono strumenti che consentono di sviluppare una ricerca di mercato primaria. Con questi strumenti, i clienti "giocano" con l'obiettivo di generare commenti e suggerimenti nonché input su un prodotto o un servizio. Luke Hohmann ha creato e descrive oltre 12 giochi nel suo libro Innovation Games, un'aggiunta importante per qualsiasi libreria. I miei due giochi preferiti da fare per ottenere un backlog classificato in ordine di priorità sono Prune the Product Tree (Potare l'albero dei prodotti) e Buy a Feature (Acquistare una funzionalità), che Luke descrive in questo estratto dal libro (usato su autorizzazione):

Potare l'albero dei prodotti

I giardinieri potano gli alberi per controllarne la crescita. Talvolta la potatura è artistica e si finisce con arbusti a forma di animali o interessanti forme astratte. La maggior parte delle volte la potatura è concepita per ottenere un albero bilanciato che produce frutti di alta qualità. Il processo non riguarda la capacità di "tagliare" bensì quella di "modellare". Usare questa metafora per creare il prodotto desiderato dai clienti.

Il gioco

Iniziare disegnando un grande albero su una lavagna o un foglio oppure stampando un'immagine grafica di un albero come un poster di grandi dimensioni. I rami spessi rappresentano le aree principali della funzionalità all'interno del sistema. Le estremità dell'albero, i rami più esterni, rappresentano le funzionalità disponibili nella versione corrente. Scrivere le nuove funzionalità potenziali su varie schede, idealmente a forma di foglia. Chiedere ai clienti di posizionare le funzionalità desiderate attorno all'albero, definendo la fase successiva della crescita. Consentono all'albero di crescere in modo bilanciato? Un ramo, ad esempio una funzionalità principale del prodotto, cresce più degli altri? Un aspetto poco usato dell'albero diventa più visibile? È noto che le radici di un albero (l'infrastruttura di supporto e di assistenza clienti) devono estendesi almeno fino alla chioma. È così per l'albero disegnato?

Albero del prodotto – Hohmann

Motivo del successo

Sia gli sviluppatori che i clienti sanno bene che l'importanza delle funzionalità varia. Tendiamo quindi a dedicare i nostri sforzi alle funzionalità più importanti, ovvero quelle che offrono il massimo valore ai clienti. Sfortunatamente, talvolta ciò significa che si sottovalutano altre funzionalità che sono necessarie al completamento del prodotto. Il gioco della potatura (Prune the Product Tree) offre ai clienti un modo per fornire un input al processo decisionale esaminando il set di funzionalità che costituiscono il prodotto in modo olistico.

Acquistare una funzionalità

Quale funzionalità attirerà i clienti al punto da acquistare il prodotto? Quale funzionalità spingerà i clienti a effettuare l'aggiornamento? Quale funzionalità soddisferà i clienti al punto tale da far loro ignorare o tollerare le funzionalità che vorrebbero correggere o rimuovere?

I pianificatori di prodotto dibattono senza fine questi e altri tipi di domande. La scelta del giusto set di funzionalità da aggiungere a una versione spesso segna la differenza tra un insuccesso a breve termine e un successo a lungo termine. Purtroppo, troppi pianificatori di prodotto prendono questa decisione senza coinvolgere le persone più interessate, ovvero i clienti. Il gioco Buy a Feature (Acquistare una funzionalità) migliora la qualità di questa decisione chiedendo ai clienti di prendervi parte.

Acquistare una funzionalità - Sterne

Il gioco

Creare un elenco di possibili funzionalità e fornire un prezzo per ognuna. Come in un prodotto reale, il prezzo può essere basato sui costi di sviluppo, sul valore del cliente o su un altro elemento. Sebbene il prezzo può essere il costo effettivo che si intende far pagare per la funzionalità, in genere non è richiesto. I clienti acquistano le funzionalità che desiderano nella versione successiva del prodotto con soldi finti. Accertarsi che il prezzo di alcune funzionalità sia abbastanza alto in modo che nessun cliente le acquisti. Incoraggiare i clienti a mettere insieme il denaro per comprare le funzionalità particolarmente importanti e/o costose. In questo modo vengono stimolate le trattative tra i clienti per determinare quali funzionalità sono più importanti.

Il gioco funziona meglio con un gruppo composto da 4 a 7 clienti, in modo da offrire ai clienti più opportunità per mettere insieme il denaro con le trattative. A differenza del gioco Product Box (Confezione del prodotto), il gioco Buy a Feature (Acquistare una funzionalità) è basato sull'elenco di funzionalità che probabilmente saranno presenti nella guida di orientamento allo sviluppo.

Motivo del successo

I pianificatori di prodotto incorrono spesso nell'errore di ritenere che i clienti hanno le priorità del prodotto molto ben definite. In effetti è così per alcuni ma sicuramente non per la maggior parte. Quando ai clienti viene presentato un set di opzioni, molti di loro dicono semplicemente di volerle tutte e affidano al team la responsabilità di classificare le loro richieste in ordine di priorità. In alternativa, i responsabili di prodotto spesso raccolgono le priorità delle funzionalità lavorando personalmente con i clienti e, nel processo e forse anche senza rendersene conto, si prendono ancora una volta la responsabilità di classificare le funzionalità in ordine di priorità. Coinvolgendo i clienti come gruppo e fornendo loro una quantità limitata di risorse, gli viene fornita la possibilità di classificare i desideri del gruppo in ordine di priorità. Ma non è questo il trucco. Il trucco sta nell'impostare i dibattiti con i clienti in modo che questi trovino tra loro un accordo sulle funzionalità specifiche. È questa negoziazione che migliora la comprensione di ciò che i clienti vogliono effettivamente.

Ponderazione relativa – Karl Weigers

Un altro metodo eccellente per la classificazione in ordine di priorità è la ponderazione relativa che Karl Weigers ha introdotto nel 1999. Questo metodo non fornisce solo un meccanismo per classificare in ordine di priorità i requisiti in base all'input e ai commenti e suggerimenti dell'utente ma include anche il giudizio esperto del team. Analogamente ai metodi Kano e Innovation Games, la ponderazione relativa consente al proprietario del prodotto di valutare meglio le funzionalità da implementare e in quale ordine di priorità.

Il primo passaggio consiste nell'assegnare un peso al vantaggio relativo di una funzionalità. Il vantaggio è rappresentato dalla possibilità per gli utenti di avere la funzionalità nel prodotto finale. Poi si passa all'assegnazione di un peso allo svantaggio relativo. Lo svantaggio è la conseguenza per gli utenti di non avere la funzionalità nel prodotto finale. La valutazione dei vantaggi e degli svantaggi ottiene lo stesso risultato del modulo funzionale e disfunzionale della domanda del metodo Kano. I pesi sono numeri arbitrari che rappresentano il valore che una società attribuisce ai vantaggi e ai rischi delle funzionalità. È molto simile al modo in cui un insegnante determina il peso da attribuire a compiti, partecipazione, quiz e test nella determinazione del voto globale, che varierà da insegnante a insegnante. Se si decide che i vantaggi hanno maggior peso degli svantaggi, aumentarne il peso rispetto agli svantaggi con il report che si ritiene più adatto. Se si decide che gli svantaggi hanno maggior peso dei vantaggi, regolare la ponderazione di conseguenza. Nell'esempio della tabella 2 è stato assegnato al vantaggio un peso relativo di 2 e allo svantaggio un peso relativo di 1, a significare che il vantaggio sarà un fattore maggiore nella determinazione della priorità finale.

Analogamente, possiamo determinare il peso della percentuale di costo e di rischio. Nell'esempio seguente, il rischio non è stato un problema sostanziale per il progetto, pertanto alla percentuale di costo è stato assegnato un peso di 1 e alla percentuale di rischio un peso di 0,5. Si noti che, sebbene il vantaggio e lo svantaggio vengano ponderati prima di calcolare la percentuale del valore, il costo e il rischio vengono ponderati come percentuali. Se si ha un progetto ad alto rischio, è possibile attribuire al rischio un peso maggiore del costo.

Dopo aver impostato i pesi, chiediamo agli utenti di valutare il vantaggio e lo svantaggio relativo di ogni funzionalità. Ogni vantaggio e svantaggio viene valutato su una scala stabilita (Weigers consiglia una scala da 1 a 9, ma è possibile sceglierne una diversa purché sia coerente). Il vantaggio relativo è il valore che apporterà la funzionalità; lo svantaggio relativo è l'impatto negativo potenziale del non avere la funzionalità.

Si supponga, ad esempio che una possibile funzionalità sia "Fare in modo che il widget sia conforme alle norme Sarbanes-Oxley". Non c'è praticamente alcun vantaggio relativo per gli utenti, ma lo svantaggio relativo per l'azienda è enorme: non implementarla significherebbe far fallire l'azienda. Per questo motivo, è possibile visualizzare un punteggio di 1 o 2 per il vantaggio relativo e un punteggio di 8 o 9 per lo svantaggio relativo.

Nell'esempio seguente, gli utenti hanno valutato il vantaggio relativo della funzionalità "Stato della query di un ordine del fornitore" come un 5. Lo svantaggio relativo è stato valutato come un 3. Per derivare il valore totale di tale funzionalità, moltiplichiamo i due numeri per i relativi pesi e li sommiamo:

(Benefit * Weight) + (Penalty * Weight) = Total Value

(5 *2) + (3*1) = 13

In questo caso, il valore totale della funzionalità è di 13 punti.

Dopo aver ottenuto il valore relativo totale e la percentuale del valore per le funzionalità, passiamo dal punto di vista degli utenti alla visione del team. Chiediamo al team di stimare il costo relativo per implementare ogni funzionalità usando la stessa scala. Karl Weigers spiega che "Gli sviluppatori valutano le stime dei costi in base a fattori quali la complessità dei requisiti, la portata del lavoro richiesto per l'interfaccia utente, la capacità potenziale di riutilizzare il codice o le progettazioni esistenti e i livelli di test e documentazione necessari".

Dopo aver stimato il costo relativo, stimiamo il rischio relativo. Weigers spiega ancora che "Gli sviluppatori stimano il grado relativo di un rischio tecnico o di altra natura associato a ogni funzionalità su una scala da 1 a 9. Una stima di 1 significa che è possibile programmarla senza alcun problema, mentre 9 indica la presenza di una serie di perplessità in merito alla fattibilità, la disponibilità di personale con competenze necessarie o l'utilizzo di strumenti e tecnologie sperimentali e non familiari. Nel foglio di calcolo verrà calcolata la percentuale di rischio totale che deriva da ciascuna funzionalità".

Dopo aver annotato i valori per vantaggio, svantaggio, costo e rischio relativi, sommiamo ogni colonna. I totali verranno usati per calcolare le percentuali.

• Percentuale del valore totale: suddividere il valore della somma del vantaggio e dello svantaggio relativi per la somma totale in basso. Nell'esempio seguente si avrà 13 / 154 = 8%.

• Percentuale del costo relativo: suddividere il valore del costo relativo per la somma totale del costo relativo in basso. Nell'esempio seguente si avrà 2 / 42 = 4,8%.

• Percentuale del rischio relativo: suddividere il valore del rischio relativo per la somma totale del rischio relativo in basso. Nell'esempio seguente si avrà 1 / 33 = 3%.

• Priorità: suddividere la percentuale del valore per (percentuale del costo * peso del costo) + (percentuale del rischio * peso del rischio). Nell'esempio seguente si avrà 8,4% / ((4,8% * 1) + (3% * 0,5) e si otterrà così il valore della priorità (1,345).

Dopo aver ottenuto i valori della priorità, ordiniamo la colonna della priorità in ordine decrescente in modo che gli elementi con priorità più elevata siano in alto. Man mano che si aggiungono elementi al backlog di prodotto o emergono informazioni su una storia, sarà necessario rivalutare la priorità.

Alla fine, il foglio sarà simile alla tabella seguente:

Adottando questo approccio, è possibile comprendere meglio la scelta adatta per il team e quella adatta per le parti interessate. È inoltre utile per organizzare meglio le discussioni poiché può essere difficile considerare obiettivamente elementi quali vantaggio, svantaggio, costo e rischio per ogni funzionalità.

Weigers spiega come rendere più realistico il modello:

"Calibrare questo modello secondo le proprie esigenze con un set di funzionalità o requisiti completi ricavati da un prodotto precedente. Regolare i fattori di ponderazione finché la sequenza di priorità calcolata non corrisponde alla valutazione di quanto fossero realmente importanti i requisiti nel set di test eseguita in un secondo momento. Questo modello può inoltre aiutare a prendere decisioni di compensazione durante la valutazione dei nuovi requisiti proposti. È possibile stimarne la priorità usando il modello per stabilire in che misura sono all'altezza dei requisiti esistenti, in modo da poter scegliere una sequenza di implementazione appropriata. Tutte le azioni che è possibile intraprendere per spostare la classificazione dei requisiti in ordine di priorità dall'ambito politico a uno obiettivo e analitico miglioreranno la capacità del progetto di fornire le funzionalità più importanti nella sequenza più appropriata".

Karl Weigers ha scritto due libri che descrivono più dettagliatamente la ponderazione relativa: Software Requirements, Second Edition e More About Software Requirements: Thorny Issues and Practical Advice.

Indipendentemente dal fatto che si utilizzi uno di questi metodi o un'altra tecnica, ricordare che il backlog di prodotto è un documento in continua evoluzione. La classificazione in ordine di priorità non viene eseguita una sola volta e quindi messa da parte, ma occorrerà ripetere questa operazione tutte le volte che sarà necessario in quanto fa parte delle regolari attività di gestione di un backlog. Per rispettare la tempistica del progetto, è necessario rivalutare costantemente le storie, la loro importanza per il progetto e il modo in cui le nuove informazioni influiscono sul backlog. Sarà necessario fare tutto il possibile affinché le parti interessate e i clienti siano coinvolti durante tutto il progetto. Inoltre, occorre ricordare che la valutazione di un elemento è fondamentale per determinarne la priorità. Non lasciare che i backlog diventino datati e obsoleti. Dedicare tempo e impegno alla realizzazione e alla gestione del backlog. I risultati saranno visibili non solo nel prodotto finale ma anche in termini economici.

Vedere anche

Concetti

Collaborare (approfondimento) [reindirizzamento]

Collaborare [reindirizzamento]

I commenti e suggerimenti delle parti interessate di revisione e di richiesta utilizzando team Web Access

Verificare il lavoro e gestire il flusso di lavoro [reindirizzato]

1. Agile Software Requirements, Dean Leffingwell, Addison Wesley

   “Attractive Quality and Must-be Quality” Noriaki Kano, Quality JSQC, Vol. 14, N. 2, ottobre 1984. Articolo originale di Kano.

2. First Things First: Prioritizing Requirements by Karl E. Wiegers