Mindmap

Metodologia Agil

lorranz sousa Engenharia de software Portugiesisch

Inhalt der Mindmap

Metodologia Agil

Objetivo
- buscam flexibilizar o desenvolvimento de software
- São baseados em abordagens iterativas
- entregar software funcionando o mais rápido possível
Manifesto Ágil
- Indivíduos e interações
  - são mais importantes que processos e ferramentas
- Software funcionando
  - é mais importante do que documentação completa e detalhada.
- Colaboração com o cliente
  - é mais importante do que negociação de contratos
- Adaptação a mudanças
  - é mais importante do que seguir o plano inicial.
- ) a equipe de desenvolvimento concentra esforços naquilo que gera maior valor para o cliente.
- São Impíricos
  - Baseado na pratica durante o longo do tempo
MODELOS
- eXtreme Programming ( XP )
  - Trata-se de uma metodologia ágil para equipes pequenas e médias desenvolvendo software com requisitos vagos em constante mudança
  - PRATICAS 13
    - Metáfora
      - Todos os interessados no sistema pode contar como funciona o sistema, facilita a comunicação entre eles
    - Projeto simples
      - Desenvolver na forma mais simples para passar nos testes e atender os requisitos
    - Refatoração
      - Melhorar o codigo sem mudar o comportamento externo o desempenho, exem: redudancia, duplicidade etc
    - Pequenas versões
      - As entregas são feitas através de pequenos releases (pedaços) de software FUNCIONANDO
    - Programação em pares
      - programadores trabalham em pares, checando (validando) mutuamente o trabalho feito ◦ Mesma máquina, mesmo mouse, mesmo monitor
    - Propriedade coletiva do código
      - Todos são responsáveis por todo o código e qualquer pessoa está autorizada a realizar mudanças nele
    - Padrão de codificação
      - Todo código é desenvolvido de acordo com um estilo e formato consistentes (padrão)
        Nomes de variáveis começa com letra Maiúscula etc
    - Ritmo sustentável
      - Cada programador trabalha 40 horas por semana, no máximo
    - Reuniões em pé
      - Reuniões rápidas e diárias com a equipe, para discutir apenas o essencial
        No máximo 15 minutos
    - Cliente sempre presente
      - O cliente, com conhecimento sobre o negócio, deve estar disponível em tempo integral para a equipe, presente fisicamente
    - Planejamento Incremental
      - Requisitos são registrados como Estórias dos Usuários e priorizados para serem incluídos em uma determinada iteração
    - Integração Contínua
      - Os diversos módulos do software são integrados o mais cedo possível, para evitar problemas de integração no futuro
    - Desenvolvimento Orientado a Testes
      - os testes são escritos antes mesmo das funcionalidades serem implementadas
  - Valores 5
    - Comunicação
      - Métodos para rapidamente construir e disseminar conhecimento
    - Simplicidade
      - XP encoraja que você comece, sempre, pela solução mais simples que funcione
    - Feedback
      - Do cliente, do sistema e da equipe
    - Coragem
      - Design simples, refatoração…
    - Respeito
      - Respeito da Equipe, do Cliente, dos Usuários…
  - 4 atividades de arcabouços
    - GOVERNANÇA,
    - CODIFICAÇÃO
    - PLANEJAMENTO,
    - TESTE.
      - Tipos de testes
        TDD
        Test Driven Development / Desenvolvimento orientado a teste
        É escrito antes da funcionalidade; após a escrita do teste o desenvolvedor implementa o código para passar no teste; em seguida, refatora o código.
        Teste Unitário
        Automatiza o teste da funcionalidade e tipicamente testa uma classe ou pequeno grupo de classes.
        Se algum erro é descoberto, acrescenta-se imediatamente um caso de teste para ele. Assim busca-se garantir que o erro não se repetirá.
        Teste de Aceitação
        É definido pelo cliente para verificar que o sistema funciona conforme por ele especificado.
        Para cada estória de usuário é escrito um teste. Quando todos os seus testes passam, a estória é considerada completa.
        Teste alfa
        é conduzido pelo cliente no ambiente do desenvolvedor, com este "olhando sobre o ombro" do usuário e registrando erros e problemas de uso
        Testes BETA
        Apos terminar o desenvolvimento é criado um software BETA para realizar alguns testes
        é conduzido em uma ou mais instalações do cliente, pelo usuário final do software
        Teste GAMA
        produtos que são mal testados e são entregues aos usuários finais para que estes encontrem os defeitos já em fase de produção.
        Teste de Configuração
        Testa se o software funciona no hardware a ser instalado.
        Teste de Integridade
        Testa a resistência do software à falhas (robustez).
        Teste de Integração
        Testa se um ou mais componentes combinados funcionam de maneira satisfatória.
        Teste de Performance
        Teste de carga:
        Teste de situação normal
        Teste de stress
        condições extremas de uso
        Teste de estabilidade
        Testa por um longo periodo de tempo
        Testes de Caixa
        Basicamente, teste de caixa branca envolve o código e o de caixa-preta, não.
        BRANCA
        Testa o comportamento interno do componente;
        PRETA
        Testa FUNCIONALIDADES;
        focaliza os requisitos funcionais do software.
        Teste de Regressão
        Reteste de um sistema ou componente para verificar se alguma modificação recente causou algum efeito indesejado, além de, certificar se o sistema ainda atende os requisitos.
  - Caracteristica
    - Ciclo de desenvolvimento curto
    - feedback constante
    - incremental
    - visa entrega partes do softwares operacionais gradativamente, ou seja, pequenos incrementos.
- Scrum
  - É um framework de processo dentro do qual podem ser empregados outros processos e técnicas variadas
  - É possível adicionar papeis, artefatos, atividades e “cerimônias” de acordo com a sua necessidade
  - pode ser aplicado em qualquer contexto no qual um grupo de pessoas trabalhe junto para atingir algum objetivo
  - Caracteristicas
    - As equipes se auto-organizam para maximizar a comunicação e diminuir a supervisão
    - O produto evolui em uma série de “sprints” / Interação
    - Os requisitos são listados em um “product backlog”
    - Não há prática de engenharia prescrita (Scrum se adapta a todas elas)
    - desenvolvimento de projetos de qualquer tamanho ou complexidade.
    - plano flexível
      - Vai-se melhorando a compreensão dos requisitos à medida que se avança no desenvolvimento.
  - Artefatos
    - Product Backlog
      - Uma lista ordenada de tudo o que é necessário no produto
      - Idealmente, cada item deve ter seu peso (prioridade) de acordo com a vontade do cliente
      - É replanejado (repriorizado) no início de cada Sprint
    - Sprint Backlog
      - lista de tarefas que a equipe se compromete a completar dentro de uma determinada Sprint
      - O cliente não enxerga essa etapa do processo
  - PAPEIS
    - Product Owner
      - Define as funcionalidades do produto
      - Prioriza as funcionalidades
      - Aceita ou rejeita os resultados dos trabalhos
      - não é um comitê, mas sim uma PESSOA
    - Team
      - tipicamente entre 5 e 9 pessoas
        Não é obrigado
      - Multi-funcional
        Programadores, testadores, desenvolvedores de interfaces, etc.
        quando somo cada das partes, tem as habilidade necessária desenvolver o produto
      - Auto-organizável
        Cada um sabe o que tem que fazer
      - NÃO TEM PAPEIS
    - Scrum Master
      - Responsável pela aplicação do SCRUM
      - Garante a plena funcionalidade e produtividade da equipe
      - Não tem nada haver com o gerente de projeto
      - Remove obstáculos, facilita resultados
        Exemplo
      - É mais importante ter conhecimento pratico do que teórico
  - EVENTOS
    - Planejamento da Sprint
      - Selecionam-se itens do Product Backlog, e as tarefas são identificadas e estimadas ◦ De forma colaborativa, não apenas feito pelo Scrum Master
      - Dividido em Duas parte
        1ª Parte: O que será feito
        2ª Parte : Como isso será feito
    - Reuniões Diárias (Daily Scrums)
      - Apenas os membros da equipe, todos os dias, em pé, durante 15 minutos
    - Revisão do Sprint
      - Apresentação dos resultados obtidos
      - Todo o time participa, informalmente, 2 horas de preparação, no máximo, Não tem slides
    - Retrospectiva da Sprint
      - Ocorre após a revisão da sprint e antes da próxima reunião de planejamento
      - Inspeciona como foi a última Sprint
      - retrospectiva analisa o processo
    - cada sprint pode ser considerada um projeto
    - Fase Sprint 2-4 semanas
      - indica que os projetos são divididos em ciclos ou sprints, que representam um time box dentro do qual um conjunto de atividades deve ser executado e no final deste ciclo haja um produto apresentável para o cliente.
- FDD (Feature Driven Development)
  - é focada na entrega regular de funcionalidades valiosas para o cliente
  - Ela decompõe o projeto em uma série de funcionalidades
    - Funcionalidade
      - Funcionalidade: uma função que tem valor para o cliente que pode ser implementado em 2 semanas ou menos
  - Caracteristicas
    - Tem mais estrutura que o XP
    - As equipes podem variar entre 10 a 250 Programadores
    - Não necessita de muita documentação
    - é mais enxuto do que o RUP
  - PAPEIS CHAVES
    - Project Manager
      - O líder administrativo do projeto
      - Planeja orçamento, elabora relatórios e protege a equipe de distrações externas
    - Chief Architect
      - Responsável pelo projeto geral do sistema
      - Tem a palavra técnica final sobre o software e sua arquitetura
    - Development Manager
      - Lidera as atividades diárias de desenvolvimento
      - Lidera a equipe de desenvolvimento através de desafios técnicos
    - Chief Programmers
      - Lideram pequenas equipes de desenvolvedores individuais
      - Desenvolvedores experientes
      - Lidera os Class Owners
    - Class Owners
      - São os desenvolvedores individuais
      - Projetam, codificam, testam e documentam as funcionalidades
    - Domain Experts
      - A base de conhecimento para os desenvolvedores
      - Usuários, clientes, patrocinadores, etc.
  - PROCESSOS
  - projetado por Peter Coad, Erich Lefebvre e Jeff De Luca

Bilder und Dateien der Mindmap

Informationen

Beschreibung: Engenharia de software Mindmap am Metodologia Agil, erstellt von lorranz sousa am 29/06/2017.
Erstellt von: lorranz sousa
Aufrufe: 2
Bewertung