TECH TALKS

Metodologias Ágeis

Por Leandro Ramalho

PARTE 1 – DEFINIÇÃO, ORIGEM E PRINCÍPIOS

Metodologias ágeis são conjuntos de práticas que proporcionam uma maneira de gerenciar projetos mais adaptáveis às mudanças e tem a função de aprimorar o processo de desenvolvimento de um produto ou serviço.

O conceito de metodologia ágil surgiu a partir do manifesto ágil. Criado nos Estados Unidos em 2001, por 17 desenvolvedores que se juntaram para discutir formas de desenvolvimentos mais leves com base em suas experiências. Foi elaborado o documento chamado “Manifesto para o Desenvolvimento Ágil de Software”. Este manifesto é composto por 12 princípios da metodologia ágil agrupados em 4 fundamentos-chave. São eles:

• indivíduos e interações acima de ferramentas e processos;
• software funcionando acima de documentação abrangente;
• colaboração com o consumidor/cliente acima de negociação de contratos;
• responder a mudanças/transformações mais do que seguir um plano.

VISÃO GERAL

Gestão de Projeto Tradicional (Waterfall) X Gestão de Projeto Ágil

CICLO TRADICIONAL (WATERFALL)	CICLO ÁGIL
Etapa por etapa (Sequencial)	Incremental
Preditivo	Adaptivo
Fases e Marcos	Interações de funcionalidades
Produto só no final ciclo	Produto desde a primeira interação até o última
Resistência à mudanças	Mudanças constantes / Feedbacks
“n” Meses de duração	Interações curtas (máx. 1 mês)
Descobrir erros no projeto depois de MESES	Descobrir erros no projeto no máximo de 30 DIAS

BENEFÍCIOS

Assertividade

O foco na entrega de valor agregado para o cliente fica muito mais evidente do que na maioria dos projetos tradicionais. É comum que o cliente seja envolvido nas diversas interações na construção do projeto. A divisão do projeto em ciclos curtos permite a validação mais rápida das entregas.

Flexibilidade

Ao contrário das metodologias preditivas, em que o objetivo é seguir o planejamento previamente elaborado, nas metodologias ágeis existe mais flexibilidade às mudanças.

Colaboração

Envolvem equipes multidisciplinares, que trabalham em conjunto na busca das soluções. Por serem equipes menores, isso facilita a criação de um ambiente colaborativo e motivador.

Comunicação

Estabelece uma boa comunicação entre as partes interessadas no projeto permitindo uma melhor interpretação do que está sendo colocado e evitando ambiguidades que podem comprometer o resultado do projeto.

Simplicidade

Enquanto uma metodologia preditiva exige um esforço de planejamento enorme, pois o foco é antecipar o máximo possível de trabalho, para uma metodologia ágil é suficiente ter um backlog com as entregas pendentes do projeto.

FRAMEWORKS

Os frameworks são ferramentas que têm como base os princípios ágeis e que podem ser implantados em times ou empresas que desejam incorporar seus conceitos em suas práticas diárias. São consideradas metodologias ou frameworks ágeis:

• Scrum;
• Kamban;
• eXtreme Programming (XP);
• Scaled Agile Framework (SAFe);
• Feature Driven-Development (FDD);
• Test Driven Development (TDD);
• Dynamic Systems Development Method (DSDM);
• Microsoft Solutions Framework (MSF);
• Adaptative Software Development (ASD);
• Entre outras.

CONSIDERAÇÕES FINAIS

Utilizar metodologias ágeis NÃO significa:

• Rapidez na entrega do projeto;
• Ausência de disciplina;
• Ausência de documentação;
• Falta de planejamento.

Utilizar metodologias ágeis SIM significa:

• Rapidez na mudança e desembaraço;
• Construção de coisas complexas de forma simples (pequenas parte);
• Equipe auto-organizadas e comprometida com os objetivos;
• Melhoria contínua;
• Maior valor para o negócio.

PARTE 2 – METODOLOGIA ÁGIL SCRUM

Criado por Jeff Sutherland nos anos 80 como um processo de desenvolvimento interativo e incremental, este é um dos métodos mais populares de implementação ágil.

Ele tem foco nas pessoas, e garante mais dinâmica ao envolver o cliente diretamente com o desenvolvimento dos produtos do projeto.

O Scrum é composto por:

• Pilares (transparência, inspeção e adaptação)
• Valores (coragem, foco, comprometimento, respeito e abertura)
• Papéis (Scrum Master, Product Owner e Developer Team)
• Cerimônias (Sprint, Sprint Planning, Daily, Sprint Review e Sprint Retrospective)

OS 3 PILARES

Transparência

É ter visibilidade do que está acontecendo. Todos aqueles que são responsáveis por algum tipo de entrega devem poder visualizar o processo do qual fazem parte.

Inspeção

É a arte de pensar. Pensar no sentido de aplicar uma visão crítica sobre o que está acontecendo, enxergar além de suas tarefas e entender o impacto das ações da cada um do time dentro do projeto.

Adaptação

É a etapa de agir. É nesse momento que é preciso entender que sempre é possível fazer melhor e desenvolver um aprendizado progressivo (Melhoria Contínua).

VALORES

Os valores têm como objetivo trazer evolução para equipe e para o projeto, através do desenvolvimento de suas competências. Devem ser desenvolvidos durante a execução do projeto por cada um dos integrantes da equipe.

Coragem

Os integrantes precisam ter coragem para fazer a coisa certa e trabalharem juntos removendo impedimentos, buscando soluções.

Foco

Os integrantes precisam focar no trabalho durante o Sprint e nas metas designadas pela empresa. Time disperso perde produtividade e não alcança os objetivos.

Comprometimento

Cada integrante se compromete com o trabalho que se responsabilizou em fazer. Se comprometer é se envolver e não abandonar o trabalho pela metade ou entregar sem qualidade.

Respeito

Respeitar uns aos outros é o primeiro passo para manter a colaboração, a integração e bom ambiente de trabalho.

Abertura

Poder ser franco, expor as ideias e propostas mesmo que elas não sejam aproveitadas. Promover momentos de debates, discussões, ouvir opiniões e sugestões para gerar novas práticas.

PAPÉIS E RESPONSABILIDADES

Product Owner (PO)

Pessoa responsável por defender os interesses dos clientes ou usuários finais, além de definir quais tarefas e funcionalidades que serão alocadas no Backlog de acordo com o seus valores. Garantir o entendimento dos itens do Backlog para o Developer Team (DEV) e validar as entregas realizadas, pelos mesmos, nos Sprints.

Scrum Master (SM)

Pessoa encarregada de ser um guardião da metodologia Scrum e se certificar de que ela está sendo seguida corretamente. Auxiliar o Product Owner (PO) no planejamento e estimativas do Backlog e o Developer Team (DEV) na remoção de impedimentos.

Developer Team ou Scrum Team (DEV)

É a equipe técnica de desenvolvimento. Todos no projeto trabalham juntos para completar o conjunto de trabalhos definidos no Backlog de uma Sprint. É composto geralmente entre 3 à 9 pessoas.

CERIMÔNIAS

Dentre seus principais rituais e agentes, podemos destacar:

Backlog: Lista de tarefas que devem ser realizadas pelas equipes para se desenvolver o produto ou serviço desejado.

Time Box: Tempo máximo definido para a realização de uma cerimônia ou Sprint.

Sprint: Um período de tempo em que se completam alguns conjuntos de tarefas do Backlog com o objetivo de consolidar um avanço incremental no produto ou serviço. Possui um Time Box de até 30 dias.

Sprint Planning

É uma reunião de planejamento onde todos membros, Product Owner (PO), Scrum Master (SM) e Developer Team (DEV) participam. Possui um Time Box de até 08 horas, onde é definido:

• Descrição das funcionalidades de maior prioridade (PO);
• Definição do objetivo da Sprint (PO) e (DEV);
• Transformação das funcionalidades em tarefas técnicas (DEV);
• Definir a estimativa de cada tarefa atribuindo um valor – Planning Poker (DEV);
• Definir a capacidade de entrega de tarefas durante a Sprint (DEV).
• Criação do Backlog e o detalhamento de prioridades (DEV).

Daily: Reuniões diárias, geralmente pela manhã, em que os membros da equipe falam sobre seus progressos no dia anterior, o que pretendem realizar naquele dia e se possui algum impedimento para a execução de uma tarefa. Possui um Time Box de até 15 minutos.

Sprint Review: No final de cada Sprint a equipe se reúne para mostrar o que foi alcançado e atestar que o objetivo tenha sido cumprido. Possui Time Box de até 04 horas.

Sprint Retrospective: Ao final de cada Sprint a equipe se reúne para avaliar seus resultados, as dificuldades superadas e planejar ações que serão tomadas para melhoria no próximo Sprint, sempre se baseando nos aprendizados do Sprint anterior. O Product Owner (PO) deve realizar ajustes necessários para as próximas Sprints e, caso necessário, cancelar ou  replanejar uma Sprint de acordo com os novos objetivos. Ele pode priorizar um estudo a fim de agilizar o desenvolvimento da próxima Sprint e investigar algo que não pode ser estimado pelo Developer Team (DEV) (conhecido como Spike). Possui um Time Box de até 03 horas.

“Quando o Incremento do Produto é entregue, é necessário que esteja “pronto” de acordo com uma compreensão compartilhada do que “pronto” significa. Essa definição é diferente para cada Time de Scrum e, à medida que o time amadurece, a Definição de Pronto se expande e se torna mais restrita.” Scrum Guide.

Artigo produzido por Leandro Ramalho

Full Stack Software Developer / Leader Team

Formado pela Universidade Paulista (UNIP) em Sistemas de Informação

(18+) anos de experiência desenvolvendo aplicações direcionadas à Administração Pública (Educação), na Sonner Sistemas.