Come scrivere obiettivi "SMART" come sviluppatore agile?


29

Come molte aziende per cui lavoro la società sta passando a un sistema di revisione delle prestazioni basato su obiettivi SMART . Il mio team è un team di sviluppo agile ad alto funzionamento che impiega le pratiche di Extreme Programming . A nostro grande beneficio, il nostro impiego di pratiche agili ha il pieno sostegno della direzione immediata e superiore.

Per eseguire il lavoro il nostro team utilizza iterazioni di tre settimane. Al di là dell'iterazione immediata abbiamo un piano generale definito in quarti. Ciò significa che ciò che avremo realizzato tra qualche trimestre è molto più sfocato di quello che realizzeremo nell'immediato trimestre. Abbiamo certamente un'idea generale di dove sia diretto il nostro progetto, ma la parola chiave qui è generale .

Dato il nostro approccio alla pianificazione del progetto, i membri del mio team, incluso me stesso, hanno difficoltà a scrivere obiettivi specifici, misurabili, raggiungibili, pertinenti e temporali (SMART).

Due domande esistenti su SoftwareEngineering.se fanno un buon lavoro nel rispondere ad alcune delle nostre preoccupazioni:

Tuttavia, le domande hanno suscitato risposte più generali rispetto alle specifiche per la gestione degli obiettivi SMART quando si lavora in un team di sviluppo agile. Come agile sviluppatore come scrivi obiettivi da cinque a sette anni che sono specifici, misurabili, raggiungibili, pertinenti e temporali?


2
In questo schema di Performance Management, i dipendenti vengono valutati / rivisti da livelli superiori ai tuoi o la valutazione in relazione agli obiettivi SMART si interrompe all'interno del tuo gruppo? Lo sto chiedendo perché se stai scrivendo gli obiettivi SMART in modo che siano davvero utili per te stesso, questa è una risposta, ma se li stai scrivendo a scopi di valutazione da persone che non capiscono Agile, questa è un'altra. (Sono stato lì, fatto quello, voglio darti una risposta utile :))
jcmeloni il

2
@jcmeloni è per le persone al di fuori della nostra organizzazione immediata. Teoricamente per noi stessi, ma non proprio. :)
ahsteele, il

Risposte:


21

Questa risposta è scritta dal punto di vista di qualcuno che aveva un tale sistema di gestione delle prestazioni messo in atto attorno a un team Agile; come te, tutti i membri del team hanno realizzato la difficoltà / inutilità degli obiettivi SMART di un anno applicati a un gruppo Agile, dove, quando pienamente funzionante, l'implementazione di Agile può essere considerata intrinsecamente / già SMART.

No davvero! Se necessario, chiama la seguente razionalizzazione (se la logica è semicotta ...), ma spiegarla a revisori esterni all'organizzazione immediata ha posto le basi per gli "obiettivi" effettivi che abbiamo inserito nel sistema di gestione delle prestazioni.

  • S per specifici : durante ogni pianificazione dello sprint, il team si impegna su una serie specifica di compiti da svolgere e si impegna a svolgerli. I compiti (e le storie degli utenti), rispondono alle domande su cosa voglio realizzare, scopi / benefici del raggiungimento dell'obiettivo, chi è coinvolto, dove si svolge e vincoli.
  • M misurabile : l'elenco di questi compiti, oltre allo spostamento dei ticket durante lo sprint, dallo sviluppo alla revisione del codice fino al QA per il rilascio (o qualunque sia il flusso), risponde alle domande su quanto lavoro e quando verrà realizzato .
  • A raggiungibile : i gruppi Agile funzionanti in genere non si impegnano in qualcosa in fase di pianificazione a meno che non sia chiaramente raggiungibile - tutti i pezzi sono lì per sapere come realizzarlo
  • R rilevante : domande come vale la pena, è il momento giusto, corrisponde ai nostri altri sforzi - storie e compiti non vengono trascinati in uno sprint e impegnati, a meno che la risposta sia sì a tutte queste domande ( tipicamente ... YMMV)
  • T per limiti di tempo : uno sprint è necessariamente limitato nel tempo, che si tratti di 2 settimane, 3 settimane, più o meno.

Se capisci / ti convinci che il tuo lavoro trimestrale (e quindi il tuo lavoro di un anno) è esso stesso un grande obiettivo SMART e che sai che stai raggiungendo i tuoi obiettivi perché il team si sta comportando bene, la velocità è positiva, i rilasci avvengono , quindi si arriva al punto della domanda, che è in definitiva come tradurre un processo SMART in una serie di obiettivi SMART a beneficio di qualcun altro.

Sono stato in grado di farlo con successo in passato scrivendo qualcosa che per me sembra vago e, beh, non molto SMART, ma in realtà è perfettamente accettabile per gli altri.

Un paio di esempi che sono stati raccolti altrove per me:

  • "Voglio rilasciare una nuova versione di WidgetMaker ogni tre mesi nel prossimo anno, seguendo il nostro processo di sviluppo del software interno, per allinearmi al programma di sviluppo generale del prodotto (blah blah)."

  • "Voglio aumentare la velocità di sviluppo del team di n% dalla versione A alla versione B, concentrandomi sulle modifiche incrementali al processo di gestione degli arretrati, al fine di aumentare la nostra efficacia e ridurre i ritardi nella spedizione del prodotto."

Sai e so che questi non sono i principi guida del tuo vero gruppo di sviluppo, ma non sono del tutto indipendenti, e nella mia esperienza sono i tipi di cose che sembrano davvero SMART e utili alle persone al di fuori della tua organizzazione immediata (senza essere completamente bugie o totalmente zoppo).


Il target della velocità non soddisfa il Mcriterio per smart? Sembra che non sia misurabile perché la velocità è (presumibilmente) definita in termini di punti della storia, e lì 'punto della storia' non è definito in modo preciso.
bdsl,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.