Esistono buone pratiche relative alla consegna dall'architettura allo sviluppo?

Stiamo cercando di migliorare il processo per la consegna di compiti dall'architettura allo sviluppo.

A un'estremità della scala non esiste una guida all'architettura che rischi di provocare caos, con ogni sviluppatore che fa le cose a modo suo.

All'altra estremità della scala in cui tutto è specificato, le specifiche richiedono più tempo dello sviluppo e si rischia di svolgere attività di sviluppo molto noiose.

Qualcuno ha trovato una via di mezzo ottimale tra questi estremi? Quali artefatti fornisci allo sviluppo? Ad esempio: moduli, struttura delle classi o diagrammi di sequenza?

Inizierò dicendo 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 ad essere il culmine dei peggiori artisti bull * * pseudo-intellettuali della torre d'avorio che si possono trovare nel pool di sviluppatori.

Altre organizzazioni trattano i gruppi di architettura come una ricompensa politica e una giustificazione per uno stipendio enorme per i membri più anziani, indipendentemente dal merito, dalla conoscenza o dall'abilità. La maggior parte consiste in 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 il completo controllo dittatoriale su ogni aspetto della progettazione del software e che deve essere trasmesso agli sviluppatori che non hanno contribuito alla progettazione, non capiscono il ragionamento alla base delle scelte di progettazione e possono comprendere i difetti critici poiché il design è più comodo e più vicino all'implementazione effettiva e al codice esistente, è francamente completamente imperfetto dal suo stesso nucleo e si tradurrà costantemente in uno dei tre scenari:

• Gli sviluppatori non comprendono il progetto o lo respingono totalmente a causa delle realtà dell'attuale implementazione e finiscono per determinare il proprio progetto non documentato e implementarlo invece. La situazione è costituita da documenti di progettazione formali che non riflettono l'implementazione del software.

• Gli sviluppatori seguono ciecamente il progetto che può o meno prendere in considerazione i requisiti attuali o aspetti unici delle storie degli utenti, risultando in un'implementazione errata e di scarsa qualità.

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

Il modo migliore per mitigare questo problema è CAMBIARE il gruppo Architecture e possibilmente metterli in posizioni di leader tecnologico. Il ruolo del gruppo Architecture dovrebbe essere più o meno una "mischia di lead tecnologici", se vuoi. Dovrebbero incontrarsi solo raramente e discutere solo i problemi di direzione tecnica di più alto livello, ad es. pensate alla discussione che sta migrando da Java a Scala, ad abbandonare Oracle per MySQL, magari scrivendo librerie di utilità comuni che impongono un certo TIPO di processo di progettazione su un altro, passando da StarUML a Altova UML.

La progettazione reale e reale del software sarà un processo comunitario che coinvolge TUTTI gli sviluppatori di software, definito dalla direzione di livello estremamente elevato del gruppo Architecture.

Ci sono sempre stati problemi nel modo in cui le informazioni fluiscono dall'architettura al 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
• credenza.

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

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

Soprattutto per i progetti governativi e finanziari, è necessario che una maggiore documentazione sia scritta in anticipo e che può richiedere molto tempo senza feedback del mondo reale sulle tue scelte. Nella mia mente il motivo principale per cui molti di questi progetti falliscono. Tuttavia, se questa è la tua situazione, farei la documentazione per soddisfare i requisiti e utilizzare l'opzione 1 o 2 per costruire effettivamente il software e perfezionare / adattare la documentazione.

Spero che sia di aiuto.

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

All'altra estremità della scala se tutto è specificato, la specifica richiede più tempo dello sviluppo. E rischi di avere compiti di sviluppo molto noiosi.

è in realtà qualcosa per cui dovresti lottare. Se la progettazione e le specifiche sono sufficientemente solide da rendere noiose le attività di sviluppo, i costi di sviluppo diminuiscono. È molto meno costoso fissare una specifica che fissare un codice, e il costo maggiore dei progetti software non è la costruzione, è il supporto a lungo termine. E il codice di supporto basato su specifiche solide è molto meno costoso.

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

Concordo 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 tutti i team di architetti con lo stesso pennello largo e, quando fatto, i team di architetti giusti possono offrire un grande valore al processo di sviluppo del prodotto complessivo. L'idea sbagliata è che gli architetti dovrebbero dettare ogni aspetto della progettazione del sistema. Dovrebbero invece concentrarsi sulla progettazione di livello superiore e lasciare i dettagli di implementazione ai loro team di sviluppo. Ciò non significa tuttavia che gli sviluppatori non debbano essere coinvolti fin dall'inizio nel processo di pianificazione e progettazione.

Più un prodotto è grande, modulare e alla fine più complesso, più è probabile che troverete varie parti del prodotto gestite da diversi team di sviluppo. Tali team non devono comprendere il sistema nel suo complesso, purché abbiano una piena comprensione delle parti del sistema di cui sono responsabili. Spesso questi team aggiuntivi vengono creati come subappaltatori con lo scopo specifico di sviluppare un modulo in una particolare area tecnologica in cui gli architetti o altri team potrebbero non avere esperienza. I miei talenti particolari risiedono nello sviluppo di API e non ho ancora visto un'API ben ponderata che è stata sviluppata interamente organicamente senza essere un disastro completo in termini di usabilità, o che non richiedeva che qualcuno si distinguesse come persona che garantiva un livello di uniformità tra i diversi aspetti dell'API. Posso continuare a elencare molti esempi e ragioni, ma non penso che questo tipo di situazioni siano la torre d'avorio BS che molti potrebbero pensare di essere. Sfortunatamente, ci sono molti luoghi, in particolare nelle aree della difesa, della medicina e dei settori finanziari in cui la paranoia aziendale provoca uno sviluppo del prodotto mal specificato e ancora più mal gestito del tipo di cui sono sicuro che maple_shaft fosse maggiormente preoccupato. Queste sono le cose che ritengo possano dare agli architetti un brutto nome meritato (in generale). Sfortunatamente, ci sono molti luoghi, in particolare nelle aree della difesa, della medicina e dei settori finanziari in cui la paranoia aziendale provoca uno sviluppo del prodotto mal specificato e ancora più mal gestito del tipo di cui sono sicuro che maple_shaft fosse maggiormente preoccupato. Queste sono le cose che ritengo possano dare agli architetti un brutto nome meritato (in generale). Sfortunatamente, ci sono molti luoghi, in particolare nelle aree della difesa, della medicina e dei settori finanziari in cui la paranoia aziendale provoca uno sviluppo del prodotto mal specificato e ancora più mal gestito del tipo di cui sono sicuro che maple_shaft fosse maggiormente preoccupato. Queste sono le cose che ritengo possano dare agli architetti un brutto nome meritato (in generale).

Allora, dov'è la via di mezzo che l'OP stava cercando? La risposta ha 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 caratteristici nel senso più ampio, in cui tutto è considerato una scatola nera. Gli architetti devono quindi assicurarsi che i team abbiano accesso al tempo dell'architetto per confermare eventuali assunzioni e ottenere risposte alle 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 interagire con gli altri team per garantire che ciascuna parte del sistema giocherà bene con le altre parti. Queste squadre si incontrano direttamente. Una volta che il sistema è stato progettato al più ampio livello, gli architetti dovrebbero davvero essere le persone a cui si rivolgono i team quando hanno bisogno di un controllo di integrità e per garantire che la "visione" del prodotto venga 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 dirigenti, dei clienti e di tutti gli altri stakeholder, garantendo comunque che queste varie persone possano riunirsi per lavorare tra loro come dovrebbero funzionare le cose.

Gli architetti IMHO dovrebbero innanzitutto essere facilitatori e comunicatori, e secondo i progettisti. Quanto al livello di specifica? Penso che i migliori architetti siano quelli che chiedono ai loro team il livello di dettaglio che un team desidera e tra loro trova un equilibrio che funziona. Team diversi possono avere requisiti diversi in termini di quantità di documentazione o direzione richiesta. I team senior possono trovare un diagramma approssimativamente disegnato e una chat veloce può essere sufficiente per iniziare, mentre i team pieni di sviluppatori relativamente junior potrebbero aver bisogno di un po 'di più per farli funzionare. Soprattutto, l'architetto deve incoraggiare gli sviluppatori a esercitare i propri talenti di progettazione al fine di ottenere il miglior risultato finale da ciascun team.

Dato che ti sforzi di migliorare qualcosa, hai già riscontrato un problema nel tuo processo. La causa principale della situazione specifica potrebbe essere la seguente: gli sviluppatori non possono identificarsi con l'architettura, perché è stata imposta loro da qualcuno esterno. Consegnare l'architettura allo sviluppo molto probabilmente non risolverà questa causa alla radice.

Rendi l'architettura parte del team di sviluppo. Abbattere il confine tra l'architetto e lo sviluppatore. Ciò garantisce che le informazioni scorrano. Se il team di sviluppo partecipa a modellare l'architettura non la considererà 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 sull'architettura per evitare la noia che hai citato. Non è più necessario un passaggio di consegne e hai svolto il tuo ruolo di architetto in un team di sviluppo.

È necessario fornire quante più informazioni possibili affinché il team futuro mantenga il codice. Se ad esempio non si dispone di diagrammi di sequenza, lo sviluppatore è costretto a tracciare il codice passo dopo passo, facendo perdere tempo.

Inoltre, c'è spazio per la nuova squadra che fa ipotesi non valide.

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

Direi che le viste dei diagrammi di classe che creano un modello e un codice sono una soluzione. Il diagramma di classe rappresenta la vista statica dell'architettura del progetto. Voglio dire che hai pacchetti> classi, interfacce, enum> attributi, mehtods ecc ...> ecc. Se stai 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 creiamo uno nuovo in forma grafica 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 davvero bene e non c'è davvero bisogno di conoscere UML perché il diagramma di classe è davvero semplice e il reverse engineering farà il lavoro e creerà la vista grafica del codice. Navigazione semplice, visualizzazioni 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 è magico :-)