Uma nova metodologia de trabalho para o LAB

Olá nós somos o João Paulo Nunes e Thiago Nogueira ambos formados em Engenharia de Software pela UnB e desenvolvedores do LABHacker. Hoje vamos utilizar esse espaço para contar um pouco como foi a experiência da construção do processo de desenvolvimento que criamos e propomos em Janeiro de 2020 no LABootcamp. No início do ano o LAB estava passado por um processo de reestruturação de processos de trabalho e alinhando com todos os colaboradores como seriam os entregáveis do LAB para este ano.

Nós participamos de todo o processo de definição de trabalho do LAB e como engenheiros de software demos nosso ponto de vista sobre como seria interessante ter um processo de desenvolvimento definido. Foi alinhado que uma das entregas finais do LABootcamp seria a definição de uma proposta de processo de desenvolvimento. Isso deixou toda a equipe de desenvolvimento do LAB muito empolgada, pois é extremamente gratificante poder participar do processo de criação de como será realizado o seu trabalho.

Empolgação da equipe de desenvolvimento

A seguir vamos contar como foi todo o processo de construção do nosso primeiro processo de trabalho, este foi denominado como LAB Scrum 1.0. Será descrito como foi o processo de ideação, onde foi inspirado, motivo das adaptações que fizemos e como fizemos para implementar no contexto do LABHacker. Descreveremos também sobre as dificuldades encontradas, erros e quais foram as melhorias identificadas para o processo.

O Bootcamp

A ideia do Bootcamp começou a ser discutida em dezembro de 2019, quando o LAB estava em um processo de estruturação. Foi levantado a possibilidade de criar um evento de alinhamento entre o time de desenvolvimento, pois a maioria da equipe tinha entrado recentemente no laboratório e necessitava de um alinhamento geral para conseguir tocar novos projetos.

Neste evento a equipe ficou imersa por um mês alinhando sobre as tecnologias de projetos já realizados no LAB e novas tecnologias que a equipe gostaria de utilizar. Foram realizadas várias palestras com membros da equipe apresentado as tecnologias e contextualizado de como elas poderiam ser aplicadas nos nossos projetos. Foi um momento MUITO LEGAL, recebemos diversas visitas que também estavam interessadas em compartilhar conhecimento. Expandimos bastante os nossos conhecimentos a ponto de algumas vezes explodir nossas cabeças.

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

Discutiu-se sobre como era o processo de desenvolvimento utilizado, mesmo não havendo nenhum processo mapeado, a forma de desenvolvimento estava internalizado apenas na cabeça da equipe. Por conta da mudança da equipe e do novo propósito do laboratório um dos entregáveis do LABootcamp foi a definição de um processo que o time de desenvolvimento gostaria de seguir baseado em tudo que foi visto e discutido em todas as palestras do bootcamp.

O LABootcamp foi um sucesso, pois nele definimos um novo modelo de trabalho no LAB. Conseguimos construir uma arquitetura robusta que facilitaria o desacoplamento das novos projetos em duas soluções distintas de frontend e backend. Também foi definido as tecnologias que já estão sendo utilizadas nos novos projetos construídos pelo laboratório neste ano de 2020.

Reação do time avaliando os resultados do LABootcamp

A seguir iremos detalhar como foi o processo de construção do LAB Scrum V1 durante o LABootcamp, os motivos da construção deste processo e onde foram as inspirações para a criação deste modelo de desenvolvimento. Iremos discutir também experiências prévias do time de desenvolvimento que foram utilizadas para construir um processo que agregasse e solucionasse problemas enfrentados anteriormente.

Equipe trabalhando unida para construir o LABScrum

A ideia de construção do LABScrum veio de um problema que o time de desenvolvimento estava enfrentando, a falta de planejamento sobre o trabalho que precisava ser executado durante a semana. Diversas vezes os desenvolvedores ficavam ociosos sem saber qual problema poderia ser atacado e algumas vezes haviam problemas demais para um curto período de tempo. Começou-se a se investigar o motivo que gerava esse problema e foi identificado que faltava um planejamento detalhado de um curto período de tempo.

A falta de planejamento detalhada também causava um outro problema, o de alta dependência dos desenvolvedores dos gerentes do projeto, pois todos os dias era necessário que os gestores sentassem com o time de desenvolvimento para decidir qual seria as atividades diárias e quando essas atividades eram finalizadas uma nova reunião era feita para decidir novas atividades. Quando um gestor estava em reuniões externas do LAB o time de desenvolvimento ficava ocioso esperando uma nova demanda.

Isso causa alguns picos de trabalho intenso e outros momentos onde a equipe de desenvolvimento não tem tanta demanda, seria interessante uma metodologia que pudesse mitigar estes picos e ociosidades de trabalho. Uma solução levantada para este problema seria o mapeamento das funcionalidades do sistema de maneira com que o desenvolvedor pudesse recorrer a algum lugar para verificar o que precisa ser feito e como deve ser implementado.

O problema relacionado a entender a solução e construir suas dependências de desenvolvimento era algo que impactava bastante o time de desenvolvimento, dificultava bastante a paralelização das atividades, pois como não se tinha a ideia do sistema como um todo muitas funcionalidades ficavam dependentes umas das outras.

Por conta desses motivos listados anteriormente começou-se a se discutir a necessidade de uma metodologia de desenvolvimento que fizesse sentido para o LAB e que pudesse ser adaptada ao contexto muito específico do laboratório. Como nós, João Paulo e Thiago Nogueira, já havíamos trabalhado com metodologias ágeis em um contexto parecido colocamos essa alternativa para implementar no LAB.

A metodologia vinha de encontro com o que o laboratório estava começando a se propor a entregar com toda a reforma interna. Seria uma equipe pequena de desenvolvedores responsáveis por realizar entregas rápidas e que pudessem ser validadas com o cliente durante todo o processo de criação. Como o LABHacker iria começar a entregar soluções minimamente viáveis que pudessem validar a ideia que foi levantada no Nós do LAB a metodologia de desenvolvimento ágil se encaixou bem no contexto.

Além de entregas rápidas e que pudessem ter validação um ponto que foi levantado como um dos principais foi que o LAB não daria manutenção nos sistemas desenvolvidos. Essa decisão fez com que fosse repensado todo o processo de desenvolvimento interno do laboratório, pois o software seria repassado a uma outra área da casa depois de validado para que essa nova área realizasse a manutenção no código.

Para que pudesse ser feito esse repasse com o menor impacto possível para a nova equipe que assumiria a 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. Por conta destes pontos optou-se pela utilização de uma metodologia ágil.

O processo foi pensado seguindo o Guia do Scrum e todas as atividades que estão presentes no processo de desenvolvimento foram mapeadas deste guia. Algumas modificações se fizeram necessárias devido ao contexto que estamos inseridos e com é a composição do time de desenvolvimento. A seguir é possível verificar como ficou mapeado a primeira versão do processo LAB Scrum V1.

Processo macro LAB Scrum V1

Subprocesso de desenvolvimento

Usando o processo no Linguagem Simples

Quando o projeto Linguagem Simples foi apresentado para nós, eu e o Thiago vimos ali a oportunidade colocar em prática conhecimentos que obtivemos ao longo de projetos passados e que sabíamos que nos ajudariam a chegar em um bom produto final.

Após apresentarmos essa proposta para a equipe técnica onde todos “pilharam”, decidimos conversar com os gerentes do projeto sobre esse assunto. Essa conversa era muito importante pois seria a adoção de um novo processo, uma nova forma de pensar, totalmente diferente do que era feito anteriormente e com isso seria necessário que toda a equipe estivesse alinhada e acreditasse no que seria feito.

“Isso parece extremamente promissor”

Antes de começar as sprints de desenvolvimento fizemos pequenos treinamentos com toda a equipe do projeto(gerentes, designers, desenvolvedores, etc) onde apresentamos mais sobre metodologia ágil, SCRUM e o processo que havia sido mapeado no LABootcamp.

“E isso, cavalheiros, é o SCRUM”

Após alguns debates fizemos algumas modificações nas atribuições de cada ator da metodologia e nas políticas que consideramos necessárias para o nosso contexto, onde chegamos nas 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 do projeto 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, onde ao longo do projeto este papel seria rotativo, de forma a não sobrecarregar somente um membro ao longo do projeto.
• Como o SCRUM Master seria um dos membros da equipe técnica, somente os desenvolvedores e o designer estariam presentes nas daily’s.
• Caso o SCRUM Master notasse empecilhos que dependessem de uma maior articulação para serem resolvidos, os mesmos seriam informados ao PO(gestor do projeto) para que as providências necessárias pudessem ser tomadas em conjunto.

Com a metodologia de trabalho definida partimos para as definições técnicas do projeto. A equipe optou por uma arquitetura com o frontend e o backend desacoplados, possibilitando assim que as equipes trabalhassem de forma paralela ao longo do projeto, onde o frontend seria implementado utilizando ReactJS e o backend em Django e esta seria a primeira vez que a equipe trabalharia com essa stack em um projeto dentro do LAB.

Com essa arquitetura definida a equipe fechou outros acordos técnicos, onde padrões de qualidade seriam adotados desde a primeira sprint do projeto e obrigatoriamente seguidos até a última sprint. Entre esses padrões para manter a qualidade do projeto 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;
• Pull requests feitos deveriam ser avaliados pelo outro membro da equipe correspondente;
• Análise estática do código por meio da ferramenta Code Climate, onde indicadores como complexidade ciclomática seriam observados;

Usar uma nova metodologia, uma nova Stack de desenvolvimento, novas políticas em um ambiente não habituado a metodologias ágeis eram ingredientes perfeitos para levar o projeto ao fracasso. Porém sabíamos que poderíamos entregar um projeto sensacional e com qualidade, por isso nos permitimos experimentar! E essa foi uma lição enorme para a equipe, mas sem spoilers no momento.

Equipe de Desenvolvimento experimentando as novas mudanças

Com todas as definições feitas, iniciamos as sprints de desenvolvimento do projeto. As duas primeiras sprints foram dedicadas a configuração dos repositórios, das ferramentas e ao desenvolvimento do esquema de autenticação entre as duas diferentes camadas da aplicação que seria feita por meio de um token JWT.

As primeiras sprints levantaram algumas desconfianças em relação à metodologia por parte de alguns membros da equipe, pois diversas novas atividades foram inseridas que pareciam não levar a lugar nenhum e somente atrapalhavam o desenvolvimento. Mas que ao longo do tempo foram demonstrando a sua importância e justificando sua utilização.

Agora vamos falar um pouco mais sobre essa jornada, vamos falar sobre nossas dificuldades, erros, acertos e principalmente dos aprendizados.

Nesse projeto com uma nova metodologia, uma nova arquitetura, novas tecnologias e com um nova equipe não tivemos nenhuma dificuldade pois somos perfeitos como o Fred(gerente do projeto)falou.

Quem dera poder falar isso, e sem dúvidas passamos por muitas dificuldades mas que levaram a diversos aprendizados. A seguir vamos citar as principais que enfrentamos:

• A primeira dificuldade que podemos citar está ligada a nova arquitetura, essa arquitetura tendo 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 a resposta a 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 sempre manter uma cobertura alta de testes o que foi difícil principalmente nas primeiras sprints pois 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ça nestas e como consequência a 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 em que está na base do projeto(como servidores, firewall, segurança), em diversos momentos foi necessário que solicitações fossem feitas a outros locais para que demandas fossem solucionadas. Acabamos, por desconhecimento de algumas burocracias e do funcionamento do processo de solicitação, prevendo um tempo errado para a solução das mesmas e assim atrasando a implementação o que levou a diversos ajustes do planejamento ao longo das Sprints.
• Obter dados foi um outro caminho difícil, em muitas Sprints tivemos que parar a implementação para vasculhar diversos locais onde uma informação poderia ser obtida. Sendo assim verdadeiros detetives.
• Como última dificuldade que vou listar está a falta de compreensão da nova metodologia de forma uniforme por toda a equipe. Essa falta de compreensão está ligada principalmente a delimitação das áreas de atuação de cada papel, gerando assim diversos conflitos nas primeiras sprints porém que foi se ajustando ao longo do processo e equipe ficou totalmente alinhada a partir da quarta sprint.

Reuniões até a quarta Sprint!

Reuniões após a quarta Sprint!

Além das dificuldades tivemos outro ator muito importante para os aprendizados que tivemos como LAB, os erros(e errar faz parte). Entre esses erros:

• 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 totalmente o fluxo de uma funcionalidade, onde vimos que somente o protótipo não era o 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 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çamos 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 um pouco ignorados.

E com essas dificuldades e erros chegamos aos aprendizados! E como LAB podemos dizer, nos permitir errar, experimentar, tentar nos trouxe aprendizados valiosos que queremos compartilhar! E vamos lá para nossa lista de aprendizados (é a última lista, eu prometo) :

• As entregas feitas pelo design para a equipe Dev precisam ser melhor detalhadas em uma linguagem em comum acordo;
• Por mais difícil que seguir uma metodologia em um projeto possa ser, vale a pena;
• Uma arquitetura desacoplada permite uma implementação paralela das funcionalidades;
• Blindar a equipe de desenvolvimento de reuniões e demandas externas no meio das Sprints trouxe resultados positivos;
• É possível utilizar tecnologias atuais e fazerem as mesmas conversarem mesmo em um contexto que não acredite que possa ser utilizado;
• Fazer testes e manter a cobertura de código é fundamental para um projeto desse tamanho;
• Um projeto deve ter seu tempo definido previamente, onde não estimar uma data para o fim do mesmo gera uma ansiedade na equipe e o escopo jamais fica delimitado;
• É 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 aprendizado 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 LAB!

Esse foi o primeiro texto para falar um pouco sobre nossa experiência em aplicar metodologias ágeis em um projeto dentro de uma Instituição Pública. E como um pequeno spoiler vamos depois falar sobre o LABScrum 2.0, que é novo processo desenhado a partir dos aprendizados e queremos compartilhar com vocês.

Quer conhecer um pouco mais sobre esse projeto? Acesse os outros textos aqui no Medium do LAB sobre ele e também veja nossos repositórios no Github! Lá você encontra a documentação de cada sprint do projeto assim como o código fonte do Linguagem Simples:

Documentação: https://github.com/labhackercd/linguagem-simples-backend/wiki
Repositório Backend: https://github.com/labhackercd/linguagem-simples-backend

Repositório Frontend: https://github.com/labhackercd/linguagem-simples-front

Vejo você no futuro!