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

Question

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

#1 da (4 voti)
#2 da (3 voti)
#3 da (0 voti)

9

Il cambiamento non è raro, modifica dei requisiti, modifica delle modifiche delle specifiche nel flusso di lavoro. Ho accettato che ci saranno dei cambiamenti, ma mi chiedo: sapendo che il cambiamento sta per accadere, quanto poco 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 compagnia "pianifichi" 1 [intervallo di tempo (dall'alto)] in anticipo rispetto alla corrente in modo tale che qualsiasi piano abbia il seguente aspetto:

"[questa mattina / oggi / questa settimana / ecc.] lavorerai su questo e [questo pomeriggio / domani / la prossima settimana / ecc.] su cui lavorerai che .

Supponi anche che le modifiche di messa a fuoco / direzione si verificheranno in modo coerente ogni secondo al terzo intervallo di tempo.

project-management estimation time-management

posta Steven Evers 20.10.2010 - 22:44

fonte

3 risposte

Leggi altre domande sui tag project-management estimation time-management

GUI, BLL, DAL Organizzazione in un progetto È sbagliato gettare i rami della forza di spinta?

score 4 · Answer 1

Sono uno Scrum Practitionner quindi ti suggerirò di usarlo.

Definisci la durata della tua iterazione. Mi piacciono le iterazioni di due settimane nelle startup e un mese in grandi progetti aziendali
All'inizio di un'iterazione, selezionare tra le funzionalità sviluppate dal backlog del prodotto. Nessuno ha il diritto di modificare il piano di iterazione, nemmeno il gestore del prodotto.
Le modifiche si verificano nel backlog del prodotto, non nel piano di iterazione. Pertanto, non sei mai interessato nel tuo lavoro.

Maggiori dettagli su Scrum

score 3 · Answer 2

Pianificare tende spesso a far perdere l'immagine più grande in tutti i dettagli, e finisci 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 sono lunghe 1-2 settimane.

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

score 0 · Answer 3

Rompendo le cose in questo modo:

Qualsiasi sviluppo significativo di progetti / applicazioni - 1 settimana.
Semplici miglioramenti one-off vengono inseriti in un elenco, con priorità e ognuno viene indirizzato in periodi da metà a giornata intera.
Le correzioni dei bug hanno solitamente priorità e seguono 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 nuovo sito web che fa yadda, yadda, yadda, c'è più pianificazione in anticipo che correggere un bug. Chi pianifica bug in anticipo? Il direttore del dipartimento scopre di aver dimenticato qualcosa e di averne bisogno per la segnalazione di fine trimestre, devi mettere da parte le cose e lavorarci sopra.

Un'iterazione settimanale può avere 10 ore o 50. Tutto dipende da quante altre cose sono immediate. Penso che sia molto più facile per il management capire i contorni temporali 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.