Centro Universitário de Lins - Unilins

 Modelo Ágil
 de
 Desenvolvimento de
Software
 LOURENÇO MARCOS & JOSÉ ALEXANDRE

 Estudantes do Curso de Tecnologia em Análise e

Desenvolvimento de Software
 UNILINS

 18/03/2010

18/03/2010 José Alexandre & 1

Lourenço Marcos
 Sumário
 Introdução
 Premissas Básicas do Modelo Tradicional
e suas conseqüências
 Conceito de metodologia Ágil
 Como avaliar projetos Doentes
 Metodologias Ágeis.
– XP ,
– SCRUM
 Resumo
18/03/2010 José Alexandre & 2
Lourenço Marcos
Premissas Básicas do Modelo Tradicional
É necessário fazer uma análise de requisitos profunda e detalhada antes
de projetar a arquitetura do sistema.

É necessário fazer um estudo minucioso e elaborar uma descrição

detalhada da arquitetura antes de começar a implementá-la.

É necessário testar o sistema completamente antes de mandar a versão

final para o cliente.

18/03/2010 José Alexandre & 3

Lourenço Marcos
 O cenário vivido por muitos

Algumas empresas adotam metodologias de

desenvolvimento e práticas extremamente formais
e controladoras, porém ainda não conseguem
obter qualidade.
Por quê?
Pouca preocupação com as pessoas e a interação entre elas
Pouca comunicação com o cliente
Custos muito altos
Excesso de formalismo

Qual a consequência disso?

Alta rotatividade
No fim o software não serve mais
Projeto cancelado
Prazos estourados
18/03/2010 José Alexandre & 4
Lourenço Marcos
 Além disso .....

muitas empresas vivem em uma situação de total descontrole e

falta de qualidade, e não são nada ágeis, vivem o ...

18/03/2010 José Alexandre & 5

Lourenço Marcos
 Estatísticas de projetos indicam que:

•31% são cancelados antes de ser complemente

entregues;
•53% custam quase o dobro (189%) do esperado;
•Apenas 16% são completados no prazo estimado;

Fonte: Chaos Report

http://net.educause.edu/ir/library/pdf/NCP08083B.pdf

... CAOS

Mas esse problema não é novo,

É assim, que Fevereiro 2001, em Utah
17 caras lançaram o ...

6
18/03/2010 José Alexandre &
Lourenço Marcos
 O Manifesto Ágil

 O que é isso?
– Um manifesto que criticava alguns mitos/práticas da
engenharia de software e da gerência de projetos
adotadas por abordagens tradicionalistas
– Foi assinado por 17 pessoas envolvidas com
desenvolvimento de software, dentre eles consultores e
programadores experientes

Kent Beck James Grenning Robert C. Martin

Mike Beedle Jim Highsmith Steve Mellor
Arie van Bennekum Andrew Hunt Ken Schwaber
Alistair Cockburn Ron Jeffries Jeff Sutherland
Ward Cunningham Jon Kern Dave Thomas
Martin Fowler Brian Marick

18/03/2010 José Alexandre & 7

Lourenço Marcos
 O que é Agilidade?
 a.gi.li.da.de sf (lat agilitate)
1. Qualidade do que é ágil.
2. Desembaraço, ligeireza, presteza de movimentos.
3. Mobilidade, perspicácia, vivacidade.
 Geralmente associa-se Agilidade com:
– Rapidez, Flexibilidade, Leveza
– Resumo: Habilidade para mudar

18/03/2010 José Alexandre & Lourenço Marcos

8
 Agilidade e a Engenharia de Software

 Engenharia de software ágil combina a filosofia e um

conjunto de diretrizes de desenvolvimento. A filosofia
encoraja a satisfação de cliente e a entrega incremental de
software logo de inicio; isso envolve equipes pequena ,
altamente motivada;métodos informais; produto de
engenharia de software mínimo e simplicidade global do
desenvolvimento.
 As diretrizes enfatizam a entrega em contraposição a
analise e ao projeto e a comunicação ativa e continua
entre os desenvolvedores e clientes;

18/03/2010 José Alexandre & 9

Lourenço Marcos
 O que diz o Manifesto?

“Estamos descobrindo melhores maneiras de desenvolver software,

fazendo software e ajudando outros a fazê-lo.
Através deste trabalho passamos a valorizar:

Indivíduos e interações mais que processos e ferramentas.

Software que funciona mais que documentação detalhada.
Colaboração do cliente mais que negociações contratuais.
Responder às mudanças mais que seguir um plano.

Isto é, embora haja valor nos itens do lado direito,

nós valorizamos mais os do lado esquerdo.”

http://www.agilemanifesto.org 2001
18/03/2010 José Alexandre & 10
Lourenço Marcos
 Os 12 Princípios do Manifesto Ágil
 12 princípios por traz do Manifesto Ágil
– Satisfazer o cliente
– As mudanças são bem vindas
– Entrega periódica de funcionalidade
– Todos juntos
– Indivíduos Motivados
– Conversas face a face
– Medida primária é o software trabalhado
– Manter um ritmo constante sempre
– Atenção contínua, excelência técnica e bom projeto
– Simplicidade
– Equipes auto-organizáveis ou auto-gerenciáveis
– Reflexão de melhoria regularmente
18/03/2010 José Alexandre & 11
Lourenço Marcos
 Pessoas X Tecnologia?

Ações
Objetivo Necessidades
Vontades

Equipes motivadas Foco nos

e comunicação indivíduos e
eficaz interações
Ter um ambiente
de projeto eficaz Conflito?
e eficiente
Padronização, Foco nos
produtividade, processos e
controle e medição ferramentas

18/03/2010 José Alexandre & 12

Lourenço Marcos
 Examinando as Premissas
• Equipes motivadas,
• Maior interação causa
comunicando-se melhor, Ações
Objetivo
produzem com mais qualidade, Necessidades• melhor comunicação
Alta interação fortalece oVontades
aumentando a eficácia do
sentimento de equipe
processo

Foco nos
indivíduos e
interações
Ter um ambiente
• Não é possível ter
de projeto eficaz foco em ambos!
Conflito?
e eficiente
Foco nos
processos e
ferramentas
• Um projeto necessita de • Processos são essenciais para padronização,
mecanismos de controle monitoramento, medição e controle
• Padronização leva à reutilização, • Ferramentas automatizam partes do processo, facilitam
que aumenta a produtividade e a padronização, aumentam a produtividade e permitem
diminui os erros a coleta automática de medidas

18/03/2010 José Alexandre & 13

Lourenço Marcos
 Pessoas & Tecnologia!

Ações
Objetivo Necessidades
Vontades

Indivíduos
amparados por
processos e
Ter um ambiente
ferramentas
de projeto eficaz
apropriadas,
e eficiente
otimizando
suas
interações

18/03/2010 José Alexandre & 14

Lourenço Marcos
 Triângulo de Ferro?

Ações
Objetivo Necessidades
Vontades

Entregar um produto Responder às

que o cliente deseja mudanças
Completar um
projeto com Conflito?
sucesso
Entregar no prazo e Seguir um
dentro do orçamento plano

18/03/2010 José Alexandre & 15

Lourenço Marcos
 Examinando as Premissas
• O cliente e a equipe
• Nenhum cliente fica satisfeito se
aprendem durante o Ações
não obtiver o que deseja, não
Objetivo Necessidadesprojeto
importando que tenha mudado
• Murphy participa Vontades
de idéia durante o projeto
ativamente dos projetos

Entregar um produto Responder às

que o cliente deseja mudanças
Completar um
• Não é possível
projeto com conseguir ambos!
Conflito?
sucesso
Entregar no prazo e Seguir um
dentro do orçamento plano
• É importante ter uma estimativa
de prazo e custo, até mesmo • Ter um mapa do caminho
para decidir se o projeto é viável ajuda muitíssimo na viagem
• Cumprir essas expectativas é • Sem um plano, como saber
um sinal de confiança e quando há mudança?
competência

18/03/2010 José Alexandre & 16

Lourenço Marcos
 Triângulo de Ouro!

Ações
Objetivo Necessidades
Vontades

Entregar um produto Planejar com

que o cliente deseja Objetivos,
Entregáveis e
Completar um
Critérios de
projeto com
Sucesso,
sucesso
abraçando e
Entregar no prazo e monitorando a
dentro do orçamento variação

18/03/2010 José Alexandre & 17

Lourenço Marcos
 Projetos Doentes: Os Sintomas

Excesso de
mudanças
Prioridades
mutáveis

Recursos
sobrecarregados

Recursos não
disponíveis
Atrasos
Retrabalho

18/03/2010 José Alexandre & 18

Lourenço Marcos
 As Causas
1. Multitarefa Nociva
2. Lei de Parkinson
3. Síndrome do Estudante
4. Dependência Entre Tarefas
5. Matemática da Gerência de Projetos

18/03/2010 José Alexandre & 19

Lourenço Marcos
 1) Multitarefa Nociva
 Multitarefa é a execução “simultânea” de várias tarefas, onde
freqüentemente há a interrupção de uma tarefa para trabalhar em
outra
– Nociva: se houver alguém esperando pela saída da tarefa interrompida
– Benigna: se corresponde ao aproveitamento do tempo relativo a alguma
espera/execução da tarefa anterior
 Motivos:
– Prioridades que mudam
– Falha no planejamento
– Tédio em trabalhar numa só tarefa
– Atenção dispersa
– Síndrome da eficiência
– Políticas, métricas, cultura

18/03/2010 José Alexandre & 20

Lourenço Marcos
 Por que Aceitamos a Multitarefa?
 Cultura de “manter-se ocupado”
 Impressão de que “quantidade” aparece mais que
“qualidade”
 Não sabemos dizer “NÃO”
– Fórmula do sucesso: não sei
– Fórmula do fracasso: querer agradar a todo mundo

Demonstrar atitude Aceitar novas

de “posso fazer” tarefas

Ter uma carreira

de sucesso
Completar o
Cumprir os
trabalho
compromissos
compromissado

18/03/2010 José Alexandre & 21

Lourenço Marcos
 O Paradoxo da Multitarefa
 Intenção: acabar mais tarefas mais rapidamente
 Conseqüência: todas as tarefas atrasam, e sofrem
potencialmente de má qualidade

A B C

A B C
or aper P

or aper P

or aper P
A B C

A B C A B C A B C
or aper P

or aper P

or aper P

or aper P

or aper P

or aper P

or aper P

or aper P

or aper P
A
B
C

18/03/2010 José Alexandre & 22

Lourenço Marcos
 Síndrome do Estudante
 Quando alguém espera até o último
momento possível para iniciar uma tarefa
 “Por que fazer hoje o que eu posso
deixar para amanhã? Tenho tempo...”
 A segurança embutida já é consumida antes

Data de entrega Imaginou-se assim...

Trabalho real na tarefa

Tempo da
Segurança
tarefa

Mas na realidade foi assim...

Segurança Tempo da tarefa

Tempo

18/03/2010 José Alexandre & 23

Lourenço Marcos
 A Matemática do Ger. Projetos
 Duas operações são geralmente feitas:
– Adição: cada nível hierárquico adiciona
sua própria segurança, pois não confia 8+7=19
que a estimativa seja suficiente
– Subtração: cada nível desconta uma
parcela, pois presume-se que há 8 7
muita segurança embutida
 Como não se sabe o fator de 1+3+2=8
inflação/deflação, usa-se o
Critério 1 3 2
Hipotético
Universal de
Tentativa e
Erro

18/03/2010 José Alexandre & 24

Lourenço Marcos
 Metodologias
 XP – eXtreme Programming
 SCRUM
 LEAN
 CRYSTAL
 FDD
 Adaptive Software Development
 ...

25
18/03/2010 José Alexandre &
Lourenço Marcos
 XP – EXtreme Programming
 Começou a engatinhar 1987 e a se estruturar
em 1996 com o projeto C3 da Chrysler
 Criado pro Kent Beck, que utilizou pela
primeira vez em conjunto as práticas que
formam a estrutura do Extreme
Programming nesse projeto da Chrysler

 “Jeito leve, eficiente, de baixo risco, flexível,

previsível, científico e divertido de
desenvolver software” – Kent Beck

26
18/03/2010 José Alexandre &
Lourenço Marcos
 XP – EXtreme Programming

 Valores:
Comunicação
Simplicidade
Feedback
Coragem

 Abordagem Incremental

27
18/03/2010 José Alexandre &
Lourenço Marcos
 A quem se destina o – XP ?

 Grupos de 2 a 10 programadores
 Projetos de 1 a 36 meses (calendário)
 De 1000 a 250 000 linhas de código
 Papéis:
Programadores (foco central)(sem hierarquia)
“Treinador” ou “Técnico” (coach)
“Acompanhador” (tracker)
Cliente

28
18/03/2010 José Alexandre &
Lourenço Marcos
 XP – EXtreme Programming
12 Práticas
 Planejamento • Refatorar
 Entregas • Propriedade
Frequêntes Coletiva
 Metáfora • Integração
 Projeto Simples Contínua
 Testes • 40 horas
 Programação em semanais de
pares trabalho
• Cliente presente
• Padronização do
18/03/2010 José Alexandre &
Lourenço Marcos
Código 29
 SCRUM
 O nome é originado da organização de uma
equipe de Rugby para o reinicio da partida.

 Formalizado e implantado no desenvolvimento de

software em 1995 por Ken Shwaber

 A função primária do Scrum é ser utilizado para o

gerenciamento de projetos de desenvolvimento de
software
30

18/03/2010 José Alexandre &

Lourenço Marcos
 SCRUM
 O que é de fato?
É um framework de desenvolvimento de produto, sobre
um ciclo de vida interativo e incremental
 Objetivos:
Acompanhamento contínuo
Iterações curtas
Retorno mais rápido

 SCRUM NÃO É A BALA DE PRATA! “Não garante

sozinho o sucesso de um projeto”

31
18/03/2010 José Alexandre &
Lourenço Marcos
 SCRUM
 Quais são os papeis envolvidos?

 Product Owner (PO)

 Scrum Team

 Scrum Master

32
18/03/2010 José Alexandre &
Lourenço Marcos
 SCRUM
Papel do Product Owner
 Conhece o produto e as
necessidades do cliente
 Representa o cliente
 Define os requisitos do
produto, bem como sua
importância e urgência
 É responsável pelo retorno
do investimento

33
18/03/2010 José Alexandre &
Lourenço Marcos
 SCRUM
Papel do Scrum Master
 É o líder servidor
 Responsável por
remover os
impedimentos do time
 Por remover
interferências externas
 E por garantir o uso
correto do Scrum
 Ensina Scrum aos
envolvidos
34
18/03/2010 José Alexandre &
Lourenço Marcos
 SCRUM
Papel do Scrum Team
 Fazem parte do Scrum team
todos os desenvolvedores,
arquitetos, analistas, ... que
participam do projeto
 O time é auto-gerenciável e
multifuncional ou
multidisciplinar (pessoas
com diferentes aptidões)
 Decidem junto com o PO o
que entra no Sprint
 E são responsáveis pelas
estimativas de esforço

35
18/03/2010 José Alexandre &
Lourenço Marcos
 Resumo
 Quem faz?
 Engenheiros de software e outros interessados no projeto
trabalham juntos em uma equipe ágil . uma equipe ágil
enfatiza a comunica;’ao e colaboração entre todos que a
compõem
 Por que e importante?
 O ambiente moderno de negócios que cria sistemas
baseado em computador e produto software é apressado e
sempre mutável. A engenharia ágil apresenta uma
alternativa razoável para a engenharia de software
convencional para certas categorias de software e certos
tipos de projetos de software. As pesquisas mostram que
este modelo entrega rapidamente sistemas bem-sucedido.


36
18/03/2010 José Alexandre &
Lourenço Marcos
 Resumo
 Quais são os passos?

 O desenvolvimento ágil poderia ser melhor denominado “ pequena engenharia de

software já que as atividades de estrutura permanecem mais elas são reduzidas a
um conjunto mínimo de tarefas que leva a equipe do projeto a construção e entrega.

 Qual é o produto de trabalho?

 Clientes e engenheiro de software que têm adotado a filosofia ágil tem a mesma
impressão - o único produto de trabalho realmente importante e um - incremento
de software operacional que é entregue ao cliente na data combinada.

 Como se tem a certeza que se fez tudo certo?

 Quando o incremento de software entregue ao cliente lhe satisfaça

37
18/03/2010 José Alexandre &
Lourenço Marcos
Onde Aprender Mais?

18/03/2010 José Alexandre & 38

Lourenço Marcos
 Obrigado
pela
Atenção Dispensada !

18/03/2010 José Alexandre & 39

Lourenço Marcos
Onde Aprender Mais?
Bibliografia

 [PRESSMAN 02] PRESSMAN, R. S., “Engenharia de Software”, 5ª Ed.,
 Makron Books, 2002.

 [SEBESTA 99] SEBESTA, R. W., “Concepts of Programming Languages”,
 4th ed., Addison-Wesley, 1999.

 [SOMMERVILLE 00] SOMMERVILLE, I., “Software Engineering”, 6th edition, Addison-
 Wesley, 2000.
 [WELLS 04] WELLS, D., Disponível em http://www.extremeprogramming.org, Visitado em
14/03/2010;.

 [BECK 99] BECK, K., “Extreme Programming Explained: Embrace Change”, 1st Edition, Addison-
Wesley, 1999.

 [FOWLER 01] FOWLER, M., BECK, K., Disponível em http://www.agilemanifesto.org, Visitado em
14/03/2010;.


18/03/2010 José Alexandre & 40

Lourenço Marcos