Che cosa si dovrebbe portare al tavolo come un Software Architect? [chiuso]

https://softwareengineering.stackexchange.com/questions/18444

22-10-2019
|

Domanda

Ci sono state molte domande con buone risposte sul ruolo di un Software Architect (SA) su StackOverflow e programmatori SE . Sto cercando di fare una domanda un po 'più mirato rispetto a quelli. La definizione stessa di una SA è ampia così per il bene di questa domanda definiamo una SA come segue:

Un Software Architect guida il disegno complessivo di un progetto, ottiene coinvolto con codifica sforzi, condotte revisioni del codice e seleziona il tecnologie da utilizzare.

In altre parole, non sto parlando di riposo manageriale e gilet sulla cresta (in rima ulteriori parole elise) tipi di Sas. Se dovessi perseguire qualsiasi tipo di posizione SA Non voglio essere lontano da codifica. Potrei sacrificare un po 'di tempo per interfacciarsi con i clienti e gli analisti aziendali, ecc, ma sono ancora tecnicamente coinvolti e non sono solo a conoscenza di quello che sta succedendo attraverso incontri.

Con questi punti in mente, quello che dovrebbe un SA portare al tavolo? Dovrebbero entrare con una mentalità di "che stabilisce la legge" (si fa per dire) e far rispettare l'utilizzo di alcuni strumenti per adattare "il loro modo", vale a dire, la codifica linee guida, controllo del codice sorgente, modelli, documentazione UML, ecc? O dovrebbero specificare direzione e la strategia iniziale poi essere rilassato e saltare come necessario per correggere la direzione della nave?

Secondo l'organizzazione non potrebbe funzionare. Un SA che si basa su TFS per far rispettare tutto ciò che può lottare per attuare il loro piano ad un datore di lavoro che utilizza solo StarTeam. Analogamente, un SA deve essere flessibile a seconda della fase di progetto. Se si tratta di un nuovo progetto hanno più scelte, mentre potrebbero avere meno per i progetti esistenti.

Qui ci sono alcune storie SA che ho vissuto come un modo per condividere un po 'di sfondo, nella speranza che le risposte alle mie domande potrebbe anche far luce su questi temi:

Ho lavorato con una SA che il codice recensione letteralmente ogni singola riga di codice della squadra. La SA avrebbe fatto questo non solo per il nostro progetto, ma altri progetti nell'organizzazione (immaginare il tempo speso su questo). In un primo momento è stato utile per far rispettare determinati standard, ma in seguito è diventato paralizzante. FxCop è stato come la SA avrebbe trovato problemi. Non fraintendetemi, è stato un buon modo per insegnare a sviluppatori junior e costringerli a pensare alle conseguenze del loro approccio scelto, ma per gli sviluppatori di alto livello è stato visto come un po 'draconiana.
Un particolare SA era contro l'uso di una certa biblioteca, sostenendo che era lento. Questo ci ha costretto a scrivere tonnellate di codice per ottenere le cose in modo diverso, mentre l'altra libreria sarebbe ci hanno risparmiato un sacco di tempo. Avanti veloce fino all'ultimo mese del progetto ed i clienti sono lamentati delle prestazioni. L'unica soluzione era quella di modificare alcune funzionalità di utilizzare l'approccio inizialmente ignorato nonostante i primi avvertimenti gli sviluppatori. A quel punto un sacco di codice è stato buttato fuori e non riutilizzabile, che porta al lavoro straordinario e lo stress. Purtroppo le stime utilizzate per il progetto sono stati basati sul vecchio approccio che il mio progetto è stato proibito di usare quindi non era un indicatore appropriato per la stima. Vorrei sentire la voce PM "che abbiamo fatto prima", quando in realtà non avevano perché stavamo usando una nuova biblioteca e gli sviluppatori che lavorano su di esso non erano gli stessi sviluppatori utilizzate sul vecchio progetto.
Il SA che avrebbe imporre l'utilizzo di DTOs, DOS, Bos, livelli di servizio e così via per tutti i progetti. Nuovi sviluppatori hanno dovuto imparare questa architettura e le linee guida di utilizzo SA forzate categoricamente. Le eccezioni a linee guida di utilizzo sono state fatte quando è stato assolutamente difficile seguire le linee guida. La SA è stata fondata nel loro approccio. Classi per DTOs e tutte le operazioni CRUD state generate tramite CodeSmith e schemi di database erano un'altra simili palla di cera. Tuttavia, avendoutilizzato questa configurazione ovunque, la SA non era aperto a nuove tecnologie come LINQ to SQL o Entity Framework.

Non sto usando questo post come una piattaforma per lo sfiato. Ci sono stati aspetti positivi e negativi per le mie esperienze con le storie SA di cui sopra. Le mie domande si riducono a:

Che cosa dovrebbe una SA portare al tavolo?
Come possono trovare un equilibrio nel loro processo decisionale?
Se uno approccio un lavoro SA (come definito in precedenza) con la mentalità che devono rispettare determinate regole di base?
C'è altro da prendere in considerazione?

Grazie! Sono sicuro che questi compiti di lavoro sono facilmente esteso per le persone che sono sviluppatori senior o responsabili tecnici, quindi sentitevi liberi di rispondere a tale capacità pure.

Soluzione

A Sistemi architetto dovrebbe:

Specifica l'architettura di alto livello
Partecipare a revisioni del codice
Approva tecnologie utilizzate
Assist gli sviluppatori nel loro sforzo di codifica
Mantenere e monitorare il programma di sviluppo
Produrre SA artefatti, come diagrammi UML, diagrammi di Gantt e simili.

SA di deve saper codice e dovrebbe partecipare una parte del lavoro di codifica, mettere le mani bagnate, per così dire. Questo li tiene in contatto con la gestalt dello sforzo di sviluppo. Come lo zio Bob Martin ha detto una volta , l'architetto deve fare un po 'di codifica se stesso, in modo che lui può vedere il dolore che sta infliggendo altri con i suoi disegni.

Il SA deve avere l'ultima parola su tutto il design, la tecnologia e le decisioni stile di codifica. Ma, come tutti i manager, il lavoro del SA è quello di spianare la strada per il suo popolo in modo che possano essere produttivi. Ciò significa che, per la maggior parte, che gli sviluppatori arriva a decidere, al loro livello, come i problemi devono essere risolti. Significa che la SA mantiene i boss dai capelli a punta di cubicoli degli sviluppatori. E ciò significa che le piazzole SA per aiutare, se necessario.

Come tutti gli esseri umani, può di SA e fare errori di chiusura. Quelli buoni imparare da questi errori, e diventare migliore di SA.

Altri suggerimenti

1 Che cosa dovrebbe una SA portare al tavolo?

Una pelle spessa
Le buone capacità di negoziazione
una buona comprensione dei vari livelli di software (da whizzy bontà AJAX per basso livello di rete di I / O). Non necessariamente essere un mani su un esperto, ma si sta andando ad avere prendere decisioni importanti su ciò che il software dovrebbe essere eseguito a quale livello (s).
La volontà di ottenere il loro mani sporche nel codice, carta bianca disegni proprio non è tagliato.
Incoraggiamento di artigianato software - sia la cheerleader per fare le cose nel modo giusto, quando possibile e al meglio date le limitazioni in altri casi. Quindi le cose come controllo del codice sorgente, TDD, costruire e CI, dojo di codifica, le revisioni del codice, un buon sistema di tracciamento problema etc

2 Come possono trovare un equilibrio nel loro processo decisionale?

Gran parte di essa dipende dalla vostra squadra (s) e come essi sono in grado.
L'ambiente (si potrebbe essere costretto ad usare prodotti di un determinato fornitore, ad esempio)
In generale è meglio non essere un architetto torre d'avorio, sia le mani su, essere parte della squadra -. La gente capirà le vostre decisioni in questo modo

3 Se uno approccio un lavoro SA (come definito in precedenza) con la mentalità che devono rispettare determinate regole di base?

Si, cose come il controllo di versione e di un sistema di compilazione sono maledettamente importanti e gli sviluppatori hanno bisogno di utilizzare questi. Tuttavia è away migliori per renderli parte della soluzione.

Non c'è molto di più, penso che ci stanno per essere alcuni davvero buone risposte che vengono attraverso per questo.

Non ho mai incontrato un architetto che è stato utile, in primo luogo perché non erano pratici.

Per quanto mi riguarda più grandi problemi che ho visto sono:

cieca adesione al procedimento per ragioni di processo
pregiudizi ciechi alla tecnologia prima di conoscere il problema
creazione e l'esecuzione delle regole senza una buona giustificazione
rewrite from scratch mentalità

Il meglio "Architetti" Ho lavorato con portato al tavolo:

Domande che hanno spinto ad una migliore comprensione del problema e le possibili soluzioni.
Opzioni di progettazione / tecnologie e le loro trade-off.
Cancella e le spiegazioni razionali per entrambe le condanne e delle specializzazioni di design e tecnologie.

Il problema per me è il migliore "Architects" con cui ho lavorato non ha avuto "Architetto nel titolo. Erano molto spesso Software ingegneri che sono a terra nel problema e progetti specifici. Hanno capito che nella maggior parte delle imprese non è pratico di riscrivere una base di codice di lavoro da zero. fanno decisione di progettazione o di fornire opzioni e le loro ragioni o giustificazioni. Essi tracciano fuori come iterare il codebase per una nuova architettura nel corso del tempo ed ancora tenere tutto funzionale. Essi danno raccomandazioni conservatori invece di raccomandare ciò che è dejour o familiare. avrebbero comunicare una visione coesa di come le cose dovrebbero funzionare e perché, MA più importante avrebbero tracciare come arrivarci e la costi.

1.What dovrebbe una SA portare al tavolo?

"dovrebbero entrare con una mentalità di 'che stabilisce la legge' ... o dovrebbero specificare direzione e la strategia iniziale poi essere rilassato e saltare come necessario per correggere la direzione della nave?"

Una combinazione di entrambi direi. Al momento di decidere su tecnologie e processi, essere aperti a opinioni e suggerimenti può dare un prezioso feedback / input sulle decisioni e la causa di imparare dagli altri. La tua squadra è (si spera) intelligente; approfittare di questo. Ma una volta che si prende una decisione (la vostra decisione), la legge è stato deposto. Identificare coloro che si lamentano tutto ciò che non era la loro scelta, e di quelli che sarà solo scegliere qualsiasi cosa e non si preoccupano -. E poi ignorarli

Per quanto riguarda le tecnologie: lavorare con quello che hai, se l'azienda utilizza StarTeam allora che di quello che si utilizza. Sposando voi stessi di un particolare prodotto / tecnologia / processo non sta andando a fare qualcosa per voi.

2.How può che trovare un equilibrio nel loro processo decisionale?

L'ascolto della squadra e sapere quando hanno ragione e sbagliato è importante, e avendo i cojones per dire loro che si sbagliano e bastone per la vostra decisione. Non ascolto porterà una mancanza di rispetto, come si flopping intorno sulle vostre decisioni.

3. Qualora dai un approccio un lavoro SA (come definito in precedenza) con la mentalità che devono rispettare determinate regole di base?

Sempre. Se no, allora i detenuti finiranno in esecuzione manicomio, apertamente o nascostamente. Decidere su queste regole di base però, può avvenire attraverso colloquio con la squadra. Ricordate che qualsiasi squadra non può sempre avere gli stessi membri che ha adesso, cosí facendo concessioni per un piccolo gruppo di loro può ostacolare la squadra in futuro, una volta che sono andati. Che include la SA.

4.Anything altro da prendere in considerazione?

In riferimento alla Vostra secondo esempio: Sembra che il team di progetto formata una dipendenza strettamente accoppiati in un sottosistema in-house. Liberamente facciate accoppiati non sono solo per codice di terze parti. Creazione di un'astrazione per tale sottosistema avrebbe potuto permettere una transizione più facile da utilizzare che libreria se la soluzione in-house non è riuscita. Si tratta di una soluzione logica per un architetto del software da solo, ma anche essere una forma di Project Manager con le preoccupazioni di espressione squadra, avrebbe dovuto doppiamente stata una soluzione ovvia.
In riferimento alla Vostra terzo esempio: Non è una cattiva idea di avere un'architettura noto o di un processo per la produzione di software (anche se, bisogna ammetterlo, hai detto 'tutti i progetti'). Questo è attaccare a ciò che funziona. Detto questo, c'è bisogno di opportunità dove le nuove tecniche può essere tentata per vedere se portano un valore aggiunto. In-house-solo il software, o di progetti di minore portata in cui queste tecnologie possono essere tentati sono luoghi ideali. Occorre tuttavia tenere presente, che spetta anche sulle sviluppatore (s) per fornire ricercato e convincenti dimostrazioni / argomenti per l'adozione di tecnologie. E SA non si può pretendere di conoscere ogni ORM competizione ed i suoi punti di forza e di debolezza rispetto agli altri.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a softwareengineering.stackexchange