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.
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. These are our values and…agilemanifesto.org
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
Sprint Retrospective
Para algumas ideias de retrospectivas
FunRetrospectives | Have fun, learn from the past and prepare for the future!
Have fun, learn from the past and prepare for the future!www.funretrospectives.com
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
Sprint: O Método Usado no Google Para Testar e Aplicar Novas Ideias Em Apenas Cinco Dias
Compre online Sprint: O Método Usado no Google Para Testar e Aplicar Novas Ideias Em Apenas Cinco Dias, de Knapp, Jake…www.amazon.com.br
Product Backlog Building: Um guia prático para criação e refinamento de backlog para produtos de…
Times ágeis constantemente encontram-se frente a frente com algumas perguntas cruciais na hora de desenvolver um…www.amazon.com.br
Scrum: A arte de fazer o dobro do trabalho na metade do tempo
Compre online Scrum: A arte de fazer o dobro do trabalho na metade do tempo, de Sutherland, Jeff, Sutherland, J. J…www.amazon.com.br
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.
Leitura
Kanban: Mudanca Evolucionaria de Sucesso Para Seu Negocio de Tecnologia: Mudança Evolucionária de…
(brazilian portuguese) kanban está se tornando uma maneira popular de visualizar e limitar trabalho-em-progresso em…www.amazon.com.br
O time decide a melhor ferramenta!
Framework inalado pode burocratizar os processos
Até lá! :)
