Quali metodi utilizzano gli sviluppatori per valutare le attività?

Ciao a tutti! La teoria richiesta per avviare lo sviluppo è molto ampia. Alcuni specialisti (sviluppatori backend in Java e altri linguaggi) ne hanno di più, mentre altri (ad esempio, sviluppatori frontend in JavaScript - React Native) ne hanno un po' meno. Entrambi, però, devono possedere un ampio bagaglio di conoscenze non solo tecniche, ma anche “organizzative”. Questa conoscenza “organizzativa” è uno dei punti di intersezione per gli sviluppatori frontend e backend. Oggi voglio parlare di un aspetto di tale conoscenza organizzativa non tecnica: la valutazione (stima) dei compiti . E poiché ho lavorato solo con la metodologia Agile (che di fatto è considerata la più popolare), nella sua sottoparte, Scrum , considererò la valutazione delle attività nel contesto di Scrum . Dirò subito che la valutazione, detta anche stima, è difficile. Per me personalmente come sviluppatore questo è uno degli aspetti più difficili/indesiderabili del lavoro. Ci sono molti fattori diversi da considerare che possono influenzare la valutazione di un compito. Allo stesso tempo, i piani per l'ulteriore sviluppo saranno basati sulle vostre previsioni.

Cosa succede se non ottieni la valutazione giusta?

Se uno sviluppatore dedica molte più ore a un'attività di quelle che verrà impiegata alla fine, potrebbe sembrare che non sia il miglior specialista, perché la stima era molto imprecisa. Per così dire, un dito nel cielo. Allo stesso tempo, se lo sviluppatore non investe nei tempi previsti, mette a repentaglio i piani del cliente di rilasciare il prodotto/nuova funzionalità. Questo è un business, e business significa denaro, e pochi clienti apprezzeranno una tale foratura. Questo è in realtà il motivo per cui non mi piace la stima, perché a volte è così difficile determinare il tempo esatto in cui completare un'attività.

Come viene valutato il tempo?

Di norma, la stima viene effettuata in ore o punti della storia. Personalmente sono molto più vicino al processo di valutazione per story points . Se un orologio è qualcosa di fisico, quindi qualcosa che può essere confuso, i punti della storia riguardano qualcos'altro, più astratto. In genere, i team di sviluppo software forniscono stime in formato temporale: ore, giorni, settimane, mesi. Tali stime di tempo si basano principalmente sull'esperienza personale, su congetture o intuizione. In questo caso, gli sviluppatori esaminano semplicemente l'attività e esprimono una stima di quanto tempo impiegherebbero. Di conseguenza, molto raramente sono accurati, perché ci sono troppi fattori che possono influenzare la scadenza per il completamento del lavoro. Pertanto, molti team che lavorano secondo la metodologia Agile utilizzano gli story point. Scopriamolo.

Cosa sono i punti Storia

Uno story point è un'unità di misura che esprime una valutazione dello sforzo totale necessario per implementare pienamente una determinata area di lavoro (funzionalità). Cioè, questa è una complessità così relativa . I team assegnano i punti della storia in base alla complessità del lavoro, alla portata del lavoro e al rischio o all'incertezza. In genere, questi valori vengono assegnati per scomporre in modo più efficiente il lavoro in parti più piccole, eliminando così l’incertezza. Nel tempo, questo aiuta i team a capire cosa possono ottenere in un dato periodo di tempo e li aiuta a pianificare le aree di lavoro successive in modo più accurato. Potrebbe sembrarti del tutto controintuitivo, ma in realtà questa astrazione è molto utile: spinge il team a prendere decisioni più difficili sulla complessità del lavoro. Diamo un'occhiata ad alcuni motivi per utilizzare gli story point nella pianificazione:

• si possono evitare imprecisioni di stima negli intervalli di tempo;
• A differenza della stima nel tempo, i costi generali possono essere presi in maggiore considerazione: comunicazioni tra i membri del team e il cliente, varie discussioni e pianificazioni del team, nonché situazioni impreviste;
• Ogni squadra valuterà il lavoro su una scala diversa, il che significa che la loro velocità (misurata in punti) sarà diversa;
• Definendo una scala per l'assegnazione di ciascun punto della storia, puoi distribuire rapidamente i punti senza troppe controversie.

Come NON utilizzare gli story point

Sfortunatamente, gli story point vengono spesso utilizzati per altri scopi. Gli story points possono essere errati quando vengono utilizzati per valutare le persone, definire scadenze e risorse dettagliate e quando vengono erroneamente presi come misura della performance. I team devono invece utilizzarli per comprendere il volume/la complessità del lavoro in ciascuna attività e per stabilire le priorità. È possibile che le parti classificate come più difficili vengano eseguite per prime in modo da poterle completare prima della fine dello sprint , ma quelle più facili possono essere rimandate a più tardi. Lascia che ti ricordi cos'è uno sprint nel contesto della metodologia Scrum : La durata di questo periodo di tempo viene determinata all'inizio dello sviluppo previo accordo tra il team e il cliente. Questo potrebbe essere un periodo di due settimane o un mese, o qualsiasi altro periodo. Di norma, la stima delle attività viene effettuata all'inizio dello sprint al fine di pianificare la possibile quantità di lavoro completato entro la fine dello sprint, quando il lavoro completato viene consegnato al cliente. Ti aiuta a vedere i tuoi progressi nello sviluppo del prodotto, ricevere feedback dal cliente e adattare lo sviluppo del progetto in base alla visione del cliente. Ma ancora divaghiamo un po’: torniamo alla stima. Valutare le attività di un solo sviluppatore sarebbe troppo soggettivo. Pertanto, di regola, questo è un lavoro di squadra. Esistono diverse tecniche per la valutazione del team. Oggi esamineremo il più utilizzato: lo Scrum Poker . Questa tecnica richiede un manager che sia qualcuno come il leader di questo Scrum poker . Potrebbe trattarsi di una persona specializzata in Scrum Master o PM .

Cos'è lo Scrum Poker

Lo Scrum Poker , o Planning Poker, è una tecnica di valutazione basata sul raggiungimento di un accordo. Utilizzato principalmente per valutare la complessità del lavoro da svolgere o il volume relativo di compiti da risolvere durante lo sviluppo del software. Noterò subito che lo Scrum Poker è una pratica comune nello sviluppo e devi assolutamente sapere che tipo di bestia è. Per questo processo, di solito utilizziamo qualche tipo di applicazione o sito Web che ci consente di organizzare una valutazione di squadra su un compito particolare. Come avviene questo? Il team prende un elemento arretrato (nuova attività, funzionalità), discute brevemente le possibili insidie ​​​​e altre sfumature ad esso associate. Ogni partecipante sceglie quindi una carta con un numero che rappresenta il proprio grado di difficoltà. Oh, e durante la stima, non viene utilizzata la solita serie, ma i numeri di Fibonacci . I numeri di Fibonacci sono così popolari nello scrum poker perché il divario tra loro aumenta nel tempo (ricordando i livelli piramidali). Ci sono compiti che avranno un'enorme complessità e non è possibile raggiungere un numero limitato di punti della storia. Spiegazione per carte insolite:

numero sconosciuto di endpoint

un compito infinitamente lungo

Ho bisogno di una pausa

Metodi di stima più rari:

• nelle taglie delle magliette: S, M, L, XL
• o nei cani: chihuahua, carlino, bassotto, bulldog e così via (secondo me questa è l'unità più strana per valutare i compiti =D)

Il team confronta quindi le stime fornite per lo stesso problema da diversi sviluppatori e, se sono d'accordo, bene! In caso contrario, è necessario discutere le ragioni delle differenze di valutazione (argomentazioni). Successivamente potremo giungere congiuntamente ad un'unica stima, con la quale tutti, più o meno, saranno d'accordo. Ebbene, perché il poker viene utilizzato anche per pianificare un progetto software serio? Dopotutto, questo è in qualche modo strano. Infatti, tale ludicizzazione incoraggia i membri del team a pensare in modo indipendente, chiedendo loro di mostrare i propri risultati contemporaneamente ai compagni di squadra. Ciò, a sua volta, evita la dipendenza dalle opinioni degli altri membri del team. Altrimenti, gli sviluppatori meno esperti guarderanno e faranno affidamento sulle valutazioni dei membri del team più esperti, il che annullerà l'utilità della propria valutazione. Ma con l’apertura simultanea dei risultati ciò è sostanzialmente impossibile. Un esempio di app di pianificazione di Scrum Poker proviene da Atlassian .

Esempio di valutazione del compito

Immaginiamo che il tuo team abbia identificato una certa scala di valutazione negli story points: Scrum Poker inizia con un compito e lo valuti in questo modo:

• non hai mai lavorato con l'implementazione di funzionalità simili prima - +3
• funzionalità di un compito di medie dimensioni - +2
• l'implementazione dell'attività ha un'elevata complessità - +3
• elevata complessità dei test di scrittura per questa funzionalità - +3

Di conseguenza, ottieni 11 punti storia, ma poiché non esiste una carta del genere, ne offri 13. Un altro tuo collega valuta il compito:

• ha già lavorato con un problema simile - +1
• funzionalità di un compito di medie dimensioni - +2
• l'implementazione dell'attività ha una complessità media - +2
• complessità media dei test di scrittura per questa funzionalità - +2

Di conseguenza, ottiene 7 punti storia, ma non esiste nulla del genere nei numeri di Fibonacci e posiziona una carta con il numero più vicino possibile: 8. Gli altri membri del team, rispettivamente, forniscono stime in base alle loro opinioni soggettive. Successivamente, mostri i tuoi risultati e scopri che quasi tutti i tuoi colleghi hanno dato la stima 13, tranne uno sviluppatore che ha dato 8. In questo caso gli viene data la parola e motiva. E loro, per esempio, sono così: ha lavorato precedentemente con lo stesso problema, e non è così difficile come potrebbe sembrare, e alla fine convince il resto dei membri del team a cambiare la loro soluzione da 13 a 8 piani punti, dicendo che aiuterà chiunque si assumerà questo compito a capirlo. Oppure, alla fine, lo farà lui stesso. E in generale, non importa se gli altri ascoltano o meno le sue argomentazioni, perché in un modo o nell'altro verrà assegnata una valutazione a questo compito e il team passerà a familiarizzare con quello successivo. Le prime volte, le stime saranno imprecise, così come le stime della quantità di lavoro che intendi svolgere nel periodo di tempo successivo (sprint). Dopotutto, queste stime sono effettuate proprio sulla base di stime. Dopo un po' di tempo, circa tre mesi, il team inizierà a stimare in modo più accurato le attività e diventerà visibile la quantità media di lavoro che il team può completare per sprint. Ma questa è una pianificazione generale dell'ambito di lavoro, è più una questione di tempo e in questo caso potrebbero esserci molti fattori diversi che hanno un impatto. Ad esempio, uno degli sviluppatori è andato in vacanza per due settimane. Cioè, è necessario cancellare una certa quantità di lavoro pianificato (funzionalità pianificata). Oppure è arrivato un nuovo sviluppatore nel team, ma non è necessario contare completamente su di lui, perché... è necessario tenere conto del tempo necessario per adattarsi al progetto, chiamato onboarding . Potrebbero essere due settimane, più o meno una settimana, a seconda della complessità del progetto. Per oggi è tutto, spero di aver leggermente migliorato le tue conoscenze in una parte non tecnica della conoscenza come la stima dei problemi. Se vuoi approfondire questo argomento, nonché i dettagli di Scrum, ti consiglio vivamente di leggere il libro “SCRUM” di Jeff Sutherland. Non posso garantire sulle conseguenze, perché forse dopo ti verrà il fastidioso desiderio di diventare uno Scrum Master =D