engenharia-37-46

Prévia do material em texto

Engenharia de Software
Aula 04
Metodologia ágil
Objetivos Específicos
• Entender os princípios e valores da metodologia ágil e as características dos 
modelos de processos ágeis. 
Temas
Introdução
1 Desenvolvimento ágil
2 Movimento ágil
3 Scrum
4 Extreme programming
Considerações finais
Referências
Ana Cláudia Rossi
Professora
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
2
Introdução
Vamos começar a nossa aula sobre metodologias ágeis!
O objetivo desta aula é conhecer o movimento ágil, sua filosofia e os principais processos 
adotados por equipes de desenvolvimento de software. Vamos observar as diferenças entre 
eles e a quebra de paradigma que temos em relação aos processos prescritivos, como o 
Modelo Cascata e o evolucionário.
Portanto, ao terminar esta aula, você deverá ser capaz de:
• compreender os conceitos que envolvem o desenvolvimento ágil;
• conhecer os principais métodos ágeis;
• compreender as diferenças entre os modelos de processo do movimento ágil e os 
modelos de processo prescritivos;
• conhecer com mais detalhes dois modelos de processo do movimento ágil, que são: 
SCRUM e XP (Extreme Programming).
Vamos começar conhecendo o manifesto ágil e o que impulsionou esse movimento.
1 Desenvolvimento ágil
No cenário atual, as empresas operam em um ambiente globalizado e muito suscetível 
a mudanças. Como sabemos, o software é parte importante deste ambiente e também é 
impactado por mudanças que vão desde a economia mundial até questões operacionais da 
empresa, em que se fazem necessários ajustes rápidos para garantir a competitividade no 
setor de atuação.
Sendo assim, considere o tempo necessário para executar todas as etapas de um 
processo de software. Neste tempo, contado desde a elicitação de requisitos até a entrega 
do produto, mudanças no ambiente podem ocorrer e gerar alterações nos requisitos 
inicialmente desenhados.
Portanto, um processo de software que planeja especificar completamente todos os 
requisitos para depois implementar e testar o sistema, não está adaptado para o cenário 
atual que descrevemos anteriormente.
Necessitamos de processos de desenvolvimento rápido, concebidos para lidar com as 
mudanças enfrentadas pelas empresas da atualidade. Sommerville (2011) indica que essas 
questões já eram conhecidas e estudadas na década de 1980, quando a IBM introduziu o 
desenvolvimento incremental. Nessa linha, as ferramentas de quarta geração também foram 
introduzidas, objetivando entregas mais rápidas.
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
3
Sendo assim, para o ciclo de vida de um produto de software, podemos criar um 
processo de software específico, mais adequado para o escopo delineado e as características 
do produto que iremos desenvolver.
Por esse motivo, a engenharia de trabalha em constante empirismo, ou seja, 
experimentando novas formas de produção mais eficientes, em menor tempo, com menor 
custo e com mais qualidade. Fazer mais com menos poderia ser uma diretiva dessa área.
Mas a ideia decolou de fato no final da década de 1990, com o desenvolvimento das 
abordagens ágeis, que são:
• Desenvolvimento de Sistemas Dinâmicos (DSDM) (STAPLETON, 1997);
• Scrum (SHWABER; BEEDLE, 2001);
• Extreme Programming (BECK, 1999).
Os processos ágeis de desenvolvimento, também conhecidos como métodos ágeis, 
foram concebidos para produzir softwares úteis rapidamente. Partindo do princípio de 
que um software pode ser desenvolvido por partes, podemos então planejar uma série 
de incrementos de software (partes), cada uma atendendo uma ou mais funcionalidades 
do sistema.
Nesse raciocínio, a produção de cada incremento poderia ser submetida a um processo 
de software previamente desenhado. Se trabalharmos nesse modo de produção, as chances 
de gerar um produto desatualizado, ou não compatível com as necessidades da empresa, 
serão menores, pois, além de distribuir a atividade de especificação ao longo do projeto, a 
cada incremento, teremos uma visão mais madura do produto que estamos criando.
Podemos observar na Figura 1 que no desenvolvimento convencional, a especificação 
inicia-se somente após o fim da fase de engenharia de requisitos. O mesmo ocorre para a 
fase de projeto e implementação. Se há mudanças de requisitos o processo reinicia-se. No 
caso do desenvolvimento ágil, existe uma interação direta entre a engenharia de requisitos e 
a fase de projeto e implementação, ou seja, a especificação ocorre dentro da fase de projeto 
e implementação, a cada novo incremento de software. 
Figura 1 – Especificações no desenvolvimento convencional e desenvolvimento ágil
Fonte: Adaptada de Sommerville (2011, p. 43).
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
4
2 Movimento ágil
Em 2001, um grupo de simpatizantes do desenvolvimento ágil se reuniu para escrever o 
que ficou conhecido como manifesto ágil, que consiste em uma declaração de valores comuns 
aos processos de software denominados ágeis. O Manifesto Ágil (2001) declara que:
Estamos descobrindo melhores maneiras de desenvolver softwares, fazendo-o e 
ajudando outros a fazê-lo. Através deste trabalho valorizamos mais:
• indivíduos e interações do que processos e ferramentas; 
• software em funcionamento do que documentação abrangente; 
• colaboração com o cliente do que negociação de contratos; 
• responder às mudanças do que seguir um plano.”
Esses princípios resultam de anos de experiência em desenvolvimento de software, 
observando problemas e experimentando alternativas ao desenvolvimento tradicional. 
2.1 Indivíduos e interações
O primeiro item diz respeito aos indivíduos e às interações. Estamos falando das 
equipes de software que devem ser mais colaborativas entre si, trocando experiências e 
compartilhando lições aprendidas a cada novo projeto.
Na prática, o cliente está preocupado com a compra de um software que funcione 
e atenda às suas necessidades. O processo de software pode vir a ser desgastante e não 
alcançar o sucesso esperado. Por esse motivo, engenheiros de software preocuparam-se em 
criar princípios que pudessem minimizar os problemas comuns em projetos de software.
2.2 Software em funcionamento
Com relação ao segundo valor, software funcionando com documentação extensa, 
segundo Cohn (2011) o movimento ágil foi mal interpretado como sendo contra a 
documentação. Ainda segundo o autor, deve existir um equilíbrio entre o que é documentado 
e o que não é documentado, mas registrado em código-fonte e testes automatizados 
(COHN, 2011). 
Assim, podemos perceber que ninguém está dizendo: “não faça documentação”, como 
muitos pregam no movimento ágil. Apenas estabelecemos graus de importância para as 
coisas. Documentação é importante e deve ser feita. Porém, o cliente espera um software. 
Esse é o produto mais importante. 
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
5
Existem situações em que 40% do tempo de projeto é destinado somente 
para documentação e reduz-se o tempo de teste para atingir esta meta. Será 
que esse é o melhor cenário para produzir software?
2.3 Colaboração com o cliente
O terceiro princípio diz respeito à participação do cliente de um modo mais próximo do 
desenvolvimento. O cliente colabora mais com a equipe de desenvolvimento em um contexto 
em que as entregas são realizadas em um espaço de tempo menor, com uma versão de software 
que agrega valor ao cliente e, assim, permitindo que ele realize um feedback contínuo e 
frequente. Desta forma, os feedbacks podem gerar mudanças na versão do software e, como 
consequência, a equipe de desenvolvimento deve responder a essas mudanças. 
Podemos perceber que os contratos formalizam as relações entre cliente e desenvolvedor, 
entretanto, o grande objetivo é entregar valor ao cliente, independentemente do que está 
descrito e registrado em um contrato assinado. Desta forma, quando uma rotina não está de 
acordo com as especificações, ou quando percebemos quedeterminada funcionalidade foi 
especificada de forma errada, as correções são acionadas e processadas de modo 
mais rápido.
Sabemos que o custo de correção de algum item no projeto de software 
aumenta sobremaneira na medida em que as fases do projeto avançam. Por 
esse motivo, o quanto antes o erro for detectado, mais em conta será o custo 
da correção. 
2.4 Responder a mudanças
O quarto princípio fala de mudanças. Este ponto remete ao que escrevemos no início 
desta aula. Estar suscetível a mudanças, porém seguindo o plano maior que é a entrega do 
produto funcionando e com qualidade. Para isso, gerenciar mudanças em desenvolvimento 
de software é fundamental. Tudo que mudamos tem impacto no tempo e no custo. A famosa 
frase “isso é fácil, deixa que eu resolvo” não adere às boas práticas de engenharia de software. 
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
6
Tudo deve ser ponderado antes de tomar a decisão. Contudo, isso não quer dizer: “melhor 
não mudar”.
Lembre-se sempre de que o cliente precisa de um produto que atenda às suas 
necessidades. Se uma mudança solicitada não for atendida, provavelmente, o produto final 
poderá não atender às necessidades.
Geralmente produtos de software representam um modelo computacional de um 
processo que era manual e foi modificado com melhorias e benefícios da computação. 
Entender esses processos e criar produtos de qualidade está entre os nossos desafios. 
Participaram do manifesto importantes personalidades da área de 
engenharia de software, como Kent Beck, Mike Beedle, Arie van Bennekum, 
Alistair Cockburn, Ward Cunningham, Jon Kern, Martin Fowler, James Grenning, 
Jim Highsmith, Andrew Hunt, Ron Jeffries, Ken Schwaber, Brian Marick, Robert 
C. Martin, Steve Mellor, Dave Thomas e Jeff Sutherland. A maioria deles tem 
livros, artigos e materiais disponíveis na web. Vale a pena pesquisar e estudar 
mais sobre o assunto. 
E, para saber mais sobre o manifesto ágil, acesse a Midiateca. 
3 Scrum
Schwaber e Sutherland (2013) definem Scrum como um framework em que as pessoas 
podem tratar e resolver problemas complexos e adaptativos, enquanto entregam de forma 
produtiva e criativa, produtos com mais valor. 
O Scrum não é um processo ou uma técnica, é um framework, ou seja, um conjunto de 
conceitos que são aplicados para resolver um problema de domínio específico. No caso, o 
problema do processo de software. A ideia básica é compor uma equipe, chamada de equipe 
Scrum, que terá papéis específicos, eventos e artefatos (documentos, ou qualquer coisa 
produzida durante o processo) e regras.
Nesse framework, os papéis específicos são:
• Equipe de Desenvolvimento – É um grupo de pessoas auto-organizável e 
multifuncional. Você não vai encontrar pessoas com papéis específicos, como 
desenvolvedor ou tester, todos trabalham multifuncionalmente. Segundo Cohn 
(2011) o tamanho de equipe ideal é de três a nove integrantes.
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
7
• Product Owner – Também denominado de dono do produto, sua responsabilidade 
é garantir que se dedique ao objetivo correto, para isso, ele redige os requisitos e 
define as prioridades (COHN, 2011). Ele gerencia o backlog do produto, que é uma 
lista de tarefas que, quando finalizada, encerra o produto.
• Scrum Master – É o responsável por garantir que o framework Scrum seja entendido 
e aplicado pela equipe Scrum e, também, atua como um facilitador para remover 
impedimentos ao progresso da equipe durante as construções de uma versão do 
software (COHN, 2011). 
Além dos papéis, temos os eventos Scrum. A Figura 2 resume o sequenciamento 
desses eventos.
Figura 2 – Fluxo do processo Scrum
Fonte: Pressman (2011, p. 96).
O backlog do produto (ou product backlog) é um artefato Scrum. Representa uma lista 
ordenada de tudo que deve ser feito no produto. Essa lista é gerenciada pelo product owner. 
Dessa lista, selecionam-se os itens que serão entregues em um incremento de software. Os 
incrementos de software são desenvolvidos em sprints.
Um sprint pode durar de duas a quatro semanas. Isso é dimensionado pela equipe 
Scrum. Durante um sprint, existem ritos que devem ser seguidos para manter o framework 
em funcionamento. São exemplos, reuniões diárias, uso do gráfico burndown, burnup ou 
similares, monitoramento do sprint e outros. 
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
8
4 Extreme programming
Mais conhecido por XP, é talvez o método ágil mais utilizado. O termo XP foi cunhado 
por Beck em 2000 e se baseou em uma coletânea de práticas reconhecidamente boas, como 
o desenvolvimento iterativo (por meio de iterações ou fases), ou a programação em pares. 
Esse conjunto de práticas foi resumido em Sommerville (2011) e reproduzido no Quadro 1:
Quadro 1 – Princípios do extreme programming
Princípio ou prática Descrição
Planejamento incremental
Requisitos são gravados em cartões de história e as histórias 
incluídas em um release são determinadas pelo tempo disponível 
e prioridade. Os desenvolvedores dividem as histórias em tarefas.
Pequenos releases
Inicia-se pelo desenvolvimento de um conjunto mínimo de 
funcionalidades úteis, que fornecem valor ao negócio. Os 
próximos releases vão gradualmente adicionando novas 
funcionalidades ao primeiro release.
Projeto simples Cada projeto é executado para atender às necessidades atuais.
Desenvolvimento baseado 
em testes
Utiliza-se um framework inicial de testes automatizados para 
escrever os testes de uma nova funcionalidade, antes que a 
funcionalidade seja implementada.
Refatoração Todos os desenvolvedores devem refatorar continuamente para 
manter o código simples e de fácil manutenção.
Programação em pares Os desenvolvedores trabalham em pares, verificando o trabalho 
do outro e prestando apoio para um bom trabalho.
Propriedade coletiva
Os desenvolvedores trabalham em todas as áreas do sistema 
de modo a não desenvolver ilhas de expertise. Todos os 
desenvolvedores assumem a responsabilidade por todo o código.
Integração contínua
Assim que o trabalho em uma tarefa é concluído, ele é integrado 
ao sistema como um todo. Após a integração, os testes unitários 
são repetidos.
Ritmo sustentável Grandes quantidades de horas-extras não são aceitáveis, pois 
geram muitas vezes um trabalho de baixa qualidade.
Cliente no local É necessário um representante usuário final disponível a todo o 
tempo para a equipe XP. O cliente é membro da equipe. 
Fonte: Adaptado de Sommerville (2011, p. 45).
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
9
O XP apresenta uma abordagem extrema para o desenvolvimento incremental. Novas 
versões do software podem ser disponibilizadas no mesmo dia e um release é entregue ao 
cliente em períodos curtos de tempo.
Prazos não são desrespeitados. Se houver problemas na entrega do release, o cliente é 
consultado e a funcionalidade problemática pode ser retirada do release.
Aspectos como a programação em pares ou a refatoração podem ser polêmicos para 
alguns profissionais de engenharia de software, pois existem controvérsias sobre a 
produtividade quando se utilizam essas práticas. Segundo Sommerville (2011) foram 
realizados estudos sobre produtividade de programadores para avaliar a eficiência 
dessa prática.
No estudo realizado por Cockburn e Williams (2001) apud Sommerville 
(2011), usando estudantes voluntários, a conclusão do estudo foi que a 
produtividade na programação em pares foi comparável a duas pessoas que 
trabalham de forma independente. Entretanto, na pesquisa realizada por 
Arisholm et al (2007) apud Sommerville (2011) e Parrish et al (2004) apud 
Sommerville (2011), como programadores experientes, não foi possível replicar 
o resultado, e sim, perceberam uma perda significativa de produtividade em 
comparação com dois programadores trabalhando sozinhos. Ainda segundo os 
autores, apesar do benefício na qualidade, não havia compensação na perda 
de produtividade.Entretanto, os entusiastas do XP garantem que a programação em pares permite 
agilidade, porque muitas vezes o desenvolvedor demora muito tempo para encontrar uma 
solução de código e, quando se trabalha em pares, duas cabeças pensam melhor do que uma. 
Já a refatoração é uma prática interessante, pois quando você revê um código, pode pensar 
em estratégias mais simples para resolver o mesmo problema, além de fazer uso de padrões 
de refatoração para melhorar um código-fonte, como os propostos por Fowler (2004).
Considerações finais
Como vimos, o movimento ágil trouxe novas abordagens para o desenvolvimento de 
software, de modo a propiciar desenvolvimento mais rápido e de qualidade.
Vimos dois métodos que atualmente são expoentes no mercado de desenvolvimento 
de software: Scrum e XP. Contudo, existem outros métodos que podem ser consultados para 
estudos mais aprofundados como: 
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
10
• Feature Driven Development;
• Crystal Clear;
• Adaptive Software Development.
Ou ainda, existem experiências que misturam partes de um ou outro método ágil, 
propondo métodos híbridos. Também vamos encontrar nessa área práticas da indústria 
de manufatura que foram inseridas no contexto do desenvolvimento de software, como o 
Kanban e o Lean. 
Portanto, este é um tema muito envolvente e apresenta diversas possibilidades de 
investigação para os interessados no assunto. O mercado vem gradativamente se inserindo 
nessas práticas, sempre na expectativa de buscar melhores métodos para desenvolver 
softwares no prazo, sem ultrapassar o orçamento e com qualidade. 
Referências
BECK, K. Embracing Change with Extreme Programming. IEEE Computer, v. 32. N. 10, 1999. P. 
70-78.
COHN, M. Desenvolvimento de software com Scrum: aplicando métodos ágeis com sucesso. 
Porto Alegre: Editora Bookman, 2011.
FOWLER, M. Refatoração: aperfeiçoando projeto de código existente. Porto Alegre: Editora 
Bookman, 2004.
MANIFESTO ÁGIL. Disponível em: . Acesso em: 06 dez. 2014.
PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. Porto Alegre: Mcgraw 
Hill - Artmed, 2011.
SCHAWABER, K.; SUTHERLAND, J. The Scrum Guide. Disponível em: . Acesso em: 06 dez. 2014.
SCHAWABER, K.; BEEDLE, M. Agile software development with Scrum. Englewood Cliffs, N. J.: 
Prentice Hall, 2001.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson, 2011.
STAPLETON, J. DSDM: Dynamic system development method. Harlow, Reino Unido: Addison 
- Wesley, 1997.
	ENG_SOFT_04_PDF_2014