Pianificazione dello sprint

Di Mitch Lacey.Proprietario, Mitch Lacey & Associates, Inc, un'azienda di consulenza che si specializza in adozioni e miglioramenti 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 peso relativo di Karl Weigers.Uno di questi metodi consente 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; Team Foundation Server

In questo articolo:

• Introduzione

• Modello Kano di soddisfazione dei clienti

• Gioco di innovazione

  • Pulire le struttura ad albero

  • Acquistare una funzionalità

• Ponderazione relativa – Karl Weigers

• Conclusione

Per mantenere il team Agile in efficienza, è necessario ordinare gli elementi nel backlog del prodotto in base alla priorità e aggiornare tali priorità man mano che il progetto avanza.Tutti i backlog 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 rappresentano il successo del prodotto.Un backlog ben organizzato e con classificazione in ordine di priorità ripaga non solo nella soddisfazione del team e del clienti ma anche nella riga inferiore delle aziende.Per informazioni sui backlog, vedere Compilazione e gestione del backlog del prodotto, Creare o aggiungere al backlog prodotto e Pulire e stimare il backlog.

Nell'ordinare e classificare per priorità il backlog del prodotto, è necessario considerare molti fattori nonché poter spiegare le proprie decisioni.Quando si inizia a creare un backlog del prodotto non elaborato, il processo può apparire estremamente impegnativo.Fortunatamente, non è necessario ordinare perfettamente ogni elemento nel backlog immediatamente.In Stimare descrivo una tecnica denominata "The Big Wall", ovvero un modo efficiente per stimare rapidamente un backlog di prodotto non elaborato e un lavoro con le parti interessate per arrivare a una definizione di priorità approssimativa.

L'assegnazione di una priorità approssimativa è un buon punto di partenza e potrebbe essere indicata per le circostanze.In alcuni casi, tuttavia, è possibile ridefinire le priorità o arrivare a un backlog classificato in ordine di priorità in modo più scientifico.Per eseguire questa attività è possibile utilizzare molte tecniche.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 peso relativo di Karl Weigers.Uno di questi metodi consente 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 di Kano della 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 discriminanti e essenziali.Un approccio basato su un questionario, il modello è un metodo efficace di visualizzazione delle caratteristiche del prodotto e di stimolo di un dibattito all'interno del gruppo addetto alla progettazione.

In Kano poniamo una serie di domande in due form diversi: funzionale e disfunzionale.Si supponga, ad esempio, si stia chiedendo ai clienti un sistema di navigazione GPS per automobili.Innanzitutto chiediamo il modello funzionale della domanda:

• Come vi sentireste se questa automobile avesse a disposizione un sistema di navigazione GPS?

È necessario limitare le risposte alle risposte seguenti:

• Mi piacerebbe

• Mi aspetterei che fosse così

• Sono neutrale

• Mi ci adatterei

• Non mi piacerebbe

Si supponga, ad questo esempio, che i clienti fittizi abbiano risposto "Mi piace così".

Successivamente chiediamo form disfunzionale della domanda:

• Come vi sentireste se questa automobile non avesse a disposizione un sistema di navigazione GPS?

I nostri clienti fittizi possono scegliere da una qualsiasi delle risposte nell'elenco.Tuttavia, la risposta spesso è diversa.Si presupponga, ad esempio, che i nostri clienti fittizi abbiano risposto “Mi aspettavo che fosse così" al form malfunzionante della domanda.

Quando prepariamo queste domande per un progetto reale, possiamo porre l'elenco di domande contrastanti a più gruppi di clienti, vale a dire gruppi di utenti diversi che rappresentano le funzioni differenti dell'organizzazione del cliente.È possibile disporre di un gruppo di vendita, un gruppo contabile, un gruppo di creazione, e così via.Ai fini della comprensione del modello, tuttavia, immaginiamo di fare una sola domando a un solo gruppo del cliente.Dopo aver compilato la coppia di risposta (le risposte al form funzionale e disfunzionale), si eseguirà il mapping su una griglia, come mostrato nella tabella 1.

Tabella 1 - Mapping Kano

Si noti che, nell'esempio, avrà clienti fittizi volta risposto a come alla domanda funzionale e preveda la domanda disfunzionale.Quando si esegue il mapping di tale coppia alla griglia, è possibile 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 = Exciters.Queste sono funzionalità che il cliente non aveva previsto e che differenziano notevolmente un prodotto dalla concorrenza.Sono difficili da identificare, in particolare all'inizio, poiché può essere difficile ottenere le domande che evidenziano le funzionalità interessanti.Per questa ragione, gli eccitatori tendono a uscire e aumentare in priorità mano a mano che il progetto va avanti e che il feedback del cliente inizia.

  • I clienti ricevono molta soddisfazione da queste funzionalità e sono disposti a acquistare un prezzo premium pur di averle.Ad esempio, l'iPod della Apple deliziava i clienti con la capacità intuitiva di girare il contenuto in base all'orientamento dello schermo.L'assenza di tale funzionalità non avrà ridotto la soddisfazione, tuttavia, poiché il cliente non ne era informato per aspettarsela.

  • Nell'esempio disporre della navigazione GPS sarebbe una funzionalità interessante.L'esplorazione di questa funzionalità, almeno fino al punto di ricezione del feedback del cliente, deve essere una priorità relativamente alta.

• B = previsione.Queste funzionalità devono essere incluse nel prodotto.Sono funzionalità necessarie che hanno una priorità elevata.

  • Indipendentemente da come questi attributi di base vengono eseguiti, il cliente rimane sempre neutrale rispetto al prodotto.Un elaboratore di testo, ad esempio, deve disporre delle funzioni "crea documento" e "salva documento".Sono essenziali.

  • Se avessimo posto domande al gruppo di clienti sulle cinture di sicurezza, la maggior parte delle persone avrebbe risposto di aspettarsi che una nuova un'auto fosse dotata di cinture di sicurezza e che, in caso contrario, non l'apprezzerebbero.Se queste due risposte venissero mappate nella griglia, troveremmo che le cinture di sicurezza sono una linea di base (B), ovvero una caratteristica imprescindibile.

• L = Lineare.Noti anche come requisiti di prestazioni, le funzionalità lineari sono direttamente correlate alla soddisfazione del clienti.Vengono dopo le funzionalità di base per priorità ma richiedono un equilibrio con i costi.

  • La migliore funzionalità o la qualità di esecuzione aumenta la soddisfazione dei clienti.La funzionalità ridotta riduce la soddisfazione.

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

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

La tabella 1 mostra anche D e R.

• D: Dubbio: la domanda è probabilmente errata o la risposta è incerta.

• R: Contrario: la combinazione di risposte non viene calcolata.Richiamare il sistema di navigazione di GPS, se qualcuno risponde che prevede di essere presente ma che preferirebbe anche non esserlo, è una risposta R.

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

Gioco di innovazione

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 e input su un prodotto o un servizio.Luke Hohmann ha creato e descrive oltre 12 giochi nel libro, Innovation Games, un'aggiunta importante per qualsiasi libreria.I miei due giochi preferiti da riprodurre per ottenere un backlog classificato in ordine di priorità sono Prune the Product Tree e Buy a Feature, che Luke descrive in questo estratta dal libro (utilizzato su autorizzazione):

Pulire le struttura ad albero

I giardinieri potano gli alberi per controllarne la crescita.Talvolta l'eliminazione è artistico e si finisce con arbusti a forma di animali o interessanti forme astratte.Per la maggior parte del tempo l'eliminazione è progettata per compilare una struttura ad albero bilanciata che produce risultati di alta qualità.Il processo richiede più che altro la capacità di modellare il prodotto sulle esigenze dei clienti.

Game of Life

Iniziare creando una grande struttura ad albero su una lavagna o stampando un'immagine grafica di un albero come un poster di grandi dimensioni.I rami spessi rappresentano le aree principali di funzionamento nel sistema.Le estremità dell'albero, i rami più esterni, rappresentano le funzionalità disponibili nella release corrente.Scrivere le nuove funzionalità potenziali su più schede, idealmente a forma di foglia.Richiedere agli utenti di inserire le funzionalità desiderate attorno all'albero, definendo la fase successiva della crescita.Stanno strutturando un albero che cresce in modo bilanciato?Un ramo, ad esempio una funzionalità chiave del prodotto, cresce più degli altri?Un aspetto poco utilizzato dell'albero diventa più visibile?È noto che le radici di un albero (l'infrastruttura di supporto e di assistenza clienti) devono estendesi lontano almeno quanto la chioma.E le vostre?

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à qui importanti, ovvero quelle che forniscono il valore più grande 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 input al processo decisionale esaminando il set di funzionalità che costituiscono il prodotto in un modo olistico.

Acquistare una funzionalità

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

I pianificatori del prodotto dibattono senza fine questi e altri tipi di domande.La scelta del giusto set di funzionalità da aggiungere a un rilascio spesso contrassegna la differenza tra errore a breve termine e riuscita a lungo termine.Sfortunatamente, troppi pianificatori del prodotto prendono questa decisione senza coinvolgere le persone più interessate, ovvero i clienti.Il gioco Buy a Feature migliora la qualità di questa decisione chiedendo ai clienti di aiutarvi a eseguirlo.

Acquistare una funzionalità - Sterne

Game of Life

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 desidera addebitare per la funzionalità, in genere non è richiesto.I clienti acquistano le funzionalità che desiderano nel rilascio successivo del prodotto utilizzando soldi finti.Accertarsi che il prezzo di alcune funzionalità sia abbastanza alto per evitare che vengano acquistate da qualsiasi cliente.Incoraggiare i clienti a raccogliere i propri soldi per comprare le funzionalità particolarmente importanti e/o onerose.In questo modo vengono stimolate le trattative tra i clienti per determinare quali funzionalità sono più importanti.

Il gioco funziona meglio con un gruppo da 4 a 7 clienti, in quanto permette di creare più opportunità per i clienti di guadagnare denaro con la negoziazione.A differenza del gioco della Confezione del prodotto, il gioco dell'Acquisto di una funzionalità è basato sull'elenco di funzionalità che probabilmente sono presenti nella guida di orientamento allo sviluppo.

Motivo del successo

I pianificatori del prodotto incorrono spesso nel trabocchetto di ritenere che i clienti hanno ben definitole priorità del prodotto.Alcuni lo fanno.La maggior parte non lo fa.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 del prodotto spesso raccolgono le priorità della funzionalità lavorando personalmente con i clienti e, nel processo e forse anche senza rendersene conto, si prendono nuovamente la responsabilità di classificare le funzionalità in ordine di priorità.Impegnando i clienti come gruppo e fornendo loro una quantità limitata di risorse, gli viene fornita la possibilità di classificare in ordine di priorità i desideri di gruppo.Ma la magia non è questa.Il trucco sta nell'impostare i dibattiti con i clienti in modo che questi trovino tra loro un accordo su funzionalità specifiche.È questa negoziazione che migliora la comprensione di ciò che i clienti che desiderano effettivamente.

Ponderazione relativa – Karl Weigers

Un altro metodo eccellente per assegnare le priorità è la ponderazione relativa 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 al feedback dell'utente ma include anche il giudizio esperto del team.Come Kano e Innovation Games, la ponderazione relativa consente al proprietario del prodotto di decidere meglio quali funzionalità implementare e in quale ordine di priorità.

Il primo passaggio consiste nell'assegnare un peso ai vantaggi relativi di una funzionalità.Un vantaggio è la possibilità per gli utenti di disporre della funzionalità nel prodotto finito.Successivamente è opportuno assegnare la penalità relativa.Lo svantaggio è la conseguenza per gli utenti di non disporre della funzionalità nel prodotto finito.(La valutazione dei vantaggi e delle penalità esegue la stessa operazione del form della domanda funzionale e disfunzionale 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 l'importanza 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 superano le penalità, aumentare il peso rispetto alla penalità con il rapporto che si ritiene più adatto.Se si decide che le penalità superano i vantaggi, modificare la ponderazione di conseguenza.Nell'esempio nella tabella 2 è stato fornito il vantaggio di un peso relativo di 2 e la penalità di un peso relativo di 1, a significare che il vantaggio è 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 la penalità siano soppesati prima che venga calcolata la percentuale di valore, il costo e il rischio sono soppesati come percentuali). Se si dispone di un progetto ad alto rischio, è possibile valutare il rischio superiore al costo.

Ora che i pesi sono impostati, chiediamo agli utenti di valutare il vantaggio relativo di ogni funzionalità e la pena relativi.Ogni vantaggio e penalità viene valutata su una scala stabilita (Weigers consiglia da 1 a 9, ma è possibile scegliere una scala diversa purché sia coerente).Il relativo vantaggio è il valore che la funzionalità offrirà; lo svantaggio è il potenziale impatto negativo del non creare la funzionalità.

Si supponga, ad esempio che una possibile funzionalità sia "Fare in modo che il widget sia conforme alle norme di Sarbanes-Oxley". Non c'è praticamente alcun vantaggio relativo per gli utenti, ma il problema relativo per l'azienda è enorme: non farlo significherebbe porre l'azienda al di fuori del business.Analogamente, è possibile visualizzare uno punteggio di 1 o 2 per il vantaggio relativo e un punteggio di 8 o 9 per la penalità relativa.

Nell'esempio seguente, gli utenti hanno valutato il vantaggio relativo della funzionalità relativa allo "stato di query di un ordine fornitore" come un 5.Il relativo svantaggio è stato valutato a 3.Per derivare il valore totale di tale funzionalità, si moltiplicano i due numeri per i relativi pesi e li si somma:

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

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

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

Quando otteniamo il valore relativo totale e la percentuale di valore per le funzionalità, ci allontaniamo dagli utenti per raccogliere spunti dal team.Viene chiesto al team di stimare il costo relativo per implementare ogni funzionalità utilizzando la stessa scala.Karl Weigers spiega, "Gli sviluppatori valutano le stime dei costi in base a fattori quali la complessità dei requisiti, la portata del lavoro dell'interfaccia utente richiesto, la capacità potenziale riutilizzare le progettazioni o il codice esistente e i livelli di test e documentazione necessari".

Dopo stimiamo il costo relativo, stimiamo il rischio relativo.Di nuovo Weigers dice: "Gli sviluppatori stimano il grado relativo dei rischi tecnici o rischi in generale associati a ogni funzionalità su una scala da 1 a 9.Una stima di 1 significa che è possibile programmarlo nel sonno, mentre 9 indica una grave preoccupazione sulla fattibilità, la disponibilità dei dipendenti con competenze necessaria, o l'utilizzo degli strumenti e tecnologie non conosciuti.Nel foglio di calcolo verrà calcolata la percentuale di rischio totale che deriva da ciascuna funzionalità".

Dopo aver annotato i valori per il vantaggio di, la penalità, costo e il rischio, sommiamo ogni colonna.I totali verranno utilizzati per calcolare le percentuali.

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

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

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

• Priorità: Suddividere la percentuale di valore per (percentuale di costo * peso del costo) + (percentuale di valore * peso del valore).Nell'esempio seguente, 8,4% / ((4,8% * 1) + (3% * 0,5).Viene così fornito il valore di priorità (1,345).

Dopo aver ottenuto i valori di priorità, viene ordinata la colonna di priorità in ordine decrescente in modo che gli elementi con priorità più elevata siano in alto.Quando gli elementi vengono aggiunti al backlog prodotto o vengono visualizzate altre informazioni su una storia, sarà necessario riassegnare la priorità.

Alla fine, l'aspetto del foglio è simile a questa tabella:

Adottando questo approccio, è possibile comprendere meglio gli intervalli che funzionano per il team e per le parti interessate.È inoltre utile per definire le discussioni poiché può essere difficile inserire obiettivamente elementi come vantaggio, penalità, costo e rischio per ogni funzionalità.

Weigers spiega come rendere più realistico il modello:

“Calibrare questo modello in base al proprio l'utilizzo con un set di requisiti completati o di funzionalità da un prodotto precedente.Regolare i fattori di peso finché la sequenza di priorità calcolata non si accorda con la valutazione successiva di quanto erano realmente importanti i requisiti nel test set.Questo modello può inoltre aiutare a prendere decisioni di compensazione durante la valutazione di nuovi requisiti proposti.Stimare la priorità utilizzando il modello per indicare come corrispondono in base ai requisiti esistenti, in modo che sia possibile scegliere una sequenza appropriata di implementazione.Tutte le azioni che è possibile eseguire per spostare la priorità dei requisiti dall'area politica in una obiettive e analitica miglioreranno la capacità del progetto di fornire funzionalità più importanti nella sequenza più appropriata".

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

Che si utilizzi uno di questi metodi o un'altra tecnica, ricordare che il backlog del prodotto è un documento in continua evoluzione.Non viene classificato in ordine di priorità una sola volta e quindi messo da parte; la riprioritizzazione è prevista una parte di gestione del backlog compilazioni.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.È necessario intraprendere dolori per mantenere le parti interessate e clienti coinvolti in tutto il progetto.Inoltre, occorre ricordare che la stima di un elemento è fondamentale per determinarne la priorità.Non lasciare che i backlog diventino non aggiornati e vengano annullati.Dedicare tempo e impegno alla realizzazione e alla pulizia del backlog. I risultati verranno visualizzati non solo nel prodotto finito ma anche nei risultati economici.

Vedere anche

Concetti

Attività iniziali di un team

Pianificazione Agile e iterazioni

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

Verificare il lavoro e gestire il flusso di lavoro

1. Requisiti del software Agile, Dean Leffingwell, Addison Wesley

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

2. http://www.processimpact.com/articles/prioritizing.html