Aula04 - Metodologias ágeis

Prévia do material em texto

1
Qualidade de Software
Ementa
1
METODOLOGIAS 
DE PROCESSOS ÁGEIS
Prof.ª Poliana Corrêa - poliana.correa@sga.pucminas.br
Pontifícia Universidade Católica de Minas Gerais (PUC Minas)
Qualidade de Software
Ementa
2
METODOLOGIAS DE PROCESSOS
TRADICIONAIS
ÁGEIS
Qualidade de Software
Ementa
3
METODOLOGIAS ÁGEIS
� Década de 80 e 90
� Visão generalizada de que a melhor maneira para conseguir construir um
software era por meio de um planejamento cuidadoso, qualidade
formalizada, uso de métodos e ferramentas CASE (Computer-aided software
engineering) e processo de desenvolvimento rigoroso e controlado
� Percepção baseada em sistemas de software grandes e
duradouros, como sistemas aeroespaciais e de governo
� Características: sistema crítico, requer uma análise mais
aprofundada, grandes equipes, dispersas geograficamente e que
trabalhavam com o software por longos períodos
Qualidade de Software
Ementa
4
METODOLOGIAS ÁGEIS
� Processos tradicionais não são adequados para todas as realidades
� Surgiram em um contexto diferente do atual (mainframes, terminais e
sistemas críticos)
� O custo de alterações e correções era muito alto devido as limitações de
acesso aos computadores e de ferramentas automáticas
� Empresas pequenas e médias não possuem recursos suficientes
para adotar metodologias pesadas (orientadas a documentação)
� Em alguns casos, não há recursos nem para adotar processos �
� As metodologias ágeis também são iterativas, mas a ênfase não
está no planejamento antecipado, mas sim em efetuar mudanças
à medida que for necessário!
Qualidade de Software
Ementa
5
METODOLOGIAS ÁGEIS
� As metodologias ágeis são adequadas para situações em que a
mudança de requisitos é frequente
� Para ser realmente considerada ágil, a metodologia deve aceitar a
mudança ao invés de tentar prever o futuro
� O termo metodologia ágeis se popularizou em 2001, quando 17
especialistas em processos de desenvolvimento de software (XP,
Scrum, DSDM, Crystal, etc) estabeleceram princípios comuns a
diferentes métodos
� Criação da Aliança Ágil e do Manifesto Ágil
Qualidade de Software
Ementa
6
METODOLOGIAS ÁGEIS
“O Manifesto Ágil é uma declaração sobre os princípios 
que servem como base para o desenvolvimento 
ágil de software”
www.agilemanifesto.org
� Alguns dos idealizadores
� Kent Beck
� Martin Fowler
� Ken Schwaber
� Jim Highsmith
2
Qualidade de Software
Ementa
7
METODOLOGIAS ÁGEIS
Qualidade de Software
Ementa
8
METODOLOGIAS ÁGEIS
� Principais conceitos do Manifesto Ágil
� Indivíduos e interações entre eles mais que processos e ferramentas
� Software em funcionamento mais que documentação abrangente
� Colaboração com o cliente mais que negociação de contratos
� Responder a mudanças mais que seguir um plano inicial
� Não rejeita processos e ferramentas, documentações ou
negociações
� O objetivo é mostrar que estes tem importância secundária perante
indivíduos, software executável, colaboração e respostas rápidas
� Aproxima-se mais da forma como pequenas e médias empresas trabalham
e respondem às mudanças
Qualidade de Software
Ementa
9
METODOLOGIAS ÁGEIS
� A IDÉIA NÃO É ESSA, MUDANÇA APENAS DE ÊNFASE!
Qualidade de Software
Ementa
10
METODOLOGIAS ÁGEIS
� Para que os métodos ágeis alcance bons resultados
1. A cultura da organização deve apoiar a negociação
Qualidade de Software
Ementa
11
METODOLOGIAS ÁGEIS
� Para que os métodos ágeis alcance bons resultados
2. As pessoas devem ser confiantes
Qualidade de Software
Ementa
12
METODOLOGIAS ÁGEIS
� Para que os métodos ágeis alcance bons resultados
3. A empresa deve ter um ambiente que facilite a
comunicação rápida entre os membros
3
Qualidade de Software
Ementa
13
METODOLOGIAS ÁGEIS
� Para que os métodos ágeis alcance bons resultados
4. Poucas pessoas, mas competentes
Qualidade de Software
Ementa
14
METODOLOGIAS ÁGEIS
� Princípios
� Envolvimento do cliente: os clientes devem estar intimamente envolvidos
no processo de desenvolvimento, seu papel é fornecer e priorizar novos
requisitos do software e avaliar suas iterações
� Entrega incremental: desenvolvimento em incrementos com o cliente,
especificando os requisitos a serem incluídos em cada um
� Pessoas, não processos: as habilidades da equipe de desenvolvimento
devem ser reconhecidas e exploradas
� Aceitar as mudanças: deve-se ter em mente que os requisitos do sistema
vão mudar
� Manter a simplicidade: focar na simplicidade, tanto do software quanto do
processo, eliminando sempre que possível a complexidade do sistema
Qualidade de Software
Ementa
15
METODOLOGIAS 
TRADICIONAIS X ÁGEIS
Tradicionais Ágeis
Duração de vários meses Duração de uma a quatro semanas
Inflexível e previsível Adaptável a mudanças externas
Documentação em excesso
Documentação apenas do que for 
necessário ao cliente
Formado por etapas sequenciais e bem 
definidas
Formado por ciclos ou iterações
Foco nos processos Foco nas pessoas
Prioriza toda a sequencia do 
desenvolvimento (planejamento até os 
testes)
Prioriza a entrega de softwares 
funcionais
Ao final de cada etapa é gerada uma 
documentação
Ao final de cada etapa é gerada uma 
versão do produto que já pode ser 
entregue ao cliente
Qualidade de Software
Ementa
16
METODOLOGIAS ÁGEIS
VÍDEO
“Métodos ágeis e documentação de software”
Disponível em https://www.youtube.com/watch?v=3Smbhnmue7Y
Qualidade de Software
Ementa
17
METODOLOGIAS ÁGEIS 
MAIS CONHECIDAS
� XP (Extreme Programming)
� SCRUM
� DSDM (Dynamic Systems Development Method)
� FDD (Feature Driven Development)
� TDD (Test Driven Development)
� ASD (Adaptative Software Development)
� Crystal Clear
� Kanban
Qualidade de Software
Ementa
18
XP (EXTREME PROGRAMMING)
� XP (do inglês, Extreme Programming)
4
Qualidade de Software
Ementa
19
XP (EXTREME PROGRAMMING)
� É uma das mais populares metodologias ágeis
� Metodologia para equipes pequenas e médias, com requisitos
vagos e modificados rapidamente
� Enfatiza o desenvolvimento rápido do projeto e visa garantir a
satisfação do cliente além de favorecer o cumprimento de
estimativas
Qualidade de Software
Ementa
20
XP (EXTREME PROGRAMMING)
� Principais diferenças entre outras metodologias
� Feedback constante
� Abordagem incremental
� A comunicação entre as pessoas é encorajada
� As práticas e valores proporcionam um agradável ambiente de
desenvolvimento de software, o foco está em quatro valores
� Comunicação
� Simplicidade
� Feedback
� Coragem
Qualidade de Software
Ementa
21
XP (EXTREME PROGRAMMING)
� A comunicação ajuda a manter o melhor relacionamento possível
entre os clientes e desenvolvedores
� Conversas pessoais, preferencialmente
� A comunicação com os gerentes de projetos também é encorajada
Qualidade de Software
Ementa
22
XP (EXTREME PROGRAMMING)
� A simplicidade visa permitir a criação de código enxuto que não
deve possuir funções desnecessárias
� Código com o menor número de componentes (classes e métodos)
� Preocupação com requisitos atuais, evitando adicionar funcionalidades que
só virão a ser importantes no futuro
Resumindo
implementação rápida de um 
produto simples!
Qualidade de Software
Ementa
23
XP (EXTREME PROGRAMMING)
� A prática do feedback constante significa que o programador terá
informações constantes sobre o código e o cliente
� Sobre o código: testes constantes (erros individuais e de integração)
� Sobre o cliente: avaliação de uma parte do código
Eventuais erros e correções são
rapidamente identificados e corrigidos
nas versões seguintes
A tendência é que o produto final esteja
de acordocom as expectativas do cliente
Qualidade de Software
Ementa
24
XP (EXTREME PROGRAMMING)
� É necessário coragem para implantar os três valores anteriores
� Não todas as pessoas que são fáceis de comunicar e bom relacionamento
� Tem que ter coragem para experimentar softwares mais simples
� É preciso coragem para receber feedback constante do cliente
5
Qualidade de Software
Ementa
25
XP (EXTREME PROGRAMMING)
� Papéis
� Cliente: Apresenta as funcionalidades e prioridades do sistema
� Gerente de equipe: Acompanha a equipe
� Desenvolvedor: Codifica e testa as funcionalidades e comunica com o
cliente a cada incremento para esclarecer dúvidas e evitar erros
� Coach: Desenvolvedor com maior experiência na equipe, identifica
habilidades entre os membros para melhor distribuição das tarefas e
verifica se as práticas XP estão sendo seguidas
� Redator técnico: Produz documentação quando necessário
� Tracker: Adicionam lembretes informativos no ambiente de trabalho
(pendências e falhas encontradas)
Qualidade de Software
Ementa
26
PRÁTICAS DO XP
� Planejamento
� Momento de negociação com o cliente
� Necessidades e prioridades são expostas
� Entregas frequentes
� Ao final do incremento uma versão do produto deve ser entregue ao cliente
� Metáforas
� Descrições do software sem a utilização de termos técnicos (estórias)
� Projeto simples
� O programa deve ser o mais simples possível
Qualidade de Software
Ementa
27
PRÁTICAS DO XP
� Testes
� O desenvolvimento inicia com a confecção de casos de testes
� Programação em pares
� A implementação é feita em duplas, um codifica e o outro observa, ocorre
troca de funções permitindo que um aprenda com o outro
� Refatoração
� Aperfeiçoamento do projeto do software
� Propriedade coletiva
� O código pertence a todos os membros da equipe
Qualidade de Software
Ementa
28
PRÁTICAS DO XP
� Integração contínua
� Uma vez testado e validado, o código produzido deve ser integrado
(gradativamente) ao sistema
� Trabalho semanal de 40 horas
� Evita adotar horas extras constantemente (foco nas pessoas)
� Cliente presente
� A participação do cliente é fundamental durante todo o processo
� Código-padrão
� Recomenda-se a adoção de regras de escrita, estilos, formatos, etc.
Qualidade de Software
Ementa
29
PRÁTICAS DO XP
� Integração contínua
� Uma vez testado e validado, o código produzido deve ser integrado
(gradativamente) ao sistema
� Trabalho semanal de 40 horas
� Evita adotar horas extras constantemente (foco nas pessoas)
� Cliente presente
� A participação do cliente é fundamental durante todo o processo
� Código-padrão
� Recomenda-se a adoção de regras de escrita, estilos, formatos, etc.
Qualidade de Software
Ementa
30
CICLO DE FEEDBACK DO XP
� O cliente escreve uma estória de usuário (funcionalidades)
� Espera-se que uma estória seja dividida em algumas tarefas
� Cada tarefa é descrita em um cartão de tarefas e esses são distribuídos aos
desenvolvedores para implementação
� O acompanhamento pode ser diário ou em intervalos de poucos dias (status
da tarefa, o que ainda precisa ser feito e comentários)
� Cada estória de usuário deve durar em média 3 três semanas (em média,
uma iteração por mês)
� A última semana pode ser usada para refatoração de códigos e testes
� Ao final da estória, um software executável é entregue
6
Qualidade de Software
Ementa
31
CICLO DE FEEDBACK DO XP
Qualidade de Software
Ementa
32
SCRUM
Qualidade de Software
Ementa
33
SCRUM
� O termo SCRUM é uma jogada do Rugby que envolve oito
jogadores de cada time, onde eles se “encaixam” para se tornar
uma muralha, para essa jogada é fundamental o trabalho em
equipe, pois se um membro falhar o outro time se sobressai
Qualidade de Software
Ementa
34
SCRUM
� O objetivo é fornecer um processo conveniente para projeto e
desenvolvimento orientado a objeto
� Apresenta foco em visibilidade, inspeção e adaptabilidade
� “As coisas devem estar visíveis a todos os envolvidos no desenvolvimento, a
inspeção deve ser uma ação corrente e, consequentemente, as ações para
adaptação do produto de software devem ser realizadas”
� Visa encontrar uma forma de trabalho dos membros da equipe
para produzir o software de forma flexível e em um ambiente em
constante mudança (ambientes dinâmicos)
� Metodologia baseada em princípios semelhantes aos da XP
� Equipes pequenas e iterações curtas
Qualidade de Software
Ementa
35
SCRUM
� Processo iterativo e incremental
� Framework de gerenciamento e controle empírico
� Entregas (em média) a cada 30 dias
� Ciclos de feedback para “Inspeção e Adaptação”
� Permite o gerenciamento de projetos complexos
� Escalável para projetos, longos, grandes e distribuídos
� Bastante simples de entender, mas difícil de aplicar
Qualidade de Software
Ementa
36
PAPÉIS NO SCRUM
� Scrum master
� Gerencia o projeto, dá suporte a equipe e acompanha a produtividade
� Implanta práticas e valores do Scrum
� Product Owner
� Cliente ou seu representante, determina as funcionalidades do produto
� Modifica requisitos e aprova ou não cada versão do software
� Scrum Team
� Equipe composta por volta de 7 pessoas
� Profissionais multifuncionais, não há divisão de papéis na equipe
7
Qualidade de Software
Ementa
37
CONCEITOS DO SCRUM
Qualidade de Software
Ementa
38
CONCEITOS DO SCRUM
� Sprint
� Ciclo ou iteração com duração média de 30 dias
� Desenvolvimento e implantação de funcionalidades
� Ao final ocorre a entrega de um incremento funcional ao cliente
Qualidade de Software
Ementa
39
CONCEITOS DO SCRUM
� Product Backlog
� Lista que contém todas as funcionalidades do produto
� Cada funcionalidade é uma “estória” definida pelo Product Owner
� Pode sofrer alterações ao longo de cada Sprint
Qualidade de Software
Ementa
40
CONCEITOS DO SCRUM
� Sprint Backlog
� Lista de atividades a ser realizadas na Sprint corrente
� Cada membro da Scrum Team decide que tarefa irá realizar
Qualidade de Software
Ementa
41
CONCEITOS DO SCRUM
� Burndown Chart
� Representação gráfica das atividades do projeto (atualizado diariamente)
� Permite visualizar rapidamente o andamento do projeto (tarefas concluídas
e pendentes)
Qualidade de Software
Ementa
42
CONCEITOS DO SCRUM
� Sprint planning
� Reunião de planejamento que ocorre no início do Sprint
� Define objetivos, atividades e prioridades
8
Qualidade de Software
Ementa
43
CONCEITOS DO SCRUM
� Dashboard
� Quadro com dados da Sprint atual
� Permite acompanhar as atividades realizadas e as que ainda faltam
� Os dados são representados nas formas de notas
Qualidade de Software
Ementa
44
CONCEITOS DO SCRUM
� Exemplo
Qualidade de Software
Ementa
45
CONCEITOS DO SCRUM
� Daily Scrum
� Reuniões diárias rápidas realizadas entre o Scrum Master e a sua equipe
� Objetivo de expor atividades concluídas, próximas atividades e problemas
� Sprint Review
� Reunião entre o Scrum Master, Product Owner e equipe
� Apresenta ao Product Owner os resultados ao final da Sprint
� Sprint Retrospective
� Acontece após a Sprint Review com o intuito de identificar pontos negativos
e positivos para gerar melhorias para o próximo Sprint
Qualidade de Software
Ementa
46
O PROCESSO DO SCRUM
� Plano inicial leve (visionário)
� Requisitos priorizados e detalhados
� Planejamento mensal com seleção dos requisitos prioritários
� Estimativa e planejamento de atividades pela equipe
� Há reuniões de acompanhamento diárias
� Curta duração (aproximadamente 15 minutos)
• Planejar iterações
• Determinar tarefas
• Gerenciar riscos
• Definir prioridades
� Eventuais problemasnão são postergados e atacados “tardiamente”
Qualidade de Software
Ementa
47
O PROCESSO DO SCRUM
Qualidade de Software
Ementa
48
O PROCESSO DO SCRUM
Fonte: Processo da metodologia Scrum (Mallmann, 2010)
9
Qualidade de Software
Ementa
49
O PROCESSO DO SCRUM
Qualidade de Software
Ementa
50
SCRUM: RELATO DE EXPERIÊNCIA
“Um exemplo que já ocorreu em nossas equipes de desenvolvimento foi
que um item de alto risco foi feito e entregue no Sprint 1. O cliente
somente foi homologá-lo de maneira mais profunda no Sprint 4 e
identificou a necessidade de uma alteração conceitual no requisito.
Como neste período muita coisa foi desenvolvida com base em um
conceito que não havia sido validado, o desvio que tivemos na direção
do projeto, bem como o tamanho da alteração necessária para corrigi-lo,
acabou sendo muito maior que o necessário. Ou seja, neste tipo de
processo, se o feedback demorar muito tempo para ser dado, existem
grandes chances de fracasso no desenvolvimento do software.”
Qualidade de Software
Ementa
51
CONCLUSÕES
� Embora ainda estejam na “infância” as metodologias ágeis já
apresentam bons resultados
� Melhores resultados em termos de cumprimento de prazos, de custos e
padrões de qualidade (pesquisa feita em um grupo de empresas em 2001)
� Tamanho dos projetos e das equipes tem crescido nos últimos anos
� O uso correto do XP pode levar a atingir os níveis CMMI 2 e 3
� XP ainda é usado de forma incorreta inibindo certas práticas como “projetar
diagramas”, mas é importante produzir alguns modelos para o
entendimento do problema
� A informalidade no levantamento de requisitos, nem sempre é bem vista
pelo cliente, que podem se sentir inseguros
� Alguns profissionais não se adaptam bem a práticas de equipe
Qualidade de Software
Ementa
52
CONCLUSÕES
� Existem vários casos de sucesso com o Scrum
� Algumas empresas adotam um mistura entre as melhores práticas
de cada metodologia (processo ágil, mas com um pouco de
documentação)
� Desafios futuros
� Eliminar os pontos fracos perante as metodologias tradicionais
� Como aplicá-las em grandes empresas e equipes (resolver problemas de
comunicação internos, principalmente se a equipe estiver distante
geograficamente)
� Casos de sucesso em projetos grandes e críticos
Qualidade de Software
Ementa
53
BIBLIOGRAFIA
� WAZLAWICK, Raul Sidnei. Engenharia de software: conceitos e práticas. Rio de
Janeiro, RJ: Elsevier, Campus, c2013. xxii, 343 p.
� KOSCIANSKI, André. Qualidade de software. 2ª edição. Novatec. 2007.
� PRESSMAN, Roger S. Engenharia de software: uma abordagem profissional.
Porto Alegre: AMGH, 2011. XXVIII, 780 p.
� CARDOSO, Marcos. Metodologias ágeis para desenvolvimento de software.
Disponível em <http://pt.slideshare.net/marcoscardoso/introduo-metodologias
-geis-para-desenvolvimento-de-software>. Acesso em fev. 2014.
� Scrum – Desenvolvimento ágil. Disponível em <http://pt.slideshare.net/
powerirs/scrum-desenvolvimento-gil>. Acesso em fev. 2014.
Qualidade de Software
Ementa
54
DÚVIDAS