Please enable JavaScript.
Coggle requires JavaScript to display documents.
Qualidade de software em projetos ágeis - Coggle Diagram
Qualidade de software em projetos ágeis
Motivação
Problemas no desenvolvimento tradicional de projetos
Orientado a processos
Processos bem definidos
Garantia da qualidade do produto
Rígido
Pressupõe que é possível especificar de antemão todos os requisitos do projeto
Preditivo
Cada etapa de desenvolvimento é baseada na anterior
Parte do princípio que os requisitos são estáveis
Burocrático
Sobrecarrega o desenvolvimento
Compromete a velocidade do projeto
Possui forte resistência a mudanças
Demora-se muito tempo para análise e feedback
Qualidade do produto se, e somente se, qualidade do processo
Foco em reproduzir e controlar
Reproduzir
Inibe aprendizado e criatividade
Mão de obra é uma mera ferramenta
Controlar
Gerenciamento excessivo
Manifesto Ágil (2001)
↑ Indivíduos e interações ↓ processos e ferramentas
↑ Software em funcionamento ↓ documentação abrangente
↑ Colaboração com o cliente ↓ Negociação de contratos
↑ Responder a mudanças ↓ Seguir planos
Princípios do desenvolvimento ágil
Entrega de Produto
Entregas iterativas baseadas em features
Entregar valor ao cliente
Buscar a excelência técnica
Liderança ⇔ Colaboração
Construir equipes adaptativas (multitalentos)
Encorajar a exploração
Estudos
Comunicação
Simplificar
Técnicas de gerenciamento ágil de projetos
Foco nas pessoas
Pessoas e interações determinam o sucesso do projeto
Organização do projeto em iterações
Curtos períodos de tempo, em que, ao final, chega-se a um objetivo específico
Estabelecer datas de entrega final somente se necessário
Indivíduo escolhe em que trabalhar
Organização própria e pessoal
Estimar coisas pequenas
É mais simples estimar um trabalho de um dia, do que de um mês
Indivíduo estima o próprio trabalho
Estimativas vêm de baixo pra cima, não dos superiores
Auto conhecimento sobre sua capacidade influencia na estimativa
Desenvolvimento Ágil VS Tradicional
Tradicional
Constante/Fixo
Escopo
Variável
Custos
Tempo de entrega
Orientado pelo planejamento
Ênfase no planejamento e controle
Ágil
Constante/Fixo
Custos
Tempo de entrega
Variável
Escopo
Orientado pela visão/valor
Ênfase na execução e adaptação
Gerente de projeto
Reconhecer que o projeto sofrerá muitas mudanças
durante a sua execução
Gerenciar as influências externas
Ser mais um facilitador
Atuar como uma canalizador de informações
Manter uma visão geral do projeto para o time
SCRUM
Visão geral
Etapas
Planning
Escolha de features do product backlog para serem colocadas no sprint backlog
Daily
Reunião diária
Foco na qualidade do produto e dos processos
Review
Foco na qualidade do produto (resultados da sprint)
Retrospective
Foco na qualidade do processo (acertos e erros)
Componentes
Produto
Product backlog
Listagem de todas as features, e seus valores, a serem realizadas na sprint
Sprint backlog
To Do
In Progress
Done
Sprint
Período de 2 a 4 semanas
Realização de features pré-definidas e escolhidas
Sprint burndown
Gráfico do total de pontos x dias da sprint
Inicia com o valor do somatório das tarefas da sprint e diminui gradativamente, de acordo com a conclusão das tarefas
Equipe
Product Owner
Maximiza o valor do produto e do trabalho da equipe
Determina a visão do projeto
Define e prioriza as funcionalidades
Aceita/rejeita o resultado do trabalho
Determina o valor de negócio
Scrum Master
Garante os valores e práticas do SCRUM
Resolve os impedimentos
Conduz as Dailies, Plannings e Retrospectives
Escudo para interferências externas ao time
Desenvolvedores
Responsáveis pelo desenvolvimento e entrega das features
Extreme Programming (XP)
Valores
Comunicação
Membros (clientes, gerentes, devs) interagindo ao máximo pessoalmente
Simplicidade
Sempre adota-se a solução mais simples, que funcione
Feedback
Equipe constantemente fornece informações sobre suas tarefas e problemas encontrados
Respeito
Cada pessoa designada a um projeto, contribui pra um objetivo em comum
Coragem
Algumas das atitudes e práticas do XP são inovadoras, é preciso de coragem para colocá-las em prática
Práticas
Desenvolvimento orientado a Testes (TDD)
Jogo do planejamento
Cliente no local
Programação em pares
Refatoramento
Integração contínua (CI/CD)
Releases pequenos
Projeto simples
Padrões de codificação
Propriedade coletiva do código
Metáfora
Semana de quarenta horas
Ciclo de vida
Fase de exploração
Anterior à construção do sistema
Verifica a viabilidade do sistema
Experimenta possíveis soluções
Fase de planejamento inicial
Define as estórias
Define com o cliente o escopo e data do lançamento
Fase de iterações do lançamento
Em uma iteração, algumas estórias são implementadas
Atividades de uma iteração
Escrita dos casos de teste
Projeto e refatoramento
Codificação
Realização dos testes
Integração
Fase de produção
O sistema é posto em operação em um ambiente que simula o de produção (aquele que está lançado)
Verifica-se, nesse ambiente, performance e desempenho
Fase de manutenção
Para o XP, manutenção é natural
As práticas consideram um ambiente onde existem constantes alterações
Fase de morte
Término de um projeto XP
Papéis
Cliente
Escreve as estórias com os programadores e define suas prioridades
Ajuda na escrita de casos de teste funcionais
Programador
Escreve o código e os casos de teste unitário
Sempre em pares
Estima as estórias
Testador
Ajuda o cliente na definição e escrita dos testes funcionais
Pode desempenhar papel de programador
Rastreador/Gerente
Coleta dados sobre o andamento do projeto
Verifica a conformidade com o planejamento feito para as iterações e lançamento
Treinador
Preocupa-se com a execução técnica e evolução do processo
Possui conhecimentos do XP e orienta a equipe
Testes
Escritos antes da programação (polêmica)
Dois tipos de teste
Unitário
De responsabilidade do programador
São automatizados
Devem ser executados após implementação de uma feature
Defeitos corrijidos, caso os testes apontem
Funcional de aceitação
De responsabilidade do cliente
PODEM ser automatizados
Pair programming permite inspeções constantes do código
Integração contínue pressupões testes de integração
Após refatoramento, deve ser feita nova rodada de testes
Testes de software em projetos ágeis
Manifesto do teste ágil
↑ Testar continuamente
↓ Testar no final
↑ Prevenir defeitos
↓ Encontrar defeitos
↑ Entender o teste
↓ Verificar a funcionalidade
↑ Time responsável pela qualidade
↓ Responsabilidade do testador
Características dos testes ágeis
Mudança e regressão
Responder a mudanças é um princípio chave
Podem ser feitas em funcionalidades anteriores
Aumento de risco de regressão
A cada iteração o produto cresce
Isso implica no aumento de testes
Ativos (artefatos) de teste devem ser atualizados constantemente, a cada iteração
Investimento em automação em todos os níveis o mais rápido possível
Demanda o envolvimento de toda a equipe
Todos estão igualmente comprometidos com a entrega
Quadrantes de testes ágeis
Q1. Automatizado
Voltado para a tecnologia
Orienta o desenvolvimento
Testes unitários e de integração
Q2. Automatizado e manual
Voltado para os negócios
Orienta o desenvolvimento
Testes funcionais
Protótipos
Simulações
Q3. Manual
Voltado para o negócio
Critica o produto
Testes exploratórios
Cenários
Testes de usabilidade
Testes de aceitação do usuário
Versões alpha/beta
Q4. Ferramentas
Voltado para a tecnologia
Critica o produto
Testes de performance, carga e segurança
Responsabilidades dos testadores
Melhorar as estórias do usuário
Especificações mais enxitas de requisitos
Envolvimento do testador desde o início do desenvolvimento
Identifica detalhes ausentes
Identifica recursos não-funcionais
Formula perguntas aos representates do negócio sobre as estórias do usuário
Define as estórias testáveis e propõe formas de testá-las
Confirma os critérios de aceitação
Colaborar com os representantes de negócio
Criação dos testes de aceitação adequados
Definir os testes e estimar seus esforços para a iteração e para o lançamento
Definir a estratégia de teste e abordagens de automação
Transferir e ampliar o conhecimento dos testes para outros membros da equipe
Influenciar o desenvolvimento do produto
Pair programming → Pair testing
Testes unitários são automatizados e de responsabilidade do programador
Testes de verificação das funcionalidades podem ser feitos por ambos testadores e programadores
Testes de regressão reexecutam os testes de unidade e de verificação através de integração contínua
Necessidade de selecionar os casos de teste candidatos
Testes de validação são, normalmente, manuais
Podem envolver desenvolvedores, testadores e stakeholders