Monitoraggio dei problemi distribuiti [chiuso]

Solo perché source control + distributed è stato un grande successo, issue tracking + distributed non è necessariamente una buona idea.

Che cosa otteniamo dal controllo distribuito del codice sorgente e si applicherebbe al monitoraggio dei problemi?

Facile ramificazione e fusione : non proprio. In realtà è fondamentale che tutti siano sulla stessa pagina. Quindi la ramificazione sarebbe altamente indesiderabile.

Prestazioni : la quantità di dati trasmessi da un tracker di problemi è piuttosto piccola e tutto il lavoro pesante è fatto sul server, quindi non è un problema.

Flussi di lavoro avanzati (push, pull, staging, ecc.): i tracker di problemi dispongono già di flussi di lavoro buoni (e spesso altamente configurabili). Quindi non abbiamo bisogno di un sistema distribuito per questo. Al contrario, renderebbe le cose molto più difficili, dato che devi affrontare cambiamenti in conflitto.

Funzionalità offline : certo, queste sarebbero belle. Tuttavia, questi possono anche essere ottenuti senza andare completamente distribuiti.

Inoltre, il controllo del codice sorgente (distribuito) è utilizzato quasi esclusivamente dai programmatori. Il rilevamento dei problemi viene utilizzato anche da tester, progettisti, redattori tecnici, manager, marketing e, a volte, persino dagli utenti finali. Queste persone con meno conoscenze informatiche potrebbero avere difficoltà a comprendere le complessità di un sistema distribuito.

Non penso che essere decentralizzati sia importante quanto avere funzionalità off-line. L'integrazione con il controllo del codice sorgente è un grande vantaggio, quindi desideri che ciascun utente sia in grado di gestire comodamente entrambe le attività. Più vicini lo fanno, più continuità avrai.

Anche i team più distribuiti dovrebbero essere in grado di mettere insieme un server web e un sistema di tracciamento. Sarebbe più vantaggioso avere un bug tracker centrale poiché ogni utente ha bisogno solo di un sottoinsieme del database dei bug. I bug vengono solitamente assegnati a qualcuno che può lavorarci individualmente. Non c'è niente di sbagliato nell'essere non disponibile a tutti gli altri se utilizza una sorta di sistema di "check-out" che lo lascia in uno stato di sola lettura. Un sito Web consente inoltre ai clienti / utenti di accedere e visualizzare i propri biglietti.

Ti stai avvicinando a qualcosa con la necessità offline, ma molti dei problemi che hai affrontato potrebbero essere evitati semplicemente verificando che parti del bug-tracker funzionino mentre sono disconnesse.

Per molti utenti, uno dei migliori strumenti di integrazione è l'e-mail soprattutto quando ci sono persone al di fuori del team. Non ho intenzione di tornare al tuo sito web per vedere se il mio problema è stato risolto. Desidero un'email con un possibile link di risposta per fornire feedback. Qualsiasi sviluppatore che risponde a un'e-mail di richiesta di modifica, può inviare una risposta e averla rintracciata nel sistema.

Sarò molto specifico sui prodotti reali. Ad alcuni probabilmente piacerà questo e altri forse no, ma ecco qui:

Nel corso degli anni ho utilizzato un sacco di strumenti per il rilevamento di problemi, attività e progetti. Microsoft Project, Trello e Jira hanno tutti avuto il loro posto.

Ora utilizzo Pivotal Tracker. Mi piace la sua raffinatezza e semplicità d'uso e mi piace molto il modo in cui le altre persone modificano e aggiornano i ticket, le modifiche vengono apportate e evidenziate anche nella finestra, quindi è di gran lunga il miglior stile "di rete" di questi strumenti che io ve provato.

Non del tutto sicuro se questo è ciò che intendi per distribuzione, ma eccoti.

Se lo è, mi ci abituerò e poi guarderò le carenze di Pivotal Tracker (se ce ne sono) per te prima di sviluppare un'alternativa.