Blog

O que é metodologia ágil?

Se de um lado as várias metodologias ágeis Scrum compartilham da mesma filosofia, bem como muitas das mesmas características e práticas.

Do ponto de vista da implementação, cada um tem sua própria característica e receita de práticas, terminologia e táticas.

 

Aqui resumimos alguns dos principais concorrentes de metodologia de desenvolvimento de software ágil mas que fazem total sentido a você que deseja caminhar sua jornada agil.

 

Metodologia Agile Scrum

O Scrum é uma estrutura de gerenciamento de projetos ágil e 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.

O Scrum conquistou crescente popularidade na comunidade ágil de desenvolvimento de software devido à sua simplicidade, produtividade comprovada e capacidade de atuar para várias práticas de engenharia promovidas por outras metodologias ágeis.

 

Com a metodologia Scrum, o “Product Owner” trabalha em estreita colaboração com a equipe para identificar e priorizar a funcionalidade do sistema sob a forma de “Backlog de produtos”.

O Backlog do produto consiste em recursos, correções de bugs, requisitos não funcionais, etc. – ou seja, o que seja necessário para fornecer como insumo de trabalho para desenvolvimento de software.

Com as prioridades orientadas pelo Proprietário do Produto, as equipes multifuncionais estimam para entregar “incrementos potencialmente prontos” de software durante Sprints sucessivos, geralmente com duração de 1 semanas, 15 dias ou 30 dias.

Uma vez que o backlog de produtos da Sprint está comprometido, nenhuma funcionalidade adicional pode ser adicionada ao Sprint, exceto pela equipe.

Uma vez que um Sprint foi entregue, o Backlog do Produto é analisado e re-priorizado, se necessário, e o próximo conjunto de funcionalidades é selecionado para o próximo Sprint.

 

A metodologia Scrum foi comprovada em escala para várias equipes em organizações muito grandes com mais de 2000 pessoas.

 

Lean Software Development

 

Lean Software Development é uma metodologia ágil e iterativa desenvolvida originalmente por Mary e Tom Poppendieck.

Lean Software Development deve muitos dos seus princípios e práticas ao movimento Lean Enterprise e às práticas de empresas como a Toyota.

O Lean Software Development concentraem identificar o que é valor para a empresa e clientes e repensar completamente a sua atuação para entregar, continuamente, experiências relevantes para o mercado.

 

Os principais princípios da metodologia Lean incluem:

 

Eliminar resíduos

Aprendizagem amplificadora

Decidindo o mais tarde possível

Entregando o mais rápido possível

Empoderando a equipe

Integridade do edifício em

Vendo o Todo

 

A metodologia Lean elimina o desperdício através de práticas tais como selecionar apenas os recursos verdadeiramente valiosos para um sistema, priorizando os selecionados e entregando-os em pequenos lotes.

Enfatiza a velocidade e eficiência do fluxo de trabalho de desenvolvimento e depende de feedback rápido e confiável entre programadores e clientes.

Lean utiliza a idéia de que o produto de trabalho seja “puxado” por solicitação do cliente. Ele concentra a autoridade e a capacidade de tomada de decisão em indivíduos e pequenas equipes, uma vez que a pesquisa mostra que isso é mais rápido e eficiente do que o fluxo de controle hierárquico.

Lean também se concentra na eficiência do uso dos recursos da equipe, tentando garantir que todos sejam produtivos tanto quanto possível.

 

Kanban

 

O método Kanban é usado por organizações para gerenciar a criação de produtos com ênfase na entrega contínua sem sobrecarregar a equipe de desenvolvimento. Como o Scrum, Kanban é um processo projetado para ajudar as equipes a trabalhar de forma mais eficaz.

 

Kanban baseia-se em 3 princípios básicos:

 

  1. Visualize o que você faz hoje (fluxo de trabalho): ver todos os itens em contexto um do outro pode ser muito informativo
  2. Limite a quantidade de trabalho em andamento (WIP): isso ajuda a equilibrar a abordagem baseada em fluxo para que as equipes não comecem e cometerem demais trabalho ao mesmo tempo
  3. Melhore o fluxo: quando algo está terminado, a próxima coisa mais alta do backlog é puxada para o jogo

 

Kanban promove a colaboração contínua e incentiva a aprendizagem ativa e contínua e melhora, definindo o melhor fluxo de trabalho da equipe possível.

Development-Driven Development (FDD)

FDD na metodologia ágil foi originalmente desenvolvida e articulada por Jeff De Luca, com contribuições de M. Rajashima, Lim Bak Wee, Paul Szego, Jon Kern e Stephen Palmer.

Os primeiros modos de FDD ocorreram como resultado da colaboração entre De Luca e OOD, líder do pensamento Peter Coad.

O FDD é um processo de curto-iterações orientado por modelo. Começa com o estabelecimento de uma forma geral do modelo.

Em seguida, continua com uma série de duas semanas “design por recurso, construído por recurso” iterações.

Os recursos são pequenos, “na visão dos clientes”.

O FDD projeta o resto do processo de desenvolvimento em torno da entrega de recursos usando as seguintes oito práticas:

 

Modelagem de objeto de domínio

Desenvolvendo por recurso

Propriedade de componente / classe

Equipes de destaque

Inspeções

Gerenciamento de configurações

Construções regulares

Visibilidade do progresso e dos resultados

 

O FDD recomenda práticas específicas do programador, como “Buildies regulares” e “Component / Class Ownership”.

Os proponentes da FDD afirmaram que eleva mais diretamente do que outras abordagens, e é mais adequado para equipes maiores.

Ao contrário de outros métodos ágeis, o FDD descreve fases de trabalho específicas, muito curtas, que devem ser realizadas separadamente por recurso.

 

Estes incluem o Walkthrough do Domínio, Design, Inspeção de Design, Código, Inspeção de Código e Promover para Construir.

 

Programação Extrema (XP)

 

O XP, originalmente descrito por Kent Beck, emergiu como uma das metodologias ágeis mais populares e controversas.

O XP é uma abordagem disciplinada para oferecer software de alta qualidade de forma rápida e contínua.

Ele promove o alto envolvimento do cliente, loops de feedback rápido, testes contínuos, planejamento contínuo e trabalho em equipe próximo para entregar software de trabalho em intervalos muito freqüentes, normalmente a cada 1-3 semanas.

A receita original do XP é baseada em simplicidade de valores simples,

  1. Comunicação – tem o intuido de manter o melhor relacionamento possível entre clientes e desenvolvedores, optando por conversas pessoais a outros meios de comunicação.
  2. Simplicidade – busca do objetivo de implementar o software com o menor número possível de classes e métodos.  Com o pensamento basico que é melhor fazer algo simples hoje do que implementar algo complicado hoje que talvez não venha a ser usado.
  3. Feedback –A prática do feedback constante significa que o desenvolvedor terá informações constantes do código e do cliente. A informação do código é dada pelos testes constantes, que indicam os erros tanto individuais quanto do software integrado.
  4. Princípio da Coragem –Sabe-se que não são todas as pessoas que possuem facilidade de comunicação e têm bom relacionamento interpessoal, este princípio também dá suporte à simplicidade, pois assim que a oportunidade de simplificar o software é percebida, a equipe pode experimentar e buscar novas soluções, além disso, é preciso coragem para obter e cobrar constantemente um feedback do cliente

 

Principais práticas da Extreme Programming (XP):

 

  • Planejamento
  • Entregas Frequentes
  • Testes de aceitação do cliente
  • Design simples
  • Programação em pares
  • Desenvolvimento orientado por testes
  • Refatoração
  • Integração contínua
  • Propriedade do Código Coletivo
  • Padrões de codificação
  • Metáfora
  • Ritmo sustentável, 40 horas de trabalhos semanais

 

No XP, o “Cliente” trabalha em estreita colaboração com a equipe de desenvolvimento para definir e priorizar as unidades granulares de funcionalidades, denominadas “Histórias de usuários”.

A equipe de desenvolvimento estima, planeja e entrega as histórias de usuários de maior prioridade sob a forma de software testado e testado em uma base de iteração por iteração.

Para maximizar a produtividade, as práticas fornecem um quadro de apoio e leve para orientar uma equipe e garantir um software de alta qualidade.

 

Crystal

A metodologia Crystal é uma das abordagens mais flexíveis e adaptáveis ​​ao desenvolvimento de software. O Crystal é composto de uma família de metodologias ágeis, como Crystal Clear, Crystal Yellow, Crystal Orange e outros, cujas características únicas são conduzidas por vários fatores, como o tamanho da equipe, a criticidade do sistema e as prioridades do projeto. Esta família Crystal aborda a percepção de que cada projeto pode exigir um conjunto de políticas, práticas e processos ligeiramente adaptados para atender as características únicas do projeto.

Vários dos principais princípios do Crystal incluem trabalho em equipe, comunicação e simplicidade, bem como reflexão para freqüentemente ajustar e melhorar o processo. Como outras metodologias de processo ágil, o Crystal promove a entrega precoce e frequente de software de trabalho, o alto envolvimento do usuário, a capacidade de adaptação e a remoção de burocracias ou distrações. Alistair Cockburn, o criador de Crystal, lançou um livro, Crystal Clear: A Human-Powered Methodology for Small Teams.

 

Método de Desenvolvimento de Sistemas Dinâmicos (DSDM)

 

DSDM é uma metodologia de desenvolvimento de software originalmente baseada em “Desenvolvimento Rápido de Aplicação” (RAD). Seu objetivo é entregar softwares no tempo e com custo estimados através do controle e ajuste de requisitos ao longo do desenvolvimento. DSDM é um dos modelos de Metodologia Ágil de desenvolvimento de software que consiste em:
3 fases: pré-projeto, ciclo de vida, e pós-projeto

 

O DSDM baseia-se em nove princípios fundamentais que giram principalmente em torno das necessidades / valor do negócio, envolvimento ativo do usuário, equipes habilitadas, entrega freqüente, testes integrados e colaboração de partes interessadas.

O DSDM especificamente chama “aptidão para fins comerciais” como o principal critério de entrega e aceitação de um sistema, com foco nos 80% úteis do sistema que podem ser implantados em 20% das vezes.

 

DSDM são priorizados usando Regras MoSCoW:

 

M – Deve ter requisitos

S – Deveria ter, se possível

C – Poderia ter, mas não é crítico

W – Won não tem esse tempo, mas potencialmente mais tarde

 

Todo o trabalho crítico deve ser concluído em um projeto DSDM. Também é importante que nem todos os requisitos em um projeto ou caixa de tempo sejam considerados críticos. Dentro de cada caixa de tempo, itens menos críticos são incluídos, de modo que, se necessário, eles podem ser removidos para evitar impactar os requisitos de maior prioridade na programação.

A estrutura do projeto DSDM é independente e pode ser implementada em conjunto com outras metodologias iterativas, como a Programação Extrema e o Rational Unified Process.

No Comment

0

Post A Comment