Rispetta le tue scadenze: metodi che gli sviluppatori utilizzano per stimare lo sforzo

Ciao a tutti! C'è un'enorme quantità di teoria che devi conoscere per iniziare nello sviluppo del software. Alcuni specialisti (ad esempio, gli sviluppatori di back-end che utilizzano Java e altri linguaggi) ne sanno di più, mentre altri (ad esempio, gli sviluppatori di front-end che utilizzano JavaScript e React Native) potrebbero saperne un po' meno. Detto questo, entrambi i gruppi devono possedere un ampio corpus di conoscenze non solo tecniche, ma anche "organizzative". Questa conoscenza "organizzativa" è un'area di sovrapposizione per gli sviluppatori frontend e backend. Oggi voglio parlare di un aspetto di questa conoscenza organizzativa non tecnica. Oggi parleremo di stima dello sforzo . Perché ho solo esperienza nell'utilizzo della metodologia Agile(che è considerato il più popolare), più specificamente il framework Scrum, prenderò in considerazione la stima dello sforzo nel contesto di Scrum . Devo dire subito che la stima dello sforzo è difficile. Per me è uno degli aspetti più impegnativi/sgradevoli del mio lavoro di sviluppatore. Esistono molti fattori diversi da considerare che possono influire sulla stima dello sforzo richiesto per un'attività. Inoltre, i futuri piani di sviluppo saranno basati sulle tue stime.

E se fornisci una stima errata?

Se uno sviluppatore stima molte più ore per un'attività rispetto a quelle eventualmente impiegate per l'attività, la sua esperienza potrebbe essere messa in dubbio poiché la stima era così imprecisa. In altre parole, era un'ipotesi selvaggia. Allo stesso tempo, se uno sviluppatore non porta a termine il lavoro nei tempi previsti, mette a repentaglio i piani del cliente di rilasciare il prodotto o la nuova funzionalità. Questi sono affari e gli affari sono soldi. Pochi clienti saranno contenti di una tale scivolata. In effetti, è per questo che non mi piacciono le stime, perché a volte è super complicato determinare con precisione il tempo necessario per completare un'attività.

Come fare una stima del tempo

Di norma, le stime vengono effettuate in ore o punti della storia. La mia preferenza personale è eseguire il processo di stima utilizzando i punti della storia . È difficile sbagliarsi sugli oggetti fisici concreti, ma i punti della storia sono un po' più astratti. I team di sviluppo software in genere forniscono stime come quantità di tempo: ore, giorni, settimane, mesi. Queste stime del tempo si basano principalmente sull'esperienza personale, su congetture e/o intuizione. In questo caso, gli sviluppatori osservano semplicemente l'attività ed esprimono la loro ipotesi su quanto tempo impiegheranno loro. Di conseguenza, queste stime sono molto raramente accurate, perché ci sono troppi fattori che possono influenzare la durata del lavoro. Ecco perché molti team che utilizzano la metodologia Agile utilizzano anche i punti della storia. Immergiamoci!

Cosa sono i punti della storia?

Uno story point è un'unità di misura per esprimere una stima dello sforzo totale richiesto per implementare completamente una determinata funzionalità. Cioè, stiamo parlando di relativocomplessità. I team assegnano una stima in punti della storia in base alla complessità del lavoro, al volume del lavoro e al rischio o all'incertezza. Questi valori vengono generalmente assegnati per suddividere in modo più efficiente il lavoro in parti più piccole, eliminando così l'ambiguità. Nel tempo, questo aiuta i team a capire cosa possono realizzare in un determinato periodo di tempo e li aiuta a pianificare in modo più accurato i successivi blocchi di lavoro. Questo può sembrare del tutto controintuitivo per te, ma questa astrazione è davvero utile: spinge il team a prendere decisioni difficili sulla complessità del lavoro. Diamo un'occhiata ad alcuni dei motivi per utilizzare i punti della storia durante la pianificazione:

• È possibile evitare stime di tempo imprecise.
• A differenza delle stime effettuate in unità di tempo, i punti della storia consentono di tenere conto dei costi generali: comunicazioni tra i membri del team e il cliente, varie discussioni del team e attività di pianificazione, nonché situazioni impreviste.
• Ogni squadra valuterà il proprio lavoro utilizzando scale diverse, il che significa che la loro capacità (misurata in punti) sarà diversa.
• Definendo una scala per l'assegnazione di ogni punto della storia, puoi assegnare rapidamente i punti senza troppe polemiche.

Come NON usare i punti della storia

Sfortunatamente, i punti della storia sono spesso usati in modo improprio. I punti della storia possono essere fuorvianti quando vengono utilizzati per valutare le persone, definire scadenze e risorse dettagliate e quando vengono scambiati per una misura delle prestazioni. Invece, i team dovrebbero usarli per comprendere l'ambito/complessità di ogni attività e per stabilire le priorità. Forse le parti considerate più difficili dovrebbero essere affrontate per prime, in modo da poterle svolgere prima della fine dello sprint , possibilmente spostando i compiti più facili a dopo. Permettetemi di ricordarvi cos'è uno sprint nel contesto della metodologia Scrum : La durata di questo periodo di tempo viene determinata quando inizia lo sviluppo e viene concordata tra il team e il cliente. Questo può essere un periodo di due settimane o un mese o qualsiasi altro periodo. Di norma, le stime degli sforzi vengono effettuate all'inizio di ogni sprint in modo da pianificare il lavoro che può essere completato entro la fine dello sprint, quando il lavoro completato viene consegnato al cliente. La demo ti aiuta a vedere i tuoi progressi nello sviluppo del prodotto, a ricevere feedback dal cliente e ad adattare la traiettoria del progetto in base alla visione del cliente. Ma stiamo divagando un po'. Torniamo alle stime. Sarebbe troppo soggettivo avere un solo sviluppatore che fornisca stime per tutte le attività. Quindi questo processo è solitamente uno sforzo di squadra. Esistono diverse tecniche che i team possono utilizzare per generare stime. Oggi esamineremo la tecnica più popolare: lo scrum poker . Questa tecnica richiede un manager che fungerà da moderatore per lo scrum poker . Questo può essere qualcuno che è uno scrum master o forse un PM .

Cos'è il poker Scrum?

Scrum poker , o planning poker, è una tecnica di stima che si basa sul raggiungimento di un accordo. Viene utilizzato principalmente per stimare la complessità del lavoro da svolgere o la dimensione relativa delle attività di sviluppo del software. Dirò subito quel poker di mischiaè una pratica comune di sviluppo software e devi sapere di cosa si tratta. Di solito coinvolge un'app o un sito Web per facilitare la creazione collaborativa di un preventivo da parte di un team per una particolare attività. Come succede? Il team prende qualcosa dall'arretrato (una nuova attività, alcune funzionalità) e discute brevemente le possibili insidie ​​e altre sfumature ad esso associate. Quindi ogni partecipante sceglie una carta con un numero che riflette la sua stima di complessità. Oh, un'altra cosa, quando facciamo queste stime, usiamo numeri nella sequenza di Fibonacci piuttosto che numeri ordinari. I numeri di Fibonacci sono popolari nello scrum poker, perché c'è un divario sempre più ampio tra loro (simile ai livelli di una piramide). Alcuni compiti saranno molto complessi e non saremo in grado di farla franca con un numero limitato di punti della storia. Ci sono alcune carte insolite che hanno i seguenti significati:

Numero sconosciuto di endpoint

Compito infinitamente lungo

Ho bisogno di una pausa

Metodi di stima meno comuni utilizzano:

• Taglie delle magliette: S, M, L, XL
• Razze di cani: chihuahua, carlino, bassotto, bulldog e così via (personalmente, penso che questa sia l'unità di misura più strana per la stima dello sforzo = D)

Il team confronta quindi le stime fornite da diversi sviluppatori per la stessa attività. Se sono d'accordo, allora fantastico! In caso contrario, è necessario discutere le ragioni (argomentazioni) delle diverse stime. Successivamente, il team lavora insieme per formare un'unica stima che tutti accettano, più o meno. Allora perché il poker viene utilizzato anche per pianificare seri progetti software? Devi ammettere che è strano. Il fatto è che questo tipo di gamification incoraggia i membri del team a pensare in modo indipendente, invitandoli a rivelare le loro stime contemporaneamente ai loro compagni di squadra. Questo, a sua volta, evita di creare una situazione in cui alcuni membri del team dipendono dalle opinioni degli altri. Se non fosse stato fatto in questo modo, gli sviluppatori meno esperti guarderebbero e si concentrerebbero sulle stime fornite dai membri del team più esperti, e ciò renderebbe le loro stesse stime meno utili. Ma mostrare contemporaneamente le stime lo rende sostanzialmente impossibile. Offerte Atlassianun'app di scrum poker da utilizzare nel processo di pianificazione.

Esempio di stima dello sforzo

Supponiamo che il tuo team abbia stabilito la seguente scala per assegnare i punti della storia alle stime: Scrum poker viene giocato per ogni attività e tu fornisci una stima come segue:

• Non hai mai implementato funzionalità simili prima: +3
• La funzionalità è di dimensioni medie: +2
• L'implementazione sarà molto complessa: +3
• I test di scrittura per la funzionalità saranno molto complessi: +3

Sommando ogni componente, ottieni un totale di 11 punti storia, ma non esiste una carta del genere, quindi ne suggerisci 13. Un collega propone la seguente stima per l'attività:

• Ha già lavorato con un compito simile: +1
• La funzionalità è di dimensioni medie: +2
• L'implementazione sarà di complessità media: +2
• I test di scrittura per la funzionalità saranno di complessità media: +2

Il suo risultato intermedio è di 7 punti storia, ma quel numero non esiste nella serie di Fibonacci, quindi invia la carta con il numero più approssimativo: 8. Anche altri membri del team fanno le loro stime in base alle loro opinioni soggettive. Quindi tutti mostrano le loro carte e scopri che quasi tutti i tuoi colleghi hanno fornito una stima di 13, tranne uno sviluppatore che ha suggerito un 8. In questo caso, è autorizzato a parlare con i motivi della sua stima inferiore. Supponiamo che offra questa giustificazione: ha lavorato in precedenza allo stesso compito, e non è così difficile come potrebbe sembrare. Alla fine, convince il resto della squadra a cambiare idea da 13 a 8 punti storia, dicendo che aiuterà chiunque finirà per assumersi questo compito. O forse lo farà lui stesso. In ogni caso, non Non importa se gli altri accettano o meno le sue argomentazioni, perché in un modo o nell'altro verrà assegnato un preventivo al compito, e il team passerà a considerare quello successivo. Inizialmente, le stime saranno imprecise, così come le stime della quantità di lavoro che prevedi di svolgere nel prossimo periodo di tempo (sprint). Dopotutto, queste stime sono state effettuate utilizzando stime. Dopo un po' di tempo, forse tre mesi dopo, il team inizierà a stimare il tempo necessario per le attività in modo più accurato e diventerà evidente la quantità media di lavoro che il team è in grado di eseguire in uno sprint. Ma questo è un processo per fare un piano generale per lo scopo del lavoro. Si concentra principalmente sul tempo, ma in questo caso potrebbero esserci molti diversi fattori rilevanti. Ad esempio, supponiamo che uno sviluppatore sia andato in vacanza per due settimane. Sarà necessario ridurre una certa quantità di lavoro pianificato (funzionalità pianificata). Oppure supponiamo che un nuovo sviluppatore si sia unito al team, ma non sia ancora completamente al passo con i tempi, quindi devi concederle il tempo di familiarizzare con il progetto attraverso unprocesso di onboarding . Potrebbero essere due settimane, più o meno una settimana, a seconda della complessità del progetto. È tutto per oggi! Spero di aver migliorato leggermente la tua conoscenza della stima dello sforzo, un aspetto non tecnico necessario dello sviluppo del software. Se vuoi approfondire questo argomento e i dettagli di Scrum, ti consiglio vivamente di leggere il libro "SCRUM" di Jeff Sutherland. Non posso fare promesse sulle conseguenze, perché dopo averlo letto avrai un fastidioso desiderio di diventare uno scrum master =D