Come far fronte a diversi stili di sviluppo (dall'alto verso il basso o dal basso verso l'alto) in una squadra?

Ovviamente hanno entrambi torto.

Il ragazzo dal basso sta tagliando il codice e non produrrà mai qualcosa che fa quello che dovrebbe fare - sarà un churn continuo man mano che vengono determinati i requisiti sconosciuti.

Il top-down può spendere altrettanto a lungo nella visione architettonica e ottenere risultati non produttivi.

Tuttavia, una via di mezzo è l'ideale: se conosci gli obiettivi a cui stai lavorando (che ottieni da un ampio lavoro di progettazione) e prosegui con la programmazione (senza alcuna pianificazione dettagliata), raccogli i frutti di un sistema che è organizzato e sviluppato in modo efficiente.

Si chiama Agile a proposito (non la versione BS di agile che alcune persone praticano in cui le procedure sono più importanti del software di lavoro) ma la vera agilità che procede verso un obiettivo finale comunemente descritto e compreso.

Per risolvere il problema qui, prova un approccio Agile (Kanban è probabilmente il migliore) che costringerà sia il ragazzo top-down a fare un po 'di lavoro, e costringerà il ragazzo dal basso verso l'alto a pianificare ciò che sta cercando di realizzare.

I due sviluppatori devono mantenere un reciproco rispetto l'uno per l'altro.

La persona top down deve rispettare il fatto che la persona dal basso potrebbe aver trovato qualcosa che funziona davvero. Come uno dei miei professori "quant" mi ha detto, "Un modello funzionante vale 1000 ipotesi". Se questo è il caso, la persona top-down dovrebbe considerare di rifare il suo "design" per adattarsi al lavoro di una persona dal basso verso l'alto.

La persona dal basso dovrebbe anche rispettare la "struttura" della persona in alto, e capire che può essere utile per evitare sforzi inutili, risolvere il problema sbagliato, uscire dal tema, ecc. Il codificatore bottom-up dovrebbe almeno mantenere in mente che cosa deve fare provare e provare ad affrontare almeno le preoccupazioni dei top downer, come espresso nel framework. Ciò sarebbe vero anche se la parte inferiore-superiore non fosse d'accordo con le parti della struttura stessa.

È possibile ridurre al minimo la perdita di tempo speso da ciascun sviluppatore se si suddividono attività di grandi dimensioni in più attività più piccole e più mirate. Fateli lavorare a stretto contatto in modo che nessuno dei due si allontani troppo dall'altro. Brevi sprint e piccoli deliverable fanno molto. È più facile correggere un errore piccolo rispetto a uno grande.

Potrebbe sembrare controintuitivo al tuo obiettivo, ma la programmazione della coppia funziona. Ci sono cose che non catturerai da solo subito, a volte per ore o persino giorni. Se lavorare direttamente sulle attività insieme è fuori discussione, prova a riesaminare / standup dei codici più frequentemente durante la settimana.

Mantieni tutti informati!

Se stai vedendo gli sviluppatori buttare via il codice perché si trovavano nel loro mondo, è necessario catturare e riconciliare i conflitti nel modo più rapido ed efficiente possibile. Il tuo capo lo apprezzerà e il team apprezzerà il fatto di non dover buttar via una settimana di lavoro perché non sapeva cosa stava facendo l'altro.

Dovresti anche vederli lavorare insieme come una benedizione. Il fatto che stiano lavorando insieme e risolvendo i propri errori mentre vanno è un buon segno. L'ho fatto a metà del tuo post pensando "questi due uomini probabilmente si odiano a vicenda ..." e con mia sorpresa hai detto che vogliono continuare a lavorare insieme.

Penso che questa citazione sia appropriata dato il tuo scenario.

"If two people agree on everything, one of them is unnecessary." ~ Some Old Guy

In realtà questo mi sembra uno scenario ideale. Poi di nuovo, io sono entrambi questi sviluppatori allo stesso tempo. Mi piace disegnare la "grande immagine" sotto forma di note che alla fine trovano la loro strada in un tracker di problemi. Poi comincio a pensare ai dettagli di implementazione dal basso verso l'alto. Il quadro generale si evolve man mano che acquisisco una migliore comprensione di come i pezzi si adatteranno e i pezzi si evolvono man mano che cambiano le esigenze e ottengo nuove idee.

Forse è un buon modello per più cervelli.

Secondo me, sono profili complementari e potrebbero finire molto bene. Sia la codifica che la progettazione sono fasi necessarie della programmazione e non vuoi finire in una squadra dove nessuno vuole fare X, tutto ciò che serve è un po 'di organizzazione (vedi Posso avere un grassetto anche la parola!)

Questo può essere fatto attraverso la supervisione, come altri hanno sottolineato, ma ancora meglio, di comune accordo, su un programma di iterazione su quando progettare e quando programmare, ed evitare in generale di codificare ciò che è attualmente in fase di progettazione.

Punto bonus, non appena un progetto è suddiviso in moduli più piccoli, il programmatore top-down può progettare cose su cui il programmatore bottom-up non sta lavorando al momento, rendendola una fase in cui entrambe fanno come vogliono. Ciò implica tuttavia l'abilità di entrambi di apportare le modifiche necessarie quando arriva il momento di mettere tutto insieme.

Una nota: hai detto

Assume that you are working on a new system rather than mimicking existing ones, and thus it is not always obvious what the right end-design should look like.

Questo fa parte del problema: a meno che tu non stia lavorando su un piccolo progetto per un problema già risolto, non è in realtà un progetto finale giusto . Ci sono molti possibili progetti. Tieni presente che, a meno che tu non stia facendo questo per aumentare l'ego a causa della bellezza del tuo codice, l'obiettivo finale è un'app funzionante. Questo è tutto. Il modo in cui ci si arriva è irrilevante e il modo migliore per farli andare velocemente è farli lavorare insieme, in modo complementare.

Come altri hanno già detto, entrambe le visualizzazioni possono essere corrette in certi modi. È tutt'altro che insolito per due sviluppatori non essere d'accordo sulle pratiche, soprattutto per qualcosa di soggettivo come i processi di progettazione e di sviluppo. Qui ci sono due persone che sono appassionate di ciò che fanno e sono ben informate su come farlo: abbracciarlo!

Qui c'è un grande potenziale per consentire a entrambe le persone di lavorare a modo loro, e comunque abbinare i pezzi per ottenere un'applicazione funzionante.

1. Vorrei che i due si sedessero e discutessero, incoraggiandoli a vederlo dal punto di vista dell'altro.

2. Dopo questa discussione, puoi iniziare a parlare di pianificazione: questo dovrebbe essere fatto come una squadra, con la consapevolezza che nessuno dei due deve "concedere" all'altro, ma dovranno essere fatti dei compromessi. Esistono molti modi per pianificare l'architettura di un codebase che consenta di estenderlo piuttosto facilmente in seguito, senza introdurre una tonnellata di codice aggiuntivo.

3. Una volta che riesci a ottenere una specie di tregua, lasciali correre! Lascia che l'iniziativa "top down guy" pianifichi l'architettura di alto livello, le interfacce, le gerarchie, ecc. Lascia che il "bottom up guy" salti dentro e inizi a scrivere codice una volta che sono stati pianificati un paio di moduli. Invitali a concordare formalmente di accettare i metodi dell'altro come validi per il progetto complessivo: La pianificazione per consentire facili cambiamenti futuri è buona, ma non deve essere codificata in questo modo immediatamente. Crea interfacce e smuovi i metodi per ottenere la struttura del codice e accetta che un bel po 'del codice per il futuro non verrà effettivamente scritto fino a quando non sarà necessario.

4. Chiedi loro di rivedere insieme design e codice frequentemente. Esegui cicli attraverso i quali ti immergi in profondità in alcuni segmenti dell'architettura, pianifichi più in dettaglio e scrivi quelle parti.

5. Questo è probabilmente il punto più importante: Facilitare i punti del ciclo in cui parlano solo del processo, piuttosto che del lavoro svolto. Rifletti sulla dinamica che si sta costruendo: ci sono quattro domande che dovresti chiedere. Cosa è andato bene che dovremmo continuare a fare? Che cosa è andato male che dovremmo smettere di fare? Cosa ci manca? Cosa possiamo fare per ciò che ci manca?

Questo richiederà un po 'di lavoro: devi convincerli a concordare di lavorare insieme a modo loro. Non è facile per alcune persone ammettere che non esiste un solo modo corretto di fare le cose. L'importante non è in che modo lavori, o come appare il codice alla fine; l'importante è che queste due persone esperte e competenti imparino a lavorare meglio insieme. Non è qualcosa che puoi semplicemente dire loro; tutto ciò che puoi fare è guidarli attraverso un processo di apprendimento come farlo da soli. Proprio come non esiste un design giusto, non esiste un modo giusto per le persone di lavorare.

In generale, nella mia esperienza sulla carriera, c'è un design insufficiente . E il design che avviene in anticipo è di bassa qualità . Questo non va bene. Principalmente perché il risultato è (in misura maggiore o minore) lanciando fango al muro e vedendo cosa si attacca. Il debito tecnico viene rodato fin dall'inizio.

Il top-down è generalmente superior in basso. Anche se non escluderei del tutto dal basso verso l'alto. La ragione di questo è che dall'alto verso il basso ti costringe a pensare più a fondo al problema e a porre domande migliori . Ciò rafforza il primo punto sopra ... porta a una progettazione di qualità superiore e di solito influenza pesantemente gran parte del lavoro di livello inferiore. Ciò riduce considerevoli rilavorazioni che sono spesso altrimenti necessarie se i componenti di livello inferiore vengono creati per primi.

C'è un rischio non insignificante che, se i componenti bottom-up vengono costruiti per primi, la pressione di sviluppo cerca di plasmare i requisiti aziendali ai componenti che sono stati progettati. Anche questo è cattivo. I requisiti aziendali dovrebbero guidare la progettazione, che dovrebbe guidare l'implementazione. Qualsiasi cosa vada nella direzione opposta porterà a risultati inferiori.

Nessun approccio è sufficiente. Sembra che ognuno di loro sia intelligente o abbastanza esperto per rendersi conto delle carenze dell'approccio (forse sono stati bruciati?) Ma non riescono a vedere le carenze del proprio approccio selezionato ...

La verità è che è necessario un approccio misto:

• è quasi impossibile trovare il design "giusto" in anticipo; è necessario un certo grado di sperimentazione per identificare i punti di dolore, i colli di bottiglia, ... (suggerimento: non sono mai dove pensi che saranno)
• è quasi impossibile andare ovunque semplicemente "andando", è più probabile che finisca da qualche parte che non vuoi, o semplicemente corri in cerchio, di qualsiasi cosa

Mescolando entrambi, tuttavia, puoi:

• avere uno schizzo approssimativo che fornisce indicazioni e uno scheletro di infrastruttura
• e lo sviluppo di componenti che adattano questa visione

Poiché non esiste un sistema esistente che soddisfi questo scopo, è importante rendersi conto in anticipo che:

• sperimentazione / prototipazione sarà necessario
l'iterazione, quindi, sarà necessaria

Pertanto, si dovrebbe porre l'accento sul raggiungimento di un sistema "funzionante" il prima possibile, anche se questo significa ignorare casi d'angolo, ecc ... Questo è il concetto di "sottile fetta verticale": invece di costruire le fondamenta della casa, poi delle mura, poi della struttura del tetto, ... e solo ottenendo qualcosa di utile alla fine (o non riuscendo mai a ottenerlo, o non essere realmente utilizzabile) ... è meglio invece costruire un oggetto completamente attrezzato room prima, come il bagno. È utilizzabile immediatamente e può essere utilizzato per raccogliere feedback.

Affinché il feedback sia prezioso, tuttavia, è meglio affrontare prima una parte fondamentale.

Quindi, che ne pensi dei tuoi colleghi?

La prima cosa è che entrambi devono comprendere la necessità di collaborazione e la necessità di concordare un modo di procedere: essere costantemente rimproverati, come sono, è destinato a mettersi nei nervi e influenzare la propria motivazione. Ho presentato sopra quello che ho trovato che funziona in pratica su più progetti, puoi usarlo come suggerimento.

Quindi, devono essere d'accordo su chi fa cosa. Si noti che nell'approccio di medio livello sottolineato sopra, entrambi dovrebbero svolgere compiti che apprezzano.

Si noti che sia la costruzione degli scheletri che la costruzione dei mattoni è meglio affrontata in modo incrementale.

1. Entrambe dovrebbero ottenere uno schizzo approssimativo dello scheletro e quindi decidere insieme quale "sezione sottile" mettere a fuoco prima
2. Il ragazzo dal basso dovrebbe iniziare a lavorare sul pezzo di "fetta sottile" meglio inteso
3. Il tizio top-down dovrebbe iniziare a rimpolpare lo scheletro, affrontando idealmente i pezzi più bloccanti prima per completare la fetta

Risciacquare e ripetere finché non si ottiene il taglio della fetta; accumulare feedback lungo la strada per modificare, se necessario.

Attenzione: questo è un prototipo, entrambi devono essere pronti a buttarlo via e ricominciare da zero su un design completamente diverso.

Ciò di cui hai bisogno è un leader (o supervisore) che comprenda lo sviluppo del software e che decida qual è l'approccio da utilizzare nel progetto. Se necessario, il leader dirige agli sviluppatori di lavorare in un modo particolare, indipendentemente dalle loro preferenze personali.

The only efficient solution I can think of that doesn't waste time is to let each developer follow his/her own style for the design.

In realtà, potrebbe essere altamente inefficiente ... perché è probabile che ci saranno molti conflitti e rielaborazioni. Peggio ancora, potresti finire con un fallimento totale del progetto.