Stima delle caratteristiche di un gioco software
Ron Jeffries ha proposto un software sfida di stima per determinare il probabile sforzo richiesto per fornire le prossime funzionalità di un gioco che lui e il suo team stanno scrivendo. Ho deciso di raccogliere questa sfida ed effettuare una stima del dimensionamento COSMIC e, forse, così facendo, attirerò alcune teste verso i meriti della stima della CFP e come può aiutare con il pensiero progettuale.
Ci viene chiesto di stimare lo sforzo richiesto per progettare alcune funzionalità all'interno di un gioco parzialmente costruito, ecco il requisito di alto livello:
Fornire la possibilità a un membro del team di progettazione livelli di controllare il posizionamento degli oggetti del dungeon, inclusi mostri, punto di partenza del giocatore, oggetti decorativi contenenti bottino e il bottino in essi contenuto, e oggetti bottino indipendenti.
C'è più contesto che può essere letto qui:
https://ronjeffries.com/articles/-z022/0222ff/cfp-est-chal/
Questo è un requisito di alto livello. Ci sono molte cose che non sappiamo. Non è possibile una misurazione precisa della CFP del software finale consegnato, ma possiamo misurare i requisiti a condizione che siano sufficientemente chiari per un'interpretazione coerente.
I due motivi principali per cui si richiede un preventivo per avere un'indicazione affidabile sull'entità dello sforzo necessario (che di solito ci dice il costo) e sulla probabile durata trascorsa. Armati di queste due informazioni, possiamo pianificare in modo efficace.
Una stima delle dimensioni funzionali può aiutarci a rispondere a queste due domande, ma anche a il processo di stima è prezioso. Il processo di stima ci aiuta a chiarire e migliorare la qualità dei requisiti, il che a sua volta può aiutare a ridurre le rilavorazioni.
Innanzitutto dobbiamo stabilire cosa stiamo stimando (e cosa non stiamo stimando). Possiamo considerarlo come la definizione dei confini della stima. Stimeremo la dimensione (non lo sforzo) della funzionalità da sviluppare solo per questo set di funzionalità. Stiamo considerando solo la funzionalità descritta, non indovineremo nessun'altra funzionalità.
Data l'elevata granularità dei requisiti forniti, possiamo solo dimensionare ciò che sappiamo e poi tenere conto di ciò che non sappiamo (ScopeMaster fa entrambe le cose). Quindi ora entriamo nei dettagli.
Cosa deve fare il software
"Fornire la possibilità a un membro del team di progettazione livelli di controllare il posizionamento degli oggetti del dungeon, inclusi i mostri, il punto di partenza del giocatore, gli oggetti decorativi contenenti bottino e il bottino in essi contenuto, e gli oggetti bottino indipendenti."
L'obiettivo generale è controllare il posizionamento iniziale degli oggetti in uno spazio limitato.
Le considerazioni contenute nella spiegazione includono quanto segue:
- Confini 2D predefiniti delle posizioni consentite (pavimenti, non pareti)
- Dobbiamo riconoscere l'adiacenza del muro
- Non dobbiamo preoccuparci dei corridoi, solo delle stanze.
- Esistono diversi tipi di Oggetti che hanno per lo più le stesse caratteristiche per i nostri scopi: Tesoro, Decorazioni e Mostri.
- Arredamento che contiene Tesoro
- Giocatore (per la posizione iniziale)
Per ora non ci preoccuperemo dei limiti relativi al numero di oggetti che possono essere posizionati su un livello, né se è possibile posizionare più oggetti nella stessa posizione.
Quindi ora iniziamo a scomporlo in una serie di storie utente (o FUR di requisiti utente funzionali orientati all'utente). Ovviamente abbiamo utilizzato ScopeMaster per aiutarci ad accelerare questo processo, in totale ho trascorso poco meno di 1 ora a leggere e comprendere i requisiti, creare le storie degli utenti e perfezionarle. (Ho quindi trascorso altre 1,5 ore a scrivere questo e a pubblicare questi risultati). ScopeMaster ha dimensionato le storie per noi, ma ci ha anche aiutato a migliorare la nostra concezione dei requisiti e della progettazione contemporaneamente.
Ecco i passaggi che ho seguito:
Per prima cosa, scopri quali sono gli oggetti identificabili dall'utente con cui dobbiamo lavorare
• Livelli (che hanno stanze)
• Stanze (che hanno dimensioni)
• Oggetti (che hanno una posizione iniziale)
• Contenimento (descrive quando su Arredamento contiene un tesoro).
Quindi descrivi la funzionalità dal punto di vista dell'utente e il risultato sono solo queste tre storie di utenti.
-
Come level_designer posso selezionare il livello su cui voglio lavorare e le stanze al suo interno
-
Come level_designer posso selezionare una stanza [all'interno di un livello] e creare un level_object [con room_location in cui posizionare un oggetto]
-
Come level_designer posso cercare level_object e quindi creare un level_object_containment
Queste non erano le mie versioni iniziali del requisito. Ognuno ha avuto alcune revisioni. ScopeMaster ha fornito feedback che mi hanno aiutato a migliorare la qualità e a determinare la dimensione di ciascun requisito.
Diagramma del modello del caso d'uso generato automaticamente per una serie di requisiti
Per ogni requisito otteniamo un'interpretazione funzionale, che determina la stima della CFP e la suddivisione del movimento dei dati:
Interpretazione funzionale di un requisito che mostra i movimenti di dati e la dimensione CFP
Un'altra prospettiva potenzialmente utile sul requisito sotto forma di diagramma di sequenza (anch'esso generato automaticamente).
Diagramma di sequenza generato automaticamente per un requisito funzionale individuale
Dato che l'intento funzionale viene rivelato, possiamo iniziare a pensare a come testare il software fornito da questi requisiti. ScopeMaster fa gran parte di questo lavoro per noi:
Scenari di test generati automaticamente per un singolo requisito funzionale
Migliorare la qualità del pensiero e dei requisiti
Le illustrazioni sopra, generate automaticamente direttamente dal testo dei requisiti, ci aiutano a raggiungere una chiara comprensione dell'intento funzionale di ciò che è stato scritto. Per i professionisti dello sviluppo software di grande esperienza, queste illustrazioni potrebbero rivelare poche informazioni aggiuntive su soli tre requisiti, ma quando si lavora su un ampio insieme di requisiti possono essere molto efficaci nell'esporre potenziali problemi prima che il codice venga scritto. ScopeMaster può analizzare un insieme fino a 2500 requisiti.
Stima delle dimensioni
Il dimensionamento COSMIC è una metodologia agile per la misurazione delle dimensioni delle funzionalità del software, poiché consente di dimensionare i requisiti che conosci senza dover conoscere altri requisiti. Potrei aver letto male la sfida e idealmente avrei alcune domande di follow-up, ma dato quello che so leggendo la sfida, la dimensione (di ciò che sappiamo) è 17 PCP.
Stime dell'impegno e della durata
Ciò che vorremmo davvero sapere è quanto impegno e quanto tempo sarebbero necessari per fornire la funzionalità. Studi, benchmark ed esperienze hanno dimostrato che la media tipica per lo sviluppo e il test unitario è di circa 4-8 ore per CFP. Notevolmente peggiori si osservano occasionalmente (20+ ore/CFP) nelle organizzazioni inefficienti. All’estremità opposta dello spettro, team altamente competenti, con livelli elevati di riutilizzo, possono ridurre questo valore a 2-3 ore/CFP, ma questo è raro. Per il bene di questo esercizio, daremo per scontato che sviluppatori altamente qualificati, con buoni strumenti, stiano lavorando su questo. Il loro unico vincolo sono i requisiti volatili, quindi 4-6 ore per CFP è un intervallo ragionevole. In genere non offro mai stime puntuali, solo intervalli, con spiegazioni. E quindi abbiamo un range stimato di 68-102 ore di impegno. Uno sviluppatore raramente è produttivo per più di 5 ore al giorno, quindi sarebbero 14-20 giorni.
Ma aspetta! Potrebbero essercene di più (incognite conoscibili). ScopeMaster ha eseguito l'analisi CRUD su una serie di 3 requisiti e ha identificato che potrebbero esserci funzionalità extra che ci sono sfuggite:
Se si prevede che lo sviluppatore crei anche tutte le funzionalità CRUD mancanti, allora il potenziale è che questo lavoro arrivi a 53 CFP (42 -63 giorni).
Conclusione
Il dimensionamento COSMIC segue i principi della progettazione software, misurando i movimenti di dati solo all'interno del contesto dato. È applicabile alla stragrande maggioranza dei domini software, compresi i giochi. La metodologia di dimensionamento aiuta con il pensiero progettuale e, come tale, di solito ci ritroviamo con requisiti migliori e una migliore adattabilità del progetto. Il dimensionamento può essere eseguito manualmente e per farlo è necessaria una percentuale molto piccola del tempo dello sviluppatore. È ancora più veloce quando si utilizza ScopeMaster®. In questo caso il lavoro di lettura, comprensione, analisi, chiarimento e dimensionamento dei requisiti è durato solo 1 ora. Ciò rappresenta solo 1,4% dello sforzo totale (o solo 0,3% per tenere conto dei requisiti mancanti). Ricorda che ciò che devi sapere per dimensionare i fabbisogni nella CFP è un sottoinsieme di ciò che devi sapere per costruirli – ovvero non ci sono sprechi.
Quando viene contestato da un manager/dirigente, è importante conoscere il limite dell'impossibilità. La CFP ci aiuta a comprendere il tempo minimo necessario per fornire questa funzionalità. In questo caso, meno di 68 ore andrebbero bene, meno di 32 ore sarebbe davvero straordinario.
Più sappiamo dove vogliamo arrivare, meno vicoli ciechi dovremo percorrere lungo il percorso. In altre parole, avere requisiti chiari ridurrà le rilavorazioni. Il dimensionamento COSMIC e ScopeMaster accelerano il lavoro per ottenere chiarezza su requisiti, dimensioni e progettazione, quindi insieme possono ridurre le rilavorazioni e dare maggiore certezza allo sforzo e alla durata della consegna del software.
Vorrei ringraziare Ron Jeffries per la sfida e spero che lo troverai utile.
Addendum
Dopo aver scritto questo, sono tornato indietro e ho notato che avevo omesso la funzionalità di “posizionamento iniziale del giocatore”. Ciò equivarrebbe ad almeno 3 CFP.
