Como convencer um colega de equipe, que se considera sênior, a aprender os conceitos básicos de SVN? [fechadas]

Para começar com alguns antecedentes, assumi uma nova posição de desenvolvedor neste verão e acabei sendo o mais novo membro da equipe, mas com a maior experiência possível.

Até agora, consegui promover iniciativas de sanidade com bastante facilidade devido aos baixos custos de adoção (em termos de tempo e esforço). No entanto, as coisas subiram um pouco.

Um dos meus colegas de equipe, apesar de experiente, não entende realmente o SVN. Naturalmente, áreas em branco em seu mapa mental representando oceanos de SVN fazem com que ele adote padrões de uso bastante estranhos.

Por exemplo, ele havia declarado uma política de "1 commit de SVN por dia por desenvolvedor" porque, caso contrário, "o servidor logo ficaria sem espaço em disco". Quando expliquei a ele que os commits SVN são deltas, não cópias completas, ele respondeu com dúvida e ainda hoje não tenho muita certeza se ele entende o que isso significa.

Também tivemos uma discussão acalorada sobre a inclusão da .projectconfiguração do Eclipse no SVN. Meu companheiro de equipe insistiu que deveríamos, embora tenha causado muitos conflitos inúteis. Eu era contra manter arquivos de configuração de desenvolvedor individuais no SVN. Por fim, meu colega de equipe teve a prática de fazer check-out de toda a árvore de código-fonte após cada confirmação para garantir que "o código comprometido no repositório funcione". Essa foi a razão pela qual ele foi tão inflexível em manter a configuração do projeto no SVN - para que fosse fácil reimportar o projeto. Quando expliquei que o commit sincroniza a cópia de trabalho com byte a byte remoto, o que torna o check-out desnecessário, meu colega de equipe respondeu com dúvida novamente e, por fim, considerou insignificante todo o problema.

Na minha opinião, nossa equipe perde tempo resolvendo conflitos SVN nos arquivos de configuração do projeto que contêm apenas configurações específicas do desenvolvedor que não precisam ser compartilhadas com o SCM. Toda essa bagunça porque alguém adaptou o processo em torno de suposições incorretas.

Como convencer um colega de equipe, que se considera sênior, a entender melhor os conceitos básicos de SVN?

Na IMO, é melhor separar os problemas que causam problemas / danos diretos ao projeto daqueles que afetam apenas esse desenvolvedor . Por exemplo, se ele preferir verificar tudo várias vezes ao dia, isso o tornará mais lento, mas, caso contrário, não afetará os outros. Portanto, você pode deixá-lo fazer isso (até que haja um atraso perceptível no desempenho de seu trabalho) e se poupar do trabalho de discutir sobre isso.

Outros problemas mencionados, como manter os .projectarquivos Eclipse no repositório ou 1 confirmação por dia, são os locais em que você deve se concentrar, para permitir que a equipe progrida da maneira mais tranquila possível. Antes de tudo, você deve pedir / coletar feedback dos outros membros da equipe , se isso também causa problemas para eles. Se houver outros, juntos , você poderá exercer mais pressão e, se necessário, poderá escalar um problema com mais facilidade para o gerenciamento.

Em relação ao "SVN fica sem espaço em disco", seria fácil refutar sua crença fazendo um experimento (potencialmente em um repositório de teste separado). Você só precisa monitorar o tamanho da hierarquia física dos arquivos de recompra antes e depois de confirmar as alterações em um grande arquivo de texto ou mesmo em muitos arquivos. Se isso não o convence, nada pode.

Nesse caso, infelizmente, você provavelmente tem um problema de autoridade, onde o outro cara vê a aceitação de conselhos de alguém "mais baixo no ranking" como uma perda de sua dignidade. Tais conflitos não podem ser resolvidos por argumentos lógicos. Você precisa escalá-lo para o gerenciamento, mas tenha cuidado para garantir que você tenha suporte suficiente (de colegas de equipe e / ou de gerenciamento) antes de fazer isso. Tal movimento pode ser percebido pelo outro cara como um ataque aberto, portanto, pode ter consequências problemáticas (para qualquer um de vocês e / ou para a paz de toda a equipe). Portanto, pense três vezes e discuta com seus colegas de apoio antes de tomar essa decisão.

Se sua empresa usa wiki, escreva algumas postagens de alta qualidade sobre SVN:

• Por que você deveria usá-lo?
• Quando você deve usá-lo?
• Que problemas ele resolve?

etc.

Ele chamará a atenção do CTO e todos que se recusarem a usar terão que usar :)

Como líder, gerente e membro da equipe, tive que lidar com a resolução de conflitos profissionais e de personalidade em vários níveis. Não importa em que função eu seja contratado, normalmente sou aceito como líder, mesmo quando não quero o cargo. A razão para isso é a maneira como lido com esses conflitos.

Ao contrário de muitas pessoas aqui, não concordo que lidar com essa situação seja "desistir" ou "mostrar a ele uma nova ferramenta" ou "esperar que ele caia de bunda ou desapareça". Mais importante ainda, nunca é uma boa ideia esperar até que os papéis sejam definidos com mais firmeza. Esses papéis são definidos por pessoas que não esperam, por suas convicções, ética e capacidade de lidar com situações críticas, envolvendo ou não pessoas.

Existem vários métodos para lidar com o tipo de pessoa que você está descrevendo nessas situações. O primeiro e mais importante passo é investigar por que ele está se comportando da maneira que está. Tem pouco a ver com o que ele sabe ou não sabe. Ele poderia facilmente ter descoberto essas informações anteriormente, então a pergunta é realmente uma das duas coisas: "Por que não?" ou "Por que ele está rejeitando a informação que está sendo fornecida?" Isso ajudará você a encontrar o que exatamente precisa ser tratado.

Na minha experiência, programadores (inclusive eu) recusam boas práticas ou novas ferramentas por apenas alguns motivos:

• A fonte não é credível. Em uma indústria que se torna cada vez mais polarizada a cada dia entre o "culto ao Mac" e os "adoradores do MS"; entre "Ideologia de código aberto" e "Praticidade proprietária" ... etc etc - Há muitos que sempre têm dúvidas sobre as informações fornecidas e seu potencial de corrupção devido ao viés do remetente ou do escritor, mesmo quando essas informações são verificado como credível.
• Más experiências prolongadas ... com uma tecnologia ou prática semelhante ou mesmo a mesma. Nada é perfeito quando é iniciado, e muitos começam com menos de 1/4 dos recursos do que acabam. É perfeitamente possível que ele tivesse muitas horas ou dias ou até semanas trabalhando com um produto inferior ou o mesmo durante uma fase mal implementada.
• Uma fonte "credível" ... entra em conflito com a informação que ele está sendo apresentada. Por "credível", quero dizer uma pessoa ou entidade em que ele confia. Muitas pessoas tendem a elevar as pessoas em quem confiamos a níveis que não representam a realidade. Essa fonte nem precisa ter imposto essa crença à pessoa. Na maioria das vezes, nós fazemos isso sozinhos. Isso geralmente nos dá algo ou alguém para aspirar a ser, em pelo menos um aspecto.
• Falta de segurança Isso foi destacado por um pôster anterior. Nossos programas se tornam ativos a partir do momento em que começamos a trabalhar neles. Não apenas para as empresas em que trabalhamos, mas também para as pessoas com quem trabalhamos. Isso não é simplesmente uma questão de controle. Alguns de nós querem poder mostrar nossas coisas legais para as pessoas de quem gostamos. Alguns de nós querem ter certeza de que não sejam prejudicados por uma pessoa ou produto externo. Para alguns, é uma extensão de como pensamos e sentimos, até. Abriga algumas de nossas filosofias e ideologias e expõe nossos núcleos intelectuais. Para muitos, é o nosso futuro, seja para uma classe, um empregador ou cliente. Para alguns, é tudo isso. "Segurança", nesse sentido, não se aplica aos dados, necessariamente, ou ao código.

Descobrir qual é o fator é frequentemente bastante fácil. Coloque a pessoa em um ambiente neutro. Explique à pessoa o que você está observando, em geral. Pergunte honestamente à pessoa o que está causando esse comportamento. Agora, nem sempre tudo corre bem, mas a maioria dos adultos responde muito bem quando você parece querer ajudar alguém que parece estar agindo irracionalmente. Provavelmente, ele não está agindo irracionalmente, mas não sabe que ninguém pode entender o que realmente está acontecendo.

Depois de descobrir qual é realmente o problema, você pode se equipar com as ferramentas adequadas para lidar com isso. Se for o cenário 1, incentive-o a fazer a pesquisa a partir das fontes em que ele confia e (isso é importante)voltar para você com suas próprias descobertas. Isso lhe dirá que suas próprias informações têm valor com você. No caso do cenário 2, faça comparações precisas com o que é diferente agora do que antes. Incentive-o a tentar, mas tenha um plano de backup para dar errado. Para o cenário 3, diga-lhe para solicitar sua fonte com SUAS informações. Provavelmente, sua fonte não mantém os pontos de vista que ele pensa que tem, mas fez ao mesmo tempo. A maioria de nós se adapta ao longo do tempo, então seu ponto de vista provavelmente mudou. Se ele não estiver disposto, incentive-o a apresentar você à fonte dele. E, finalmente, no cenário 4, assegure-lhe que as preocupações dele são suas. (Eles devem estar em algum nível) Demonstre como essa "nova" ferramenta pode proteger seus interesses e aumentar sua segurança. E se não puder,

Sei que tudo isso parece simples demais para funcionar, mas às vezes simplesmente funciona. De fato, quanto mais sincero você é, mais frequentemente isso acontece. Ao atender às necessidades dele, você está atendendo às necessidades da equipe, seja ele "sênior" ou não, porque ele faz parte da equipe. Mostrar a ele que você deseja estar na mesma página que ele, mas simplesmente não está, pode incentivá-lo a começar a trabalhar junto com você. Se você já fez tudo isso e ainda não obteve nenhuma solução, fez tudo o que pode antes de falar com o líder da equipe.

FuzzicalLogic

Há muita superstição em relação ao controle de origem. É contra-intuitivo, a matemática é misteriosa e envolve o ativo mais importante que uma empresa de software possui. Eu tenho que admitir que há uma parte de mim que ainda não confia nela. Mas eu não ficaria sem isso por um minuto.

Uma solução pode ser oferecer a responsabilidade de cuidar do repo. Claro, se você apresentar como "é muito trabalho para você, e isso é apenas uma área em que tenho alguma experiência", em vez de "você não sabe o que está fazendo", isso terá uma melhor chance de trabalhar.

Se "se vê como sênior" significa o que eu acho que faz, ele não vai deixar de lado, porque o vê como uma fonte de autoridade e controle. Portanto, você pode usar o Git localmente para gerenciar unidades e ramificações de consolidação sãs, basta pressionar o svn uma vez por dia, como ele pede. O Git é projetado como um sistema ponto a ponto e para ter uma cópia de repo completa em cada máquina local. Você pode oferecer o git a outros desenvolvedores que preferem fazê-lo dessa maneira, e pode continuar sendo apenas um complemento ao SVN que grupos de trabalho individuais (sejam um ou mais desenvolvedores, formais ou ad-hoc) usam internamente. E quando chega o dia em que o veterano cede, passa para outro departamento ou empresa ou se põe em um canto irrecuperável com suas políticas de SVN, você começa a limpar tudo.

Apenas fale com eles. Sou um desenvolvedor sênior, mas há coisas que não sei. Essa é a natureza do negócio. Se eles se tornarem defensivos ou agressivos, isso é um problema de personalidade do desenvolvedor e isso deve ser tratado pelo líder da equipe, ou se eles são o líder da equipe, pelo chefe.

Comece uma iniciativa de sacola marrom, uma vez em poucas semanas alguém realiza uma conversa na hora do almoço sobre algo que conhece e a apresenta aos outros.

Você usa isso como desculpa para apresentar o SVN em detalhes e talvez um pouco do pensamento por trás de algumas alternativas.

Algumas semanas depois, alguém pode tentar.

Vou tentar dar algumas dicas apoiadas pela minha experiência pessoal.

Um dos meus colegas de equipe, apesar de experiente, não entende realmente o SVN. Naturalmente, áreas em branco em seu mapa mental representando oceanos de SVN fazem com que ele adote padrões de uso bastante estranhos.

Por exemplo, ele havia declarado uma política de "1 commit de SVN por dia por desenvolvedor" porque, caso contrário, "o servidor logo ficaria sem espaço em disco". Quando expliquei a ele que os commits SVN são deltas, não cópias completas, ele respondeu com dúvida e ainda hoje não tenho muita certeza se ele entende o que isso significa.

Mesmo se o espaço em disco fosse um problema, você sempre poderia confirmar muitos arquivos de uma só vez, então acho que o que ele sugere é a solução errada. Além disso, é possível desperdiçar muito espaço verificando arquivos binários grandes, porque o SVN não armazena deltas para arquivos binários. Um check-in por dia também é ruim porque obriga a confirmar alterações que não pertencem juntas, por exemplo, no caso de você corrigir mais de um bug por dia.

A solução que adotamos em nossa empresa é que existe um filtro que rejeita qualquer confirmação que contenha arquivos binários. Podemos forçar a confirmação usando uma palavra-chave especial no comentário do check-in (precisamos mostrar ao SVN que sabemos o que estamos fazendo). Uma vez em um ano ou dois, um gerente de projeto arquiva ramificações antigas e as remove do repositório. Com essa estratégia, não temos problemas de espaço que conheço (nosso repositório suporta vários projetos diferentes e possui mais de 100000 revisões).

Resumindo, você pode dizer a ele que concorda com ele que o espaço em disco é uma questão importante, mas, por outro lado, ressalte

1. a importância de check-ins relacionados a recursos em vez de um check-in diário monolítico;
2. o fato de que, ao verificar um arquivo binário grande por dia, é possível preencher o disco de qualquer maneira.

Em seguida, você pode sugerir que você tenha uma reunião (possivelmente com outros desenvolvedores ou administradores de sistema) para discutir estratégias para manter o uso do espaço em disco sob controle (por exemplo, filtros de arquivos binários, backup regular e limpeza de antigos ramos não utilizados).

Também tivemos uma discussão acalorada sobre a inclusão da configuração do projeto Eclipse no SVN. Meu companheiro de equipe insistiu que deveríamos, embora tenha causado muitos conflitos inúteis. Eu era contra manter arquivos de configuração de desenvolvedor individuais no SVN. Por fim, meu colega de equipe teve a prática de fazer check-out de toda a árvore de código-fonte após cada confirmação para garantir que "o código comprometido no repositório funcione". Essa foi a razão pela qual ele foi tão inflexível em manter a configuração do projeto no SVN - para que fosse fácil reimportar o projeto. Quando expliquei que o commit sincroniza a cópia de trabalho com byte por byte remoto, o que torna o check-out desnecessário, meu colega de equipe respondeu com dúvida novamente e, por fim, considerou insignificante todo o problema.

Na minha opinião, nossa equipe perde tempo resolvendo conflitos SVN nos arquivos de configuração do projeto que contêm apenas configurações específicas do desenvolvedor que não precisam ser compartilhadas com o SCM. Toda essa bagunça porque alguém adaptou o processo em torno de suposições incorretas.

Você usa um servidor de construção? Temos um servidor de compilação que verifica o projeto completo e o compila todas as noites. Na manhã seguinte, os testadores têm um instalador pronto para teste do produto (se a compilação principal foi executada corretamente) e nós (os desenvolvedores) temos um relatório de compilação com todos os avisos (e erros, caso haja algum). Claro, você precisa configurar os arquivos de configuração padrão para o servidor de compilação e verificá-los. Cada desenvolvedor pode, em seguida, vê-los junto com o resto do projeto, mas eles não estão autorizados a verificar em quaisquer alterações locais.

Nesse cenário, você aborda a necessidade dele de poder verificar o projeto completo e construí-lo a qualquer momento. Você também evita gastar tempo para mesclar alterações que não deveriam ter sido verificadas em primeiro lugar, porque não fazem parte do produto: o produto é a construção principal e deve ser mantido limpo. Se alguém interromper a construção principal (por exemplo, verificando seu próprio arquivo .project), você poderá reverter as alterações ou forçar o desenvolvedor a corrigir o problema.

Talvez se ele levantar a questão novamente, você pode sugerir novamente uma reunião (possivelmente com outros desenvolvedores) e encontrar uma estratégia comum juntos.

Como convencer um colega de equipe, que se considera sênior, a entender melhor os conceitos básicos de SVN?

Penso que a melhor estratégia seria evitar levar o conflito a um nível pessoal e, em vez disso, discutir os problemas em questão e as possíveis soluções. Se você tem a impressão de que ele está procurando um confronto pessoal, aqui estão algumas sugestões (novamente, por experiência pessoal):

• Como está a dinâmica da sua equipe? Seus outros colegas estão tendo uma experiência semelhante com este companheiro de equipe? Existem muitas dicas pequenas, não muito explícitas, que uma equipe pode dar a um de seus membros para desencorajar certos comportamentos (pequenas piadas ou observações) e incentivar o confronto construtivo (propondo uma reunião ou trazendo um tópico informalmente durante uma pausa para o café). ) Às vezes, uma boa equipe pode isolar rapidamente um elemento perturbador e trazer as coisas de volta ao normal.
• Quão boa é a sua gestão de pessoas? Tivemos um caso de conflito em nossa empresa e o chefe de pessoal teve que intervir para esclarecer a situação. Não foi bom, mas às vezes a atmosfera de trabalho se deteriora tanto que não melhora por si só. Espero que esse não seja o seu caso (ainda não tenho a impressão de que tenha chegado tão longe), mas é sempre bom saber se você tem uma boa administração de pessoal ou se precisa resolver conflitos por conta própria.

Por que estou escrevendo isso? Você diz que deseja "convencer um colega de equipe, que se considera mais velho, a entender melhor os conceitos básicos de SVN". Para mim, parece que o conflito pode estar ficando muito pessoal. Alguns psicólogos sustentam que 70% da nossa comunicação está no nível emocional; se esse nível não está funcionando, as pessoas param de falar sobre fatos porque estão ocupadas demais lidando com emoções.

Portanto, além de explicar seus pontos, você também pode tentar fazer algo para melhorar a comunicação. Convidar um café ou almoçar juntos, conversar rapidamente sobre um tópico que não está relacionado ao trabalho, etc., pode melhorar a comunicação e chamar a atenção do colega para os fatos importantes que você deseja que ele entenda. Se ele aceita esse tipo de comunicação, talvez os conflitos que você teve até agora estejam relacionados ao fato de que você não se conhece bem e houve alguns pequenos mal-entendidos, mas ele provavelmente está aberto para construir uma colaboração construtiva. Se ele recusar, pode haver uma hostilidade mais profunda do lado dele.

Nesse caso, acho que você deve esperar até que seus papéis se tornem mais claros. Se o seu companheiro de equipe não possui oficialmente uma classificação mais alta que a sua, ele não faz sentido ficar irritado com suas tentativas de melhorar as coisas. Com o tempo, ele terá que aceitar ou fazer papel de bobo se continuar tentando mostrar que sabe melhor. Se ele tem uma classificação mais alta, você deve encontrar uma maneira de fazê-lo entender que isso não está em discussão: suas observações visam melhorar a produtividade e não prejudicar sua posição, isso deve ser 100% claro. Quando os papéis foram esclarecidos, se ele ainda não pode aceitar sugestões ou críticas construtivas, então ele realmente deve ter algum problema com a auto-estima ou algo assim.

Portanto, se todas as estratégias acima falharem e você continuar se sentindo (muito) frustrado, receio que a única coisa razoável a fazer seja arrumar suas coisas e procurar um lugar melhor. Fiz essa experiência há três anos e encontrei uma empresa muito melhor na qual estou muito satisfeito agora. Talvez este não seja o seu caso (espero que não, é claro), mas tente entender esse ponto também.

Apenas meus 2 centavos.

Aponte para ele algum material de aprendizagem sobre como o SVN funciona e quais são as melhores práticas ao usar o SVN.

Como o @Peter diz - escolha suas batalhas com cuidado e não gaste sua energia lutando com alguém que obviamente não entende o básico. O SVN não é exatamente uma tecnologia de ponta e está aqui há um tempo, então há informações suficientes sobre isso.

Tente manter um registro do 'SVN desperdiçando tempo'. Sempre que houver um problema de conflito / checkout / versão que precise ser resolvido, anote quanto tempo você / a equipe levou para resolvê-lo. Se você estiver perdendo um tempo considerável toda semana, aumente isso com ele e a gerência. Tenho certeza de que o gerenciamento em breve solicitará soluções se eles perceberem que a produtividade pode ser melhorada com simples mudanças no processo de trabalho.

Ou tente convencer seu colega a ter uma semana de teste em que a equipe use seu sistema de check-ins (se isso for facilmente possível com seus projetos e base de código atuais). Prometa a ele que, se não der certo, você poderá voltar ao sistema antigo depois que a semana terminar. Mas ele pode voltar depois de tentar sozinho.

1. Deixe o Subversion resolver o problema para você. Do jeito que você diz, seu colega de trabalho é relativamente pouco sofisticado no que diz respeito ao Subversion. Nesse caso, uma solução técnica pode ser uma boa opção. Se o restante da equipe concordar e você puder obter a bênção do seu gerente, adicione um global-ignorescampo ao arquivo de configuração do repositório para excluir os arquivos .project e outros que você não deseja sob controle de versão.

2. Ajude-o. Em vez de impor sua maneira de fazer as coisas, tente ajudar o cara a fazer as coisas do seu jeito, sem causar problemas para todos os outros. Se seu colega de trabalho estiver trabalhando em seu próprio ramo, você realmente não deve se importar com o que ele comete. Se ele deseja confirmar seu arquivo .project para poder fazer check-out de uma cópia nova de todo o diretório, isso não é problema para você. A única coisa com a qual você deve se preocupar é que ele não mescla seu arquivo .project de volta ao ramo de desenvolvimento comum. Isso deve ser fácil de gerenciar, novamente, configurando a propriedade ignore no ramo de desenvolvimento para excluir o arquivo .project.

3. Procure apoio de cima. Não entre no argumento "você não é o meu chefe" com ele, mas se o comportamento dele estiver causando um problema para você, verifique se o gerente está ciente da situação. Se você não tem certeza de como abordar seu gerente, tente pedir conselhos: "Mike, estou tentando conversar com Larry, mas não estou conseguindo. Ele insiste em X, Y e Z e o resto de nós gasta muito tempo desnecessário trabalhando com os problemas que isso cria. Você pode me dar alguma dica sobre como lidar com o cara? "

4. Ignore-o. Por que alguém da equipe ouve esse cara? Ele tem alguma autoridade real sobre o projeto? Quem se importa se ele declara uma política de uma confirmação por desenvolvedor se ele não tem o poder de aplicá-la? Deixe-o pensar que ele é Yertle, a Tartaruga, se isso o faz se sentir melhor, apenas não deixe que ele crie problemas reais para você.

Ponha o cara demitido e termine com o arrastamento do calcanhar e a mancha óbvia em relação às novas tecnologias. Ou realmente surpreenda e comece a usar o GIT. Se ele não conseguir entender o SVn, ele certamente ficará impressionado com o GIT.

Você parece estar travando uma batalha perdida, mas pode vencer. Maquiavel, em O príncipe, descreveu como é difícil mudar o status quo. Eu sugeriria ler esse capítulo novamente e, talvez, não fazer o que ele sugere - pode ser duro.

Você deve levar suas preocupações para o desenvolvedor sênior em particular e não se esqueça de criticar construtivamente a maneira como as coisas são feitas, e não ele ou qualquer outro desenvolvedor. Depois, ofereça uma palestra e escreva um guia de práticas recomendadas. Mostre a eles como entender melhor o SVN facilitará sua vida. Por fim, trata-se de custos e eficiência. Se você pode provar que seu caminho melhora as coisas sem pisar no pé, então você pode ganhar este.

Tente entender por que os caras mais velhos estão usando o repositório como ele é. Quais são as preocupações deles? O que eles estão tentando alcançar? Como você pode ajudá-los a serem mais produtivos? Acima de tudo, tente manter uma abordagem calma e profissional. É fácil ficar frustrado. Seja assertivo: assertividade no trabalho: um guia prático para lidar com situações embaraçosas de Ken Back e Kate Back é uma boa leitura. Finalmente, pense "como eu me convenceria a mudar?". Seja um advogado honesto do diabo e isso pode ajudá-lo a encontrar boas respostas e perguntas a serem feitas.

Como uma nota lateral, eu teria o cuidado de usar o humor. Pode fazer maravilhas ou fazer você parecer um idiota. Assim, eu evitaria isso.

Fundamentalmente, escolha suas batalhas com cuidado, pois você pode não vencer esta. Se for esse o caso, não se importe mais ou procure um emprego diferente. Duro, eu sei.

Eu já estive no inverso de sua posição há cerca de 8 anos, quando o SVN era uma tecnologia razoavelmente nova. Eu era desenvolvedor sênior e fui solicitado / com bug para instalar o SVN por um desenvolvedor júnior (na verdade, ele era um suporte de TI com mais precisão do que um desenvolvedor). Tomei uma mente aberta, apesar das minhas suspeitas iniciais sobre aumento da carga de trabalho, complexidade desnecessária, etc ... e depois me tornei um grande fã disso.

Na minha opinião, pelo que você descreveu, esse problema definitivamente se resume às personalidades da equipe - a teimosia dele está se mostrando um obstáculo para a equipe como um todo nessa questão. Você pode estar melhor se afastando neste momento e deixando a pressão do resto da equipe aumentar naturalmente para forçar a mão dele.

É praticamente um caso de "falta de autoridade" e uma pessoa que aplica o poder de seu próprio medo para manter as coisas "sob controle"

Para resolver isso, encontre alguém que tenha inspirado seu companheiro de equipe ou alguém que ele respeite e que seja capaz de explicar a urgência de usar algo como SVN. Dessa forma, seu medo de mudar e basicamente "perder a autoridade" não está em jogo porque não é um membro da equipe dizendo a ele o que fazer. Eu evitaria usar alguém como gerente para falar com esse cara, porque isso apenas aumenta a pressão e pode até criar uma situação mais estressante para você.

Recentemente, li Conduzindo mudanças técnicas: por que as pessoas de sua equipe não agem com base em boas idéias e como convencê-las de que devem , publicado pela The Pragmatic Programmers. Este livro fornece um histórico que você deve conhecer antes de tentar introduzir mudanças técnicas, vários padrões em pessoas que se opõem ou se recusam a mudar, técnicas para implementar as mudanças e estratégias para maximizar o uso dessas técnicas e de todas as pessoas ao redor. vocês.

Com base no seu post, eu diria que seu companheiro de equipe provavelmente se enquadra no padrão Não Informado ou Cínico, mas ele também pode ser um caso do Irracional. Algumas das técnicas recomendadas para combater esse tipo de pessoa são ganhar experiência no ambiente de destino, para que você possa encontrar quaisquer problemas e apresentar respostas para os problemas que outras pessoas enfrentarão antes que elas aconteçam, resolver o problema certo, transmitir a mensagem apaixonadamente, mas sem ser excessivamente zeloso, demonstre as técnicas mostrando claramente as vantagens de seus métodos e ferramentas e venda-as organicamente (mas não crie problemas apenas para resolvê-las), obtenha publicidade e participe do resto de sua equipe. No entanto, se ele é irracional, há

Finalmente, então você começa a usar essas técnicas, precisa de uma estratégia geral. É importante não deixar que aqueles que são ativamente hostis ou irracionais o atrapalhem - os ignore. Em vez disso, encontre pessoas que você possa demonstrar e convença de que você tem uma maneira melhor e aplique as técnicas apropriadas baseadas nelas como indivíduo. Mais uma vez, as pessoas veem as melhorias que seu conhecimento oferece, use-as para continuar a convencer outras pessoas. Por fim, use esse esforço de base para convencer a gerência de que existe uma maneira melhor, mas certifique-se de colocá-la em termos que eles possam entender (tempo, dinheiro, qualidade).

Não tente "convencer" esse cara de nada. As pessoas (até os programadores) não vão responder ou respeitar argumentos lógicos / razoáveis ​​de alguém que vêem como juniores a elas. Portanto, não perca seu fôlego. Em vez disso, trabalhe na construção de um nível de confiança com essa pessoa. Essa pessoa ouvirá o que você tem a dizer apenas quando estiver aberta.

Enquanto isso, você tem problemas reais:

1. O cara verifica seu arquivo .project no repositório: apenas ignore-o. você não precisa modificar o arquivo, nem mais ninguém na equipe que conhece melhor. Deixe ir. Se isso der ao seu "membro sênior" um sentimento caloroso e feliz como um cobertor de segurança, que assim seja.
2. Há um orçamento percebido no espaço em disco: esse é o motivo pelo qual o Sr. Senior dita 1 compromisso por dia. A escassez de espaço é real ou percebida? Mesmo que seja apenas percebido, talvez haja algo que você possa fazer para mudar essa percepção. Isso deve ser tratado imediatamente - se você tomar a iniciativa, também ajudará a criar confiança.

Devo acrescentar também que esse cara estará disposto a adotar melhores práticas de SVN quando achar que foram suas idéias. Isso exigirá um pouco de reflexão de sua parte, e ele provavelmente assumirá o crédito por estabelecer melhores práticas - mas você concorda com isso.