Dato un progetto e lavorando con un'altra persona - mai lavorato con qualcuno prima [chiuso]

Parte di ciò che imparerai da questo esercizio è assicurarti di avere un design buono e chiaramente comunicato con il tuo compagno di squadra.

Lavorando da solo, potresti "sfilarlo" in una certa misura, inventandoti un po 'di "design" ma poi cambiandolo a piacimento, dal momento che influenzerà solo il tuo lavoro.

Lavorare in un team (2 o più persone) significa che dovresti lavorare insieme per progettare correttamente ciò che stai scrivendo, e assicurarti che le tue "interfacce" o i tuoi contratti siano definiti correttamente. Inserisco le "interfacce" tra virgolette, poiché potrebbero non essere interfacce OO corrette, a seconda della lingua che si sta utilizzando. (A scuola, è una buona idea lavorare insieme sul design, mentre nel mondo reale spesso sarà una persona a fare il disegno e ad assegnare moduli al team)

Una volta che hai progettato questo progetto, ogni persona nel team può quindi sviluppare una parte dell'intero sistema (una classe, o un'area discreta di funzionalità), e fintanto che programmano all'interfaccia / contratto concordato i moduli dell'applicazione dovrebbero inserirsi insieme.

Un approccio che potreste desiderare di utilizzare è l'approccio di sviluppo basato sulle caratteristiche, il che significa che 1 sviluppatore è responsabile di un'intera funzionalità dell'intera applicazione e, a condizione che sia integrato nell'applicazione "core" che ha incollato l'intero insieme, erano più o meno liberi di svilupparlo come meglio credevano. (Questo rende anche più facile per i docenti di segnarlo, dal momento che possono vedere chiaramente quale studente ha scritto quale pezzo)

NB Sebbene io sia un grande fan della programmazione pair e lo usi regolarmente nel mio lavoro quotidiano, non sono sicuro di essere d'accordo sul fatto che sarebbe di beneficio in questo situazione, dal momento che è troppo facile per uno sviluppatore solo "spegnere" lo sviluppo. Questo è qualcosa che di solito raccomando solo per un pezzo di codice complesso, che può beneficiare di diverse coppie di occhi per avere ragione.

Dato che è scuola / università, probabilmente starai meglio con la programmazione delle coppie. Sarai in grado di correggere e imparare gli uni dagli altri.

link

Jean-Paul Sartre nel suo film No Exit, famoso ha detto: "L'inferno sono altre persone". Certo, per tutti su questo pianeta, tranne te, sei altre persone, quindi c'è molto su cui lavorare.

I progetti di gruppo a scuola e sul posto di lavoro possono essere pieni di sfide. Ci sono alcuni strumenti utili che puoi usare:

• Inizia presto.
• Crea degli obiettivi per te stesso su ciò che vorresti imparare e fare sul progetto.
• Dedica più tempo che ti aspetti di selezionare i partner.
• Mantieni la tua squadra piccola.
• Comprendi le tue differenze.
• Cerca persone con punti di forza complementari, idee contrastanti, background diversi.
• Comprendi e gestisci le dinamiche di gruppo.
• Comprendi gli stili di comunicazione e di pensiero (esterno - parla attraverso, interno - pianificalo, scrivilo)
• Scegli qualcuno che sia ugualmente serio riguardo alla classe o al progetto come te.
• Lavorare con persone che hanno una pianificazione compatibile.
• Crea una comprensione condivisa di ciò che il professore (o il manager o il maestra di misericordia) si aspetta.
• Comunicare frequentemente.
• Cerca di creare un partenariato equo.
• Non cavilli su chi sta lavorando o sta ottenendo di più.
• Sii attento e accomodante.
• Mostra apprezzamento presto e spesso.
• Sii felice e positivo nel collaborare anche in caso di problemi.
• Aspettatevi giorni difficili, quindi usate giornate facili per costruire rapporti di lavoro.
• Morditi la lingua se sei tentato di dire cose come "Ti odio, non lavorerei mai più con te" perché dopo che ciò accadrà, tutto diventerà più difficile e non avrai l'amica della carriera che dovresti fare in collegio. La nostra attività non è così ampia che non faremo né accetteremo domande di lavoro a / da quella persona successivamente, in particolare dall'avvento di Linked In.
• Se il tuo partner è bloccato, fornisci aiuto.
• Se sei bloccato, chiedi aiuto.
• Utilizza gli strumenti di collaborazione.
• Sii il più consapevole possibile del lavoro che gli altri stanno facendo. Il tuo interesse è motivare l'altra persona.
• La revisione reciproca funziona a vicenda. Consiglia, ma evita le critiche personali, permanenti o pervasive ("rovini sempre tutto" non è utile).
• Comprendi ciò che costituisce un plagio e prendi provvedimenti per assicurare che il tuo lavoro e il lavoro degli altri membri della tua squadra siano originali e attribuisca correttamente il lavoro degli altri.
• Goditi il lavoro.
• Capisci cosa ha funzionato e cosa no.
• Condividi il merito del successo, ma non recriminare se le cose non soddisfano le aspettative.

Is the goal to divide the work up and decides who does what or should one person code and the other person reviews and switch roles after a while?

A meno che il tuo istruttore non ti abbia detto esplicitamente come condividere l'attività, spetta a te e al tuo partner decidere. Quindi inizierei a discuterne con lui / lei. Ciò include una valutazione approssimativa delle tue qualità e abilità - niente di male, solo per vedere se sei più o meno sullo stesso livello, o uno di voi è più abile / esperto in qualche aspetto del lavoro . Ciò influenza in maniera abbastanza strong le tue opzioni.

Se voi due siete all'incirca allo stesso livello, probabilmente il migliore è tentare di risolvere almeno i compiti più fondamentali - mettere a punto un progetto approssimativo e implementare un'applicazione scheletrica in codice - insieme. è necessario realizzare un design perfetto e brillante - ci vuole molta esperienza per riuscirci. È meglio provare a inventare idee, discutere su come il programma potrebbe funzionare nel modo previsto e, in caso di dubbio, scrivere codice per verificare le tue idee. Il risultato è uno skeleton , contenente tutte le parti principali del programma e capace di alcune funzionalità molto semplici per dimostrare che il sistema funziona fino in fondo. Per esempio. lo scheletro di un elaboratore di testi sarebbe in grado di aprire un file molto semplice, visualizzarlo in una finestra dell'editor, quindi salvarlo. Un server Web scheletro sarebbe in grado di rispondere alla richiesta GET HTTP più semplice inviando una risposta "200 OK" con alcuni contenuti codificati. Ecc ecc.

Una volta che sei pronto con questo, puoi iniziare a dividere le attività tra voi due se lo preferite. In effetti, il secondo obiettivo principale della creazione dello scheletro è consentire a più persone di lavorare sul codice in parallelo. Il che implica che mettere tutto in un unico file di codice sorgente non è la migliore idea qui; -)

Una nota (probabilmente ovvia): se non hai mai utilizzato un sistema di controllo versione, ora è il momento di iniziare a usarne uno.

Se, OTOH, uno di voi è notevolmente più abile / interessato ad alcune aree, potrebbe essere ovvio dare un compito a lui / lei correlato. L'altro potrebbe voler guardare e seguire comunque, o per ottenere una presentazione in seguito, per imparare anche quell'abilità. In un secondo momento, quando entrambi conoscete già le basi del lavoro di squadra e risolvendo i problemi, potreste scegliere di fare il contrario, lasciando che il minore esperto faccia un compito specifico per pareggiare il vostro skillset.

* Nota a margine: questo processo può includere o meno la programmazione delle coppie. Se entrambi siete aperti all'idea della programmazione di coppie, perché non provarci. Tuttavia, assicurati di lavorare davvero insieme, con entrambi i partecipanti e i ruoli di commutazione frequenti. Se uno di voi sta dominando e l'altro sta solo cercando di rimanere sveglio, questo non aiuta nessuno di voi e dà solo una brutta esperienza.

Quindi, se non ti piace l'idea della programmazione della coppia, e / o hai qualche brutta esperienza (come sembri aver menzionato nel tuo post), e / o ritieni che sarebbe una cosa troppo da imparare a questo punto, puoi lasciarlo fuori. Hai ancora bisogno di molta collaborazione tra di voi, quindi assicuratevi di incontrare, discutere e condividere i vostri risultati frequentemente.