Aula_0015-Desenvolvimento-Ágil

Prévia do material em texto

DESENVOLVIMENTO ÁGIL 
Francisco Paulo de Freitas Neto 
paulo.freitas@ifrn.edu.br 
Apodi, RN 
SUMÁRIO 
• INTRODUÇÃO 
 
• PROCESSOS ÁGEIS 
 
• PRINCÍPIOS DA AGILIDADE 
 
• EXTREME PROGRAMMING (XP) 
– EXEMPLO PRÁTICO 
 
• SCRUM 
SUMÁRIO 
• INTRODUÇÃO 
 
• PROCESSOS ÁGEIS 
 
• PRINCÍPIOS DA AGILIDADE 
 
• EXTREME PROGRAMMING (XP) 
– EXEMPLO PRÁTICO 
 
• SCRUM 
INTRODUÇÃO 
• Em 2001 o manifesto para o desenvolvimento ágil de software 
foi assinado pela “Agile Alliance”: 
 
“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 entre eles 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 
Ou seja, embora haja mais valor nos itens à direita, valorizaremos os da 
esquerda mais ainda” 
INTRODUÇÃO 
• Os métodos ágeis de desenvolvimento surgiram para minimizar 
alguns problemas encontrados na engenharia de software 
convencional. 
 
• Não são aplicáveis a todos os projetos, produtos, pessoas e 
situações; 
 
• Atualmente é impossível prever como uma aplicação irá evoluir 
com o tempo, assim, é preciso ser ágil para dar uma resposta 
rápida a essas mudanças. 
SUMÁRIO 
• INTRODUÇÃO 
 
• PROCESSOS ÁGEIS 
 
• PRINCÍPIOS DA AGILIDADE 
 
• EXTREME PROGRAMMING (XP) 
– EXEMPLO PRÁTICO 
 
• SCRUM 
O QUE É AGILIDADE? 
• Segundo Ivan Jacobson: 
– “Uma equipe ágil é aquela rápida e capaz de responder apropriadamente 
a mudanças. [...] Uma equipe ágil reconhece que o software é 
desenvolvido por indivíduos trabalhando em equipes e que as 
habilidades dessas pessoas, estão no cerne do sucesso do projeto”; 
 
• Mas a agilidade não está somente ligada a resposta à 
mudanças, ela: 
– Incentiva a estruturação e as atitudes em equipes; 
– Enfatiza a entrega rápida do software operacional; 
– Assume que o cliente faz parte da equipe; 
– Reconhece que o planejamento pode ser flexível. 
CUSTO DAS MUDANÇAS 
O QUE É PROCESSO ÁGIL? 
• Se baseia nos preceitos-chave: 
– É difícil afirmar antecipadamente quais requisitos de software irão 
persistir e quais sofrerão alterações; 
– Para muitos, projeto e construção devem ser realizadas em sequência; 
– Análise, projeto, construção e testes não são previsíveis. 
 
• Como então criar um processo capaz de administrar a 
imprevisibilidade? 
– Projetos adaptáveis 
 
• Os processo ágeis devem adaptar-se incrementalmente, para 
isso, precisa de um feedback do cliente. 
SUMÁRIO 
• INTRODUÇÃO 
 
• PROCESSOS ÁGEIS 
 
• PRINCÍPIOS DA AGILIDADE 
 
• EXTREME PROGRAMMING (XP) 
– EXEMPLO PRÁTICO 
 
• SCRUM 
PRINCÍPIOS DA AGILIDADE 
• Existem 12 princípios da agilidade: 
– Satisfazer o cliente pela entrega adiantada e contínua de software valioso; 
– Acolha pedidos de alterações, mesmo que atrasados; 
– Entregue software em funcionamento frequentemente; 
– O pessoal comercial e desenvolvedores devem trabalhar em conjunto; 
– Construa projetos em torno de indivíduos motivados; 
– O método mais eficiente de transmitir informações é uma conversa 
aberta, presencial; 
– Software em funcionamento é a principal medida de progresso; 
– Promovem o desenvolvimento sustentável; 
– Atenção contínua para a excelência técnica; 
– Simplicidade é essencial; 
– Auto-organização da equipe; 
– Auto avaliação. 
SUMÁRIO 
• INTRODUÇÃO 
 
• PROCESSOS ÁGEIS 
 
• PRINCÍPIOS DA AGILIDADE 
 
• EXTREME PROGRAMMING (XP) 
– EXEMPLO PRÁTICO 
 
• SCRUM 
VALORES DO XP 
• Beck define cinco valores base do XP: 
– Comunicação 
– Simplicidade 
– Feedback 
– Coragem 
– Respeito 
VALORES DO XP 
COMUNICAÇÃO 
 
• A XP enfatiza: 
– Colaboração estreita, embora 
informal (verbal) entre clientes, 
desenvolvedores; 
– Estabelecimento de metáforas 
eficazes para comunicar conceitos 
importantes; 
– Feedback contínuo; 
– Evitar documentação volumosa 
como meio de comunicação. 
VALORES DO XP 
SIMPLICIDADE 
 
• A XP restringe os 
desenvolvedores a projetar 
apenas para as necessidades 
imediatas; 
 
• Almeja-se criar um projeto 
simples que possa ser 
implementado em código; 
 
• Para ser melhorado, o produto 
é refabricado. 
VALORES DO XP 
FEEDBACK 
 
• O retorno pode vir: 
– Do próprio software, através dos 
resultados dos testes. São 
realizados testes de unidade; 
– Do cliente, quando o mesmo 
recebe o incremento, as histórias 
do usuário são usadas para 
validar; 
– Da equipe, nas reuniões podem 
também avaliar impactos nos 
custos e cronograma. 
VALORES DO XP 
CORAGEM 
 
• Pode ser compreendido como 
disciplina; 
 
• Muitas equipes falham ao 
tentar projetar para amanhã. 
No XP, deve-se ter disciplina 
(coragem) para projetar para 
HOJE. 
VALORES DO XP 
RESPEITO 
 
• Entre os membros da equipe; 
 
• Entre outros envolvidos e os 
membros da equipe; 
 
• Para o próprio software, pois 
quando os incrementos são 
entregues com sucesso, há 
mais respeito pelo XP. 
 
PROCESSO XP 
• Emprega uma abordagem orientada a objetos como paradigma 
de desenvolvimento; 
• Baseia-se em quatro atividades metodológicas: 
 
 
PROCESSO XP 
PLANEJAMENTO 
 
• Inicia-se com a atividade de 
ouvir que leva ao entendimento 
do ambiente de negócio do 
software; 
 
• O “ouvir” conduz à criação de 
histórias, que descrevem 
características, resultados e 
funcionalidades requeridas do 
software; 
PROCESSO XP 
PLANEJAMENTO 
 
• As histórias são alocadas em 
fichas e o cliente atribui um 
valor (prioridade); 
 
• Os membros da equipe 
estimam um custo em semanas; 
 
• Se o tempo estimado para uma 
história for maior que 3 
semanas, o cliente deve dividi-
la em menores. 
PROCESSO XP 
PLANEJAMENTO 
 
• É necessária a participação do 
cliente nesse ponto, pois junto 
com ele será decidido: 
– Quais histórias serão incluídas em 
cada versão; 
– Data de entrega; 
– Outras questões de projeto. 
 
• O cliente pode acrescentar, 
modificar valores, dividir ou 
acrescentar histórias. 
PROCESSO XP 
PROJETO 
 
• Segue rigorosamente o KIS 
(Keep it simple); 
 
• É sempre melhor um projeto 
simples que uma representação 
mais complexa; 
 
• O projeto de funcionalidades 
extra é desencorajado; 
PROCESSO XP 
PROJETO 
 
• O uso de cartões CRC (Classe-
Responsabilidade-Colaborador) 
é encorajado; 
 
• Esses cartões identificam e 
organizam classes orientadas a 
objetos; 
 
• Os cartões CRC são os únicos 
artefato de projeto. 
PROCESSO XP 
PROJETO 
 
• CRC (Classe -Responsabilidade 
-Colaboração), esses cartões 
mostram: 
– Nome da classe e descrição; 
– Responsabilidade: 
conhecimento interno 
(atributos) e serviços (métodos); 
– Colaboradores das 
responsabilidades (outras 
classes cujos serviços são 
necessitados por uma 
responsabilidade); 
PROCESSO XP 
PROJETO 
 
• Se um problema difícil for 
encontrado, é recomendado 
criar um protótipo dessa parte 
imediatamente chamada de 
solução pontual. 
 
 
PROCESSO XP 
CODIFICAÇÃO 
 
• Antes da codificação há o 
desenvolvimento de casos de 
teste de unidade para cada uma 
das histórias; 
 
• Desse modo, ele foca no que 
deve ser implementado para ser 
testado. 
PROCESSO XP 
CODIFICAÇÃO 
 
• Um conceito do XP para a 
codificação é a programação em 
dupla;• Dois programadores em um 
mesmo computador, 
fornecendo um mecanismo 
para resolução de problemas 
em tempo real. 
PROCESSO XP 
TESTES 
 
• Os testes de unidade devem ser 
criados antes de começar a 
codificação; 
 
• Os testes de integração podem 
ser realizados diariamente; 
 
• Os testes de aceitação são feitos 
a partir das histórias do usuário 
implementados como parte de 
uma versão de software. 
O DEBATE XP 
• Existem muitos questionamentos sobre o XP; 
 
• O XP é um tema muito controverso. 
 
• Algumas questões ainda são levantadas sobre o XP: 
– Volatilidade de requisitos; 
– Necessidades conflitantes; 
– Requisitos levantados informalmente; 
– Falta de projeto formal 
SUMÁRIO 
• INTRODUÇÃO 
 
• PROCESSOS ÁGEIS 
 
• PRINCÍPIOS DA AGILIDADE 
 
• EXTREME PROGRAMMING (XP) 
– EXEMPLO PRÁTICO 
 
• SCRUM 
EXEMPLO PRÁTICO 
• Baseado no site: https://code.google.com/p/extreme-programming-
mds/wiki/UserStories 
 
• Inicialmente temos as Histórias do usuário, que vem do inglês 
(User Stories), trata-se de uma breve descrição de uma 
funcionalidade discutida; 
 
• As histórias devem ser: 
– Independentes 
– Negociáveis 
– Estimáveis 
– Pequenas 
– Testáveis 
EXEMPLO PRÁTICO 
CARACTERÍSTICAS: INDEPENDÊNCIA 
 
• COMO DEVE SER: 
– Um usuário pode entrar com o seu primeiro nome, com o seu último 
nome ou opcionalmente pode entrar com o seu nome do meio; 
 
• COMO NÃO DEVE SER: 
– Um usuário pode entrar com o seu primeiro nome; 
– Um usuário pode entrar com o seu último nome; 
– Um usuário pode, opcionalmente, entrar com o seu nome do meio. 
EXEMPLO PRÁTICO 
CARACTERÍSTICAS: NEGOCIÁVEIS 
 
• COMO DEVE SER: 
– Os dados devem persistir em um banco de dados de qualidade e 
gratuito; 
 
• COMO NÃO DEVE SER: 
– A aplicação deve ser escrita usando Ruby on Rails 
– MySQL será usada para a persistência dos dados 
EXEMPLO PRÁTICO 
CARACTERÍSTICAS: TESTÁVEL 
 
• “Um usuário deve encontrar um software fácil de usar”  “Um 
usuário iniciante deve ser capaz de realizar tarefas completas 
sem treinamento”; 
 
• Um usuário não deve esperar muito tempo para visualizar as 
telas  “Novas telas serão mostradas em 2 segundos em 95% 
dos casos”; 
EXEMPLO PRÁTICO 
EXEMPLOS DE HISTÓRIAS 
 
• Como um [ator] eu quero/preciso/devo/gostaria de/ [ação] para 
[funcionalidade] 
 
• “Como um vendedor responsável pelo setor de livros eu quero 
procurar por livros filtrando por nome para que seja possível verificar 
se o livro X está disponível para pronta entrega”; 
– Um vendedor do setor de livros pode procurar por livros filtrando por nome 
para verificar se o mesmo está disponível para pronta entrega. 
 
• “Como um cliente eu quero ver os filmes disponíveis para locação 
para que eu possa agendar uma reserva na data X”. 
– Um cliente pode visualizar os filmes disponíveis para locação para agendar 
reservas em uma data específica. 
 
 
EXEMPLO PRÁTICO 
EXEMPLO PRÁTICO 
HISTÓRIAS DE USUÁRIO 
 
• US1 – Como gerente eu quero manter o cadastro de vídeos da 
locadora para que seja possível catalogar os vídeos existentes; 
• US2 – Como gerente eu quero manter o cadastro de clientes da 
locadora para que as informações a respeito do cliente estejam 
disponíveis quando necessário; 
• US3 – Como gerente eu quero imprimir um relatório dos vídeos 
pendentes para poder lembrar os clientes da devolução dos vídeos; 
• US4 – Como cliente eu quero ter um cartão que me identifique para 
que eu possa alugar os vídeos; 
• US5 – Como funcionário eu quero manter o controle dos vídeos 
alugados para que seja possível cobrar taxas em caso da devolução 
ocorrer com atraso. 
EXEMPLO PRÁTICO 
CRITÉRIOS DE ACEITAÇÃO 
 
• É o comportamento esperado durante a utilização; 
• O teste de aceitação pode ser visto como a verificação da adequação aos 
critérios de aceitação; 
• Para definir os critérios opta-se por utilizar o desenvolvimento baseado em 
comportamento; 
• Usa-se três blocos: 
– Given: dado um contexto 
– When: quando acontecer um evento 
– Then: então se espera que aconteça algo 
 
• É interessante seguir um modelo para a equipe. 
EXEMPLO PRÁTICO 
CARTÕES CRC 
 
• US1 – Como gerente eu quero manter o cadastro de vídeos da 
locadora para que seja possível catalogar os vídeos existentes; 
• Substantivos: gerente, vídeos, locadora. 
• Verbos: manter, catalogar. 
 
Gerente 
Responsabilidades 
 
*Manter vídeos 
 
*Catalogar vídeos 
Colaboração 
 
Vídeo 
 
Locadora 
Vídeo 
Responsabilidades 
 
Manter dados dos 
vídeos 
Colaboração 
 
Locadora 
Locadora 
Responsabilidades 
 
Manter dados do 
catálogo de vídeos 
Colaboração 
 
Vídeo, gerente 
EXEMPLO PRÁTICO 
CARTÕES CRC 
 
• US2 – Como gerente eu quero manter o cadastro de clientes da 
locadora para que as informações a respeito do cliente estejam 
disponíveis quando necessário; 
• Substantivos: gerente, clientes, locadora, vídeos. 
• Verbos: Manter 
Cliente 
Responsabilidades 
 
*Descrever as 
características dos 
clientes 
Colaboração 
 
 
Locadora 
EXEMPLO PRÁTICO 
CARTÕES CRC 
 
• US3 – Como gerente eu quero imprimir um relatório dos vídeos 
pendentes para poder relembrar os clientes da data de devolução dos 
vídeos 
• Substantivos: gerente, clientes, relatório. 
• Verbos: imprimir, poder, relembrar 
Gerente 
Responsabilidades 
 
*Imprimir 
relatórios 
Colaboração 
 
Locadora, 
relatório 
Relatório 
Responsabilidades 
 
*Descrever as 
características dos 
relatórios 
Colaboração 
 
 
Gerente 
EXEMPLO PRÁTICO 
CARTÕES CRC 
 
• US4 – Como cliente eu quero ter um cartão que me identifique 
para que eu possa alugar os vídeos 
• Substantivos: cliente, cartão, vídeos. 
• Verbos: ter, identificar, alugar 
Cliente 
Responsabilidades 
 
*Alugar vídeos 
Colaboração 
 
Locadora 
Cartão 
Responsabilidades 
 
*Identificar os 
clientes 
Colaboração 
 
cliente 
EXEMPLO PRÁTICO 
CARTÕES CRC 
 
• US5 – Como funcionário eu quero manter o controle dos vídeos 
alugados para que seja possível cobrar taxas em caso da devolução 
ocorrer com atraso 
• Substantivos: funcionário, vídeos. 
• Verbos: manter, cobrar 
Funcionário 
Responsabilidades 
 
*Realizar a locação 
de vídeos 
*Realizar a 
devolução de 
vídeos 
*Cobrar taxas dos 
clientes 
 
Colaboração 
 
 
 
 
Locadora 
SUMÁRIO 
• INTRODUÇÃO 
 
• PROCESSOS ÁGEIS 
 
• PRINCÍPIOS DA AGILIDADE 
 
• EXTREME PROGRAMMING (XP) 
– EXEMPLO PRÁTICO 
 
• SCRUM 
SCRUM 
• Processo iterativo e incremental; 
 
• Foi criado como um framework em 1995 por Ken Schwaber; 
 
• O Scrum divide o projeto em ciclos de duas a quatro semanas 
chamados de sprints, e a ideia é a cada sprint ter um código que 
possa ser entregue ao cliente. 
 
 
SCRUM 
• O Scrum define o Product Backlog como uma lista de tudo que 
se deseja do software, com uma visão macro; 
– Permite o início do projeto sem ter um escopo fechado 
 
• O cliente é representado pelo Product Owner, ele possui 
responsabilidades no desenvolvimento, como: 
– Definir a lista de funcionalidades do sistema 
– Detalhar itens nos planejamentos 
– Sequenciar a entrega dos códigos 
SCRUM 
• No início de cada Sprint faz-se o Sprint Planning, uma reunião 
onde o Product Owner prioriza os itens a serem desenvolvidos 
no Sprint 
– A equipe se compromete de executar um conjunto de atividades e o 
Product Owner de não trazer mais requisitos durente o Sprint 
 
• Após definir as atividades, essas saemdo Product Backlog e vão 
para o Sprint Backlog; 
– Detalha as atividades do Sprint 
 
SCRUM 
• Diariamente são realizadas reuniões chamadas de Daily Scrum 
– São reuniões breves com o intuito de compartilhar os avanços do projeto 
– Alguns livros trazem o termo standup meeting para essas reuniões 
 
• Ao final do Sprint a equipe apresenta as funcionalidades 
implementadas em uma Sprint Review 
 
• Faz-se por fim um Sprint Retrospective como parte do 
planejamento do próximo sprint. 
SCRUM 
REFERÊNCIAS 
• PRESSMAN, Roger. S. Engenharia de software: Uma 
abordagem profissional. Porto Alegre: AMGH, 2011. 
• https://code.google.com/p/extreme-programming-
mds/wiki/UserStories 
• ENGHOLM JUNIOR, Hélio. Análise e Design Orientados 
a Objetos. São Paulo: NOVATEC, 2013. 
• http://www.desenvolvimentoagil.com.br/scrum/ 
• http://www.dsc.ufcg.edu.br/~pet/Artigos/ARTIGO_YP.p
df