Come organizzare il lavoro per un team che fornisce 3 prodotti connessi ma distinti e resta agile

Question

Come organizzare il lavoro per un team che fornisce 3 prodotti connessi ma distinti e resta agile

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

7

Siamo un team responsabile di 3 prodotti:

2 prodotti sono in fase di sviluppo attivo di nuove funzionalità e si stanno muovendo velocemente, quindi il lavoro potrebbe essere classificato come progetto
3 ^rd il prodotto è vivo e vegeto e qui il lavoro coinvolge BAU ¹ e la manutenzione

Uno dei prodotti è nuovo e con grandi promesse per il business, quindi il lavoro sarà sempre in pieno svolgimento. È anche il progetto più attraente per i membri del team.

Il secondo prodotto è in fase di sviluppo, ma il lavoro ha una priorità leggermente inferiore e quindi sarà in grado di fluire e diminuire.

Il lavoro sul BAU del lavoro sul 3 ^rd prodotto sarà per lo più silenzioso con brevi raffiche di attività per risolvere i problemi segnalati e assistere nella distribuzione.

Finora la pianificazione del lavoro era molto ad hoc e vogliamo portare maggiore pianificazione, prevedibilità e un po 'di monitoraggio con tutti i benefici, ma soprattutto, in modo che il team rimanga motivato a causa del valore reale, mentre il business aumenta prevedibilità e qualità.

Quindi la domanda come indicato nel titolo è:
Come gestire un lavoro così diverso e mutevole della natura, ma aggiungere abbastanza processi per mantenere gli obiettivi di maggiore prevedibilità, qualità del software e soddisfazione del lavoro?

Pensiamo di avere le seguenti opzioni:

Due Scrum separati per gestire i due prodotti in fase di sviluppo e una Kanban per estrarre gli articoli BAU per il terzo prodotto. Le persone ruoterebbero tra le 3 per dare a tutti un po 'di fluidità con i ruvidi (nuovi progetti contro il lavoro di BAU). I lati negativi sono le varie combinazioni che influenzano anche la nozione molto approssimativa di capacità e velocità della squadra, stime fluttuanti.
Una Scrum con tutto il lavoro tra i 3 progetti in corso. In questo modo stiamo mantenendo una squadra con la stessa capacità, la stessa capacità mediata di stimare, e la rotazione da liscia a ruvida avverrebbe in base alla storia dell'utente. Non siamo sicuri se ancora in questo modo sia supportato dagli strumenti che usiamo (Jira) ma sembra un'opzione molto migliore per ospitare impostazioni aziendali così complesse.

Penso che siamo più entusiasti dell'opzione 2, ma qualcuno vedrebbe problemi e trucchi ovvi che potremmo aver perso?

Qualunque suggerimento e suggerimento costruttivo molto apprezzato!

NB. Sappiamo quanto sia specifica e unica tale situazione e idealmente lavoreremo tutti su un progetto / prodotto con un backlog ben curato, un'ottima road map e con le aziende in grado di creare un ambiente di consegna ideale, ma queste cose sono fuori dal nostro controllo.

^{1: Business as usual}

agile scrum kanban backlog

posta diginoise 24.07.2017 - 19:16

fonte

3 risposte

Leggi altre domande sui tag agile scrum kanban backlog

Esiste un motivo pratico per non utilizzare un'impostazione ".NET" per archiviare dati che non sono un'impostazione? Struttura dati per determinare l'intersezione tra linea e poligono in 3D

score 2 · Answer 1

Opzione 2 con un proprietario del prodotto dedicato per ciascuno dei progetti. Ogni proprietario del prodotto deve concordare durante lo Sprint Planning che lo sprint acquisirà un numero sufficiente di deliverable per il proprio progetto. Il leverage nei negoziati avverrà in base all'ordine di progetto prioritario concordato per lo sprint.

Bilancia un compito meno interessante con uno più interessante laddove possibile. In alternativa, se i compiti di BAU sono davvero noiosi, assegnare loro crediti con una ricompensa di un pomeriggio libero per chiunque accumuli un numero concordato di tali crediti. A lungo termine il ritorno sarà più che pagare il costo di quei pomeriggi assegnati.

score 1 · Answer 2

L'aggiunta di altri team Scrum è una funzione del numero di posizioni del team di sviluppo che hai, non dei prodotti su cui stai lavorando. Un team di sviluppo non dovrebbe avere più di nove persone, quindi se si hanno 20 membri del team di sviluppo, potrebbe essere opportuno dividere le persone in team Scrum separati. Tuttavia, fare Scrum of Scrum non è banale, e dovresti avere un processo ben definito e le posizioni di supporto necessarie prima ancora di prenderlo in considerazione.

Se hai 9 o meno persone nel tuo team di sviluppo, avere 3 prodotti non è un motivo per rompere la squadra. Il modo in cui tutto funziona è apparentemente semplice. Innanzitutto, tutto va nel backlog. Non importa se è per prodotti separati o no; è tutto lavoro che deve essere fatto dal team. Puoi usare tag, aree, poemi epici, ecc. Per distinguere a quale prodotto appartiene un particolare PBI, ma non ha importanza.

In secondo luogo, a tutto viene assegnato un valore aziendale. In genere, il valore aziendale seguirà lo stesso formato dei punti storia per il tuo sforzo, con una sequenza di Fibonacci modificata (1, 2, 3, 5, 8, 13, 21, 40, 80, 120, ecc.), Ma generalmente aggiungi due zeri alla fine per 1) differenziarlo dallo sforzo e 2) farlo apparire come denaro. È denaro non , ma i tipi di business preferiscono vedere cose come 1300 anziché 13 per qualcosa di simile al valore aziendale. È tutto solo convenzione, però, sei libero di gestirlo come preferisci, proprio come per lo sforzo. Il punto è che hai bisogno di una scala di valore aziendale e devi assegnare PBI a quella scala.

In terzo luogo, si dà la priorità al backlog in base a questo valore aziendale. Più valore aziendale ha un PBI, più intrinsecamente prezioso per l'organizzazione che è, e quindi la priorità più alta che ha per l'organizzazione. Come nota a margine, è per questo motivo che mi piace consigliare ai team Scrum di trattare tutto come un PBI, inclusi bug, debito tecnico, ecc. Un bug non è intrinsecamente più prezioso perché è un bug, ma il grassetto rosso che di solito va insieme a uno stato di "bug" tende a implicare che deve essere risolto subito. Viceversa, c'è una tendenza ad evitare di pagare il debito tecnico, anche se ha un grande valore per l'organizzazione, semplicemente perché è sottinteso che non è così importante come le caratteristiche di parola d'ordine che vanno nelle brochure di marketing. Quando tutto è un PBI e viene assegnato un valore aziendale, allora lavori sempre sulle cose che sono più preziose per il business, indipendentemente dal fatto che si tratti di una funzionalità, un bug, un debito tecnologico e indipendentemente dal fatto che sia per il prodotto A, B, o C.

Il che mi porta a: in quarto luogo, lavorare sugli articoli con il valore più aziendale di ogni sprint. Non importa quale prodotto è per quel punto. Se il tuo prodotto di "manutenzione" ha qualcosa che deve essere fatto con un grande valore per l'azienda, viene davanti e al centro, mentre se il tuo nuovo prodotto appariscente ha qualcosa di un prodotto proposto con poco o nessun valore aziendale, va verso il basso della pila, come dovrebbe, nonostante il fatto che sia per il prodotto su cui tutti vogliono lavorare.

Nel caso in cui non sia completamente ovvio attraverso la ripetizione, eccone un po 'di più: valore aziendale, valore aziendale, valore aziendale. È tutto sul valore aziendale. Se stai lavorando su cose che non portano valore all'organizzazione stai perdendo tempo. Periodo. In qualsiasi momento, durante uno sprint, dovresti sempre lavorare sul PBI che ha il maggior valore per l'organizzazione, indipendentemente dal tipo di cosa o dal prodotto di cui fa parte.

Quindi, quando si tratta dei tuoi sviluppatori che vogliono lavorare su funzionalità "sexy" e non vogliono eseguire lavori di manutenzione da grugniti, beh, benvenuti nel mondo dello sviluppo del software. Questo descrive ogni sviluppatore di sempre. Sfortunatamente, c'è sempre lavoro da fare e qualcuno deve farlo. Il meglio che puoi fare è provare a ruotarlo, quindi forse se lo sviluppatore A ha lavorato a un prodotto di manutenzione PBI all'ultimo sprint, lo sviluppatore B dovrà fare uno di questi sprint, mentre lo sviluppatore A subirà una crepa come un prodotto appariscente PBI. Diffondi il dolore, per così dire.

score 0 · Answer 3

È una situazione comune e penso che molte aziende lo gestiscano con:

3: Crea un team dedicato per progetto + uno per BAU

Che è ottimo per la gestione ma non così buono per gli sviluppatori bloccati su BAU

Il problema che dovrai affrontare con 1 è che i membri del team in rotazione rallentano le cose e le persone diventano pigre nei compiti difficili se sanno che stanno per ruotare.

Il problema che dovrai affrontare con 2 è che entrambi i progressi sui progetti sono limitati dal volume del lavoro BAU e dal bug prioritario del giorno. INOLTRE tenderai a dividere naturalmente in team con persone che scelgono attività correlate all'area che conoscono.

La mia soluzione è FINISH project, ovvero interrompere il lavoro BAU e passare alla prossima cosa.

È molto difficile per un'azienda fare questo perché ci sono sempre clienti esistenti, interni ed esterni, che vogliono nuove funzionalità.

Ma da un punto di vista tecnico a un certo punto stai trasformando quel pezzo originale di software in una gigantesca palla di fango. dovrebbe essere un investimento migliore rendendo una v2 o qualcosa di nuovo.