Quando i team componenti sono una scelta migliore rispetto ai feature team nello sviluppo agile?

Question

Quando i team componenti sono una scelta migliore rispetto ai feature team nello sviluppo agile?

#1 da (6 voti)
#2 da (1 voti)

5

Quando si tratta di una struttura organizzativa in un contesto agile, molte persone sostengono che i team di caratteristiche sono in genere una scelta migliore rispetto ai team di componenti. Questo almeno è quello che trovo quando discuto con i colleghi, sia nella mia attuale che nella mia precedente posizione. Inoltre, Larman e Vodde discutono con veemenza contro i team di componenti (Practices for Scaling Lean & Agile Development) e hanno portato questa posizione anche nello Scrum Primer ( link ).

Esistono tuttavia fonti che indicano che la scelta tra team di componenti e componenti non è una decisione "tutto o niente" e che ci sono criteri che possono rendere una scelta saggia (almeno un paio di componenti). Ad esempio, in link gli autori indicano che un alto grado di riutilizzabilità e un alto grado di specializzazione tecnologica sono criteri che rendono favorevoli i team di componenti per quella rispettiva parte del sistema. Anche Mike Cohn e Ken Rubin nei loro libri hanno una visione più equilibrata.

Nel mio ambiente professionale (fornitori automobilistici) ci sono tradizionalmente molti team di componenti. Quando si passa a un modo di lavorare agile, molti colleghi pensano che, stando con una struttura di componenti, la direzione farebbe qualcosa di fondamentalmente sbagliato. Non lo vedo in questo modo per diversi motivi:

In primo luogo, ciò che un fornitore automobilistico offre come prodotto è, dal punto di vista del veicolo, solo un componente. Le caratteristiche effettive del cliente sono a livello del veicolo. Quindi, di conseguenza e idealmente, i team di feature dovrebbero lavorare su un veicolo trasversale (attraverso i confini di fornitore e OEM). Questo, tuttavia, non è mai nemmeno discusso come un possibile modo di lavorare.
Ci sono lotti di componenti in uso, come sistemi operativi (Linux, QNX, AutoSar, ...), librerie standard, librerie di terze parti (navigazione, riconoscimento vocale), librerie open source , ... E, per la maggior parte di queste librerie, nessuno ha l'esperienza per migliorare comunque gli interni della biblioteca. Per dirla in modo un po 'sarcastico: avere altri team che sviluppano componenti da usare è a portata di mano, ma lo sviluppo di componenti nella propria organizzazione agile è una cattiva scelta?
E, certamente, ci sono molte aree in cui persone e team hanno sviluppato una profonda esperienza su anni e, dove questa competenza è veramente essenziale per evitare costosi ritorni sul campo. Sviluppare una strategia di aggiornamento del software che funzioni in tutte le circostanze sul campo con power-drop che si verificano in momenti arbitrari è qualcosa che solo pochi possono fare. Quindi c'è un alto rischio se tutti in un progetto più grande possono apportare modifiche a tale albero dei sorgenti. Allo stesso modo, le funzionalità di sicurezza sono ovunque, ma solo pochi comprendono i dettagli, anche i protocolli di comunicazione specifici del veicolo ecc.

Ora la mia domanda: quali altri criteri (ad eccezione del grado di riutilizzo e delle competenze tecniche) vedete che potrebbe rendere i team di componenti in determinati scenari di sviluppo software favorevoli mentre si lavora in un contesto agile?

agile organization

posta Dirk Herrmann 12.12.2018 - 00:51

fonte

2 risposte

Leggi altre domande sui tag agile organization

readonly vs. proprietà private getter-only in C # 6 MVVM Commands - un comando per tutto o più comandi?

score 6 · Answer 1

Un punto chiave del funzionamento di "Agile" indica che il team produce deliverable in piccoli cicli (detti "Sprint" in Scrum speech). Quindi, IMHO, l'unica cosa che conta davvero in questo contesto è: i componenti di un sistema più grande possono avere principalmente cicli di rilascio indipendenti , quindi possono essere sviluppati in singoli Sprint?

Se la risposta è sì, non c'è IMHO alcun motivo che vieta di lavorare "Agile" nei team di componenti. Ogni componente deve essere un "prodotto consegnabile a sé stante", con interfacce chiaramente definite, il proprio controllo delle versioni, i propri test, la propria documentazione e una pianificazione Sprint che non intralci lo sviluppo di componenti diversi insieme.

Hai già fornito alcuni esempi in cui funziona correttamente: componenti come il sistema operativo o altre librerie specializzate di terze parti: lo sviluppo di componenti che dipendono dal primo è pianificato in aggiunta alle funzioni già disponibili all'inizio di ogni sprint (ad esempio, del sistema Linux o del sistema di riconoscimento vocale o altro). Quindi, se il tuo team sviluppa il nuovo centro multimediale utilizzando un sistema di riconoscimento vocale su V123.4, non è importante per la pianificazione dello sprint quando sarà disponibile la "nuova versione 4.0 del componente di riconoscimento vocale con una percentuale di rilevamento maggiore" no, o se Linux V123.5 sarà disponibile o meno - il tuo team può lavorare ai tuoi prossimi dieci sprint del centro multimediale con o senza quella nuova versione.

Per darti un contro esempio: un'applicazione web a più livelli in cui lo sviluppo di ogni nuova funzione richiede sempre modifiche al "frontend" e al "backend" in parallelo. Quando non puoi pianificare Sprint per il frontend team indipendentemente dal team di back-end, lavorare in sprint produrrà attriti tra i team, perché uno di loro dovrà sempre aspettare l'altro. Quindi questo tipo di sviluppo funzionerà probabilmente meglio con un team interfunzionale, perché se le attività di frontend sono fatte prima della fine dello sprint pianificato (o viceversa), gli sviluppatori disponibili che hanno lavorato sul frontend possono aiutare a finire il back-end attività per lo sprint (o viceversa).

score 1 · Answer 2

Se necessario, puoi essere agile all'interno di ogni team di componenti esistente. E vedi dove va. Imporre agilità al livello più alto di un'organizzazione di produzione multidisciplinata perfezionata, tuttavia, sarà dirompente, distruttivo, porterà al caos e porterà l'operazione a una battuta d'arresto.

Agile uccide la proprietà

Questo non è necessariamente negativo in tutte le situazioni, potrebbe essere il modo di affrontare un singolo punto di errore. La domanda da porre dovrebbe sempre essere: possiamo permetterci di farlo e possiamo permetterci di farlo bruscamente?

Ci saranno conseguenze non solo immediate sulla qualità ma anche socialmente. Come pensi che a John piacerà il fatto che la componente su cui ha lavorato per anni, che si sente responsabile, di cui è orgoglioso, che è il suo bambino, sarà improvvisamente là fuori per tutti con cui fare casino e pipì? Come affronterà il messaggio "Be ', John, potresti sentire che hai lavorato sodo e accumulare esperienza, ma ciao, abbiamo notizie per te: non ci crediamo, pensiamo che chiunque possa fare il tuo lavoro! sedetevi sul sedile posteriore e osservate come i vostri colleghi, che siete andati molto d'accordo finora, stanno per rovinare tutto ciò che avete fatto. " È probabile che John abbia dei problemi di lealtà.

Essere mandati dappertutto per estinguere piccoli incendi in parti che non conoscono è poco gratificante, le persone più capaci alla fine se ne andranno. E questo è ciò che l'agile / scrum spesso si deteriora quando viene implementato con noncuranza: nessuno possiede niente e quindi nessuno si sente responsabile di nulla, si prende cura di qualsiasi cosa o si fa bene con qualsiasi cosa.

Agile / scrum è grandioso se non provi alcun processo. Se hai un sistema con una cronologia che ha funzionato, dovresti fare molta attenzione a non perdere più di quanto guadagni.