metodologias ageis

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 
TRADICIONAIS X ÁGEIS
Qualidade de Software
Ementa
17
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
18
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
4
Qualidade de Software
Ementa
19
XP (EXTREME PROGRAMMING)
� XP (do inglês, Extreme Programming)
Qualidade de Software
Ementa
20
XP (EXTREME PROGRAMMING)
� É uma das mais populares metodologias ágeis e amplamente
usado
� 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
21
XP (EXTREME PROGRAMMING)
� O Extreme Programming (XP) usa uma abordagem 'extrema' ao
desenvolvimento iterativo
� Novas versões podem ser construídas várias vezes por dia
� Incrementos são entregues aos clientes a cada 2 semanas
• O desenvolvimento incremental é mantido através de releases de sistema pequenos e
frequentes
� Todos os testes devem ser realizados em todas as versões e cada versão só
é aceita se os testes forem concluídos com sucesso
Qualidade de Software
Ementa
22
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
23
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
� O envolvimento do cliente significa compromisso do cliente com a equipe
em tempo integral (o cliente faz parte da equipe de desenvolvimento)
Qualidade de Software
Ementa
24
XP (EXTREME PROGRAMMING)
� A simplicidade visa permitir a criação de código enxutoque 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
� Manter a simplicidade através de
constante refatoração de código
Resumindo...
implementação rápida de um 
produto simples!
5
Qualidade de Software
Ementa
25
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 acordo com as expectativas do cliente
Qualidade de Software
Ementa
26
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
Qualidade de Software
Ementa
27
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
28
CICLO DO XP
Qualidade de Software
Ementa
29
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
Qualidade de Software
Ementa
30
CICLO DE FEEDBACK DO XP
6
Qualidade de Software
Ementa
31
EXEMPLO DE ESTÓRIA
Qualidade de Software
Ementa
32
EXEMPLO DE CARTÕES DE TAREFA
Qualidade de Software
Ementa
33
PRÁTICAS DO XP
� Planejamento incremental
� Negociação com o cliente, necessidades e prioridades são expostas
� Requisitos gravados em cartões de história, priorização, definição de
recursos e prazo, divisão de histórias em tarefas
� Entregas frequentes (pequenos releases)
� 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
34
PRÁTICAS DO XP
� Desenvolvimento test-first
� 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, código simples e manutenível
� Propriedade coletiva
� O código pertence a todos os membros da equipe
Qualidade de Software
Ementa
35
PRÁTICAS DO XP
� Integração contínua
� Uma vez testado e validado, o código produzido deve ser integrado
(gradativamente) ao sistema, todos os testes unitários devem passar
� Ritmo sustentável de trabalho
� Evita adotar horas extras constantemente (foco nas pessoas)
� Cliente presente
� A participação do cliente é fundamental, um representante do usuário final
do sistema deve estar disponível todo o tempo
� Código-padrão
� Recomenda-se a adoção de regras de escrita, estilos, formatos, etc.
Qualidade de Software
Ementa
36
XP E AS MUDANÇAS DE 
REQUISITOS
� O senso comum da engenharia de software diz que se deve
projetar pensando em mudanças
� Vale a pena gastar tempo e esforço antecipando as mudanças já que,
posteriormente, esse esforço reduz custos no ciclo de vida
No entanto, o XP afirma que isso não vale a pena já
que as mudanças não podem ser antecipadas de
forma confiável
No entanto, o XP afirma que isso não vale a pena já
que as mudanças não podem ser antecipadas de
forma confiável
Ao invés disso, propõe melhorias constantes do
código (refatoração) para tornar as mudanças
mais fáceis quando essas precisam ser
implementadas
7
Qualidade de Software
Ementa
37
REFATORAÇÃO
“Assim como a nossa casa, sistemas também se deterioram quando não investimos
continuamente na limpeza e na organização dos mesmos. Isso acontece, à medida em que
novas funcionalidades são inseridas, alterações são feitas, erros são corrigidos e mais código
é introduzido. Para evitar que a aplicação se transforme em uma casa desorganizada e difícil
de manter, equipes XP utilizam a prática de refatoração. Elas alteram pequenas partes do
sistema, frequentemente, sempre que encontram uma oportunidade para melhorar o
código, tornando-o mais limpo e mais fácil de ser compreendido. Tais alterações não mudam
o comportamento das funcionalidades, apenas melhoram a estrutura do código. “
Fonte: http://www.desenvolvimentoagil.com.br/xp/praticas/refatoracao
Qualidade de Software
Ementa
38
REFATORAÇÃO
� A equipe de programação busca possíveis melhorias de software
e as faz mesmo quando essas não são uma necessidade imediata
� O que melhora a inteligibilidade do software e reduz a
necessidade de documentação
� Torna-se mais fácil fazer mudanças porque o código é bem
construído e limpo
� No entanto, algumas mudanças requerem refatoração da
arquitetura, o que é muito mais caro
Qualidade de Software
Ementa
39
REFATORAÇÃO
� Exemplos
� Reorganização de uma hierarquia de classes para remover código duplicado
� Organização e renomeação de atributos e métodos para torná-los mais
fáceis de entender
� A substituição do código com as chamadas para métodos definidos em uma
biblioteca de programas
Qualidade de Software
Ementa
40
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
41
GERENCIAMENTO ÁGIL DE 
PROJETOS
� Principal responsabilidade de gerentes de projeto de software
� Gerenciar o projeto para que o software seja entregue em tempo e dentro
do orçamento planejado para o projeto
� Abordagem padrão
� Dirigida a planos
• Plano para o projeto mostrando o que deve ser entregue, quando deve ser entregue e
quem irá trabalhar no desenvolvimento dos entregáveis
� O gerenciamento ágil de projetos requer uma abordagem
diferente, adaptada ao desenvolvimento incremental e aos
pontos fortes particulares dos métodos ágeis
Qualidade de Software
Ementa
42
GERENCIAMENTO ÁGIL DE 
PROJETOS
8
Qualidade de Software
Ementa
43
SCRUM
Qualidade de Software
Ementa
44
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 emequipe, pois se um membro falhar o outro time se sobressai
O objetivo é fornecer um
processo conveniente para
projeto e desenvolvimento
orientado a objeto
Qualidade de Software
Ementa
45
SCRUM
� 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
46
CARACTERÍSTICAS DO 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
47
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
Qualidade de Software
Ementa
48
SCRUM
� É um método ágil genérico mas seu foco é na gerência de
desenvolvimento iterativo ao invés de práticas ágeis específicas
� Existem três fases no Scrum
� A fase inicial é uma fase de planejamento em que se estabelece os objetivos
gerais do projeto e se projeta a arquitetura do software
� Essa é seguida por uma série de ciclos de Sprint, em que cada ciclo
desenvolve um incremento do sistema
� A fase de encerramento do projeto finaliza o projeto, completa a
documentação necessária como manuais de ajuda do sistema e manuais de
usuário e avalia as lições aprendidas no projeto
9
Qualidade de Software
Ementa
49
CONCEITOS DO SCRUM
Qualidade de Software
Ementa
50
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
51
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
52
CONCEITOS DO SCRUM
� Sprint planning
� Reunião de planejamento que ocorre no início do Sprint
� Define objetivos, atividades e prioridades
Qualidade de Software
Ementa
53
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
54
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)
10
Qualidade de Software
Ementa
55
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
56
CONCEITOS DO SCRUM
� Exemplo
Qualidade de Software
Ementa
57
CONCEITOS DO SCRUM
� Exemplo
Qualidade de Software
Ementa
58
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
� Para apresentar 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
59
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 problemas não são postergados e atacados “tardiamente”
Qualidade de Software
Ementa
60
O PROCESSO DO SCRUM
11
Qualidade de Software
Ementa
61
O PROCESSO DO SCRUM
� O ciclo de Sprint
� Os Sprints possuem um deadline definido, geralmente de 2 a 4 semanas
� Correspondem ao desenvolvimento de um release de um sistema em XP
� O ponto de partida de planejamento é o backlog de produto, que é a lista
de trabalho a ser feito no projeto
� A fase de seleção envolve a seleção das características e funções que serão
desenvolvidas durante o Sprint, pela equipe do projeto que trabalha com o
cliente
Qualidade de Software
Ementa
62
O PROCESSO DO SCRUM
� O ciclo de Sprint
� Assim que isso é definido, a equipe se organiza para desenvolver o software
� Durante esse estágio a equipe é isolada do cliente e da orgainzação, com
todas as comunicações canalizadas por meio do chamado “Scrum Master”
� A função do Scrum Master é proteger a equipe de desenvolvimento de
distrações externas
� Ao final do Sprint o trabalho feito é revisto e apresentado aos stakeholders,
assim o próximo ciclo de Sprint começa
Qualidade de Software
Ementa
63
O PROCESSO DO SCRUM
Qualidade de Software
Ementa
64
O PROCESSO DO SCRUM
Fonte: Processo da metodologia Scrum (Mallmann, 2010)
Qualidade de Software
Ementa
65
O PROCESSO DO SCRUM
Qualidade de Software
Ementa
66
TRABALHO EM EQUIPE
� O Scrum Master é um facilitador
� Funções: organiza reuniões diárias, mantêm o backlog do trabalho a ser
feito, grava decisões, mede o processo usando o backlog e comunica-se
com os clientes e a gerência fora da equipe
� A equipe inteira comparece às reuniões diárias curtas
� Todos os membros da equipe compartilham informações, descrevem seu
progresso desde a última reunião, descrevem os problemas que surgiram e
o quê está planejado para o dia seguinte
12
Qualidade de Software
Ementa
67
TRABALHO EM EQUIPE
� Com isso, todos na equipe sabem o que está acontecendo e, caso
ocorra um problema, podem replanejar o trabalho a curto prazo
para lidar com a situação
� Consequentemente, evita-se falhas de comunicação☺
Qualidade de Software
Ementa
68
BENEFÍCIOS DO SCRUM
� O produto é dividido em um conjunto de partes gerenciáveis e intelígiveis
� Requisitos instáveis não impedem o progresso
� Toda a equipe tem visão de tudo e consequentemente a comunicação da
equipe é melhorada
� Os clientes recebem a entrega dos incrementos no tempo certo, além do
feedback de como o produto funciona
� Se estabelece a confiança entre os clientes e os desenvolvedores e se cria
uma cultura positiva na qual todos acham que o projeto dará certo
Qualidade de Software
Ementa
69
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 norequisito.
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
70
COMO ESCALONAR OS 
MÉTODOS ÁGEIS?
� Os métodos ágeis provaram-se bem-sucedidos para projetos
pequenos e médios que podem ser desenvolvidos por uma equipe
pequena e localizada
� É dito que o sucesso desses métodos ocorre devido a melhorias
na comunicação, as quais são possíveis quando todos estão
trabalhando juntos
� O escalamento dos métodos ágeis envolve mudá-los para que
lidem com projetos maiores e mais longos onde existem múltiplas
equipes de desenvolvimento, talvez trabalhando em localizações
diferentes
Qualidade de Software
Ementa
71
DESENVOLVIMENTO DE SISTEMAS 
DE GRANDE PORTE
� Geralmente, os sistemas de grande porte são coleções de sistemas
separados que se comunicam
� Normalmente, as equipes desenvolvem cada sistema separadamente
� Frequentemente, estão em locais diferentes e em fuso-horários diferentes
� Incluem e interagem com vários sistemas existentes
� Vários dos requisitos de sistema se preocupam com essa interação o que não
permite flexibilidade e desenvolvimento incremental
� Vários sistemas são integrados para criar um sistema
� Uma fração significante do desenvolvimento é voltada para a configuração do
sistema ao invés do desenvolvimento do código original
Qualidade de Software
Ementa
72
DESENVOLVIMENTO DE SISTEMAS 
DE GRANDE PORTE
� Geralmente, os sistemas de grande porte são
� Restringidos por regras externas e regulamentações que limitam a forma
como podem ser desenvolvidos
� Tempo de aquisição e desenvolvimento
longo, portanto é difícil manter equipes
coesas, que conhecem o sistema já que
inevitavelmente as pessoas podem sair
para outros trabalhos e projetos
� Tem um conjunto diversificado de
stakeholders sendo praticamente
impossível envolver todos eles no
processo de desenvolvimento
13
Qualidade de Software
Ementa
73
PERSPECTIVAS PARA ESCALONAR
� ‘Scaling up’ se preocupa em usar métodos ágeis para desenvolver
sistemas de software de grande porte que não podem ser
desenvolvidos por uma equipe pequena
� ‘Scaling out’ se preocupa em como os métodos ágeis podem ser
introduzidos em uma grande organização com vários anos de
experiência de desenvolvimento de software
� Escalar métodos ágeis é essencial manter os fundamentos ágeis
� Planejamento flexível, releases de sistema frequentes, integração contínua,
desenvolvimento dirigido a testes e boa comunicação entre os membros da
equipe
Qualidade de Software
Ementa
74
PERSPECTIVAS PARA ESCALONAR
� Para o desenvolvimento de sistemas de grande não é possível
focar apenas no código do sistema
� De início, é necessário fazer mais designs e documentação do sistema
� Os mecanismos de comunicação entre as equipes precisam ser
desenvolvidos e usados
� Telefones comuns, vídeo-conferências, reuniões virtuais curtas e frequentes
entre os membros da equipe, nas quais as equipes se informam
mutuamente acerca do progresso do trabalho
� Integração contínua, na qual o sistema todo é construído a
qualquer mudança, é praticamente impossível
� No entanto, é essencial manter builds frequentes e releases regulares
Qualidade de Software
Ementa
75
PONTOS IMPORTANTES
� Ponto forte da programação extrema é o desenvolvimento de
testes automatizados antes de se criar um atributo do programa
� Todos os testes devem ser executados com sucesso quando um incremento
é integrado ao sistema
� O Scrum é um método ágil que provê um framework de
gerenciamento de projeto
� É baseado em um conjunto de Sprints, que são períodos fixos de tempo em
que um incremento de sistema é desenvolvido
� Escalamento de métodos ágeis para sistemas de grande porte
ainda é difícil!!!
� Tais sistemas precisam de mais projeto inicial e alguma documentação
Qualidade de Software
Ementa
76
CONCLUSÕES
� Os métodos ágeis são métodos de desenvolvimento
� Incremental centrados no desenvolvimento rápido, frequentes releases de
software, redução de overheads de processo, produção de código de alta
qualidade, e envolve o cliente diretamente no processo de desenvolvimento
� A decisão de quando usar uma abordagem ágil deve depender
� Tipo de software que está sendo desenvolvido, da capacidades da equipe
de desenvolvimento e da cultura da companhia desenvolvedora do sistema
� 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
Qualidade de Software
Ementa
77
CONCLUSÕES
� O Extreme Programming é um método ágil bem conhecido que
integra uma série de boas práticas de programação
� Como por exemplo, releases de software frequentes, melhorias contínuas
de software e participação do cliente na equipe de desenvolvimento
� 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
78
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
14
Qualidade de Software
Ementa
79
BIBLIOGRAFIA
� WAZLAWICK, Raul Sidnei. Engenharia de software: conceitos e práticas. Rio de
Janeiro, RJ: Elsevier, Campus, c2013. xxii, 343 p.
� SOMMERVILLE, Ian. Engenharia de software. 9. ed. São Paulo: Pearson Prentice
Hall, 2011. xiii, 529 p.
� PRESSMAN, Roger S. Engenharia de software: uma abordagem profissional.
Porto Alegre: AMGH, 2011. XXVIII, 780 p.
� KOSCIANSKI, André. Qualidade de software. 2ª edição. Novatec. 2007.
� 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
80
DÚVIDAS