Motivi per non creare il proprio sistema di tracciamento dei bug [chiuso]

https://stackoverflow.com/questions/62153

bug-tracking

09-06-2019
|

Domanda

Diverse volte mi sono trovato di fronte ai piani di un team che vuole costruire il proprio sistema di tracciamento dei bug: non come prodotto, ma come strumento interno.

Gli argomenti che ho sentito a favore sono solitamente sulla falsariga di:

Voler "mangiare il nostro cibo per cani" in termini di una struttura web costruita internamente
Necessità di un rapporto altamente specializzato o della capacità di modificare alcune funzionalità in un modo presumibilmente unico
Credere che non sia difficile costruire un sistema di tracciamento dei bug

Quali argomenti potresti utilizzare per supportare l'acquisto di un sistema di tracciamento dei bug esistente?In particolare, quali funzionalità sembrano facili ma si rivelano difficili da implementare, oppure sono difficili e importanti ma spesso trascurate?

Soluzione

Per prima cosa, guarda questi Ohloh metrica:

    Trac:  44 KLoC, 10 Person Years,   $577,003
Bugzilla:  54 KLoC, 13 Person Years,   $714,437
 Redmine: 171 KLoC, 44 Person Years, $2,400,723
  Mantis: 182 KLoC, 47 Person Years, $2,562,978

Cosa impariamo da questi numeri?Impariamo che costruire Yet Another Bug Tracker è un ottimo modo per sprecare risorse!

Quindi ecco i miei motivi per creare il tuo sistema interno di tracciamento dei bug:

Devi neutralizzare tutti i bozocoder per un decennio o due.
È necessario buttare un po' di soldi per evitare la riduzione del budget l'anno prossimo.

Altrimenti no.

Altri suggerimenti

Vorrei ribaltare la questione.PERCHÉ mai vorresti costruirne uno tuo?
Se hai bisogno di alcuni campi aggiuntivi, scegli un pacchetto esistente che può essere modificato.
Rapporto speciale?Accedi al database e fallo.

Credere che non sia difficile?Prova allora.Specificalo e guarda crescere l'elenco delle funzionalità e degli orari.Quindi, una volta completato l'elenco, provare a trovare un pacchetto esistente che possa essere modificato prima di implementarne uno proprio.

In breve, non reinventare la ruota quando un'altra ha solo bisogno di qualche modifica per adattarsi.

Ai programmatori piace costruire il proprio sistema di ticket perché, avendone visti e usati dozzine, ne sanno tutto.In questo modo possono rimanere nella zona di comfort.

È come visitare un nuovo ristorante:potrebbe essere gratificante, ma comporta un rischio.Meglio ordinare di nuovo la pizza.

C'è anche un grande fatto relativo al processo decisionale sepolto lì dentro:ci sono sempre due motivi per fare qualcosa:quello buono e quello giusto.Prendiamo una decisione ("Costruisci la nostra"), quindi la giustifichiamo ("abbiamo bisogno del pieno controllo").La maggior parte delle persone non è nemmeno consapevole della propria vera motivazione.

Per fargli cambiare idea, devi attaccare il vero motivo, non la giustificazione.

La sindrome non inventata qui!

Costruisci il tuo bug tracker?Perché non creare il tuo client di posta, uno strumento di gestione dei progetti, ecc.

COME Omer van Kloeten dice altrove, paga ora o paga più tardi.

C'è una terza opzione, né comprare né costruire.Ci sono pile di buoni gratuiti là fuori.Per esempio:

Utilizzare il proprio bug tracker per qualsiasi uso diverso dall'apprendimento non è un buon uso del tempo.

Altri collegamenti:

Direi solo che è una questione di soldi: comprare un prodotto finito che sai che ti fa bene (e talvolta nemmeno comprarlo se è gratuito) è meglio che dover svilupparne uno da solo.È un semplice gioco di paga ora contro paga dopo.

Innanzitutto, contro gli argomenti a favore della costruzione del proprio:

Voler "mangiare il nostro cibo per cani" in termini di una struttura web costruita internamente

Ciò ovviamente solleva la questione del perché creare il proprio framework web.Proprio come ci sono molti validi bug tracker gratuiti là fuori, ci sono anche molti framework validi.Mi chiedo se i tuoi sviluppatori abbiano ben chiare le loro priorità?Chi sta facendo il lavoro che fa guadagnare soldi veri alla tua azienda?

OK, se devono costruire una struttura, lascia che si evolva organicamente dal processo di creazione del software effettivo che la tua azienda utilizza per fare soldi.

Necessità di un rapporto altamente specializzato o della capacità di modificare alcune funzionalità in un modo presumibilmente unico

Come altri hanno già detto, prendi uno dei tanti ottimi tracker open source e modificalo.

Credere che non sia difficile costruire un sistema di tracciamento dei bug

Bene, ho scritto la prima versione del mio BugTracker.NET in appena un paio di settimane, iniziando senza alcuna conoscenza preliminare di C#.Ma ora, 6 anni e un paio di migliaia di ore dopo, c'è ancora un lungo elenco di richieste di funzionalità annullate, quindi tutto dipende da cosa vuoi che faccia un sistema di tracciamento dei bug.Quanta integrazione della posta elettronica, integrazione del controllo del codice sorgente, autorizzazioni, flusso di lavoro, monitoraggio del tempo, stima della pianificazione, ecc.Un bug tracker può essere un'applicazione importante e importante.

Quali argomenti potresti utilizzare per supportare l'acquisto di un sistema di tracciamento dei bug esistente?

Non è necessario acquistarlo. Troppi buoni open source: Trac, Mantis_Bug_Tracker, il mio BugTracker.NET, solo per citarne alcuni.

In particolare, quali funzionalità sembrano facili ma si rivelano difficili da implementare, oppure sono difficili e importanti ma spesso trascurate?

Se lo state creando solo per voi stessi, allora potete prendere molte scorciatoie, perché potete cablare le cose.Se lo stai creando per molti utenti diversi, in molti scenari diversi, allora è il supporto per la configurabilità che è difficile.Flusso di lavoro configurabile, campi personalizzati e autorizzazioni.

Penso che due caratteristiche che a Bene il bug tracker deve avere entrambi FogBugz e BugTracker.NET hanno, sono 1) integrazione della posta elettronica sia in entrata che in uscita, in modo che l'intera conversazione su un bug conviva con il bug e non in un thread di posta elettronica separato, e 2) un'utilità per trasformare uno screenshot in un post di bug con solo un paio di clic.

L'argomento più basilare per me sarebbe la perdita di tempo.Dubito che possa essere completato in meno di un mese o due.Perché perdere tempo quando sono disponibili così tanti buoni sistemi di tracciamento dei bug?Fammi un esempio di una funzionalità che devi modificare e che non è immediatamente disponibile.

Penso che un buon sistema di tracciamento dei bug debba riflettere il tuo processo di sviluppo.Un processo di sviluppo molto personalizzato è intrinsecamente dannoso per un'azienda/team.La maggior parte delle pratiche agili sono favorevoli Mischia o questo genere di cose, e la maggior parte dei sistemi di tracciamento dei bug sono in linea con tali suggerimenti e metodi.Non essere troppo burocratico su questo.

Un sistema di tracciamento dei bug può essere un ottimo progetto su cui avviare gli sviluppatori junior.È un sistema abbastanza semplice che puoi utilizzare per addestrarli alle tue convenzioni di codifica e così via.Convincere gli sviluppatori junior a costruire un sistema del genere è relativamente economico e possono commettere errori su qualcosa che un cliente non vedrà.

Se è spazzatura puoi semplicemente buttarla via, ma puoi dare loro la sensazione che il lavoro sia già importante per l'azienda se viene utilizzato.Non è possibile imputare un costo al fatto che uno sviluppatore junior sia in grado di sperimentare l'intero ciclo di vita e tutte le opportunità di trasferimento delle conoscenze che un simile progetto porterà.

Lo abbiamo fatto qui.Abbiamo scritto il nostro primo più di 10 anni fa.Lo abbiamo quindi aggiornato per utilizzare i servizi web, più come un modo per apprendere la tecnologia.Il motivo principale per cui lo abbiamo fatto originariamente era che volevamo un sistema di tracciamento dei bug che producesse anche rapporti sulla cronologia delle versioni e alcune altre funzionalità che non riuscivamo a trovare nei prodotti commerciali.

Ora stiamo esaminando nuovamente i sistemi di tracciamento dei bug e stiamo seriamente considerando la migrazione a Mantis e l'utilizzo di Mantis Connect per aggiungere ulteriori funzionalità personalizzate.Lo sforzo necessario per implementare il nostro sistema è semplicemente troppo grande.

Immagino che dovremmo dare un'occhiata anche a FogBugz :-)

Ancora più importante, dove invierai i bug per il tuo bug tracker prima che sia finito?

Ma sul serio.Gli strumenti esistono già, non è necessario reinventare la ruota.Modificare gli strumenti di monitoraggio per aggiungere determinate funzionalità specifiche è una cosa (ho modificato Trac Prima)...riscriverne uno è semplicemente stupido.

La cosa più importante che puoi sottolineare è che se tutto ciò che vogliono fare è aggiungere un paio di report specializzati, non è necessaria una soluzione dal basso.Inoltre, l'ULTIMO posto in cui conta la "tua soluzione homebrew" è per gli strumenti interni.A chi importa cosa usi internamente se sta portando a termine il lavoro quando ne hai bisogno?

Essendo un programmatore che lavora su un compito già critico (o meno importante), non dovrebbe lasciarsi deviare cercando di sviluppare qualcosa che è già disponibile sul mercato (open source o commerciale).

Ora proverai a creare un sistema di tracciamento dei bug per tenere traccia del sistema di tracciamento dei bug che utilizzi per tenere traccia dei bug nel tuo sviluppo principale.

Primo:1.Scegli la piattaforma che il tuo sistema di bug sarebbe eseguito su (Java, PHP, Windows, Linux ecc.) 2.Prova a trovare strumenti open source disponibili (per open source, intendo sia strumenti commerciali che gratuiti) sulla piattaforma che hai scelto 3.Dedica un tempo minimo per provare a personalizzare in base alle tue esigenze.Se possibile, non perdere affatto tempo nella personalizzazione

Per un team di sviluppo aziendale, abbiamo iniziato a utilizzare JIRA.Volevamo alcuni report aggiuntivi, accesso SSO, ecc.JIRA ne era capace e abbiamo potuto estenderlo utilizzando il plugin già disponibile.Poiché al codice è stata fornita parte del supporto a pagamento, abbiamo dedicato solo un tempo minimo alla scrittura del plug-in personalizzato per l'accesso.

Basandosi su ciò che hanno detto gli altri, piuttosto che scaricarne semplicemente uno gratuito/open source.Che ne dici di scaricarlo e poi modificarlo interamente per le tue esigenze?So che mi è stato richiesto di farlo in passato.Ho preso un'installazione di Bugzilla e poi l'ho modificata per supportare i test di regressione e il reporting dei test (questo è successo molti anni fa).

Non reinventare la ruota se non sei convinto di poter costruire una ruota più rotonda.

Direi che uno dei maggiori ostacoli sarebbe l'agonia del modello dati/flusso di lavoro.Prevedo che ci vorrà un lungo tempo e comportano molte discussioni su cosa dovrebbe accadere a un bug in determinate circostanze, cosa costituisce realmente un bug, ecc.Invece di passare mesi a discutere avanti e indietro, se dovessi semplicemente implementare un sistema precostruito, la maggior parte delle persone imparerebbe come usarlo e trarne il meglio, indipendentemente dalle decisioni già prese.Scegli qualcosa di open source e potrai sempre modificarlo in seguito, se necessario: lo sarà tanto più veloce che crearne uno tuo da zero.

A questo punto, senza una nuova direzione nel tracciamento/bigliettazione dei bug, si tratterebbe semplicemente di reinventare la ruota.Il che sembra essere quello che pensano tutti gli altri, in generale.

Le tue discussioni inizieranno con ciò che costituisce un bug e si evolveranno in quale flusso di lavoro applicare e finiranno con una discussione massiccia su come gestire i progetti di ingegneria del software.Lo vuoi davvero?:-) No, non pensavo: vai a comprarne uno!

La maggior parte degli sviluppatori pensa di avere dei poteri unici che nessun altro ha e quindi di poter creare un sistema in qualche modo unico.

Il 99% di loro ha torto.

Quali sono le probabilità che la vostra azienda abbia dipendenti nell'1%?

Sono stato su entrambi i lati di questo dibattito, quindi permettetemi di essere un po' bifronte qui.

Quando ero più giovane, ho spinto a costruire il nostro sistema di tracciamento dei bug.Ho semplicemente evidenziato tutte le cose che il materiale standard non poteva fare e ho chiesto al management di farlo.Chi hanno scelto per guidare la squadra?Me!Sarebbe stata la mia prima occasione di essere a capo di un team e di avere voce in capitolo in tutto, dalla progettazione agli strumenti al personale.Sono rimasto basito.Quindi la mia raccomandazione sarebbe quella di verificare le motivazioni delle persone che spingono questo progetto.

Ora che sono più grande e mi trovo di nuovo di fronte alla stessa domanda, ho deciso di optare per FogBugz.Fa il 99% di quello che ci serve e i costi sono praticamente 0.Inoltre, Joel ti invierà e-mail personali facendoti sentire speciale.E alla fine, non è questo il problema, i tuoi sviluppatori pensano che questo li renderà speciali?

Ogni sviluppatore di software desidera creare il proprio sistema di tracciamento dei bug.È perché possiamo ovviamente migliorare ciò che è già disponibile poiché siamo esperti di dominio.

Quasi certamente non vale il costo (in termini di ore di sviluppo).Basta comprare JIRA.

Se hai bisogno di report aggiuntivi per il tuo sistema di tracciamento dei bug, puoi aggiungerli, anche se devi farlo accedendo direttamente al database sottostante.

La domanda è: per cosa ti paga la tua azienda?È per scrivere software che utilizzerai solo tu?Ovviamente no.Quindi l'unico modo per giustificare il tempo e i costi necessari per costruire un sistema di tracciamento dei bug è se costa meno dei costi associati all'utilizzo anche di un sistema di tracciamento dei bug gratuito.

Potrebbero esserci casi in cui questo ha senso.Hai bisogno di integrarti con un sistema esistente?(Monitoraggio del tempo, stima, requisiti, QA, test automatizzati)?Hai alcuni requisiti unici nella tua organizzazione legati, ad esempio, alla conformità SOX che richiedono elementi di dati specifici che sarebbero difficili da acquisire?

Ti trovi in un ambiente estremamente buracratico che porta a notevoli "tempi di inattività" tra i progetti?

Se la risposta è sì a questo tipo di domande, allora l'argomento "acquisto" vs costruzione direbbe sicuramente costruire.

Se "Abbiamo bisogno di un rapporto altamente specializzato o della capacità di modificare alcune funzionalità in un modo presumibilmente unico", il modo migliore ed più economico per farlo è parlare con gli sviluppatori dei sistemi di tracciamento dei bug esistenti.Pagali per inserire quella funzionalità nella loro applicazione, renderla disponibile al mondo.Invece di reinventare la ruota, basta pagare i produttori di ruote per inserire raggi a forma di molla.

Altrimenti, se si tenta di mostrare un quadro, va tutto bene.Assicurati solo di inserire le relative dichiarazioni di non responsabilità.

Per le persone che credono che il sistema di tracciamento dei bug non sia difficile da costruire, seguire rigorosamente l'SDLC a cascata.Ottieni tutti i requisiti in anticipo.Ciò li aiuterà sicuramente a comprenderne la complessità.Solitamente si tratta delle stesse persone che affermano che un motore di ricerca non è così difficile da costruire.Solo una casella di testo, un pulsante "cerca" e un pulsante "mi sento fortunato", e il pulsante "mi sento fortunato" può essere creato nella fase 2.

Utilizzare alcuni software open source così come sono.Di sicuro ci sono dei bug e avrai bisogno di ciò che non è ancora presente o è in attesa di una correzione dei bug.Succede sempre.:)

Se estendi/personalizzi una versione open source, devi mantenerla.Ora l'applicazione che dovrebbe aiutarti con i test applicazioni per fare soldi diventerà un peso da sostenere.

Penso che il motivo per cui le persone scrivono i propri sistemi di tracciamento dei bug (secondo la mia esperienza) siano:

Non vogliono pagare per un sistema che considerano relativamente facile da costruire.
L'ego del programmatore
Insoddisfazione generale per l’esperienza e la soluzione fornita dai sistemi esistenti.
Lo vendono come prodotto :)

Per me, il motivo principale per cui la maggior parte dei rilevatori di bug fallisce è che non offrono un'esperienza utente ottimale e può essere molto doloroso lavorare con un sistema che usi MOLTO, quando non è ottimizzato per l'usabilità.

Penso che l'altro motivo sia lo stesso per cui quasi ognuno di noi (programmatori) ha creato il proprio CMS o framework CMS personalizzato prima o poi (colpevole come accusato).Solo perché puoi!

Sono d'accordo con tutte le ragioni per NON farlo.Abbiamo provato per un po' di utilizzare quello che c'era là fuori, e alla fine abbiamo comunque scritto il nostro.Perché?Principalmente perché la maggior parte di essi è troppo ingombrante per coinvolgere chiunque tranne il personale tecnico.Abbiamo anche provato il campo base (che, ovviamente, non è progettato per questo scopo e ha fallito in questo senso).

Abbiamo anche ideato alcune funzionalità uniche che hanno funzionato benissimo con i nostri clienti:un pulsante "segnala un bug" che abbiamo inserito nel codice con una riga di javascript.Consente ai nostri clienti di aprire una piccola finestra, annotare rapidamente le informazioni e inviarle al database.

Ma sicuramente ci sono volute molte ore per programmare;è diventato un GRANDE progetto per animali domestici;tanto tempo nel fine settimana.

Se vuoi verificarlo: http://www.archerfishonline.com

Mi piacerebbe un feedback.

Abbiamo fatto questo...alcune volte.L'unico motivo per cui ne abbiamo costruito uno nostro è perché è successo cinque anni fa e non c'erano molte buone alternative.ma ora ci sono tantissime alternative.La cosa principale che abbiamo imparato costruendo il nostro strumento è che passerai molto tempo a lavorarci.E questo è il tempo che potresti fatturare per il tuo tempo.Ha molto più senso, come piccola impresa, pagare la tariffa mensile che puoi facilmente recuperare con una o due ore fatturabili, piuttosto che dedicare tutto quel tempo a lavorare da solo.Certo, dovrai fare alcune concessioni, ma a lungo termine starai molto meglio.

Quanto a noi, abbiamo deciso di rendere la nostra applicazione disponibile ad altri sviluppatori.Dai un'occhiata a http://www.myintervals.com

Perché Trac esiste.

E perché dovrai formare nuovo personale sul tuo software su misura quando probabilmente avrà esperienza in altri sistemi su cui puoi costruire piuttosto che buttare via.

Perché non è un tempo fatturabile e nemmeno molto utile a meno che tu non lo venda.

Sono disponibili sistemi di tracciamento dei bug perfettamente validi, ad esempio, FogBugz.

Ho lavorato per diversi anni in una startup da cui abbiamo iniziato Moscerini, uno strumento open source, su cui essenzialmente abbiamo costruito il nostro elaborato sistema di tracciamento dei bug.L'argomento era che avremmo evitato di spendere molti soldi per un sistema commerciale e avremmo ottenuto un sistema di tracciamento dei bug perfettamente adatto alle nostre esigenze.

Naturalmente si è rivelato molto più difficile del previsto e ha rappresentato una grande distrazione per gli sviluppatori, che oltre al nostro codice hanno dovuto occuparsi anche della manutenzione del sistema di tracciamento dei bug.Questo è stato uno dei fattori che hanno contribuito alla fine della nostra azienda.

Non scrivere il tuo software solo per poter "mangiare il tuo cibo per cani".Stai semplicemente creando più lavoro, quando probabilmente potresti acquistare un software che fa la stessa cosa (e meglio) spendendo meno tempo e denaro.

Diglielo, è fantastico, l'azienda potrebbe risparmiare un po' di soldi per un po' e sarà felice di contribuire con gli strumenti di sviluppo mentre lavori in questo anno sabbatico non retribuito.Chiunque desideri invece prendersi le ferie annuali per lavorare al progetto è libero di farlo.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow