Engenharia de Software - Aula 5 - Desenvolvimento Agil

Prévia do material em texto

Assuntos do dia
• Desenvolvimento Ágil
Desenvolvimento Ágil
• Manifesto para o Desenvolvimento Ágil
• Assinado em 2001 por Kent Beck e outros 16 
desenvolvedores, autores e consultores de software
“Desenvolvendo e ajudando outros a desenvolver software, estamos 
desvendando formas melhores de desenvolvimento. Por meio deste trabalho 
passamos a valorizar:
• Indivíduos e interações acima de processos e ferramentas
• Software operacional acima de documentação completa
• Colaboração dos clientes acima de negociação contratual
• Respostas a mudanças acima de seguir um plano”
Desenvolvimento Ágil
• Surgiram de um esforço para sanar fraquezas reais e 
perceptíveis da engenharia de software convencional
• Oferece benefícios importantes• Oferece benefícios importantes
• MAS, não é indicado para todos os tipos de projetos, 
produtos, pessoas e situações
Métodos ágeis = métodos light = métodos enxutos
Desenvolvimento Ágil
“Os modelos de processos esquecem das fragilidades das pessoas que 
desenvolvem o software. Os engenheiros de software não são robôs. Eles 
apresentam variações nos estilos de trabalho; diferenças significativas no 
REFLEXÕES...
nível de habilidade, criatividade, organização, consistência e 
espontaneidade.” (Cockburn, 2002)
“Para que funcionem, os modelos de processos devem fornecer um 
mecanismo realista que estimule a disciplina ou ter características que 
apresentem tolerância com as pessoas que realizam trabalhos de 
engenharia de software” (Pressman, 2011)
Desenvolvimento Ágil
Desenvolvimento Ágil
• AGILIDADE
• Entregar versões funcionais em prazos curtos
• Estar preparado para requisitos mutantes
• Pessoal de negócios e desenvolvedores juntos
• Cliente é considerado parte da equipe (visão nós e eles)
• Troca de informações através de conversas diretas
• Plano de projeto deve ser flexível
Desenvolvimento Ágil
• Agilidade e Custo das Mudanças
• Desenvolvimento de software convencional afirma 
que os custos com de mudanças aumentam de 
forma não linear conforme o projeto avançaforma não linear conforme o projeto avança
• Defensores da agilidade argumentam que o processo 
ágil bem elaborado “achata” o custo da curva de 
mudança 
• Processo ágil envolve entregas incrementais
• Custo das mudanças é atenuado com entrega incremental 
associada a outras práticas ágeis: testes contínuos de 
unidade e programação por pares
Desenvolvimento Ágil
O que é um processo ágil?
• Processo capaz de administrar a imprevisibilidade
• Processo facilmente adaptável
• Adaptar incrementalmente
• Equipe precisa de feedback do cliente para adaptações 
incrementais
• Catalisador para feedback do cliente é um protótipo 
operacional ou parte de um sistema operacional 
entregues em curtos períodos de tempo
Política de Desenvolvimento Ágil
• Debates entre benefícios do desenvolvimento de software 
ágil X processos de engenharia de software convencionais
• Questão importante:
• Como desenvolver software que atenda às necessidades 
atuais dos clientes e que apresente características de 
qualidade que permitirão que seja estendido e ampliado para 
responder às necessidades dos clientes no longo prazo?
• Não existe uma resposta absoluta para essa questão
• Mesmo na ‘escola ágil’ existem várias propostas de 
modelos de processos com diferentes abordagens
Abordagens para Desenvolvimento Ágil
• Extreme Programming – XP – Programação Extrema
• Industrial XP – IXP – Programação extrema industrial
• Scrum
• Adaptive Software Development – ASD – Desenvolvimento 
de software adaptativo
• Dynamic Systems Development Method – DSDM –
Método de Desenvolvimento de Sistemas Dinâmicos
• Crystal
XP - Extreme Programming 
• Amplamente divulgado em 2004 por Kent Beck
• Abordagem mais amplamente usada para desenvolvimento 
de software ágil (dados de 2011)de software ágil (dados de 2011)
• A que se destina
• Grupos de 2 a 10 programadores
• Projetos de 1 a 36 meses
XP - Extreme Programming 
• Valores para trabalhos realizados com a XP
• Comunicação
• Simplicidade
• Feedback• Feedback
• Coragem
• Respeito
XP - Extreme Programming 
• COMUNICAÇÃO
• Colaboração estreita, informal (verbal) entre clientes 
e desenvolvedores
• Estabelecimento de metáforas (histórias) eficazes 
para comunicar conceitos importantes
• Feedback contínuo
• Evitar documentação volumosa como meio de 
comunicação
XP - Extreme Programming 
• SIMPLICIDADE
• Desenvolvedores projetam apenas para as 
necessidades imediatas 
• Não consideram necessidades futuras
• O intuito é criar projetos simples facilmente 
codificados
• Se o projeto tiver que ser melhorado, poderá ser 
refabricado mais tarde
XP - Extreme Programming 
• FEEDBACKS
• Próprio software implementado
• Estratégia de testes eficaz – uso de teste de unidades como 
tática de testes primáriatática de testes primária
• A medida que cada parte (classe) é desenvolvida, são feitos 
testes de unidade para exercitar a funcionalidade desejada
• A medida que um incremento é entregue a um cliente, casos 
de uso (histórias) implementados são usados para testes de 
aceitação
• Se surgem novas necessidades, como parte do 
planejamento interativo, a equipe dá ao cliente feedback 
referente ao impacto nos custos e cronograma
XP - Extreme Programming 
• CORAGEM
• Existe uma pressão significativa para elaboração do 
projeto pensando em futuros requisitos
• Equipes argumentam que ‘projetar para amanhã’ 
poupará tempo e esforço a longo prazo
• Equipe XP ágil deve ter coragem e disciplina para 
projetar para hoje
• Deve reconhecer que necessidades futuras podem 
mudar dramaticamente exigindo retrabalhos em 
relação ao projeto e código implementado
XP - Extreme Programming 
• RESPEITO
• Ao seguir os valores de comunicação, simplicidade, 
feedback e coragem a equipe inculca respeito pelos
• Membros da equipe de desenvolvimento: decisões foram 
tomadas de forma conscientes, não existem culpados
• Clientes: a comunicação e feedback estreita os laços 
entre cliente e desenvolvedor e ensina o respeito entre 
ambos
• Próprio software desenvolvido: faz bem feito o que deve 
fazer HOJE
Processo XP - Extreme Programming 
Boas Práticas da XP 
Boas Práticas da XP 
Boas Práticas da XP 
Boas Práticas da XP 
SCRUM
• Definição Informal
• Estratégia em um jogo de rugby onde jogadores colocam uma 
bola quase perdida novamente em jogo através de trabalho em 
equipe 
• Método de desenvolvimento ágil de software
• Concebido por Jeff Sutherland no início de 1990
• Princípios são consistentes com o manifesto ágil e usados para 
orientar as atividades de desenvolvimento dentro de um 
processo de construção de software
SCRUM - conceitos
• Enfatiza o uso de padrões de processos de software
• os projetos são divididos em ciclos (de 2 – 4 semanas) 
chamados de Sprints. O Sprint representa um Time Box chamados de Sprints. O Sprint representa um Time Box 
dentro do qual um conjunto de atividades deve ser 
executado
• as funcionalidades a serem implementadas em um projeto 
são mantidas em uma lista que é conhecida 
como Product Backlog
SCRUM - conceitos
• Enfatiza o uso de padrões de processos de software
• No nício de cada Sprint, faz-se um Sprint Planning 
Meeting, ou seja, uma reunião de planejamento na qual Meeting, ou seja, uma reunião de planejamento na qual 
o Product Owner prioriza os itens do Product Backlog e 
a equipe seleciona as atividades que ela será capaz de 
implementar durante o Sprint que se inicia.
• As tarefas alocadas em um Sprint são transferidas 
do Product Backlog para o Sprint Backlog.
SCRUM - conceitos
• Enfatiza o uso de padrões de processos de software
• A cadadia de um Sprint, a equipe faz uma breve reunião 
(normalmente de manhã e em pé), chamada Daily (normalmente de manhã e em pé), chamada Daily 
Scrum. O objetivo é disseminar conhecimento sobre o 
que foi feito no dia anterior, identificar impedimentos e 
priorizar o trabalho do dia que se inicia.
SCRUM - conceitos
• Enfatiza o uso de padrões de processos de software
• Ao final de um Sprint, a equipe apresenta as 
funcionalidades implementadas em uma Sprint Review funcionalidades implementadas em uma Sprint Review 
Meeting. Finalmente, faz-se uma Sprint Retrospective e 
a equipe parte para o planejamento do próximo Sprint. 
Assim reinicia-se o ciclo.
SCRUM
DMA: Desenvolver um modelo abrangente
CLF: Construir lista de features
PPF: Planejar por feature
Conclusão
• Pode-se ganhar muito se considerar o que há de 
melhor nas duas visões
• Desenvolvimento tradicional• Desenvolvimento tradicional
• Desenvolvimento ágil
Leitura Recomendada
– Capítulo 2 e 3 do livro texto: Pressman, 
Roger. Engenharia de Software, 7ed. 
McGrawHill, Porto Alegre, RS, 2011.
– Capítulo 2 do livro texto: Sommerville, Ian. – Capítulo 2 do livro texto: Sommerville, Ian. 
Engenharia de Software, 9ed. Prentice Hall, 
São Paulo, SP, 2011.