Métodos_Àgeis_-_CBSoft

7/22/2019 Mtodos_geis_-_CBSoft

1/101

CBSoft Salvador Bahia Setembro de 2010

Introduo a Mtodos geisde Desenvolvimento de

SoftwareDaniel Cukier (AgilCoop)

twitter.com/danicuki

Prof. Dr. Rafael Prikladnicki (PUCRS)twitter.com/rafaelpri


2/101


Quem usa Scrum e XP?


3/101




4/101


EUA

BR2 anos!



5/101




6/101




7/101CBSoft Salvador Bahia Setembro de 2010




Daniel Cukier15 anos de experincia com desenvolvimento do Software

3 anos como gerente de Desenvolvimento na Locaweb

Membro da Agilcoop desde 2003

Autor do blog www.agileandart.com

Mestre em Cincia da ComputaoIME/USP (2009)

Palestra em vrios eventosEncontro gil, Oxente Rails, Falando em gil, SugarLoafPLoP, etc

reas de atuao acadmica e profissional:

Desenvolvedor e lder tcnico em vrios projetos de software.

Um dos responsveis pela implantao de Mtodos geis na Locaweb

Padres para Introduzir Novas Ideias na Indstria de Software

Outras no menos importantes:

Teatro, msica, poesia, meditao
http://www.agileandart.com/http://www.agileandart.com/



Contexto e experincia na AgilCoop

Cursos de graduao em XP desde 2001

ApresentaesSBES, SUCESU, SEPAI, SEBRAE, etc.

Arquivos disponveis: www.agilcoop.org.br

Assessorias em mtodos geis

Artigos cientficos

Dissertaes de Mestrado



Professor da FACINPUCRS desde 2004www.inf.pucrs.br/~rafael

Coordenador de Gesto de Projetos da AGT/PUCRSProfessor do PPGCC desde 2010/1

Coordenador do GUMA e do SPIN-POA (Sucesu-RS)

Certified ScrumMaster (CSM) e Project Mgmt Professional (PMP)

Mestre em Cincia da ComputaoPUCRS (2003)

Doutor em Cincia da ComputaoPUCRS (2009)

reas de atuao acadmica e profissional:

Desenvolvimento Distribudo de SoftwareGerncia de Projetos

Melhoria de Processo de Software

Engenharia de Software Experimental

Leane Mtodos geis para Desenvolvimento de Software

Rafael Prikladnicki



Contexto e experincia na PUCRS

www.inf.pucrs.br/munddos

Criado em 2001

Registrado no CNPq em 2004

Livros publicados em 2007, 2009 e 20102 pesquisadores

Formou 11 mestres, 1 doutor

Possui 6 mestrandos, 2 doutorandos



Implantao de prticas de DDS nas empresas

Desenvolvimento de ferramentas para apoiar DDS

Integrao de DDS com mtodos geisEstudo de maneiras de usar Follow-the-Sun (FTS)

Formao de profissionais e alunos em DDS

Estudo do papel do Brasil no mercado global de TI

www.inf.pucrs.br/munddos




Introduo e motivaoO que so Mtodos geis?

Princpios

Problemas com abordagens tradicionais

Alguns mtodos geis

Concluso

Agenda



Por que teu projeto

termina comsucesso?

Por que teu projetofracassa?

Discusso em grupo 15 minutos

Agrupar problemas efracassos emcategorias

Dinmica

Grupo 2

Grupo n

Grupo 1

Grupo 3

Sucesso Fracasso

Ref: Henrik Kniberg



Motivao



Como ganhar dinheiroresolvendo problemas que

voce no conhece, compessoas desconhecidas, emum tempo curto e com

poucos recursos (e sedivertindo)?

Motivao



Tenho como produzir 100 avies em 10 minutos?

Quantos avies 10 pessoas produzem em 10 minutos?

Tenho, mas:

- Vou verificar tudo ao final

- Posso ter baixa qualidade

- Posso ter retrabalho

- Posso no ter entendido o escopoEnto por que deixar tudo para o final?


20/101


Tenho como produzir 100 avies em 10 minutos?

E se produzirmos um pouco a cada 2 minutos?

E se melhorarmos a cada ciclo?

E se o cliente fornecer feedback a cada ciclo?

E se a equipe encontrar a melhor forma de trabalhar?

Quantos avies 10 pessoas produzem em 10 minutos?


21/101


0

50

100

150

200

250

300

Objetivo Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5

Sprints

Avies restantes

Motivao


22/101


Grfico de Burndown

0

50

100

150

200

250

Objetivo Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5

Sprints

Avies restantes

Motivao


23/101


Sociedade demandagrande quantidade de sistemas/aplicaes

software complexo, sistemas distribudos,heterogneos

requisitos mutantes (todo ano, todo ms,todo dia)

Mas, infelizmente,no h gente suficiente para desenvolver tanto

software com qualidade

Novos ventos no desenvolvimento de software


24/101


Resultado dos projetos em 2004

Relatrio do Chaos (Chaos Report)


25/101


Resultado dos projetos em 2004

Relatrio do Chaos (Chaos Report)

1994 2004

Projetosno concludos

------------31%

Projetos bem sucedidos-----16%

Estouro mdio de custo----------------------->180%

Estouro mdio de prazo----------------------->164%

Projetos no concludos

-------18%

Projetos bem sucedidos-----------29%

Estouro mdio de custo-----------------56%

Estouro mdio deprazo-------------------------84%


26/101


Evitar desperdcio

Estudo do The Standish Group conclui (Chaos Report):

Pesquisa sobre a utilizao das funcionalidades do software ...

Mais de 64%de um sistema desoftware quase nunca no utilizado!


27/101


Com mtodos tradicionais/clssicos de

desenvolvimentoSupem que possvel 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 do cdigoCom softwareGrande quantidade de erros

Falta de flexibilidade

Problemas


28/101


Melhores Tecnologias

Padres de Projeto (reutilizao de idias)Componentes (reutilizao de cdigo)Middleware/frameworks (aumenta a bstrao)

Melhores MetodologiasMtodos geis (o foco deste mini-curso)

outras... (abordados em outros cursos de ES)

Como resolver o impasse?


29/101


Erro comum: olhar para software como apenas um desses itens eignorar os demais

O que desenvolvimento de software?

(Gabriel)Arte(Knuth)Artesanato

(Cockburn)Poesia(Humphreys)Disciplina

(Meyer)Engenharia(Jacobson)Modelagem

Por Alistair Cockburn:

d


30/101


Agile is not a set ofpractices, but a

core set of beliefs

and principlesJim Highsmith

O que so mtodos geis?

i i


31/101


Retorno de investimentoInovaoMelhoria de processo

PessoasCultura

ComunicaoAdaptao x Antecipao

Princpios

Hi i


32/101


Movimento iniciado por programadoresexperientes e consultores em desenvolvimentode software.

Questionam e se opem a uma srie de mitos e

prticas adotadas em abordagens tradicionaisde Engenharia de Software e Gerncia deProjetos.

Manifesto gil:

Assinado por 17 desenvolvedores em Utah emfevereiro/2001.

http://agilemanifesto.org

Histrico

A il M if t (2001)


33/101


Processos e ferramentas

Documentao abrangente

Negociao de contrato

Plano pr-estabelecido

maisimportante

que

Agile Manifesto (2001)

Indivduos e interaes

Software funcionando

Colaborao do cliente

Resposta s mudanas

http://agilemanifesto.org

Kent Beck James Grenning Robert C. MartinMike Beedle Jim Highsmith Steve Mellor

Arie van Bennekum Andrew Hunt Ken SchwaberAlistair Cockburn Ron Jeffries Jeff SutherlandWard Cunningham Jon Kern Dave ThomasMartin Fowler Brian Marick

Al i i


34/101


O mais importante o software funcionando

Periodicamente a equipe deve refletir sobre comose tornar mais efetivo

Profissionais motivados

Suporte s necessidades da equipe e ambientenecessrio para desenvolvimento das atividades

Confiana no trabalho da equipe

Alguns princpios

E j t il id l


35/101


O gerente de projeto concorda em prosseguir sem

que todos os requisitos estejam bem definidos

Os desenvolvedores concordam em prosseguir

sem ter todos os requisitos documentados

Os membros da equipe sabem que algum vaiajudar quando ocorrerem problemas

Em um projeto gil ideal...

E j t il id l


36/101


Os gerentes percebem que no precisam dizer

equipe o que fazer, ou garantir o que vai ser feito

A equipe percebe que ningum vai dizer o que

fazer, isto faz parte do trabalho da equipe

No existem mais a impresso de diviso (testersand programmers), todos so desenvolvedores

Em um projeto gil ideal...

M d d P t


37/101


Mudana de Postura

Equipe

Equipe

Equipe

Equipe

GP

Equipe

Equipe

Equipe

Equipe

GP

Tradicional gil

Cross-funcional

Auto-organizao

Enq nto i o n m p ojeto t di ion l


38/101


0. Levantamento de Requisitos

1. Anlise de Requisitos

2. Desenho da Arquitetura

3. Implementao

4. Testes

5. Produo / Manuteno

Enquanto isso, num projeto tradicional...

Premissas bsicas do modelo tradicional


39/101


necessrio fazer uma anlise de requisitos

profunda e detalhada antes de projetar aarquitetura do sistema

necessrio fazer um estudo minucioso eelaborar uma descrio detalhada da arquiteturaantes de comear a implement-la

necessrio testar o sistema completamenteantes de mandar a verso final para o cliente

Premissas bsicas do modelo tradicional

Cascata como uma bala de canho


40/101


Cascata como uma bala de canho

Iterativo e Incremental


41/101


Interface

Cliente

Servidor

BD

C

Iterativo = no espere ter tudo correto na primeira vezIncremental = construa em pedaos verticais (features) ao invs de horizontais (camadas)

Desenvolvimento monoltico

1

2

3

4

1

Desenvolvimento incremental

2 3

Talvez no sejanecessrio construiro resto

C

Interface

Cliente

Servidor

BD


Ref: Henrik Kniberg



42/101



Produto?

O que muda?


43/101


O que muda?

Custodamudana

Intensidadee stress

Tempo

Tempo Tempo

Entrega

de valor

TransparnciaEnvolvimento

do cliente

Tempo

Ref: Henrik Kniberg

Tradicional

gil


44/101


Metodologias geis souma tentativa de refinar

as metodologiasiterativas, tirando o foco

do processo em si e

dando mais nfase para acontribuio das pessoas


45/101


Metodologias geis umafebre? Uma onda

passageira?

o incio de uma mudanana forma de trabalho...

Evitar incerteza x Gerenciar para incerteza


46/101


Evitar incerteza x Gerenciar para incerteza

Ref: Luiz Cludio Parzianello

O paradoxo da multitarefa


47/101


O paradoxo da multitarefa

Ref: Henrik Kniberg

Viso tradicional Tudo importante, vamos fazer tudo ao mesmo tempo!

Viso gil Prioriza e foca naquilo que mais importante!

Jan Feb Mar Abr Mai Jun Jul

A3A2A1 B3B2B1 C3C2C1

Jan Feb Mar Abr Mai Jun Jul

A B C

O que muda?


48/101


Mtodos tradicionais

O planejamento deve propiciar a preveno demudanas

Mtodos geis

A mudana incorporada ao escopo

Razes Necessidades de negcio

Novas oportunidades

Mudanas de legislao

Requisitos incompletos

O que muda?

E se fosse essa a realidade?


49/101


A atitude dos desenvolvedores de software seria

completamente diferente:

Tomaramos as grandes decises o mais tardepossvel

Implementaramos agora somente o queprecisamos agora

No implementaramos flexibilidade desnecessria(no anteciparamos necessidades)

E se fosse essa a realidade?

E essa a nova realidade (em muitos casos)


50/101


Orientao a Objetos: facilita e cria oportunidades

para mudanas

Tcnicas de Refatorao

Testes automatizados: nos do segurana quandofazemos mudanas

Prtica / cultura de mudanas: aprendemostcnicas e adquirimos experincia em lidar comcdigo mutante

E essa a nova realidade (em muitos casos)

Principais Mtodos geis


51/101


Adaptative Software Development (ASD)

Jim Highsmith

Crystal Clear (Crystal)

Alistar Cockburn

Extreme Programming (XP)

Kent Beck, Eric Gamma

Scrum

Ken Schwaber, Jeff Sutherland, Mark Beedle

Lean Software Development

Mary e Tom Poppendieck

Feature Driven Development (FDD) Peter Coad, Jeff DeLuca

Test Drive Development (TDD)

Kanban

Principais Mtodos geis

Mudana de perspectiva


52/101


Agile Project ManagementJim Highsmith, 2008

Agile Enterprise Framework

Governana e Portflio

Gerncia de Projeto

Gerncia de IteraesPrticas Tcnicas

ROI, Progresso,Risco, Investimento

Release, aquisio,PMBOK, externo

Interno, Scrum

XP, FDD, etc

Mudana de perspectiva

Mtodos geis funcionam?


53/101


1. David Rico (2008)

Survey de artigos acadmicos e cientficos publicados2. VersionOne (2008)

Survey online com mais de 3.000 pessoas

3. QSMA (Michael Mah 2008) Comparao rigorosa de 26 projetos geis com umabase de 7.500 projetos tradicionais

Equipes geis variando entre 26 e 1.000 pessoas

4. Dr. Dobbs Journal (2008) Survey online com 642 pessoas




54/101


Fonte: Mah 2008.

Agileprojects are16% moreproductive ata statisticallysignificantlevel of

confidence.




55/101


Satisfao no trabalho Aps 15 meses de adoo do Scrum, 86% dos colabroadores da

Salesforce.com estavam tendo um good time ou o best time

Apenas 40% disseram isto antes de adotar Scrum

92% recomendariam mtodos geis para outras pessoas

Time to Market VersionOne

64% disseram que o time to market melhorou

23% disseram que melhorou significativamente

Michael Mah Projetos geis tem um time to market 37% mais rpido com um

nvel de confiana estatisticamente significante




56/101


Fonte: Mah 2008.




57/101


Melhoria na satisfao dos stakeholders Dr. Dobbs

47% disseram que a satisfao foi somewhat higher

31% disseram que foi much higher

Version One

ImprovedSignificantly

Improved

Enhanced ability to manage changingpriorities

41% 51%

Improved project visibility 42% 41%Improved alignment of IT and businessgoals

39% 27%

Reduced project risk 48% 17%



58/101


5 motivos para

NO usar

mtodos geis?

Cinco Motivos para no usar Mtodos geis


59/101



Motivo 1

Eu sei e defino

todos os requisitosno incio do projeto

No preciso de ciclos iterativos

Qual projeto de software possui todos os

requisitos definidos (corretamente) no incio?



60/101



Motivo 2

Os objetivos do meuprojeto esto muito

claros desde o

incio

O cliente descobre o que quer ao longodo caminho



61/101


C co ot os pa a o usa todos ge s

Motivo 3

Meu projeto envolve

baixa incerteza

Qual projeto de software envolve baixaincerteza?



62/101


p g

Motivo 4

Minha estimativaest toda definida ecom ndice de erro

muito baixo

Em qual projeto de software consigo terestimativas precisas?



63/101


p g

Motivo 5

Meu processo

rgido e controlado(comando-controle)

As tarefas so delegadas, equipes ficamdesmotivadas mais facilmente

Qual equipe gosta de trabalhar desmotivada?



64/101


p g

Requisitos definidos desde o incioObjetivos claros desde o incio

Comando-controle

Baixa incertezaEstimativas precisas

Qual projeto de desenvolvimento desoftware possui estas caractersticas?

E os Cinco Motivos?


65/101


Requisitos definidos desde o incioObjetivos claros desde o incio

Comando-controle

Baixa incertezaEstimativas precisas

Qual projeto de desenvolvimento desoftware possui estas caractersticas?


66/101


SCRUM

Scrum - Jogada de Rugby


67/101


g g y

Quem usa Scrum?
http://upload.wikimedia.org/wikipedia/commons/9/98/Image-Rugby_Union_Scrum.jpg


68/101


Ref.:3rd Annual State of Agile Development Survey June-July 20083061 respondentes, 80 pases

Q

Como resolver


69/101


69

Requisit

os

Longe de um acordo

Perto de um acordo

TecnologiaPerto da certeza Longe da certeza

Simples

Complicado

Complexo

Anarquia

Ref. : Strategic Management and Organizational Dynamics byRalph Stacey, in Agile Software Development With Scrum byKen Schwaber and Mike Beedle.

Mesmo que oproduto sejacomplexo...

... Tente manteruma iterao

simples

Adaptativo


70/101


E

C D

A

Planejado

Tradicional

gil

Sem 1 Sem 2 Sem 3 Sem 4

B

C D

A


B


D

A


B


A B

nfase: processo emprico


71/101


Princpio Caractersticas desconhecidas

Prioridades devem ser consideradas Escopo ir mudar!

Essncia do SCRUM Inspeo

Verificar o que foi feito no perodo

Adaptao Melhorar o processo

Planejar Planejar o sprint

Desenvolver Realizar o sprint

Inspecionar (check) Sprint review e retrospectiva

Adaptar Lies para o prximo planejamento

PLAN

DO

ACT

CHECK

O Framework do Scrum


72/101


Planejamento e preparao


73/101


Product Owner e Cliente

Viso do produto

Requisitos funcionais e no funcionais

Restries e User stories (prtica do XP)

Criao doproduct backlog

Conjunto de funcionalidades do sistema

Priorizao das funcionalidades

Preparao da base necessria para o desenvolvimeto

Mecanismos de comunicao e coordenao

Formao das equipes

User Stories


74/101


User stories Identificao de atores envolvidos

Como um [papel do usurio]quero [funcionalidade]para [valor de negcio]

I.N.V.E.S.T. (independente, negocivel, valorizvel, estimvel, small etestvel)

Quebrar grandes e juntar pequenas

Definio do conceito de DONE (testes)

Diferentes perspectivas

Prioridades das user stories

Valor entre 1 e 150? Must have Should have

Could have

Desenvolvimento


75/101


Product Owner, ScrumMaster e Equipe

Anlise e organizao do Product Backlog

Refinamento das funcionalidades

Estimativas

Escolha das funcionalidades para o sprint

Formalizao do sprint backlog

Identificao das tarefas Organizao da taskboard

2-4 hs 2-4 hs

Desenvolvimento


76/101


Estimativas Tempo e/ou complexidade?

Fibonacci

1, 2, 3, 5, 8, 13, 21

Planning poker

As duas estratgias de uso deplanning poker

Jogar as cartas para cada estria Colocar cada estria embaixo de uma carta

Algumas prticas utilizadas:

Pontos para funcionalidades e horas para tarefas

1-day tasks (mximo 2 e mnimo 1/2)

Considerar tarefas como teste, pesquisas, documentao, etc.

Desenvolvimento


77/101


Tempo ou Complexidade

4 pessoas trabalhando 4 semanas Equipe: 640 horas

2 junior, 2 senior

Produzem 25 pontos de complexidade

4 pessoas trabalhando 4 semanas

Equipe: 640 horas

4 senior

Produzem 60 pontos de complexidade

Planning poker


78/101


1Muito pequeno! 2 3 5

8 13 21 40

JFrias!

LMais detalhes! Nem idia!

Intervalo!

Planning poker


79/101


Planning Poker na PRTICA!

Avaliar distncia entre

Argentina e Monglia

Chile e Itlia

Japo e Austrlia

ndia e Alemanha

EUA e Rssia

Ucrnia e China

Priorizao e classificao do backlog


80/101


VALOR

COMPLEXIDADEAltaBaixa

Alta

Baixa

UStory1

UStory2

UStory3

UStory4

Calibrando a velocidade


81/101


40 3030 2830 3130 30

Estimado Realizado

40 3040 3040 30

40 3050 3060 30

40 3535 3030 25

302520

Estimado Realizado

Estimado Realizado Estimado Realizado

Calibrando a velocidade


82/101


Incio da sprint

8

5

3

5

5

5

3

5

5

8

Backlogdo produto

8

5

3

5

5

Backlogda sprint

Final da sprint

8

5

3

5

5

Feito!

Feito!

Feito!Quase

Nem iniciamos

Velocidadereal =

18

Backlogda sprint

Velocidade

estimada =26

Dividindo user stories


83/101


Administrateusers

Register newuser

Edit existinguser

Delete user

Find user

100 simultaneoususers

Operationsmanual

As a helpdeskoperator I want to see

who is logged in

View Invoice in

HTML, PDF, orExcel format


Operationsmanual

As a helpdeskoperator I want tosee who is logged

in

View Invoice inHTML, PDF, orExcel format

Register newuser

Edit existinguser

Delete user

Find user


Operations

manual

As a helpdesk

operator I want to seewho is logged in

View Invoice inHTML, PDF, orExcel format

Dividindo user stories


84/101


Administrateusers

Register newuser

Edit existinguser

Delete user

Find user

User admin

User admin

User admin

User admin

Do GUIdesign

Write failingtest

Do integrationtest

Create DBschema

Write server-side logic

Write formvalidation

Dividir

Quebrar em tarefas durante a reunio de sprint planning

13

5

3

8

2

Ref: Henrik Kniberg

Como priorizaritens do backlog?

Como planejaras tarefas?

Desenvolvimento


85/101


ScrumMaster e Equipe

Dia-a-dia do SCRUM

Sprint 2 semanas a 4 semanas

Daily meetings (Daily Scrum)

Impedimentos Obstculos ao trabalho da equipe

Manter a taskboard

Burndown

Tarefas e estimativas

Tarefas no-planejadas

O Grfico de Burndown


86/101


5

10

15

20

Trabalho queresta na sprint

(pontos de userstory)

Dias da sprint

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Grfico de Burndown de uma Sprint de duas semanas

Vamos terminar antes



87/101


5

10

15

20



Dias da sprint

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16


No vamosconseguir cumprir

a meta desta sprint



88/101


5

10

15

20



Dias da sprint

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

No estamos atualizandoo grfico de burndown




89/101


100

200

300

400

Trabalho queresta no projeto(pontos de user

story)

Nro de sprints

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

O projeto vai terminarentre os sprints 14 e 16

Grfico de Burndown da release ou do projeto

Desenvolvimento


90/101


Daily Meetings (Daily Scrum)

Reunio diria de 15 minutos

Mantm equipe informada e integrada O que voc fez ontem?

O que pretende fazer para amanh?

Quais so seus impedimentos?

Questes tcnicas

No final da reunio

No se resolve problema, apenas se identifica

Desenvolvimento


91/101


Para ajudar na execuo (taskboard)

Sprint review


92/101


Cliente, PO, SM e Team

Apresentao do produto

Foco no QUE foi feito e no COMO foi feito

Aceite formal e feedback do cliente

Melhoria na forma de priorizao?

Prximo sprint


93/101


Lies aprendidas

Alimentam o prximo sprint

Velocidade da equipe

Erros x acertos

Previsto x realizado

Fator de foco da equipe

Repositrio de lies

Disseminao na empresa

Usar parte do sprint anterior para planejar oprximo sprint

Lies aprendidas

Fluxo do Scrum


94/101


Cancel

Gift wrap

Return

Sprint2-4 semanas

???Objetivo do Sprint

Backlog daSprint

Produto a serentregue

(ou seu incremento)

Backlogdo produto

CuponsEmbrulho

Cupons

Cancelar

24 horas

Sprint Planning 1 Sprint Planning 2

Dai ly Scrum

Sprint Review Retrospect iva


95/101


XP

Dinmica


96/101


Lembram disto?

Como Mtodosgeis podem

ajudar aresolver ouminimizar os

motivos defracassoidentificados?

Grupo 2

Grupo n

Grupo 1

Grupo 3

Sucesso Fracasso

Ref: Henrik Kniberg

Concluses


97/101


Quando temos problema em cronograma, modelostradicionais cortam testes, modelos geis cortam histrias.Um reduz a qualidade, o outro reduz o escopo.

A questo no documentar, entender.

No existem melhores prticas. Existem boas prticas paradeterminadas situaes.

Entregue hoje. Adapte amanh.

Adaptao uma resposta mudana.

Equipes auto-gerenciveis no so equipes sem liderana,

so equipes com outro estilo de liderana. Uso de tcnicas como Refatorao, Testes, Modelagem

gil so fundamentais para constante mudana do cdigo

Plans are nothing; Planning is everything


98/101


twitter.com/danicukitwitter.com/rafaelpri

Dinmica


99/101


Analista Projetista Programador Testador Cliente


Dinmica


100/101



Pequenos Lotes

Grandes Lotes

Dinmica


101/101

Qual o arranjo logstico mais rpido?

Qual equipe apresentou o maior esforo por projeto?

Quais as vantagens de cada abordagem?

Quais as desvantagens de cada abordagem?

Qual a justificativa para manter os grandes lotes?

Métodos_Àgeis_-_CBSoft

Documents

Transcript of Métodos_Àgeis_-_CBSoft