Julio Bitencourt - Web Developer

Como mudei minha carreira — parte II — Organizando o projeto e gerenciando uma equipe de desenvolvimento

March 10, 2020

Artigo publicado originalmente no medium

A importância de estar sempre atualizado

Photo by [Glenn Carstens-Peters](https://unsplash.com/photos/RLw-UC03Gwc?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)Photo by Glenn Carstens-Peters on Unsplash

Este é o primeiro artigo relatando os passos que eu dei para mudar minha carreira em aproximadamente 3 anos, depois de quebrar minha empresa. A introdução da série você pode ler clicando aqui.

  • Você conhece SOLR?
  • Conheço, nunca usei mas conheço sim. Mas olha, tem um tal de Elasticsearch aí que é bem legal! Podemos dar uma olhada nele. Ambos são baseados no Apache Lucene.

Você conhece SOLR. Foi a pergunta que eu ouvi em um evento e que foi o gatilho para minha empreitada atual.

Minha resposta foi dada apenas com conhecimento teórico. Eu nunca tinha usado nenhuma daquelas ferramentas.

Eu sempre fui um consumidor voraz de conteúdos técnicos sobre desenvolvimento de software e tecnologia em geral. Me lembro do saudoso Google Reader, onde eu tinha centenas de inscrições em RSS de blogs técnicos.

Sou programador PHP desde 2003, mas também procuro acompanhar outras comunidades de desenvolvimento web. Desta forma, saberei quem procurar quando precisar de algo fora do mundo LAMP, como foi o caso da pergunta do início deste texto.

Se eu tivesse oito horas para derrubar uma árvore, passaria seis afiando meu machado.

Abraham Lincoln

E foi em um evento de Ruby/Python, ou seja, nada a ver com PHP, que eu vi uma das melhores palestras sobre agilidade e gestão de times.

Conteúdo que não tinha tanta aplicação prática para mim naquele momento, mas que me deixou com a sensação de que se eu tivesse visto aquilo antes poderia ter mudado a história da minha empresa. Vida que segue.

Meses depois, quando surgiu a oportunidade de criar um novo projeto de software, me lembrei da palestra do Fábio Akita – @akitaonrails – na Rupy 2014 em São José dos Campos.

Ele resumiu em 45 minutos, quase todos os tópicos que norteiam o gerenciamento de um time de desenvolvimento ágil de software, relatando como ele mesmo trabalha na empresa em que é sócio.

Na palestra o Fábio Akita cita as melhores práticas, problemas frequentes, ferramentas, e principalmente: comportamento durante o dia a dia de uma equipe de desenvolvimento ágil de software.

Recomendo que você pare a leitura agora, assista, e depois volte para cá. Vale a pena, eu garanto.

Pragmatismo

Era preciso encarar o contexto de uma startup: recursos limitados e incerteza.

Em um cenário assim, qualquer decisão errada pode colocar tudo a perder, pois não existe espaço — nem dinheiro — para voltar e consertar o trabalho que pode ter levado meses para ser concluído.

As práticas de desenvolvimento ágil de software foram criadas por engenheiros de software que sofriam na pele a falha na entrega e atrasos constantes.

Recomendo a leitura de dois livros: Extreme Programming e Lean Startup. Estes livros foram muito úteis para mim.

Ok. Vamos seguir as metodologias ágeis. E agora?

Mise en place – Organizando as ideias

Mapas mentais são, ao meu ver, a ferramenta ideal para organizar ideias em um cenário onde não se sabe exatamente quais são os passos necessários para atingir os objetivos.

Recomendo o Mindmup, que foi a ferramenta utilizada lá no início do projeto.

Partindo do mapa mental listamos as principais funcionalidades do Keeva e criamos um roadmap de 6 meses de desenvolvimento.

Utilizar mapas mentais foi essencial neste processo. Em 2 reuniões já tínhamos a visão geral do sistema e também da infraestrutura necessária para rodá-lo.

A partir daí já poderíamos partir para o desenvolvimento. Só que não, antes era preciso montar o time. Falarei sobre isto em um post futuro.

Além do Mindmup, abaixo eu listo algumas ferramentas que utilizamos no dia a dia do time.

Código. Acima de tudo, código

Escolhi o Bitbucket para o gerenciamento do código fonte do projeto. Você deve estar se perguntando: por que não github?

Simples. No Bitbucket eu poderia usar repositórios privados na conta gratuita.

Lembra-se dos “recursos escassos” que eu citei acima? Então.

Mas hoje utilizamos a conta paga pois o time cresceu ?

Desde o início utilizamos Pull Requests, que sempre passavam pela minha revisão. Hoje eu não faço mais a revisão, pois o time está maduro e os processos são (quase) sempre respeitados.

Dica: Se você não usa Pull Requests e Code Review comece agora mesmo. O ganho de produtividade e qualidade no código é incrível. Recomento o episódio 64 do podcast Hipsters.tech, que aborda exatamente PRs e Code Review.

Hoje utilizamos GitFlow para o gerenciamento de branches e para organizar o caos um pouco.

SCRUM? Bom, não sei.

Demoramos para entrar nos eixos com relação ao SCRUM. Acredito que até hoje fazemos mais um “ScrumBut”, mas a metodologia está bem aderente ao nosso fluxo de trabalho.

Começamos com sprints semanais, reuniões de planning e review apenas. Nada funções estabelecidas (PO, Scrum Master, etc), retrospectiva ou daily meeting. O time era era muito pequeno e naquele momento utilizar todos os rituais do Scrum soava mais como uma burocracia desnecessária.

A partir da reunião de planning o time fazia a pontuação das estórias, que eram colocadas no Pivotal Tracker e iniciava o desenvolvimento das funcionalidades.

Notei que quando éramos fiéis aos processos as entregas eram feitas com grande qualidade e dentro dos prazos. Mas, quando surgia algum incêndio e atropelávamos as coisas, as entregas ficavam comprometidas.

Isto era perceptível na velocidade registrada pelo Pivotal Tracker. Ponto para o Scrum.

Gerenciamento de tarefas

O Pivotal Tracker foi a ferramenta escolhida para gerenciar o projeto puramente pela indicação feita na palestra do Fábio Akita, que eu citei acima neste texto.

Não testei nenhuma outra que fosse voltada ao mesmo problema que o Pivotal resolve. Com excessão do Trello — que eu gosto muito e uso para gerenciar meu time de marketing — mas acredito que as duas não se comparam pois atendem demandas diferentes.

O Pivotal Tracker é um software fantástico. Permite o gerenciamento detalhado das estórias, épicos, bugs, etc. Tudo bem alinhado às práticas ágeis como XP, Scrum e Kanban.

Recomendo fortemente a utilização do Pivotal Tracker. É daquelas ferramentas que valem cada centavo investido.

Mas nenhuma ferramenta resolverá seus problemas se o comportamento das pessoas que compõem o time não estiver alinhado com os objetivos.

Comunicação

Embora eu não seja muito fã de comunicação assíncrona, ou melhor, não sou fã de quem trata comunicação assíncrona como síncrona, o slack foi a opção mais óbvia na hora de escolher o sistema de Instant Messaging para o time.

Minha única crítica ao Slack no início do projeto era sua administração, que tinha uma UX sofrível, e a falta de threads, mas este problema foi resolvido depois de um tempo.

É muito importante que você combine com seu time uma certa forma de etiqueta para comunicação, inclusive na hora de pedir ajuda sobre bugs ou dificuldades técnicas.

Uma boa comunicação é fator crítico do sucesso de um time, e o Scrum estimula a comunicação constante e aberta.

Conclusão

Organizar um time de desenvolvimento e criar um produto do zero não é tarefa fácil.

Mas vivemos em uma era onde o acesso às informações permite que, com foco e dedicação, você aprenda muito.

É sempre importante frisar: faça uso das ferramentas. Um conjunto de softwares SaaS hoje custa muito menos do que as suítes de trabalho que só eram viáveis para grandes corporações alguns anos atrás.

Obrigado pela leitura!

Me siga no Twitter ou aqui mesmo no Medium para ficar sabendo quando os novos posts forem publicados.