ANLISE E PROJETO DE SISTEMAS WEBProf. Miguel Brasil

miguelbrasil@ctism.ufsm.br

MODELOS DE PROCESSO GEIS

SEGUNDO PRESSMANN

Em muitas situaes no podemos definir completamente os requisitos antesdo incio do projeto.

Os engenheiros de software devem ser geis o suficiente para responder a umambiente de negcios mutante;

A equipe de desenvolvimento deve estar preparada para lidar commodificaes no software que est sendo desenvolvido, nos membros daequipe, na tecnologia que esta sendo utilizada, modificaes de todas asespcies que podem ter impacto no produto que eles constroem ou noprojeto.

2

METODOLOGIAS AGEIS - MOTIVAO

Segundo os agilistas! Alguns dos PROBLEMAS Com mtodostradicionais de desenvolvimento so:

impossvel prever o futuro;

Pouca interao com os clientes;

nfase em burocracias (documentos, formulrios, processos, controlesrgidos, etc.);

Avaliao do progresso baseado na evoluo da burocracia e no docdigo;

nfase no processo de desenvolvimento de software;

Grande quantidade de erros;

Falta de flexibilidade.

3

METODOLOGIAS GEIS - DEFINIO

So mtodos de desenvolvimentoincremental em que os incrementos sopequenos e, normalmente, as novasverses do sistema so criadas edisponibilizadas aos clientes a cada duasou trs semanas. Eles envolvem osclientes no processo de desenvolvimentopara obter feedback rpido sobre aevoluo dos requisitos. Assim,minimiza-se a documentao, pois seutiliza mais a comunicao informal doque reunies formais com documentosescritos. (SOMMERVILLE, 2011)

4

Fonte: http://eufacoprogramas.com/wp-content/uploads/2014/04/metodos-ageis.jpg

METODOLOGIAS GEIS - HISTRICO

A partir da metade de 1990 comearam a surgir como parte deuma reao contra os mtodos "pesados".

Em 1999 Beck publica sua obra sobre o modelo XP.

Em 2001 Kent Beck e outros 16 notveis profissionais da rea(Aliana gil) lanaram o Manifesto para o desenvolvimento gilde software.

Esse movimento foi proposto para solucionar algumas dasfraquezas dos processos tradicionais da ES.

Os modelos geis podem fornecer importantes benefcios, masno so aplicveis a todos os tipos de projetos, produtos, pessoase situaes (PRESSMAN, 2006).

5

MANIFESTO GIL

Indivduos e interaes so mais importantes que processos eferramentas.

Software funcionando mais importante do quedocumentao completa e detalhada.

Colaborao com o cliente mais importante do quenegociao de contratos.

Adaptao a mudanas mais importante do que seguir oplano inicial.

ATENO: Os agilistas no desprezam os fatores da direita(final de cada frase); mas valorizam mais os de incio.

Veja mais em: http://www.manifestoagil.com.br/

6

EXTREME PROGRAMMING - XPDesenvolvimento iterativo e

com a entrega constante depequenas partes dafuncionalidade do software.

Grupos pequenos (2 a 10,programadores)

Projetos de 1 a 36 meses(calendrio)

Programao em pares

Cliente sempre presente

Refatorao

7

VALORES DO XP

Comunicao;

Feedback;

Coragem;

Simplicidade;

Respeito.

8

REGRAS PRTICAS DO XP

Planejamento (6 prticas)

1. Histrias do usurio;

2. Planejando liberaes (releases)e pequenas liberaes;

3. Dividir projetos em iteraes(ciclos);

4. Medindo velocidade do projeto;

5. Dinmica de pessoal;

6. Reunies dirias em p ;

9

Stand up meeting com Kanban.

10

Fonte: http://blog.myscrumhalf.com/2011/10/user-stories-o-que-sao-como-usar/

Fonte: http://www.modalisa-technology.com/wp-content/uploads/2010/09/Kanban_chart.jpg

Userstories

Kanban

REGRAS PRTICAS DO XP Projeto (design)

1. Simplicidade (no adicione funcionalidades antes do tempo)

2. Metfora

3. Cartes CRC (Classes, Responsabilidades e Colaborao)

4. Re-fabricar (refactor)

Codificao

1. O cliente deve estar sempre disponvel.

2. Programao em pares.

3. Codificar de acordo com padres acordados.

4. Codificar testes de unidade primeiro.

5. Integrar com freqncia.

6. O cdigo propriedade coletiva.

7. No atrase.

11

REGRAS PRTICAS DO XP Testes

1. Todo cdigo deve ter os testes de unidade.

2. Cada unidade deve ser testada antes de liberada.

3. Quando um erro encontrado, testes devem ser realizados.

4. Testes de aceitao devem ser frequentes.

Gerenciamento

1. A equipe deve ter um espao de trabalho dedicado.

2. Ritmo de trabalho sustentvel.

3. Reunio de p inicia cada dia.

4. Medir a velocidade do projeto.

5. Mexer os papeis das pessoas.

6. Concertar o XP quando ele quebrar.

12

ALGUMAS PRTICAS DO XP

Jogo de Planejamento: O desenvolvimento feito em iteraes semanais.Uma vez por semana, desenvolvedores e cliente renem-se para priorizar asfuncionalidades. Essa reunio recebe o nome de Jogo do Planejamento(PLANNING POKER). O cliente identifica prioridades e os desenvolvedoresas estimam. Como o escopo reavaliado semanalmente, o projeto regidopor um contrato de escopo negocivel.

Para prover uma estimativa, o membro da equipe precisa de algum tipo de entendimentodo qu trata a estria. Pedindo para todos estimarem cada item, ns nos certificamos quecada membro da equipe compreende do que cada item se trata. Isso aumenta aprobabilidade de que os membros se ajudaro durante o sprint. Isso tambm aumenta aprobabilidade de que questes importantes sobre a estria surjam cedo.

Quando pedimos que todos estimem uma estria, frequentemente descobrimosdiscrepncias onde duas pessoas da equipe tm estimativas bastante diferentes para amesma estria. Esse tipo de coisa melhor ser descoberto e discutido o quanto antes.

13

PLANNING POKER

As cartas do baralho do planning pokerpossuem os seguintes nmeros: 0 1/2 1 2 3 5- 8 13 20 40 100. Tambm comum colocar um smbolo deinterrogao (?) e um desenho de umaxcara de caf. Normalmente os nmerosrepresentam horas e dificilmente serusado os nmeros 100 e 40, isso porquequando se pratica gil as atividades soquebradas em tarefas muitopequenas. A interrogao utilizadaquando voc no tem a mnima noo deestimativa para aquela tarefa e o caf paradescontrao quando todos j estocansados de estimar e precisam de umtempo.

14

PLANNING POKER

Metfora: preciso traduzir as palavras do cliente para osignificado que ele espera dentro do projeto.

Ritmo Sustentvel: Trabalhar com qualidade, ritmo detrabalho saudvel (40 horas/semana, 8 horas/dia), semhoras extras. Trabalho motivado, motivao da equipe.

15

ATIVIDADES DO PROGRAMADOR

O carto de histria descreve uma caracterstica (feature)desejada pelo cliente.

16

E alm disso cada funcionalidade necessita

do que chamamos de estria do usurio

Eu no posso te entregar todas

funcionalidades na primeira

verso.

Ok, aqui est a histria: voc me entrega TODAS as funcionalidades ou estrago

tua vida.

XP QUANDO NO ADOTAR?

Quando o cliente no aceita as regras do jogo.

Quando o cliente quer uma especificao detalhada do sistema antesde comear.

Quando os programadores no esto dispostos a seguir (todas) asregras ou no tem o perfil Grupos grandes (>10 [>20] programadores).

Quando feedback rpido no possvel: sistema demora 6h para compilar.

testes demoram 12h para rodar.

exigncia de certificao que demora meses.

Quando no possvel realizar testes.

Quando o custo de mudanas exponencial.

17

RESUMO SOBRE EXTREME PROGRAM

18

Fases e suas atividades.

19

Voc colhe o que planta. Se focar em equipes baratas e sem capacidades, tero software ruim. Voc somente consegue ser gil em um time capacitado e motivado. Eder Ignatowicz.(gile Brasil, 2013)

SCRUM - http://www.scrum.org/

A funo primria do Scrum ser utilizado para ogerenciamento de projetos de desenvolvimento de SW.

Modelo para gerenciamento de projetos adaptado em (1993)por Jeff Suttherland para desenvolvimento de SW.

Posteriormente formalizado por Ken Schwaber e Beedlehttp://www.controlchaos.com .

Tarefas realizadas em padro de processo chamado:SPRINT

Quantidade e tamanho dos sprints (max. at um ms) . Issovaria de acordo a necessidade.

20

PILARES DO SCRUM

Scrum fundamentado nas teorias empricas de controle deprocesso, ou seja, em observaes de experincias vividas .

Emprega uma abordagem iterativa e incremental paraaperfeioar a previsibilidade e o controle de riscos.

Trs pilares apoiam o controle emprico:

1. Transparncia

2. Inspeo

3. Adaptao.

21

CARACTERISTICAS DO SCRUM

Equipespequenas.

Requisitospoucos estveis.

Iteraes curtas.

Reunies deacompanhamento dirias de curtadurao.

22

FUNCIONAMENTO

23

Fonte: traduzida do site http://www.agileforall.com/intro-to-agile/

15

min

PAPEIS NO SCRUM: EQUIPE SCRUM

Scrum Master

Garante produtividade e funcionalidade da equipe;

Tem como funo remover qualquer impedimento habilidade de uma equipede entregar o objetivo do sprint;

Assegurar que a equipe esteja utilizando corretamente as prticas de Scrum;

Gerencia o processo (no gerencia a equipe!!) .

Product Owner ou Proprietrio do produto

Define, ajusta e prioriza funcionalidades do produto;

Aceita ou rejeita resultados obtidos;

Maximizar ROI (Return of Investment) e TCO (Total Cost of Ownership).

Equipe de desenvolvimento: auto gerenciada.

24

EVENTOS DO SCRUM

SPRINT: max. 1 ms (1 a 4 semanas).

Composta pelos 4 eventos a seguir mais o trabalho dedesenvolvimento. produzida uma verso incrementalpotencialmente utilizvel do produto.

1. Reunio de planejamento da Sprint: 8 horas;

2. Reunio diria: 15 min;

3. Reviso da Sprint: 4 horas; e

4. Retrospectiva da Sprint: 3 horas.

25

ARTEFATOS DO SCRUM

PRODUCT BACKLOG:

Lista ordenada de tudo que necessrio no produto;

O Product Owner o seu responsvel;

Define, prioriza, descreve cada item;

Contedo mutvel.

SPRINT BACKLOG:

Conjunto de itens do Backlog do produto, selecionados paradesenvolvimento na Sprint, junto com o plano de entrega doincremento da Sprint.

26

ATIVIDADES DO SCRUM

Os requisitos so descritos em um documento (backlog).

So feitas estimativas de esforo para o desenvolvimento decada requisito.

definido pela equipe de desenvolvimento, ferramentas aserem usadas e possveis riscos do projeto e as necessidadesde treinamento.

proposta uma arquitetura de desenvolvimento.

27

EXEMPLO PRODUCT BACKLOG

28

Fonte: http://www.mountaingoatsoftware.com/uploads/blog/SprintBacklog.jpg

SPRINT

Sprint: veja template em:http://www.miguelbrasil.com/agile/

29

PRTICAS: MONITORAMENTO

O Scrum no considera o tempo gastotrabalhando nos itens do backlog daSprint. O trabalho restante e a data deentrega so as variveis de interesse.

Em qualquer momento o totaltrabalho remanescente para alcanar oobjetivo pode ser resumido.

Essas devem ser informaestransparentes.

30

PRTICAS: BURNDOWN

BurndownCharts

o grfico deandamento doSprint,relacionandohoras e data emrelao ao restantedo tempo hbilpara o trmino dociclo.

31

Fonte: Scrum e XP direto das trincheiras: Como ns fazemos Scrum. (http://www.miguelbrasil.com/agile/LIVRO_ScrumeXPDiretodasTrincheiras.pdf )

PRTICAS SCRUM Planos frequentes de mitigao de riscos desenvolvidos pela equipe;

Discusses dirias de status com a equipe, realizadas em p, duram cerca de 15 minutos;

Transparncia no planejamento e desenvolvimento;

Reunies frequentes com os stakeholders para monitorar o progresso;

Problemas no so ignorados e ningum penalizado por reconhecer ou descrever qualquerproblema no visto;

Locais e horas de trabalho devem ser energizadas, no sentido de que trabalhar horasextras no necessariamente significa produzirmais.

32

ENTO QUAIS SO AS CARACTERSTICAS COMUNS DE METODOLOGIAS GEIS?

Colocam o foco:

Na entrega frequente de subverses do software [funcionando]para o cliente.

Nos seres humanos que desenvolvem o software.

Retiram o foco de:

Processos rgidos e burocratizados.

Documentaes e contratos detalhados.

Ferramentas que so usadas pelos seres humanos.

33

MODELOS DE PROCESSO DIFEREM DE:

Fluxo geral e interdependncias de atividades e tarefas;

Grau de definio de cada tarefa;

Grau de elaborao dos produtos de trabalho;

Forma de aplicao da garantia de qualidade;

Forma de gerncia e controle do projeto;

Rigor e grau de detalhe da descrio do processo;

Grau de envolvimento do cliente;

Nvel de autonomia da equipe;

Organizao e grau de definio dos papeis na equipe

34

ATIVIDADE

Faa uma pesquisabibliogrfica ediferencie mtodosgeis de mtodosplanejados.

35

REFERNCIAS BIBLIOGRFICAS

Aula da Prof. Dra. Maria Ins Castieira - P. Engenharia deSoftware 2010.

PRESSMANN, R. Engenharia de Software. 6. Ed.McGraw-Hill, 2007.

SOMMERVILLE, I. Engenharia de Software. 8. Ed.Pearson Education, 2007.

36