Un mio piccolo problema sono le scadenze arbitrarie.
Scadenza del progetto: il problema
La stima del progetto porta inevitabilmente a una data che diventa una scadenza implicita. Manca quella data, indipendentemente dalla causa, spesso si sente come un fallimento se non è del tutto definito come tale. Quando date una data stabilite le aspettative e quando quelle aspettative non vengono soddisfatte, è naturale che le persone si sentano in qualche modo ingannate o ingannate. Il morale della squadra spesso colpisce.
Scadenza del progetto: gestione smussata del team e costo
Secondo la mia esperienza, le persone vogliono date arbitrarie perché vogliono usare la gestione dei progetti come strumento per smussare gli sviluppatori delle mandrie su cosa lavorare e quanto sia difficile lavorare. Quindi, lo scenario migliore è che il team lavori a una scadenza e lo faccia presto. Lo stesso rendimento in genere si ottiene senza una scadenza.
Lo scenario peggiore è, come sa chiunque abbia mai avuto un progetto in una scadenza. Più ti avvicini a una scadenza, più scorciatoie vengono prese. La maggiore qualità del codice soffre. E generalmente più morale soffre. È idiota cercare di forzare le persone a lavorare su una data arbitraria quando si guarda al costo. Il risultato è che hai prodotto codice cattivo e fatto peggio il morale. Potresti anche avere un certo giro d'affari mentre gli sviluppatori cercano altri posti di lavoro.
Solo per ripetere:
- Il caso migliore è lo stesso rendimento che si ottiene dal team senza una scadenza.
- Lo scenario peggiore è un codice errato, un brutto morale e una brutta esperienza tutt'intorno.
Progetti senza scadenze: un modo migliore
Non fornisco date a meno che non ci sia una scadenza difficile. La versione deve essere allineata con una campagna di marketing, un evento particolare, ecc. Tuttavia , la domanda diventa quindi come noi (il team di sviluppo) interagire con gli altri? Come fanno a sapere quando il loro pezzo di lavoro richiesto verrà completato?
Frequent Releases: Vertical Slices and Velocity
In primo luogo teniamo traccia di tutto il lavoro svolto. Nessun lavoro è impegnato in quello non è funzionalità o una correzione di bug. Tutto è fatto come una fetta verticale. Quindi, quando una funzionalità è completata, è rilasciabile. Rilasciamo bisettimanale al momento, ma in passato abbiamo pubblicato settimanalmente. Il risultato è che tutti vedono non solo il progresso e il lavoro completato, ma percepiscono anche il senso del ritmo del lavoro. In effetti abbiamo anche una velocità settimanale (usiamo l'idea di Sprint settimanali continui), insieme a una media di 14 settimane, deviazione standard e mediana.
Elenco priorità pubblico
Secondo, abbiamo un elenco di priorità pubblico e lavoriamo solo con il lavoro con la priorità più alta. Gestisco la lista e faccio chiamate sulla priorità informata da vari fattori. Ricontrollo con il mio manager.
Quindi le persone arrivano a vedere il lavoro in relazione agli altri, e riescono a vedere ogni pezzo non appena è stato rilasciato (nella versione bisettimanale). Finora sembra funzionare, e soprattutto non ci sono date arbitrarie.