Considerando un cambiamento coerente, quanto è breve un periodo di pianificazione troppo breve?

Il cambiamento non è insolito, il cambiamento dei requisiti, il cambiamento delle specifiche cambia nel flusso di lavoro. Ho accettato che ci saranno cambiamenti, ma mi chiedo: sapendo che il cambiamento sta per accadere, quanto è breve un periodo di pianificazione troppo breve? (Le giustificazioni sono incoraggiate)

• Un'iterazione (2-4 settimane)?
• Una settimana?
• Un periodo di 2-3 giorni?
• Un giorno?
• 1/2 al giorno?

Supponiamo che la società "pianifichi" 1 [intervallo di tempo (dall'alto)] in anticipo dalla corrente in modo che qualsiasi piano suoni come:

"[questa mattina / oggi / questa settimana / etc.] si lavorerà su questo e [questo pomeriggio / domani / prossima settimana / etc.] si lavorerà su quella .

Supponi anche che i cambiamenti di messa a fuoco / direzione si verifichino costantemente ogni intervallo di tempo dal secondo al terzo.

Sono uno Scrum Practitionner, quindi ti suggerirò di usarlo.

1. Definisci la durata della tua iterazione. Mi piacciono due settimane di iterazione nelle startup e un mese in progetti di grandi aziende
2. All'inizio di una iterazione, selezionare tra le funzionalità che si svilupperanno dal backlog del prodotto. Nessuno ha il diritto di modificare il piano di iterazione, nemmeno il product manager.
3. Le modifiche si verificano nel backlog del prodotto, non nel piano di iterazione. Pertanto, non sei mai interessato al tuo lavoro.

Maggiori dettagli su Scrum

Pianificare spesso tende a far perdere l'immagine più grande in tutti i dettagli e si finisce per girare le ruote. Questo è un rischio enorme.

Preferisco usare XP (o Scrum) che dice che dovresti pianificare una volta all'inizio di ogni iterazione, che trovo più efficace quando durano 1-2 settimane.

Detto questo, ci sono alcune cose molto interessanti in Kanban che incoraggiano la pianificazione ad avvenire quando necessario, anche se personalmente penso che Kanban sia più adatto per le situazioni di manutenzione e supporto piuttosto che quando si inizia lo sviluppo da zero.

Divido le cose in questo modo:

1. Qualsiasi sviluppo significativo di progetto / applicazione - 1 settimana.
2. Semplici miglioramenti una tantum vengono inseriti in un elenco, con priorità e ciascuno viene indirizzato in periodi da metà a giornata intera.
3. Le correzioni di bug di solito hanno la priorità e passano attraverso un processo simile al n. 2, ma a volte possono essere risolte molto più rapidamente.

Il fattore chiave qui è quanta pianificazione puoi effettivamente fare per una determinata attività? Avvio di un sito Web nuovo di zecca che fa yadda, yadda, yadda, c'è più pianificazione in anticipo che correzione di un bug. Chi pianifica i bug in anticipo? Il responsabile di dipartimento scopre di aver dimenticato qualcosa e di averne bisogno per la fine del trimestre, devi mettere da parte le cose e lavorarci sopra.

Un'iterazione settimanale può avere 10 ore o può avere 50. Tutto dipende da quanto altre cose sono immediate. Penso che sia molto più facile per il management capire i limiti di tempo quando chiedi, se dovresti mettere da parte un progetto per fare una piccola aggiunta? Sono piacevolmente sorpreso quando identificano quel piccolo cambiamento come non necessario e dovrei continuare a lavorare sul sito web yadda-yadda-yadda.