Um pouco sobre agilidade em desenvolvimento de software
Rafael Moura
Muito se fala em ser ágil, mas precisamos entender um pouco da origem e do motivo de que as grandes empresas precisam ser ágeis.
Antes de iniciar esse artigo, o conteúdo faz parte de uma apresentação que fiz aqui na empresa em que trabalho. Eu inicio falando que não sou agilista, mas um apreciador das ferramentas e do manifesto :)
Algumas métricas são retiradas dos times e também trago alguns exemplos de conteúdos da internet.
Então, bóra ao que interessa!
Origem
A origem de alguns métodos ágeis, no mundo de Software vem de outras engenharias. Se olharmos para a Engenharia Civil identificamos etapas de um projeto.
Para a construção de uma casa, precisamos iniciar com uma análise, partimos para uma fundação e depois iniciamos os Pilares. A sequência eu vou pedir para algum Engenheiro nos ajudar 😜
Nesse cenário, estamos falando de projetos em fase.
Essa metodologia, quando trazemos para o mundo de Engenharia de Software, podemos nomear como modelo Waterfall.
Exemplo de modelo Waterfall
Nesse modelo, quando iniciamos um projeto, levantamos os requisitos, desenvolvemos o design da funcionalidade, colocamos para o desenvolvimento e iniciamos o mesmo. Depois de todo o desenvolvimento, fazemos uma verificação, sendo validações internas e testes. Publicamos e dizemos que está pronto para utilização.
Acontece que no mundo atual, esse modelo pode “quebrar as pernas” do nosso produto.
Imagine o seguinte:
O cliente deseja um sistema onde ele possa acompanhar o andamento dos pedidos que são realizados em sua loja. Os funcionários utilizam o computador/notebook da loja para poder acessar o sistema. Para isso, ele traz algumas demandas (exemplo bem simplificado):
Nosso funcionário irá acessar o sistema;
Uma lista com todos pedidos será exibida;
O funcionário poderá filtrar por pedido;
Ao acessar um determinado pedido, irá exibir os detalhes.
Levantado todos requisitos e alinhado com o cliente o contrato, foi firmado um prazo de 6 meses para o desenvolvimento da aplicação. Dentro desse prazo, o fornecedor irá entregar a aplicação funcionando 100%.
Iniciado o desenvolvimento, passamos 6 meses desenvolvendo o sistema, contando a implementação, validações internas e entrega.
Ao entregar o sistema, o cliente levanta alguns pontos
- Atualmente, nossos funcionários utilizam as máquinas desktop/notebook da loja mas alguns gostariam de acompanhar via mobile.
Retrabalho no desenvolvimento pois não houve uma primeira validação da funcionalidade com o cliente final.
- Dentro desse período de desenvolvimento, criamos alguns cargos e houve a necessidade de termos perfis de acesso ao sistema
Passamos 6 meses em desenvolvimento, sendo que poderíamos estar validando com o cliente algumas etapas de entrega.
- Precisamos ter um login diferenciado por perfil. Além disso, agora precisamos que o usuário tenha um cadastro/login através de um determinado meio.
Se tivéssemos entregue e validado uma tela de login e acesso ao sistema, antes de entregarmos o sistema como um todo, poderíamos ter tido esse feedback durante o desenvolvimento.
Isso vale para todas funcionalidades do sistema.
É um exemplo simples mas a ideia é trazer que quando assumimos um desenvolvimento, por mais que o contrato esteja fechado, precisamos validar e sermos flexíveis a mudanças de acordo com os desejos do cliente.
É aí que colocamos em cheque o modelo Waterfall, para algumas organizações.
Um resumo do que é ser ágil
Ser ágil é diferente de ser rápido.
Ser ágil é ser adaptável a responder as mudanças.
Para ser ágil, precisamos entregar valor. Esse é um ponto importante! Entregando pequenas partes, conseguimos ter feedbacks mais rápidos e direcionamos a melhor estratégia para o caminho da entrega da funcionalidade/produto.
No fim das contas, ao receber feedbacks constante dos clientes, fazemos com que as mudanças sejam feitas em tempo.
Manifesto ágil
Estamos descobrindo maneiras melhores de desenvolver
software, fazendo-o nós mesmos e ajudando outros a
fazerem o mesmo. Através deste trabalho, passamos a valorizar:Indivíduos e interações mais que processos e ferramentas;
Software em funcionamento mais que documentação abrangente;
Colaboração com o cliente mais que negociação de contratos;
Responder a mudanças mais que seguir um plano.
Ou seja, mesmo havendo valor nos itens à direita,
valorizamos mais os itens à esquerda.
O manifesto ágil dá diretrizes ao pensamento e modelo ágil.
Recomendo entrar lá e entender melhor a história disso tudo. Tem alguns autores bem conhecidos 😄
Para trabalharmos a agilidade, temos algumas ferramentas.
Vou abordar duas delas (e uma mescla dessas). O Scrum e o Kanban!
Scrum
Para falarmos de Scrum, precisamos definir alguns papeis.
Scrum Master
Figura no time que garante a aplicação da ferramenta;
Guia cerimônias e verifica o cumprimento das regras;
Supera os impedimentos apontados pelo time.
Desenvolvedores
Devs Frontend, Backend, Fullstack, QAs, Tech Leaders, Devops…
A necessidade da especialidade dos devs vão ser de acordo com o produto.
Product Owner | Product Manager
Cuidar do Backlog de Produtos;
Solicita e refina as demandas junto com o dev team e prioriza;
Agrega o máximo de valor a cada entrega do time;
É a ponte dos stakeholders.
Design
Anda junto com os POs|PMs;
Podemos realizar sprints de Design;
Acompanha e efetua handoff com os devs; (demandas UI)
Colhe feedback e atua na experiência do usuário.
Cerimônias
Cerimônias do Scrum
Sprint Planning
Primeiro dia da Sprint;
Definição e estimativas das tarefas;
Recomendação de 2hrs de call, por semana de sprint;
PO | PM já está com o backlog priorizado;
Direciona entrega de maior valor possível.
Daily Scrum
Não é um reporte de ações;
Alinhamento entre equipes e solução de impedimentos;
15 min. recomendados;
Objetiva;
No modelo presencial, muitas empresas realizavam em pé. O nome original é “Stand up Daily”
Sprint Review
Apresentar aos stakeholders o que foi produzido naquele ciclo;
Coleta de feedback e alinhamento;
Percepção de avanço.
Sprint Retrospective
Troca de feedback entre o time interno;
O que foi bem e o que não foi naquele ciclo (sprint);
Sair com ações;
Melhoria contínua.
Para algumas ideias de retrospectivas
Métricas
Durante a sprint, olhamos a métrica de Burndown.
O gráfico de burndown é usado em Scrum para rastrear o progresso do trabalho durante um sprint. Ele ajuda a equipe a monitorar a quantidade de trabalho restante e a verificar se estão no ritmo certo para completar todas as tarefas planejadas até o final do sprint. Tem como objetivo:
- Transparência: Fornece uma visão clara e visual do progresso do sprint.
- Monitoramento: Ajuda a identificar desvios no planejamento e permite ajustes proativos.
- Comunicação: Facilita a comunicação dentro da equipe e com stakeholders sobre o andamento do trabalho.
Velocity:
Para entendermos nossa velocidade e termos uma média de entregas para estimarmos o quanto podemos entregar nas próximas sprints, podemos usar a métrica de Velocity.
https://www.atlassian.com/br/agile/project-management/metrics
Leitura
Kanban
O Kanban é uma metodologia ágil que se concentra na visualização do trabalho, gerenciamento do fluxo de trabalho e melhoria contínua. Originado no sistema de produção da Toyota, Kanban é amplamente utilizado para melhorar a eficiência e a eficácia na gestão de projetos.
Princípios:
Utiliza o quadro kanban para exibir as tarefas que são representadas por cartões e se movem pelas etapas do processo a medida que avança.
WIP (Trabalho em progresso): Definição de limites (mínimo e máximo) para o número de tarefas em cada etapa do processo, ajudando na sobrecarga de trabalho e melhorando o foco e a qualidade.
Acompanhamento de gargalos e impedimentos, garantindo um fluxo suave e eficiente de trabalho.
Pequenas entregas: incentiva a entrega frequente e incremental permitindo ajustes rápidos e melhoria contínua.
O quadro Kanban:
To Do: Tarefas a serem iniciadas.
In Progress: Tarefas em andamento.
Done: Tarefas concluídas.
Métricas
Lead Time: Mede o tempo total que uma tarefa leva para ser concluída desde o momento em que é solicitada até a sua entrega.
Cycle Time: Enquanto o lead time mede o tempo total desde a solicitação até a entrega, o cycle time se concentra no tempo que uma tarefa leva para ser concluída a partir do momento em que se inicia o trabalho ativo nela.
Gráficos
- CFD (Cumulative Flow Diagram): É uma ferramenta visual usada no Kanban para monitorar e analisar o fluxo de trabalho ao longo do tempo. Ele ajuda a entender a estabilidade e a eficiência do processo de desenvolvimento, identificando gargalos e áreas de melhoria.
Quadro Kanban com WIP
Leitura
O time decide a melhor ferramenta!
Framework inalado pode burocratizar os processos
No próximo artigo, continuarei falando um pouco mais sobre como utilizamos as ferramentas ágeis aqui onde trabalho, atuando com uma mistura dos dois, o famoso ScrumBan.
Até lá! :)
Subscribe to my newsletter
Read articles from Rafael Moura directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by