Programmazione con un gruppo di persone che non ho mai incontrato

Mi è stato assegnato un progetto di gruppo dal mio corso di informatica in AP e mi viene richiesto di lavorare con altre tre persone. Non ho mai parlato con loro prima, non ho idea del loro livello di abilità e tutto ciò che ho è il loro indirizzo e-mail. Il compito, riassunto, è questo:

"Come squadra completerai un minimo di tre moduli per una classe ...."

Proverò a diventare "Capitano della squadra" perché nessuno di loro ha tentato di contattarsi ma sono curioso: come procedere? Li ho inviati per e-mail e ho chiesto loro se ci sono metodi di comunicazione che preferiscono piuttosto che mandarli via e-mail, ma una volta che avremo effettivamente avviato il progetto dovrò capire chi sta facendo cosa.

Cosa dovrei fare? Come posso "prendere in carico" e guidare tre persone che non ho mai incontrato?

Ecco un estratto del compito effettivo:

Pertanto dovrai discutere i vari ruoli che ciascun membro del team assumerà in questo progetto all'inizio della settimana. Puoi comunicare tramite Pronto (o IM della lavagna), e-mail, wiki, gruppo Google, blog o qualsiasi altro metodo che ritieni opportuno. Se un membro del gruppo non coinvolge il gruppo entro la fine della settimana, informa il tuo istruttore e forniranno ulteriori indicazioni.
...
Alla fine di un progetto sarà inoltre prevista una valutazione del team in cui valuterai il contributo di ciascun membro del team al completamento di questo progetto insieme a un voto suggerito.

Modifica: molte persone mi hanno suggerito di incontrarli in un bar o qualcosa del genere. L'unico problema è che tutti noi siamo in stati diversi. Ho anche capito che uno di loro non è autorizzato a utilizzare Facebook / Skype / Twitter, quindi devo ricorrere a messaggiarli su Yahoo Messenger ed e-mail.

Il leader di questo progetto sarà la persona che si farà avanti e si farà carico all'inizio.

Questo vale per la maggior parte delle cose nella vita, non solo per lo sviluppo di software. Quando tutti gli altri corrono in giro come galline senza testa, la persona che ci pensa, fa un passo avanti e dice: " Questo è ciò che faremo e questo è il modo in cui lo faremo ". è di solito la persona considerata il leader per il resto del progetto. Tieni presente che facendo questo ti stai assumendo la responsabilità del successo o dell'insuccesso finale del progetto.

Vuoi guidare questo progetto? Ecco un paio di cose che puoi iniziare a fare subito per avere un grande impatto.

1. Utilizza uno strumento di gestione del progetto come Trello e invia inviti a tutti e inizia ad assegnare parti del progetto alle persone.
2. Generare un database di bug e iniziare ad aggiungere attività e bug - di nuovo, basta iniziare ad assegnare.
3. Configurare un repository di controllo versione e archiviare una buona porzione iniziale di codice da cui tutti possano lavorare. Rifiuta di trattare qualsiasi altra forma di controllo del codice.
4. Offri aiuto alle persone nello sviluppo, mostrando loro come usare il sistema di controllo della versione e il database dei bug.
5. Invia e-mail settimanali che descrivono lo stato del progetto e lo stato di avanzamento della settimana precedente.

Nessuno di questi passaggi è particolarmente difficile o richiede tempo, ma sarà un enorme risparmio di tempo lungo la strada. Inoltre, farà parlare la tua squadra tra loro e li abituerà a vederti al comando.

La risposta di Jarrod Nettles riassume praticamente molto ciò che stavo per suggerire, quindi aggiungerò parte di ciò che ha funzionato nelle mie recenti esperienze in una situazione simile.

Suggerirei di trovare un modo per parlare con loro vocalmente, piuttosto che via e-mail. Se non sei nella stessa area, procurali tutti su Skype. Se ti trovi in ​​zona, incontrali in un bar o qualcosa del genere. Parlare di persona durante le riunioni iniziali ti porterà a prendere decisioni e a svolgere il lavoro in quel momento; le discussioni via e-mail consentono a coloro che sono timidi o che spesso non sono al computer di bloccare il processo - sappiamo tutti quanto possono essere pigri gli studenti!

Nel tuo primo incontro, proverei a conoscere il tuo gruppo cercando di andare avanti con il progetto, ma non ignorare il progetto! 10 o 20 minuti spesi per rompere il ghiaccio sono probabilmente sufficienti tra 4 persone.

Quando si tratta di parlare del progetto, suggerirei di esaminare ciò che pensi coinvolga il progetto. Penso che sia importante chiarire che questa è la tua comprensione, e non un caso in cui dici loro esattamente cosa fare. Tutti dovrebbero essere in grado di gettare i loro pensieri e idee sul ring, se ne hanno, e dovresti allontanarti da quell'incontro iniziale con una comprensione abbastanza decente di ciò che tu, come gruppo, senti che il progetto comporta.

In future riunioni (regolari), puoi iniziare a esaminare diverse parti del progetto in modo più dettagliato; guarda cosa deve fare esattamente, quali risorse e quanto tempo sarà necessario e chi può fare cosa. Dividi ulteriormente il pezzo, se necessario. Forse prova a fissare delle scadenze morbide?

Qualcuno di voi ha esperienza nel lavorare con un gruppo di persone che non ha mai incontrato online e non è possibile incontrarli di persona ma è necessario completare un progetto insieme?

Aggiungi scadenze ridicole e ridicolissime e venditi lungo il fiume attraverso il marketing e questo suona come circa il 65% dei progetti di sviluppo software nel mondo reale.

Probabilmente saresti meglio servito convincendo la gente a fare volontariato per le parti che sarebbero interessate a fare piuttosto che assumersi la responsabilità unilaterale e assegnare compiti. Probabilmente sono tutti seduti lì a pensare a come dovrebbero farsi carico. O come possono ottenere una povera zolla che si preoccupa troppo di fare tutto il lavoro di gruppo in modo che possano cavalcare in classe.

La prima cosa da fare in casi come questo è stabilire un tracker di problemi e imparare come usarlo.

Per un'introduzione più fondamentale su come gestire lo sviluppo come descritto, il mio riferimento preferito vale per l'articolo di Martin Fowler sull'utilizzo di un processo software agile con sviluppo offshore . Questo articolo descrive le basi e i concetti avanzati di impostazione della comunicazione distribuita tra i team:

Use Continuous Integration to Avoid Integration Headaches
Have Each Site Send Ambassadors to the Other Sites
Use Contact Visits to build trust
Don't Underestimate the Culture Change
Use wikis to contain common information
Use Test Scripts to Help Understand the Requirements
Use Regular Builds to Get Feedback on Functionality
Use Regular Short Status Meetings
Use Short Iterations
Use an Iteration Planning Meeting that's Tailored for Remote Sites
When Moving a Code Base, Bug Fixing Makes a Good Start
Separate teams by functionality not activity
Expect to need more documents.
Get multiple communication modes working early

Per il tuo progetto sicuramente non sarai in grado di seguire tutti i suggerimenti e i trucchi qui menzionati (ad esempio, probabilmente non ci saranno ambasciatori né visite di contatto per te :) ma vale comunque la pena studiare.

• Per molte squadre avere tutto quanto sopra sarebbe sicuramente eccessivo. Tuttavia, trovo davvero utile avere una lista di controllo completa come quella - in modo che anche gli articoli saltati siano controllati e abbiano chiaramente documentato i motivi del rifiuto - solo per assicurarsi che non sia mancato nulla di importante.

Non ci hai detto quanto tempo hai per questo o la lingua in cui stai lavorando (direi che una singola classe è molto piccola, ma forse nella tua lingua è molto di più).

Prima di tutto, avere un prodotto funzionante ad ogni costo.

Se il progetto dura due settimane o meno, supponi che sarai l'unico a fare qualsiasi cosa ed essere molto contento di qualsiasi aiuto tu ottenga. Cerca di pianificare le cose per tutti, ma assicurati che se nessuno fa qualcosa, avrai comunque un prodotto funzionante. Anche se qualcuno fa qualcosa, non fare affidamento sul fatto che continui: sii pronto a lasciare qualcuno in qualsiasi momento.

Se hai più di una settimana, considera la pianificazione di un giorno della settimana in cui il prodotto deve essere contrassegnato come pietra miliare e attenersi a quello il più possibile. Assicurati di avere qualcosa su cui puoi muoverti e controlla le carenze di: se il peggio dovesse peggiorare, questo sarà ciò che consegnerai. Ognuno di essi creerà, vedrai quanto potresti migliorare le cose, che ti motiveranno ad andare sopra. Non pianificare troppo in avanti: certo, devi avere un'idea di ciò che finirai, ma mantieni i tuoi piani più specifici a breve termine.

Si noti che quei due si sovrappongono un po ': questo è intenzionale, poiché due settimane sono a mio avviso un po' di un'area grigia in cui è difficile eseguire due iterazioni, ma lavorare in un'unica iterazione è rischioso.

Sto assumendo il caso peggiore, in cui lavorerai con persone molto nuove nella programmazione. Il mio consiglio generale sarebbe:

• Tieni un elenco di funzionalità che desideri implementare presto e chi lavorerà su di esse. Jarrod ha suggerito Trello, e io lo sostengo del tutto: se i tuoi compagni di squadra non sono molto esperti, sarà di grande aiuto. Potresti provare a tenere lì anche i bug.
• In una squadra di quattro, è necessario il controllo della versione. Potrebbe rendere gli altri più riluttanti a contribuire se non sanno come farlo, ma ne vale la pena.
• Eventuali dipendenze esterne possono spaventare i neofiti. Se scrivi unit test, dì alla gente che non dovrebbero preoccuparsi di romperli. Di 'alla gente che non dovrebbero preoccuparsi di rompere la build, specialmente all'inizio. È molto più difficile correggere le persone che non commettono alcun codice rispetto a quelle che commettono codice errato.
• Controlla se le cose suggerite qui si applicano davvero a te. "Integrazione continua" è un termine sofisticato - per un piccolo programma, ciò potrebbe significare "questo programma funziona e tutte le funzionalità possono essere utilizzate". Hai anche dei siti? La divisione in squadre ti aiuta?
• YAGNI, cento volte. Se proprio devi, scrivi le cose in anticipo per le funzionalità che ti creerai. Fallo funzionare, quindi rifattorizza, altrimenti non riuscirai a farlo funzionare.
• Refactor. Una volta che funziona, dedica un po 'di tempo a ripararlo. Non dimenticare che anche i tuoi compagni di squadra dovranno leggere il tuo codice: una giornata trascorsa a riparare pezzi brutti e sostituire soluzioni semplici con soluzioni più performanti non è un giorno perso.
• Tieni d'occhio tutte le parti. Scorrere i log delle modifiche e, occasionalmente, leggere il codice degli altri aiuta a garantire che tutto sia all'altezza degli standard di qualità che ritieni di dover applicare e che non sia così difficile immergersi se la persona abbandona.
• Non esitare a lavorare sulla cosa più importante, al contrario della cosa designata. Se qualcuno è in ritardo, prendine nota da qualche parte e fallo da solo. Chiedi prima a loro, ma vai avanti se non rispondono o se chiedi una o due volte e poi senti che non lo faranno ancora.
• Concentrati sul creare qualcosa di cui sei orgoglioso. Anche se si discosta dall'incarico. Anche se devi tagliare grandi funzionalità a favore di rendere più fluido ciò che hai. Ogni iterazione pensa "Sono orgoglioso di questo?" E nella prossima iterazione, prova a sistemare queste cose.

Ho avuto un progetto fallito orribilmente di recente; puoi leggere i miei pensieri sul perché non è riuscito se lo desideri, ma questo riassume come farei una cosa del genere se avessi un'altra possibilità.

La risposta di Jarrod Nettles è buona. Vorrei aggiungere questo:

1. Aspettati che almeno una delle altre tre persone sarà completamente inutile.
2. Accetta solo che ti sentirai come se stessi svolgendo la maggior parte (o tutto) del lavoro, ma tutti otterranno lo stesso credito. Qualsiasi tentativo di cercare di rendere le cose "giuste" provocherà solo conflitti inutili e ti rallenterà.
3. Rimani in contatto con tutti i membri del team che sono bravi. Queste persone sono difficili da trovare e vorrai lavorare di nuovo con loro.

Sono stato in una posizione simile alcune volte perché sono sicuro che ci sono molte persone. La cosa principale però è fare del tuo meglio per mantenere tutti contenti e felici, quindi penso sia positivo che tu voglia assumere il compito di capo squadra, comunque come qualcuno sopra menzionato - questo deve essere affrontato attentamente come qualcun altro potrebbe pensare che dovrebbero invece fare il lavoro.

So che hai detto che nessuno si è preso la briga di contattarsi, ma a volte queste situazioni possono essere difficili per le persone, come hai detto che stai lavorando con persone che non hai mai incontrato e può essere difficile comunicare ecc.

Vorrei iniziare con un'email indirizzata a tutti e facendoli sapere chi pensi come dovrebbe essere affrontato il progetto e facendo sapere che vuoi guidare il progetto assumendoti la responsabilità di stabilire ruoli, obiettivi, scadenze, tempi di comunicazione, incontri ( se desiderato / desiderato) e aggiornamenti del progetto.

Anche se non puoi influenzare completamente le altre persone, puoi tenere traccia di chi sta facendo cosa e chi non lo è. La delega dei lavori consente di suddividere il lavoro in modo uniforme o appropriato per le persone con competenze o livelli diversi.

In questo modo, se non viene svolto un determinato lavoro, puoi assumerti la responsabilità di dividere il lavoro tra le persone che sono realmente interessate a lavorarci. In questo modo non finirai con un progetto fallito alla fine e avrai le registrazioni del tentativo di comunicare date, orari e tutte le informazioni rilevanti che puoi mostrare alla fine se le cose vanno male. Tutte le cose che ti mantengono nel giusto se alcune persone non tirano il loro peso.

In termini di suggerimenti:

Personalmente adoro un ambiente di lavoro collaborativo trovato qui: https://docs.google.com/

Ciò consente di condividere documenti di Word, fogli di calcolo ecc. È un ottimo modo di lavorare in collaborazione. Non posso sottolineare quanto sia utile a volte. Lo uso con alcune persone con cui lavoro, che al momento non sono nel paese.

Spero che questo abbia aiutato qualcuno, ci sono così tanti aspetti della conduzione di un progetto che potremmo continuare per sempre, ma dipende solo da così tante cose. Almeno questo è un piccolo aiuto.