3. Introdução
• Sobre os métodos tradicionais
– São baseados na produção de uma grande quantidade
de documentação
– São considerados métodos pesados
• Sobre os métodos ágeis
– São o contraponto dos métodos tradicionais, sendo
considerados métodos leves
– As pesquisas sobre eles ainda são relativamente novas
– Nem todas as práticas relacionadas aos métodos ágeis
são novas
4. Introdução
• O manifesto ágil:
– Satisfação do cliente através de entregas mais cedo e
contínuas, utilizando ciclos de iteração menores
– Aceitação e acomodação de requistos em qualquer
tempo do desenvolvimento
– Desenvolvedores e usuários trabalhando juntos
– Times motivados e em ambientes apropriados
– Minimização de documentação e maximização de troca
de informação face-a-face
– Encorajamento de atitudes reflexivas e contínuo
aprendizado
7. Scrum
• O termo Scrum é uma metáfora para uma situação
em um jogo de Rugby. Esta situação envolve um
grupo denso de pessoas, lutando pela posse da
bola.
• O Scrum não é um método completo. Não requer
que seja utilizada nenhuma prática ou técnica para
o desenvolvimento de software
• Utiliza pequenos grupos
• É um método para gerenciamento de um projeto
de software
8. Scrum
• Processos definidos X processos empíricos :
– Um processo definido usa uma base de conhecimento
sobre o processo: são descritos como reproduzíveis
– Um processo empírico envolve atividades complicadas,
não reproduzíveis e com resultados imprevisíveis
• As atividades envolvidas no desenvolvimento de
software são complexas e poucas geram resultados
repetidos
• O Scrum é baseado nos métodos utilizados nas
fábricas químicas, que utilizam muito inspeções e
ajustes.
9. Scrum
• Principais conceitos da metodologia Scrum:
– Time: máximo 7 pessoas
– Backlog do Produto
– Sprint: ciclo de desenvolvimento mensal
– Sprint Backlog
– Reunião de Planejamento do Sprint
– Reunião do Scrum diário
– Comunicação e retroalimentação
– ScrumMaster: lider responsável
– Incremento de produto potencialmente entregável:
funcionalidades implementadas, testadas e com
performance adequada
11. Feature Driven Development
(FDD)
• Baseado em modelos e guiado por características e
implementado em ciclos curtos de iterações
• Os ciclos de implementação de uma característica
são de no máximo 2 semanas
• Interessante para desenvolvedores pois estão
permanentemente recebendo novas tarefas
• Interessante para os clientes pois vêem os
resultados rapidamente
12. Feature Driven Development
(FDD)
• Busca-se focar os esforços nas
funcionalidades que sejam úteis aos olhos
dos clientes...
• Procura-se restringir a lista de
funcionalidades (características) àquelas
que os usuários podem entender
13. Feature Driven Development
(FDD)
• Uma feature ou característica é uma função com valor para
o cliente e que pode ser implementada em duas semanas ou
menos e é descrita da seguinte forma:
– <ação><artigo><resultado><preposição><artigo><objeto>
• Exemplos:
– calcular o total de uma venda
– calcular o total de compras de um cliente
• As features podem ser agrupadas. Neste caso são assim
descritas:
– <ação - verbo no particípio><artigo><objeto>
• Exemplos:
– Comprando um produto
– Efetivando um pagamento
14. Feature Driven Development
(FDD)
• Papéis no FDD:
– Papéis chaves
• Gerente de projeto, arquiteto-chefe, gerente de
desenvolvimento, programador-chefe, dono-de-classe,
especialista no negócio
– Papéis de suporte
• Gerente de liberações, gerente de configuração, administrador
de rede, especialista na ferramenta, testador, documentador
– Papéis adicionais
• outros...
15. Feature Driven Development
(FDD)
• Práticas no FDD
– Modelagem dos objetos de negócio
– Desenvolver por características
– Posse de classes de código fonte
• Cada classe tem um responsável e ele é responsável por sua
construção e manutenção
– Time de características
• Cada feature tem um responsável
– Builds regulares
– Visible Progress Report
– Inspeções
17. Extreme Programming (XP)
• XP é considerado o mais importante movimento
entre os métodos ágeis atualmente
• XP não é uma idéia totalmente terminada
• Os limites de sua aplicação ainda não estão bem
definidos
• As práticas do método não precisam ser adotadas
como um conjunto
• O principal objetivo do XP é reduzir o ciclo de
desenvolvimento de alguns anos para alguns dias
ou horas
20. Extreme Programming (XP)
• As práticas do XP:
– Jogo de planejamento
• As decisões sobre os prazos e escopo são tomadas pelos
clientes
– Pequenas liberações
• Devem ser feitas liberações o mais rápido possível para o
ambiente de produção
– Metáfora
• É definida uma metáfora para o objetivo do sistema
– Projeto simplificado
• O código deve ser sempre o mais simples possível
21. Extreme Programming (XP)
• As práticas do XP:
– Testes
• Os testes unitários são escritos pelos programadores com bastante
freqüência. Os clientes escrevem os testes de aceitação. Os resultados
dos testes são publicados e ficam visíveis para todos da equipe
– Redesenho
• O código vai sendo melhorado aos poucos
– Programação em pares
• Todo o código é escrito por um par de programadores
– Integração contínua
• Novas classes e métodos são integrados imediatamente
– Propriedade coletiva do código
• Qualquer programador, a qualquer momento, pode alterar qualquer
porção do código fonte
22. Extreme Programming (XP)
• As práticas do XP:
– Cliente disponível
• O cliente ou usuário fica integralmente disponível para a
equipe
– Semana de 40 horas
• Se houver necessidade de trabalho extra, é sinal que há
problemas
– Ambiente aberto
• O time trabalha em um ambiente bastante espaçoso. O grupo
de programação trabalha em estações de trabalho localizadas
no centro do ambiente
– Somente regras
• As regras podem ser adaptadas e melhoradas, de acordo com a
necessidade.
23. Extreme Programming (XP)
• Processo proposto pelo XP:
– Ele se inicia com o cliente escolhendo as funcionalidades que serão
implementadas. Estas funcionalidades são chamadas de estórias do
usuário (user stories). A escolha leva em conta a estimativa de
custo/tempo feita pelos programadores
– O desenvolvimento é fortemente guiado a testes (TDD: Test-
Driven Development). Os programadores escrevem testes
unitários, que são classes que automatizam sequências de testes
sobre outras classes. São escritos antes do código estar completo
– Normalmente no par de programadores procura-se unir um com
muita experiência em TDD e outro com pouca ou nenhuma
experiência nesta técnica.
25. Extreme Programming (XP)
• Estórias dos usuários:
– Uma estória do usuário é uma unidade funcional
– Ela deve ser entendida pelos clientes e usuários, deve ser testável,
deve ter valor para o cliente e deve ser pequena o bastante para que
os programadores possam construir dúzias delas em um ciclo de
iteração
– Ela é formada por uma ou duas sentenças que descrevem algo com
valor para o cliente:
• O sistema deve verificar se o CPF do cliente é um número válido...
– Os programadores deverão ser capazes de estimar o custo/tempo
para implementar a estória. Caso isto não seja possível, a estória
deve ser subdividida em estórias menores, para que possam ser
então estimadas
– As estórias do usuários devem ser criadas pelos clientes e usuários.
Os desenvolvedores concentram-se nas decisões técnicas
26. Extreme Programming (XP)
• Estórias dos usuários:
– O principal critério de ordenamento das estórias é o
valor para o negócio
– Não existe consenso nisto
– O consenso é negociado quando houver problemas de
priorização.
27. Exemplo de estória
Everest 1 10
Cadastro de usuário
01 08 2005
Acessando-se o menu principal, administradores do sistema
têm privilégio de acesso ao módulo de cadastro de usuário. Marcos
02 08 2005
O módulo consiste num formulário simples que permite o cadas-
tramento de informações como: nome, sobrenome, endereço,
Marcio
e-mail, telefone, estado e cidade.
2
Após o cadastramento, é exibida uma página com a listagem
04 08 2005
de usuários.
Juliano
O evento de cadastramento é registrado em log de atividades.
05 08 2005
1,5
28. Extreme Programming (XP)
• Reportando o progresso de um projeto XP:
– O progresso de cada iteração é medido e
reportado por uma pessoa chamada tracker
– A cada programador, o tracker faz duas
perguntas básicas:
• Quantos dias você já trabalhou nesta tarefa?
• Mais quantos dias você precisa para completar a
tarefa?
29. Extreme Programming (XP)
• Reportanto o progresso de um projeto XP:
– Se o tracker descobre que um programador não vai
conseguir terminar sua tarefa, ele tenta redistribuir o
encargo para outro programador que esteja com alguma
folga. Caso isto não seja possível, o cliente deve ser
informado
– As iterações no XP terminam na data estimada. As
estórias implementadas, são apresentadas aos clientes,
que decidirá se está adequada, a qual, neste caso, será
considerada completa. As estórias incompletas serão
consideradas para a próxima iteração
30. Considerações finais
• Outros Métodos Ágeis
– ASD (Adaptive Software Development)
• Mission-driven, component-driven (results), time-limited,
timeboxed; risk driven; change tolerant
– Crystal Clear
• Strong communications; frequent deliveries; reduce overhead;
management by milestones and risk lists
– DSDM (Dynamic Systems Development Model)
• User involvement, stakeholder collaboration; empowered
team; frequent delivery; backtracking to reverse changes; high-
level requirements baselining; iterative and incremental
development; integrated lifecycle testing;
31. Considerações finais
ABORDAGEM TRADICIONAL ABORDAGEM ÁGIL
Preditiva: detalhar o que ainda não é Adaptativa: conhecer o problema e
bem conhecida resolver o crítico primeiro
Rígida: seguir especificação Flexível: adaptar-se a requisitos
predefinida a qualquer custo atuais, que podem mudar
Burocrática:controlar sempre, para Simplista: fazer algo simples de
alcançar objetivo planejado imediato, e alterar no futuro se for
necessário
Orientado a processos: seguí-los
possibilita garantir a qualidade Orientado a pessoas: motivadas,
comprometidas e produtivas
Documentação: é a garantia de
confiança Comunicação: é a garantia de
confiança
Sucesso: é entregar o planejado
Sucesso: é entregar o desejado
Gerência: sinônimo de “comando-
controle”, voltada para o trabalho em Gerência: sinônimo de “liderança-
massa com ênfase no papel do orientação”, voltada para o trabalho
gerente, com planejamento e do conhecimento, com ênfase na
disciplina fortes criatividade, flexibilidade e atenção às
pessoas
32. Comparação das metodologias
METODOLOGIA DIRIGIDA A PRIORIZA
Engenharia da Construção do
Informação
Informação Banco de Dados
Construção de
Análise Estruturada Procedimentos
sistemas
Análise Orientada a Construção de
Objetos
Objeto Componentes
Implementação Funções com valor
Métodos Ágeis
contínua de funções para o cliente
