Programmazione con un gruppo di persone che non ho mai incontrato

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

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

Vuoi guidare questo progetto? Ecco un paio di cose che puoi iniziare subito a fare 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. Genera un database dei bug e inizia ad aggiungere attività e bug - di nuovo, inizia ad assegnare.
3. Configura un archivio di controllo versioni e archivia una buona porzione iniziale di codice da cui tutti possono lavorare. Rifiuta di trattare qualsiasi altra forma di controllo del codice.
4. Offerta per aiutare le persone ad andare avanti con lo sviluppo mostrando loro come utilizzare il sistema di controllo delle versioni e il database dei bug.
5. Invia email settimanali che specificano lo stato del progetto e i progressi della settimana precedente.

Nessuno di questi passaggi è particolarmente difficile o richiede molto tempo, ma sarà enorme risparmio di tempo in futuro. Inoltre, farà parlare la tua squadra e ti abituerà a vederti al comando.

La risposta di Jarrod Nettles riassume molto ciò che stavo per suggerire, quindi aggiungerò alcune delle cose che hanno funzionato nelle mie recenti esperienze in una situazione simile.

Suggerirei di trovare un modo per parlare con loro a voce, piuttosto che via email. Se non sei nella stessa zona, prendili tutti su Skype. Se sei in zona, incontrali in un bar o qualcosa del genere. Parlare di persona nelle riunioni iniziali ti porterà a prendere decisioni e a fare il lavoro lì e là; le discussioni via email consentono a coloro che sono timidi o spesso non al computer di sostenere il processo - sappiamo tutti quanto possono essere pigri gli studenti!

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

Quando parliamo del progetto, suggerirei di descrivere ciò che tu pensa che il progetto implichi. Penso che sia importante chiarire che questa è la tua comprensione, e non il caso che tu dica loro esattamente cosa fare. Tutti dovrebbero essere in grado di lanciare i propri pensieri e idee sul ring se ne hanno, e dovresti uscire da quell'incontro iniziale con una comprensione abbastanza decente di ciò che tu, come gruppo, senti che il progetto comporta.

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

Do any of you have experience with working with a group of people you've never met online, and you don't get to meet them in person but must complete a project together?

Aggiungete contenuti scadenti, scadenze ridicole e vendute lungo il fiume attraverso il marketing e questo suona come circa il 65% dei progetti di sviluppo software nel mondo reale.

Probabilmente ti sarebbe servito meglio convincere la gente a fare volontariato per le parti che sarebbero interessate a fare piuttosto che prendere in carico unilateralmente e assegnare compiti. Probabilmente sono tutti seduti lì a pensare a come dovrebbero farsi carico. O come possono ottenere delle povere zolle che si preoccupano troppo di fare tutto il lavoro di gruppo in modo che possano cavalcare il suo grado.

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

Per un'introduzione più fondamentale su come gestire lo sviluppo come descrivi, il mio riferimento preferito è per l'articolo di Martin Fowler Utilizzo di un processo software agile con lo sviluppo offshore . Questo articolo delinea le nozioni di base e i concetti avanzati di impostazione della comunicazione del team distribuito:

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 non sarai certo in grado di seguire tutti i trucchi e le astuzie menzionate (ad esempio, probabilmente non ci saranno Ambasciatori né Visite ai Contatti per te :) ma vale comunque la pena studiare.

• Per molte squadre che hanno tutto sopra sarebbe sicuramente un eccesso. Tuttavia, trovo molto utile avere una checklist esauriente come quella - così che anche gli elementi saltati vengono controllati e hanno ragioni di rifiuto chiaramente documentate - solo per assicurarsi che non sia stato notato nulla di importante.

Non ci hai detto quanto tempo hai per questo o per la lingua in cui lavori (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 e ad essere molto felice di qualsiasi aiuto tu possa ottenere. Prova a 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 su di loro continuando: preparati a farti abbandonare 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 una pietra miliare e attenersi il più possibile. Assicurati di avere qualcosa da poter calciare e controllare le carenze di: se il peggio arriva al peggio, questo sarà ciò che consegnerai. Ognuno che crei, vedrai quanto potresti migliorare le cose, il che ti motiverà ad andare sopra. Non pianificare troppe cose in avanti: certo, devi avere un'idea di cosa finirai, ma mantieni i tuoi piani più specifici a breve termine.

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

Sto assumendo il caso peggiore, dove lavorerai con persone molto nuove alla programmazione. Il mio consiglio generale sarebbe:

• Tieni un elenco di funzionalità che desideri implementare presto e chi le lavorerà. Jarrod ha suggerito Trello e io sostengo tutto questo: se i tuoi compagni di squadra non sono molto esperti, sarà di grande aiuto. Potresti provare a tenere i bug anche lì.
• In un team di quattro persone, è necessario il controllo della versione. Potrebbe rendere gli altri più riluttanti a contribuire se non sanno come lavorarlo, ma ne vale la pena.
• Qualsiasi dipendenza esterna può spaventare i neofiti. Se scrivi dei test unitari, dì alla gente che non dovrebbero preoccuparsi di romperli. Dì alla gente che non dovrebbero preoccuparsi di rompere la costruzione, soprattutto all'inizio. È molto più difficile correggere le persone che non commettono alcun codice rispetto a coloro che eseguono il commit del codice buggy.
• Verifica se le cose suggerite qui si applicano veramente a te. "Integrazione continua" è un termine di fantasia - per un piccolo programma, che potrebbe significare "questo programma viene eseguito e tutte le funzioni possono essere utilizzate". Hai persino dei siti? La suddivisione in team ti aiuta?
• YAGNI, cento volte. Se proprio devi, scrivi in anticipo le caratteristiche per te stesso. Fatelo funzionare, quindi refactoring, altrimenti non riuscirete a farlo funzionare.
• Refactor. Una volta funzionante, dedica del tempo a risolverlo. Non dimenticare che i tuoi compagni di squadra dovranno leggere il tuo codice: un giorno trascorso a riparare pezzi brutti e sostituire soluzioni semplici con quelli con prestazioni migliori non è un giorno sprecato.
• Tieni d'occhio tutte le parti. Scremare i changelog 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 fa in modo che non sia così difficile immergersi se la persona abbandona.
• Non esitare a lavorare sulla cosa più importante, al contrario della tua cosa designata. Se qualcuno sta cadendo in ritardo, prendi nota scritta di ciò da qualche parte e fallo tu stesso. Chiedigli prima, ma vai avanti se non rispondono, o se chiedi una o due volte e poi senti che non lo faranno ancora.
• Concentrati a creare qualcosa di cui essere orgoglioso. Anche se si discosta dal compito. Anche se devi tagliare grandi caratteristiche in favore di rendere ciò che hai più liscio. Ogni iterazione pensa "Sono orgoglioso di questo?", E nella prossima iterazione, prova a sistemare quelle cose.

Ho avuto un progetto fallito orribilmente di recente; puoi leggere i miei pensieri sul perché ha fallito se lo desideri, ma questo riassume come Farei qualcosa del genere se avessi un'altra possibilità.

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

1. Aspettatevi che almeno una delle altre tre persone sia completamente inutile.
2. Accetti solo che ti sentirai come se stessi facendo la maggior parte (o tutta) del lavoro, ma a tutti verrà attribuito lo stesso credito. Qualsiasi tentativo di rendere le cose "giuste" causerà solo conflitti inutili e rallenterà.
3. Resta in contatto con tutti i membri del team che sono bravi. Queste persone sono difficili da trovare e vorrai lavorare ancora con loro.

Sono stato in una posizione simile alcune volte in quanto sono sicuro che molte persone. La cosa principale però è fare del tuo meglio per mantenere tutti contenti e felici, quindi penso che sia bene che tu voglia assumere il compito di team leader, comunque come qualcuno di cui sopra, questo deve essere affrontato con attenzione come qualcun altro potrebbe pensare che dovrebbero fare il lavoro, invece.

So che hai detto che nessuno si è incaricato 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.

Comincio con una e-mail che si rivolge a tutti e fa sapere a chi sei come ritieni che il progetto debba essere affrontato e fai sapere che vuoi guidare il progetto assumendosi la responsabilità di stabilire ruoli, obiettivi, scadenze, tempo di comunicazione , meetup (se desiderato / desiderato) e aggiornamenti del progetto.

Sebbene non sia possibile influenzare completamente le altre persone, è possibile tenere traccia di chi sta facendo cosa e chi no. La delega di posti di lavoro consente di suddividere il lavoro in modo uniforme o appropriato per le persone con diverse serie o livelli di competenze.

In questo modo, se non si sta facendo un certo lavoro, puoi prendere in carico te stesso per dividere il lavoro tra le persone che sono davvero desiderose di lavorarci. In questo modo non si concluderà con un progetto fallito alla fine e si avrà record di provare a comunicare date, orari e tutte le informazioni rilevanti che è possibile mostrare alla fine se le cose vanno male. Tutte 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: link

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

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