Centro Universitrio de Lins - Unilins Modelo gil de Desenvolvimento de

LOURENO MARCOS-205003 & JOS ALEXANDRE-204960 Estudantes do Curso de Tecnologia em Anlise e

Software

Desenvolvimento de Software UNILINS

18/03/2010

18/03/2010 Jos Alexandre & Loureno Marcos

Sumrio
Introduo Premissas Bsicas do Modelo

Tradicional e suas conseqncias Conceito de metodologia gil Como avaliar projetos Doentes Metodologias geis.
XP , SCRUM

Resumo
18/03/2010 Jos Alexandre & Loureno Marcos 2

Premissas Bsicas do Modelo Tradicional

necessrio fazer uma anlise de requisitos profunda e detalhada antes de projetar a arquitetura do sistema. necessrio fazer um estudo minucioso e elaborar uma descrio detalhada da arquitetura antes de comear a implement-la. necessrio testar o sistema completamente antes de mandar a verso final para o cliente.

18/03/2010 Jos Alexandre & Loureno Marcos

O cenrio vivido por muitos

Algumas empresas adotam metodologias de desenvolvimento e prticas extremamente formais e controladoras, porm ainda no conseguem obter qualidade.

Por qu?

Pouca preocupao com as pessoas e a interao entre elas Pouca comunicao com o cliente Custos muito altos Excesso de formalismo Alta rotatividade No fim o software no serve mais Projeto cancelado Prazos estourados

Qual a consequncia disso?

18/03/2010 Jos Alexandre & Loureno Marcos

Alm disso .....

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

18/03/2010 Jos Alexandre & Loureno Marcos

Estatsticas de projetos indicam que: 31% so cancelados antes de ser complemente entregues; 53% custam quase o dobro (189%) do esperado; Apenas 16% so completados no prazo estimado; Fonte: Chaos Report http://net.educause.edu/ir/library/pdf/NCP08083B.pdf

... CAOS
Mas esse problema no novo, assim, que Fevereiro 2001, em Utah 17 caras lanaram o ...
18/03/2010 Jos Alexandre & Loureno Marcos 6

O Manifesto gil
O que isso? Um manifesto que criticava alguns mitos/prticas da engenharia de software e da gerncia de projetos adotadas por abordagens tradicionalistas Foi assinado por 17 pessoas envolvidas com desenvolvimento de software, dentre eles consultores e programadores experientes
Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler
18/03/2010 Jos Alexandre & Loureno Marcos

James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick

Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas

O que Agilidade?
a.gi.li.da.de sf (lat agilitate) 1. Qualidade do que gil. 2. Desembarao, ligeireza, presteza de movimentos. 3. Mobilidade, perspiccia, vivacidade. Geralmente associa-se Agilidade com:
Rapidez, Flexibilidade, Leveza Resumo: Habilidade para mudar

18/03/2010 Jos Alexandre & Loureno Marcos

Agilidade e a Engenharia de Software

Engenharia de software gil combina a filosofia e um

conjunto de diretrizes de desenvolvimento. A filosofia encoraja a satisfao de cliente e a entrega incremental de software logo de inicio; isso envolve equipes pequena , altamente motivada;mtodos informais; produto de engenharia de software mnimo e simplicidade global do desenvolvimento. As diretrizes enfatizam a entrega em contraposio a analise e ao projeto e a comunicao ativa e continua entre os desenvolvedores e clientes;

18/03/2010 Jos Alexandre & Loureno Marcos

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
18/03/2010 Jos Alexandre & Loureno Marcos

2001
10

Os 12 Princpios do Manifesto gil

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
11

18/03/2010 Jos Alexandre & Loureno Marcos

Pessoas X Tecnologia?
Objetivo Necessidades Equipes motivadas e comunicao eficaz Ter um ambiente de projeto eficaz e eficiente Padronizao, produtividade, controle e medio Aes Vontades Foco nos indivduos e interaes
Conflito?

Foco nos processos e ferramentas

18/03/2010 Jos Alexandre & Loureno Marcos

12

Examinando as Premissas
Equipes motivadas, comunicando-se melhor, produzem com mais qualidade, Objetivo aumentando a eficcia do processo Maior interao causa Aes melhor comunicao Necessidades Alta interao fortalece oVontades sentimento de equipe

Foco nos indivduos e interaes Ter um ambiente de projeto eficaz e eficiente

No possvel ter foco em ambos! Conflito?

Foco nos processos e ferramentas

Um projeto necessita de mecanismos de controle Padronizao leva reutilizao, que aumenta a produtividade e diminui os erros
18/03/2010 Jos Alexandre & Loureno Marcos

Processos so essenciais para padronizao, monitoramento, medio e controle Ferramentas automatizam partes do processo, facilitam a padronizao, aumentam a produtividade e permitem a coleta automtica de medidas
13

Pessoas & Tecnologia!

Objetivo Necessidades Aes Vontades

Ter um ambiente de projeto eficaz e eficiente

Indivduos amparados por processos e ferramentas apropriadas, otimizando suas interaes

18/03/2010 Jos Alexandre & Loureno Marcos

14

Tringulo de Ferro?
Objetivo Necessidades Aes Vontades Responder s mudanas
Conflito?

Entregar um produto que o cliente deseja Completar um projeto com sucesso Entregar no prazo e dentro do oramento

Seguir um plano

18/03/2010 Jos Alexandre & Loureno Marcos

15

Examinando as Premissas
Nenhum cliente fica satisfeito se no obtiver o que deseja, no Objetivo importando que tenha mudado de idia durante o projeto O cliente e a equipe aprendem durante o Necessidadesprojeto Murphy participa ativamente dos projetos

Aes Vontades

Entregar um produto que o cliente deseja Completar um projeto com sucesso

No possvel conseguir ambos!

Responder s mudanas
Conflito?

Entregar no prazo e dentro do oramento

importante ter uma estimativa de prazo e custo, at mesmo para decidir se o projeto vivel Cumprir essas expectativas um sinal de confiana e competncia
18/03/2010 Jos Alexandre & Loureno Marcos

Seguir um plano

Ter um mapa do caminho ajuda muitssimo na viagem Sem um plano, como saber quando h mudana?
16

Tringulo de Ouro!
Objetivo Necessidades Aes Vontades

Entregar um produto que o cliente deseja Completar um projeto com sucesso Entregar no prazo e dentro do oramento

Planejar com Objetivos, Entregveis e Critrios de Sucesso, abraando e monitorando a variao

18/03/2010 Jos Alexandre & Loureno Marcos

17

Projetos Doentes: Os Sintomas

Excesso de mudanas

Prioridades mutveis

Recursos sobrecarregados Recursos no disponveis Atrasos Retrabalho

18/03/2010 Jos Alexandre & Loureno Marcos

18

As Causas
1. Multitarefa Nociva 2. Lei de Parkinson 3. Sndrome do Estudante 4. Dependncia Entre Tarefas 5. Matemtica da Gerncia de Projetos

18/03/2010 Jos Alexandre & Loureno Marcos

19

1) Multitarefa Nociva
Multitarefa a execuo simultnea de vrias tarefas,

onde freqentemente h a interrupo de uma tarefa para trabalhar em outra

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

18/03/2010 Jos Alexandre & Loureno Marcos

Por que Aceitamos a Multitarefa?

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

qualidade No sabemos dizer NO

Frmula do sucesso: no sei Frmula do fracasso: querer agradar a todo mundo

Demonstrar atitude de posso fazer Ter uma carreira de sucesso Cumprir os compromissos

Aceitar novas tarefas

Completar o trabalho compromissado

18/03/2010 Jos Alexandre & Loureno Marcos

21

O Paradoxo da Multitarefa
Inteno: acabar mais tarefas mais rapidamente Conseqncia: todas as tarefas atrasam, e sofrem

potencialmente de m qualidade
A B C

A
o r ape rP o r ape rP

B
o r ape rP

C
A B C

A
o r ape rP o r ape rP

B
o r ape rP

C
o r ape rP

A
o r ape rP

B
o r ape rP

C
o r ape rP

A
o r ape rP

B
o r ape rP

A B C

18/03/2010 Jos Alexandre & Loureno Marcos

22

Sndrome do Estudante
Quando algum espera at o ltimo

momento possvel para iniciar uma tarefa Por que fazer hoje o que eu posso deixar para amanh? Tenho tempo... A segurana embutida j consumida antes
Data de entrega Imaginou-se assim... Tempo da tarefa Segurana

Trabalho real na tarefa

Mas na realidade foi assim... Segurana Tempo Tempo da tarefa

18/03/2010 Jos Alexandre & Loureno Marcos

23

A Matemtica do Ger. Projetos

Duas operaes so geralmente feitas:
Adio: cada nvel hierrquico adiciona sua prpria segurana, pois no confia que a estimativa seja suficiente Subtrao: cada nvel desconta uma parcela, pois presume-se que h muita segurana embutida
8+7=19

8 7 2

Como no se sabe o fator de

1+3+2=8

inflao/deflao, usa-se o
Critrio Hipottico Universal de Tentativa e Erro
18/03/2010 Jos Alexandre & Loureno Marcos

3
24

Metodologias
XP eXtreme Programming SCRUM LEAN CRYSTAL FDD

Adaptive Software Development

...

18/03/2010 Jos Alexandre & Loureno Marcos

25

XP EXtreme Programming
Comeou 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 prticas que formam a estrutura do Extreme Programming nesse projeto da Chrysler

Jeito leve, eficiente, de baixo risco, flexvel,

previsvel, cientfico e divertido de desenvolver software Kent Beck

18/03/2010 Jos Alexandre & Loureno Marcos

26

XP EXtreme Programming
Valores: Comunicao Simplicidade Feedback Coragem Abordagem Incremental

18/03/2010 Jos Alexandre & Loureno Marcos

27

A quem se destina o XP ?
Grupos de 2 a 10 programadores Projetos de 1 a 36 meses (calendrio) De 1000 a 250 000 linhas de cdigo Papis: Programadores (foco central)(sem hierarquia) Treinador ou Tcnico (coach) Acompanhador (tracker) Cliente

18/03/2010 Jos Alexandre & Loureno Marcos

28

XP EXtreme Programming
12 Prticas
Planejamento Entregas

Frequntes Metfora Projeto Simples Testes Programao em pares

18/03/2010 Jos Alexandre & Loureno Marcos

Refatorar Propriedade Coletiva Integrao Contnua 40 horas semanais de trabalho Cliente presente Padronizao do Cdigo

29

SCRUM
O nome originado da organizao de uma

equipe de Rugby para o reinicio da partida.

Formalizado e implantado no desenvolvimento de

software em 1995 por Ken Shwaber

A funo primria do Scrum ser utilizado para o

gerenciamento de projetos de desenvolvimento de software

30

18/03/2010 Jos Alexandre & Loureno Marcos

SCRUM
O que de fato? um framework de desenvolvimento de produto, sobre um ciclo de vida interativo e incremental Objetivos: Acompanhamento contnuo Iteraes curtas Retorno mais rpido SCRUM NO A BALA DE PRATA! No garante

sozinho o sucesso de um projeto

18/03/2010 Jos Alexandre & Loureno Marcos 31

SCRUM
Quais so os papeis envolvidos?

Product Owner (PO) Scrum Team Scrum Master

18/03/2010 Jos Alexandre & Loureno Marcos

32

SCRUM

Papel do Product Owner

Conhece o produto e as

necessidades do cliente Representa o cliente Define os requisitos do produto, bem como sua importncia e urgncia responsvel pelo retorno do investimento

18/03/2010 Jos Alexandre & Loureno Marcos

33

SCRUM

Papel do Scrum Master

o lder servidor Responsvel por

remover os impedimentos do time Por remover interferncias externas E por garantir o uso correto do Scrum Ensina Scrum aos envolvidos
18/03/2010 Jos Alexandre & Loureno Marcos 34

SCRUM

Papel do Scrum Team

Fazem parte do Scrum team

todos os desenvolvedores, arquitetos, analistas, ... que participam do projeto O time auto-gerencivel e multifuncional ou multidisciplinar (pessoas com diferentes aptides) Decidem junto com o PO o que entra no Sprint E so responsveis pelas estimativas de esforo
35

18/03/2010 Jos Alexandre & Loureno 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 colaborao entre todos que a compem

Por que e importante?

O ambiente moderno de negcios que cria sistemas

baseado em computador e produto software apressado e sempre mutvel. A engenharia gil apresenta uma alternativa razovel 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 & Loureno Marcos

Resumo
Quais so os passos?

O desenvolvimento gil poderia ser melhor denominado pequena engenharia de software j que as atividades de estrutura permanecem mais elas so reduzidas a um 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 mesma impresso - 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 satisfaa

37

18/03/2010 Jos Alexandre & Loureno Marcos

Onde Aprender Mais?

18/03/2010 Jos Alexandre & Loureno Marcos

38

Obrigado pela Ateno Dispensada !

18/03/2010 Jos Alexandre & Loureno Marcos 39

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

18/03/2010 Jos Alexandre & Loureno Marcos

40