centro universitário de lins - unilins 18/03/2010 josé alexandre & lourenço marcos 1 modelo...

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


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


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 .....


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


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


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


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;


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


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


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



Vontades

Examinando as PremissasExaminando as Premissas

Conflito?


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



Vontades

Pessoas & Tecnologia!Pessoas & Tecnologia!

Indivíduos amparados por

processos e ferramentas apropriadas, otimizando

suas interações


e eficiente

14


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


Vontades

15


Examinando as PremissasExaminando as Premissas

Responder às mudanças

Seguir um plano

Conflito?




sucesso


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


Triângulo de Ouro!Triângulo de Ouro!




sucesso


Vontades

Planejar com Objetivos,

Entregáveis e Critérios de Sucesso,

abraçando e monitorando a

variação

17


Projetos Doentes: Os SintomasProjetos Doentes: Os Sintomas

Atrasos

Recursos sobrecarregados

Excesso de mudanças

Retrabalho

Recursos não disponíveis

Prioridades mutáveis

18


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


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


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


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


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


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

......


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


26

XPXP – E – EXXtreme treme PProgrammingrogrammingXPXP – E – EXXtreme treme PProgrammingrogramming

Valores:Valores:ComunicaçãoComunicaçãoSimplicidadeSimplicidadeFeedbackFeedbackCoragemCoragem

Abordagem IncrementalAbordagem Incremental


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


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


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


30


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”


31


Quais são os papeis envolvidos?Quais são os papeis envolvidos?

Product Owner (PO)Product Owner (PO)

Scrum TeamScrum Team

Scrum MasterScrum Master


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


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


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


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.


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


37


38

Onde Aprender Mais? Onde Aprender Mais?

Obrigado

pela

Atenção Dispensada !


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;.


40

BibliografiaBibliografia

centro universitário de lins - unilins 18/03/2010 josé alexandre & lourenço marcos 1 modelo...

Documents