Qual è la differenza / relazione tra i progetti GitHub e le pietre miliari?

Il recente aggiornamento di GitHub ha aggiunto qualcosa chiamato Progetti nel flusso di lavoro di GitHub, e poiché non ho alcuna esperienza particolare con strumenti di tracciamento del progetto come Jira o Trello (ehi, almeno ho notato la somiglianza) , qualcuno potrebbe, per favore, elaborare sulle differenze (chiave) tra le pietre miliari di GitHub e i nuovi progetti ?

Se ho capito bene, le pietre miliari sono un modo di organizzare i problemi in "sottoprogetti" più piccoli, più piccoli dell'intero "progetto" (che, secondo la mia visione del mondo, è rappresentato dal repository ). Quando tutti i problemi sono terminati / chiusi, il traguardo può essere considerato completo .

I nuovi progetti introdotti sono anche, a mio avviso, un modo di organizzare le questioni in "sotto-progetti" più piccoli del repository (anche se chiamati progetti ). Capisco che il flusso di lavoro dovrebbe essere leggermente diverso e più dettagliato rispetto alle "semplici" pietre miliari .

Quindi, i progetti sono qualcosa che integra le pietre miliari (o meglio le pietre miliari integrano i progetti ora?) O dovrei piuttosto vedere i progetti come una sostituzione delle pietre miliari ?

Dove rientrano esattamente i progetti nella repository[-milestone]-issuegerarchia?

Purtroppo, il blog di GitHub sull'introduzione dei progetti non menziona alcuna relazione ( https://github.com/blog/2256-a-whole-new-github-universe-announcing-new-tools-forums-and- caratteristiche ).

In qualche modo sento che ce n'è uno, ma non ci riesco.

Mi chiedo esattamente la stessa cosa. Ecco cosa mi è venuto in mente.

Innanzitutto, esaminiamo le principali somiglianze e differenze:

• Un problema può appartenere a più progetti, ma solo una pietra miliare.
• I progetti non sono mai completi . Non c'è barra di avanzamento o scadenza. I progetti non hanno barra di avanzamento o scadenza, ma ora possono essere chiusi (come sottolineato da @Sheen)
• Le pietre miliari d'altra parte hanno tutto ciò, ma mancano di qualsiasi forma di organizzazione. Un problema è in una pietra miliare o non lo è. (Possono essere ordinati come indicato da @Nick McCurdy)
• I problemi possono essere filtrati per Milestone, ma non per Progetto. Come sottolineato da @cmonkey, i problemi ora possono essere filtrati per Progetto e per Milestone.
• I progetti possono contenere note (che possono essere convertite in problemi) in modo da non inquinare il tracker dei problemi con idee vaghe
• Un progetto può estendersi su più pietre miliari e una pietra miliare può contenere parti di progetti diversi.
• Un'organizzazione può avere anche progetti. Questi progetti possono includere biglietti da qualsiasi archivio nell'organizzazione, il che lo rende abbastanza utile.

Quindi, per come la vedo io, è che i progetti sono un modo completamente separato di visualizzare e organizzare il tuo lavoro a un livello superiore (pensa a "gestione del progetto", più team, repository multipli, ecc.), Mentre le pietre miliari sono un modo per organizzare il tuo scadenze e rilasci a un livello più elementare (si pensi a "gestione delle versioni", "versioni", ecc.). Con questo in mente, ha senso che un problema appartenga a una sola pietra miliare (viene rilasciato o portato in produzione una sola volta) ma può far parte di diversi progetti.

Sono sicuro che ci sono altri modi per vederlo, e sono interessato a sentire altre opinioni.

Modifica dicembre 2017

Qualche tempo fa, dopo aver lavorato con pietre miliari e progetti per oltre un anno, mi sono reso conto che c'era un altro aspetto importante che avevo completamente ignorato.

• Le pietre miliari sono uno strumento per la metodologia Scrum . Le pietre miliari sono utili per le iterazioni in timebox e per gli sprint con serie di problemi.
• Projects è uno strumento per la metodologia Kanban . I progetti sono validi per consegne continue e flusso di lavoro costante.

La mia opinione:

• Un progetto riguarda un processo e le persone .
• Una pietra miliare riguarda un prodotto .

Un progetto è la soluzione migliore per ottenere informazioni dettagliate su un processo utilizzato dalle persone del gruppo. Un nome migliore sarebbe "flusso di lavoro" o "processo". C'è più sovraccarico nella creazione di un nuovo progetto rispetto alla creazione di un nuovo traguardo. Quindi vuoi davvero creare un nuovo progetto solo quando c'è un nuovo processo nel tuo team: le corsie devono essere scelte, configurate e ordinate. Possono anche essere molto diversi in ciascun progetto. Ripenso all'uso originale di Kanban da parte di Toyota: gestire le persone e il loro carico di lavoro.

Un progetto risponde alla domanda "A cosa stiamo lavorando in questo momento?"

Due grandi esempi di progetti: sviluppo di software e blog. Le configurazioni per ciascuno supporterebbero i processi di persone dei diversi gruppi; come lavorano insieme e firmano le cose.

Le pietre miliari, al contrario, funzionano tutte allo stesso modo. Sono un elenco ordinato di attività che devono essere chiuse affinché il prodotto di lavoro sia considerato completo. Facoltativamente, è possibile impostare una data di scadenza, che fornisce solo promemoria, ma non modifica il funzionamento di Milestone.

Una pietra miliare risponde alla domanda "Cosa resta per finire questo prodotto?"

Una cosa bella dei progetti è che sono più in forma libera delle pietre miliari. Puoi semplicemente inserire note in esse e collegarle a problemi e organizzarle come preferisci. Sono ottimi per annotare idee, creare roadmap e elencare risorse e dipendenze. In passato ho usato i problemi e il wiki per le stesse cose, ma ho scoperto che entrambi erano troppo formali e transazionali (cioè un overhead più elevato).

Le pietre miliari sono tipi di etichette che contrassegnano e raggruppano i biglietti che dovrebbero essere consegnati in un determinato momento. La Milestonespagina a cui puoi accedere dalla Issuespagina lo rende chiaro: puoi vedere la percentuale di biglietti completati per un determinato traguardo e la data di scadenza. È inoltre possibile ordinare i traguardi per data di scadenza e dare la priorità ai biglietti all'interno di un determinato traguardo.

Lo stress qui è sulle date di consegna e sul monitoraggio dei progressi.

I progetti d'altra parte sono implementati in GitHub come schede Kanban con alcune campane e fischietti. È possibile specificare un numero di colonne ( e swimlanes - come ha detto @Doug seguito swimlanes non sono ancora supportati) per creare flussi di lavoro semplici. È quindi possibile aggiungere ticket da uno o più repository, assegnarli in ordine di priorità e quindi farli avanzare da una colonna all'altra mentre vengono elaborati. Ad esempio, potresti avere colonne "Backlog", "In corso", "In corso di revisione", "In prova" e "Fine" e spostare i biglietti da sinistra a destra o da destra a sinistra se, per esempio, un difetto il ticket viene rimbalzato da "In Testing" a "Backlog".

Lo stress qui è sull'organizzazione e la gestione del lavoro.

Quindi come organizzare e partizionare quel lavoro dipende da te. È possibile creare un progetto per traguardo o avere più traguardi in un singolo progetto o suddividere i traguardi in sprint più brevi . Potresti anche avere diversi progetti che coprono diversi aspetti del lavoro sul prodotto, ad esempio uno per gli sviluppatori e uno per i tester.