Sviluppo concorrente senza design centrale?

5

Ho un team di sviluppatori che stanno cercando di scrivere specifiche / test contemporaneamente per parti diverse (e talvolta adiacenti) del sistema.

In genere, la persona che scrive la specifica / test è non lo sviluppatore che scriverà l'implementazione e farà passare la specifica / test.

Ecco il problema che stiamo riscontrando: la persona che riceve la specifica / test per cui un'implementazione non è stata ancora scritta non è abbastanza familiare con la progettazione dei molti oggetti del sistema da sapere :

Risolvo questo problema (la specifica / test) con un oggetto esistente o creo (per la prima volta) le dipendenze che permetteranno al sistema di superare questa specifica / test?

Non tutti gli sviluppatori del progetto hanno la conoscenza del dominio per prendere queste decisioni bene , e ci scontriamo fino a quando disparati disegni e oggetti creati in relativo isolamento iniziano a confliggere e duplicano ogni altro.

Quali sono le soluzioni a questo problema? È semplicemente inevitabile che tutti gli sviluppatori del progetto debbano sapere (o essere pronti a chiedere) gli oggetti del sistema?

Sentiti libero di fornire quelle che ritieni siano risposte ovvie.

    
posta lance 08.07.2011 - 20:08
fonte

4 risposte

1

Per quale dominio è il sistema? Ho fatto l'esperienza, che tutte queste specifiche di scrittura sono spesso esagerate. Spesso è molto più utile rafforzare la comunicazione e la collaborazione tra chi ha l'idea o la visione del software e chi lo sta implementando. È uno dei core-value principali del core (http://agilemanifesto.org/), che funziona con il software sulla documentazione (includo specifiche pile di carta alla documentazione).

Secondo me, ogni sviluppatore deve capire il dominio, per i neofiti del dominio ciò comporta investimenti. Un modo molto utile è quello di fare la programmazione della coppia o di avere un mentore che sta introducendo gli sviluppatori con meno comprensione per le parti del sistema.

Ovviamente ci sono delle eccezioni a questa regola quando l'approccio intensivo delle specifiche è la soluzione ottimale del problema ... Dipende anche dalle dimensioni del tuo sistema e dalle dimensioni del team. Quindi forse puoi dare maggiori dettagli su questo.

    
risposta data 08.07.2011 - 20:34
fonte
1

Not all of the developers on the project have the domain knowledge to make these decisions well

Se alcuni sviluppatori non hanno una profonda comprensione dello scopo del sistema o dei requisiti del cliente (conoscenza del dominio del cliente), impiegheranno più tempo per scrivere e il codice scritto richiederà più test e < strong> più rilavorazione . Questo è il tipico approccio sperimentale all'errore ed è sia un costo sia un investimento .

Se alcuni sviluppatori non progettano bene l'architettura , quindi delegano il lavoro di progettazione a un architetto migliore. Ad esempio, per progettare bene ci vuole molto di più della conoscenza del dominio, ad es. la saggezza dell'architettura, per la quale alcuni programmatori fanno meglio di altri e che non cresce linearmente con l'esperienza. Ci sono due modi in cui questo può funzionare:

  • L'architetto può specificare CRC e i metodi di interfaccia e consentire ad altri sviluppatori di implementare i dettagli .
  • L'architetto può entrare dopo il fatto e supervisionare il refactoring del progetto mentre il codice / specifiche / test era già stato stabilizzato.

Se vuoi che l'architettura del software si abbini bene con lo scopo, beh ... cambia team o cambia azienda. DDD di solito hanno una norma "i non esperti non devono applicare".

Typically, the person writing the specification/test is not the developer who will write the implementation and make the specification/test pass.

Se una specifica / test è troppo generica / vaga / enorme per gli sviluppatori da implementare ... suddividili in specifiche / test più piccoli.

Do I solve this problem (the specification/test) with an existing object(s), or do I create (for the first time) the dependencies which will allow the system to pass this specification/test?

Nella tua situazione, suggerisco abbracciare la rilavorazione . A volte la risposta alla domanda di creazione / riutilizzo non è ovvia. Chiedi a un architetto quando disponibile. In caso contrario, lancia una moneta.

... we're colliding so far as disparate designs and objects created in relative isolation begin to conflict and duplicate each other.

Ecco un approccio che ha funzionato per me in un progetto più piccolo . Probabilmente non è scalabile per progetti più grandi.

Ogni membro del team inizia una giornata di lavoro leggendo tutte di ogni modifiche al codice di altri membri del team.

(Questo è adatto per le impostazioni di "tutti in una grande stanza gigante condivisa con altre squadre" in quanto può essere fatto in assoluto silenzio. È adatto anche per i team dispersi geograficamente in quanto non occupa tempo di affrontare. che hanno uffici dedicati potrebbero trovare la programmazione di coppie più adatta.)

(Lo sforzo è gestibile fino a 10 sorgenti di commit al giorno o 500 linee di cambiamento.)

    
risposta data 10.07.2011 - 05:02
fonte
0

Sembra che tu possa risparmiare MOLTO denaro riunendo tutti gli sviluppatori principali per discutere ogni nuova specifica prima di implementarla.

La cosa più importante è la comunicazione, e se non sai che non puoi usare.

    
risposta data 08.07.2011 - 20:40
fonte
0

Questo problema viene in genere risolto da un lead come parte della risposta alle domande degli sviluppatori o dell'identificazione dei difetti in una revisione del progetto.

Un altro modo in cui ho visto i team risolvere questo problema è quello di sinterizzare il loro lavoro. Alle persone vengono assegnate responsabilità silicee. Una persona primaria e forse una secondaria possiede una particolare area del sistema. Sono gli esperti. Ottengono tutto il lavoro in quest'area. Sebbene ciò possa rendere più semplice ed essere altamente produttivo, comporta molti rischi che vanno dalla disponibilità degli sviluppatori alla mancanza di conoscenza generale del sistema.

    
risposta data 09.07.2011 - 15:49
fonte

Leggi altre domande sui tag