Pulizia dei bug nel bel mezzo di un progetto

Question

Pulizia dei bug nel bel mezzo di un progetto

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

4

Nella mia attuale azienda, in tutti i progetti software in cui sono stato, di solito c'è una fase alla fine di un progetto che richiede una buona quantità di tempo ed è dedicata alla lucidatura di nuove funzionalità in modo che siano pronte per il lancio .

Nel libro "Guida alla sopravvivenza del progetto software" di Steve McConnell, sostiene di farlo dopo ogni importante pietra miliare che è stata completata su un progetto (e probabilmente anche a quel punto). Diciamo che non vogliamo lanciare dopo aver completato importanti traguardi, perché il nostro prodotto deve essere lanciato in uno stato più coerente. Qualcuno di voi ha avuto un'esperienza positiva con seri sforzi di pulizia dei bug eseguiti un paio di volte durante la durata del progetto, invece di farlo prima del lancio?

project-management

posta Petko M 13.05.2011 - 23:09

fonte

6 risposte

Leggi altre domande sui tag project-management

Config di analisi statica e script di convenienza nel controllo del codice sorgente E riguardo le prestazioni di più bit nei database comuni?

score 3 · Answer 1

In una società precedente trascorriamo un'intera giornata ogni due settimane per correggere bug. Se avessimo finito la lista, saremmo partiti presto. Faceva pressione su tutti per trovare bug che esistevano nel codice. Preferisco questa strategia più che passare una settimana a inseguire i bug alla fine del progetto.

score 3 · Answer 2

Risolviamo bug quando li troviamo e li ritengono di priorità sufficientemente alta. In pratica di solito risolviamo quasi tutti i bug che vengono registrati immediatamente. Non aspettiamo mai la "fine" di un progetto per bug. Potremmo spingere le funzionalità per essere dopo la versione iniziale. I bug vengono semplicemente corretti quando sono considerati il ticket con il maggior ROI.

score 1 · Answer 3

Non è questa una delle domande della lista di controllo di Joel? "Risolvi i bug prima di implementare nuove funzionalità?" Credo di si. Ad ogni modo, dopo aver pensato a quella domanda, l'ho provato e, whaddya 'so, ha funzionato! Non solo, ma trovare il bug di solito significava trovarne un altro in più. Così ora sono a volte piuttosto coscienzioso, rimandando la nuova funzionalità - davvero fighissima! quindi sexy! - fino a quando non vengono corretti errori precedenti. Funziona alla grande.

È accaduto anche qualcos'altro: la nuova funzione iper-cool che non vedevo l'ora di aggiungere la scorsa settimana? Ricorda quel babbeo che sono saltato fuori dal letto (aspettando che vedano questo merda!) Al codice? Bene, questa settimana è solo un altro oggetto (sbadiglio!) nell'elenco delle caratteristiche. Questa è stata un'intuizione nuova di zecca per me: le cose fantastiche diventano subito un ho-hum.

Credo che sia una buona cosa.

score 0 · Answer 4

Non farlo. Questo è il processo di sviluppo equivalente all'ottimizzazione prematura.

Quando si scende al filo, e iniziano le revisioni finali, non è raro che le funzionalità vengano eliminate. Se hai perso tempo a eseguire il debug di queste funzionalità, è tempo di perdere tempo.

Al contrario, le funzionalità sono spesso aggiunte vicino alla fine dello sviluppo. Se devi rivisitare una porzione di codice per aggiungere più funzionalità, allora stai reintroducendo i bug in un territorio "pulito", che ti lascerà coprire lo stesso terreno di nuovo durante la fase di debug.

E infine, a volte le librerie dipendenti risultano troppo problematiche e vengono sostituite o sostituite. Se hai sviluppato soluzioni alternative per cercare di arginare il flusso di bug, è tempo perso.

Buttalo fuori in un modo funzionante, poi torna indietro e aggiusta ciò che non va in modo ordinato e sistematico.

score 0 · Answer 5

Dove ho lavorato ci sarebbe stato un bug generale per ripulire periodicamente i tempi poiché la combinazione di numero e priorità dei bug era abbastanza alta da giustificare la correzione di the broken windows. Quindi, questo può essere fatto una manciata di volte o più in un progetto che si estende per un paio di anni, per esempio.

score 0 · Answer 6

Idealmente, i bug dovrebbero essere rimossi il prima possibile, (preferibilmente prima di inserirli!). Alcuni dei problemi con l'interruzione di bug sono:

È difficile stimare quanto tempo impiegherà il ckean. La natura dei bug è che spesso conosci il sintomo ma non la causa.
I bug tendono a nascondere altri bug.
I bug spesso impediscono il corretto test. Fino a quando i bug non vengono risolti, non è possibile dimostrare che l'applicazione copre le specifiche, tanto meno lo soddisfa.
Gli sviluppatori risolveranno i bug e li tratteranno anche come funzionalità. Questo lascerà il codice disordinato e difficile da eseguire il debug.
La fiducia degli utenti nell'applicazione sarà ridotta se vedono una versione preliminare con un sacco di bug. Gli utenti si fidano di se stessi più dell'app, quindi portano a bug-report spuri e perdite di tempo.
Alcuni bug logici, quando vengono rilevati in anticipo, possono essere risolti abbastanza facilmente, ma se catturati in ritardo richiedono una riprogettazione sostanziale.
Pochissimi bug hanno una bassa priorità. Se sono non importanti , probabilmente esistono in parti dell'applicazione che non sono importanti. In tal caso, potrebbero esserci interi moduli di codice che non dovrebbero mai essere stati scritti in primo luogo.
I bug sono demoralizzanti per i programmatori, portando a una qualità inferiore e alla produzione più lenta del codice.

La legge di Kramii del giorno: ci sono momenti in cui lo sviluppo di nuove funzionalità è più importante della caccia agli insetti, ma queste sono meno frequenti di quanto si pensi, anche tenendo conto della legge di Kramii del giorno.