Come scrivere obiettivi "SMART" come sviluppatore agile?

26

Come molte aziende, la società per cui lavoro è la transizione a un sistema di revisione delle prestazioni basato su obiettivi SMART . Il mio team è un team di sviluppo agile ad alto funzionamento che utilizza le pratiche di SCRUM e Programmazione estrema . Per il nostro grande vantaggio, il nostro impiego di pratiche agili ha il pieno supporto della gestione immediata e superiore.

Per completare il lavoro, il nostro team utilizza le iterazioni di tre settimane. Oltre l'iterazione immediata abbiamo un piano generale disposto in quattro parti. Ciò significa che ciò che avremo compiuto da pochi mesi è molto più pesante di quello che realizzeremo nell'immediato trimestre. Abbiamo certamente un'idea generale di dove è diretto il nostro progetto, ma la parola chiave qui è generale. Dato il nostro approccio alla pianificazione del progetto, i membri del nostro team e me stesso stanno trovando difficile scrivere obiettivi specifici, misurabili, raggiungibili, pertinenti e limitati nel tempo.

Due domande esistenti su Programmers.se fanno un buon lavoro per risolvere alcuni dei nostri dubbi:

Tuttavia, le domande hanno suscitato risposte più generali rispetto a specifiche per il trattamento degli obiettivi SMART quando si lavora su un team di sviluppo agile. Come sviluppatore agile, come si scrivono da cinque a sette anni obiettivi che sono specifici, misurabili, raggiungibili, pertinenti e limitati nel tempo?

    
posta ahsteele 18.01.2013 - 19:03
fonte

1 risposta

19

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

No, davvero! Se necessario, chiama la seguente razionalizzazione (se la logica è semicarrata ...), ma spiegarla ai revisori al di fuori dell'organizzazione immediata ha posto le basi per gli "obiettivi" effettivi che abbiamo inserito nel sistema di gestione delle prestazioni. / p>

  • S per specifici : durante ogni pianificazione sprint, il team accetta una serie specifica di compiti da raggiungere e si impegna a eseguirli. I compiti (e le storie degli utenti), rispondono alle domande su cosa voglio realizzare, scopi / benefici del raggiungimento dell'obiettivo, chi è coinvolto, dove ha luogo e vincoli.
  • M per misurabili : l'elenco di queste attività, oltre al movimento dei ticket durante lo sprint, dallo sviluppo alla revisione del codice, al QA per il rilascio (o qualunque sia il flusso), risponde alle domande di quanto lavoro e quando sarà compiuto.
  • A per essere raggiungibile : i gruppi Agile funzionanti di solito 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 per pertinente : domande come ne vale la pena, è il momento giusto, corrisponde agli altri nostri sforzi - storie e attività non vengono tirate in uno sprint e impegnate a meno che la risposta è sì a tutte queste domande (tipicamente ... YMMV)
  • T per il limite 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) è di per sé un grande obiettivo SMART, e che sai che stai raggiungendo i tuoi obiettivi perché la squadra sta andando bene, la velocità è positiva, i rilasci stanno accadendo, quindi si arriva al punto della domanda, che alla fine è come tradurre un processo SMART in un insieme di obiettivi SMART a beneficio di qualcun altro.

Sono riuscito a 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 trasmessi 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 allinearci con il programma generale di sviluppo del prodotto (bla bla)."

  • "Voglio aumentare la velocità di sviluppo del team del n% dalla versione A alla versione B, concentrandomi sulle modifiche incrementali al processo di grooming del backlog, 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 attuale gruppo di sviluppo, ma non sono del tutto estranei, e nella mia esperienza sono i tipi di cose che appaiono davvero SMART e utili alle persone al di fuori del tuo immediato organizzazione (senza essere menzogne o totalmente zoppi).

    
risposta data 18.01.2013 - 20:19
fonte

Leggi altre domande sui tag