Jira

Marco

Jira core

Per la codifiche delle issue (attività) con un numero identificativo;
Organizzazione dei team;
Backlog di prodotto;
Dashboard, cioè la pagina principale con dei widget che ci possono dare delle informazioni riguardanti il versionamento del prodotto;
Report, dello sprint;
Filtri, selezioni, ricerche di quello che sono le issue;
TimeTracking, elemento in cui si riesce a fare la dichiarazione del tempo e l'analisi del tempo per capire come sta svolgendo il lavoro del team.

Issue

Presenta un numero con prefisso (es. GW), si ha quindi un numero per progetto! Dato un numero riesco anche a risalire al progetto
Tipi di issue:

--> Task: aggiornamento cliente, interfacciamento, formazione etc.. Sfogo che consente di pianificare. Tutte le cose che sono, quindi, extra sviluppo.

--> Story: sviluppo associato ad una analisi (insieme di sviluppo), vengono associate ad un'epica (3-5 Giorni)

--> Bug: defect da risolvere

--> QA-QC: attività di test, formali sulla singola funzionalità o di integrazione

--> Analisys: Analsi di qualsiasi cosa.

--> Master-epic: raggruppamento di Epic, serve al P.O. per tenere traccia di tutte le epiche per fare in modo che il P.O. riesca a raggruppare i temi come vuole. (solamente per il P.O)

--> Epic: suddivisione massima che riesce a fare un P.O. Sono degli elementi di raggruppamento. Consente al P.O. e allo scrum master di vedere l'avanzamento dei lavori. E' in sostanza un raggruppamento di issue. Le analisi vengono associate alle epiche. (solamente per il P.O)

Possibile assegnare una priorità;
Una issue può coinvolgere più versioni!
Label --> Mettere qualsiasi cosa, un tag (mi propone anche quelle vecchie);
Area --> Possiamo definirle noi
Story Point --> Complessità dell'attività!
Sprint --> Una volta pianificata lui se lo ricorda.
Epic --> Epica collegata
Descrizione:
Stato:
Resolution:
Attachment --> Posso mettere dentro qualsiasi files
IssueLink --> In che pagine di confluence è stata menzionata
Attività --> commenti, Worklog (tracciature di tempo), History (tutti i cambiamenti), attività (messa in bella dell'history).
Continuous integration build:
Assegnee--> A chi è in carico
Voti --> serve per capire meglio la priorità!
Watcher --> Notifiche do ogni cambiamento
Create Branch --> Creato il branch deve essere associata l'issue
Move --> Cambiare di progetto oppure di tipologia
Stato: ogni issue di storia, analisi o bug ha un workflow associato quindi in ogni momento si può mettere uno stato.
Tempo stimato per eseguirlo

Dashboard di sviluppo

Configurabile secondo le esigenze;
Inserire tutti i widget utili
Dovrebbero riusicre a dare uno stato della situazione del mio lavoro;
E' possibile anche condividerle (ma solamente contattando l'amministratore, in questo caso Luigi);
Ognuno può farsi la sua, ma se ognuno ha una dashboard differente allora significa che non si sta lavorando insieme

Board

Elemento dove tutti i pezzi fino ad ora illustrati cominciano a legarsi.

Visualizzare tutte le issue che ci sono;
Backlog
Gestione degli Sprint, sia quelli attivi che quelli futuri
E' possibile spostare issue con semplice drag and drop
Dichiarazione del time-spent

BitBucket

Repository delle source;
Stretto controllo del codice per capire meglio quali sono le versioni interessate del codice. SISTEMA DI VERSIONAMENTO VERO E PROPRIO;
Basato su Git;
Sviluppo isolato, ogni programmatore avrà il proprio stream e solo quando sono realmente testate e funzionanti viene fatta una push request sullo stream principal-e.

Confluence

Documentazione quale analisi, manuali, meeting, verbali, sprint review.
Creare tutta la documentazione scritta su template di tutto ciò che è associato a AGILE;
Collegato a Jira Core --> Ogni issue può essere collegata ad una pagina, si possono mettere il link di una o più issue e automaticamente ti espone lo stato di quel documento e di quello sviluppo;

Inserimento dei filtri di Jira, per creare della documentazione su quell'elenco di issue

Portfolio

Strettamente legato a Jira Core, consente di fare un Gantt delle attività gestendo il team anche con le assenze e individuare il carico di lavoro per persona.
Una serie di Utility che ti consentono di vedere se la pianificazione eseguita sia corretta o meno anche attraverso delle simulazioni che permettono di capire se si sta facendo correttamente.
Non è trattato in questo corso in quanto prima è necessaria una base degli altri punti che sono assai importanti.

Informazioni Generali

Esposta solamente internamente all'azienda per riservatezza e sicurezza;
Solamente online NON è associato a nessun editor di sviluppo;
Viene utilizzato da qualsiasi persona tranne i sistemisti;
Identificato la Suite solamente per i centro sviluppo!
Solamente la documentazione è disponibile ai sistemisti
Abbiamo due ambienti di Jira --> Un ambiente di test ed uno di formazione

Per me

SourceTree per la gestione di stream etc

GIT

Versionamento

Sitema in grado di mantenere:

Reversibilità
Concorrenza
Annotazione

Nello specifico utilizzeremo Git. E' un sistema di versionamento distribuito, cioè ogni repository locale è una copia di quello remoto e il server centrale sere come appoggio per la condivisione e permette di lavorare in maniera indipendente anche in attesa di connettività.

Un repository è una cartella che viene gestita come un piccolo database nel nostro computer.

E' utile vederlo come una linea temporarie in cui possiamo fare delle fotografie istantanee (commit) su delle funzionalità stabili.

Stato dei files

Untracked --> File non gestito
Staged --> Inserito iin una cartella monitorata da git
Unmodified --> Non modificato ma già dentro la cartella
Modified --> File modificato

Branch

E' un ramo aperto sulla linea temporale (identifficato come hash) che permette di separare il flusso di sviluppo. Conosce tutto quello che è successo prima ma nulla di quello che è successo dopo negli altri branch.

Il master potrebbe non sapere che sono stati creati altri branch e la loro storia. Fino a quando si continua a lavorare su quel branch senza intaccare le modifiche degli altri.

Operazioni di base

Branching: Non fa altro che attaccare una etichetta al branch master. Viene creata una nuova linea di sviluppo.
Questo lo faremo perchè vengono fatte delle commit riconoscibile da hashcode univoco. E' una azione locale. Non è possibile fare il commit sul master. Ogni commit ha una descrizione.
Chechout: Spostarsi tra un branch e un altro, non fa modifiche di alcun genere ma solamente ti chiede di salvare le operazioni.
Clone: permette di portare in locale un repository remoto, crea il proprio repository locale permette di portare a casa lo stato complessivo del repository. Creata questa cosa è possibile anche lavorare isolati. Tutta la copia di brach e quantaltro.
Fetch: rendere consapevoli lo stato del repository remoto al nostro locale. Nel mio ambiente non è cambiato nulla. Aggiorna i metadati del repository non modifica il tuo branch, si allinea solamente sui "metadati" associati.
Pull: permette di recuperare delle modifiche di un altro branch di cui ho necessità e importarle nel mio repository locale. (Eseguire sempre dopo un ferch); L'operazione di pull porta tutte le modifiche e me le porto dentro da me. Può causare dei conflitti.
Push: remotizza la mia storia locale (del branch in cui sto lavorando), è una che porta nel repository remoto tutte le modifiche che ho fatto (sul branch in cui sto lavorando). Nel primo momento prende il mio branch e lo porta nel repository. Poi riporterà tutte le modifiche fatte. (NON NEL MASTER)
Merge: operazione locale, permette di riunirvi alla storia del master e genera un nuovo commit da mettere nel master nella copia locale. Per rendere consapevole il repository remoto dovrei fare una push;
Squash: permette di accorpare tra loro più commit, alterandone la descrizione. E' sempre una operazione locale. Il risultato è una commit che contiene le modifiche di quelle precedenti. (Da questa non si hanno più i commit precedenti. Si sta alterando la storia e git te lo segnala. E' proprio una riscrittura della storia del branch! Se proprio voglio distruggere la storia faccio un push forzato! (Ottima idea prima di mergiarlo con il master). Puoi anche farlo tra due nodi vicini precedenti.
Rebase: Voglio fare credere al master che mi sono staccato oggi e non in precedenza. Serve in modo da avere le ultime modifiche fatte, ma ovviamente può portare a molti conflitti. (Ti viene in aiuto in qualche situazioni). Mantiene la storia pulita, a differenza del push che crea un commit con le modifiche fatte per risolvere i conflitti). E' utile qualora si voglia portare solamente una serie stretta di commit e non tutti.

Bitbucket

Server remoto di git. Pull request, scrivere del buon codice prima di portare nello stream master. Permettono di lavorare in maniera più controllata.

Dalla issue si crea il branch e si lavora per ogni issue nel branch di sviluppo. Se si deve salvare per noi stessi si fa un commit, oppure se mi serve condividere quello che ho scritto oppure per sicurezza con un commit e un push lo metto nel server. Quando ho finito di fare tutto faccio un push sul server remoto e faccio una pull request, solo chi di competenza può accettarlo o meno. Solo nel momento che tutti approvano allora solamente in quel momento si jira fai merge.