Come modellare la preparazione della storia per i problemi che vengono affrontati in diversi progetti

9

Nella nostra azienda diversi team lavoreranno contemporaneamente su diversi componenti di più progetti. Ad esempio, un team potrebbe creare tipi specifici di software (o hardware) per alcuni progetti, un altro team un altro tipo specifico di software. Utilizziamo i progetti Jira per ospitare problemi relativi a progetti specifici e schede Jira per gli sprint per diversi team.

Ci troviamo ad affrontare il problema di evitare la duplicazione del codice tra progetti e abbiamo sviluppato una serie di librerie di base che utilizziamo in tali progetti. Mentre si lavora su un progetto, alcuni sviluppatori si renderanno conto che un pezzo di codice che hanno scritto è di maggiore interesse e dovrebbe essere estratto in una libreria di base, o che un codice di base che stanno usando ha un bug, ha bisogno di un po 'più di parametrizzazione o un nuova funzionalità ... lo chiami.

Quindi creano un problema di libreria di base che rientra nel backlog del progetto principale. Tutti questi problemi vengono esaminati, ordinati per priorità e stimati in una riunione della biblioteca principale (una volta alla settimana) e verranno affrontati in base alla loro priorità (insieme a questioni specifiche del progetto) in alcuni sprint futuri.

La definizione delle priorità viene eseguita in base ai problemi di ordinamento e inseriamo sortedun'etichetta per i problemi ordinati (in modo da poter cercare quelli non ordinati). Quindi inseriamo manualmente un problema per componente principale nella parte superiore del backlog in modo che possano essere affrontati per primi. Quando una squadra mette un tale problema nel proprio sprint, devono invece trascinare manualmente un altro elemento in cima al backlog.

Questo è abbastanza soggetto a errori. Fondamentalmente, ciò che abbiamo sono gli stati dei problemi aggiuntivi "ordinati" e "stimati" tra "aperto" e "in corso". Riflettere questo attraverso l' sortedetichetta e la loro posizione nel tabellone è piuttosto ingombrante e soggetto a errori. (Ad esempio, se qualcuno sposta un problema in uno sprint su e giù, questo si rifletterà nella scheda madre, rimescolando silenziosamente l'ordine dei problemi che il team avrebbe potuto decidere in una lunga discussione settimane prima.)

Quindi quale sarebbe un modo migliore per implementarlo?

— SBI
fonte

2

Sembra troppo sovraccarico diplomatico solo per aggiungere una funzione a una lib. Nella nostra azienda di 50 sviluppatori (software medico) consentiamo ancora agli sviluppatori di inviare il codice a ciascuna delle nostre librerie interne se ritengono che sia appropriato. Viene rivisto in seguito ovviamente. Potresti forse considerare di lavorare con un flusso pullrequest ma una riunione? No. Non funzionerà mai.

— Teimpz,

@Teimpz: Naturalmente, tutti invieranno alle librerie interne e, ovviamente, ogni codice verrà rivisto. Tuttavia, l'ordine in cui vengono affrontate le questioni fondamentali (che non sono necessarie per alcuni progetti in corso) è deciso da tutti i team. Funziona abbastanza bene, solo Jira non sembra supportarlo bene.

— sabato

L'overhead sembra piuttosto un po ', ma dato che il core è così ampiamente usato, sarei disposto ad accettare un po' di overhead per assicurarmi che nulla vada storto. Un incontro sembra molto però. Lo vedrei come qualsiasi altro compito, ma una comunicazione extra - recensioni, conversazioni - sarebbe importante.

— Erdrik Ironrose,

2

Se vuoi rintracciarlo in JIRA, lo seguirei come se fosse un nuovo compito.

Quindi per esempio:

Diciamo che hai la storia CORE-75: Foo the Bar .

Una volta deciso quale squadra prenderà il compito, possono quindi creare un nuovo compito: SUPPORT-123: Foo the Bar in Core .

È quindi possibile bloccare CORE-75 con SUPPORT-123 . Una volta terminato SUPPORT-123 , è possibile tornare a CORE-75 . È possibile unire le revisioni oppure rivedere il codice due volte (una volta dal team designato, una volta da un team più specifico del core).

Questo è davvero ciò che stai facendo: considera la libreria principale come il suo prodotto / cliente, non andare a metà strada.

— Erdrik Ironrose
fonte

Sembra ingombrante, ma, sì, funzionerebbe. Quindi +1da parte mia.

— sabato

0

Un approccio prevede che il team crei un nuovo problema per il proprio sprint che ricolleghi al problema della libreria principale. È un po 'come se stai facendo un'attività secondaria per un'attività, ma tra i board / backlog.

Un altro approccio è solo quello di rintracciarlo separatamente al di fuori di JIRA. Esporta il backlog esistente come CSV o foglio di calcolo e organizzalo.

Separando i problemi da JIRA, hai la flessibilità di definire la priorità nella riunione di pianificazione e non devi preoccuparti dell'algoritmo di ordinamento di JIRA nei consigli di amministrazione e non dovrai nemmeno usare le etichette.

Nella riunione di pianificazione delle priorità per la libreria principale è possibile creare un elenco di attività da completare per la libreria principale e chiunque sia responsabile / responsabile della libreria principale può assicurarsi che tali attività vengano avviate dai diversi team di progetto e completate.

— Vecchio account
fonte

-2

C'è una visione secondo cui le librerie di base che incapsulano molte funzionalità comuni, ma non correlate sono una "cosa negativa" (tm)

Ci sono alcuni motivi per questo

Richiedono dipendenze e codice che non ti servono
La loro modifica provoca modifiche a tutte le applicazioni
Nessun singolo "proprietario"

Nel tuo caso, penso che la divisione dei compiti da parte dell'applicazione a cui verrebbe apportata la modifica sia la radice del problema. Una specie di legge inversa di Conway.

Penso che la soluzione migliore per te sarebbe quella di allontanarti dall'avere le librerie 'Core Libraries' dovrebbero avere un set specifico (piccolo) di funzionalità raggruppate logicamente. Dovrebbe essere possibile completarli. cioè JsonParser, LogWriter ecc. dovrebbe raramente avere senso aggiungere una nuova funzione.

Tuttavia, supponendo che questo sarebbe un compito lungo e difficile, come soluzione secondaria manterrei semplicemente le attività della biblioteca principale con il team che ha bisogno della funzionalità. vale a dire.

Attività: aggiungere la funzione X al prodotto Y

Dev: hmm parte del codice per la funzione X dovrebbe andare in un corelibrary .. Lo inserirò come parte di questo compito

— Ewan
fonte

Sembra strano. Per i principianti: quale pensi sia la differenza tra ciò che chiamate "librerie con un piccolo insieme specifico di funzionalità raggruppate logicamente" e quelle che chiamiamo "librerie di base"? (A proposito: sembra che mi sia sfuggita la notifica per questa risposta. Ci scusiamo per la risposta così tardi.)

— sbi

Penso che questa sia la citazione distintiva per me: "un pezzo di codice che hanno scritto è di maggiore interesse e dovrebbe essere estratto in una libreria di base". Se i tuoi progetti condivisi sono "librerie" complete di funzionalità, non devi mai aggiungere una funzionalità ad esse.

— Ewan,

Non riesco a capire la tua argomentazione. Perché un codice non dovrebbe beneficiare della manutenzione? E i tuoi clienti non richiedono mai nuove funzionalità, portando alla scrittura di nuovo codice? E come fai a sapere che il codice è di interesse comune, oltre a ricevere un altro progetto con un requisito già interessato?

— sbi,

Supponiamo che la tua libreria sia Json.Net. ha uno scopo serializzare oggetti su json e reverse. sicuramente potresti aver bisogno di correggere un bug o aggiungere il supporto per generici ma il set di funzionalità generali non cambia mai. Non sei mai nella posizione in cui, ad esempio, un cliente ti chiede di implementare "la possibilità di annullare gli ordini" o qualsiasi altra cosa e pensi: "Lo aggiungerò a Json.Net"

— Ewan