Centro Universitário de Lins - Unilins 18/03/2010 José Alexandre & Lourenço Marcos 1 Modelo Ágil...
Transcript of Centro Universitário de Lins - Unilins 18/03/2010 José Alexandre & Lourenço Marcos 1 Modelo Ágil...
Centro Universitário de Lins - UnilinsCentro Universitário de Lins - Unilins
18/03/2010 José Alexandre & Lourenço Marcos
1
Modelo Ágil de
Desenvolvimento de Software LOURENÇO MARCOS-205003
& JOSÉ ALEXANDRE-204960
Estudantes do Curso de Tecnologia em Análise e Desenvolvimento de Software
UNILINS
18/03/2010
Sumário 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
Resumo18/03/2010 José Alexandre & Lourenço Marcos
2
Premissas Básicas do Modelo TradicionalPremissas Básicas do Modelo Tradicional
18/03/2010 José Alexandre & Lourenço Marcos
3
É 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.
O cenário vivido por muitosO cenário vivido por muitos
18/03/2010 José Alexandre & Lourenço Marcos
4
Algumas empresas adotam metodologias de Algumas empresas adotam metodologias de desenvolvimento e práticas extremamente formais desenvolvimento e práticas extremamente formais e controladoras, porém ainda não conseguem e controladoras, porém ainda não conseguem obter qualidade.obter qualidade.
Por quê?Por quê?Pouca preocupação com as pessoas e a interação entre elasPouca preocupação com as pessoas e a interação entre elasPouca comunicação com o clientePouca comunicação com o clienteCustos muito altosCustos muito altosExcesso de formalismoExcesso de formalismo
Qual a consequência disso?Qual a consequência disso?Alta rotatividadeAlta rotatividadeNo fim o software não serve maisNo fim o software não serve maisProjeto canceladoProjeto canceladoPrazos estouradosPrazos estourados
Além disso .....Além disso .....
18/03/2010 José Alexandre & Lourenço Marcos
5
muitas empresas vivem em uma situação de total descontrole e muitas empresas vivem em uma situação de total descontrole e falta de qualidade, e não são nada ágeis, vivem o ...falta de qualidade, e não são nada ágeis, vivem o ...
... CAOS... CAOS... CAOS... CAOS
18/03/2010 José Alexandre & Lourenço Marcos
6
Mas esse problema não é novo, Mas esse problema não é novo, É assim, que Fevereiro 2001, em UtahÉ assim, que Fevereiro 2001, em Utah17 caras lançaram o ...17 caras lançaram o ...
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 Reporthttp://net.educause.edu/ir/library/pdf/NCP08083B.pdf
18/03/2010 José Alexandre & Lourenço Marcos
O Manifesto ÁgilO Manifesto Ágil
7
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 BeckMike BeedleArie van BennekumAlistair CockburnWard CunninghamMartin Fowler
James GrenningJim HighsmithAndrew HuntRon JeffriesJon KernBrian Marick
Robert C. MartinSteve MellorKen SchwaberJeff SutherlandDave Thomas
O que é Agilidade?O que é Agilidade?
18/03/2010 José Alexandre & Lourenço Marcos8
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
Agilidade e a Engenharia de SoftwareAgilidade e a Engenharia de Software
18/03/2010 José Alexandre & Lourenço Marcos
9
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 & Lourenço Marcos
O que diz o Manifesto? 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 200110
18/03/2010 José Alexandre & Lourenço Marcos
Os 12 Princípios do Manifesto ÁgilOs 12 Princípios do Manifesto Ágil
11
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
Ter um ambiente de projeto eficaz
e eficiente
18/03/2010 José Alexandre & Lourenço Marcos
Pessoas X Tecnologia?Pessoas X Tecnologia?
Conflito?
Equipes motivadas e comunicação
eficaz
Padronização, produtividade,
controle e medição
Objetivo NecessidadesAções
Vontades
Foco nos indivíduos e interações
Foco nos processos e ferramentas
12
18/03/2010 José Alexandre & Lourenço Marcos
Objetivo NecessidadesAções
Vontades
Examinando as PremissasExaminando as Premissas
Conflito?
Ter um ambiente de projeto eficaz
e eficiente
• Maior interação causa melhor comunicação
• Alta interação fortalece o sentimento de equipe
• Processos são essenciais para padronização, monitoramento, medição e controle
• Ferramentas automatizam partes do processo, facilitam a padronização, aumentam a produtividade e permitem a coleta automática de medidas
• Equipes motivadas, comunicando-se melhor, produzem com mais qualidade, aumentando a eficácia do processo
• Um projeto necessita de mecanismos de controle
• Padronização leva à reutilização, que aumenta a produtividade e diminui os erros
• Não é possível ter foco em ambos!
Foco nos indivíduos e interações
Foco nos processos e ferramentas
13
18/03/2010 José Alexandre & Lourenço Marcos
Objetivo NecessidadesAções
Vontades
Pessoas & Tecnologia!Pessoas & Tecnologia!
Indivíduos amparados por
processos e ferramentas apropriadas, otimizando
suas interações
Ter um ambiente de projeto eficaz
e eficiente
14
18/03/2010 José Alexandre & Lourenço Marcos
Triângulo de Ferro?Triângulo de Ferro?
Responder às mudanças
Seguir um plano
Conflito?
Entregar um produto que o cliente deseja
Entregar no prazo e dentro do orçamento
Completar um projeto com
sucesso
Objetivo NecessidadesAções
Vontades
15
18/03/2010 José Alexandre & Lourenço Marcos
Examinando as PremissasExaminando as Premissas
Responder às mudanças
Seguir um plano
Conflito?
Entregar um produto que o cliente deseja
Entregar no prazo e dentro do orçamento
Completar um projeto com
sucesso
Objetivo NecessidadesAções
Vontades
• O cliente e a equipe aprendem durante o projeto
• Murphy participa ativamente dos projetos
• Ter um mapa do caminho ajuda muitíssimo na viagem
• Sem um plano, como saber quando há mudança?
• Nenhum cliente fica satisfeito se não obtiver o que deseja, não importando que tenha mudado de idéia durante o projeto
• É importante ter uma estimativa de prazo e custo, até mesmo para decidir se o projeto é viável
• Cumprir essas expectativas é um sinal de confiança e competência
• Não é possível conseguir ambos!
16
18/03/2010 José Alexandre & Lourenço Marcos
Triângulo de Ouro!Triângulo de Ouro!
Entregar um produto que o cliente deseja
Entregar no prazo e dentro do orçamento
Completar um projeto com
sucesso
Objetivo NecessidadesAções
Vontades
Planejar com Objetivos,
Entregáveis e Critérios de Sucesso,
abraçando e monitorando a
variação
17
18/03/2010 José Alexandre & Lourenço Marcos
Projetos Doentes: Os SintomasProjetos Doentes: Os Sintomas
Atrasos
Recursos sobrecarregados
Excesso de mudanças
Retrabalho
Recursos não disponíveis
Prioridades mutáveis
18
18/03/2010 José Alexandre & Lourenço Marcos
As CausasAs 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
19
18/03/2010 José Alexandre & Lourenço Marcos
1) Multitarefa Nociva1) 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
20
18/03/2010 José Alexandre & Lourenço Marcos
Por que Aceitamos a Multitarefa?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
Ter uma carreirade sucesso
Demonstrar atitude de “posso fazer”
Cumprir os compromissos
Aceitar novas tarefas
Completar o trabalho
compromissado
21
18/03/2010 José Alexandre & Lourenço Marcos
O Paradoxo da MultitarefaO Paradoxo da Multitarefa
Intenção: acabar mais tarefas mais rapidamente Conseqüência: todas as tarefas atrasam, e sofrem
potencialmente de má qualidade
A
Pre
paro
BP
repa
roC
Pre
paro
A B C
A
Pre
paro
Pre
paro
B
Pre
paro
C
Pre
paro
AB
Pre
paro
BP
repa
roC
Pre
paro
A
Pre
paro
B
Pre
paro
C
A B C
ABC
22
18/03/2010 José Alexandre & Lourenço Marcos
Síndrome do Estudante Síndrome do Estudante
Quando alguém espera até o últimomomento possível para iniciar uma tarefa
“Por que fazer hoje o que eu possodeixar para amanhã? Tenho tempo...”
A segurança embutida já é consumida antes
Tempo
Tra
balh
o r
eal
na
tare
fa
Data de entrega
Tempo da tarefa
Segurança
Imaginou-se assim...
Tempo da tarefaSegurança
Mas na realidade foi assim...
23
18/03/2010 José Alexandre & Lourenço Marcos
A Matemática do Ger. Projetos 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 confiaque a estimativa seja suficiente
– Subtração: cada nível desconta umaparcela, pois presume-se que hámuita segurança embutida
Como não se sabe o fator deinflação/deflação, usa-se o
1 3 2
8 7
1+3+2=8
8+7=19
CritérioHipotéticoUniversal deTentativa eErro
24
MetodologiasMetodologiasMetodologiasMetodologias
XP – eXtreme ProgrammingXP – eXtreme Programming SCRUMSCRUM LEANLEAN CRYSTALCRYSTAL FDDFDD Adaptive Software DevelopmentAdaptive Software Development
......
18/03/2010 José Alexandre & Lourenço Marcos
25
XPXP – E – EXXtreme treme PProgrammingrogrammingXPXP – E – EXXtreme treme PProgrammingrogramming
Começou a engatinhar 1987 e a se estruturar Começou a engatinhar 1987 e a se estruturar em 1996 com o projeto C3 da Chryslerem 1996 com o projeto C3 da Chrysler
Criado pro Kent Beck, que utilizou pela Criado pro Kent Beck, que utilizou pela primeira vez em conjunto as práticas que primeira vez em conjunto as práticas que formam a estrutura do formam a estrutura do Extreme Extreme Programming Programming nesse projeto da nesse projeto da ChryslerChrysler
““Jeito leve, eficiente, de baixo risco, flexível, Jeito leve, eficiente, de baixo risco, flexível, previsível, científico e divertido de previsível, científico e divertido de desenvolver software” – Kent Beckdesenvolver software” – Kent Beck
18/03/2010 José Alexandre & Lourenço Marcos
26
XPXP – E – EXXtreme treme PProgrammingrogrammingXPXP – E – EXXtreme treme PProgrammingrogramming
Valores:Valores:ComunicaçãoComunicaçãoSimplicidadeSimplicidadeFeedbackFeedbackCoragemCoragem
Abordagem IncrementalAbordagem Incremental
18/03/2010 José Alexandre & Lourenço Marcos
27
A quem se destina o –A quem se destina o – XP ? XP ?A quem se destina o –A quem se destina o – XP ? 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
18/03/2010 José Alexandre & Lourenço Marcos
28
XPXP – E – EXXtreme treme PProgrammingrogramming12 Práticas12 PráticasXPXP – E – EXXtreme treme PProgrammingrogramming12 Práticas12 Práticas
PlanejamentoPlanejamento Entregas Entregas
FrequêntesFrequêntes MetáforaMetáfora Projeto SimplesProjeto Simples TestesTestes Programação em Programação em
parespares
18/03/2010 José Alexandre & Lourenço Marcos
29
• RefatorarRefatorar• Propriedade Propriedade
ColetivaColetiva• Integração Integração
ContínuaContínua• 40 horas 40 horas
semanais de semanais de trabalhotrabalho
• Cliente presenteCliente presente• Padronização do Padronização do
CódigoCódigo
SCRUMSCRUMSCRUMSCRUM
O nome é originado da organização de uma O nome é originado da organização de uma equipe de Rugby para o reinicio da partida.equipe de Rugby para o reinicio da partida.
Formalizado e implantado no desenvolvimento de Formalizado e implantado no desenvolvimento de software em 1995 por Ken Shwabersoftware em 1995 por Ken Shwaber
A função primária do Scrum é ser utilizado para o A função primária do Scrum é ser utilizado para o gerenciamento de projetos de desenvolvimento de gerenciamento de projetos de desenvolvimento de softwaresoftware
18/03/2010 José Alexandre & Lourenço Marcos
30
SCRUMSCRUMSCRUMSCRUM
O que é de fato?O que é de fato?É um framework de desenvolvimento de produto, sobre É um framework de desenvolvimento de produto, sobre
um ciclo de vida interativo e incrementalum ciclo de vida interativo e incremental
Objetivos:Objetivos:Acompanhamento contínuoAcompanhamento contínuoIterações curtasIterações curtasRetorno mais rápidoRetorno mais rápido
SCRUM NÃO É A BALA DE PRATA! “Não garante SCRUM NÃO É A BALA DE PRATA! “Não garante sozinho o sucesso de um projeto”sozinho o sucesso de um projeto”
18/03/2010 José Alexandre & Lourenço Marcos
31
SCRUMSCRUMSCRUMSCRUM
Quais são os papeis envolvidos?Quais são os papeis envolvidos?
Product Owner (PO)Product Owner (PO)
Scrum TeamScrum Team
Scrum MasterScrum Master
18/03/2010 José Alexandre & Lourenço Marcos
32
SCRUMSCRUMPapel do Product OwnerPapel do Product OwnerSCRUMSCRUMPapel do Product OwnerPapel do Product Owner
Conhece o produto e as Conhece o produto e as necessidades do clientenecessidades do cliente
Representa o clienteRepresenta o cliente Define os requisitos do Define os requisitos do
produto, bem como sua produto, bem como sua importância e urgênciaimportância e urgência
É responsável pelo retorno É responsável pelo retorno do investimentodo investimento
18/03/2010 José Alexandre & Lourenço Marcos
33
SCRUMSCRUMPapel do Scrum MasterPapel do Scrum MasterSCRUMSCRUMPapel do Scrum MasterPapel do Scrum Master
É o líder servidorÉ o líder servidor Responsável por Responsável por
remover os remover os impedimentos do timeimpedimentos do time
Por remover Por remover interferências externasinterferências externas
E por garantir o uso E por garantir o uso correto do Scrumcorreto do Scrum
Ensina Scrum aos Ensina Scrum aos envolvidosenvolvidos
18/03/2010 José Alexandre & Lourenço Marcos
34
SCRUMSCRUMPapel do Scrum TeamPapel do Scrum TeamSCRUMSCRUMPapel do Scrum TeamPapel do Scrum Team
Fazem parte do Scrum team Fazem parte do Scrum team todos os desenvolvedores, todos os desenvolvedores, arquitetos, analistas, ... que arquitetos, analistas, ... que participam do projetoparticipam do projeto
O time é auto-gerenciável e O time é auto-gerenciável e multifuncional ou multifuncional ou multidisciplinar (pessoas multidisciplinar (pessoas com diferentes aptidões)com diferentes aptidões)
Decidem junto com o PO o Decidem junto com o PO o que entra no Sprintque entra no Sprint
E são responsáveis pelas E são responsáveis pelas estimativas de esforçoestimativas de esforço
18/03/2010 José Alexandre & Lourenço Marcos
35
Resumo Resumo Resumo 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.
18/03/2010 José Alexandre & Lourenço Marcos
36
Resumo Resumo Resumo 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
18/03/2010 José Alexandre & Lourenço Marcos
37
18/03/2010 José Alexandre & Lourenço Marcos
38
Onde Aprender Mais? Onde Aprender Mais?
Obrigado
pela
Atenção Dispensada !
18/03/2010 José Alexandre & Lourenço Marcos
39
Onde Aprender Mais?Onde Aprender Mais?
[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 & Lourenço Marcos
40
BibliografiaBibliografia