Trello vs. Jira: confrontato dal punto di vista di uno sviluppatore

La produzione di software oggi non è la stessa di 20 anni fa. Il software è diventato sempre più complesso, con team distribuiti letteralmente in tutto il mondo e che dipendono da persone specializzate solo in una parte specifica del processo. Inoltre, UI/UX è diventata una questione molto importante in quanto la competizione per acquisire nuovi utenti e mantenere gli aumenti di quelli attuali.

Nell'ultimo anno ho lavorato a una dozzina di progetti e quasi tutti hanno utilizzato uno strumento di gestione dei progetti (PMT). Oggi non ti darò una presentazione di vendita per uno strumento specifico, ma piuttosto, ti fornirò una visione interna dal punto di vista di uno sviluppatore di come questi strumenti vengono utilizzati nella vita reale, nonché una panoramica di due rappresentanti utensili. Si spera che questo articolo aiuti i decisori e gli sviluppatori a capire cosa è più conveniente per loro, per il loro team e per il progetto su cui stanno lavorando.

Perché utilizzare uno strumento di gestione dei progetti?

Quando stavo iniziando, la maggior parte dei miei progetti non si basava su uno strumento di gestione dei progetti, quindi potresti chiederti se ne hai davvero bisogno. Gli sviluppatori non possono semplicemente creare software senza di loro? La risposta è che dipende da molteplici fattori, quindi analizziamone alcuni.

L'ascesa dei team globali

Nella maggior parte dei progetti, mi ritrovo a lavorare per persone in tutto il mondo e, sebbene sia davvero fantastico, pone anche una serie di sfide che un team di ufficio non dovrà affrontare. I fusi orari diventano un vero problema quando cerchi di convincere un collega a riparare o modificare una parte del sistema in cui non sei sufficientemente esperto.

Ci sono anche scenari in cui potresti non essere in grado di parlare con l'altro sviluppatore più di una o due volte alla settimana. Gli strumenti di gestione dei progetti aiutano a semplificare tali processi collaborativi perché diventano un canale ufficiale (e, per ragioni pratiche, a volte l'unico) per i membri del team per comunicare le proprie esigenze avanti e indietro.

Naturalmente, non si tratta semplicemente di comunicazione tra i singoli membri di un team distribuito. I PMT forniscono anche maggiori informazioni e visibilità a tutti i membri del team, consentendo loro di tenere traccia dei progressi degli altri membri del team e pianificare le loro attività di conseguenza.

Collaborazione

Potresti pensare di poter ottenere gli stessi risultati semplicemente collaborando via e-mail o altri canali di comunicazione. Un mio cliente l'ha fatto su un progetto a cui ho lavorato qualche mese fa, ed è stato un incubo. Le persone utilizzavano più e-mail per comunicare, quindi era difficile tenere traccia dei diversi thread. Inoltre, la comunicazione su un singolo problema diventa un puzzle suddiviso in diversi pezzi che vivono in diverse conversazioni e-mail. La maggior parte delle conversazioni e-mail ha toccato molteplici problemi che hanno reso sempre più difficile tenere traccia di ciò che restava da fare.

Gli strumenti di gestione dei progetti risolvono questo problema avendo un flusso di conversazione dedicato a ciascun problema, semplificandoti la vita, poiché ti consentono di trovare tutto ciò di cui hai bisogno (progetti, API e feedback) con un solo clic. Da una prospettiva collaborativa, questo può fare un'enorme differenza, poiché gli strumenti di gestione dei progetti consentono a tutti di accedere e visualizzare tutti i segmenti e le fasi del progetto, riducendo la necessità di comunicazioni e aggiornamenti costanti.

Gestisci i requisiti del progetto

Uno dei maggiori problemi che devono affrontare i team che non utilizzano uno strumento di gestione dei progetti è causato dalla natura intrinseca del software. Forse stai lavorando in una startup e hai fatto perno più di un paio di volte. Forse i tuoi obiettivi e le tue esigenze continuano a evolversi mentre lavori al progetto.

In questo contesto, dovremmo pensare al software come a un essere vivente. Indipendentemente da quanto bene sia stato redatto il piano iniziale, c'è sempre una buona possibilità che dovrà cambiare. Tuttavia, a volte queste modifiche non vengono comunicate a tutti i membri del team. I dirigenti possono avere una conversazione su una nuova funzionalità che ti darà un vantaggio rispetto ai tuoi concorrenti, ma se il manager non lo esprime al resto della squadra, non accadrà.

Se non fosse scritto, potrebbe anche essere dimenticato dal manager e dall'amministratore delegato. Non avere un posto dove hai le ultime novità e i requisiti ufficiali ti farà perdere molto tempo e denaro. I PMT offrono un unico punto di verità, un unico luogo in cui tutti i requisiti e le informazioni vengono archiviati per la durata del progetto. Non si tratta solo di funzionalità che non vengono aggiunte che puoi aggiungere in seguito: ho sviluppato intere funzionalità solo per scoprire che non mi è stato detto che non supportiamo più quella funzionalità.

Memoria ed efficienza nel tempo

L'inchiostro più pallido è più affidabile della memoria più potente. – Proverbio

Possiamo gestire solo così tanto nella nostra testa alla volta. Quando hai una chiamata con i tuoi manager e loro sollevano una dozzina di problemi diversi durante la conversazione, a un certo punto qualcosa andrà perso. Potresti provare a scrivere tu stesso i punti più importanti, ma comunque qualcosa potrebbe cadere nelle crepe.

Avere i requisiti scritti invece di parlarne durante una chiamata è un buon modo per rilevare potenziali elementi mancanti nel flusso o per rilevare elementi che potrebbero impedirti di implementare quel problema in questo momento. Lo sviluppo del software non è lineare, quindi potresti iniziare a lavorare su una funzionalità oggi ma avere qualcosa di più urgente su cui lavorare nel prodotto e tornare un paio di settimane o mesi dopo solo per renderti conto di aver dimenticato esattamente cosa era necessario.

Ecco perché annotare i requisiti può farti risparmiare tempo, non dovendo ricordare o evitando di dover discutere di nuovo la stessa caratteristica. L'efficienza del tempo è molto importante in quanto il software è più complesso, quindi potresti trarre vantaggio dalla semplice scrittura delle cose, per ridurre della metà o più il tempo della riunione, concentrandoti solo sulle questioni che devi chiarire.

Messa a fuoco

Questo è correlato al precedente problema di tenere traccia della comunicazione relativa al problema che viene affrontato e di tenere traccia delle caratteristiche dei requisiti futuri senza che tu debba parlare di queste cose.

Questo aiuta lo sviluppatore sia a mantenere l'attenzione sulla creazione di cose che sono richieste al momento, sia a imparare cosa accadrà dopo. Non si tratta solo di comodità e facile accesso alle informazioni. Il livello di visibilità aggiunto consente a ciascun membro del team di vedere il quadro generale e pianificare in anticipo di conseguenza.

Caratteristiche chiave del PMT

Quindi, quello che stiamo cercando in un PMT è uno strumento che aiuti a gestire la conversazione mantenendo la discussione di diversi problemi separata e ben organizzata. Ciò aiuta la comunicazione tra persone in fusi orari diversi e team diversi mentre allo stesso tempo funge da repository della visione ufficiale del software, aiutandoti a mantenere la concentrazione e risparmiando tempo riducendo l'attrito nel processo di sviluppo per lo sviluppatore, il project manager e tutti coloro che sono coinvolti nell'odierno panorama dello sviluppo software.

Jira

Jira è un PMT molto potente progettato specificamente per lo sviluppo di software. Tuttavia, non tutti conoscono tutte le funzionalità di Jira e può essere travolgente se sei un imprenditore che cerca di gestire il tuo primo progetto. Se stai leggendo questo come una persona che decide tra diverse opzioni ma non hai mai usato Jira prima, ti consiglio di guardare prima alcuni tutorial in modo da poter davvero sfruttare il suo potere.

Sprint

Ci sono tre parole con cui posso definire la maggior parte della mia esperienza con Jira, e una di queste è sprint . Uno sprint è un periodo di tempo in cui la squadra lavora per completare determinati obiettivi che possono essere strettamente correlati o meno. È completamente flessibile. Gli sprint di Jira in genere durano una settimana, che, secondo me, è la durata ottimale.

Dal punto di vista di uno sviluppatore, questo ti dà la flessibilità di avere più cose assegnate a te e lavorare nell'ordine che è più comodo per te, che può essere lavorare su uno difficile e poi su uno facile per rilassarti, o magari lavorare su 2 -3 strettamente correlati allo stesso tempo. Ciò consente agli sviluppatori di prendere alcune decisioni mantenendo allo stesso tempo l'attenzione sulla consegna in tempo.

Epopee e problemi di Jira

Mentre gli sprint raggruppano le attività nel regno temporale, le epiche possono raggruppare le attività per argomento. Ad esempio, puoi dividere le tue attività in sprint a settimana, ma puoi anche raggruppare le attività contemporaneamente nel front-end e nel back-end. Quando dividi le attività per argomento, puoi assegnare uno sviluppatore a un argomento.

Ad esempio, puoi avere un'epopea per la migrazione dei dati da un database esistente, quindi potresti chiamarla migrazione epica di DB e, poiché tutte le attività in quell'epopea sono correlate, un singolo sviluppatore può essere quello responsabile durante tutto il sprint. Ciò evita che due sviluppatori trascorrano del tempo ad apprendere il vecchio database, rendendo lo sviluppo più efficiente.

I problemi , invece, sono le cose che devono essere fatte, che possono appartenere a un'epopea ea uno sprint. Esistono diversi tipi di problemi e quelli sono storia , attività e bug . Una storia ha la particolarità di avere sottocompiti, che possono essere utilizzati per scomporre un problema in parti più piccole che formano un quadro completo se presi insieme: questo evita di creare un gran numero di compiti, concentrandosi invece su un singolo elemento da completare.

Le attività in Jira sono problemi molto specifici e non hanno attività secondarie. Quando qualcosa che deve essere fatto è molto semplice e non ha senso cercare di scomporlo, è un compito. I bug sono cose da correggere: mantenere i bug come una categoria speciale ti aiuterà a capire quanto stai risolvendo rispetto a quanto stai procedendo nel progetto.

Priorità

La comunicazione è una parte importante dell'equazione quando si lavora in un team globale che lavora su più fusi orari. Lavorare "in tutto il mondo" non è una metafora, ma una realtà in cui vivono molti sviluppatori. Una delle cose che è difficile comunicare dai manager agli sviluppatori è il livello di priorità di un'attività. Immagina il seguente scenario usando un elenco di cose da fare:

Lo sviluppatore vede che durante questa settimana hanno sette attività da completare. Alcuni di loro sono difficili e alcuni sono facili. Un compito critico per il manager, tuttavia, è molto complesso, ma per lo sviluppatore in una lista di cose da fare, tutti i compiti sono uguali: potrebbe scegliere di passare prima a quelli più facili, lasciando quello critico per la fine. Se accade qualcosa di inaspettato e l'elenco non viene completato, è l'attività più importante che viene tagliata o viene completata in fretta (probabilmente sacrificando la qualità nel processo). Questo è molto facilmente risolvibile in Jira avendo delle priorità , che consente agli sviluppatori di capire cosa è più importante o critico da completare.

Contenuto, contenuto, contenuto

Una delle cose che apprezzerai davvero di Jira è la quantità di contenuti che puoi inserire in ogni numero; puoi aggiungere immagini o collegamenti e taggare altri membri del team: anche se questo vale anche per Trello, l'interfaccia utente ti invoglia davvero a posizionare più contenuti, il che aiuta ad avere più dati su ogni attività.

I pro ei contro di Jira

Jira è uno strumento molto consolidato con molte funzionalità che sono state incorporate specificamente per lo sviluppo del software. Offre un sacco di integrazioni con altri sistemi e ti aiuta a mantenerti ben organizzato. È particolarmente utile per le squadre (molto) grandi.

Jira, essendo un PMT capace e ricco di funzionalità può essere alquanto scoraggiante per uno sviluppatore alle prime armi. L'esperienza può essere travolgente: sprint, epiche e problemi possono fondersi insieme. Ciò è particolarmente vero se il manager è un cliente con poca esperienza nello sviluppo di software, che cerca di gestire un team di sviluppatori. Consiglio vivamente Jira per grandi team e grandi progetti che richiederanno un po' di tempo per essere sviluppati (più di un paio di mesi), così come per manager (clienti) e sviluppatori esperti.

Professionisti

• Progettato specificamente per lo sviluppo di software
• Consente che ogni problema possa avere molti contenuti, come collegamenti, immagini, allegati
• Ha un'app mobile con notifiche, che ti aiuta a tenere traccia dei tuoi problemi tutto il tempo
• Integra gli sprint con il cuore del prodotto
• Fornisce un filtraggio delle attività molto intuitivo in modo da poterti concentrare sulle attività che sono rilevanti per te

contro

• Ha molte funzioni, quindi puoi facilmente sottoutilizzare il software
• Richiede un po' di formazione per sfruttare tutte le sue funzionalità
• Richiede (o almeno è immensamente aiutato da) una comprensione dello sviluppo Agile
• Può essere eccessivo per un piccolo progetto con un piccolo team

Trello

Trello può essere riassunto in una semplice frase: "tavole con le carte", alias Kanban . A prima vista, potrebbe anche essere troppo semplice per un occhio inesperto; tuttavia, le cose semplici possono essere estremamente utili.

La semplicità è un concetto potente. Questo è parte del motivo per cui iPhone e Mac sono diventati così popolari, poiché il loro sistema operativo era semplice e gioioso da usare. Mentre Jira ha voglia di avere ogni singola cosa a cui riesci a pensare, Trello ha voglia di avere quel tanto che basta per farti passare. Niente epopee, niente storie, niente sprint: lavori semplicemente su una carta e la muovi attraverso le diverse fasi (colonne).

Tenendo presente che tutti questi esistono anche in Jira, spiegherò alcune delle caratteristiche che brillano di più in Trello.

Fasi

Trello semplifica la definizione delle fasi : crea semplicemente una colonna e inizia a usarla. I più comuni sono Da fare, Fare, Rivedere e Fatto. Per la sua semplicità, puoi aggiungere altre colonne come In attesa (anche Jira può farlo, ma sembra che siano perse a meno che non cerchi esplicitamente questi problemi) o creare colonne per diverse parti del sistema come Todo Front-end o Todo Back-end. Questo è eccellente quando il team e il progetto sono piccoli, come un semplice sito Web, un widget o un'estensione, in cui non ci sono molti membri o attività da gestire contemporaneamente.

Membri

Puoi assegnare una carta ai membri ed è così che assegni una carta a uno sviluppatore, molto semplice lì. Puoi anche taggare altri membri nei commenti, il che aiuta tutte le persone coinvolte in un problema a continuare a comunicarlo.

Con un solo clic, gli utenti possono facilmente filtrare le proprie carte o quelle appartenenti ad altri membri del team, il che è particolarmente utile nella visualizzazione Calendario.

Molto visivo

Grazie alla sua semplicità, Trello ha il Kanban visibile ogni volta che apri il contenuto di una carta. È un approccio molto visivo, poiché non puoi sfuggire a questa vista. Inoltre, le carte possono avere immagini visibili sul tabellone.

Questo è qualcosa che Jira non ha (o almeno non l'ho visto utilizzato in un progetto reale). Poiché un'immagine può dire più delle parole, puoi facilmente vedere cosa sta succedendo senza aprire ogni biglietto.

Inoltre, i tag colorati di Trello possono essere utilizzati per aggiungere ancora più informazioni senza dover espandere una scheda. Con un po' di buona organizzazione, questi equivalenti Kanban delle etichette Post-It possono rivelarsi molto utili e risparmiarti un sacco di clic inutili.

Sovraccarico di informazioni

Grazie alla sua intrinseca semplicità, Trello ti spinge a mantenere le cose semplici e al punto, evitando la sensazione di essere sopraffatto da montagne di informazioni. Molte volte lavorerai a un progetto in cui sarai costantemente bombardato da notifiche per oggetti con cui non sei nemmeno coinvolto.

Questo rumore extra sembra essere in qualche modo ridotto su Trello, almeno nella mia esperienza. Poiché Trello non è così intuitivo per l'aggiunta di informazioni, ho scoperto che i problemi tendono ad essere più piccoli, il che significa che le attività sono suddivise in parti più piccole rispetto a Jira. Con un po' di pianificazione, questi piccoli compiti non dovrebbero generare troppo rumore.

Gamificazione

Il concetto di gamification è, in parte, quello di prendere un compito semplice e trasformarlo in un gioco attraverso l'uso di ricompense. "La difficoltà non ti scoraggia se è integrata con ricompense", come sottolineato in questo articolo sul blog Trello.

C'è una carica di adrenalina (o dopamina) ogni volta che un biglietto viene spostato da una fase all'altra. Dal momento che non puoi spostare una carta in una fase diversa senza trascinarla su Trello (mentre su Jira, è più semplice modificare lo stato di un problema), ottieni una connessione fisica con i progressi che stai facendo. Ad un certo momento senza che tu te ne accorga, hai voglia di competere contro te stesso per eliminare più problemi in quel giorno rispetto al giorno prima (spero di non essere solo qui con questa sensazione) o hai solo voglia di combattere per fare la colonna delle cose da fare svuotare il più rapidamente possibile. Molti prodotti software utilizzano oggi la gamification per creare un coinvolgimento maggiore come le visualizzazioni e i Mi piace sulla maggior parte delle piattaforme social: quel meccanismo di ricompensa dell'azione è ciò che mantiene le persone coinvolte nelle piattaforme.

Il buono e il cattivo

Sono ancora stupito di come l'utilizzo di Trello sia gioioso e, certamente, la sua semplicità è fondamentale per questa esperienza. Le attività tendono ad essere più piccole, sebbene tu svolga lo stesso lavoro, è meglio spostare tre attività nella colonna "Per la revisione" piuttosto che cambiare lo stato di una singola storia di Jira in Fatto. (Sento che il tasso di conversione di una storia di Jira è di circa tre carte su Trello.)

Questo è l'ideale per i nuovi sviluppatori o imprenditori che cercano di gestire un progetto perché la barriera all'ingresso è molto bassa. Trello è facilmente padroneggiabile da chiunque, ingegnere del software o altro. Il problema è che Trello potrebbe essere troppo leggero per alcuni progetti e team enormi. Sebbene tu possa facilmente creare schede aggiuntive, avere molti sviluppatori che lavorano su una singola scheda può causare problemi. Non è la stessa cosa, qualitativamente, dello spazio di lavoro condiviso di Jira.

Professionisti

• Bassa barriera d'ingresso: non è necessaria alcuna esperienza
• Interfaccia utente semplice
• Estremamente visivo: ti viene subito l'idea
• Ideale per piccoli progetti e piccoli team

contro

• Non è un'interfaccia utente/UX amichevole per aggiungere molti dettagli a un problema
• Non si traduce altrettanto bene sui dispositivi mobili, poiché hai fisicamente bisogno di più spazio per visualizzare una scheda kanban
• Non ha un modo (almeno, intuitivamente) per dare la priorità alle attività

Dovrei usare uno strumento di gestione dei progetti?

Sì, penso che nella situazione tipica di oggi, in cui il manager o l'imprenditore non è disponibile a rispondere alle domande 24 ore su 24, 7 giorni su 7, dovresti davvero pensare all'utilizzo di uno strumento solo come un modo per avere un repository in cui tutto ciò che serve è annotato in modo chiaro. Questo ti aiuterà a evitare confusione o elementi persi perché sono stati dimenticati in una conversazione Skype o sepolti sotto centinaia di e-mail. Se il tuo progetto è più piccolo, come un sito di hobby, un PMT potrebbe essere eccessivo.

Quale dovrei usare?

La risposta a questa è quella più adatta alle tue esigenze. Se il tuo team è composto da più di quattro persone e il progetto durerà per più di un anno, sceglierei Jira. Se questo è il tuo caso, ti consiglio vivamente di leggere di più su come utilizzare Jira e come utilizzare le metodologie di sviluppo del software.

Se il tuo team ha meno di quattro persone e il progetto è un semplice sito Web, o magari aggiunge alcune funzionalità a un progetto esistente, ti consiglio Trello per la sua semplicità. Come sempre, con gli strumenti, entrambi possono portare a termine il lavoro, ma ciò non significa che il migliore sia uguale per tutti.