In un ambiente agile, responsabile dell'architettura software


19

In un team agile, chi è responsabile di prendere decisioni di alto livello in architettura e design che interessano l'intero sistema, non solo il lavoro svolto nello sprint attuale?

Forse il proprietario del prodotto, lo scrum master, lo scrum team o qualcun altro?

inserisci qui la descrizione dell'immagine


10
Questo ... non ha senso ...
Telastyn,

3
La presenza di arretrati di Product e Sprint non influisce su chi è responsabile dell'architettura software. Una domanda migliore potrebbe essere: in un ambiente agile, chi è responsabile dell'architettura software?
Caricatore IIC

Ho provato ad aggiornare la domanda in modo che almeno possa essere compresa. Non sono sicuro al 100% se ho capito bene ...
FrustratedWithFormsDesigner

Risposte:


24

"L'architettura del software è eseguita da tutto il team. Questa pratica non elimina la necessità di un architetto del software, significa solo che l'architetto contribuisce alla discussione con una prospettiva più ampia e probabilmente più esperta, tuttavia tutti i membri del team contribuiscono a l'architettura del software ".


5
Pure Agile tende a rifiutare ruoli top-down tradizionali come "project manager" e "architetto di sistema", preferendo invece riformattare quei ruoli e distribuire le loro responsabilità tradizionali in tutto il team.
Jonathan Eunice,

6
@JonathanEunice: come può essere praticamente fattibile? Non tutti gli sviluppatori sono anche un buon architetto.
Giorgio,

2
@JonathanEunice: Quindi la domanda posta a DWD ha senso dopo tutto. Non capisco tutti i voti negativi.
Giorgio,

3
@DaveHillier: Forse questi progetti sono grandi ma l'architettura è abbastanza semplice: gli sviluppatori devono solo compilare i pezzi in uno schema piuttosto semplice e ripetitivo (ad esempio scrivere centinaia di moduli simili in un'applicazione basata su web con un modello di dominio esistente) . D'altra parte, so che non appena un'applicazione diventa sufficientemente complessa, hai bisogno di qualcuno che si occupi dell'architettura (spesso in anticipo), altrimenti finirai con un enorme casino.
Giorgio,

6
"Big Upfront Design" è il tipico argomento agile per trarre la conclusione che non dovrebbe esserci affatto un design iniziale: un approccio è portato all'estremo, l'estremo provato è sbagliato e l'estremo opposto è proposto come soluzione. Concordo sul fatto che un grande progetto iniziale è raramente un buon approccio, ma alcune decisioni architettoniche fondamentali devono essere prese in anticipo per evitare enormi refactoring o la completa riscrittura in seguito. Questa non è un'attività che può essere improvvisata "quando si ha la sensazione che il codice stia diventando troppo disordinato e necessiti di un refactoring". L'esperienza aiuta a trovare un buon equilibrio.
Giorgio,

19

Architetti, ovviamente, ma forse non i tipi tradizionali di architetti.

Non intendo il tipo di architetto chirurgo capo che fa tutto il pensiero e poi lascia le scimmie a fare tutte le battiture. Intendo un programmatore capo esperto che comprende i compromessi costi / benefici delle decisioni difficili da invertire e che consiglia i team su cosa fare.

Gli architetti efficaci sono difficili da trovare, ma può essere una posizione fantastica, e quindi probabilmente hai almeno un programmatore esperto e premuroso che potrebbe farlo bene. Tale persona ha bisogno di

  • Prendi delle buone decisioni sull'architettura, ovviamente, ma anche
  • Sapere come dare consigli in modo efficace, così che gli altri si sentano a proprio agio nel prenderli e anche
  • Delegare lentamente le decisioni sull'architettura ai team

Quest'ultimo punto fa inciampare molte persone. Quando gli agilisti ben intenzionati affermano cose come "Il team possiede l'architettura", hanno quel "diritto", ma trovo il consiglio quasi completamente privo di significato nella sua applicazione. Se ti fidi che i team si assumano la responsabilità della propria architettura, allora non faresti la domanda in primo luogo, ora lo faresti ?! Presumo quindi che tu faccia la domanda perché c'è qualche preoccupazione o quello

  • Nessuno si assumerà la responsabilità e avremo un'architettura scadente, o
  • Le persone sbagliate si prenderanno la responsabilità e avremo un'architettura scadente, o
  • Chiunque si prenda la responsabilità diventerà un capro espiatorio e speri di evitarlo

Se hai bisogno di qualcuno che si assuma la responsabilità, affidalo a chiunque voglia accettarlo. Sul serio. Quella persona almeno se ne frega. Dai a quella persona le risorse di cui ha bisogno per fare il lavoro e aiutalo quando ne ha bisogno. Probabilmente non importa quanto sia competente la persona, perché se si preoccupano, allora cercheranno di imparare cosa devono imparare. Naturalmente, una persona del genere ha bisogno di sostegno sotto forma di buoni libri da leggere e di una comunità di colleghi e tutor ai quali possono chiedere aiuto e consigli.

Se temi che la persona sbagliata si occupi della responsabilità, spero che tu sappia chi è "la persona giusta" e combatterò per installarli come architetto. Un libro come The New Strategic Selling ti aiuterà a imparare le tecniche di vendita per realizzarlo.

Se hai solo bisogno di un capro espiatorio, spingi tranquillamente gli altri a dare la responsabilità alla carriera di chiunque desideri distruggere o compromettere. Almeno sii onesto.

Tornando al lavoro di un architetto efficace, possono pensare al loro lavoro come una posizione di gestione, piuttosto che semplicemente come una posizione decisionale. Se non delegano almeno le decisioni più ordinarie ai team, diventeranno un collo di bottiglia e rallenteranno l'intera organizzazione . L'aggiunta di più architetti in alto non lo rende più veloce. Coltivare le migliori decisioni sull'architettura da zero. La tecnica del consiglio di delegazione aiuterà il tuo architetto a sentirsi più a suo agio nel tempo delegando sempre più decisioni ai team mentre quei team guadagnano fiducia mostrando competenza.

Penso a un grande architetto come a qualcuno che mi aiuta a capire come progettare meglio i miei sistemi, che mi consiglierà pazientemente quando lo chiederò e che occasionalmente mi impedirà di prendere una decisione molto sbagliata. Un tale architetto si comporta come un leader nel vero senso della parola: qualcuno che altri seguono volontariamente .

So che è stato molto.

Riferimenti

Miller, la nuova vendita strategica . Questo libro include un modello per capire perché non sei riuscito a chiudere una vendita specifica. Lo trovo prezioso per capire perché i colleghi non faranno la cosa ovviamente meravigliosa che sto suggerendo.

Weinberg, diventando un leader tecnico . Questo libro mi ha aiutato a imparare a fare la parte non architetto del lavoro dell'architetto effettivo.

Appelo, Delegation Boards e Delegation Poker . Non sottovalutare quanto è dura la delega e quanto facciamo schifo. Impara a farlo in modo più efficace e più comodo.


1
La tua chiave "h" è pericolosa? ;)
Dave Hillier,

3
No, Dave. Ho usato pronomi Spivak (di genere neutro).
JB Rainsberger,

A causa delle domande come pone @DaveHillier, tendo a usare "lui / lui" ... (Grazie per l'ottima risposta, a proposito, riporta la realtà nel "il team è / fa / ha / possiede ..." cliché)
Marjan Venema

1
@ jdl134679 Controllo della versione in soccorso: softwareengineering.stackexchange.com/posts/260541/revisions
JB Rainsberger

1
@Walfrat Dopo ulteriori riflessioni, ho deciso di chiarire ulteriormente questo punto. Una persona che si preoccupa proverà ad imparare ciò che deve imparare, ma probabilmente ha bisogno di supporto, come un mentore.
JB Rainsberger,

10

Le migliori architetture , requisiti e progetti emergono da team auto-organizzati

- Manifesto Agile

Quindi il team si auto-organizza per prendere decisioni sull'architettura in qualunque modo lo ritenga opportuno. Non esiste una regola rigida e veloce, che può variare dal consenso a un "consiglio" dei membri più anziani, alla designazione di un membro in particolare come autorità dell'architettura, a consentire all'architetto di scegliere se esiste un membro con tale titolo professionale. .


9
Mi piace Agile, ma questa è una grande debolezza: l'architettura viene spesso trascurata o messa insieme.
user949300,

1
@ user949300 "Agile" come nel manifesto dice molto poco sull'architettura. Su quali metodi esatti stai prendendo questa conclusione? XP ti incoraggerebbe a riformattare senza pietà. Sei a favore della BUFD?
Dave Hillier,

"XP ti incoraggerebbe a refactoring senza pietà": fino a quando non dedichi più tempo al refactoring che alla scrittura di nuovo codice. Penso che la soluzione migliore sia quella di trovare un equilibrio tra le decisioni architettoniche fondamentali che prendi in anticipo dopo un'attenta analisi e le decisioni di progettazione più piccole che prendi in considerazione lungo il refactoring.
Giorgio,

@ user949300 questo perché il team non si auto-organizza, se lo fossero sarebbero in frequente comunicazione con il resto del team ogni volta che una decisione sull'architettura deve essere presa e documentare / discutere / discutere adeguatamente quelle idee.
Rudolf Olah,

3

Sento che la risposta a "" chi è responsabile di prendere decisioni di alto livello in architettura e design? "Dipende dalle dimensioni e dal numero di team.

Per una o due squadre con 3-7 su ogni squadra, la squadra auto-organizzata può fare con il vantaggio dei membri senior.

Per 3 o più team la maggiore complessità porta alla necessità di un team di architettura in grado di vedere se i vari sotto-team stanno facendo un lavoro che si interfaccia con gli altri team. Nella mia esperienza questo punto viene raggiunto quando ci sono circa 8 squadre o circa 50 persone.


1

Ci sono alcune grandi risorse del team Scaled Agile Framework (SAFe) sul loro sito.

In sostanza, ti aiuta a scalare agilmente in tutta la tua organizzazione, andando oltre una singola versione e nella pianificazione di portfolio e programmi. La loro documentazione mostra suggerimenti su come coinvolgere la tua Enterprise e System Architects nel processo per introdurre epopee architettoniche nel treno di rilascio.

Modifica per maggiore chiarezza per rispondere alla domanda in modo più diretto:

In un ambiente agile scalato ci sono più livelli di proprietà sull'architettura. Il team di implementazione agile sarà proprietario dell'architettura emergente di basso livello effettuando il refactoring, se necessario, per continuare l'implementazione dei propri arretrati. Le decisioni di architettura di livello superiore (sistemi operativi supportati, browser, piattaforme, librerie) sono sotto la responsabilità del sistema e degli architetti aziendali. Faranno i casi aziendali per quando è necessario che si verifichino questi cambiamenti e raccomanderanno che questi cambiamenti architetturali vengano aggiunti al treno di rilascio per i team di implementazione.

Quindi, per quanto riguarda le decisioni di architettura di alto livello che vanno oltre lo sprint, di solito queste verranno prese a un livello superiore al team. Questi professionisti hanno già tradizionalmente un ruolo di "architetto" all'interno dell'impresa.


2
come risponde a questa domanda "chi è responsabile di prendere decisioni di alto livello in architettura e design"?
moscerino del

1
Grazie moscerino, ho provato a modificarlo per rendere più chiaro quale fosse la mia intenzione di rispondere alla domanda. Ho fatto qualche balzo in testa, ma ho dimenticato di scriverli :)
Jay S

1

Penso che la maggior parte delle altre risposte stiano pensando a questo dal punto di vista di essere all'interno di un progetto.

Se questo è l'unico livello di architettura in un'organizzazione, il risultato sarà francamente il caos. Ho assistito in prima persona a questo caos, purtroppo succede.

Secondo TOGAF, il dipartimento di architettura aziendale pianifica di alto livello per e con l'azienda per creare e sostituire l'ambiente IT. Enterprise Architect avrà definito i principi dell'architettura e li avrà firmati ai massimi livelli dell'organizzazione e contribuirà a creare l'architettura e i requisiti di alto livello per ciascun progetto. Ogni progetto viene avviato per fornire un blocco architettonico in quell'architettura di alto livello.

Quindi, a livello di progetto, Solution Architect creerà l'architettura del progetto (possibilmente in modo iterativo) e riceverà l'approvazione da Enterprise Architect.

Ora, concentrarsi su un progetto agile. Un progetto agile ha dei requisiti. Non hanno la forma di un enorme "Documento sui requisiti", ma sono invece epiche e storie. Queste epiche richiedono ancora pianificazione. Non invii un team di sviluppatori a fare qualche sprint verso l'ignoto. Sai ad alto livello cosa deve fare il sistema, con quali altri sistemi ha bisogno per interagire e quali vincoli hardware / Sistema Operativo / Lingua ha l'organizzazione e questo guida e limita le scelte architetturali aperte a Solution Architect. Ad esempio, se ti impegni su .NET e SQL Server, dovresti fare un estremamentecaso convincente di implementare un sito di e-commerce basato su Magento usando PHP e MySQL a causa dei costi associati al supporto di due DB, due lingue, due server web ecc. In alternativa, un progetto potrebbe scegliere di utilizzare una libreria completamente diversa o un aspetto diverso e sentire e questo potrebbe avere implicazioni per tutti gli altri progetti in volo. È essenziale avere la supervisione di un Enterprise Architect per evitare che questo tipo di "debito architettonico" si verifichi.


0

Dipende dal design organizzativo dell'organizzazione e se il prodotto è in un portfolio. Le organizzazioni più grandi e orientate al ruolo possono nominare architetti senior per condurre questo tipo di attività.

Generalmente un architetto senior faciliterà e guiderà le decisioni di progettazione in quanto non influiscono solo sul portafoglio ordini di un prodotto, ma possono influenzare diversi prodotti in un portafoglio di prodotti.

Le aziende più piccole e agili possono fare affidamento su sviluppatori esperti di sistema per guidare il team di sviluppo ad allinearsi alla progettazione architettonica.

In definitiva, le decisioni sull'architettura devono essere concordate dal team di consegna che lavora sul prodotto. Architetti esperti e responsabili della tecnologia saranno più concentrati nel facilitare la discussione su come dovrebbe essere il design, piuttosto che dettare il design.


0

Penso che la maggior parte delle risposte evidenzi già che il team non una sola persona dovrebbe prendere queste decisioni.

Quello che non toccano è un altro principio Agile:

La semplicità - l'arte di massimizzare la quantità di lavoro non svolto - è essenziale.

Pensare alle architetture di alto livello e alle decisioni di progettazione spesso non viene preso in considerazione con semplicità, probabilmente portando a sprecare molto sforzo e aggiungere complessità inutili che potrebbero rendere le cose più difficili da estendere.

Pensa al "giardinaggio" piuttosto che all'architettura "Crea una cultura di vita, design in crescita

Durante la tua attuale iterazione dovresti prendere decisioni di architettura e design per le tue attuali esigenze. Invece di guardare avanti verso un futuro che potrebbe non diventare mai, concentrati solo su ciò di cui hai bisogno ora. Probabilmente YAGNI è un'architettura ben pensata ora, lascia che il team la gestisca a poco a poco.

Altre letture:

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.