Acertos, erros e experimentos com frameworks ágeis
Na Brainny, desde sua concepção, nos produtos por nós desenvolvidos, utilizamos por essência o Scrum para desenvolvermos nossos projetos, agregando práticas que julgamos interessantes de outras metodologias. Assim como muitas das empresas que se inspiram em tal metodologia, não podemos dizer que seguimos a risca o Scrum.
Como sugere o manifesto ágil, estamos preocupados em
Responder a mudanças mais que seguir um plano
E com isso, vamos aplicando as práticas conforme hoje, resolvem nosso problema. Amanhã, pode ser que seja diferente.
Neste artigo, vou contar um pouquinho sobre como nos organizamos e o que já fizemos enquanto empresa para desenvolvermos nossos projetos durante este primeiro ano de vida.
Ferramentas
Com relação a ferramentas, iniciamos as operações com todo o gerenciamento do projeto pelo próprio gitlab, junto com o versionamento de código. É uma ótima ferramenta, com recursos que nos possibilita administrar um projeto ágil de maneira satisfatória, desde que se utilize a versão profissional dela. Porém, na versão profissional o seu custo comparado ao popular Jira Software é mais alto considerando uma equipe de 10 membros, que é a nossa realidade. Além do que, o Jira possui um vasto número de opções de plugins que podemos adicionar nos nossos projetos. Quase todos eles são pagos, então, precisamos ter cuidado para selecionar plugins que realmente são importantes para nossas necessidades. Por isso, hoje, utilizamos o gitlab como repositório remoto e o Jira para gerenciamento dos nossos projetos.
Como ferramenta de comunicação utilizávamos o slack, que vejo como principal ponto positivo uma série de bots prontos e integrações com outras ferramentas para automatizar a comunicação. Negativamente, na sua versão gratuita tem limitação de caracteres, que quando excedida começa a descartar os conteúdos mais antigos. Com isso passamos a perder históricos que eram importantes dentro da empresa. Tínhamos duas opções: Pagar a versão Pro ou buscar um ferramenta alternativa. Hoje trabalhamos com Discord, que embora tenha sua essência voltada para games, nos entrega funcionalidades similares as do slack e mais facilidades interessantes, como a criação de canais de áudio e um layout mais amigável e sem limite de histórico de conteúdo. Como ponto negativo, não tem tanta integração com outras ferramentas.
Necessidades do cliente
É bastante comum trabalharmos em cima de casos de uso ou requisitos funcionais para definirmos nossas ações de desenvolvimento, porém, o scrum sugere o trabalho com histórias de usuários e critérios de aceitação desta história.
A história de usuário segue um template que identifica o tipo de usuário envolvido na história, o quê, e por quê aquela história é importante para ele e os critério de aceitação, que conforme o próprio nome sugere, destaca pontos que são importantes para que a futura entrega da funcionalidade seja aceita pelo cliente.
A partir das necessidades levantadas, tarefas que devem ser desenvolvidas pelo time são especificadas, conforme pode ser observado na figura acima, no Issue Checklist.
Vale comentar que estas tarefas poderiam ser criadas em novos cards, o que facilitaria a movimentação dos mesmos na board por parte da equipe de desenvolvimento, que foi a forma trabalhada por algum tempo e, embora se tenha alguns benefícios com essa organização, estamos optando por manter as tarefas referentes a uma história dentro da mesma para aumentar o foco da equipe nas história de usuário, e não em resolver problemas quaisquer da board.
Eventos Scrum
O Scrum sugere alguns eventos que precisam existir na iteração de uma sprint, tais como: Reunião de Planejamento da Sprint, Reunião diária, Revisão e Retrospectiva da Sprint. Cada um desses eventos tem uma sugestão de time-box e formatos de execução, vou contar para vocês como nós fazemos na Brainny.
Reunião de Planejamento da Sprint
Nossas sprints sempre são de duas semanas, e por isso, nossas reuniões de planejamento não costumam a passar de um turno. Nesta reunião é analisado o backlog já priorizado e organizado do produto para que a equipe selecione as histórias que entrarão na entrega, buscando sempre entregar o máximo de valor possível para o cliente.
Planning Poker
Para definir o esforço de cada história de usuário, utilizamos o planning poker, onde por um bom tempo utilizamos cartas com os valores da sequencia de fibonacci, conforme orienta o scrum, medindo esforço/peso de cada tarefa sem pensar em tempo. Assim se define a velocidade do time baseada em esforço e se faz a seleção de histórias para a sprint de forma que o somatório de esforço não ultrapasse a velocidade do time.
A prática funcionou bem, até que passamos a enfrentar um problema: Começamos a trabalhar prestando serviço para outras empresas de desenvolvimento de software que nos pediam uma estimativa de tempo para a execução das tarefas, e isso não era uma prática comum da equipe — estimar tempo. Como isso passou a ser um problema recorrente, para melhorar nossas estimativas para nossos parceiros, passamos a trabalhar o nosso planning poker baseado em tempo.
Reunião diária
A reunião diária, também conhecida como stand up meeting, tem como indicação ser uma reunião rápida de no máximo 15 minutos, em que os participantes respondem, em pé, três perguntas: O que fez ontem, o que fará hoje e se possui algum impedimento para realizar sua atividade.
Com a minha rotina de sala de aula, nem sempre consigo estar na empresa em horários relevantes para realizarmos a nossa reunião diária em formato adequado. Como alternativa, adotamos a utilização de um bot que todos os dias fazia as perguntas da daily para o time no slack às 9h e aguardava as respostas até as 10h, momento em que o bot fazia uma postagem com as respostas de toda a equipe. A estratégia me servia para acompanhar o que os membros do time estavam fazendo diariamente, porém, passei a perceber que cada membro reportava suas ações mas não lia as dos colegas.
Para resolver este problema, hoje eu me organizo para “fugir” no intervalo de aula, fazer a daily com o pessoal, pessoalmente ou por hangouts, e assim o time interage entre si. A documentação das ações são rabiscadas brevemente no Discord para retomada no dia seguinte.
Reunião de revisão
Na reunião de revisão o cliente é convidado a participar, e normalmente dura em torno de 2 horas. Nesta ele dará o aceite ou não da funcionalidade desenvolvida, podendo o time mudar o status da história para pronto ou devolvê-la para o backlog para passar por correções.
Reunião de retrospectiva
Finalizada a reunião de revisão, o time se reune para refletir sobre seu desempenho, avaliar pontos positivos e negativos da sprint e discutir sobre como ficar mais ágil, organizando as ideias em um quadro de Start-Stop-Continue. Baseado nesta reunião planos de ações são traçados para tentar melhorar a velocidade e assertividade do time.
Ao longo das sprints o time lança nas histórias as horas investidas para desenvolver as funcionalidades previamente estimadas e nesta reflete sobre o quão assertivo foram as estimativas e como podem ser melhoradas.
Pair Programming
Outra prática experimentada pelo time é a de programação em dupla, altamente recomenda na metodologia Extreme Programming, o XP. Entendemos na prática benefícios como o aumento do foco do colaborador, aumento da qualidade de código, melhoria do relacionamento entre os membros da equipe e a socialização de conhecimento e redução da dependência de um único membro da equipe.
Sabendo disso, começamos a aplicar o pair programming em um dia selecionado da semana — toda a sexta-feira. Não deu certo, o time acabava tendo outras tarefas prioritárias e a prática acabava ficando de lado.
Hoje, tentamos identificar histórias/tarefas que tenham um nível de complexidade acima da média e especificamos estas para serem trabalhadas em pair. Assim, o time consegue se organizar melhor para executar as tarefas em duplas.
Excelência técnica
Além das práticas já citadas que auxiliam a busca da excelência técnica, temos um encontro semanal, em grupo, onde separamos alguns podcasts e artigos para a equipe estudar durante a semana e discutirmos o tema específico durante 30 minutos, onde todos colocam as suas conclusões sobre o estudo e analisamos como o tema pode ser utilizado no nosso ambiente de trabalho. Nesta reunião discutimos de temas extremamente técnicos até temas administrativos. Normalmente a partir da discussão já surge o tema da reunião da semana seguinte.
Ainda, quando um tema mesmo após a discussão se mostra muito complexo para ser absorvido, elaboramos uma talk a ser conduzida por um dos colaboradores que tenha mostrado mais afinidade com o tema.
A equipe também tem espaço para experimentação e validação de novas tecnologias, onde após validação e justificativa podem vir a ser adotadas. O time é empoderado e responsável, possuindo autonomia para adoção de novas tecnologias que venham a agregar valor aos nossos projetos.
Outra prática que utilizamos é o code review. Nos nossos primeiros projetos fizemos uma utilização mais rigorosa, forçando o review de 4 integrantes para a aprovação de um merge request. Notamos que com o tempo as MR estavam ficando acumuladas aguardando aprovação e para não trancar a evolução do projeto, o time acabava simplesmente aprovando o código do colega, perdendo completamente o sentido da prática. Passamos a flexibilizar as MR de forma que quem abri-la, de acordo com o tipo de feature desenvolvida, marca um ou mais colegas da equipe para revisar e aprovar o código. Hoje, estamos experimentando também trabalhar com a MR sendo aberta em bloqueada para aceitação (WIP) desde o início do desenvolvimento da feature e tendo o seu changelog sendo escrito de forma incremental, podendo também a equipe fazer um review contínuo do código conforme a entrega vai sendo construída.
Hoje, assim trabalhamos na Brainny para organizarmos nossos projetos e desenvolvermos nossa equipe. Entendemos que ainda estamos em processo de ajustes e amadurecimento para chegar em um ponto ideal, porém, com práticas já bem mais eficientes do que as que tínhamos no início das operações. Continuaremos experimentando, acertando e errando. Daqui um tempo mais eu volto para contar o que mudou nas nossas práticas.
Originally published at https://www.linkedin.com.
