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

Ho un problema con i miei compagni di squadra. Per farla breve: siamo tre studenti che lavorano a un progetto per un concorso. Il progetto consiste in 2 applicazioni separate: una per Windows (che sviluppo) e una per Android (i miei colleghi sono responsabili dello sviluppo). Le nostre basi di codice non si intersecheranno mai, le app comunicheranno tramite strumenti di terze parti.

Il problema è il seguente: ho una certa esperienza di lavoro in team mentre ho fatto uno stage in una grande azienda l'anno scorso e cerco di applicare alcuni standard di codifica per il nostro codice. Ho anche creato un repository git / wiki / software di collaborazione che possiamo usare per spingere codice / scrivere idee, protocolli di documenti e così via, ma sembra che io sia l'unico che usa questi strumenti.

Ho cercato di dire loro che scrivere codice di qualità e documentare ogni passo ci gioverà a lungo termine, ma sembra che non ne vedano il vantaggio. Inoltre stavo pensando di aggiungere alcuni test di integrazione, ma da quello che posso vedere, purché non utilizzino gli strumenti attuali per semplificare la loro vita, non credo di poterli convincere dell'utilità dei test di integrazione.

La maggior parte del codice del peer risiede sui loro computer, non condividono una base di codice comune e, come ho scoperto, hanno integrato i loro pezzi incontrando e condividendo il codice tramite chiavetta USB.

La mia domanda è: sono troppo duro su questo argomento? Devo applicare alcune regole assurde? Tieni presente che questo è un piccolo progetto, i requisiti sono molto chiari (ho creato documenti che specificano cosa dovrebbero fare le applicazioni), tre sviluppatori qualificati potrebbero farlo in 3-4 giorni, quindi potrebbero non vedere la complessità aggiunta della qualità di scrittura codice fintanto che il loro metodo attuale funziona.

Esiste un modo per mostrare loro il vantaggio di documentare il codice, usare git e così via?

La mia domanda è: sono troppo duro su questo argomento?

Puoi condurre 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.

Ridimensiona 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 usare Git, probabilmente non ne trarranno molti benefici. Tuttavia, vuoi comunque assicurarti che venga eseguito il backup di tutto il codice in caso di guasto del disco rigido o altra catastrofe, quindi chiedi loro di copiare periodicamente la cartella del progetto su Google Drive, Dropbox o un servizio di condivisione di file online simile. Assicurati di fare lo stesso.

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

Se seguiranno le buone pratiche di sviluppo con questo progetto, avranno il codice da mostrare ai futuri datori di lavoro e avranno esperienza che li renderebbe preziosi come dipendenti.

Se vuoi più materiale per convincerli, farei riferimento al programmatore pragmatico , o codice completo .

D'altra parte, considera di ridurli un po '. Se il progetto è una dimostrazione di concetto che si sta affermando subito dopo la competizione, allora dovresti considerare di lasciarli fare come vogliono. Potrebbero avere difficoltà a scrivere il codice in primo luogo, senza il sovraccarico mentale delle buone pratiche.

Temo che le regole che hai descritto non siano affatto basilari.

Il compito più semplice IMO è convincere i tuoi compagni di squadra ad usare alcuni standard di codifica. E un modo semplice per raggiungere questo obiettivo è mostrare loro lo stesso frammento di codice una volta ben formattato e quindi di cattivo stile, chiedere loro di leggere il codice, capire cosa fa e lasciarli giudicare da soli.

Ciò che viene ad usare un repository git, questo può essere un dolore per i principianti. Quando stavo lavorando in un team di 3 persone su un progetto Android, all'inizio abbiamo avuto molti problemi con il nostro sistema di controllo della versione. Quindi mi aspetto che anche i tuoi compagni di squadra avranno il problema.

Hai detto che ci vorranno 3-4 giorni per lo sviluppatore esperto per terminare il progetto (suppongo che occorrerebbe 2-3 volte il tuo team). Questo è un periodo di tempo molto breve, quindi l'argomento secondo cui l'uso di nuovi strumenti aiuterà a lungo termine semplicemente non funzionerà.

Quello che puoi fare è fare brevi e semplici dimostrazioni per mostrare come vengono utilizzati quegli strumenti. Copri inizialmente le funzioni più elementari, siediti al loro fianco e aiutali a usare gli strumenti. Preparati a fare 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 che usare git o strumenti simili. Se prevedi di lavorare sull'applicazione in un secondo momento, è molto importante tenere traccia di ciò che è già stato fatto e del tempo impiegato da ciascuna funzione. Quindi ti suggerisco di iniziare dalla gestione delle attività e quindi procedere con gli strumenti che desideri utilizzare.

In realtà mi piacciono i pensieri di Joel Spolsky su questo, come ha spiegato in Come fare le cose quando sei solo un grugnito . Riassumere:

1. Fallo e basta : scrivi makefile, crea un server di build giornaliero, ecc.
2. Nessuno usa il controllo del codice sorgente o database di bug? Inizia a usarli tu stesso. Se qualcuno segnala un bug contro il tuo lavoro, chiedi cortesemente di utilizzare 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 ripararli. Su qualsiasi progetto non banale, ci sarà una situazione che è solo risolvibile con il controllo del codice sorgente: usa il controllo del codice sorgente per il codice da solo e sfreccia eroicamente per salvare il giorno in cui si verifica una situazione del genere. Una volta che questo accadrà alcune volte, si convinceranno
3. Crea una tasca di eccellenza - Fai le cose giuste per te: speccing, schedulazione ecc. Dato che questo non sembra un progetto di lavoro, non sembra che tu possa prendere completamente questo consiglio, dato che non puoi assumere nuovi membri del team che credono nel tuo messaggio
4. Diventa prezioso - Dimostra di essere un grande collaboratore per consolidare la tua influenza nella squadra. Altrimenti si corre il rischio di farsi conoscere come persona che valorizza i processi e gli strumenti rispetto ai risultati

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

Ma per provare a rispondere alla tua domanda:

Se fai parte di una squadra con loro, dovrai applicare ciò che ritieni sia importante in modo da favorire i loro interessi. Ad esempio: dovrebbero lamentarsi della rottura del loro codice quando l'USB lo condivide? Quindi forse dai loro un modo semplice (non complicato) di usare SVN (piuttosto che git) come strumento di controllo delle versioni.

Concordo anche con il commento di Arnaud.

Hai visto il vantaggio di tutti questi strumenti quando lavoravi con loro ed è così che hai visto il valore in loro e perché ne comprendi l'uso. Se i tuoi compagni di squadra non vedono un valore aggiunto nel modo in cui attualmente fanno le cose, allora non lo applicheranno. E la cosa triste è che ciò conta anche per le squadre fatte di persone con qualsiasi livello di esperienza.

L'approccio ha problemi:

1. Il tuo approccio non è simmetrico. Gli altri membri del 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 quindi tutti leggono semplicemente il documento risultante.

2. L'apprendimento è difficile. Le regole di altre persone semplicemente 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 ambienti diversi abbiano imparato cose diverse. I loro punti di forza sono diversi e gli stili di scrittura del codice diversi. Gli strumenti che usano sono diversi. Applicare un insieme di regole / strumenti / stili sarà un incubo perché i limiti stanno perdendo la forza che gli sviluppatori hanno trascorso anni a imparare.
4. Il cambiamento richiede tempo. Mentre la persona che ha inventato le regole che stai imponendo ha abbastanza tempo a seguire le regole, tutti gli altri soffrono e passano il tempo ad imparare le nuove regole. Questo è uno dei motivi per cui tutti i membri del team dovrebbero essere in grado di cambiare le regole.
5. Scegliere strumenti / convenzioni di codifica o stili per un'intera squadra è un'attività difficile . Può essere fatto 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 riscontrato questo problema all'università. Molte persone semplicemente non sono disposte ad imparare un modo diverso (e forse più professionale) di lavorare.

Tuttavia, se disponi di sistemi che spiegano come utilizzare il sistema, molte persone sono disposte a provarlo. Penso anche che i repository siano strumenti molto usati e che le persone usino semplicemente un dropbox.