Procedure per la riunione di progettazione del software

Alcune cose che potresti voler provare a migliorare la situazione

Agenda

Avere una serie di argomenti che devi discutere e limitarti a questi (almeno inizialmente).

Discussioni di Timebox

Timebox ogni oggetto dell'agenda. Se sembra che finirà, portalo offline o eseguilo su un'altra riunione.

Limita i partecipanti

Puoi evitare che le discussioni sfuggano di mano limitando il numero di partecipanti o suddividendo la sessione di progettazione in più riunioni. Se riesci a convincere i partecipanti a pensare in anticipo agli oggetti dell'agenda, ingrasserà le ruote.

Calendario

Accetta che le riunioni di progettazione possano coprire più sessioni. Considera quando è meglio pianificare le riunioni per ottenere il meglio dai partecipanti.

Fai progressi laddove possibile

Se un elemento dell'ordine del giorno viene bloccato, non esitare a parcheggiarlo e spostarti su un articolo in cui è probabile il consenso. È probabile che l'incontro sia considerato più positivamente per tutte le parti se sono stati compiuti alcuni progressi.

Limita le opzioni disponibili

Se una funzionalità di progettazione è discutibile, limita le opzioni disponibili. Anche se non puoi farlo, potresti essere in grado almeno di escludere alcune opzioni (dall'esperienza in progetti precedenti).

I problemi che stai riscontrando sono principalmente problemi del posto di lavoro, tuttavia credo che siano radicati nei problemi dei ruoli che le persone svolgono nel processo di enginering del software. Una possibile mancanza di un ruolo (analisi aziendale) potrebbe aiutare anche.

We get off track easily, a combination of low understanding of the content of the system ...

Questo potrebbe indicare che hai bisogno di un'analisi aziendale o di qualcuno che raccolga i requisiti e capisca i problemi che il cliente sta avendo e come il software possa risolvere questi problemi.

... and want for the solution to be your solution drives the conversation often.

Questo è un problema di persone, che è fuori tema per questo sito.

We are unable to come to an acceptable conclusion. Often the developers and the system architect have issues due to the involvement of the architect in the low level design.

Anche se questo potrebbe essere un "problema di persone", in particolare si riferisce all'ingegneria del software. L'architetto dovrebbe prendere decisioni come "questa sarà un'applicazione web" e "useremo un database relazionale" e "utilizzerà i micro-servizi".

Le decisioni relative ai componenti di basso livello dovrebbero essere delegate allo sviluppatore principale del team di ingegneri. Separazione dei doveri, sarebbe un termine che si applica qui.

In-ability to stick to a top-down approach, often going into depth of components before the high level design is completed. I believe this is due to a significant difference of design thinking by the members of the meeting.

Questo è probabilmente dovuto al fatto che le persone "approfondiscono i componenti prima che il design di alto livello sia completato. " Il design di alto livello deve essere completato, prima di pensare ai livelli inferiori.

Non invitare persone che non dovrebbero essere presenti alla riunione.

Ad esempio, l'architetto non dovrebbe nemmeno essere presente quando si discute della progettazione di basso livello. Invita solo le persone che comprendono bene il sistema, al livello che viene discusso in quella riunione.

Non cercare di fare architettura, design di alto livello e design di basso livello in un'unica grande riunione.

Disegnala dall'alto verso il basso. In riunioni separate. Non pensare nemmeno al design di basso livello finché non hai deciso cosa si intende fare.

Oltre alla risposta di @Robbie Dee,

Per il punto 1

Condividi in anticipo l'ordine del giorno con i principali stakeholder e preparali con il loro lavoro / domande a casa.

Se la discussione sta andando fuori pista, parcheggiala per metterla offline con il sottogruppo coinvolto nel fuori traccia. Un esempio potrebbe essere lo sviluppatore e l'architetto che non concordano su particolari punti di progettazione. Lascia che queste persone arrivino al consenso sulla propria riunione offline o separata. Ciò ti aiuterà a raggiungere la tua agenda per quel particolare incontro ea forgiare gruppi a livello di argomento per creare consenso.

Se succedono queste cose di tanto in tanto, individua i punti deboli (abilità tecniche / soft) nella squadra che portano al fuori fuoco e indirizza quelli.

Per il punto 2: Accettare lo sviluppo del software non è come una catena di montaggio, dove una persona fa qualcosa e l'altra prende il sopravvento. Tutto il team deve essere coinvolto in ogni processo in modo che possano capire meglio le cose.

Per il punto 3: Hai già menzionato al punto 1 "conoscenza limitata del contenuto del sistema". Il team sta andando in profondità perché non ha fiducia nella progettazione di alto livello (a causa della conoscenza limitata del contenuto del sistema) e desidera convalidare immediatamente il design scavando in profondità. Per risolvere questo problema, l'Architetto offre un design di alto livello, assegna i componenti agli sviluppatori / conduce alla progettazione e alla revisione come da HLD prima della riunione. Solo il tempo di revisione in scatola si verifica in riunione.