Seis meses depois – Experiência de como entrar em um grande projeto

Ah algum tempo atrás eu escrevi um post sobre como foram os primeiros dias quando entrei em um grande projeto na ThoughtWorks.
Bom, seis meses depois eu parei pra refletir sobre o que eu fiz de certo/errado – e o feedback que recebi – e resolvi compartilhar a experiencia para quem quiser algumas dicas para entrar em novos projetos – grandes ou pequenos.

Entendendo o problema

Antes de falar o que deu certo ou errado é importante dar algum contexto para que os pontos positivos e negativos sejam avaliados corretamente e evitar interpretações erradas.

Time grande e distribuído

Talvez a característica mais forte do projeto que entrei seja o tamanho da equipe e o fato de que a equipe não está localizada toda em um único escritório. A equipe conta com mais de 15 pares de desenvolvedores além de possuir uma larga variedade de papéis como: Analistas de Negócios (BA), Analistas de Qualidade (QA), Gerentes de Iteração (IM), etc. Além da quantidade de pessoas, ainda pesa o fato de não estarem todas no mesmo local e nem no mesmo fuso horário, dificultando comunicação e sincronização entre os vários papéis.

Base de código grande e antiga

A base de código do projeto também é incrivelmente grande. O projeto possui mais de 5 anos de desenvolvimento e utiliza Ruby on Rails, desde a versão 1.2, como framework base. Então muitas das facilidades que já são providas por versões atuais do RoR não existiam naquela época, desde gerenciamento automático de Fuso Horário até as validações de modelos. Muito precisou ser feito e ainda estamos tentando remover alguns impedimentos para utilizar novas versões.
Some a isso um domínio complexo e não tão explorado que precisa ser entendido tanto por devs quanto por BAs, IMs, etc.

Infraestrutura complexa

Não só a base de código, mas também a infraestrutura para suportar o projeto também são igualmente complexas, desde memcached para realização de cache distribuída de objetos até tungsten para replicação de dados.
Além disso, as ferramentas utilizadas para o desenvolvimento na equipe também eram muito diferentes. Eu trabalhava com RoR e não utilizava nenhuma IDE, apenas editores de textos. A equipe toda utilizava como editor de texto o Vim o que aumentou ainda mais a dificuldade para conseguir se tornar produtivo.

O que deu certo

Em um projeto grande não se pode ter tudo
Acho que um dos conselhos que mais me ajudou foi o de não tentar entender todo o aplicativo de uma vez só. É difícil tentar entregar valor quando você não sabe o que precisa fazer, então eu tentei focar meus esforços em pequenas partes do sistema, assim, mesmo não entendendo a maioria do que era falado em reuniões, consegui entender bem o que eu conhecia.

Conheça a linguagem/framework base

Um fator que me ajudou bastante foi ter conhecimento sobre Ruby e Rails, mesmo que as versões utilizadas no projeto não sejam as mais recentes, que eu tinha estudado. Vale muita a pena conhecer a fundo a linguagem e o framework utilizados no projeto. Os posts mais recentes do blog são inspirados no que eu aprendi no dia-a-dia do projeto e ajudaram bastante a entender melhor decisões técnicas feitas.

Equipe grande pode ser bom

Apesar da equipe grande ser aparentemente um problema, é possível tornar isso uma vantagem pois você tem várias pessoas, provavelmente com conhecimento diferente do sistema, que podem lhe ajudar a superar as dificuldades.
Uma característica da ThoughtWorks é a forte utilização da programação em par, geralmente pareamos 100% do tempo, isso me ajudou bastante a ganhar experiência com o projeto, desde as mágicas que são bastante utilizadas por desenvolvedores experientes de ruby até utilizar os atalhos e configurações do vim.

Tire o máximo de proveito dos testes

Por ser uma base de código gigantesca, e por ser desenvolvido baseado nos princípios ágeis desde o começo, a suíte de testes é igualmente grande, o que facilitou bastante desenvolver novas funcionalidades, pois os testes explicavam muito bem como os objetos funcionavam e quais os relacionamentos entre eles.

Esteja perto do cliente

Por ser uma equipe distribuída, um dos problemas era ficar longe do cliente, o que dificulta entender os motivos para as decisões do negócio e você fica com a impressão de estar só entregando código. Geralmente o cliente é a própria empresa, então isso não chega nem a ser uma preocupação, mas quando o cliente está bem distante da equipe é muito importante conhecer o negócio e as pessoas que constroem ele.

O poderia ter sido melhor

Agora vou falar um pouco sobre coisas que fiz errado, baseado no feedback que tive de meus colegas e de reflexões próprias.

Quem tem medo de código? o/

Talvez o meu maior problema tenha sido o medo. Entrar em uma empresa grande e em um projeto grande é bem difícil, então eu tive muito medo de fazer a menor alteração que fosse no código. Isso me bloqueou de fazer sugestões ou tentar descobrir as coisas por mim mesmo. Depois de um tempo eu vi que a estrutura do projeto não era tão frágil assim e ai pude aprender mais (principalmente fazendo besteira com o git). Mas se desde o começo eu tivesse encarado diretamente o código, acho que teria feito um progresso mais rápido.

Conheça não só o código

Uma coisa que senti muita falta de conhecer o sistema e as funcionalidades. Após algum tempo eu conhecia alguma coisa sobre o código mas não fazia a menor ideia de como aquilo tudo se integrava ou fazia sentido. Isso atrapalha pois você fica alheio as decisões e não consegue opinar sobre as direções que o time deve seguir.

Melhore o seu aprendizado

Algumas pessoas, assim como eu, aprendem muito mais rápido alguma coisa visualizando ao invés de ler. Infelizmente eu não tirei muito proveito de modelos visuais logo quando entrei no projeto, principalmente devido a facilidade que um par mais experiente proporciona. O problema não é necessariamente sobre utilizar modelos visuais ou não, mas por confiar no seu par mais experiente e não se esforçar tanto para aprender.

Use e abuse de Feedback

Uma coisa que é bem enfatizada na ThoughtWorks é dar e receber feedback, eu acho que poderia ter feito mais isso, principalmente no começo quando você está tentando achar seu próprio caminho. Nesse ponto a programação em par ajudam muito, pois você sempre tem alguém próximo para perguntar como está indo.

Saber apertar o freio e pedir ajuda

Logo quando entrei foi muito difícil seguir o ritmo do time, com todas as reuniões e várias pessoas falando sobre vários assuntos. Uma coisa que poderia ter me ajudado bastante seria tomar notas de pontos durante a reunião para poder perguntar aos mais experientes depois.

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s