Come modellare la preparazione della storia per le questioni che vengono affrontate in diversi progetti

Question

Come modellare la preparazione della storia per le questioni che vengono affrontate in diversi progetti

#1 da (2 voti)
#2 da (0 voti)
#3 da (-2 voti)

9

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

Affrontiamo il problema di evitare la duplicazione del codice tra i progetti e abbiamo sviluppato una serie di librerie principali che utilizziamo in quei 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 il codice di base che stanno usando ha un bug, necessita di più parametrizzazione o nuova funzionalità ... lo chiami.

Quindi creano un problema di libreria principale che entra nel backlog del core project. Tutti questi aspetti vengono esaminati, classificati in ordine di priorità e stimati in una riunione della biblioteca centrale (una volta alla settimana) e verranno affrontati in base alla loro priorità (insieme a questioni specifiche del progetto) in alcuni sprint futuri.

L'assegnazione delle priorità viene effettuata ordinando i problemi e inserendo un'etichetta sorted sui problemi ordinati (in modo che possiamo cercare quelli non ordinati). Quindi abbiamo inserito manualmente un numero per componente principale nella parte superiore del backlog per poterli affrontare per primi. Quando alcuni team mettono un tale problema nello sprint, devono invece trascinare manualmente un altro oggetto nella parte superiore del backlog.

Questo è abbastanza incline agli errori. Fondamentalmente, quello che abbiamo sono gli stati dei problemi aggiuntivi "ordinati" e "stimati" tra "aperto" e "in corso". Riflettendo su questo attraverso l'etichetta sorted e la loro posizione nel board è piuttosto macchinosa e soggetta a errori. (Ad esempio, se qualcuno sposta un problema in uno sprint su e giù, questo si rifletterà nella scheda madre, mescolando 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?

project-management agile user-story requirements-management jira

posta sbi 24.11.2016 - 15:01

fonte

3 risposte

Leggi altre domande sui tag project-management agile user-story requirements-management jira

Alcuni programmatori conoscono alcuni segreti che noi non facciamo? [chiuso] Migrazione di un'applicazione Grails su Scala Play / Spray

score 2 · Answer 1

Se vuoi tracciare questo in JIRA, lo seguirò come se fosse un nuovo compito.

Quindi ad esempio:

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

Una volta deciso quale team prenderà l'incarico, potranno quindi creare una nuova attività: SUPPORT-123: Foo the Bar in Core .

Puoi quindi bloccare CORE-75 con SUPPORT-123 . Una volta completato SUPPORT-123 , puoi tornare a CORE-75 . Puoi avere le recensioni unite o rivedere il codice due volte (una volta dal team designato, una volta da un team più specifico di nucleo).

Questo è esattamente ciò che stai facendo in ogni caso: considera la libreria di base come il suo prodotto / cliente, non andare a metà strada.

score 0 · Answer 2

Un approccio prevede che il team crei un nuovo problema per lo sprint che rimandi al problema della libreria principale. È come se stessimo facendo un sub-task per un'attività, ma attraverso le schede / backlog.

Un altro approccio è solo per tracciarlo separatamente al di fuori di JIRA. Esporta il backlog esistente come CSV o foglio di lavoro e organizzalo.

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

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

score -2 · Answer 3

C'è una visione che le Core Libraries che racchiudono molte delle funzionalità comuni, ma non correlate, sono una 'cosa cattiva' (tm)

Ci sono alcuni motivi per questo

Inseriscono dipendenze e codice di cui non hai bisogno
La loro modifica causa modifiche a tutte le applicazioni
Nessun singolo "proprietario"

Nel tuo caso, ritengo che la divisione dei compiti da parte dell'applicazione in cui verrà apportato il cambiamento sia la radice del problema. Una specie di legge di Conway inversa.

Penso che la soluzione migliore per te sia quella di allontanarti dal fatto che le Librerie delle "Core Libraries" dovrebbero avere una specifica (piccola) serie di funzionalità raggruppate logicamente. Dovrebbe essere possibile completarli. cioè JsonParser, LogWriter ecc. dovrebbe essere raro avere senso aggiungere una nuova funzionalità.

Tuttavia, supponendo che questo sarebbe un compito lungo e difficile, come soluzione secondaria vorrei semplicemente mantenere le attività della libreria di base con il team che ha bisogno della funzionalità. vale a dire.

Attività: aggiungi la caratteristica X al prodotto Y

Dev: hmm parte del codice per la feature X dovrebbe andare in un corelibrary .. Lo inserirò come parte di questa attività