Metodologias ágeis são diversas metodologias para a gestão de equipes multifuncionais de maneira simples e eficiente. Elas focam em melhorar a eficiência da comunicação e trabalhos de times, de maneiras simples e desburocratizada.
Começaram sendo aplicadas para o desenvolvimento de softwares (como é o caso do SCRUM), mas evoluíram para outras atividades, de desenvolvimento ou de gestão.
As metodologias ficaram famosas com o manifesto ágil, uma declaração dos princípios que norteiam a maioria das metodologias.
Quais o 4 valores das metodologias ágeis?
Os valores das metodologias ágeis foram estabelecidos pelo Manifesto Ágil, elaborado em 2001 por 17 especialistas em desenvolvimento de softwares. Os quatro valores são:
- Indivíduos e interações acima de processos e ferramentas;
- Software funcionando acima de documentação abrangente;
- Colaboração com o cliente acima de negociação de contratos;
- Responder a mudanças acima de seguir um plano.
Quais são as metodologias ágeis?
A metodologia ágil Scrum
O Scrum é uma estrutura de gerenciamento de projetos ágil leve, com ampla aplicabilidade para gerenciar e controlar projetos iterativos e incrementais de todos os tipos.
Ken Schwaber, Mike Beedle, Jeff Sutherland e outros contribuíram significativamente para a evolução do Scrum na última década, sendo que este conquistou crescente popularidade na comunidade de desenvolvimento de software ágil devido à sua simplicidade, produtividade comprovada e capacidade de atuar como invólucro para várias práticas de engenharia promovidas por outras metodologias ágeis.
Com a metodologia do Scrum, os projetos são divididos em ciclos chamados de Sprints, no qual o Product Owner (Dono do Produto) trabalha em estreita colaboração com a equipe para identificar e priorizar a funcionalidade do sistema na forma de um Product Backlog (Backlog do Produto), que consiste em recursos, correções de bugs, requisitos não funcionais etc. - tudo o que precisa ser feito para fornecer com êxito um sistema de software em funcionamento.
Com as prioridades orientadas pelo Dono do Produto, as equipes multifuncionais estimam e se inscrevem para fornecer "incrementos potencialmente entregáveis" de software durante Sprints sucessivos, normalmente com duração de 30 dias. Depois que o Backlog de um produto da Sprint é confirmado, nenhuma funcionalidade adicional pode ser adicionada ao ciclo, exceto pela equipe. Depois que um Sprint é entregue, o Backlog do Produto é analisado e priorizado, se necessário, e o próximo conjunto de funcionalidades é selecionado para o próximo Sprint. Foi comprovado que a metodologia Scrum pode ser dimensionada para várias equipes em organizações muito grandes, com mais de 800 pessoas.
A metodologia ágil do Kanban (Desenvolvimento Lean)
O desenvolvimento Lean é uma metodologia ágil iterativa originalmente desenvolvida por Mary e Tom Poppendieck. O Lean Software Development deve muitos de seus princípios e práticas ao movimento Lean Enterprise e às práticas de empresas como a Toyota.
O Lean Software Development concentra a equipe na entrega de valor ao cliente e na eficiência do "fluxo de valor", os mecanismos que entregam esse valor. Os princípios da metodologia Lean incluem:
- Eliminar o desperdício;
- Amplificar o aprendizado;
- Decidir o mais tarde possível;
- Entregar o mais rápido possível;
- Capacitar a equipe;
- Incorporar a Integridade;
- Ver o Todo.
A metodologia Lean elimina o desperdício através de práticas como selecionar apenas os recursos realmente valiosos para um sistema, priorizar os selecionados e entregá-los em pequenos lotes. Ele enfatiza a velocidade e a eficiência do fluxo de trabalho de desenvolvimento e conta com feedback rápido e confiável entre programadores e clientes.
O Lean usa a ideia de o produto de trabalho ser "puxado" por solicitação do cliente. Ele concentra autoridade e capacidade de tomada de decisão em indivíduos e equipes pequenas, pois a pesquisa mostra que isso é mais rápido e eficiente do que o fluxo hierárquico de controle.
O Lean também se concentra na eficiência do uso dos recursos da equipe, tentando garantir que todos sejam produtivos o máximo de tempo possível. Concentra-se no trabalho simultâneo e no menor número possível de dependências de fluxo de trabalho dentro da equipe.
O Lean também recomenda enfaticamente que os testes de unidade automatizados sejam gravados ao mesmo tempo em que o código é gravado. O Método Kanban é usado pelas organizações para gerenciar a criação de produtos com ênfase na entrega contínua, sem sobrecarregar a equipe de desenvolvimento.
Como o Scrum, o Kanban é um processo projetado para ajudar as equipes a trabalharem juntas de maneira mais eficaz.
O Kanban é baseado em 3 princípios básicos.
Os três princípios básicos do Kanban
1 - Visualize o que você faz hoje (fluxo de trabalho): ver todos os itens no contexto um do outro pode ser muito informativo;
2 - Limitar a quantidade de trabalho em andamento (WIP): isso ajuda a equilibrar a abordagem baseada no fluxo para que as equipes não iniciem e se comprometam com muito trabalho ao mesmo tempo;
3 - Aprimore o fluxo: quando algo termina, a próxima coisa mais alta da lista de pendências é colocada em ação.
O Kanban promove a colaboração contínua e incentiva o aprendizado ativo e contínuo e a melhoria, definindo o melhor fluxo de trabalho da equipe possível.
Programação Extrema (XP)
O XP, originalmente descrito por Kent Beck, emergiu como uma das metodologias ágeis mais populares e controversas. XP é uma abordagem disciplinada para fornecer softwares de alta qualidade de forma rápida e contínua.
Promove alto envolvimento do cliente, ciclos rápidos de feedback, testes contínuos, planejamento contínuo e trabalho em equipe próximo para fornecer software de trabalho em intervalos muito frequentes, geralmente a cada 1-3 semanas.
A receita original do XP baseia-se em quatro valores simples - simplicidade, comunicação, feedback e coragem - e em doze práticas de suporte:
- Jogo de Planejamento;
- Pequenas Versões;
- Testes de aceitação do cliente;
- Design simples;
- Programação em pares;
- Desenvolvimento Orientado a Testes;
- Refatoração;
- Integração contínua;
- Propriedade do código coletivo;
- Padrões de codificação;
- Metáfora;
- Ritmo Sustentável.
Don Wells descreveu o processo XP em um diagrama popular, no qual o "Cliente" trabalha em estreita colaboração com a equipe de desenvolvimento para definir e priorizar unidades granulares de funcionalidade, conhecidas como "Histórias do Usuário". A equipe de desenvolvimento estima, planeja e entrega as histórias de usuários com a mais alta prioridade na forma de software testado e funcional, com base na iteração por iteração.
Para maximizar a produtividade, as práticas fornecem uma estrutura leve e de suporte para orientar uma equipe e garantir software de alta qualidade.
Crystal
A metodologia Crystal é uma das abordagens mais leves e adaptáveis ao desenvolvimento de software. Ela é realmente composta por uma família de metodologias ágeis, como Crystal Clear, Crystal Yellow, Crystal Orange e outras, cujas características únicas são impulsionadas por vários fatores, como tamanho da equipe, criticidade do sistema e prioridades do projeto.
A família Crystal aborda a percepção de que cada projeto pode exigir um conjunto de políticas, práticas e processos levemente adaptados para atender às características exclusivas do projeto. Os princípios do Crystal incluem trabalho em equipe, comunicação e simplicidade, além de reflexão para ajustar e melhorar o processo com frequência.
Como outras metodologias de processo ágeis, o Crystal promove a entrega precoce e frequente de software de trabalho, alto envolvimento do usuário, adaptabilidade e remoção de burocracia ou distração. Caso tenha gostado do assunto, Alistair Cockburn, o criador do Crystal, lançou um livro, Crystal Clear: A Human-Powered Metodology for Small Teams, que pode ser interessante para você.
Método Dinâmico de Desenvolvimento de Sistemas (DSDM)
O DSDM, datado de 1994, surgiu da necessidade de fornecer uma estrutura de entrega de projetos padrão do setor para o que era conhecido como RAD (Rapid Application Development) na época. Embora o RAD fosse extremamente popular no início dos anos 90, a abordagem do RAD para a entrega de software evoluiu de maneira bastante desestruturada.
Como resultado, o DSDM Consortium foi criado e convocado em 1994 com o objetivo de criar e promover uma estrutura comum da indústria para a entrega rápida de software. Desde 1994, a metodologia DSDM evoluiu e amadureceu para fornecer uma base abrangente para planejar, gerenciar, executar e dimensionar processos ágeis e projetos iterativos de desenvolvimento de software.
O DSDM é baseado em nove princípios-chave que giram principalmente em torno das necessidades/valor do negócio, envolvimento ativo do usuário, equipes capacitadas, entrega frequente, testes integrados e colaboração das partes interessadas.
O DSDM chama especificamente de "adequação aos objetivos de negócios" como o principal critério para entrega e aceitação de um sistema, concentrando-se nos 80% úteis do sistema que podem ser implantados em 20% do tempo. Os requisitos são baseados em alto nível no início do projeto. O retrabalho é incorporado ao processo e todas as mudanças no desenvolvimento devem ser reversíveis.
