In un team agile, chi è responsabile della realizzazione di decisioni di alto livello sull'architettura e sulla progettazione che riguardano l'intero sistema, non solo il lavoro svolto nello sprint corrente?
Forse il proprietario del prodotto, il mischia, il team di mischia o qualcun altro?
"The software architecture is performed by the entire team. This practice does not remove the need for a software architect, it just means that the architect contributes to the discussion with a broader and probably more experienced perspective, nevertheless all members of the team contribute towards the architecture of the software."
Architetti, ovviamente, ma forse non i tipi tradizionali di architetti.
Non intendo il tipo di architetto-chirurgo che fa tutto il pensiero e poi lascia le scimmie per fare tutta la digitazione. Intendo un programmatore capo esperto che comprende i compromessi in termini di costi / benefici di decisioni difficili da respingere 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. Una persona del genere deve
Quest'ultimo punto fa salire un sacco di persone. Quando gli agilisti ben intenzionati dicono cose come "La squadra possiede l'architettura", hanno quella "giusta", 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 porteresti la domanda in primo luogo, ora lo faresti ?! Quindi presumo che tu poni la domanda perché ci sono alcuni preoccupare che
Se hai bisogno che qualcuno si assuma la responsabilità, consegnalo a chiunque desideri accettarlo. Sul serio. Almeno quella persona se ne frega. Fornisci a quella persona le risorse di cui hanno bisogno per svolgere il lavoro e aiutali quando ne hanno bisogno. Probabilmente non importa quanto sia competente la persona, perché se gli interessa, allora proveranno a imparare ciò che hanno bisogno di imparare. Naturalmente, una tale persona ha bisogno di supporto sotto forma di buoni libri leggere e una comunità di colleghi e mentori che possono chiedere aiuto e consigli
Se ti preoccupi che la persona sbagliata abbia a che fare con la responsabilità, allora spero tu sappia chi è "la persona giusta" e combatterà per installarli come architetto. Un libro come The New Strategic Selling ti aiuterà ad apprendere le tecniche di vendita per farlo accadere.
Se hai solo bisogno di un capro espiatorio, allora manda leggermente a tacere gli altri per dare la responsabilità alla carriera di chiunque tu voglia distruggere o danneggiare. Almeno sii onesto.
Tornando al lavoro di un architetto efficace, possono pensare al loro lavoro come a una posizione dirigenziale, piuttosto che semplicemente una posizione decisionale. Se non delegano almeno le decisioni più abituali ai team, allora diventeranno un collo di bottiglia e rallenteranno l'intera organizzazione . Aggiungere più architetti nella parte superiore non lo rende più veloce. Coltivare meglio le decisioni di architettura da zero. La tecnica della scheda di delega aiuterà il tuo architetto a sentirsi più a suo agio nel tempo a delegare sempre più decisioni ai team man mano che i team guadagnano fiducia mostrando competenza.
Penso a un grande architetto come a qualcuno che mi aiuta a capire come progettare meglio i miei sistemi, chi mi consiglierà pazientemente quando lo chiederò e chi a volte mi impedirà di prendere una decisione molto povera. Un tale architetto si comporta come un leader nel vero senso della parola: qualcuno che altri seguono volontariamente .
So che è stato molto.
Miller, The New Strategic Selling . Questo libro include un modello per capire perché non sei riuscito a chiudere una vendita specifica. Trovo questo inestimabile capire perché i colleghi non faranno la cosa ovviamente meravigliosa che sto suggerendo.
Weinberg, Diventare un leader tecnico . Questo libro mi ha aiutato a imparare come fare la parte non-architetto del lavoro dell'architetto efficace.
Appelo, Schede di delega e delega poker . Non sottovalutare quanto sia difficile la delega e quanto ne facciamo. Impara fallo più efficacemente e in modo più constrongvole.
The best architectures, requirements, and designs emerge from self-organizing teams
Quindi il team si auto-organizza per prendere decisioni architettoniche nel modo che ritiene opportuno. Non c'è una regola dura e veloce, può andare dal consenso a un "consiglio" dei membri più anziani, alla designazione di un particolare membro come autorità di architettura, a lasciare che l'architetto scelga se c'è un membro con un titolo di lavoro simile. .
Sento che la risposta a "" chi è responsabile della realizzazione di architetture di alto livello e decisioni di progettazione? "dipende dalla dimensione e dal numero di team.
Per uno o due team con 3-7 per ciascuna squadra, il team autoorganizzato può fare con il piombo 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 sottogruppi stanno facendo del lavoro che si interfaccia con gli altri team. Nella mia esperienza quel punto è raggiunto quando ci sono circa 8 squadre o a circa 50 persone.
Ci sono alcune grandi risorse del team Scaled Agile Framework (SAFe) sul loro sito.
In sostanza, ti aiuta a scalare agilmente tutta la tua organizzazione, andando al di sopra di una singola release e nella pianificazione del portfolio e del programma. La loro documentazione mostra suggerimenti su come coinvolgere il tuo Enterprise e System Architects nel processo per introdurre le epopee architettoniche nel treno di rilascio.
Modifica per chiarezza per indirizzare la domanda più direttamente:
In un ambiente agile scalato esistono più livelli di proprietà sull'architettura. Il team di implementazione agile sarà proprietario dell'architettura emergente di basso livello effettuando il refactoring in base alle necessità per continuare a implementare i propri backlog. Decisioni architetturali di livello superiore (sistemi operativi supportati, browser, piattaforme, librerie) sono sotto la responsabilità del tuo sistema e degli architetti aziendali. Faranno i casi aziendali per quando questi cambiamenti devono verificarsi e raccomandano di aggiungere queste modifiche architettoniche al treno di rilascio per i team di implementazione.
Quindi, per quanto riguarda le decisioni sull'architettura di alto livello che vanno oltre lo sprint, di solito queste sono realizzate a un livello superiore al team. Questi professionisti hanno tradizionalmente un ruolo di "architetto" all'interno dell'azienda.
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 realizza piani di alto livello per e con l'azienda per creare e sostituire l'ambiente IT. L'Enterprise Architect avrà definito i principi architettonici e li ha fatti firmare ai più alti livelli dell'organizzazione e contribuirà a creare l'architettura di alto livello e i requisiti per ogni progetto. Ogni progetto è avviato per fornire un elemento architettonico in quell'architettura di alto livello.
Quindi, a livello di progetto, Solution Architect creerà l'architettura del progetto (possibilmente iterativamente) e otterrà il consenso da Enterprise Architect.
Ora, concentrarsi su un progetto agile. Un progetto agile ha dei requisiti. Non hanno la forma di un massiccio "Requirements Document", ma sono epici e storie. Questi Epics richiedono ancora una pianificazione. Non mandi un gruppo di sviluppatori su pochi sprint verso l'ignoto. Conoscete ad alto livello ciò che il sistema deve fare, quali altri sistemi ha bisogno di interagire e quali vincoli hardware / sistema operativo / lingua l'organizzazione ha e questo guida e vincola le scelte architettoniche aperte a Solution Architect. Ad esempio, se ti impegni con .NET e SQL Server, dovresti creare un caso irresistibile estremamente per implementare un sito di e-commerce basato su Magento usando PHP e MySQL a causa dei costi coinvolti supportare 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 questo potrebbe avere implicazioni per tutti gli altri progetti in volo. È essenziale avere la supervisione di un Enterprise Architect per impedire che questo tipo di "debito architettonico" si verifichi.
Dipende dal design organizzativo dell'organizzazione e se il prodotto è in un portfolio. Organizzazioni più grandi e orientate al ruolo possono nominare architetti senior per guidare questo tipo di attività.
Generalmente un architetto anziano faciliterà e guiderà le decisioni di progettazione in quanto non solo influenzano un portafoglio di prodotti, ma potrebbero riguardare diversi prodotti in un portafoglio di prodotti.
Le aziende più piccole e agili possono affidarsi a sviluppatori esperti di sistemi per guidare il team di sviluppo ad allinearsi sulla progettazione architettonica.
In definitiva, le decisioni di architettura devono essere concordate dal team di consegna che lavora sul prodotto. Architetti esperti e lead tecnologici saranno più focalizzati nel facilitare la discussione su come dovrebbe essere il design, piuttosto che dettare il design.
Penso che la maggior parte delle risposte evidenzi già che il team non una singola persona dovrebbe prendere queste decisioni.
Ciò che non toccano è un altro principio Agile:
Simplicity--the art of maximizing the amount of work not done--is essential.
Pensando a architetture e ampli di alto livello; le decisioni di progettazione spesso non vengono prese con semplicità, il che potrebbe portare a sprecare un sacco di sforzi e aggiungere complessità non necessarie che potrebbero rendere le cose più difficili da estendere.
Think ‘gardening’ over ‘architecting’—Create a culture of living, growing design
Durante la tua attuale iterazione dovresti fare architettura e amp; decisioni di progettazione per le vostre esigenze attuali. Invece di guardare avanti a un futuro che potrebbe non diventare mai, concentrati solo su ciò di cui hai bisogno ora. Probabilmente YAGNI ora è un'architettura ben congegnata, lascia che sia il team a gestirlo un po 'alla volta.
Altre letture: