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.

Empolgação da equipe de desenvolvimento

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.

Por dentro da cabeça do time de desenvolvimento no LABootcamp

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!

Reação do time avaliando os resultados do LABootcamp

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.

Equipe trabalhando unida para construir o LABScrum

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.

Processo macro LAB Scrum V1
Subprocesso de desenvolvimento

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.

“Isso parece extremamente promissor”

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.

“E isso, cavalheiros, é o SCRUM”

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:

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:

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.

Equipe de Desenvolvimento experimentando as novas mudanças

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:

Reuniões até a quarta Sprint!
Reuniões após a quarta Sprint!

Além das dificuldades, os #erros tiveram um papel fundamental em nosso processo de aprendizagem. Listamos os principais:

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:

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

Vemos você no futuro!

LABHacker

Laboratório Hacker da Câmara dos Deputados

LABHacker

Laboratório Hacker da Câmara dos Deputados

João Paulo N. Soares

Written by

LABHacker

Laboratório Hacker da Câmara dos Deputados