Como convencer meus colegas de equipe a seguir algumas regras básicas

Eu tenho um problema com meus colegas de equipe. Resumindo: somos três estudantes trabalhando em um projeto para uma competição. O projeto consiste em 2 aplicativos separados: um para Windows (que eu desenvolvo) e outro para Android (meus colegas são responsáveis ​​por desenvolvê-lo). Nossas bases de código nunca se cruzam, os aplicativos se comunicam por meio de ferramentas de terceiros.

O problema é o seguinte: Tenho alguma experiência trabalhando em equipes quando estudei em uma grande empresa no ano passado e tento impor alguns padrões de codificação para o nosso código. Também configurei um repositório git / wiki / software de colaboração que podemos usar para enviar ideias de código / gravação, protocolos de documentos e assim por diante, mas parece que sou o único que usa essas ferramentas.

Tentei dizer a eles que escrever código de qualidade e documentar cada etapa nos beneficiará a longo prazo, mas eles não parecem ver a vantagem disso. Também estava pensando em adicionar alguns testes de integração, mas pelo que vejo, desde que eles não usem as ferramentas atuais para facilitar sua vida, acho que não posso convencê-los da utilidade dos testes de integração.

A maior parte do código dos pares reside em seus computadores, eles não compartilham uma base de código comum e, como eu descobri, eles integraram suas peças ao conhecer e compartilhar código via usb stick.

Minha pergunta é: eu sou muito duro com esse assunto? Eu imponho algumas regras absurdas? Lembre-se de que este é um projeto pequeno, os requisitos são muito claros (criei documentos especificando o que os aplicativos devem fazer), três desenvolvedores qualificados podem fazer isso em 3 a 4 dias, para que não percebam a complexidade adicional da qualidade da escrita código, desde que o método atual funcione.

Existe alguma maneira de mostrar a eles o benefício de documentar código, usando git e assim por diante?

Minha pergunta é: eu sou muito duro com esse assunto?

Você pode levar um cavalo à água, mas não pode fazê-lo beber.

É difícil dizer se você é "muito duro", mas pode ser irreal esperar que seus colegas de equipe adotem toda a infraestrutura que você espera. E, sinceramente, se a equipe estiver trabalhando bem em conjunto, o uso de um wiki para se comunicar entre três pessoas provavelmente será um exagero.

Reduza suas expectativas e procure maneiras de atingir alguns de seus objetivos sem exigir que eles comecem a usar ferramentas que eles não conhecem. Se eles não souberem usar o git, provavelmente não serão beneficiados em nenhum caso. No entanto, você ainda deseja garantir a cópia de segurança de todo o código em caso de falha do disco rígido ou outra catástrofe; peça a eles que copiem periodicamente a pasta do projeto para um serviço de compartilhamento de arquivos on-line do Google Drive, Dropbox ou similar. Certifique-se de fazer o mesmo.

Minha atitude é que, se você puder aprender a fazer essas coisas em pequenos projetos, estará preparado quando surgirem grandes projetos.

Se eles seguirem boas práticas de desenvolvimento com este projeto, terão código a ser exibido para futuros empregadores e terão experiência que os tornaria valiosos como funcionários.

Se você quiser mais material para convencê-los, eu me referiria ao Programador Pragmático , ou Código Completo .

Por outro lado, considere cortá-los um pouco. Se o projeto é uma prova de conceito que está sendo adiada logo após a competição, considere deixá-los fazer o que quiserem. Eles podem estar lutando apenas para escrever o código em primeiro lugar, sem a sobrecarga mental das boas práticas.

Receio que as regras que você descreveu não sejam básicas.

A tarefa mais fácil da IMO é convencer seus colegas de equipe a usar alguns padrões de codificação. E uma maneira simples de conseguir isso é mostrar a eles o mesmo trecho de código, uma vez bem formatado e mal estilizado, peça para que leiam o código, entendam o que faz e permitam que eles se julguem.

O que acontece com o uso de um repositório git, pode ser um problema para iniciantes. Quando eu trabalhava em uma equipe de três pessoas em um projeto Android, tivemos muitos problemas com nosso sistema de controle de versão no início. Então, espero que seus colegas de equipe também tenham problemas.

Você mencionou que levaria de 3 a 4 dias para o desenvolvedor experiente concluir o projeto (presumo que a sua equipe levaria 2 a 3 vezes mais). Este é um período de tempo muito curto, portanto o argumento de que o uso de novas ferramentas ajudará a longo prazo simplesmente não funcionará.

O que você pode fazer é fazer demonstrações curtas e simples para mostrar como essas ferramentas são usadas. Cubra as funções mais básicas no início, sente-se ao lado delas e ajude-as a usar as ferramentas. Esteja preparado para executar todas as tarefas, como configurar o git, criar a estrutura da página da wiki etc.

Edit : Em resposta ao comentário, acho que estabelecer tarefas claras, estimativas e prazos e acompanhar o tempo gasto é mais importante do que usar git ou ferramentas semelhantes. Se você planeja trabalhar no aplicativo posteriormente, é muito importante acompanhar o que já está feito e quanto tempo cada recurso levou. Então, sugiro que você comece do gerenciamento de tarefas e prossiga para as ferramentas que deseja usar.

Na verdade, eu gosto dos pensamentos de Joel Spolsky, como ele descreveu em Como fazer as coisas quando você é apenas um grunhido . Para resumir:

1. Apenas faça - Escreva makefiles, crie um servidor de compilação diário etc.
2. Ninguém usa controle de origem ou bancos de dados de bugs? Comece a usá-los você mesmo. Se alguém relatar um bug no seu trabalho, peça a ele educadamente para usar o banco de dados de erros para relatar erros para que você possa acompanhá-los; caso contrário, você não será capaz de mantê-los na sua cabeça e consertá-los. Em qualquer projeto não trivial, haverá uma situação que só pode ser resolvida com o controle de origem: use o controle de origem para o código sozinho e mergulhe heroicamente para salvar o dia em que essa situação ocorrer. Quando isso acontece algumas vezes, eles ficam convencidos
3. Crie um bolso de excelência - faça as coisas certas por si mesmo: especificação, programação, etc. Como isso não parece um projeto de trabalho, não parece que você pode seguir esse conselho até o fim, pois não pode contratar novos membros da equipe que acreditam na sua mensagem
4. Torne-se inestimável - demonstre que você é um grande colaborador para consolidar sua influência na equipe. Caso contrário, você corre o risco de se tornar conhecido como uma pessoa que valoriza processos e ferramentas sobre os resultados

Documentação, Wiki, software de controle de versão, metodologias etc. são experiências e lições aprendidas ao longo do tempo; trabalhando em vários projetos e provavelmente em várias equipes. E geralmente fica com aqueles que já estão empregados ou que levam a indústria a sério. Como são estudantes, seus interesses provavelmente estão limitados ao que acontecerá no futuro. :)

Mas, para tentar responder à sua pergunta:

Se você estiver em uma equipe com eles, precisará aplicar o que considera importante de maneira a beneficiar seus interesses. Como exemplo: eles devem reclamar muito da quebra do código quando o usb o compartilha? Então, talvez, dê a eles uma maneira simples (não complicada) de usar o SVN (em vez de git) como uma ferramenta de controle de versão.

Também concordo com o comentário do arnaud.

Você viu o benefício de todas essas ferramentas quando estava trabalhando com elas e foi assim que viu valor nelas e por que entende o uso delas. Se seus companheiros de equipe não virem um valor agregado na maneira como fazem as coisas, eles não o aplicarão. E o triste é que isso conta para equipes compostas por pessoas com qualquer nível de experiência.

A abordagem tem problemas:

1. Sua abordagem não é simétrica. Seus outros membros da equipe precisam mudar, mas você não está aprendendo suas boas práticas. Impor regras em situações como essa é difícil. Uma abordagem melhor seria coletar boas regras e práticas de todos os membros da equipe e, em seguida, todos lerão o documento resultante.

2. Aprender é difícil. As regras de outras pessoas simplesmente não fazem sentido porque essas regras não têm a estrutura lógica que seus programadores estão esperando. A imposição de regras que não fazem sentido não é uma atividade útil.

3. Todo mundo aprendeu coisas diferentes. É natural que programadores de diferentes origens tenham aprendido coisas diferentes. Seus pontos fortes são diferentes e os estilos de escrever códigos diferentes. As ferramentas que eles usam são diferentes. A imposição de um conjunto de regras / ferramentas / estilos será um pesadelo, porque as limitações estão perdendo a força que esses desenvolvedores passaram anos aprendendo.
4. Mudança leva tempo. Enquanto a pessoa que inventou as regras que você está aplicando tem bastante facilidade em segui-las, todo mundo está sofrendo e gastando tempo aprendendo as novas regras. Essa é uma das razões pelas quais todos na equipe devem poder alterar as regras.
5. A escolha de ferramentas / convenções ou estilos de codificação para toda a equipe é uma atividade difícil . Isso só pode ser feito lentamente com o tempo, testando o que funciona e o que não está funcionando. Dar a uma equipe duas semanas para começar a seguir as 50 regras não vai funcionar.

Eu encontrei esse mesmo problema na universidade. Muitas pessoas simplesmente não estão dispostas a aprender uma maneira diferente (e talvez mais profissional) de trabalhar.

No entanto, se você possui sistemas em funcionamento e explica como usá-lo, muitas pessoas estão dispostas a experimentá-lo. Eu também acho que os repositórios estão muito pouco utilizados e as pessoas geralmente usam apenas algo como o dropbox.