Qual è lo scopo di pianificare il poker in uno sprint?

Il nostro analista aziendale e i responsabili del progetto ci dicono che il cliente ha bisogno di storie. Ogni pianificazione Sprint, a noi (sviluppatori) viene chiesto di giocare a poker di pianificazione.

Hanno chiesto a tutti noi di considerare la "complessità" anziché "lo sforzo". Siamo davvero confusi e stiamo perdendo tempo nei nostri incontri. Uno sviluppatore ha posto una domanda: "Cosa dovremmo davvero considerare? Riguarda la modifica del codice / DDL che dobbiamo fare in questo requisito (stima del tempo) o se abbiamo capito o no il requisito? "

Ma cosa significano veramente (analista aziendale e responsabile del progetto) per "comprendere il requisito" e "raccogliere una carta"?

Inoltre, abbiamo riunioni di suddivisione per singoli team di scrum, in cui ogni sviluppatore fornisce una stima del tempo per un determinato compito per ciascun team di scrum. Quindi, di che genere di cose stanno davvero parlando in Planning Poker?

Qualcuno può spiegare questo usando un esempio? Cerca di differenziare ciò di cui stanno realmente parlando quando dicono "Complessità" e "Sforzo".

Considera il punto di vista del Project Manager

Chiedendo complessità vogliono un numero che possano confrontare con il tuo prossimo sprint per trovare la tua velocità come squadra. Potrebbero anche tentare di utilizzarlo per sommare il risultato con le stime di altri team per fornire una stima globale su quando tutte le storie saranno completate.

Il project manager sta cercando una stima di quando il progetto sarà finito, o se sono flessibili su altri lati del triangolo costo-funzione-tempo, quali altri fattori possono essere estratti per adattarlo al tempo rimanente. Questo non è irragionevole. Le decisioni commerciali dovranno essere prese sulla base di questa stima. Il problema è che è davvero difficile stimarlo per il software. Pianificare il poker è uno dei modi per aiutare con questo problema. Piuttosto che vederlo semplicemente sommando il numero di punti della storia, piuttosto pensalo come una funzione più complessa di stimare il più possibile, fare il lavoro, misurare il tempo impiegato, iterare e quindi estrapolare.

La discussione è più importante di un numero

Trovo che la parte più importante degli incontri di puntamento della storia siano le discussioni che si presentano. Se qualcuno nel team non è sicuro di suggerire un numero, probabilmente non capirà completamente la storia e ci sarà bisogno di più discussioni. Dal Manifesto Agile "Collaborazione del cliente sulla negoziazione del contratto". Piuttosto che specificare semplicemente un contratto scritto come user story e dire che il team ha fallito se non fanno esattamente quello che vuoi, è sempre meglio parlare di ciò che il cliente vuole davvero fino a quando non lo capisci.

Complessità vs sforzo

Per rispondere alla tua domanda specifica sulla complessità e sullo sforzo, tutti sembrano avere un'opinione diversa su questo. Mountain Goat , che sono le persone che creano le carte da poker di pianificazione che hanno delle capre sul retro e il cui proprietario Mike Cohn è grande nel mondo Agile / Scrum, afferma che dovrebbe essere uno sforzo e non una complessità.

Normalmente non è considerato una misura del tempo (vedere l'esempio seguente per un contro esempio) poiché le persone sono pessime nella stima del tempo, con altri fattori che influenzano il numero che danno: ad esempio la pressione per mantenere basso il numero in modo da poter adattare più funzioni in, la pressione per dare un numero più alto per darti un po 'di spazio se ti imbatti in un problema. Costruire software è difficile. Quando costruisci la tua centesima casa, puoi stimare quanto tempo ci vorrà perché hai già costruito 99 case. Se il software che stai costruendo è lo stesso dei programmi precedenti che hai creato, puoi copiarlo e incollarlo, qualsiasi valore mentre il progetto software è diverso e quindi avrà problemi che non avevi previsto all'inizio.

Come per le stime temporali che contengono pressioni nascoste, anche una certa misura di sforzo presenta problemi. Se uno sviluppatore junior stima un'elevata complessità, può pensare di lasciarsi aperto agli attacchi perché non è abbastanza bravo da altri che gli darebbero una stima più bassa. Questo non è solo dannoso per le tue stime ma per le persone del team.

I numeri del poker di pianificazione non sono "numero di giorni" o qualche altra misura del tempo, sono una misura relativa per poter confrontare due storie utente. La prima cosa che devi fare in una nuova squadra è stabilire una linea di base. Scegli una user story che si trova al centro dell'intervallo di complessità e concorda come squadra un numero al centro dell'intervallo che desideri assegnare. Ora tutte le altre storie utente possono essere numerate rispetto a questa. Ho scoperto che questo rende molto più semplice.

Motivi per cui non puoi fornire un preventivo

Quando i project manager ti chiedono quando sarà fatto un progetto, devono capire la complessità della domanda che stanno ponendo. I programmatori non sono operai di fabbrica, dove la loro produttività può essere misurata moltiplicando la velocità con cui digitano per quanto tempo lavorano. Stanno scoprendo le risposte ai problemi ed è difficile. Giocando a poker di pianificazione, identifichi innanzitutto chi nella squadra sente di non poter rispondere alla domanda su quale numero assegnare e poi approfondisci il motivo per cui non possono rispondere a questa domanda. Penso che ci siano almeno quattro ragioni:

1. La storia è troppo grande. Suddividilo in storie utente più piccole e specifiche. Ricorda che ogni user story dovrebbe fornire all'utente un valore; input - process - output = value.
2. Non capiscono abbastanza bene il dominio problematico da poter dire quanto tempo impiegherà o addirittura porre tutte le domande correttamente. Parla con persone che conoscono meglio il dominio / la programmazione delle parti interessate quel tipo di applicazione, qualunque cosa tu non abbia mai visto prima. Se ciò non è possibile o non ti porta fino in fondo, puoi usare un picco di design. Vai e prototipa una soluzione, ma solo per un periodo di tempo limitato e specificato . Definisci per quanto tempo durerà la fase di prototipazione, non troppo a lungo, quindi incontra nuovamente il backup per condividere le tue nuove conoscenze.
3. Le parti interessate non sono abbastanza specifiche. "Build me a cloud" non è una user story accettabile. "Costruiscimi un sistema in cui posso far girare le VM su richiesta" è meglio in quanto è ulteriormente suddiviso ma non è ancora al livello in cui puoi dare una stima accurata di quanto tempo ci vorrà perché ci saranno centinaia nascosti ipotesi in quella dichiarazione che il tuo stakeholder ha che non scoprirai finché non mostri loro qualcosa.
4. Infine, anche se puoi dare un preventivo, probabilmente sarà sbagliato la prima volta. La stima è un problema difficile e il modo migliore che conosco per risolvere problemi difficili è usare il metodo scientifico. Raccogli i dati sui numeri stimati da ciascun membro del team, quindi raccogli i dati su quanto tempo li impiegava davvero o su quanto fosse "complesso", anche se più difficile, e confrontali nel tempo. Alla fine avrai un'idea di chi sopravvaluta e di chi sottovaluta e quindi dovresti condividerlo con il team. Le persone possono aiutarsi a vicenda per migliorare nella stima. Questi numeri possono anche essere reinseriti nello strumento di monitoraggio per aiutare a prevedere meglio il tempo necessario per le storie.

Conclusione

Credo che il punto dovrebbe davvero essere la discussione, ma se hai davvero bisogno di dare un numero a qualcuno, prova semplicemente a renderlo indipendente da quale membro del team ci lavora e in quale ordine vengono elaborate le storie. Il punto è quello di accedere a un registro di back che ha entrambe le priorità, quindi ci stai lavorando nell'ordine giusto e dimensionato, in modo che il Project Manager possa vedere all'incirca quanti altri puoi inserire prima della scadenza. Dovresti essere in grado di interrompere alla fine di ogni iterazione e spedire con tutte le funzionalità completate che erano state avviate.

avvertimento

Puoi stimare il tempo necessario per completare le attività all'interno della tua squadra quanto vuoi, purché tu mantenga i numeri per te. Quando permetti a qualsiasi numero di sfuggire alla squadra e di essere visto da altre persone, faranno cose con quel numero che non avevi intenzione di fare. Proveranno ad usarlo come numero di giorni per completare le attività. Proveranno a mantenerti al relativo grado di complessità e ti chiederanno perché hai impiegato più tempo a completare una storia utente rispetto a un'altra con lo stesso numero di punti. Aggiungeranno i tuoi numeri insieme e li confronteranno con i numeri dell'altra squadra e ti chiederanno perché l'altra squadra 'sta facendo più lavoro' mentre completano più punti trama in un periodo di tempo. Puoi'

A parte

Il set di numeri del poker di pianificazione viene normalmente distribuito in modo tale che gli spazi tra i numeri continuino a crescere. Credo che questo abbia lo scopo di scoraggiare le persone dal discutere se una user story sia un 16 o un 17, se è più grande di un 13, quindi trasformalo in un 20.

Esempio

Conosco almeno una squadra che utilizza solo i numeri 1, 2, 3 e 4 per pianificare il poker. Loro, contrariamente alle convenzioni e contrariamente alla discussione sopra, li definiscono giorni di programmazione (in realtà abbinano i giorni di programmazione, ovvero quanti giorni ci vorranno due programmatori che lavorano insieme sulla stessa macchina per completare la storia dell'utente). Se il team pensa che occorrerebbero più di 4 giorni per completare una storia dell'utente, non viene lasciata la storia puntata e al proprietario del prodotto viene chiesto di lavorare con la squadra per scomporre ulteriormente la storia o per specificarla più esattamente in modo che possa essere portato in questo intervallo per un futuro incontro di pianificazione. Ma questo è avanzato agile e probabilmente dovrebbe essere usato solo da persone che hanno già esperienza nell'uso delle altre tecniche.

Penso che le risposte di Frank ed Encaita coprano praticamente tutto, ma ci sono alcune cose aggiuntive da considerare:

Perché usare i punti trama

Lo scopo della stima con i punti della storia è quello di dare la relativa complessità dello sviluppo di funzionalità per la tua applicazione. Un modo semplice per pensarci è prendere una storia che hai nel prossimo sprint, ad esempio un cambio di url. Sai che questo è semplice in termini di complessità e ha chiaramente definito i criteri di accettazione, quindi tutto il team concorda sul fatto che anche con i test è un 1 (usando la scala Fibo).

La prossima storia da stimare è l'aggregazione di un insieme di dati utente e la visualizzazione di quello sul front-end. Ora come sviluppatore sai immediatamente che questo è molto più complesso rispetto alla modifica di un URL. Discuti la storia e i criteri di accettazione e hai molte domande e puoi vedere diverse potenziali soluzioni per farlo. Anche gli altri sviluppatori e il QA concordano che è molto complesso. Quindi siete tutti d'accordo sul fatto che si tratta di una storia di 34 punti. Vale la pena notare che la scala Fibo ti consente anche di indicare quanta fiducia hai nell'esimate - maggiore è il divario tra i numeri, minore è la fiducia che hai nella tua stima

A questo punto il tuo maestro Scrum dovrebbe saltare e dire che questo come una singola storia è troppo grande e deve essere suddiviso in storie più piccole di minore complessità. Puoi affrontarlo facendo ciò che sono noti come SPIKES - questo è solo un po 'di tempo dedicato a indagare su qualcosa. Quindi, per questo esempio, tu e gli altri sviluppatori concordate che volete 4 ore per discutere e studiare le possibili soluzioni tecniche.

Per farla breve, dividi quella grande storia in altre quattro storie di 5, 8, 8 e 13 punti. Non ricordate che queste stime sono tutte relative alla complessità relativa: non devono sommarsi alla stima originale e in più avete più informazioni ora per fare una stima più accurata.

Accetti quindi come squadra che per questo sprint mirerai a fare la storia di 13 punti, una storia di 8 punti più il cambiamento di url di 1 punto che hai già identificato. Quindi un totale di 22 punti. Al prossimo sprint ottieni 27 punti, al successivo sprint ottieni 18 punti. Dopo 3 sprint puoi iniziare a prendere confidenza con la tua velocità (la velocità è la quantità di lavoro che la tua squadra può fare in uno sprint). Per ottenere la velocità, prendi la media degli sprint precedenti. Quindi in questo esempio la media è (22 + 27 + 18) / 3 = 22.3, quindi arrotondala al più vicino sulla scala Fibo che è 21.

Ora, per il prossimo sprint, punta solo a fare 21 punti.

Non rimanere impaziente di ottenere la stima del punto della storia esattamente nel modo giusto - non è una scienza esatta. Sai che una modifica dell'URL è molto meno complessa dell'aggregazione dei dati, quindi votala di conseguenza.

Inoltre, discutere di queste cose come una squadra è positivo. Guarda le tue stime durante la revisione dello sprint e discuti se ne eri soddisfatto o meno e poi inseriscilo nella prossima sessione di pianificazione dello sprint.

La stima di tutto il team

L'intero team deve concordare una singola stima per ogni storia. Una funzione non viene eseguita fino a quando non è pronta per la produzione. Basta ottenere il codice scritto non è affatto fatto. Nella mia esperienza, i team Scrum sono stati molto più efficaci quando hanno lavorato in team. Fai un esempio del team con cui sto lavorando in questo momento. Quando mi sono unito, stavano facendo tutte le riunioni dello sprint e pianificando il poker, ma durante lo sprint il processo era 1. I BA / i proprietari dei prodotti definiscono i requisiti come storie con criteri di accettazione e test di accettazione 2. Consegnano questi requisiti allo sviluppatore che quindi scrive il codice 3. Lo sviluppatore ha unito il codice nel ramo di sviluppo affinché il controllo qualità possa testare 4. Il test di controllo qualità inizia quindi a porre domande e i test falliscono, quindi torna allo sviluppo.

Cosa manca qui? Non c'è abbastanza discussione in anticipo e ogni membro del team ha visto solo il proprio compito. Ora il BA / PO, gli sviluppatori e il QA si incontrano prima di scrivere qualsiasi codice per discutere dettagliatamente i requisiti e porre domande in anticipo, quindi continuare la discussione durante lo sprint. Questo è molto più efficiente e porta a soluzioni di qualità migliore.

Pianificare il poker aiuta questo processo perché costringe il team a discutere la caratteristica e concordare, come squadra, quanto sia complessa la consegna di quella funzione. Nello sviluppo di software tradizionale il Project Manager era responsabile della consegna del progetto, ma chiunque abbia esperienza di tale approccio sa che non funziona perché il più delle volte, le persone non si assumono la responsabilità per la loro parte nella consegna dell'applicazione. In Agile non dovresti avere bisogno di project manager perché il team si assume la responsabilità nel suo insieme per la consegna dell'applicazione.

Stima puntuale dei compiti

La mia opinione di aver lavorato con i team che stimano il tempo in compiti e team che fanno solo stimare i punti della storia è NON FARE PREVENTIVI! In realtà sono solo una perdita di tempo. Non sono accurati come i punti della storia perché sono specifici per gli individui, non per la squadra, e ogni individuo avrà un'idea diversa della stima del tempo (accendi la fiamma).

I punti della storia accettano che le cose, ad esempio i requisiti, cambiano continuamente, quindi è davvero necessario un indicatore di ciò che il team può completare in uno sprint.

Una volta che hai capito la velocità, puoi misurare i tuoi risultati in tempo perché sai cosa puoi fare in ogni sprint, ad esempio ogni due settimane sai quali funzionalità possono essere fornite. La tua scrum master e i proprietari dei prodotti dovrebbero avere sessioni di stima per guardare avanti agli sprint futuri, quindi puoi ottenere un indicatore di quanto lavoro farai nei prossimi mesi. Ciò consente ai proprietari di prodotti di prendere decisioni in ordine di priorità su quali funzionalità includere nell'applicazione finale.

Ho chiesto agli sviluppatori di stimare il tempo necessario per pianificare le attività, ma in realtà non sono d'accordo con questo approccio (in realtà non sono molto d'accordo con questo approccio) perché non è accurato, ad es. Cosa ci vorranno davvero per 4 ore: uno sviluppatore potrebbe includere solo il tempo sull'attività stessa, qualcun altro potrebbe aggiungere tempo per preparare tazze di tè!

Le stime dei tempi vengono sempre consegnate a qualcun altro a scopo di reportistica e sottolinea in modo eccessivo i singoli elementi della fornitura di una funzionalità rispetto all'intero sforzo del team.

La stima non è il problema più grande

A parte questo, capire la stima non è il problema più grande che penso che i team debbano risolvere. La cosa più importante è lavorare insieme come una squadra per fare le cose durante lo sprint, in modo da non consegnare tutto per i test dell'ultimo giorno. Vuoi vedere una serie costante di funzionalità durante lo sprint di 2 settimane. La dinamica del team che ho spiegato sopra è una grande parte di questo. La stima del punto della storia ti aiuterà a pianificare questo perché vedrai quali sono le grandi storie che devono essere scomposte in quelle più piccole che possono essere consegnate regolarmente ai test.

Wikipedia spiega abbastanza bene la pianificazione del poker . Permettetemi di ricapitolare parte di ciò che è stato lì con un focus sul tuo caso:

Perché pianificare il poker?

Prima di tutto, dovresti essere tutti d'accordo sul perché stai pianificando un poker piuttosto che su una stima "normale". La ragione è in realtà abbastanza semplice: tutti noi facciamo schifo quando si tratta di stimare il tempo per un compito. Praticamente ogni studio ha rivelato che il cervello umano è semplicemente incapace di stimare compiti che richiedono un ragionevole lasso di tempo. (Anche un motivo, perché i biglietti che superano i 2-3 giorni nella loro stima sono praticamente inutili in termini di stima.)

Perché la complessità piuttosto che lo sforzo?

Questo va di pari passo con quanto sopra. Lo sforzo di solito significa tempo , e noi ci facciamo schifo. La complessità invece è difficile da quantificare oggettivamente, il che è una buona cosa in questo caso. È il tuo istinto che ti dice che questa storia sarà complessa. Per qualcun altro potrebbe essere meno complesso. Ma non è necessario quantificare esattamente quanto sia realmente complesso. Non hai bisogno di ottenere questo numero Xdi complessità - al contrario di uno sforzo a tempo, dove alla fine devi essere d'accordo che ci vogliono Xgiorni o qualcosa del genere.

Perché nascondere le carte?

Le carte con la tua complessità ospite vengono giocate nascoste e poi rivelate tutte in una volta. Questo viene fatto per assicurarti di non essere influenzato dalle opinioni di altre persone prima di fare il tuo preventivo iniziale. Se tutti hanno la stessa sensazione visiva in termini di complessità, allora il gioco è fatto. Se ci sono numeri selvaggiamente diversi, sai che c'è qualcosa da discutere nascosto lì. In questo modo, puoi affrontare molto rapidamente storie per le quali tutti hanno la stessa idea della complessità / sforzo richiesti.

Perché i numeri di Fibonacci?

I numeri sulle tue carte sono in genere numeri di Fibonacci o qualche altro tipo di sequenza con molte lacune nei numeri. Questo per obbligarti a fidarti completamente del tuo istinto. Se devi scegliere tra 8 e 13, è molto più un'affermazione che andare per 9 o 10. Inoltre, come menzionato sopra, le grandi differenze sono dovute ai problemi nascosti, quindi allargando le lacune, aumenti le possibilità di rilevare meglio questi problemi.

Perché funziona tutto questo?

È interessante notare che le prime volte che fai un poker di pianificazione non funzionerà. E 'così semplice. Cosa significa "3" o "5"? Non esiste una definizione per ciò che significa ogni numero (apposta!) E spetta a tutta la tua squadra scoprire il significato reale dietro ciascuno di questi numeri. Solo dopo aver accettato di stimare le tue storie in questi numeri - e dopo averne realizzato parecchi di questi - avrai un'idea migliore di quando dovresti aumentare un 5 e quando invece è un 8.

Una volta combinato questo con il concetto di velocità e misurando i tuoi progressi di sprint attraverso questi punti della storia, hai una scala completamente nuova di efficienza che è più o meno indipendente dalle stime temporali tradizionali.

Tuttavia, per me personalmente, il punto più vantaggioso di pianificare il poker è che usando i numeri di fibonacci anziché le stime del tempo, hai un tempo molto più facile per rilevare le incertezze. Con le stime del tempo classico non sei costretto a prendere decisioni "estreme" (a causa delle lacune numeriche), quindi le stime potrebbero essere piuttosto vicine tra loro e il team potrebbe credere erroneamente di aver capito abbastanza bene la storia.

Esempio

Un semplice esempio di ciò che accade in genere è che viene presentata una storia e quindi la persona A presenta un'obiezione. È qualcosa del genere "per favore, non dimenticare che questa funzionalità influisce su X e questo può significare che è più costoso di quanto pensassimo finora". Il problema principale è che c'è sempre questa persona A al tavolo. C'è sempre qualcosa di cui qualcuno è preoccupato. Se hai una discussione aperta, non hai davvero idea di quanto sia grande questa cosa X.

Se fai stime nascoste in base al tempo, allora migliora un po '. Tuttavia, una persona A con un'obiezione valida potrebbe non essere ancora un chiaro outlier nella sua stima. D'altra parte, con la pianificazione del poker, la persona A deve riflettere di più su quanto sia un vero problema X. Per due diversi problemi, non è possibile distinguere correttamente la loro importanza dal "testo di obiezione" sopra menzionato. Anche con le stime del tempo è piuttosto difficile capire quale sia un problema. La speranza di usare la pianificazione del poker qui è che si finisce con un'obiezione che è solo 2-3 punti diversa dalle stime degli altri, ma l'altra obiezione che è finita a 5 o 8 punti dalla mediana potrebbe essere solo l' incertezza più importante della tua pianificazione dello sprint.

Dopo dozzine di iterazioni nel mio team, abbiamo capito che i punti della storia riguardano principalmente la direzione di progetti a medio termine. Consentono al proprietario del prodotto di proiettarsi in anticipo di 2 o 3 sprint e, in sostanza, di prendere decisioni aziendali e di ambito su un rilascio, in base a una velocità media.

Abbiamo scoperto che i punti della storia non sono molto utili a livello di sprint, perché non ci sono 2 sprint simili e predire quanto lavoro sarà impossibile è impossibile. Di conseguenza, abbiamo deciso che non dovremmo essere ossessionati dalla parte di stima e prendere semplicemente la pianificazione delle sessioni di poker come pretesti per la conversazione sulle funzionalità.

Ciò concorda con un punto sollevato da Mike Cohn qui .

Come nota a margine, questo è vero per una determinata squadra, ma non ci sono regole su come i punti della storia ti aiuteranno. Ti consiglio di attenerti prima alla metodologia, ma prova a scoprire rapidamente da solo se e come sono utili. Le retrospettive ti aiuteranno a riflettere su questo.

Il problema fondamentale qui è che è rotto. Il PM vuole usare il poker programmato per farsi un'idea della complessità di ogni storia, con l'intenzione di sapere approssimativamente quante storie possono essere inserite in uno sprint (la velocità della squadra).

Di conseguenza, è un "non basato sul tempo" che è "basato sul tempo". Non c'è da meravigliarsi se tutti vengono confusi.

Ci sono modi per farlo funzionare per te. Innanzitutto dimentica lo sforzo e concentrati sulla complessità. Dimentica tutto il tempo necessario per lo sviluppo e concentrati invece sulle aree interessate da ogni storia. Se hai una storia che aggiorna il DB, il codice del server, il codice client e la documentazione del client, allora puoi dire che è una storia in 4 punti. Se è solo una modifica al DB sql, allora è una storia a 1 punto. Questo ti dà un modo più comprensibile di capire la complessità relativa tra le storie. (Dovrai elaborare alcune metriche che hanno senso per le tue circostanze, magari testare i requisiti di copertura o la complessità dell'interfaccia utente)

La mia opinione generalmente però è che è una inutile perdita di tempo che incoraggia semplicemente la pianificazione dello sprint come se fossero progetti di mini cascate. A chi importa davvero quanti punti della storia puoi inserire in uno sprint? Se hai lasciato delle storie alla fine di uno sprint, le fai solo nel prossimo. Detto questo, potresti anche rendere il tuo backlog delle dimensioni di ogni storia eccezionale che hai e gradualmente ridimensionarle nel tempo. La consegna richiede tutto il tempo necessario (ma sarà più veloce se non ti sei preoccupato di perdere il 20% del tuo tempo in riunioni di pianificazione degli arretrati e degli sprint). Alla fine del progetto, a nessuno importa quanti punti della storia sono stati consegnati. Ciò che interessa alle persone è il progetto consegnato.

Inoltre, l'individuazione della storia degli utenti offre all'azienda un vantaggio in termini di se qualcosa deve essere rinegoziato. se hai un mese per completare alcuni lavori che hai segnato come 100, potresti essere nei guai. ti dà anche la possibilità di spezzare una storia epica in qualcosa di più piccolo che ha ancora valore e può essere completato in uno sprint.