Best practice per la spedizione puntuale del software

Question

Immagina di non avere il problema del creep di funzionalità, di avere un team motivato e stabile, di chiarire i problemi definiti da risolvere, E conosci il dominio / lingua / strumenti relativi al tuo progetto.

Come attenersi a un programma e raggiungere quel traguardo 1.0?
Qual è il tuo approccio a una spedizione iterativa ?

Vorrei raccomandazioni appositamente per un piccolo team, dove ci sono pochi o quasi nessun problema di comunicazione.

Answer 1

1. Concentrati sulle funzioni e non sulle attività di implementazione.
2. Lavora in iterazioni (come settimanali o bisettimanali).
3. Rilascia le funzioni di lavoro nel tuo ambiente di staging in ordine di priorità.
4. Unit test il tuo codice mentre procedi, quindi non sei rallentato da una lista di bug che aumenta geometricamente man mano che ti avvicini alla data di rilascio.
5. Preparati a tagliare l'ambito dalle funzionalità meno importanti. Le cose richiedono sempre più tempo di quanto pensi.
6. Assicurati di disegnare in anticipo l'interfaccia utente (se esiste un'interfaccia utente) e mostrarla ai potenziali utenti.
7. Prova, testa e prova ancora un po '. Questo sembra controintuitivo, ma consente di risparmiare più tempo di quanto non sia necessario.

Answer 2

Questo è probabilmente uno scenario utopico ;-). Ma comunque, se non ci sono caratteristiche limitate, un'ottima squadra e requisiti chiaramente definiti senza assolutamente problemi di comunicazione, probabilmente il modo migliore per consegnare il prodotto in tempo sarebbe

1. Incontro settimanale con il team per valutare lo stato corrente (PM con il team, se è presente un PM)
2. Il responsabile del team può tenere un piccolo incontro quotidiano con i membri del team per valutare il loro stato sui problemi / requisiti loro delegati. Se ci sono problemi, lui / lei dovrebbe prendere le misure necessarie per risolvere il problema.
3. Monitoraggio del piano di progetto e delega del lavoro (il team leader dovrebbe conoscere i punti di forza individuali di ciascun membro del team per delegare il lavoro in modo appropriato).
4. I test possono essere automatizzati nella misura consentita dalla tecnologia.
5. Proprietà del lavoro di ciascun membro del team.

Alla fine della giornata, si riduce a quanto una persona sia appassionata del proprio lavoro.

Solo le mie 2 paise ;-)

Answer 3

Domanda: In che modo un grande progetto software arriva con un anno di ritardo? Risposta: un giorno alla volta!

Ciò non fornisce una risposta alla tua domanda, ma penso che ciò indichi la necessità di attenersi al tuo programma: se hai anche un giorno di ritardo, devi recuperarlo in qualche modo. (Sfortunatamente, il resto di The Mythical Man Month è tutto incentrato su come nella maggior parte dei progetti non ci sia "in qualche modo" ...)

Inoltre, dai un'occhiata all'Evidence Based Scheduling in prodotti come FogBugz . Ciò fornirà una stima aggiornata di quando è probabile che il prodotto venga spedito, in effetti, fornisce un intervallo di date, con probabilità per ogni data. Se vedi che la tua probabile data di rilascio sta scivolando oltre la scadenza, questo ti farà sapere che devi fare qualcosa al riguardo - e si spera con abbastanza tempo per avere un effetto.

Answer 4

C'è un piccolo punto mancato dai precedenti poster. Per rispettare la scadenza prima di tutto è necessario definire un programma realistico. Il progetto dovrebbe essere suddiviso in piccoli compiti, dipende dalle dimensioni del progetto, ma nel mio mondo con progetti che richiedono circa 3-4 mesi, stiamo cercando di dividerli in un massimo di 2-3 giorni. In questo modo la stima del tempo è per lo più realistica e i rischi vengono calcolati in anticipo e aggiunti al programma proposto.

Answer 5

Ci sono molti buoni consigli in questa discussione. L'unica cosa che devo aggiungere è adottare un calendario regolare per le versioni. La mia azienda è passata a questo alcuni anni fa ed è stato inizialmente doloroso, ma ha molti vantaggi, il più grande dei quali è consentire alle persone di rinviare facilmente le funzionalità.

Va ??bene rinviare le funzionalità perché sai che la tua funzionalità può passare alla versione successiva e sai quando sarà quella versione. Ciò significa che invece di affrettarti a ottenere la tua caratteristica da forno all'ultimo minuto, puoi spendere un po 'più a lungo e averlo all'inizio della prossima versione.

Answer 6

Escludendo tempistiche irragionevoli da vendite / marketing / gestione, hai praticamente escluso tutti i motivi per cui un progetto non viene spedito in tempo. La storia delle metodologie di sviluppo software è una raccolta di metodi per aggirare, ridurre l'impatto e / o evitare:

• ambito definito male
• creep
• mancanza di conoscenza del dominio
• grandi team con problemi di comunicazione
• sviluppatori non motivati ??/ incompetenti

Answer 7

Scopri quali sono le funzioni mission-critical per il cliente. Proteggi i progressi su di essi. È spesso vero che l'80% del successo proviene dal 20% del lavoro.

Answer 8

Stage periodic (mensili? settimanali?) procedure dettagliate sui prodotti che utilizzano l'attuale build accettata, a beneficio del team del prodotto. Inizia questi il ??prima possibile. Demo ogni funzione, indipendentemente dalla loro usabilità attuale; non saltare quelli che sono in ritardo.

Il punto è fornire agli stakeholder un'idea chiara dello stato attuale del prodotto nel corso del progetto. In questo modo i responsabili delle decisioni hanno maggiori probabilità di affrontare prontamente i rischi programmati, piuttosto che mettere a repentaglio la data della nave.

Answer 9

Mi piace dire che puoi scegliere un set di funzionalità o una data di spedizione, ma non entrambi.

Ecco alcuni pensieri individuali: - non essere ottimista - fai prima la parte difficile - non aggiungere funzionalità senza sfuggire al programma - scrivere le funzionalità in modo tale da poterle rilasciare per accedere alla pianificazione

http://shipcamp.com