Come possiamo pianificare realisticamente i progetti e tenere conto delle questioni relative all'assistenza?

The problem is though that its difficult to plan for a project without knowing everything that's going to happen.

Questo è il punto di gestione del rischio. Non puoi sapere tutto, quindi pianifichi in base a ciò che conosci e identifica le cose che potrebbero avere più impatto sul tuo piano e quanto è probabile che ciò accada. Valutare anche l'impatto potenziale del programma dicendo che se X accade, farà sì che il programma scivoli di una Y (o parola) stimata (parola chiave - stimata) di giorni o settimane.

Its all well and good saying that a project will take 3 weeks,

Non dare mai una stima così specifica. Fornire un intervallo o quantificare la probabilità di raggiungere tale stima. Ad esempio, dì "questo progetto richiederà 2-5 settimane" o "c'è una probabilità dell'85% che questo progetto venga svolto in 3 settimane e una probabilità del 95% che venga fatto in 4 settimane".

Its also not professional to the client to keep saying we've missed a deadline.

È vero. Tuttavia, stai mescolando i concetti di "stima", "pianificazione" e "scadenza". La stima è un'approssimazione di quanto tempo ci vorrà per terminare una determinata attività o progetto e la probabilità di incontrarlo. La scadenza è una data imposta dal cliente su cui il progetto deve essere eseguito al fine di aggiungere valore. Il programma è come utilizzi le risorse disponibili per rispettare la tua scadenza.

Ci sono momenti in cui semplicemente non è possibile finire il lavoro assegnato entro una scadenza e tutte le stime e la programmazione nel mondo non faranno alcuna differenza.

So my question... how do other people do this? How do you manage the planning of projects? How much "extra" time do you schedule into a project to account for anything that happens in the mean time?

Raccomando di leggere due libri, entrambi di Steve McConnell: Stima del software: Demistificazione della Black Art e Rapid Development: Taming Wild Software Schedules . La stima del software consiste nel fornire le stime, presentarle ai clienti e alcuni aspetti della negoziazione e affrontare aspettative non realistiche. Rapid Development è la gestione generale del progetto, che si occupa dei cicli di vita dello sviluppo, della pianificazione, dell'allocazione delle risorse e di come pianificare e pianificare al meglio i progetti per soddisfare le stime e le scadenze.

Suggerirei di approfondire i dettagli del processo di sviluppo Scrum . Copre tali attività di sidetracking con la metrica focus factor . Fondamentalmente devi lavorare 2-3 sprint / iterazioni e quindi misurare il fattore di messa a fuoco del tuo team (e anche per ogni membro sarebbe utile). Successivamente, potresti fornire stime più accurate che coprono l'attività quotidiana.

Dai un'occhiata a questo articolo - "Il fattore di attenzione"

If any of you are familiar with Agile development, you’ve probably heard of the focus factor (or productivity factor). It’s used for planning to help determine how many “real hours” you have to work on something. It’s the difference between “real hours” and “ideal hours.”

Il problema delle interruzioni è che, per determinati individui o team, tendono a verificarsi in una gamma relativamente piccola di probabilità. Ad esempio, hai all'incirca lo stesso numero di riunioni ogni settimana, o all'incirca lo stesso numero di ore spese per le correzioni urgenti dei bug ogni mese, o la stessa quantità di tempo speso a rispondere alle domande per le persone che si avvicinano alla tua scrivania, specialmente se la media è scaduta un lungo periodo di tempo.

Molte moderne tecniche di pianificazione tengono conto di ciò. Scrum lo influenza in velocità. La schedulazione basata sull'evidenza utilizza anche una velocità con un intervallo di confidenza per ogni stima data. Pomodoro prende in considerazione le interruzioni quando decidi quanti "pomodorini" puoi contare completando in una data settimana. Tutto ciò dipende dal monitoraggio delle misurazioni storiche delle interruzioni e dal fattorizzarle in qualche modo nelle stime. Ti consiglio di dare un'occhiata a tutti loro e ideare una tecnica che funzioni per il tuo team.

Un buon consiglio tutto intorno.

Un'altra cosa che potrebbe essere utile per affrontare i problemi di supporto è dedicare la gente a supporto su una base fissa "round robin".

Ad esempio, se hai 5 sviluppatori ne assegni uno a ogni giorno della settimana. Quando arriva quel giorno, lo sviluppatore assegnato lavora SOLO per quel giorno sul supporto. Il giorno dopo un altro sviluppatore si assume il supporto. In questo modo tutti hanno la possibilità di rimanere nel loro "flusso", ognuno ha un assaggio del cibo per cani.

Come si effettivamente scegliere di dividere il normale lavoro di supporto non ha molta importanza (il round robin del giorno della settimana è solo un esempio). Ciò che importa è limitare il tempo di supporto a intervalli regolari fissi. Ciò rende il tempo di sviluppo più prevedibile con il trade-off che non si può avere "tutti lasciano tutto" per affrontare i problemi di supporto.

Questa è un'abilità che deriva davvero dall'esperienza e spesso viene chiesto alle persone di essere in grado di giudicare accuratamente una cosa del genere. Ho sempre lavorato in un gruppo abbastanza affiatato con uno stile informale, ma abbiamo sviluppato alcune regole empiriche che sembravano tenere bene.

Innanzitutto, nessuna attività richiede meno di una settimana. Stimare sempre in settimane, anche se un compito sembra solo richiedere alcuni giorni per realizzarlo. Ci sarà qualche ragione per cui non sarà fatto prima della fine della settimana.

In secondo luogo, dedica il massimo sforzo alla stima della quantità di tempo che l'attività richiederà, comprese le interruzioni, i problemi di assistenza clienti, le prove, ecc. Ora raddoppia quel numero. Questa è la tua stima (in settimane).

In terzo luogo, assicurati che il tuo manager non stia già aggiungendo un po 'di padding alle tue stime. Il nostro team ha avuto un manager lamentarsi delle nostre stime. Si è scoperto che lo avrebbe già moltiplicato per 2.1 (la stima del padding empiricamente derivata) e lo avevamo già raddoppiato prima di dirglielo.

Non è uno strumento di fantasia e potrebbe non essere un metodo perfetto, ma funziona sorprendentemente bene.

Le persone che fanno la stima devono capire che nessuna squadra è mai 100% su un progetto. Hai congedi per malattia, ferie, giuria, ferie in lutto, riunioni obbligatorie per le risorse umane (è tempo di benefici!), Riunioni di gruppo non legate al progetto, ritardo inevitabile, pause per il bagno, lavoro di supporto sugli articoli già in produzione, gestione delle e-mail, , configurando il nuovo computer dopo la morte del vecchio, rispondendo alle domande sul lavoro futuro e facendo stime per quel lavoro, mentoring juniores, ecc. che devono essere presi in considerazione. È irresponsabile che uno stimatore si assuma più di 6 ore su 8 disponibile al giorno. Questa è una garanzia che la scadenza non può essere soddisfatta. Se si garantisce che la scadenza non può essere soddisfatta, si garantisce un cliente scontento.

Hai assolutamente ragione: è difficile pianificare un progetto senza sapere tutto quello che succederà. Ma è molto importante tenere traccia delle cose che sono una norma così come i compiti che prevedi. Ecco dove la gestione della pianificazione svolge un ruolo. Ho utilizzato la gestione dei progetti Microsoft (versione standard) per la quale sono incluse anche funzionalità che fanno parte di un software di pianificazione della gestione dei progetti.

Per ulteriori informazioni, puoi visitare il link .

Sembra che ci sia un sacco di sforzo nascosto tratto dai team di progetto attraverso il quale stai perdendo concentrazione e velocità. Potrebbe essere utile separare effettivamente l'attività per affrontare

..support issues and bugs and stuff?

a un gruppo specifico di persone in modo che gli altri membri del team possano concentrarsi sulle nuove attività di sviluppo. In questo modo la loro produzione complessiva potrebbe diminuire un po ', ma la qualità migliorerà perché c'è meno distrazione. Questo in cambio ridurrà il numero di bug, quindi un lavoro ad-hoc che fa strada nei tuoi progetti.

Per quanto riguarda la parte di pianificazione, sono completamente d'accordo con la risposta di Thomas Owens.