apresentacao sobre agile (1)

8/9/2019 Apresentacao Sobre Agile (1)

1/40

Centro Universitrio de Lins - Unilins

18/03/2010 Jos Alexandre &Loureno Marcos

1

Modelo gil de

Desenvolvimento deSoftware LOURENO MARCOS & JOS ALEXANDRE

Estudantes do Curso de Tecnologia em Anlise e

Desenvolvimento de Software UNILINS

18/03/2010


2/40

Sumrio

Introduo Premissas Bsicas do Modelo Tradicional

e suas conseqncias

Conceito de metodologia gil Como avaliar projetos Doentes Metodologias geis.

XP , SCRUM

Resumo


2


3/40

Premissas Bsicas do Modelo Tradicional


3

necessrio fazer uma anlise de requisitos profunda e detalhada antesde projetar a arquitetura do sistema.

necessrio fazer um estudo minucioso e elaborar uma descriodetalhada da arquitetura antes de comear a implement-la.

necessrio testar o sistema completamente antes de mandar a versofinal para o cliente.


4/40

O cenrio vivido por muitos


4

Algumas empresas adotam metodologias deAlgumas empresas adotam metodologias dedesenvolvimento e prticas extremamente formaisdesenvolvimento e prticas extremamente formaise controladoras, porm ainda no consegueme controladoras, porm ainda no conseguemobter qualidade.obter qualidade.

Por qu?Por qu?Pouca preocupao com as pessoas e a interao entre elasPouca preocupao com as pessoas e a interao entre elasPouca comunicao com o clientePouca comunicao com o clienteCustos muito altosCustos muito altosExcesso de formalismoExcesso de formalismo

Qual a consequncia disso?Qual a consequncia disso?Alta rotatividadeAlta rotatividadeNo fim o software no serve maisNo fim o software no serve maisProjeto canceladoProjeto cancelado

Prazos estouradosPrazos estourados


5/40

Alm disso .....


5

muitas empresas vivem em uma situao de total descontrole emuitas empresas vivem em uma situao de total descontrole efalta de qualidade, e no so nada geis, vivem o ...falta de qualidade, e no so nada geis, vivem o ...


6/40

... CAOS... CAOS


6

Mas esse problema no novo,Mas esse problema no novo, assim, que Fevereiro 2001, em Utah assim, que Fevereiro 2001, em Utah17 caras lanaram o ...17 caras lanaram o ...

Estatsticas de projetos indicam que:

31% so cancelados antes de ser complementeentregues;53% custam quase o dobro (189%) do esperado;Apenas 16% so completados no prazo estimado;

Fonte: Chaos Reporthttp://net.educause.edu/ir/library/pdf/NCP08083B.pdf


7/4018/03/2010 Jos Alexandre &Loureno Marcos

O Manifesto gil

7

O que isso? Um manifesto que criticava alguns mitos/prticas da

engenharia de software e da gerncia de projetosadotadas por abordagens tradicionalistas

Foi assinado por 17 pessoas envolvidas comdesenvolvimento de software, dentre eles consultores eprogramadores experientes

Kent BeckMike BeedleArie van BennekumAlistair CockburnWard CunninghamMartin Fowler

James GrenningJim HighsmithAndrew HuntRon JeffriesJon KernBrian Marick

Robert C. MartinSteve MellorKen SchwaberJeff SutherlandDave Thomas


8/40


9/40

Agilidade e a Engenharia de Software


9

Engenharia de software gil combina a filosofia e umconjunto de diretrizes de desenvolvimento. A filosofiaencoraja a satisfao de cliente e a entrega incremental de

software logo de inicio; isso envolve equipes pequena ,altamente motivada;mtodos informais; produto deengenharia de software mnimo e simplicidade global dodesenvolvimento.

As diretrizes enfatizam a entrega em contraposio aanalise e ao projeto e a comunicao ativa e continuaentre os desenvolvedores e clientes;


10/40


O que diz o Manifesto?

Estamos descobrindo melhores maneiras de desenvolver software,fazendo software e ajudando outros a faz-lo.Atravs deste trabalho passamos a valorizar:

Indivduos e interaes mais que processos e ferramentas.Software que funciona mais que documentao detalhada.

Colaborao do cliente mais que negociaes contratuais.

Responder s mudanas mais que seguir um plano.

Isto , embora haja valor nos itens do lado direito,ns valorizamos mais os do lado esquerdo.

http://www.agilemanifesto.org 2001 10


11/40


Os 12 Princpios do Manifesto gil

11

12 princpios por traz do Manifesto gil Satisfazer o cliente As mudanas so bem vindas Entrega peridica de funcionalidade

Todos juntos Indivduos Motivados Conversas face a face Medida primria o software trabalhado Manter um ritmo constante sempre Ateno contnua, excelncia tcnica e bom projeto Simplicidade Equipes auto-organizveis ou auto-gerenciveis Reflexo de melhoria regularmente


12/40

Ter um ambientede projeto eficaz

e eficiente


Pessoas X Tecnologia?

Conflito?

Equipes motivadase comunicao

eficaz

Padronizao,

produtividade,controle e medio

Objetivo NecessidadesAes

Vontades

Foco nosindivduos einteraes

Foco nos

processos eferramentas

12


13/40



Vontades

Examinando as Premissas

Conflito?Ter um ambientede projeto eficaz

e eficiente

Maior interao causamelhor comunicao

Alta interao fortalece osentimento de equipe

Processos so essenciais para padronizao,monitoramento, medio e controle

Ferramentas automatizam partes do processo, facilitama padronizao, aumentam a produtividade e permitema coleta automtica de medidas

Equipes motivadas,comunicando-se melhor,produzem com mais qualidade,aumentando a eficcia doprocesso

Um projeto necessita demecanismos de controle

Padronizao leva reutilizao,que aumenta a produtividade ediminui os erros

No possvel terfoco em ambos!

Foco nosindivduos einteraes

Foco nos

processos eferramentas

13


14/40



Vontades

Pessoas & Tecnologia!

Indivduos

amparados porprocessos eferramentasapropriadas,otimizando

suas

interaes

Ter um ambientede projeto eficaz

e eficiente

14


15/40


Tringulo de Ferro?

Responder s

mudanas

Seguir um

plano

Conflito?

Entregar um produto

que o cliente deseja

Entregar no prazo e

dentro do oramento

Completar umprojeto com

sucesso


Vontades

15


16/40


Examinando as Premissas

Responder s

mudanas

Seguir um

plano

Conflito?

Entregar um produto


Entregar no prazo e

dentro do oramento


sucesso


Vontades

O cliente e a equipeaprendem durante oprojeto

Murphy participaativamente dos projetos

Ter um mapa do caminhoajuda muitssimo na viagem

Sem um plano, como saberquando h mudana?

Nenhum cliente fica satisfeito seno obtiver o que deseja, noimportando que tenha mudadode idia durante o projeto

importante ter uma estimativade prazo e custo, at mesmopara decidir se o projeto vivel

Cumprir essas expectativas um sinal de confiana ecompetncia

No possvelconseguir ambos!

16


17/40


Tringulo de Ouro!

Entregar um produto


Entregar no prazo e

dentro do oramento


sucesso


Vontades

Planejar com

Objetivos,Entregveis eCritrios deSucesso,

abraando emonitorando a

variao

17


18/40


Projetos Doentes: Os Sintomas

Atrasos

Recursossobrecarregados

Excesso demudanas

Retrabalho

Recursos nodisponveis

Prioridadesmutveis

18


19/40


As Causas

1. Multitarefa Nociva2. Lei de Parkinson

3. Sndrome do Estudante

4. Dependncia Entre Tarefas5. Matemtica da Gerncia de Projetos

19


20/40


1) Multitarefa Nociva

Multitarefa a execuo simultnea de vrias tarefas, ondefreqentemente h a interrupo de uma tarefa para trabalhar emoutra Nociva: se houver algum esperando pela sada da tarefa interrompida

Benigna: se corresponde ao aproveitamento do tempo relativo a alguma

espera/execuo da tarefa anterior Motivos:

Prioridades que mudam

Falha no planejamento

Tdio em trabalhar numa s tarefa

Ateno dispersa Sndrome da eficincia

Polticas, mtricas, cultura

20


21/40


Por que Aceitamos a Multitarefa?

Cultura de manter-se ocupado Impresso de que quantidade aparece mais quequalidade

No sabemos dizer NO Frmula do sucesso: no sei

Frmula do fracasso: querer agradar a todo mundo

Ter uma carreirade sucesso

Demonstrar atitudede posso fazer

Cumprir oscompromissos

Aceitar novastarefas

Completar otrabalho

compromissado

21


22/40


O Paradoxo da Multitarefa

Inteno: acabar mais tarefas mais rapidamente Conseqncia: todas as tarefas atrasam, e sofrem

potencialmente de m qualidade

APreparo

BPreparo

CPreparo

A B C

APreparo

Preparo

BPreparo

CPreparo

AB Preparo

B Preparo

C Preparo

A Preparo

B Preparo

C

A B C

ABC

22


23/40


Sndrome do Estudante

Quando algum espera at o ltimomomento possvel para iniciar uma tarefa Por que fazer hoje o que eu posso

deixar para amanh? Tenho tempo...

A segurana embutida j consumida antes

Tempo

Trabalho

realna

tarefa

Data de entrega

Tempo datarefa

Segurana

Imaginou-se assim...

Tempo da tarefaSegurana

Mas na realidade foi assim...

23


24/40


A Matemtica do Ger. Projetos

Duas operaes so geralmente feitas: Adio: cada nvel hierrquico adicionasua prpria segurana, pois no confiaque a estimativa seja suficiente

Subtrao: cada nvel desconta uma

parcela, pois presume-se que hmuita segurana embutida

Como no se sabe o fator deinflao/deflao, usa-se o

1 3 2

8 7

1+3+2=8

8+7=19

CritrioHipotticoUniversal deTentativa eErro

24


25/40

MetodologiasMetodologias

XP eXtreme ProgrammingXP eXtreme ProgrammingSCRUMSCRUMLEANLEANCRYSTALCRYSTALFDDFDD Adaptive Software DevelopmentAdaptive Software Development......


25


26/40

XPXP E EXXtremetreme PProgrammingrogramming

Comeou a engatinhar 1987 e a se estruturarComeou a engatinhar 1987 e a se estruturarem 1996 com o projeto C3 da Chryslerem 1996 com o projeto C3 da Chrysler

Criado pro Kent Beck, que utilizou pelaCriado pro Kent Beck, que utilizou pela

primeira vez em conjunto as prticas queprimeira vez em conjunto as prticas queformam a estrutura doformam a estrutura do ExtremeExtremeProgrammingProgrammingnesse projeto danesse projeto da ChryslerChrysler

Jeito leve, eficiente, de baixo risco, flexvel,Jeito leve, eficiente, de baixo risco, flexvel,

previsvel, cientfico e divertido deprevisvel, cientfico e divertido dedesenvolver software Kent Beckdesenvolver software Kent Beck


26


27/40

XPXP E EXXtremetreme PProgrammingrogramming

Valores:Valores:ComunicaoComunicaoSimplicidadeSimplicidade

FeedbackFeedbackCoragemCoragem

Abordagem IncrementalAbordagem Incremental


27


28/40

A quem se destina o A quem se destina o XP ?XP ?

Grupos de 2 a 10 programadoresProjetos de 1 a 36 meses (calendrio)De 1000 a 250 000 linhas de cdigoPapis:Programadores (foco central)(sem hierarquia)Treinador ou Tcnico (coach)Acompanhador (tracker)Cliente


28


29/40

XPXP E EXXtremetreme PProgrammingrogramming12 Prticas12 Prticas

PlanejamentoPlanejamento EntregasEntregas

FrequntesFrequntesMetforaMetfora Projeto SimplesProjeto Simples TestesTestes

Programao emProgramao emparespares


29

RefatorarRefatorar PropriedadePropriedade

ColetivaColetiva

IntegraoIntegraoContnuaContnua

40 horas40 horas

semanais desemanais detrabalhotrabalho Cliente presenteCliente presente Padronizao doPadronizao do

CdigoCdigo


30/40

SCRUMSCRUM

O nome originado da organizao de umaO nome originado da organizao de umaequipe de Rugby para o reinicio da partida.equipe de Rugby para o reinicio da partida.

Formalizado e implantado no desenvolvimento deFormalizado e implantado no desenvolvimento desoftware em 1995 por Ken Shwabersoftware em 1995 por Ken Shwaber

A funo primria do Scrum ser utilizado para oA funo primria do Scrum ser utilizado para o

gerenciamento de projetos de desenvolvimento degerenciamento de projetos de desenvolvimento desoftwaresoftware


30


31/40

SCRUMSCRUM

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 contnuoAcompanhamento contnuoIteraes curtasIteraes curtasRetorno mais rpidoRetorno mais rpido

SCRUM NO A BALA DE PRATA! No garanteSCRUM NO A BALA DE PRATA! No garantesozinho o sucesso de um projetosozinho o sucesso de um projeto


31


32/40

SCRUMSCRUM

Quais so os papeis envolvidos?Quais so os papeis envolvidos?

Product Owner (PO)Product Owner (PO)

Scrum TeamScrum Team

Scrum MasterScrum Master


32

SCRUM


33/40

SCRUMSCRUMPapel do Product OwnerPapel do Product Owner

Conhece o produto e asConhece o produto e asnecessidades do clientenecessidades do cliente

Representa o clienteRepresenta o clienteDefine os requisitos doDefine os requisitos do

produto, bem como suaproduto, bem como suaimportncia e urgnciaimportncia e urgncia

responsvel pelo retorno responsvel pelo retornodo investimentodo investimento


33

SCSCRUM


34/40

SCRUMSCRUMPapel do Scrum MasterPapel do Scrum Master

o lder servidor o lder servidor Responsvel porResponsvel por

remover osremover os

impedimentos do timeimpedimentos do time Por removerPor remover

interferncias externasinterferncias externas E por garantir o usoE por garantir o uso

correto do Scrumcorreto do Scrum Ensina Scrum aosEnsina Scrum aos

envolvidosenvolvidos


34

SCRUMSCRUM


35/40

SCRUMSCRUMPapel do Scrum TeamPapel do Scrum Team

Fazem parte do Scrum teamFazem parte do Scrum teamtodos os desenvolvedores,todos os desenvolvedores,arquitetos, analistas, ... quearquitetos, analistas, ... queparticipam do projetoparticipam do projeto

O time auto-gerencivel eO time auto-gerencivel emultifuncional oumultifuncional oumultidisciplinar (pessoasmultidisciplinar (pessoascom diferentes aptides)com diferentes aptides)

Decidem junto com o PO oDecidem junto com o PO oque entra no Sprintque entra no Sprint

E so responsveis pelasE so responsveis pelasestimativas de esforoestimativas de esforo


35


36/40

ResumoResumo

Quem faz? Engenheiros de software e outros interessados no projetotrabalham juntos em uma equipe gil . uma equipe gilenfatiza a comunica;ao e colaborao entre todos que acompem

Por que e importante? O ambiente moderno de negcios que cria sistemas

baseado em computador e produto software apressado esempre mutvel. A engenharia gil apresenta umaalternativa razovel para a engenharia de softwareconvencional para certas categorias de software e certostipos de projetos de software. As pesquisas mostram queeste modelo entrega rapidamente sistemas bem-sucedido.


36


37/40

ResumoResumo

Quais so os passos?

O desenvolvimento gil poderia ser melhor denominado pequena engenharia desoftware j que as atividades de estrutura permanecem mais elas so reduzidas aum conjunto mnimo de tarefas que leva a equipe do projeto a construo e entrega.

Qual o produto de trabalho?

Clientes e engenheiro de software que tm adotado a filosofia gil tem a mesmaimpresso - o nico produto de trabalho realmente importante e um - incrementode 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 satisfaa


37


38/40


38

Onde Aprender Mais?


39/40

Obrigadopela

Ateno Dispensada !


39


40/40

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., Disponvel 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., Disponvel em http://www.agilemanifesto.org, Visitado em

14/03/2010;.

Bibliografia

apresentacao sobre agile (1)

Documents