Sou um desenvolvedor júnior que tem a capacidade de ajudar a moldar os processos da minha equipe se eu puder justificar a mudança e se isso ajudar a equipe a realizar o trabalho. Isso é novo para mim, pois minhas empresas anteriores tinham mais ou menos processos definidos rigidamente que vieram da administração.
Minha equipe é relativamente pequena e um pouco nova (<3 anos). Eles não têm:
- uma estrutura bem definida de desenvolvimento de software / gerenciamento de trabalho (como scrum)
- forte propriedade do produto
- funções bem definidas (por exemplo, a equipe de negócios fará testes manuais)
- reuniões stand-up regulares
- um processo consolidado de rastreamento de problemas (temos uma ferramenta, o processo ainda está sendo desenvolvido)
- uma unidade, sistema, regressão ou suíte de testes ou lista manual
- documentação sobre lógica e processos de negócios
- uma base de conhecimento para documentar dicas internas e voltadas para o cliente
E a lista continua. A gerência está aberta à implementação de melhorias desde que o valor seja justificado e ajude o trabalho mais importante (a saber, o desenvolvimento). A suposição subjacente, no entanto, é que você deve se apropriar da implementação, pois ninguém fará isso por você. E escusado será dizer que alguns dos projetos acima são não triviais, sem dúvida demorados, e claramente não são trabalhos de desenvolvimento.
Vale a pena o esforço de um desenvolvedor (júnior) para tentar avançar com o exposto com o passar do tempo? Ou é melhor "permanecer na sua via" e se concentrar no desenvolvimento, deixando a maior parte da definição e otimização do processo para o gerenciamento?
fonte
Respostas:
Boas respostas até agora, mas elas não cobrem todas as bases.
Na minha experiência, muitas pessoas recém-formadas na faculdade têm um conhecimento teórico fantástico - muito melhor do que eu ou muitos outros idosos com décadas construindo software para viver.
MAS, e isso é muito grande, esse conhecimento não se baseia em nenhum cenário prático. No mundo real, grande parte dessa teoria se esgota ou, pelo menos, deve ser tomada com um grão maciço de sal, pois na prática se verifica que não funciona tão bem em um cenário do mundo real.
Caso em questão: um aplicativo em que trabalhei há muito tempo foi projetado por um brilhante teórico de OO, arquitetado para seguir os princípios e a teoria de OO no T, com muitos padrões aplicados em todos os lugares.
Foi uma peça fantástica de design de software.
Infelizmente, isso resultou em pesadelo de produção e manutenção. A base de código era tão grande e complexa que era impossível mudar de lugar; Não porque era especialmente frágil, mas porque era tão complexa, ninguém se atreveu a tocá-lo com medo do que aconteceria (o arquiteto / designer original era um empreiteiro que havia muito tempo saíra).
Ele também teve um desempenho muito ruim, precisamente devido à estrutura de padrões em várias camadas e às bibliotecas de classes necessárias para o projeto. Por exemplo, clicar em um botão em uma tela para fazer uma única chamada ao banco de dados resultaria em várias centenas de instanciações de objetos e chamadas de método - tudo em nome de garantir um acoplamento flexível e coisas assim.
Esse arquiteto era professor universitário com vários livros sobre o tema em seu nome. Ele nunca trabalhou um dia como programador em um projeto comercial.
Pessoas com experiência prática em criação de software teriam percebido que monstruosidade a que o design inevitavelmente levaria e adotado uma abordagem mais pragmática, levando a um sistema mais fácil de manter e com melhor desempenho.
O mesmo se aplica a muitas outras coisas que você encontra quando se forma recém-formado ou mesmo como um novo funcionário em qualquer empresa. Não presuma que, porque sua base teórica diz que algo está errado ou abaixo do ideal, não há uma boa razão para que isso seja feito dessa maneira.
Mesmo agora, com mais de 20 anos de experiência no campo, tenho receio de criticar a maneira como as coisas são feitas nas empresas com as quais trabalho. Mencionarei de passagem que notei que as coisas são diferentes do que, na minha experiência, é a melhor, mas não de uma maneira beligerante. Isso geralmente leva a conversas interessantes sobre por que essas coisas são como são. Talvez as mudanças aconteçam e talvez não, dependendo se o valor de mudar as coisas é menor que o custo.
Não tenha medo de sugerir que as coisas podem ser feitas melhor, mas sempre certifique-se de que você não se mostre como o garoto que sabe tudo, mas como um colega de trabalho que está tentando e disposto a não apenas aprender, mas também ajudar a melhorar os processos para a melhoria da empresa, não apenas a correção teórica.
fonte
Sim, mas com muito cuidado!
Deixe-me esclarecer isso.
Você deve se esforçar para melhorar a habitabilidade do software. Se você olhar o código / equipe / negócio / projeto / gerenciamento e sua primeira resposta for tomar um banho, ele não será habitável. Se a sua primeira resposta for gritar sim! ... e depois reclamar quando você estiver fora do escritório, precisará tornar sua casa mais habitável. É um sentimento, e você saberá.
Dito isto, você está trabalhando em uma síntese muito complicada . Qualquer coisa que você faça provavelmente dará errado e provavelmente piorará as coisas, pelo menos a curto prazo, porque uma simples mudança tem ondulações. Então, primeiro, torne-se humilde, não quero dizer que sou um empurrão ou aceite que as coisas devem estar ruins; quero dizer, aceite o fato de que suas boas intenções vão afetá-lo violentamente.
O problema
Com a melhor das intenções, você pode achar que uma grande mudança precisa acontecer, e eu não discordo que essas situações existam, mas reserve um momento para pensar sobre isso. O sistema atual está funcionando, você e sua equipe estão produzindo código, talvez lento, talvez doloroso, mas está funcionando e todos vocês têm experiência em como fazer isso. Você sabe aproximadamente o que esperar; em resumo, você é um profissional nesse sistema.
Após a mudança radical, ninguém, exceto talvez o implementador, sabe o que esperar. Em resumo, todos foram redefinidos para um nível de neófito nesta parte do sistema. Isso não é bom. Os neófitos precisam aprender as novas regras que levam tempo. Nesse período, os neófitos estão cometendo erros porque não são praticados. Esses erros se tornam parte do sistema, com o qual você agora tem que conviver e não é tão perto agora.
Um caminho a seguir
Há momentos em que cortar, gravar e reconstruir é de longe o melhor que você pode fazer. É particularmente atraente se ninguém é praticado no sistema antigo, porque a única coisa que está sendo perdida é o conhecimento codificado. Se esse conhecimento é completamente incompreensível, então já está perdido, e recomeçar é a única opção. Por outro lado, se o método de codificação, ou como ele é usado, é problemático, mas está funcionando, esse conhecimento ainda é acessível, e talvez valha a pena manter, talvez não - Apenas não tome a decisão de ânimo leve.
A outra opção é trabalhar com o sistema para que todos tenham um quadro de referência, mas alterar pequenas partes do sistema para que todos na equipe estejam cientes ou, se não estiverem cientes da mudança, é fácil aviso e fácil de aprender. Essa é a base para as práticas chamadas Kaizen . Uma fórmula mais orientada para o desenvolvedor é apresentada na apresentação Shaving the Golden Yak, eu recomendo assistir e refletir sobre isso.
Portanto, encontre algo pequeno que possa ser mudado que melhore sua vida e, esperançosamente, o de alguns outros. Corrija ou melhore a situação. Isso lhe dará prática e experiência em colocar as mudanças em prática. Certifique-se de obter feedback: você poderia ter discutido melhor, se foi realmente útil, perturbou outra parte do sistema. Desenvolva sua percepção do que pode ser feito e como fazê-lo.
Agora, três coisas aconteceram:
Agora escolha outra coisa para melhorar, à medida que sua experiência aumenta e à medida que elimina problemas de baixo nível, você começa a enfrentar os problemas mais difíceis do sistema, mas pelo menos agora quando você diz que precisamos mudar o X:
fonte
Sim você pode. MAS...
Você tem que ter cuidado.
No início da minha carreira (há muito tempo) eu tive sorte / azar de entrar em um projeto de alguns meses como "Junior".
Como a primeira coisa que notei, não havia (OMG) nenhum repositório de código! Todas as mesclagens de código foram feitas manualmente, enviando arquivos zip entre si por correio.
Então fui ao meu (também novo) gerente e sugeri que tivéssemos um repositório. A resposta foi: Ok, organize-o ....
Portanto, organizar um repositório de código, sem ajuda, era novo na empresa, agora que foi uma experiência humilhante.
Quando eu configurei tudo, (choque) ninguém queria usá-lo. Por isso, tentei levar as coisas adiante e, felizmente, meu gerente entendeu a importância, então tive apoio.
Mas isso resultou em que eu não gostei muito e, infelizmente, recebi um apelido derivado do sistema de controle de origem.
Portanto, minha opinião sobre isso é: primeiro sinta os membros de sua equipe, o que eles acham importante configurar a seguir.
Talvez eles também tenham uma lista como a sua. Talvez eles tenham pensado em tudo e queriam fazer essa "coisa" na lista. Talvez eles .... (tanto faz) ....
Toda a equipe deve estar alinhada.
Mas se não estiverem, você ainda poderá trabalhar profissionalmente. E encontre pessoas que pensam e trabalhe em conjunto como você acha que isso deve ser feito. Se isso resultar em bons resultados, mais pessoas trabalharão com você; eventualmente, ele se tornará "o" processo.
Assim como no código, o mesmo para os processos de desenvolvimento: é necessária melhoria contínua.
Então sim, você deve sempre tentar melhorar o que é possível melhorar.
Mas lembre-se também de muitas pessoas com quem você está trabalhando, já podem ser profissionais, e elas sabem o que está errado e o que é necessário.
fonte
Sim, sempre vale a pena o seu esforço para tentar melhorar as coisas. Você sabe melhor quais os problemas que enfrenta, afinal.
Mas, como você mencionou, há muitos problemas a serem resolvidos e muitos desses problemas não são terrivelmente valiosos. E em muitos lugares, haverá barreiras intransponíveis ao seu sucesso ou outras pessoas que estão muito melhor posicionadas para defendê-las. Portanto, você deve sempre tentar melhorar as coisas, mesmo que isso signifique escolher quais coisas você gasta seu tempo tentando melhorar.
Porque no final, se você não faz parte da solução, faz parte do problema.
fonte
Sim. Mas a mudança organizacional é difícil, mesmo para os mais graduados; portanto, se você realmente quer fazer a diferença, faça da maneira certa:
Não durante as primeiras semanas: use esse tempo para:
Escolha suas batalhas. Consiga algumas vitórias iniciais : você pode chegar com energia para mudar tudo, mas isso não é realista. Concentre-se em algumas frutas baixas e mostre que suas idéias funcionam. Você quer que eles sejam receptivos a melhorias mais complexas. E lembre-se de que as coisas são mais fáceis nos livros.
Considere a implicação para outras pessoas : faço refatores que afetam muitos arquivos. Mesmo que eles melhorem o código, devo ser muito cuidadoso para evitar transformar as mesclas em algo chato. Tente também entender as razões pelas quais eles continuam trabalhando assim. Talvez eles não possam usar o Scrum porque não possuem testes e, compreensivelmente, têm medo de enviar código não testado para produção com freqüência. Escrever um teste confiável não é tarefa fácil. O código atual pode ser realmente difícil de testar. Além disso, a equipe não pode usar nem para escrever testes ou código testável. A base de código atual pode ser especialmente difícil de testar e precisa ser refatorada. Pode levar anos para mudar esse problema, mas pelo menos você pode se concentrar na causa raiz.
Não julgue. Não exija. Peça e ouça com atenção: este é um momento em que a comunicação é crítica e nós, os programadores, geralmente não somos muito bons em nuances sutis. Existem técnicas para ajudar . É fácil continuar pressionando nossa ideia, em vez de focar na resposta. Primeiro, verifique se eles acham que você conseguiu os pontos deles. Entenda que os sentimentos são importantes. O que essa mudança os faz sentir? medo? insuficiência? raiva? frustração? esperança? Preguiçoso? Estúpido? (Nunca faça as pessoas se sentirem estúpidas). É claro que você já fez muitas perguntas antes e isso evitará muitos passos falsos.
Lidere o exemplo : reclamar é fácil, criar a mudança é difícil. Mostre resultados e as pessoas acreditarão em você. Se eles não usam teste, você pode escrever seus testes de unidade. Se as pessoas não documentarem, você poderá compartilhar alguns documentos do Google com a equipe. Entenda que "Ok, faça" é um dos melhores cenários possíveis e você precisa entregar. Nesse caso, você precisa ter pensado quais recursos você precisará . Exemplo: dê-me uma pequena instância da Amazon e duas horas dos administradores de um servidor Jenkins
Mantenha-o pequeno e simples (e barato): você não deseja esperar por uma aprovação formal do orçamento ou seus chefes pensam que você está perdendo um tempo valioso de programadores caros. Seria ótimo ter esse código revisando o software ou avaliar várias ferramentas de código aberto, mas usaremos o repositório por enquanto.
Obtenha massa crítica: reúna o grupo de pessoas focadas na melhoria da qualidade. Você pode até ir com eles para conferências e pedir ajuda ou orientação. O Peopleware descreve o "despertar do fenômeno gigante", com a base da equipe literalmente se rebelando contra algumas práticas estúpidas que diminuem a produtividade. Isso individualmente teria sido realmente perigoso e eu não recomendaria. Mas se todo o grupo concorda que a mudança é mais fácil.
Dê um tempo. Depois vote em seus pés: você pode tentar por alguns meses até dois anos. Mas algumas empresas não têm soluções fáceis. Algumas equipes não querem mudar e não têm incentivos. E algumas bases de código são puro horror. Se você acha que é você contra o mundo, lembre-se de que há muitas ofertas no pool de empregos. Você quer aprender boas práticas e, a longo prazo, será melhor em um lugar com um salário ligeiramente menor, mas obtendo experiência que o tornará mais valioso.
Bônus: Se você conseguir anotá-lo em seu currículo / entrevistas. Como Junior, você geralmente tem muito pouco a dizer e criar uma mudança para melhor é sempre um ótimo sinal. Você quer ter uma visão muito clara e realista sobre o que você fez pessoalmente e o que foi trabalho de outras pessoas. Imagine a seguinte pergunta da entrevista.
fonte
Sim. Mas não as coisas que você sugere.
Fora da sua lista Os testes de unidade / integração são o único item em que você pode progredir.
Você pode começar a adicionar você mesmo com um investimento de tempo mínimo e mostrar valor instantâneo. É um problema técnico com benefícios amplamente aceitos e não afetará outras práticas de trabalho. Além disso, você adquire conhecimento sobre a base de código, mesmo que os resultados não sejam aceitos. Uma venda fácil.
Os outros geralmente são processos de negócios que envolvem a equipe inteira ou até outras equipes. Você pode sugerir melhorias, mas será difícil mudar para um funcionário júnior e o processo de mudá-las geralmente não é técnico e provavelmente não está relacionado ao seu trabalho normal.
Eu também sugeriria coisas como: configurar pipelines de CI, implantações automatizadas, versionamento, bibliotecas de empacotamento como coisas boas para atacar
fonte
Isso depende de:
Basicamente: é de sua responsabilidade gastar um tempo razoável defendendo o que você acha melhor - mas a decisão deve ser uma responsabilidade de equipe ou de gerenciamento. Lembre-se de que alienar pessoas raramente vale a pena, mesmo que você tenha melhores práticas.
fonte
Não comece com as coisas mais complicadas, como Scrum. Comece com as etapas mais fáceis possíveis.
Você não mencionou o gerenciamento de código-fonte. Você tem algum repositório de código-fonte (git, svn, cvs, ...)? Uma estratégia para marcação e ramificação? Essas são etapas simples que um iniciante pode executar. Leia quais problemas essas etapas (tentam) resolver e como isso ajuda sua empresa a reduzir custos (é nisso que a gerência está interessada).
O próximo passo pode ser compilações automatizadas, todas as noites ou diretamente após cada check-in, por exemplo, com Jenkins. Você também pode executar testes automaticamente. E adicione algumas ferramentas para medir a qualidade do código (oh sim: definir alguns padrões de codificação também é um bom passo).
Quanto ao scrum, leia melhor sobre "Extreme Programming" (XP). O Scrum é baseado em muitas idéias do XP e adiciona um processo formalizado ao seu redor - os conceitos do XP ainda podem ser usados sem esse processo.
Sugira coisas, forneça informações de base, tente convencer os outros a experimentá-las, analise os resultados, ... mas não espere muita cooperação dos outros: a maioria das pessoas prefere seguir seus velhos hábitos ruins. Mas quando você não tenta, nada vai melhorar.
fonte
Você disse que a equipe é bastante nova (3 anos); portanto, se você não pode introduzir alguns bons princípios agora, será mais difícil fazer isso 10 anos depois. Algumas das coisas que você mencionou, como o sistema de teste e versão, estão entre as que você já pode sugerir, mas não a jogue da mesma maneira sem enfatizar seus benefícios óbvios e escolher as ferramentas que sua pilha de desenvolvimento exige.
fonte
No começo, faça perguntas
Ao ler sua lista, sugiro as seguintes perguntas (consulte sua lista para ver como elas se encaixam):
Substitua as coisas entre colchetes, conforme apropriado, para fazer as perguntas fazerem sentido ou se ajustarem às suas prioridades. Considere reformular se minha redação não corresponder ao seu estilo.
Você já deve ter começado a fazer isso. Favorecer conversas individuais sobre conversas em grupo. Porque individualmente, você pode obter uma melhor leitura do que a outra pessoa pensa. Essa pessoa é para essa mudança? Contra isso? Fracamente? Raivosamente?
Quando você é novo, fazer perguntas é praticamente gratuito. As pessoas devem esperar que você faça perguntas. Mesmo que suas perguntas defendam implicitamente uma posição à qual eles se opõem, elas não devem ficar com raiva. Eles devem explicar por que se opõem a essa posição. Eu recomendo não discutir com eles. Discutir tende a endurecer posições mais do que convence. Observe quem tem qual posição e siga em frente.
Mais tarde, tome medidas
Procure maneiras pelas quais você e possivelmente outras pessoas (por exemplo, as que você anotou concordando com você anteriormente) possam iniciar as alterações desejadas. Nem todo mundo quer um stand-up? Por que não? Talvez aqueles de vocês que querem um possam ter sua própria posição. Não é tão eficaz quanto com toda a equipe, mas mais do que você tem agora.
Quando você tiver um impedimento (e supondo que você não possa compartilhar em pé), envie um email à equipe para obter ajuda.
Identifique quais devem ser os papéis, possivelmente com o apoio de outras pessoas que concordam com você. Comece sempre a ir às pessoas quando o trabalho envolve o papel que você (possivelmente um grupo que você) acha que elas deveriam ter. Se eles recuarem, peça que identifiquem quem deve ser o dono dessa função.
Peça aos proprietários do produto (que você identificou) que escrevam descrições de como eles acham que o produto deve funcionar agora e no futuro.
Instale uma estrutura de teste (se alguém preferir isso, tome uma decisão conjunta sobre qual estrutura) e use-a para seus projetos. Quando você estiver corrigindo erros, escreva testes. Documente isso no relatório de bug do rastreador de problemas (teste escrito demonstrando o bug, armazenado em [local]). Incentive outras pessoas a executar os testes quando fizerem alterações. Caso contrário, execute você mesmo os testes e envie os problemas ao rastreador, conforme necessário.
Se você puder obter suporte de gerenciamento, instale um software wiki ou similar e comece a documentar suas coisas. Se as pessoas fizerem perguntas que mostram que não leram a documentação, aponte-as nas páginas relevantes. Incentive-os a fazer mais perguntas se não entenderem a documentação. Se eles continuarem fazendo as perguntas abordadas na documentação, cite a documentação ao responder. Considere incentivá-los a atualizar o wiki se você achar que o problema foi estrutural e não eles não estão lendo.
Eu sugeriria apenas me concentrar em uma tarefa de cada vez. E certamente apenas aperte um de cada vez. Não force demais. Veja este exemplo de se esforçar mais do que o grupo queria. Concentre-se mais em mudar seu comportamento do que o deles. Se o seu caminho é o caminho certo, isso deve ser óbvio para as pessoas que o observam. Ações falam mais alto que palavras. Tente não se repetir com a mesma pessoa ao cutucar. Depois de levar o cavalo para a água, deixe a escolha de quando ou se deve beber para o outro.
Eventualmente, você estará sênior
Com o tempo, sua equipe contratará novas pessoas. Você deixará de ser o novo contratado e poderá defender suas posições com novas pessoas. Trabalhe com eles para fazer alterações. E você pode descobrir que está progredindo também com seus colegas de equipe existentes. Ou, se isso não funcionar, procure um novo emprego em que tenham melhores práticas. Não há pressa real. Você tem um emprego. Você pode esperar um pouco para ter um emprego melhor, melhorando esse ou encontrando um melhor.
fonte
Resposta curta : Não, por todos os motivos descritos nas outras respostas. Mesmo sendo um desenvolvedor de nível médio ou sênior, geralmente é melhor procurar primeiro entender quando ingressar em uma nova equipe.
Uma solução proposta :
1) sempre que vir algo que acha que deve ser aprimorado, tome nota! (em um caderno, em uma nota digital ...)
2) Após 6 meses, volte para suas anotações e verifique-as. Quantas idéias agora parecem inúteis e inadequadas? Muito provavelmente, você se salvou de vergonha. Se algumas idéias ainda se mantiverem, agora seria um bom momento para apresentá-las, se possível testando-as primeiro.
fonte
Resposta tardia e concorde com um bom conteúdo nas outras respostas.
Penso que é necessário salientar que uma questão fundamental aqui não são as práticas específicas, mas a cultura geral da equipe.
Tudo o resto pode seguir se houver um meio de alcançar a melhoria contínua .
Minha abordagem para conseguir isso é:
Eu acho que se você não tem sprints, ainda não possui retrospectivas regulares. Tudo que você precisa é de uma conversa com a equipe e, em seguida, agir.
Você pode facilmente começar a documentar processos. "Eu sou o cara novo, entendi direito? Deixe-me escrever isso." É importante, então, seguir o processo você mesmo ou tentar ligar para o local onde ele se rompe.
Talvez você comece com essas conversas sendo ad hoc e depois sugira rituais regulares.
A adoção dessa abordagem permite uma abordagem incremental e suave. Você pode evitar aparecer como um júnior que sabe tudo e tentar ser um facilitador para a equipe fazer mudanças.
Algumas considerações:
fonte