Come far fronte a diversi stili di sviluppo (top-down vs. bottom-up) in un team?

Supponiamo che tu abbia appena iniziato a lavorare in un team molto piccolo su un progetto {attualmente relativamente piccolo, anche se si spera più grande in seguito}. Si noti che questo è un progetto reale destinato ad essere utilizzato da altri sviluppatori nel mondo reale, non da un progetto accademico che dovrebbe essere demolito alla fine di un semestre.
Tuttavia, il codice non è ancora stato rilasciato ad altri, quindi nessuna decisione è ancora stata presa sulla pietra.

Le metodologie

A uno di voi piace iniziare a programmare e adattare i pezzi insieme man mano che si procede prima di avere necessariamente una chiara idea di come interagiranno esattamente tutti i componenti (design dal basso). Ad un altro di voi piace fare prima l'intero progetto e inchiodare i dettagli di tutti i componenti e la comunicazione prima di codificare una soluzione.

Supponiamo che tu stia lavorando su un nuovo sistema piuttosto che imitare quelli esistenti, e quindi non è sempre ovvio come dovrebbe essere il giusto design finale. Quindi, nel tuo team, diversi membri del team a volte hanno idee diverse su quali requisiti sono persino necessari per il prodotto finale, per non parlare di come progettarlo.

Quando lo sviluppatore bottom-up scrive del codice, lo sviluppatore top-down lo rifiuta a causa di potenziali problemi futuri previsti nella progettazione nonostante il fatto che il codice possa risolvere il problema a portata di mano, ritenendo che sia più importante ottenere la progettazione corretta prima di tentare di codificare la soluzione al problema.

Quando lo sviluppatore top-down tenta di elaborare l'intero progetto e i problemi previsti prima di iniziare a scrivere il codice, lo sviluppatore bottom-up lo rifiuta perché lo sviluppatore bottom-up non pensa che alcuni dei problemi insorgeranno effettivamente nella pratica e ritiene che il progetto potrebbe dover essere modificato in futuro quando i requisiti e i vincoli diventano più chiari.

Il problema

Il problema che ciò ha comportato è che lo sviluppatore bottom-up finisce per perdere tempo perché lo sviluppatore top-down spesso decide la soluzione che lo sviluppatore bottom-up ha scritto dovrebbe essere scartato a causa di un difetto di progettazione, con conseguente necessità di ri -scrivi il codice.

Lo sviluppatore top-down finisce per perdere tempo perché invece di parallelizzare il lavoro, lo sviluppatore top-down ora si siede spesso per elaborare il progetto corretto con lo sviluppatore bottom-up, serializzando i due al punto in cui potrebbe persino essere più veloce per 1 persona di svolgere il lavoro rispetto a 2.

Entrambi gli sviluppatori vogliono continuare a lavorare insieme, ma non sembra che la combinazione stia effettivamente aiutando nessuno dei due nella pratica.

Gli obiettivi

Gli obiettivi comuni sono ovviamente massimizzare l'efficacia della codifica (ovvero ridurre al minimo lo spreco di tempo) e scrivere software utile.

La domanda

In parole povere, come risolvere questo problema e far fronte a questa situazione?

L'unica soluzione efficiente a cui riesco a pensare che non perda tempo è lasciare che ogni sviluppatore segua il proprio stile per il design. Ma questo è più difficile di quanto sembri quando si rivede il codice e in realtà è necessario approvare le modifiche reciproche e quando si sta tentando di progettare un framework coerente che gli altri possano utilizzare.

Esiste un modo migliore?

Ovviamente si sbagliano entrambi.

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

Il ragazzo dall'alto in basso può dedicare altrettanto tempo alla visione architettonica e non fare nulla di produttivo.

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

A proposito, si chiama Agile (non la versione BS di agile che alcune persone praticano laddove le procedure sono più importanti del software funzionante) ma vera agile che va avanti lavorando verso un obiettivo finale comunemente descritto e compreso.

Per risolvere il problema qui, prova un approccio Agile (Kanban è probabilmente il migliore) che costringerà entrambi il ragazzo dall'alto in basso a fare un po 'di lavoro e costringerà il ragazzo dal basso a fare pianificazione su ciò che sta cercando di ottenere.

I due sviluppatori devono mantenersi reciprocamente rispettosi .

La persona dall'alto verso il basso deve rispettare il fatto che la persona dal basso verso l'alto potrebbe aver escogitato qualcosa che effettivamente funziona. Come mi disse uno dei miei professori "quant", "Un modello funzionante vale 1000 ipotesi". In tal caso, la persona dall'alto in basso dovrebbe considerare di ripetere il suo "progetto" per adattarsi al lavoro della persona dal basso verso l'alto.

La persona dal basso verso l'alto dovrebbe anche rispettare il "quadro" della persona dall'alto verso il basso e rendersi conto che può essere utile per evitare sforzi sprecati, risolvere il problema sbagliato, ottenere fuori tema, ecc. Il programmatore dal basso verso l'alto dovrebbe almeno tenere a mente cosa la persona dall'alto in basso sta provando a fare, e cerca di rispondere almeno alle preoccupazioni del primo downer, come espresso nel quadro. Ciò sarebbe vero anche se la parte inferiore inferiore non fosse d'accordo con parti del quadro stesso.

È possibile ridurre al minimo la perdita di tempo impiegata da ogni sviluppatore se si suddividono attività di grandi dimensioni in più attività più piccole e mirate. Falli lavorare a stretto contatto in modo che nessuno dei due si avvicini troppo all'altro. Brevi sprint e piccoli risultati finali fanno molto. È più facile correggere un piccolo errore che uno grande.

Potrebbe sembrare contro intuitivo al tuo obiettivo, ma la programmazione della coppia funziona. Ci sono cose che non ti accorgerai subito, a volte per ore o addirittura giorni. Se lavorare direttamente sulle attività insieme è fuori discussione, prova a rivedere il codice / standup più frequentemente durante la settimana.

Tieni tutti informati!

Se vedi che gli sviluppatori scaricano codice perché erano nel loro stesso mondo, devi catturare e riconciliare i conflitti nel modo più rapido ed efficiente possibile. Il tuo capo lo apprezzerà e il team apprezzerà di non dover buttare via una settimana di lavoro perché non sapeva cosa stesse facendo l'altro ragazzo.

Dovresti anche vederli lavorare insieme come una benedizione. Il fatto che stiano lavorando insieme e correggano i loro errori mentre vanno è un buon segno. Sono arrivato a metà del tuo post pensando "amico, questi due probabilmente si odiano l'un l'altro ..." e con mia sorpresa hai detto che vogliono continuare a lavorare insieme.

Penso che questa citazione sia appropriata dato il tuo scenario.

"Se due persone sono d'accordo su tutto, uno di questi non è necessario." ~ Qualche vecchio ragazzo

Questo in realtà sembra uno scenario ideale per me. Poi di nuovo, sono entrambi quegli sviluppatori allo stesso tempo. Mi piace redigere il "quadro generale" sotto forma di note che alla fine trovano la loro strada in un tracker di problemi. Quindi inizio a pensare ai dettagli dell'implementazione dal basso verso l'alto. Il quadro generale si evolve man mano che acquisisco una migliore comprensione di come i pezzi si adatteranno insieme e i pezzi si evolvono man mano che i requisiti cambiano e ricevo nuove idee.

Forse è un buon modello per cervelli multipli.

Secondo me, sono profili complementari e possono finire molto bene. Sia la programmazione che la progettazione sono fasi necessarie della programmazione e non vuoi finire in un team in cui nessuno vuole fare X, tutto ciò di cui hai bisogno è un po 'di organizzazione (vedi che posso avere anche una parola in grassetto!)

Questo può essere fatto attraverso la supervisione come altri hanno sottolineato, ma ancora meglio fatto di comune accordo su un programma di iterazioni su quando progettare e quando codificare, ed evitando 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 attualmente lavorando, rendendolo una fase in cui entrambi fanno come vogliono. Ciò implica tuttavia la capacità di entrambi di apportare le modifiche necessarie quando arriva il momento di mettere tutto insieme.

Una nota: hai detto

Supponiamo che tu stia lavorando su un nuovo sistema piuttosto che imitare quelli esistenti, e quindi non è sempre ovvio come dovrebbe essere il giusto design finale.

Questo è parte del problema: a meno che tu non stia lavorando a un piccolo progetto per un problema già risolto, in realtà non esiste un progetto giusto . Ci sono molti possibili progetti. Tieni presente che, a meno che tu non lo stia facendo per aumentare l'ego grazie alla 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 far andare veloci questi due è farli lavorare insieme, in modo complementare.

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

C'è un grande potenziale qui per consentire a entrambe le persone di lavorare a modo loro, e allo stesso tempo abbinare i pezzi per ottenere un'applicazione funzionante.

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

2. Dopo quella 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 i compromessi dovranno essere fatti. Esistono molti modi per pianificare l'architettura per una base di codice che consente di estenderla piuttosto facilmente in seguito, senza introdurre una tonnellata di codice aggiuntivo.

3. Una volta che riesci a farli venire a una specie di tregua, lasciali correre selvaggi! Lascia che l'unità "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 previsti un paio di moduli. Fai in modo che accettino formalmente di accettare i metodi dell'altro come validi per l'intero progetto: pianificare per consentire facili cambiamenti futuri è buono, ma non è necessario codificarlo immediatamente. Creare interfacce e stub metodi per ottenere la struttura del codice e accettare che una buona parte del codice per il futuro non verrà effettivamente scritta fino a quando non sarà necessaria.

4. Invitali a rivedere sia il design che il codice frequentemente, insieme. Scorrere i cicli in cui ti immergi in profondità in alcuni segmenti dell'architettura, pianifica in modo più dettagliato e scrivi quelle parti.

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

Ci vorrà un po 'di lavoro: devi farli accettare di lavorare insieme a modo loro. Per alcune persone non è facile ammettere che non esiste un solo modo corretto di fare le cose. L'importante non è il modo in cui lavori o l'aspetto del 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 su come farlo da soli. Proprio come non esiste un design giusto, non esiste un modo giusto per far lavorare le persone.

In generale, nella mia esperienza sulla mia carriera, non c'è un design sufficiente all'inizio . E il design che accade davanti è di bassa qualità . Questo non va bene. Soprattutto perché il risultato è (in misura maggiore o minore) lanciare fango contro il muro e vedere cosa si attacca. Il debito tecnico si fa sentire fin dall'inizio.

Il top-down è generalmente superiore al bottom-up. Anche se non escluderei del tutto dal basso verso l'alto. La ragione di ciò è che il top-down ti costringe a pensare al problema in modo più ampio e a porre domande migliori . Ciò rafforza il primo punto sopra ... porta a un design 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 costruiti per primi.

Esiste un rischio non trascurabile che se i componenti bottom-up vengono costruiti per primi, la pressione di sviluppo cerca di modellare i requisiti aziendali per i componenti che sono stati progettati. Anche questo è male. I requisiti aziendali dovrebbero guidare la progettazione, che dovrebbe guidare l'implementazione. Qualunque cosa che vada dall'altra parte porterà a risultati inferiori.

Nessuno dei due approcci è sufficiente. Sembra che ognuno di loro sia abbastanza intelligente o abbastanza esperto da realizzare le carenze dell'altro approccio (forse sono stato bruciato?) Ma non riescono a vedere le carenze del loro approccio selezionato ...

La verità è che è necessario un approccio misto:

• è quasi impossibile trovare in anticipo il design "giusto"; è 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 in un posto che non volevi, o semplicemente corri in cerchio, di qualsiasi altra cosa

Mescolando entrambi, tuttavia, puoi:

• hanno uno schizzo approssimativo che fornisce indicazioni e uno scheletro di infrastruttura
• e lo sviluppo di componenti adatti a questa visione

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

• sarà necessaria la sperimentazione / prototipazione
• sarà pertanto necessaria l'iterazione

Pertanto, si dovrebbe porre l'accento sul raggiungimento di un sistema "funzionante" il più presto possibile, anche se ciò significa ignorare i casi angolari, ecc ... Questo è il concetto di "fetta verticale sottile": invece di costruire le basi della casa , poi i muri, poi la struttura del tetto, ... e ottenendo solo qualcosa di utilizzabile alla fine (o mai ottenendolo, o che non sia realmente utilizzabile) ... è meglio invece costruire prima una stanza completamente attrezzata , come il bagno. È immediatamente utilizzabile e può essere utilizzato per raccogliere feedback.

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

Quindi, cosa fanno con i tuoi colleghi?

La prima cosa è che entrambi devono capire la necessità della collaborazione e la necessità di concordare una via da seguire: essere costantemente rimproverati, così come sono, è tenuto a innervosirsi e influenzare la motivazione. Ho presentato sopra quello che ho scoperto che funziona bene in pratica su più progetti, puoi usarlo come suggerimento.

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

Si noti che sia la costruzione degli scheletri che la costruzione dei mattoni sono meglio affrontate in modo incrementale.

1. Entrambi dovrebbero ottenere uno schizzo approssimativo dello scheletro e quindi decidere insieme su quale "fetta sottile" concentrarsi per prima
2. Il ragazzo dal basso dovrebbe iniziare a lavorare sul pezzo meglio compreso di "fetta sottile"
3. Il ragazzo dall'alto verso il basso dovrebbe iniziare a riempire lo scheletro, affrontando idealmente prima i pezzi più bloccanti per completare la fetta

Risciacquare e ripetere fino a quando la fetta non funziona; accumulare feedback lungo la strada per modificare, se necessario.

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

Ciò di cui hai bisogno è un leader (o supervisore) che comprenda lo sviluppo del software e che decida su quale approccio deve essere utilizzato nel progetto. Se necessario, il leader dirige gli sviluppatori a lavorare in un modo particolare, indipendentemente dalle loro preferenze personali.

L'unica soluzione efficiente a cui riesco a pensare che non perda tempo è lasciare che ogni sviluppatore segua il proprio stile per il design.

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