Uma nova metodologia de trabalho para o LAB
Olá! Nós somos o João Paulo N. Soares e Thiago Nogueira, ambos formados em Engenharia de Software pela Universidade de Brasília (UnB) e desenvolvedores do LABHacker. Hoje vamos utilizar este espaço para contar um pouco sobre a experiência de construção do método de desenvolvimento que propomos em janeiro de 2020, no evento LABootcamp. O LAB estava passando por uma fase de reestruturação dos procedimentos e alinhamento de trabalho de todos os colaboradores, planejando como seriam os entregáveis para este ano.
Nós participamos de toda a concepção do sistema de trabalho do LAB e, como engenheiros de software, reforçamos que seria interessante ter um processo de desenvolvimento definido. A visão foi acatada e acordamos que uma das entregas finais do LABootcamp seria uma proposta de processo de desenvolvimento. Isso deixou toda a equipe de devs do LAB muito empolgada! É extremamente gratificante poder participar da criação de como será realizado o seu próprio trabalho.
O LABootcamp
A ideia do LABootcamp começou a ser discutida em dezembro de 2019, quando o LAB estava em uma etapa de reestruturação. Nesse momento, foi levantada a possibilidade de criar um evento de engajamento e troca entre o time de desenvolvedores, considerando que a maioria da equipe era nova no Laboratório e necessitava de um alinhamento geral para conseguir tocar novos projetos.
Nesse evento, os devs ficaram imersos durante um mês, debatendo tecnologias de projetos já realizados no LAB e novas possibilidades que a equipe gostaria de experimentar. Foram diversas palestras com membros da equipe apresentando as ferramentas e contextualizando como elas poderiam ser aplicadas. Um momento MUITO LEGAL! Recebemos várias visitas que também estavam interessadas em compartilhar conhecimento e, assim, expandimos bastante nossos horizontes.
Em seguida, discutiu-se como era o processo de desenvolvimento utilizado — mesmo não havendo nenhum método mapeado, a forma de construção estava internalizada apenas na cabeça da equipe. Considerando a mudança do time e tendo o Laboratório adotado um novo propósito, nós, desenvolvedores, definimos o plano de trabalho que gostaríamos de seguir, fundamentado em todo o debate promovido nas palestras do evento.
O LABootcamp foi um sucesso! A partir dele, conseguimos construir uma arquitetura robusta que facilitaria o desacoplamento dos novos projetos em duas soluções distintas de frontend e backend. Para além disso, pudemos estabelecer as tecnologias que nos seriam úteis nas etapas seguintes — e que já foram implementadas nos novos projetos do LAB neste ano de 2020!
A seguir, vamos contar como foi todo o caminho de construção do nosso primeiro modelo de trabalho, denominado LABScrum 1.0. Falaremos como foi a trajetória de ideação; em que foi inspirado; o motivo das adaptações realizadas; e como fizemos para implementá-lo no contexto do LABHacker. Comentaremos, também, sobre experiências prévias do time de desenvolvimento utilizadas para traçar um processo que agregasse e solucionasse problemas enfrentados anteriormente.
LABScrum 1.0
A ideia de construção do LABScrum surgiu a partir de um problema que os devs estavam enfrentando: a falta de um planejamento semanal de execução. Era comum que, na rotina de trabalho, os desenvolvedores ficassem ociosos, sem saber qual problema atacar primeiro e, por diversas vezes, havia obstáculos demais para ultrapassar em um curto período de tempo.
Essa falta de planejamento também causava outro problema: a constante dependência aos gerentes do projeto. Todos os dias era necessário que os gestores sentassem com a equipe de desenvolvimento para decidir quais seriam as atividades. Ao serem finalizadas, fazia-se uma nova reunião com o mesmo propósito e, caso o gestor não estivesse presente, os devs precisavam aguardar por uma nova demanda. Isso resultava em um desequilíbrio na rotina, com picos de trabalho intensos e momentos inoperantes.
Após reflexões, chegou-se à conclusão de que seria necessário construir um plano detalhado de curto prazo, reconhecendo e mapeando as funcionalidades do sistema, de forma a identificar os espaços nos quais os desenvolvedores poderiam consultar as tarefas a serem realizadas e a maneira como deveriam ser implementadas. Assim, tanto os devs quanto os gestores teriam mais independência e possibilidade de proatividade.
Após detalhar todas essas questões particulares do sistema, passamos a debater sobre a metodologia de implementação da solução no LAB — que possui um cenário muito específico. Felizmente, nós, João Paulo e Thiago Nogueira, já tínhamos experiência com um contexto parecido no qual fizemos o uso de metodologias ágeis. Assim, propomos essa alternativa, que auxiliaria, inclusive, na viabilidade do planejamento colaborativo estruturado no Nós do LAB.
Metodologia ágil: uma equipe pequena de desenvolvedores responsáveis por realizar entregas rápidas e passíveis de serem validadas com o cliente durante todo o processo de criação.
Além de possibilitar entregas rápidas, um dos pontos principais levantados foi que o LAB não ofertaria manutenção nos sistemas desenvolvidos. A partir disso, a equipe repensou todo o processo de programação interna do Laboratório, de forma que, após a validação do software, este seria repassado a uma outra área da Casa, que ficaria responsável pela manutenção/revisão no código.
Para que o repasse do software pudesse ser feito com o menor impacto possível à equipe que assumiria sua manutenção, o time de desenvolvimento do LAB precisava garantir a qualidade do código — nas metodologias ágeis, principalmente no Scrum, a qualidade do código é algo fundamental. Estávamos no caminho correto!
O método foi pensado seguindo o Guia do Scrum, e todas as atividades que estão presentes no processo de desenvolvimento foram mapeadas por meio dele. Algumas modificações se fizeram necessárias devido à composição do time de desenvolvimento e ao contexto em que estamos inseridos.
Usando o processo no Plenário Fácil
Quando o projeto Plenário Fácil foi apresentado para nós, eu e o Thiago vimos ali a oportunidade de colocar em prática os conhecimentos que tivemos ao longo de projetos passados e que sabíamos que nos ajudariam a chegar a um bom produto final. Após apresentarmos a metodologia do Scrum como proposta para a equipe técnica e todos “pilharem”, decidimos levar a ideia para os gerentes do projeto.
Essa conversa foi muito importante. A partir dela, adotamos, oficialmente, um novo processo, uma nova forma de pensar, totalmente diferente do que era feito antes. Foi necessário que toda a equipe estivesse alinhada e acreditasse na mudança de perspectiva.
Antes de começar as sprints de desenvolvimento, fizemos pequenos treinamentos com toda a equipe do Plenário Fácil — gerentes, designers, desenvolvedores, etc — em que nos aprofundamos na metodologia ágil, no Scrum e no processo que havia sido mapeado no LABootcamp.
Após debates, propomos algumas modificações nas atribuições de cada ator do processo e nas políticas que consideramos necessárias para o nosso contexto, chegando às seguintes definições:
- O papel de PO (Product Owner) seria feito pelo gestor do projeto, visto que ele tinha um conhecimento melhor do modelo de negócio, assim como um maior poder de negociação com outras partes necessárias;
- O papel de SCRUM Master seria feito por um membro da equipe técnica. Esta atribuição seria rotativa ao longo do projeto, para não sobrecarregar nenhum membro;
- Como o SCRUM Master seria um dos membros da equipe técnica, somente os desenvolvedores e o designer estariam presentes nas daily’s (reuniões diárias);
- Caso o SCRUM Master notasse empecilhos que dependessem de uma maior articulação para serem resolvidos, isso seria informado ao PO (gestor do projeto) para que as providências necessárias pudessem ser tomadas em conjunto.
Com a metodologia de trabalho, partimos para as definições técnicas do Plenário Fácil. Optamos por uma arquitetura com o frontend e o backend desacoplados, possibilitando, assim, que as equipes trabalhassem de maneira paralela ao longo do projeto. O frontend seria implementado utilizando ReactJS e o backend em Django. Esta seria a primeira vez que trabalharíamos com essa stack — conjunto de tecnologias para criar aplicações — em um projeto dentro do LAB.
Na sequência, fechamos outros acordos técnicos, como os padrões de qualidade que seriam adotados desde a primeira sprint do projeto e, obrigatoriamente, seguidos até a última. Entre esses padrões, podemos citar:
- Integração contínua ao longo de todo o desenvolvimento;
- Realização de testes unitários com o objetivo de alcançar o máximo de cobertura de código;
- Avaliação de pull requests feitos por outro membro da equipe correspondente;
- Análise estática do código por meio da ferramenta Code Climate, na qual indicadores como complexidade ciclomática seriam observados.
Um novo procedimento, uma nova stack de desenvolvimento e novas políticas em um ambiente não habituado a metodologias ágeis poderiam ser ingredientes perfeitos para levar o projeto ao fracasso. Porém, nos permitimos experimentar: acreditávamos na nossa capacidade de entregar um produto de qualidade.
Essa foi uma lição enorme para a equipe, mas, por hora, não daremos spoilers.
Com todas as definições feitas, iniciamos as sprints. As duas primeiras foram dedicadas à configuração dos repositórios e das ferramentas, e ao desenvolvimento do esquema de autenticação entre as duas diferentes camadas da aplicação, que seria feito por meio de um token JWT.
Essa etapa levantou algumas desconfianças em relação à metodologia por parte de alguns membros da equipe, pois uma série de novas atividades foram inseridas e pareciam não levar a lugar nenhum, somente atrapalhavam o desenvolvimento. Felizmente, ao longo do tempo, essas operações foram demonstrando sua importância e justificando suas utilizações.
Uma jornada de dificuldades, erros, acertos e, principalmente, aprendizados
Não tivemos nenhuma dificuldade em implementar uma nova metodologia, arquitetura, tecnologias ou uma nova equipe no projeto do Plenário Fácil, pois, como o Fred (gerente do projeto) falou, “somos perfeitos!” — quem dera podermos dizer isso! Sem dúvidas, passamos por muitos desafios, mas esses nos levaram a diversos aprendizados. A seguir vamos citar os principais #perrengues:
- Arquitetura: A primeira dificuldade está ligada à nova arquitetura. Essa estrutura com o front e back desacoplados leva a todo um novo estilo de programar e pensar. Ela fez com que a comunicação da equipe e as respostas às mudanças fossem mais importantes do que nunca, tornando-as parte da nossa rotina — olha a metodologia ágil fazendo efeito!;
- Testes: Com a nossa nova política de qualidade definida, a equipe precisava manter sempre uma cobertura alta de testes, o que foi difícil (principalmente nas primeiras sprints). Isso demandava mais tempo de implementação, e a falta de conhecimento da tecnologia aumentou a complexidade;
- Mudança de requisitos: Começamos a desenvolver o projeto sem que todas as principais funcionalidades tivessem sido mapeadas e compreendidas de uma melhor forma com o público-alvo, o que levou a mudanças e, como consequência, à necessidade de refatoração do código que já havia sido implementado;
- Subestimamos solicitações externas: Como a equipe de desenvolvimento do LAB não tem controle de toda a infraestrutura que está na base do projeto — como servidores, firewall, segurança — , em diversos momentos foi necessário pedir a solução de demandas para outras áreas. Acabamos, por desconhecimento de algumas burocracias e do funcionamento do processo de solicitação, avaliando errado o tempo necessário e, assim, atrasando a implementação. Isso levou a diversos ajustes do planejamento ao longo das sprints.
- Obtenção de dados: Outro ponto difícil. Em muitas sprints, tivemos que parar a implementação para vasculhar, como detetives, diversos locais onde uma informação poderia ser obtida.
- Uniformidade de conhecimento: A última dificuldade que listamos é a falta de compreensão da nova metodologia de maneira uniforme por toda a equipe. Esse fator está ligado, principalmente, à delimitação das áreas de atuação de cada papel, o que gerou conflitos nas primeiras sprints. Porém, isso foi se ajustando ao longo do processo e a equipe ficou totalmente alinhada a partir da quarta sprint.
Além das dificuldades, os #erros tiveram um papel fundamental em nosso processo de aprendizagem. Listamos os principais:
- Não definir completamente os critérios de aceitação das histórias, gerando dívidas técnicas para sprints subsequentes. Isso ocorria principalmente por não compreender todo o fluxo de uma funcionalidade. Percebemos, então, que somente o protótipo não era suficiente para essa total compreensão;
- Pontuar as histórias de forma diferente ao longo das sprints, não seguindo um padrão. Isso fez com que a equipe não pudesse estimar corretamente um velocity (capacidade de entrega) ao longo do projeto;
- Deixar o Scrum Master como um membro da equipe de Dev. Isso fez com que o papel não fosse desempenhado corretamente, pois o membro com essa responsabilidade acabava ficando com muitas atividades;
- Começar a implementar em código sem o design do produto estar definido, levando a muitas mudanças de requisitos;
- Não seguir todas as políticas da metodologia. Em um determinado momento do projeto, várias demandas começaram a surgir e alguns eventos da metodologia foram deixados um pouco de lado.
Com essas dificuldades e erros, chegamos aos #aprendizados! E, como um LAB pode errar, experimentar e tentar sempre, resolvemos compartilhar estes conhecimentos valiosos — é a última lista, a gente promete:
- As entregas feitas pelo design para a equipe de Dev precisam ser mais bem detalhadas, em uma linguagem de comum acordo;
- Por mais difícil que seguir uma metodologia possa ser, vale a pena;
- Uma arquitetura desacoplada permite uma implementação paralela das funcionalidades;
- A blindagem da equipe de desenvolvimento, para não participar de reuniões e demandas externas no meio das sprints, trouxe resultados positivos;
- É possível utilizar tecnologias atuais e fazê-las conversarem, mesmo em um contexto em que não aparenta ser viável;
- A aplicação de testes e manutenção da cobertura de código são fundamentais para um projeto desse tamanho;
- O tempo do projeto deve ser definido previamente. Não considerar uma data para o seu término gera grande ansiedade na equipe e dificuldade para delimitação do escopo;
- É necessário um maior entendimento do processo de design e do processo de desenvolvimento, para assim entender melhor como os dois conversam;
- Reuniões de planejamento/retrospectiva da sprint devem ocorrer no mesmo dia;
- Errar faz parte;
- E o mais importante: é totalmente possível utilizar metodologias no contexto de instituições públicas!!!
Talvez você esteja se perguntando: “E o que eles fizeram com essas informações? Será que isso foi realmente utilizado?”, e, sim, utilizamos essas informações para melhorar o LABHacker!
Esse foi o primeiro texto para falarmos um pouco sobre nossa experiência com aplicação de metodologias ágeis em um projeto dentro de uma instituição pública. Como um pequeno spoiler: em breve compartilharemos com vocês o LABScrum 2.0, que é o novo processo desenhado a partir destes aprendizados.
Saiba mais sobre LABootcamp e sobre Plenário Fácil acessando os outros textos aqui no Medium do LAB e em nosso canal no YouTube. Ah! E temos repositórios no Github, onde você também encontra a documentação de cada sprint do projeto, assim como o código-fonte: Documentação | Repositório Backend | Repositório Frontend
