Ci sono delle buone pratiche per quanto riguarda il passaggio dall'architettura allo sviluppo?

Inizierò affermando che il concetto stesso di un team "Architecture" separato è un affronto alle buone pratiche di sviluppo del software. I team di architettura negli ambienti aziendali tendono a rappresentare il culmine dei peggiori artisti pseudo-intellettuali di toro * * che si possono trovare tra il pool di sviluppatori.

Altre organizzazioni considerano i gruppi di architettura come una ricompensa politica e la giustificazione di un massiccio stipendio per i membri più anziani, indipendentemente dal merito, dalla conoscenza o dall'abilità. La maggior parte consiste di entrambi i tipi.

Ogni sviluppatore può e dovrebbe essere un architetto e dovrebbe essere coinvolto nei progetti di alto livello di un'azienda. Il solo pensiero che un singolo gruppo abbia un controllo dittatoriale completo su ogni aspetto della progettazione del software e che debba essere distribuito agli sviluppatori che non hanno contribuito alla progettazione, non capisce il ragionamento dietro le scelte progettuali e può comprendere difetti critici poiché il design è più comodo e più vicino all'attuale implementazione e al codice esistente, è francamente completamente imperfetto dal suo stesso nucleo e genererà coerentemente uno dei tre scenari:

• Gli sviluppatori non comprendono il design, o addirittura lo rifiutano a causa della realtà dell'attuale implementazione e finiscono per determinare il proprio design non documentato e implementarlo. La situazione è costituita da documenti di progettazione formale che non riflettono l'implementazione del software.

• Gli sviluppatori seguono ciecamente il progetto che può o non può tenere in considerazione i requisiti attuali o gli aspetti unici delle storie degli utenti, risultando in un'implementazione di qualità scadente e buggy.

• Gli sviluppatori intelligenti che comprendono i documenti di progettazione e sono in grado di implementarli, si annoiano rapidamente non essendo coinvolti nelle discussioni sul design. Probabilmente sono esclusi dalla partecipazione al gruppo Architecture a causa di problemi politici o di anzianità, quindi diventano frustrati, annoiati e partono per pascoli più verdi. Ciò influisce negativamente sul progetto, causando una fuga di cervelli che fa continuare il circolo vizioso della scarsa qualità del software.

Il modo migliore per mitigare questo problema è CAMBIARE il gruppo Architecture e possibilmente metterlo in posizioni di leadership tecnologiche. Il ruolo del gruppo Architecture dovrebbe essere più o meno una "mischia di lead tecnologici", se lo vorrai. Dovrebbero incontrarsi solo di rado e discutere solo i problemi di direzione tecnica di più alto livello, ad es. Pensa a una discussione che migra da Java a Scala, Abbandona Oracle per MySQL, possibilmente scrivendo librerie di utilità comuni che impongono un determinato TIPO del processo di progettazione rispetto a un altro, passando da StarUML a Altova UML.

Il design del software reale e reale sarà un processo comunitario che coinvolge TUTTI gli sviluppatori di software, definito dalla direzione di altissimo livello del gruppo Architecture.

Ci sono sempre stati problemi nel modo in cui le informazioni vengono trasferite dall'architettura ai test di sviluppo e alle operazioni. Il modo di affrontare questi problemi dipende da diversi fattori come:

• dimensione del software
• complessità
• cultura nella tua organizzazione
• convinzione.

Per alcune combinazioni di questi fattori è appropriato un approccio puramente agile a squadre interfunzionali con design emergente. Le informazioni fluiscono lavorando insieme. Le discipline documentano ciò di cui hanno bisogno.

Per altre combinazioni di questi fattori una piccola squadra di architetti, tester, esperti delle operazioni e sviluppatori di piombo potrebbe iniziare con iterazioni di architettura che lentamente costruiscono l'architettura, documentano e ottengono un feedback immediato sulle loro decisioni di architettura. Lentamente altri sviluppatori che implementano funzionalità possono essere aggiunti al team e il core team originale può essere ridotto.

Soprattutto per progetti governativi e finanziari è necessario che più documentazione sia scritta in anticipo e che possa richiedere molto tempo senza alcun riscontro da parte del mondo reale sulle tue scelte. Nella mia mente il motivo principale per cui molti di questi progetti falliscono. Comunque, se questa è la tua situazione, farei la documentazione per soddisfare i requisiti E poi usare l'opzione 1 o 2 per costruire effettivamente il software e perfezionare / adattare la documentazione.

Spero che questo aiuti.

So che non sarà molto popolare ma il commento che hai fatto

At the other end of the scale if everything is specified, the specification takes longer than the development. And you risk having very boring development tasks.

è in realtà qualcosa per cui dovresti lottare. Se il progetto e le specifiche sono abbastanza solidi che i compiti di sviluppo sono noiosi, il costo dello sviluppo diminuisce. È molto meno costoso riparare una specifica piuttosto che correggere il codice, e il costo maggiore dei progetti software non è la build, è il supporto a lungo termine. E il codice di supporto basato su una specifica solida è molto meno costoso.

Non sono completamente d'accordo con la risposta di maple_shaft, ma non c'era abbastanza spazio nel commento per dire tutto il mio bit! ; -)

Sono d'accordo sul fatto che ogni sviluppatore può e dovrebbe essere un architetto, ma ciò non significa che ogni sviluppatore debba essere responsabile dell'architettura di un intero prodotto o sistema. Inoltre, non penso che tu possa dipingere ogni team di architetti con lo stesso ampio pennello e, una volta fatto, i team di architetti possono dare un grande valore al processo di sviluppo del prodotto. L'idea sbagliata è che gli architetti debbano dettare ogni aspetto della progettazione del sistema. Dovrebbero invece concentrarsi sul design di livello superiore e lasciare i dettagli di implementazione ai propri team di sviluppo. Ciò non significa tuttavia che gli sviluppatori non dovrebbero essere coinvolti nel processo di pianificazione e progettazione sin dall'inizio.

Il più grande e più modulare e in definitiva un prodotto più complesso è, più è probabile che troverai varie parti del prodotto gestite da diversi team di sviluppo. Tali team non hanno bisogno di comprendere il sistema nel suo complesso, a condizione che abbiano una piena comprensione delle parti del sistema di cui sono responsabili. Spesso questi team aggiuntivi vengono portati come subappaltatori allo scopo specifico di sviluppare un modulo in una particolare area della tecnologia a cui gli architetti o altri team potrebbero non avere esperienza. I miei talenti particolari si trovano nello sviluppo di API e non ho ancora visto una API ben costruita che è stata sviluppata interamente in modo organico senza essere un disastro completo in termini di usabilità, o che non ha richiesto a qualcuno di emergere come la persona che ha assicurato che c'era un livello di uniformità tra i diversi aspetti dell'API. Posso elencare molti esempi e ragioni, ma non penso che questo tipo di situazioni siano la torre d'avorio che molti potrebbero pensare di essere. Sfortunatamente, ci sono molti posti, in particolare nei settori della difesa, della medicina e dei settori finanziari in cui la paranoia aziendale si traduce in uno sviluppo di prodotti poco specificati e ancora più mal gestiti del genere di cui sono sicuro che Maple_shaft fosse maggiormente preoccupato. Queste sono le cose che credo possano dare agli architetti un brutto nome meramente meritato (in generale).

Quindi dov'è la via di mezzo che l'OP stava cercando? La risposta è tutto a che fare con l'apertura dei canali di comunicazione. Gli architetti devono consegnare le specifiche che descrivono i loro progetti in modo sufficientemente dettagliato in modo da garantire che i team di sviluppo capiscano dove sono i confini. Storie e Scenari di funzionalità nel senso più ampio, in cui tutto è considerato una scatola nera. Gli architetti devono quindi assicurarsi che i team abbiano accesso ai tempi dell'architetto per confermare eventuali ipotesi e avere risposte a domande su specifiche che sembrano troppo ampie o poco chiare. Dopodiché, si tratta davvero di garantire che i singoli team siano consapevoli di ciò su cui stanno lavorando gli altri team e che sappiano con chi contattare gli altri team per garantire che ciascuna parte del sistema giochi bene con le altre parti. Questi team si incontrano direttamente. Una volta che il sistema è stato progettato al livello più ampio, gli architetti dovrebbero essere solo le persone a cui si rivolgono le squadre quando hanno bisogno di un controllo di integrità, e per garantire che la "visione" del prodotto sia mantenuta. Dovrebbero anche prendere in considerazione qualsiasi processo di integrazione richiesto e fornire la necessaria "copertura aerea" per i team di sviluppo da parte dei manager, dei clienti e di qualsiasi altro stakeholder, pur garantendo che queste varie persone possano riunirsi per lavorare tra loro come dovrebbero funzionare le cose.

Gli architetti IMHO dovrebbero prima di tutto essere facilitatori & comunicatori e designer in secondo luogo. Per quanto riguarda il livello di specifica? Penso che i migliori architetti siano quelli che chiedono ai loro team il livello di dettaglio che una squadra vuole, e tra loro trova un equilibrio che funzioni. Diversi team possono avere requisiti diversi in termini di quantità di documentazione o di direzione richiesta. Le squadre senior possono trovare un diagramma approssimativamente disegnato e una chat veloce può essere sufficiente per andare avanti, mentre i team pieni di sviluppatori relativamente giovani potrebbero aver bisogno di un po 'di più per farli andare avanti. Soprattutto, l'architetto deve incoraggiare gli sviluppatori a esercitare i propri talenti di design al fine di ottenere il miglior risultato finale da ogni squadra.

Dato che ti sforzi di migliorare qualcosa, hai già avvertito un problema nel tuo processo. La causa principale della situazione specifica potrebbe essere la seguente: Gli sviluppatori non possono identificarsi con l'architettura, perché sono stati imposti su di loro da una persona esterna. La gestione dell'architettura allo sviluppo molto probabilmente non risolverà questa causa principale.

Rendi l'architettura una parte del team di sviluppo. Distruggi il confine tra l'architetto e lo sviluppatore. Questo assicura che l'informazione scorrerà. Se il team di sviluppo partecipa a plasmare l'architettura, non lo considereranno come qualcosa di alieno. Infondere la conoscenza dell'architettura nel team. Insegna loro i fattori guida dietro l'architettura aziendale per evitare il caos che hai citato. Coinvolgi gli sviluppatori quando devono essere prese decisioni architettoniche per evitare la noia che hai menzionato. Non è più necessario un passaggio di consegne e hai adempiuto al tuo ruolo di architetto in un team di sviluppo.

Devi dare quante più informazioni possibili al futuro team per mantenere il codice. Se non si dispone di diagrammi di sequenza, ad esempio, lo sviluppatore è costretto a tracciare il codice passo dopo passo, perdendo così tempo.

C'è anche spazio per la nuova squadra che fa ipotesi non valide.

In generale dovrebbe esserci un documento su cosa è il progetto, le specifiche tecniche, i casi di test unitario e i diagrammi sequenza / classe.

Direi che le viste dei diagrammi di classe che creano un modello e il codice sono una soluzione. Il diagramma delle classi rappresenta la vista statica della tua architettura di progetto. Voglio dire che hai pacchetti > classi, intefaces, enum > attributi, mehtods ecc ... > eccetera.. Se si guarda bene, il metamodello UML2 ha esattamente la stessa struttura di un progetto java o dotnet.

Ciò che utilizziamo nei nostri progetti sono semplicemente diagrammi di classe che vengono salvati in un singolo modello. Generiamo viste del modello se il classificatore esiste già o ne crea uno nuovo in formato grafico se è nuovo. Gli sviluppatori possono vedere i nostri diagrammi e modelli perché salvati nella cartella principale del progetto all'interno di CVS. Quello che mi piace è che anche lo sviluppatore può modellare perché se qualcosa viene cambiato a livello di codice, il modello viene automaticamente aggiornato su CVS per l'intero team.

Funziona molto bene e non è necessario conoscere UML perché il diagramma delle classi è davvero semplice e il reverse engineering farà il lavoro e creerà la vista grafica del codice. Navigazione semplice, viste avanzate e dettagliate in cui è possibile aggiungere molti commenti con diagrammi sempre aggiornati e visibili su CVS direttamente nel progetto. Il mio diagramma di classe UML ora è Magic: -)