ANLISE E PROJETO DE

SISTEMAS WEB
Prof. Miguel Brasil

MODELOS DE
PROCESSO
GEIS
miguelbrasil@ctism.ufsm.br

SEGUNDO PRESSMANN
Em muitas situaes no podemos definir completamente os requisitos antes
do incio do projeto.
Os engenheiros de software devem ser geis o suficiente para responder a um
ambiente de negcios mutante;

A equipe de desenvolvimento deve estar preparada para lidar com

modificaes no software que est sendo desenvolvido, nos membros da
equipe, na tecnologia que esta sendo utilizada, modificaes de todas as
espcies que podem ter impacto no produto que eles constroem ou no
projeto.

METODOLOGIAS AGEIS - MOTIVAO

Segundo os agilistas! Alguns dos PROBLEMAS Com mtodos
tradicionais de desenvolvimento so:
impossvel prever o futuro;

Pouca interao com os clientes;

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

Avaliao do progresso baseado na evoluo da burocracia e no do

cdigo;
nfase no processo de desenvolvimento de software;

Grande quantidade de erros;

Falta de flexibilidade.
3

METODOLOGIAS GEIS - DEFINIO

So mtodos de desenvolvimento
incremental em que os incrementos so
pequenos e, normalmente, as novas
verses do sistema so criadas e
disponibilizadas aos clientes a cada duas
ou trs semanas. Eles envolvem os
clientes no processo de desenvolvimento
para obter feedback rpido sobre a
evoluo
dos
requisitos.
Assim,
minimiza-se a documentao, pois se
utiliza mais a comunicao informal do
que reunies formais com documentos
escritos. (SOMMERVILLE, 2011)

Fonte: http://eufacoprogramas.com/wpcontent/uploads/2014/04/metodosageis.jpg

METODOLOGIAS GEIS - HISTRICO

A partir da metade de 1990 comearam a surgir como parte de
uma 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 gil
de software.
Esse movimento foi proposto para solucionar algumas das
fraquezas dos processos tradicionais da ES.

Os modelos geis podem fornecer importantes benefcios, mas

no so aplicveis a todos os tipos de projetos, produtos, pessoas
e situaes (PRESSMAN, 2006).
5

MANIFESTO GIL
Indivduos e interaes so mais importantes que processos e
ferramentas.
Software funcionando mais
documentao completa e detalhada.

importante

do

que

Colaborao com o cliente mais importante do que

negociao de contratos.

Adaptao a mudanas mais importante do que seguir o

plano 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 - XP
Desenvolvimento iterativo e
com a entrega constante de
pequenas
partes
da
funcionalidade do software.
Grupos pequenos
programadores)

(2 a 10,

Projetos de 1 a 36 meses
(calendrio)
Programao em pares

Cliente sempre presente

Refatorao
7

VALORES DO XP
Comunicao;

Feedback;
Coragem;

Simplicidade;
Respeito.

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 ;
Stand up meeting com Kanban.
9

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

Kanban
Fonte: http://www.modalisatechnology.com/wpcontent/uploads/2010/09/Kanba
n_chart.jpg
10

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 as
funcionalidades. Essa reunio recebe o nome de Jogo do Planejamento
(PLANNING POKER). O cliente identifica prioridades e os desenvolvedores
as estimam. Como o escopo reavaliado semanalmente, o projeto regido
por um contrato de escopo negocivel.
Para prover uma estimativa, o membro da equipe precisa de algum tipo de entendimento
do qu trata a estria. Pedindo para todos estimarem cada item, ns nos certificamos que
cada membro da equipe compreende do que cada item se trata. Isso aumenta a
probabilidade de que os membros se ajudaro durante o sprint. Isso tambm aumenta a
probabilidade de que questes importantes sobre a estria surjam cedo.
Quando pedimos que todos estimem uma estria, frequentemente descobrimos
discrepncias onde duas pessoas da equipe tm estimativas bastante diferentes para a
mesma estria. Esse tipo de coisa melhor ser descoberto e discutido o quanto antes.

13

PLANNING POKER
As cartas do baralho do planning poker
possuem os seguintes nmeros: 0 1/2 1
2 3 5- 8 13 20 40 100. Tambm
comum colocar um smbolo de
interrogao (?) e um desenho de uma
xcara de caf. Normalmente os nmeros
representam horas e dificilmente ser
usado os nmeros 100 e 40, isso porque
quando se pratica gil as atividades so
quebradas
em
tarefas
muito
pequenas. A interrogao utilizada
quando voc no tem a mnima noo de
estimativa para aquela tarefa e o caf para
descontrao quando todos j esto
cansados de estimar e precisam de um
tempo.
14

PLANNING POKER
Metfora: preciso traduzir as palavras do cliente para o
significado que ele espera dentro do projeto.

Ritmo Sustentvel: Trabalhar com qualidade, ritmo de

trabalho saudvel (40 horas/semana, 8 horas/dia), sem
horas extras. Trabalho motivado, motivao da equipe.

15

ATIVIDADES DO PROGRAMADOR
O carto de histria descreve uma caracterstica (feature)
desejada pelo cliente.
Ok, aqui est a histria:
E alm disso cada
Eu no posso te
entregar todas
funcionalidades
na primeira
verso.

funcionalidade necessita
do que chamamos de
estria do usurio

voc me entrega TODAS as

funcionalidades ou estrago
tua vida.

16

XP QUANDO NO ADOTAR?
Quando o cliente no aceita as regras do jogo.
Quando o cliente quer uma especificao detalhada do sistema antes
de comear.

Quando os programadores no esto dispostos a seguir (todas) as

regras 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

Fases e suas atividades.

18

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)

19

SCRUM - http://www.scrum.org/
A funo primria do Scrum ser utilizado para o
gerenciamento 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 Beedle
http://www.controlchaos.com .
Tarefas realizadas em padro de processo chamado:
SPRINT

Quantidade e tamanho dos sprints (max. at um ms) . Isso

varia de acordo a necessidade.
20

PILARES DO SCRUM
Scrum fundamentado nas teorias empricas de controle de
processo, ou seja, em observaes de experincias vividas .

Emprega uma abordagem iterativa e incremental para

aperfeioar a previsibilidade e o controle de riscos.
Trs pilares apoiam o controle emprico:
1. Transparncia
2. Inspeo

3. Adaptao.

21

CARACTERISTICAS DO SCRUM
Equipes
pequenas.

Requisitos
poucos estveis.
Iteraes curtas.
Reunies
de
acompanhament
o dirias de curta
durao.
22

FUNCIONAMENTO

15
min

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

23

PAPEIS NO SCRUM: EQUIPE SCRUM

Scrum Master
Garante produtividade e funcionalidade da equipe;
Tem como funo remover qualquer impedimento habilidade de uma equipe
de 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 de
desenvolvimento. produzida uma verso incremental
potencialmente 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 para
desenvolvimento na Sprint, junto com o plano de entrega do
incremento da Sprint.
26

ATIVIDADES DO SCRUM
Os requisitos so descritos em um documento (backlog).
So feitas estimativas de esforo para o desenvolvimento de
cada requisito.
definido pela equipe de desenvolvimento, ferramentas a
serem usadas e possveis riscos do projeto e as necessidades
de treinamento.
proposta uma arquitetura de desenvolvimento.

27

EXEMPLO PRODUCT BACKLOG

Fonte:
http://w
ww.mou
ntaingoat
software.
com/upl
oads/blo
g/Sprint
Backlog.j
pg
28

SPRINT
Sprint: veja template em:
http://www.miguelbrasil.c
om/agile/

29

PRTICAS: MONITORAMENTO
O Scrum no considera o tempo gasto
trabalhando nos itens do backlog da
Sprint. O trabalho restante e a data de
entrega so as variveis de interesse.
Em qualquer momento o total
trabalho remanescente para alcanar o
objetivo pode ser resumido.
Essas
devem
transparentes.

ser

informaes

30

PRTICAS: BURNDOWN
Burndown
Charts
o grfico de
andamento
do
Sprint,
relacionando
horas e data em
relao ao restante
do tempo hbil
para o trmino do
ciclo.

Fonte: Scrum e XP direto das trincheiras: Como ns fazemos Scrum.

(http://www.miguelbrasil.com/agile/LIVRO_ScrumeXPDiretodasTr
incheiras.pdf )
31

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 qualquer
problema no visto;
Locais e horas de trabalho devem ser energizadas, no sentido de que trabalhar horas
extras no necessariamente significa produzir mais.

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 pesquisa
bibliogrfica
e
diferencie
mtodos
geis de mtodos
planejados.

35

REFERNCIAS BIBLIOGRFICAS
Aula da Prof. Dra. Maria Ins Castieira - P. Engenharia de
Software 2010.

PRESSMANN, R. Engenharia de Software. 6. Ed.

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

36