Gestione del progetto: funzionalità (traguardi, attività e cicli di feedback)

La gestione dei progetti è sfaccettata e il modo in cui tutti noi scomponiamo i vari aspetti dei nostri progetti dipende probabilmente da come lo fa il nostro posto di lavoro, da come il cliente vuole farlo o da come scegliamo di farlo noi stessi.

Per questo post, quando si tratta di lavorare in modo specifico su un determinato progetto, sto parlando in particolare di come prendiamo i requisiti di un progetto e li suddividiamo in parti e risultati più gestibili per le persone per cui stiamo lavorando. E nel fare questo, penso che sia importante che siano tenuti al passo e possano vedere i progressi ai checkpoint appropriati per raccogliere feedback.

Nonostante il cambiamento di vari aspetti della mia attività, poiché ho imparato di più su cosa funziona e cosa no, una cosa è rimasta coerente nel modo in cui gestisco gli aspetti relativi allo sviluppo delle funzionalità di un progetto.

Caratteristiche: traguardi, attività e cicli di feedback

Ogni volta che parliamo di questo genere di cose, è facile entrare nel gergo del nostro settore. E anche se non penso che ci sia necessariamente qualcosa di eccessivamente tecnico su "traguardi" e "compiti", un "ciclo di feedback" è qualcosa di leggermente diverso. Ma lo tratterò momentaneamente.

Data una serie di requisiti, non importa quanto grandi, inizio immediatamente a esaminare il documento, indipendentemente da come lo riceviamo, e pensare a tutti i pezzi che saranno necessari per ottenere una determinata funzionalità. Indipendentemente dai linguaggi, dagli strumenti, dai framework o dalle applicazioni con cui scegli di lavorare, credo che qui sia importante avere una profonda familiarità con ciò con cui lavori.

Suddividere le funzionalità in pietre miliari e le pietre miliari in attività.

Da lì, prenderò una determinata funzionalità e la suddividerò in varie attività e lo ripeterò per ciascuna delle funzionalità. Di solito, cercherò di rendere ogni funzionalità una pietra miliare, ma alcune funzionalità sono più grandi di altre e devono essere suddivise in più parti. A tal fine, un progetto è solitamente suddiviso in modo tale che:

• Una caratteristica diventa una pietra miliare (o pietre miliari),
• Una pietra miliare è un gruppo di compiti,
• E un’attività corrisponde a un’unità funzionale (non necessariamente una funzione nella base di codice generale, però).

Quindi, puoi tornare indietro da questo per vedere come corrisponde a una versione:

• Un compito di solito corrisponde a un commit,
• Un insieme di commit corrisponde a un tag,
• Un tag corrisponde all’unione di una caratteristica,
• Una caratteristica corrisponde a una pietra miliare.

A questo punto, una pietra miliare dovrebbe essere pronta per essere implementata nell’ambiente di staging in modo che il cliente possa valutarla rispetto a ciò che ha in mente (e ai requisiti) per assicurarsi che sia soddisfatta.

È qui che entra in gioco un ciclo di feedback. Ma prima, definisco un ciclo di feedback semplicemente come:

Una conversazione su una determinata caratteristica che determina se è finita o se merita più lavoro.

Anche se altri entrano molto più nel dettaglio. Sto divagando, però.

Quindi, in attesa che il cliente torni in contatto in merito all’ultima pietra miliare, io (o noi) in genere andremo avanti con la tappa successiva. Questo è il motivo per cui è importante avere un modo coerente di lavorare con pietre miliari, attività e feedback (oltre a rami nel controllo del codice sorgente e negli ambienti di staging).

Inizia a lavorare su una nuova funzionalità dopo aver assegnato l’ultima al controllo del codice sorgente e allo staging.

Se il feedback viene restituito dal cliente, in genere prendiamo il feedback, determiniamo cosa si può fare, cosa non si può fare e quindi lo inseriamo in una nuova pietra miliare. A volte, la pietra miliare viene aggiunta alla fine; altre volte, viene aggiunto come elemento prioritario successivo. Tutto dipende dalla natura del lavoro, dal feedback e da come si inserisce nell’ambito del progetto.

Più che funzionalità

In generale, questa è solo una visione di alto livello di come cerco di gestire gli aspetti di sviluppo delle funzionalità. Ma guardare le pietre miliari, le attività e i cicli di feedback è qualcosa di importante perché una volta che il sistema è in atto, crea un modo prevedibile in cui tu e un team potete implementare soluzioni.

Inoltre, crea prevedibilità con i risultati finali e la comunicazione con il cliente, e questo funziona particolarmente bene anche con i clienti abituali, poiché sanno cosa aspettarsi.

Come per molte delle cose di cui scrivo, non cerco di presentarlo come un vangelo, ma credo che avere un sistema in atto sia importante. Non credo che si dovrebbe mai realizzare un progetto a meno che non sia solo un progetto collaterale personale.

Quindi, indipendentemente dall’approccio che scegli, almeno abbi un approccio.