Come convincere un compagno di squadra, che si vede come senior, ad apprendere le basi concettuali di SVN? [chiuso]

Per iniziare con un po 'di esperienza, quest'estate ho assunto una nuova posizione di sviluppatore e ho finito per essere il nuovo membro del team, ma con la maggior esperienza al mondo.

Finora sono riuscito a portare avanti le iniziative di sanità pubblica abbastanza facilmente a causa dei bassi costi di adozione (in termini di tempo e sforzi). Tuttavia, le cose sono leggermente aumentate.

Uno dei miei compagni di squadra, sebbene esperto, non capisce davvero SVN. Naturalmente, aree vuote sulla sua mappa mentale raffiguranti oceani di SVN gli fanno adottare schemi di utilizzo piuttosto strani.

Ad esempio, aveva dichiarato una politica di "1 commit SVN al giorno per sviluppatore" perché altrimenti "il server avrebbe presto esaurito lo spazio su disco". Quando gli ho spiegato che i commit SVN sono delta, non copie complete, ha risposto con dubbio e anche oggi non sono del tutto sicuro se capisca cosa significhi.

Abbiamo anche discusso a fondo se includere la .projectconfigurazione di Eclipse in SVN. Il mio compagno di squadra ha insistito che dovremmo, anche se ha causato numerosi conflitti inutili. Ero contrario a mantenere i file di configurazione dei singoli sviluppatori in SVN. Alla fine, si è scoperto che il mio compagno di squadra aveva l'abitudine di ricontrollare l'intero albero dei sorgenti dopo ogni commit per assicurarsi che "il codice impegnato nel repository funzioni". Questo era il motivo per cui era così irremovibile nel mantenere la configurazione del progetto in SVN - quindi sarebbe stato facile reimportare il progetto. Quando ho spiegato che commit sincronizza la copia di lavoro su byte per byte remoto, il che rende superfluo il checkout, il mio compagno di squadra ha risposto di nuovo con dubbi e alla fine ha evitato che l'intero problema fosse insignificante.

A mio avviso, il nostro team perde tempo risolvendo i conflitti SVN nei file di configurazione del progetto che contengono solo impostazioni specifiche per gli sviluppatori che non devono essere condivise con SCM. Tutto questo casino perché qualcuno ha adattato il processo a presupposti errati.

Come posso convincere un compagno di squadra, che si vede come senior, a comprendere meglio le basi di SVN?

IMO è meglio separare quei problemi che causano problemi / danni diretti al progetto da quelli che riguardano solo quel singolo sviluppatore . Ad esempio, se preferisce effettuare il checkout di tutto più volte al giorno, lo rallenterà, ma per il resto non influirà sugli altri. Quindi puoi lasciarglielo fare (fino a quando non ci sarà un notevole ritardo nelle prestazioni nel suo lavoro), e salvarti dalla difficoltà di litigare.

Altri problemi citati, come la conservazione dei .projectfile Eclipse nel repository o 1 commit al giorno, sono i punti su cui concentrarsi, per consentire al team di progredire nel modo più fluido possibile. Prima di tutto, dovresti chiedere / raccogliere feedback dagli altri membri del team , se ciò causa problemi anche a loro. Se ce ne sono altri, insieme è possibile esercitare una maggiore pressione e, se necessario, è possibile aumentare più facilmente un problema verso la direzione.

Per quanto riguarda "SVN esaurisce lo spazio su disco", sarebbe facile confutare la sua convinzione facendo un esperimento (potenzialmente in un repository di prova separato). Devi solo monitorare la dimensione della gerarchia dei file di repository fisici prima e dopo aver eseguito le modifiche in un enorme file di testo o anche molti file. Se ciò non lo convince, nulla può.

In tal caso, sfortunatamente probabilmente hai un problema di autorità, in cui l'altro ragazzo vede accettare un consiglio da qualcuno "di rango inferiore" come una perdita della sua dignità. Tali conflitti non possono essere risolti con argomentazioni logiche. Devi intensificarlo verso la direzione, ma assicurati di avere abbastanza supporto (dai compagni di squadra e / o dalla direzione) prima di farlo. Tale mossa può essere percepita dall'altro come un attacco aperto, quindi può avere conseguenze problematiche (per entrambi, e / o per la pace dell'intera squadra). Quindi pensa tre volte e discuti con i tuoi colleghi di supporto prima di fare quella mossa.

Se la tua azienda utilizza wiki, scrivi alcuni post di alta qualità su SVN:

• Perché dovresti usarlo?
• Quando dovresti usarlo?
• Quali problemi risolve?

eccetera.

Catturerà l'attenzione di CTO e tutti coloro che si rifiuteranno di usare dovranno usare :)

Come leader, manager e membro del team, ho dovuto affrontare la risoluzione di conflitti professionali e di personalità a molti livelli. Indipendentemente dal ruolo in cui sono assunto, in genere vengo accettato come leader anche quando non voglio il ruolo. La ragione di ciò è il modo in cui gestisco questi conflitti.

A differenza di molte persone qui, non sono d'accordo sul fatto che affrontare questa situazione sia un "arrendersi" o "mostrargli un nuovo strumento" o "aspettare che cada sul sedere o scompaia". Ancora più importante, non è mai una buona idea aspettare che i ruoli siano definiti in modo più deciso. Tali ruoli vengono definiti da persone che non attendono, dalle loro convinzioni, etica e capacità di affrontare situazioni critiche, che coinvolgono o meno persone.

Esistono diversi metodi per gestire il tipo di persona che stai descrivendo in queste situazioni. Il primo e principale passo è indagare sul perché si sta comportando come è. Ha poco a che fare con ciò che sa o non sa. Avrebbe potuto facilmente scoprire queste informazioni in precedenza, quindi la domanda è davvero una delle due cose: "Perché non l'ha fatto?" o "Perché rifiuta le informazioni che gli vengono fornite?" Questo ti aiuterà a trovare esattamente ciò che deve essere affrontato.

Nella mia esperienza, i programmatori (incluso me stesso) rifiutano le buone pratiche o i nuovi strumenti per alcuni motivi:

• La fonte non è credibile. In un settore che diventa ogni giorno sempre più polarizzato tra il "culto di Mac" e i "adoratori della SM"; tra "Ideologia Open Source" e "Praticità proprietaria" ... ecc ecc. - Ci sono molti che hanno sempre dubbi sulle informazioni fornite e sul suo potenziale di corruzione a causa del pregiudizio del mittente o dello scrittore, anche quando tali informazioni sono verificato come credibile.
• Esperienze negative prolungate ... con una tecnologia o pratica simile o addirittura uguale. Nulla è perfetto quando inizia, e molti iniziano con meno di 1/4 delle funzionalità rispetto a quando finiscono. È del tutto possibile che abbia avuto molte ore o giorni o addirittura settimane a lavorare con un prodotto inferiore o con lo stesso durante una fase mal implementata.
• Una fonte "credibile" ... conflitto con le informazioni che gli vengono presentate. Per "credibile" intendo una persona o entità di cui si fida. Molte persone tendono ad elevare le persone di cui ci fidiamo a livelli che non rappresentano la realtà. Questa fonte non deve nemmeno aver imposto questa convinzione alla persona. Molto spesso, lo facciamo da soli. Spesso ci dà qualcosa o qualcuno a cui aspirare ad essere come, in almeno un aspetto.
• Mancanza di sicurezza Ciò è stato evidenziato da un precedente poster. I nostri programmi diventano risorse dal momento in cui iniziamo a lavorarci. Non solo per le aziende per cui lavoriamo, ma per le persone con cui lavoriamo. Questo non è semplicemente un problema di controllo. Alcuni di noi vogliono essere in grado di mostrare le nostre cose ordinate alle persone a cui teniamo. Alcuni di noi vogliono assicurarsi che non sia danneggiato da una persona o un prodotto esterno. Per alcuni, è un'estensione di come pensiamo e sentiamo, anche. Ospita alcune delle nostre filosofie e ideologie ed espone i nostri nuclei intellettuali. Per molti, è il nostro futuro, che sia per una classe, un datore di lavoro o un cliente. Per alcuni è tutto ciò. La "sicurezza" in questo senso non si applica ai dati, necessariamente o al codice.

Scoprire qual è il fattore è spesso abbastanza facile. Porta la persona in un ambiente neutro. Spiega alla persona cosa stai osservando, in generale. Chiedi alla persona onestamente cosa sta causando questo comportamento. Ora, non sempre va bene, ma la maggior parte degli adulti risponde abbastanza bene quando sembra che tu voglia aiutare qualcuno che sembra agire in modo irrazionale. È probabile che non agisca in modo irrazionale, ma non è consapevole del fatto che nessuno può capire cosa sta realmente succedendo.

Una volta scoperto qual è effettivamente il problema, puoi dotarti degli strumenti adeguati per affrontarlo. Se è lo scenario n. 1, incoraggialo a fare le ricerche dalle fonti di cui si fida (questo è importante)tornare da te con i suoi risultati. Questo gli dirà che le sue informazioni sono importanti per te. Nel caso dello scenario n. 2, fornire confronti accurati con ciò che è diverso ora rispetto a prima. Incoraggiatelo a provarlo, ma fate un piano di riserva se andrà storto. Per lo scenario n. 3, digli di richiedere la sua fonte con le tue informazioni. È probabile che la sua fonte non abbia le opinioni che pensa di fare, ma ha fatto una volta. Molti di noi si adattano nel tempo, quindi il suo punto di vista è probabilmente cambiato. Se non è disposto, incoraggialo a presentarti alla sua fonte. E infine, per lo scenario n. 4, assicuragli che le sue preoccupazioni sono tue. (Dovrebbero essere ad un certo livello) Dimostrare come questo "nuovo" strumento può proteggere i suoi interessi e aumentare la sua sicurezza. E se non può,

So che tutto ciò sembra troppo semplice per funzionare, ma a volte lo fa semplicemente. In effetti, più sei sincero, più spesso lo fa. Affrontando le sue esigenze, stai rispondendo alle esigenze della squadra, che sia "senior" o meno, perché fa parte della squadra. Mostrargli che vuoi essere sulla stessa pagina di lui, ma semplicemente non lo sei, potrebbe incoraggiarlo a iniziare a lavorare insieme a te. Se hai fatto tutto questo e non hai ancora raggiunto alcuna soluzione, hai fatto tutto il possibile per non parlare con il capo squadra.

FuzzicalLogic

C'è molta superstizione nel controllo del codice sorgente. È controintuitivo, la matematica è arcana e coinvolge la risorsa più importante di una società di software. Devo ammettere che c'è una parte di me che ancora non si fida. Ma non ne farei a meno per un minuto.

Una soluzione potrebbe essere quella di offrire la responsabilità di prendersi cura del repository. Certo, se lo presenti come "è molto lavoro per te, e questo sembra essere un'area in cui ho una certa esperienza", piuttosto che "non sai cosa stai facendo" che avrà una migliore possibilità di lavorare.

Se "vede se stesso come senior" significa ciò che penso faccia, non lo lascerà andare perché lo vede come una fonte di autorità e controllo. Quindi una soluzione alternativa potrebbe essere quella di utilizzare Git localmente per gestire le unità e le filiali di commit sane, quindi basta premere su svn una volta al giorno come richiede. Git è progettato come un sistema peer-to-peer e per avere una copia repository completa su ogni macchina locale. Potresti offrire git ad altri sviluppatori che preferirebbero farlo in questo modo, e può rimanere solo un supplemento a SVN che i singoli gruppi di lavoro (siano essi uno o più sviluppatori, formali o ad hoc) usano internamente. E quando arriva il giorno in cui un ragazzo anziano cede, passa a un altro dipartimento o azienda o si dipinge in un angolo irrecuperabile con le sue politiche SVN, hai un vantaggio sul ripulire tutto.

Parla con loro. Senti, sono uno sviluppatore senior, ma ci sono cose che non conosco. Questa è la natura del business. Se diventano difensivi o aggressivi, questo è un problema di personalità con lo sviluppatore nel caso in cui dovrebbe essere affrontato dal capo squadra, o se sono il capo squadra, dal loro capo.

Inizia un'iniziativa a sacco marrone, una volta pochissime settimane qualcuno tiene un discorso all'ora di pranzo di qualcosa che sa e lo presenta agli altri.

Lo usi come scusa per presentare SVN in dettaglio e forse alcune delle idee alla base di alcune delle alternative.

Qualche settimana dopo qualcun altro può provare.

Proverò a darti alcuni suggerimenti supportati dalla mia esperienza personale.

Uno dei miei compagni di squadra, sebbene esperto, non capisce davvero SVN. Naturalmente, aree vuote sulla sua mappa mentale raffiguranti oceani di SVN gli fanno adottare schemi di utilizzo piuttosto strani.

Ad esempio, aveva dichiarato una politica di "1 commit SVN al giorno per sviluppatore" perché altrimenti "il server avrebbe presto esaurito lo spazio su disco". Quando gli ho spiegato che i commit SVN sono delta, non copie complete, ha risposto con dubbio e anche oggi non sono del tutto sicuro se capisca cosa significhi.

Anche se lo spazio su disco fosse un problema, potresti sempre eseguire il commit di molti file contemporaneamente, quindi penso che ciò che suggerisce sia la soluzione sbagliata. Inoltre, è possibile sprecare molto spazio controllando file binari di grandi dimensioni perché SVN non memorizza delta per file binari. Anche un check-in al giorno è negativo perché ti costringe a commettere modifiche che non si uniscono, ad esempio nel caso in cui correggi più di un bug al giorno.

La soluzione che abbiamo adottato nella nostra azienda è che esiste un filtro che rifiuta qualsiasi commit contenente file binari. Possiamo forzare il commit utilizzando una parola chiave speciale nel commento del check-in (dobbiamo mostrare a SVN che sappiamo cosa stiamo facendo). Una volta ogni due anni un project manager archivia i vecchi rami e li rimuove dal repository. Con questa strategia non abbiamo problemi di spazio che conosco (il nostro repository supporta diversi progetti e ha oltre 100000 revisioni).

Riassumendo, potresti dirgli che sei d'accordo con lui sul fatto che lo spazio su disco è un problema importante ma, d'altro canto, fai notare

1. l'importanza dei check-in relativi alle funzionalità anziché di un check-in monolitico giornaliero;
2. il fatto che controllando un grosso file binario al giorno, si potrebbe comunque riempire il disco.

Quindi potresti suggerire di avere un incontro (possibilmente con altri sviluppatori o anche amministratori di sistema) per discutere le strategie per tenere sotto controllo l'utilizzo dello spazio su disco (ad es. Filtri di file binari, backup regolari e pulizia di vecchi rami non utilizzati).

Abbiamo anche discusso a fondo se includere la configurazione del progetto. Eclipse in SVN. Il mio compagno di squadra ha insistito che dovremmo, sebbene abbia causato numerosi conflitti inutili. Ero contrario a mantenere i file di configurazione dei singoli sviluppatori in SVN. Alla fine, si è scoperto che il mio compagno di squadra aveva l'abitudine di ricontrollare l'intero albero dei sorgenti dopo ogni commit per assicurarsi che "il codice impegnato nel repository funzioni". Questo era il motivo per cui era così irremovibile nel mantenere la configurazione del progetto in SVN - quindi sarebbe stato facile reimportare il progetto. Quando ho spiegato che commit sincronizza la copia di lavoro su byte per byte remoto, il che rende superfluo il checkout, il mio compagno di squadra ha risposto di nuovo con dubbi e alla fine ha evitato che l'intero problema fosse insignificante.

A mio avviso, il nostro team perde tempo risolvendo i conflitti SVN nei file di configurazione del progetto che contengono solo impostazioni specifiche per gli sviluppatori che non devono essere condivise con SCM. Tutto questo casino perché qualcuno ha adattato il processo a presupposti errati.

Usi un server di build? Abbiamo un server di build che verifica il progetto completo e lo compila ogni notte. La mattina successiva i tester hanno un programma di installazione pronto per il test del prodotto (se la build principale è stata eseguita correttamente) e noi (gli sviluppatori) abbiamo un report di build con tutti gli avvisi (e gli errori, nel caso ce ne siano). Naturalmente, è necessario impostare il backup dei file di configurazione standard per il server di build e il check-in. Ogni sviluppatore può quindi controllare fuori insieme con il resto del progetto, ma non è consentito il check-in eventuali modifiche locali.

In questo scenario affronti la sua necessità di poter controllare il progetto completo e costruirlo in qualsiasi momento. Eviti anche di perdere tempo a unire le modifiche che non avrebbero dovuto essere verificate in primo luogo perché non fanno parte del prodotto: il prodotto è la build principale e deve essere tenuto pulito. Se qualcuno interrompe la build principale (ad es. Controllando il proprio file .project) è possibile annullare le modifiche o forzare lo sviluppatore a risolvere il problema.

Forse se risolve nuovamente il problema, puoi di nuovo suggerire di tenere un incontro (possibilmente con altri sviluppatori) e trovare insieme una strategia comune.

Come posso convincere un compagno di squadra, che si vede come senior, a comprendere meglio le basi di SVN?

Penso che la migliore strategia sarebbe quella di evitare di portare il conflitto a livello personale e piuttosto di discutere delle questioni a portata di mano e delle possibili soluzioni. Se hai l'impressione che stia cercando un confronto personale, ecco alcuni suggerimenti (di nuovo, per esperienza personale):

• Come sono le dinamiche del tuo team? I tuoi altri colleghi hanno un'esperienza simile con questo compagno di squadra? Ci sono molti piccoli suggerimenti non troppo espliciti che una squadra può dare a uno dei suoi membri per scoraggiare determinati comportamenti (piccole battute o osservazioni) e incoraggiare un confronto costruttivo (proporre una riunione o sollevare un argomento in modo informale durante una pausa caffè ). A volte una buona squadra può isolare rapidamente un elemento di disturbo e riportare le cose alla normalità.
• Quanto è buona la tua gestione del personale? Abbiamo avuto un caso di conflitto nella nostra azienda e il capo del personale ha dovuto intervenire per chiarire la situazione. Non è stato bello, ma a volte l'atmosfera di lavoro si deteriora così tanto che non migliorerà da sola. Spero che questo non sia il tuo caso (non ho l'impressione che sia arrivato così lontano) ma è sempre bene sapere se hai una buona amministrazione del personale o se devi risolvere i conflitti da solo.

Perché sto scrivendo questo? Dici che vuoi "convincere un compagno di squadra, che si vede come senior, a comprendere meglio le basi di SVN". Per me sembra che il conflitto potrebbe diventare troppo personale. Alcuni psicologi sostengono che il 70% della nostra comunicazione è a livello emotivo, se questo livello non funziona, le persone smettono di parlare dei fatti perché sono troppo occupate a gestire le emozioni.

Quindi, oltre a spiegare i tuoi punti, potresti anche provare a fare qualcosa per migliorare la comunicazione. Invitare per un caffè o fare una pausa pranzo insieme, avere una breve conversazione su un argomento che non è legato al lavoro, ecc., Può migliorare la comunicazione e riportare l'attenzione del collega sui fatti importanti che vuoi che capisca. Se accetta questo tipo di comunicazione, forse i conflitti che hai avuto finora erano legati al fatto che non ti conosci bene e ci sono stati alcuni piccoli equivoci, ma probabilmente è aperto a costruire una collaborazione costruttiva. Se rifiuta, potrebbe esserci un'ostilità più profonda dalla sua parte.

In questo caso, penso che dovresti aspettare che i tuoi ruoli diventino più chiari. Se il tuo compagno di squadra non ha ufficialmente un rango più alto del tuo, non ha senso irritare i tuoi tentativi di migliorare le cose. Con il tempo dovrà accettarlo o prendersi in giro da solo se continua a provare a dimostrare di conoscere meglio. Se lui ha un rango più elevato, si dovrebbe trovare un modo per fargli capire che questo non è in discussione: le tue osservazioni sono volte a migliorare la produttività e non a minare la sua posizione, questo deve essere chiaro al 100%. Quando i ruoli sono stati chiariti, se non riesce ancora ad accettare suggerimenti o critiche costruttive, allora deve davvero avere qualche problema con l'autostima o qualcosa del genere.

Quindi, se tutte le strategie di cui sopra falliscono e continui a sentirti (molto) frustrato, temo che l'unica cosa ragionevole da fare sarà imballare le tue cose e cercare un posto migliore. Ho fatto questa esperienza tre anni fa e ho trovato un'azienda molto migliore di cui sono molto soddisfatto ora. Forse questo non è il tuo caso (spero non ovviamente) ma cerca di capire anche questo punto.

Solo i miei 2 centesimi.

Indicalo del materiale di apprendimento su come funziona SVN e quali sono le migliori pratiche quando si utilizza SVN.

Come dice @Peter - scegli attentamente le tue battaglie e non sprecare le tue energie nel combattere con qualcuno che ovviamente non capisce le basi. SVN non è esattamente una tecnologia all'avanguardia ed è qui da un po ', quindi ci sono abbastanza informazioni al riguardo.

Prova a tenere un registro dello "spreco di tempo SVN". Ogni volta che c'è un problema di conflitto / checkout / versione che deve essere risolto, prendi nota di quanto tempo hai impiegato tu / il team per risolverlo. Se si scopre che stai perdendo un considerevole periodo di tempo ogni settimana, intensificalo con lui e la direzione. Sono sicuro che il management chiederà presto soluzioni se si rendono conto che la produttività può essere migliorata da semplici cambiamenti nel processo di lavoro.

Oppure prova a convincere il tuo collega ad avere una settimana di prova in cui il team utilizza il tuo sistema di check-in (se ciò è facilmente realizzabile con i tuoi progetti e codebase attuali). Promettigli che se non funziona puoi tornare al vecchio sistema al termine della settimana. Ma potrebbe venire dopo averlo provato da solo.

1. Lascia che Subversion risolva il problema per te. Il modo in cui lo dici, il tuo collega è relativamente poco sofisticato quando si tratta di Subversion. In tal caso, una soluzione tecnica potrebbe essere una buona opzione. Se il resto del team è d'accordo e puoi ottenere la benedizione del tuo manager, aggiungi un global-ignorescampo al file di configurazione del repository in modo da poter escludere i file .project e altri che non desideri sotto il controllo della versione.

2. Aiutalo. Invece di imporre il tuo modo di fare le cose su di lui, cerca di aiutare il ragazzo a fare le cose a modo suo senza causare problemi a tutti gli altri. Se il tuo collega lavora nel suo stesso ramo, non dovresti davvero preoccuparti di ciò che commette. Se vuole eseguire il commit del suo file .project in modo da poter effettuare il checkout di una nuova copia dell'intera directory, non è un problema per te. L'unica cosa di cui dovresti preoccuparti è che non unisce il suo file .project al comune ramo di sviluppo. Dovrebbe essere facile da gestire, ancora una volta, impostando la proprietà ignore sul ramo di sviluppo per escludere il file .project.

3. Chiedi supporto dall'alto. Non entrare in una discussione "non sei il capo di me" con il ragazzo, ma se il suo comportamento sta causando un problema per te, assicurati che il tuo manager sia consapevole della situazione. Se non sei sicuro di come contattare il tuo manager, prova a chiedere un consiglio: "Mike, ho provato a parlare con Larry, ma non ci riesco. Insiste su X, Y e Z, e il resto di noi trascorre molto tempo inutile a risolvere i problemi che si creano. Puoi darmi qualche suggerimento su come affrontare il ragazzo? "

4. Ignoralo. Perché qualcuno nella squadra ascolta questo ragazzo? Ha qualche autorità effettiva sul progetto? A chi importa se dichiara una politica di commit per sviluppatore se non ha il potere di applicarla? Lascia che pensi che sia Yertle la Tartaruga se lo fa sentire meglio, non lasciargli creare problemi reali per te.

Fai licenziare il ragazzo e finisci con il tallone trascinando e l'evidente contaminazione verso la tecnologia più recente. Oppure fai davvero saltare la testa e inizia a usare GIT. Se non riesce a capire SVn, sarà sicuramente spazzato via da GIT.

Sembra che stai combattendo una battaglia persa, ma puoi farcela. Machiavelli in The Prince ha descritto quanto sia difficile cambiare lo status quo. Suggerirei di rileggere quel capitolo e forse non fare ciò che suggerisce - può essere duro.

Dovresti portare le tue preoccupazioni allo sviluppatore senior in privato e assicurarti di criticare in modo costruttivo il modo in cui le cose vengono fatte e non lui o altri sviluppatori. Quindi offri di parlare e di scrivere una guida alle migliori pratiche. Mostra loro come capire meglio SVN renderà le loro vite più facili. In definitiva, si tratta di costi ed efficienza. Se riesci a dimostrare che la tua strada migliora le cose senza calpestare le dita, allora puoi vincere questa.

Cerca di capire perché il / i ragazzo / i senior sta (stanno) usando il repository così com'è. Quali sono le loro preoccupazioni? Cosa stanno cercando di ottenere? Come puoi aiutarli a essere più produttivi? Soprattutto, cerca di mantenere un approccio calmo e professionale. È facile sentirsi frustrati. Sii assertivo: Assertività sul lavoro: una guida pratica alla gestione delle situazioni imbarazzanti di Ken Back e Kate Back è una buona lettura. Infine, pensa "come mi convincerei a cambiare?". Sii un onesto sostenitore del diavolo e questo potrebbe aiutarti a trovare buone risposte e domande da porre.

Come nota a margine, starei attento a usare l'umorismo. Potrebbe fare miracoli o farti sembrare un cretino. Quindi, lo eviterei.

Fondamentalmente, scegli attentamente le tue battaglie in quanto potresti non vincere questa. In tal caso, o non ti interessa più o cerca un lavoro diverso. Duro, lo so.

Una volta ero al contrario della tua posizione circa 8 anni fa, quando SVN era una tecnologia ragionevolmente nuova. Ero uno sviluppatore senior e mi è stato chiesto / infastidito l'installazione di SVN da uno sviluppatore junior (in realtà era un supporto IT più accurato di uno sviluppatore). Ho preso una mentalità aperta nonostante i miei sospetti iniziali riguardo all'aumento del carico di lavoro, alla complessità inutile, ecc ... e poi ne sono diventato un grande fan.

A mio avviso, da quello che hai descritto questo problema dipende sicuramente dalle personalità della squadra: la sua testardaggine sta dimostrando un ostacolo per l'intera squadra su questo tema. Potresti stare meglio arretrando a questo punto e lasciando che la pressione del resto della squadra costruisca naturalmente per forzare la sua mano.

Questo è praticamente un caso di "mancanza di autorità" e una persona che applica il potere della propria paura di tenere le cose "sotto controllo"

Per risolvere questo problema, trova qualcuno che abbia ispirato il tuo compagno di squadra o qualcuno che rispetti e che sia in grado di spiegare l'urgenza di usare qualcosa come SVN. In questo modo la sua paura per il cambiamento e fondamentalmente la "perdita di autorità" non è in gioco perché non è un membro del team che gli dice cosa fare. Mi asterrei dall'usare qualcuno come un manager per parlare con questo ragazzo perché questo aggiunge solo pressione e potrebbe persino creare una situazione più stressante per te stesso.

Di recente ho letto il cambiamento tecnico alla guida: perché le persone del tuo team non agiscono in base a buone idee e come convincerli che dovrebbero , pubblicato da The Pragmatic Programmers. Questo libro fornisce un background che dovresti conoscere prima di provare a introdurre un cambiamento tecnico, una serie di modelli nelle persone che si oppongono o rifiutano di cambiare, tecniche per implementare i cambiamenti e quindi strategie per massimizzare l'uso di queste tecniche e di tutte le persone intorno tu.

In base al tuo post, direi che il tuo compagno di squadra probabilmente rientra nel modello disinformato o cinico, ma potrebbe anche essere un caso di irrazionale. Alcune delle tecniche raccomandate per contrastare questo tipo di persone sono di acquisire esperienza all'interno dell'ambiente di destinazione in modo da poter trovare eventuali problemi e presentare le risposte ai problemi che altre persone incontreranno prima che si verifichino, risolvere il problema giusto, consegnare il messaggio con passione ma senza essere troppo zelanti, dimostra le tecniche mostrando chiaramente i vantaggi dei tuoi metodi e strumenti e vendili organicamente (ma non creare problemi solo per risolverli), e ottenere pubblicità e acquistare dal resto del tuo team. Tuttavia, se è irrazionale, c'è '

Infine, quindi inizi a utilizzare queste tecniche, hai bisogno di una strategia globale. È importante non lasciare che quelli che sono attivamente ostili o irrazionali ti rallentino - ignorali. Invece, trova persone che puoi dimostrare e convincere di avere un modo migliore e applicare le tecniche appropriate basate su di esse come individuo. Una volta che più persone vedranno i miglioramenti offerti dalle tue conoscenze, usali per continuare a convincere gli altri. Infine, usa questo sforzo di base per convincere il management che esiste un modo migliore, ma assicurati di metterlo in termini comprensibili (tempo, denaro, qualità).

Non cercare di "convincere" questo ragazzo di niente. Le persone (anche i programmatori) non risponderanno o rispetteranno argomenti ragionevoli / logici da parte di qualcuno che vedono come junior. Quindi non sprecare fiato. Invece, lavora per costruire un livello di fiducia con questa persona. Questa persona ascolterà ciò che hai da dire solo quando sarà aperto ad esso.

Nel frattempo, hai problemi reali:

1. Il ragazzo controlla il suo file .project nel repository: ignoralo. non è necessario modificare il file, né chiunque altro nel team lo sappia meglio. Lasciarlo andare. Se dà al tuo "membro senior" una sensazione calda e felice come una coperta di sicurezza, allora così sia.
2. C'è un budget percepito sullo spazio su disco: questa è la ragione per cui Mr. Senior impone 1 impegno al giorno. La carenza di spazio è reale o percepita? Anche se è appena percepito, forse c'è qualcosa che puoi fare per cambiare quella percezione. Questo dovrebbe essere affrontato immediatamente - se prendi l'iniziativa aiuta anche a creare fiducia.

Potrei anche aggiungere che questo ragazzo sarà disposto ad adottare migliori pratiche SVN quando pensa che siano le sue idee. Ciò richiederà un po 'di riflessione da parte tua, e probabilmente si prenderà il merito per aver stabilito pratiche migliori, ma tu sei d'accordo con quello.