Come convincere i miei compagni di squadra a seguire alcune regole di base

My question is: am I too harsh on this matter?

Puoi portare un cavallo all'acqua, ma non puoi farlo bere.

È difficile dire se sei "troppo duro", ma potrebbe non essere realistico aspettarsi che i tuoi compagni di squadra adottino tutta l'infrastruttura che speri. E davvero, se il team sta lavorando bene insieme, usare un wiki per comunicare tra tre persone è probabilmente eccessivo.

Riduci le tue aspettative e cerca modi per raggiungere alcuni dei tuoi obiettivi senza richiedere loro di iniziare a utilizzare strumenti che non conoscono. Se non sanno come usare git, probabilmente non otterranno molti benefici da esso in ogni caso. Tuttavia, desideri comunque assicurarti che venga eseguito il backup di tutto il codice in caso di guasto del disco rigido o di altre catastrofi, quindi chiedi loro di copiare periodicamente la cartella del progetto su Google Drive, Dropbox o un servizio di condivisione file online simile. Assicurati di fare lo stesso.

Il mio atteggiamento è che se puoi imparare a fare queste cose su piccoli progetti, sarai preparato quando arrivano i grandi progetti.

Se seguono una buona pratica di sviluppo con questo progetto, avranno codice da mostrare ai futuri datori di lavoro e avranno esperienza che li renderebbe preziosi come dipendenti.

Se desideri altro materiale per convincerli, fare riferimento al Programmatore pragmatico o Code completato .

D'altro canto, prendi in considerazione la possibilità di ridurli un po 'di tempo. Se il progetto è un proof-of-concept che viene rimesso in gioco subito dopo la competizione, allora dovresti considerare di lasciare che facciano come vogliono. Potrebbero essere in difficoltà solo per scrivere il codice in primo luogo, senza il sovraccarico mentale delle buone pratiche.

Temo che le regole che hai descritto non siano affatto di base.

Il compito più semplice IMO è convincere i tuoi compagni di squadra a utilizzare alcuni standard di codifica. E un modo semplice per ottenere ciò è mostrare loro lo stesso frammento di codice una volta ben formattato e poi mal progettato, chiedere loro di leggere il codice, capire cosa fa e lasciare che si giudichino da soli.

Per quanto riguarda l'utilizzo di un repository git, questo può essere un problema per i principianti. Quando lavoravo in un team di 3 persone su un progetto Android, all'inizio avevamo un sacco di problemi con il nostro sistema di controllo delle versioni. Quindi mi aspetto che anche i tuoi compagni di squadra abbiano il problema.

Hai detto che ci vorranno 3-4 giorni prima che lo sviluppatore esperto finisca il progetto (presumo che la tua squadra impiegherà 2-3 volte di più). Questo è un periodo di tempo molto breve, quindi l'argomentazione che l'utilizzo di nuovi strumenti aiuterà a lungo termine semplicemente non funzionerà.

Quello che puoi fare è creare dimostrazioni brevi e semplici per mostrare come vengono utilizzati tali strumenti. Coprire le funzioni di base in un primo momento, sedersi al loro fianco e aiutarli a utilizzare gli strumenti. Preparati a svolgere tutte le attività come configurare git, creare la struttura della pagina wiki, ecc.

Modifica : in risposta al commento, penso che stabilire compiti chiari, stime e scadenze e tenere traccia del tempo trascorso sia più importante dell'uso di git o strumenti simili. Se si prevede di lavorare sull'applicazione in un secondo momento, è molto importante tenere traccia di ciò che è già stato fatto e della durata di ciascuna funzione. Quindi ti suggerisco di iniziare dalla gestione delle attività e quindi passare agli strumenti che desideri utilizzare.

In realtà mi piacciono i pensieri di Joel Spolsky su di esso, come illustrato in Ottenere le cose fatte quando sei solo un grugnito . Per riassumere:

1. Fallo e basta - Scrivi makefile, crea un server di build giornaliero ecc.
2. Nessuno utilizza i database di controllo dei sorgenti o dei bug? inizia a usarli tu stesso. Se qualcuno segnala un bug contro il tuo lavoro, chiedi gentilmente di usare il database dei bug per segnalarti i bug in modo da poterne tenere traccia; altrimenti non sarai in grado di tenerli dritti in testa e sistemarli. Su qualsiasi progetto non banale, ci sarà una situazione che è risolvibile solo con il controllo del codice sorgente: usa il controllo del codice sorgente per te stesso e fai un salto eroico per salvare il giorno in cui si verifica una situazione del genere. Una volta che questo accade alcune volte, si convinceranno
3. Crea una tasca di eccellenza - Fai le cose giuste per te stesso: speculazioni, pianificazione ecc. Poiché questo non sembra un progetto di lavoro, non sembra che tu possa seguire questo consiglio fino in fondo , dal momento che non puoi assumere nuovi membri del team che credono nel tuo messaggio
4. Diventa prezioso - Dimostra che sei un grande contributore per cementare la tua influenza nella squadra. Altrimenti corri il rischio di diventare noto come una persona che valuta i processi e gli strumenti rispetto ai risultati

Documentazione, Wiki, software di versioning, metodologie, ecc. sono esperienze e lezioni apprese nel tempo; lavoro di diversi progetti e probabilmente su più squadre. E di solito si attacca a quelli già impiegati o che prendono sul serio il loro settore. Sono studenti, quindi i loro interessi sono probabilmente limitati a ciò che accade in futuro. :)

Ma per cercare di rispondere alla tua domanda:

Se sei in una squadra con loro, dovresti applicare ciò che pensi sia importante in un modo che avvantaggi i loro interessi. Ad esempio: dovrebbero lamentarsi del fatto che il loro codice si rompa molto quando il USB lo condivide? Quindi magari dare loro un modo semplice (non complicato) di usare SVN (piuttosto che git) come strumento di versioning.

Sono d'accordo anche con il commento di arnaud.

Hai visto il vantaggio di tutti questi strumenti quando stavi lavorando con loro e questo è il modo in cui hai visto il valore in essi e perché ne capisci il loro uso. Se i tuoi compagni di squadra non vedono un valore aggiunto nel modo in cui fanno attualmente le cose, allora non lo applicheranno. E la cosa triste è che questo vale anche per le squadre composte da persone con qualsiasi livello di esperienza.

L'approccio ha problemi:

1. Il tuo approccio non è simmetrico. gli altri membri del tuo team devono cambiare, ma non stai imparando le loro buone pratiche. Applicare regole in situazioni come questa è difficile. Un approccio migliore sarebbe quello di raccogliere buone regole e pratiche da tutti i membri del team e poi tutti leggeranno il documento risultante.

2. L'apprendimento è difficile. Le regole altrui non hanno senso perché quelle regole non hanno la struttura logica che i programmatori si aspettano. L'applicazione di regole che non hanno senso non è un'attività utile.

3. Tutti hanno imparato cose diverse. È naturale che i programmatori provenienti da background diversi abbiano imparato cose diverse. I loro punti di forza sono diversi e gli stili di scrittura del codice sono diversi. Gli strumenti che usano sono diversi. Applicare un insieme di regole / strumenti / stili sarà un incubo perché le limitazioni stanno perdendo la forza che gli sviluppatori hanno dedicato anni ad imparare.
4. Il cambiamento richiede tempo. Mentre la persona che ha inventato le regole che imponi ha abbastanza tempo per seguire le regole, tutti gli altri ne soffrono e trascorrono del tempo ad apprendere le nuove regole. Questa è una delle ragioni per cui tutti i membri del team dovrebbero essere in grado di cambiare le regole.
5. Scelta degli strumenti / convenzioni di codifica o stili per un intero team è un'attività difficile . Può essere fatto solo lentamente nel tempo, testando cosa funziona e cosa non funziona. Dare a una squadra 2 settimane per iniziare a seguire 50 regole non funzionerà.

Ho trovato questo problema all'università. Molte persone semplicemente non sono disposte a imparare un modo di lavorare diverso (e forse più professionale).

Tuttavia, se hai sistemi in atto e spieghi come utilizzare il sistema, molte persone sono disposte a provarlo. Penso anche che i repository siano strumenti molto poco usati e la gente userà comunemente qualcosa come Dropbox.