Skip to content

Instantly share code, notes, and snippets.

@candidosouza
Last active March 25, 2022 12:07
Show Gist options
  • Save candidosouza/22492f5fe8430dcd32c0112576e89588 to your computer and use it in GitHub Desktop.
Save candidosouza/22492f5fe8430dcd32c0112576e89588 to your computer and use it in GitHub Desktop.
Pós graduação em Engenharia de Software - Metodologia Ágil

Metodologia Ágil

Introdução

Manifesto Ágil

Criado no final da décade de 90, por Kent Beck e outros dezesseis renomados desenvolvedores que se reuniram para redigi-lo. Por meio do manifesto ágil foi criada a Aliança Ágil, que é uma organização sem fins lucrativos, que tem por objetivo promover o conhecimento e discussões sobre as metodologias ágeis, sendo que muitos dos líderes do manifesto ágil são membros da aliança ágil.

Princípios

    1. “A prioridade é satisfazer ao cliente por meio de entregas contínuas e frequentes de software de valor.” O cliente deve receber de forma rápida e eficiente o produto solicitado, sendo o principal foco das equipes de desenvolvimento ágil.
    1. “Mudanças de requisitos são bem-vindas, mesmo em uma fase avançada do projeto”. Processos ágeis esperam que a mudança traga uma vantagem competitiva ao cliente.
    1. Processos ágeis se adaptam no caso de mudanças nos projetos ao longo de seu desenvolvimento, contudo, as mudanças devem ser aceitas somente com o intuito de agregar valor e vantagens competitivas ao negócio do cliente.
    1. “Entregas com frequência de software funcional, sempre na menor escala de tempo, de algumas semanas a alguns meses, preferindo sempre um período curto.” Buscar realizar entrega funcional de 39 software, dentro de parâmetros de qualidade e o mais breve possível.
    1. “As equipes de negócio e de desenvolvimento devem trabalhar juntas diariamente durante o projeto.” Toda a equipe de desenvolvimento deve trabalhar junta e estar alinhada, principalmente com o cliente, que deve estar sempre presente.
    1. “A maneira mais eficiente da informação circular entre a equipe de desenvolvimento é por uma conversa cara a cara.” O cliente sempre deve estar presente, realizando reuniões mais frequentes e rápidas, para melhor entendimento das necessidades do cliente e negócio.
    1. “Ter um software funcionando é a medida primária de progresso.” Esta preocupação remete ao entendimento de que entregar um software que não funcione é o mesmo que não entregá-lo. Espera�se que, na medida em que as funcionalidades sejam validadas, sejam implementadas e entregues ao cliente.
    1. “Processos ágeis promovem o desenvolvimento sustentável. Patrocinadores (quem financia o projeto), desenvolvedores e usuários devem ser capazes de manter um ritmo constante.” Deve-se manter um ritmo de entrega de novas funcionalidades, mantendo a comunicação e foco nas prioridades do projeto.
    1. “Atenção contínua à excelência técnica e um bom design aumenta a agilidade. ” Manter um padrão de projeto para garantir a qualidade e excelência técnica.
    1. “Simplicidade é essencial.” Criar projetos simples para atendimento dos requisitos dos clientes, evitando arquiteturas complexas que podem atrasar as entregas.
    1. “As melhores arquiteturas, requisitos e projetos provêm de equipes organizadas.” Formar equipes autoorganizáveis, que se adaptam às mudanças e reinventam e reestruturam o negócio com criatividade.
    1. “Em intervalos regulares, a equipe deve refletir sobre como se tornar mais eficaz, buscando sintonizar e ajustar seus 40 comportamentos.” Realizar reuniões de avaliação de desempenho são importantes para identificar processos falhos e desnecessários e, planejar planos de melhoria.

Abordagens Ágeis – XP e FDD

Extreme Programming (XP)

Caracteristicas

O Extreme Programming, por Sommerville (2011), é uma metodologia ágil para equipes pequenas e médias que desenvolvem software baseado em requisitos vagos e que são modificados rapidamente. Como princípios da XP

  • Feedback constante.
  • Abordagem incremental.
  • Comunicação entre pessoas é encorajada.
  • Simplicidade.

12 práticas

  • Planejamento: consiste em decidir o que é necessário fazer e o que pode ser adiado no projeto. A XP baseia-se em requisitos atuais reais para desenvolvimento de software, não em possíveis requisitos futuros.
  • Entregas frequentes: visam a construção de um software simples, atualizado à medida que novos requisitos surgem. Cada versão deve conter os requisitos de maior valor para o negócio.
  • Metáfora: são as descrições de um software sem a utilização de termos técnicos, com o intuito de guiar o desenvolvimento do software.
  • Projeto simples: o programa deve ser o mais simples possível e satisfazer aos requisitos atuais, sem a preocupação com requisitos futuros. Eventuais requisitos futuros devem ser adicionados assim que realmente existirem.
  • Testes: a XP focaliza a validação do projeto durante todo o processo de desenvolvimento. Os programadores desenvolvem o software criando, primeiramente, os casos de testes.
  • Programação em Pares: a implementação do código é feita em duplas, ou seja, dois desenvolvedores trabalham em uma única máquina. Um desenvolvedor implementa o código enquanto o outro observa continuamente o trabalho que está sendo feito, procurando por erros sintáticos e semânticos e pensando em como melhorar o código.
  • Refatoração: aperfeiçoar o projeto do software em todo o desenvolvimento. A refatoração deve ser feita sempre que for possível simplificar uma parte do software, sem que seja perdida nenhuma funcionalidade.
  • Propriedade coletiva: o código do projeto pertence a todos os membros da equipe. Qualquer pessoa pode adicionar valor a um código, mesmo que não o tenha desenvolvido.
  • Integração contínua: uma vez testado e validado, o código produzido por uma equipe deve ser integrado ao sistema e este, por sua vez, também deve ser testado.
  • Trabalho semanal de 40 horas: a XP assume que não se deve fazer horas extras constantemente. Caso seja necessário trabalhar mais que 40 horas pela segunda semana consecutiva, há um problema no projeto que deve ser resolvido não com o aumento de horas trabalhadas, mas com melhor planejamento, por exemplo.
  • Cliente presente: o cliente deve participar efetivamente de todo o desenvolvimento do projeto, devendo estar disponível para sanar todas as dúvidas sobre requisitos.
  • Código-padrão: recomenda-se a adoção de regras de escrita. A padronização favorece o trabalho em equipe e a propriedade coletiva do código.

Processo do Extreme Programming (XP)

Feature Driven Development (FDD)

Características básicas

  • Benefícios a gerentes, desenvolvedores e clientes
  • Benefício ao cliente por meio de trabalho significativo
  • Atende equipes pequenas, médias ou grandes
  • Software de qualidade
  • Entrega de resultados frequentes, tangíveis e funcionais
  • Permite acompanhamento do progresso do desenvolvimento do projeto

Boas práticas

    1. Modelagem de objetos do domínio: atividade que deve ser realizada com toda a equipe com a finalidade de estudar, analisar e modelar um sistema. Deve-se produzir um documento de requisitos a partir de um método de coleta de dados, que pode ser uma entrevista, questionários, além de diagramas da Unified Modeling Language (UML) que ajudam o desenvolvedor.
    1. Desenvolvimento por funcionalidade: essa prática faz a sugestão que se construa uma lista de funcionalidades, decompondo funcionalmente o domínio do negócio em áreas de negócio, atividades do negócio e passos da atividade de negócio.
    1. Entregas regulares: o desenvolvedor deve sempre reconstruir o software, incluindo novas funcionalidades, assim desenvolvedores trabalham e utilizam uma versão sempre atualizada do projeto. Os clientes vão se beneficiar, pois sempre estarão com a última versão do projeto.
    1. Formação da equipe de projeto–a equipe deve ser composta pelos seguintes profissionais:
    • a. Gerente de projeto: possui contato direto como cliente (stakeholders) e capta todos os requisitos e restrições. O gerente monta sua equipe com afinidades e experiências das pessoas. Cabe ao gerente determinar a quantidade de analistas e acompanhar todo o desenvolvimento.
    • b. Equipe de modelagem e planejamento representam um grupo de pessoas definidos pelo gerente para elaborar a lista de funcionalidades do sistema. Esse profissional deve dominar, entre outras habilidades, técnicas de modelagem de sistema, como UML, devendo dividir as funcionalidades para a equipe de funcionalidades (desenvolvedores), por meio do programador chefe, que determina seu sequenciamento.
    • c. Programador chefe: refina a lista de funcionalidades e as transforma em modelo de objetos, organizando os trabalhos, escolhendo a linguagem a ser utilizada, formas de armazenamento, revisão e liberação ao cliente.
    • d. Equipe de funcionalidades: são os desenvolvedores, profissionais que conhecem as ferramentas de desenvolvimento e escreve os métodos e classes (no caso da Programação Orientada a Objetos) para a concepção do projeto. Essa equipe também é responsável por construir testes de unidade para validar o projeto e inspecionar o software em todas as suas fases.
    1. Posse individual do código: elaborar uma lista contendo as funcionalidades do sistema e seus proprietários, de forma que o programador seja responsável pela funcionalidade implementada.

Feature Driven Development (FDD)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment