Come comunicare in modo efficiente la progettazione del software tra gli sviluppatori? [duplicare]

5

Recentemente ho capito che un problema serio sul mio posto di lavoro è la mancanza di comunicazione tra gli sviluppatori. È strano, perché siamo un'organizzazione di tipo totalmente aperto. Tutti possono andare da tutti e chiedere tutto ciò di cui hanno bisogno e la comunicazione non è affatto regolamentata. Eppure non succede da solo ...

Il tipo di mancanza che sento più profondamente me stesso è tra me (l'architetto del sistema, più o meno) e il resto degli sviluppatori (che di solito lavorano su una parte della funzionalità richiesta, non sul framework). Ogni volta che creo un componente o una convenzione di denominazione o qualsiasi altra cosa ... non c'è modo di farla conoscere a tutte le persone che potrebbero aver bisogno di saperlo. Al massimo, lo dico di persona al compagno che me lo ha chiesto, ma questo è tutto.

Di conseguenza, le ruote vengono reinventate, non ci sono quasi convenzioni nel codice (per lo più evolute da copia-incolla), occasionali codifiche del carico, ecc. Cerco di ripulirlo ogni volta che ne ho l'opportunità, ma con Poiché il carico di lavoro è tanto grande, raramente ci sono tali possibilità. : (

Non sono sicuro di come risolvere questo problema. Potrei provare a documentare tutte le cose che sono state create (probabilmente ci vorrebbe almeno una settimana - difficile da spendere tanto tempo) nella nostra wiki interna, ma chi legge mai regolarmente tali luoghi per le notizie? E come troveresti se qualcosa di cui hai bisogno è già stato implementato da qualche parte?

Cosa fanno gli altri per evitare questo trabocchetto? Quali metodi si sono dimostrati efficienti?

    
posta Vilx- 26.11.2014 - 11:16
fonte

7 risposte

2

Uso due cose: la mia voce e una lavagna.

Voglio dire, per quanto gli sviluppatori odiano le riunioni, do devono lavorare come una squadra. Le stand up sono un ottimo momento per parlare di nuove cose che stai facendo in codice (e per chiedere se esiste già qualcosa). Per grandi cose, lo sprint planning meeting è un buon momento per l'intero team per fornire input al design, quindi tutti sanno cosa sta succedendo. E lo sprint demo meeting è un buon momento per entrare nei minimi dettagli su come il design è cambiato dall'inizio dello sprint. Nella mia esperienza, una lavagna è lo strumento migliore per comunicare il design tra gli sviluppatori. Pochi sono abbastanza bravi a leggere il codice e nessuno legge (rapidamente obsoleto) la documentazione.

E per cose particolarmente grandi / complesse / sottili, probabilmente avrai bisogno di un incontro dedicato per divulgare tali informazioni.

Le revisioni di codice possono essere un'ultima linea di difesa contro sforzi duplicati o uso improprio / errata modifica del codice. Ma prendono le cose dopo tutto il lavoro è fatto. Avendo un buon lavoro di squadra, previeni che il lavoro sprecato venga svolto completamente.

Non usare agile / scrum? In primo luogo, le mie condoglianze. In secondo luogo, la premessa è ancora valida. Devi parlare in gruppo - ogni giorno per piccole cose. E devi coordinare periodicamente le cose più grandi in modo che lavori come una squadra.

    
risposta data 26.11.2014 - 13:53
fonte
1

Non esiste una risposta semplice.

Le immagini grandi messe sui muri possono aiutare. qualcosa come i diagrammi 4C (Context, Container, Component, Class) link (sebbene la classe sia probabilmente troppo dettagliata)

Questi possono aiutare ad orientare le persone nel codice e a capire cosa esiste.

Le revisioni del codice possono aiutare a diffondere le buone pratiche, ma farle bene è un'arte. Il recensore non dovrebbe sentirsi messo sopra, e non dovrebbe (principalmente) non essere un singolo gatekeeper del repository (a causa del problema hit-by-a-bus se non altro)

Oltre a ciò, standup e schede di gioco sono metodi per condividere le conoscenze all'interno del team, e una buona squadra impegnata che vuole migliorarsi è la chiave per l'intera impresa!

    
risposta data 26.11.2014 - 12:31
fonte
1

La risposta più semplice è la revisione del codice (e la revisione di codice , intendo davvero "tutto ciò che riguarda le modifiche al codice incluso il codice stesso." Ovviamente questo significa che devi avere documentazione.

Conosco luoghi in cui la gente sta hackerando da tutte le parti, l'ultimo posto in cui il mio compagno ha lavorato ogni volta che è venuto a correggere un bug che avrebbe preso l'ultimo codice e ... sarebbe cambiato. Una squadra avrebbe apportato cambiamenti in questa direzione e un'altra squadra avrebbe apportato cambiamenti in una direzione diversa. A volte i team hanno cambiato direzione da soli e si è ritrovato con un puro caos in cui nulla è stato fatto al prodotto, ma c'erano costanti e intensi cambi di codice.

Qui è dove hai bisogno di una forma di controllo delle modifiche di tipo non sviluppatore. Se si implementa un sistema in cui le modifiche vengono apportate in modo controllato, e con ciò intendo che chiunque può modificare qualcosa, è solo che hanno bisogno di un motivo per farlo e una qualche forma di autorizzazione che è una buona cosa per progredire.

Quindi puoi imporre che nessuna modifica venga applicata a meno che non sia in risposta a un ticket di modifica. (chiunque può creare un ticket che descriva un problema che deve essere modificato, ovviamente) ma questi biglietti vengono assegnati a una persona oa un team da un responsabile della direzione del prodotto - un analista di business o un'autorità di progettazione tecnica o persino un team che si riunisce. Ciò che è importante è che il cambiamento venga fatto in modo non individuale.

Una volta che ci si prende cura di qualcuno, qualcuno andrà a fare dei cambiamenti e poi li farà rivedere. Ciò significa che qualcun altro vede il codice ma anche le modifiche e la documentazione del ticket. Quindi, se vuoi cambiare il tuo sistema di accesso ai DB, bene ... ma devi descrivere di cosa si tratta, perché è stato cambiato e come funziona ora. Senza tale documentazione il cambiamento fallisce nella sua revisione. Successivamente è possibile implementare 'allenamenti' interni come borse marroni o dojo di codice per garantire che il resto del team venga informato.

Alcune persone resisteranno a questa situazione, ma tendono a essere quelle che controllano costantemente il codice, "codice di taglio" piuttosto che "lavorare sul prodotto". Questa è una distinzione importante da fare, in quanto sviluppatori possiamo essere tutti coinvolti nel concetto che il codice è ciò che è importante - non lo è. Il prodotto che stai creando è ciò che è importante e molto più del semplice codice.

La documentazione non deve essere estesa, quanto basta per dire a qualcun altro cosa hai fatto o come funziona. Può essere un wiki o anche solo delle note sui biglietti - poiché i biglietti invecchiano, svaniscono dalla vista e la documentazione con loro, ma questo è ok in quanto significa che solo i documenti rilevanti e aggiornati vengono conservati. In alternativa puoi avere una wiki di componenti, architettura e utilizzo e che viene tenuta aggiornata come parte di ogni cambiamento di codice. O (la mia preferenza) è di archiviare tutta la documentazione tecnica insieme al codice come documenti di testo in un formato di markup che è incorporato in html dal server di build e presentato su un server web - così chiunque può vedere la documentazione corrente che può essere facilmente aggiornata quando il codice è aggiornato.

Un'ultima risorsa è quella di ottenere un team di architettura che ha la responsabilità di documentare il sistema, ma avranno anche il potere di impedire che vengano apportate modifiche a meno che la documentazione non sia stata aggiornata per prima: molte squadre più sciolte potrebbero non gradire questo più restrittivo approccio, ma se non riescono a farlo funzionare usando i miei suggerimenti, questo è il sistema che dovrebbe essere implementato.

    
risposta data 26.11.2014 - 12:39
fonte
1

Ci sono (almeno) due problemi nascosti in questo problema comune. Il primo sta avendo un processo che assicura che le comunicazioni appropriate stiano avendo luogo, e il secondo sta assicurando che gli sviluppatori seguano effettivamente il processo - che sono spesso sotto stress da consegnare ed entusiasti di scrivere codice, guidati dall'ego (spesso in una buona modo) ecc.

Quest'ultimo, penso, è spesso più facile da realizzare nella pratica che il primo: separare lo sviluppo dei test di implementazione (integrazione finale) dalle persone responsabili della codifica e non accettare alcun codice nel ramo principale finché non passa tutto test. Quindi, indipendentemente da quanto o meno gli sviluppatori ascoltino o seguano il processo di comunicazione, qualsiasi modifica apportata non avrà alcun impatto sul codice distribuito se interrompe i test esistenti. Se i test sono una vera espressione di tutti i requisiti (funzionali e non funzionali) - incluso test che la nuova funzionalità non viene aggiunta senza conferma del test - allora questo processo impone la comunicazione perché altrimenti il codice di uno sviluppatore non va mai in qualunque posto! Il tuo lavoro minimo è quindi comunicare eventuali nuovi requisiti agli scrittori di test e assicurarti che vengano implementati per primi.

Il primo - cioè il processo di comunicazione reale può quindi svilupparsi nel tempo. Inizialmente, l'utilizzo del gate di qualità dei test di integrazione completa di cui sopra prima si impegna a padroneggiare obbligherà le persone a venire a tu a chiedere funzionalità e requisiti ecc. O il codice di nessuno verrà mai implementato e gli sviluppatori sono motivati dalla distribuzione. Potresti quindi iniziare a lavorare con meccanismi appropriati per la comunicazione, ad es. riunioni scrum o strumenti di collaborazione come Trello o elenchi di e-mail, recensioni di codici o riunioni di discussione sulla storia degli utenti del fabbisogno giornaliero o qualsiasi altra cosa funzioni per la struttura dei team.

Inserisci il gate di qualità di implementazione indipendente per primo e il resto, alla fine, seguirà.

    
risposta data 26.11.2014 - 12:59
fonte
1

I could try and document all the stuff that has been created…

Devi iniziare da qualche parte.

…who ever reads such places regularly for news?

Quindi utilizzare l'e-mail per notificare le modifiche. Mantenere l'SNR basso.

Dovrai coinvolgere le persone nelle modifiche (inclusa la gestione), quindi renderle consapevoli dei cambiamenti man mano che vengono adottati. Potresti volere il loro input su alcune modifiche. Altrimenti, basta spostarli in una e-mail / aggiornamento. Per argomenti più complessi, dedica alcuni minuti a spiegare e Q + A non molto tempo dopo che è stato pubblicato.

And how would you find if something that you need has already been implemented somewhere?

Le revisioni del codice sarebbero un buon inizio. Se le persone continuano a non riutilizzare il codice, dovresti entrare nelle fasi precedenti (ad esempio prima che venga scritto il codice).

As a result, wheels get reinvented, there are hardly any conventions in the code…

Questa è la parte difficile. Nessuno vuole prendere l'iniziativa. Il mio approccio tipico è di eseguire personalmente il cambiamento, fluttuare, discutere se necessario, spingere, quindi applicare (permettendo gli strumenti).

Quindi se si tratta di convenzioni di codifica:

  • fai una prova a secco della prossima modifica importante sulla tua lista di cose da fare
  • se riesce, passa la modifica ai tecnici
  • se ci sono domande / dubbi, dettagli il caso per il cambio di email o riunione
  • spinta
  • applica (strumento permettendo)

È così che di solito lo faccio, comunque. A volte le attività più grandi sono divise.

    
risposta data 26.11.2014 - 22:39
fonte
0

Per i team che eseguono la progettazione e l'implementazione OO, parte della comunicazione deve essere una comprensione condivisa dello spazio del problema e degli strumenti tipici utilizzati per risolvere tali problemi.

La nozione di modelli di progettazione è stata creata in modo molto specifico per creare un vocabolario condiviso che può essere usato come una scorciatoia quando si parla degli spazi problema.

Non intendo usare schemi di progettazione come un modo per prolungare i tempi di riunione con fastidiosi "così e così non è lo schema xyzzy!" argomenti. Piuttosto, invece di dover discutere a lungo di una specifica implementazione, i pattern di progettazione ci consentono di discutere l'immagine più grande e come i pezzi combaciano.

    
risposta data 26.11.2014 - 21:10
fonte
-3

È qui che entra in gioco DevOps. In realtà distrugge i silos tra gli sviluppatori e gli addetti alle infrastrutture IT. Quindi, ognuno sa cosa sta succedendo in un progetto. Nessuno è lasciato alle spalle.

Per la tua soluzione, prova ad implementare la cultura DevOps nella tua organizzazione.

    
risposta data 26.11.2014 - 12:18
fonte

Leggi altre domande sui tag