# Um pouco sobre agilidade em desenvolvimento de software

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.

![](https://cdn-images-1.medium.com/max/1200/0*lwFikxR7FQA3VJqW align="center")

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](https://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

![](https://cdn-images-1.medium.com/max/1200/0*9nmIT0q77IK7E56X.png align="center")

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

[**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](https://www.funretrospectives.com/)

### Métricas

Durante a sprint, olhamos a métrica de Burndown.

![](https://cdn-images-1.medium.com/max/1200/0*l4oOlSwuiucjbour.jpg align="center")

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://cdn-images-1.medium.com/max/1200/1*PTzMdW7Y5K-z3MJg9xn3YQ.png align="center")

[https://www.atlassian.com/br/agile/project-management/metrics](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](https://www.amazon.com.br/Sprint-M%C3%A9todo-Google-Testar-Aplicar/dp/8551001523/ref=asc_df_8551001523/?tag=googleshopp00-20&linkCode=df0&hvadid=379748610448&hvpos=&hvnetw=g&hvrand=6814294110314722842&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9100388&hvtargid=pla-460804272437&psc=1)

[**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](https://www.amazon.com.br/Product-Backlog-Building-refinamento-produtos/dp/6586660106/ref=sr_1_1?__mk_pt_BR=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=2IR2A7W16SK6Q&keywords=product+backlog+building&qid=1682107911&s=books&sprefix=product+backlog+build%2Cstripbooks%2C322&sr=1-1&ufe=app_do%3Aamzn1.fos.6121c6c4-c969-43ae-92f7-cc248fc6181d)

[**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](https://www.amazon.com.br/SCRUM-fazer-dobro-trabalho-metade/dp/8543107164/ref=sr_1_1?__mk_pt_BR=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=21CLA6ZZJ5DSI&keywords=scrum+a+arte&qid=1682107930&s=books&sprefix=scrum+a+arte%2Cstripbooks%2C259&sr=1-1&ufe=app_do%3Aamzn1.fos.6121c6c4-c969-43ae-92f7-cc248fc6181d)

### 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.
    

![](https://cdn-images-1.medium.com/max/1200/0*waR_OFWTbW88r0JN.jpg align="center")

#### 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.
    

![](https://cdn-images-1.medium.com/max/1200/0*xd9NEjVWEKTDBtqE.png align="center")

#### Quadro Kanban com WIP

![](https://cdn-images-1.medium.com/max/1200/0*7TcJSr4XvflN-C6s align="center")

#### 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](https://www.amazon.com.br/Kanban-Mudanca-Evolucionaria-Sucesso-Tecnologia/dp/0984521461/ref=sr_1_1?__mk_pt_BR=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=2Y84S15T79L0C&keywords=kanban&qid=1682108439&s=books&sprefix=kanba%2Cstripbooks%2C323&sr=1-1&ufe=app_do%3Aamzn1.fos.6121c6c4-c969-43ae-92f7-cc248fc6181d)

> 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á! :)