Métodos Àgeis - CBSoft

Introduo a Mtodos geis de Desenvolvimento de Software
Daniel Cukier (AgilCoop) twitter.com/danicuki Prof. Dr. Rafael Prikladnicki (PUCRS) twitter.com/rafaelpri
CBSoft Salvador Bahia Setembro de 2010
Quem usa Scrum e XP?
EUA
BR
2 anos!
Daniel Cukier
15 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 Computao IME/USP (2009) Palestra em vrios eventos
Encontro 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
Contexto e experincia na AgilCoop Cursos de graduao em XP desde 2001 Apresentaes

SBES, SUCESU, SEPAI, SEBRAE, etc. Arquivos disponveis: www.agilcoop.org.br
Assessorias em mtodos geis Artigos cientficos
Dissertaes de Mestrado
Rafael Prikladnicki
Professor da FACIN PUCRS desde 2004 www.inf.pucrs.br/~rafael Coordenador de Gesto de Projetos da AGT/PUCRS Professor 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 Computao PUCRS (2003)
Doutor em Cincia da Computao PUCRS (2009)

reas de atuao acadmica e profissional:
Desenvolvimento Distribudo de Software Gerncia de Projetos Melhoria de Processo de Software Engenharia de Software Experimental Lean e Mtodos geis para Desenvolvimento de Software
Contexto e experincia na PUCRS
www.inf.pucrs.br/munddos
Criado em 2001 Registrado no CNPq em 2004 Livros publicados em 2007, 2009 e 2010 2 pesquisadores
Formou 11 mestres, 1 doutor

Possui 6 mestrandos, 2 doutorandos
www.inf.pucrs.br/munddos
Implantao de prticas de DDS nas empresas
Desenvolvimento de ferramentas para apoiar DDS

Integrao de DDS com mtodos geis Estudo 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
Agenda
Introduo e motivao
O que so Mtodos geis?

Princpios
Problemas com abordagens tradicionais

Alguns mtodos geis
Concluso
Dinmica
Por que teu projeto termina com sucesso? Por que teu projeto fracassa?
Sucesso
Fracasso
Grupo 2
Grupo 1
Discusso em grupo
15 minutos Agrupar problemas e fracassos em categorias
Grupo 3
Grupo n
Ref: Henrik Kniberg
Motivao
Motivao
Como ganhar dinheiro resolvendo problemas que voce no conhece, com pessoas desconhecidas, em um tempo curto e com poucos recursos (e se divertindo)?
Quantos avies 10 pessoas produzem em 10 minutos?
Tenho como produzir 100 avies em 10 minutos? Tenho, mas:

- Vou verificar tudo ao final - Posso ter baixa qualidade - Posso ter retrabalho - Posso no ter entendido o escopo
Ento por que deixar tudo para o final?
Quantos avies 10 pessoas produzem em 10 minutos?
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?
Motivao
300
250
200
Avies restantes 150
100
50
0 Objetivo Sprint 1 Sprint 2 Sprints Sprint 3 Sprint 4 Sprint 5
Motivao
Grfico de Burndown
250
200
150 Avies restantes
100
50
0 Objetivo Sprint 1 Sprint 2 Sprints Sprint 3 Sprint 4 Sprint 5
Novos ventos no desenvolvimento de software
Sociedade demanda
grande 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
Relatrio do Chaos (Chaos Report)
Resultado dos projetos em 2004
Relatrio do Chaos (Chaos Report)
Resultado dos projetos em 2004

1994
Projetos no concludos ------------ 31%
2004
Projetos no concludos ------- 18%
Projetos bem sucedidos ----- 16%

Estouro mdio de custo -----------------------> 180% Estouro mdio de prazo -----------------------> 164%
Projetos bem sucedidos ----------- 29%

Estouro mdio de custo ----------------- 56% Estouro mdio de prazo ------------------------- 84%
Evitar desperdcio
Estudo do The Standish Group conclui (Chaos Report): Pesquisa sobre a utilizao das funcionalidades do software ...
Mais de 64% de um sistema de software quase nunca no utilizado!

Problemas
Com mtodos tradicionais/clssicos de desenvolvimento Supem que possvel 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 Com software Grande quantidade de erros Falta de flexibilidade
Como resolver o impasse?
Melhores Tecnologias
Padres de Projeto (reutilizao de idias) Componentes (reutilizao de cdigo) Middleware/frameworks (aumenta a bstrao)
Melhores Metodologias
Mtodos geis (o foco deste mini-curso) outras... (abordados em outros cursos de ES)
O que desenvolvimento de software?

Por Alistair Cockburn:
Modelagem Engenharia
(Jacobson) (Meyer)
Disciplina
Poesia Artesanato Arte
(Humphreys)
(Cockburn) (Knuth) (Gabriel)
Erro comum: olhar para software como apenas um desses itens e ignorar os demais
O que so mtodos geis?
Agile is not a set of practices, but a core set of beliefs and principles
Jim Highsmith
Princpios
Retorno de investimento Inovao Melhoria de processo Pessoas Cultura Comunicao Adaptao x Antecipao
Histrico
Movimento iniciado por programadores experientes e consultores em desenvolvimento de software. Questionam e se opem a uma srie de mitos e prticas adotadas em abordagens tradicionais de Engenharia de Software e Gerncia de Projetos. Manifesto gil: Assinado por 17 desenvolvedores em Utah em fevereiro/2001. http://agilemanifesto.org
Agile Manifesto (2001)

Indivduos e interaes
Processos e ferramentas Documentao abrangente Negociao de contrato Plano pr-estabelecido
James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas
Software funcionando
Colaborao do cliente
mais importante que
Resposta s mudanas
Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler
http://agilemanifesto.org
Alguns princpios O mais importante o software funcionando Periodicamente a equipe deve refletir sobre como se tornar mais efetivo Profissionais motivados Suporte s necessidades da equipe e ambiente necessrio para desenvolvimento das atividades Confiana no trabalho da equipe
Em um projeto gil ideal...
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 vai ajudar quando ocorrerem problemas
Em um projeto gil ideal...
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 (testers and programmers), todos so desenvolvedores
Mudana de Postura Tradicional

Equipe
gil
Equipe
Equipe
GP
Equipe
Equipe
Equipe
Equipe
GP
Equipe
Cross-funcional Auto-organizao
Enquanto isso, num projeto tradicional... 0. Levantamento de Requisitos 1. Anlise de Requisitos 2. Desenho da Arquitetura 3. Implementao
4. Testes
5. Produo / Manuteno
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
Cascata como uma bala de canho
Iterativo e Incremental
Iterativo = no espere ter tudo correto na primeira vez Incremental =construaempedaosverticais(features) ao invs de horizontais (camadas)
Desenvolvimento monoltico
Desenvolvimento incremental
C
1 4 Interface Interface Cliente Servidor BD
C
2 3
3 2
Cliente Servidor 1 BD
Talvez no seja necessrio construir o resto
Ref: Henrik Kniberg

Iterativo e Incremental
Produto?
O que muda?
Custo da mudana
Intensidade e stress
Tempo
Tempo
Entrega de valor
Transparncia Envolvimento do cliente
Tempo
gil Tradicional
Tempo
Ref: Henrik Kniberg
Metodologias geis so uma tentativa de refinar as metodologias iterativas, tirando o foco do processo em si e dando mais nfase para a contribuio das pessoas
Metodologias geis uma febre? Uma onda passageira? o incio de uma mudana na forma de trabalho...
Evitar incerteza x Gerenciar para incerteza
Ref: Luiz Cludio Parzianello
O paradoxo da multitarefa
Viso tradicional
Tudoimportante,vamosfazertudoaomesmotempo!
A1
Jan
B1
Feb
C1
Mar
A2
B2
Abr
C2
Mai
A3
Jun
B3
Jul
C3
Viso gil
Priorizaefocanaquiloquemaisimportante!
A
Jan
Ref: Henrik Kniberg
B
Mar Abr Mai
C
Jun Jul
Feb
O que muda? Mtodos tradicionais

O planejamento deve propiciar a preveno de mudanas
Mtodos geis
A mudana incorporada ao escopo
Razes
Necessidades de negcio
Novas oportunidades
Mudanas de legislao Requisitos incompletos
E se fosse essa a realidade?
A atitude dos desenvolvedores de software seria completamente diferente:
Tomaramos as grandes decises o mais tarde possvel Implementaramos agora somente o que precisamos agora No implementaramos flexibilidade desnecessria (no anteciparamos necessidades)
E essa a nova realidade (em muitos casos) Orientao a Objetos: facilita e cria oportunidades para mudanas Tcnicas de Refatorao
Testes automatizados: nos do segurana quando fazemos mudanas Prtica / cultura de mudanas: aprendemos tcnicas e adquirimos experincia em lidar com cdigo mutante
Principais Mtodos geis

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

Mudana de perspectiva
Agile Project Management Jim Highsmith, 2008 Agile Enterprise Framework
ROI, Progresso, Risco, Investimento

Release, aquisio, PMBOK, externo Interno, Scrum
Governana e Portflio Gerncia de Projeto Gerncia de Iteraes
XP, FDD, etc
Prticas Tcnicas
Mtodos geis funcionam? 1. David Rico (2008)

Survey de artigos acadmicos e cientficos publicados
2. VersionOne (2008)
Survey online com mais de 3.000 pessoas
3. QSMA (Michael Mah 2008)

Comparao rigorosa de 26 projetos geis com uma basede7.500projetostradicionais Equipes geis variando entre 26 e 1.000 pessoas
4.Dr.DobbsJournal(2008)
Survey online com 642 pessoas
Mtodos geis funcionam?
Agile projects are 16% more productive at a statistically significant level of confidence.
Fonte: Mah 2008.

Satisfao no trabalho
Aps 15 meses de adoo do Scrum, 86% dos colabroadores da Salesforce.comestavamtendoumgoodtimeouobesttime 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
Fonte: Mah 2008.


Melhoria na satisfao dos stakeholders
Dr.Dobbs 47%disseramqueasatisfaofoisomewhat higher 31%disseramquefoimuch higher Version One
Significantly Improved 51% 41% 27% 17%
Improved Enhanced ability to manage changing priorities Improved project visibility Improved alignment of IT and business goals Reduced project risk
41% 42% 39% 48%
5 motivos para NO usar mtodos geis?

Cinco Motivos para no usar Mtodos geis
Motivo 1
No preciso de ciclos iterativos
Qual projeto de software possui todos os requisitos definidos (corretamente) no incio?
Eu sei e defino todos os requisitos no incio do projeto

Motivo 2
O cliente descobre o que quer ao longo do caminho
Os objetivos do meu projeto esto muito claros desde o incio

Motivo 3
Qual projeto de software envolve baixa incerteza?
Meu projeto envolve baixa incerteza

Motivo 4
Em qual projeto de software consigo ter estimativas precisas?
Minha estimativa est toda definida e com ndice de erro muito baixo
Motivo 5
As tarefas so delegadas, equipes ficam desmotivadas mais facilmente Qual equipe gosta de trabalhar desmotivada?
Meu processo rgido e controlado (comando-controle)

Requisitos definidos desde o incio Objetivos claros desde o incio Comando-controle Baixa incerteza Estimativas precisas
Qual projeto de desenvolvimento de software possui estas caractersticas?

E os Cinco Motivos?
Requisitos definidos desde o incio Objetivos claros desde o incio Comando-controle Baixa incerteza Estimativas precisas
Qual projeto de desenvolvimento de software possui estas caractersticas?

SCRUM
Scrum - Jogada de Rugby
Quem usa Scrum?
Ref.: 3rd Annual State of Agile Development Survey June-July 2008 3061 respondentes, 80 pases
Como resolver
Longe de um acordo
Mesmo que o produto seja complexo...
Anarquia
Requisitos
Complexo
Complicado
... Tente manter uma iterao simples
Perto de um acordo
Simples
Perto da certeza
Tecnologia
Longe da certeza
Ref. : Strategic Management and Organizational Dynamics by Ralph Stacey, in Agile Software Development With Scrum by Ken Schwaber and Mike Beedle.
69
Adaptativo
A B
Planejado
Sem 1 Sem 2 Sem 3 Sem 4
C D
Tradicional
A B C D
Sem 1
Sem 2
Sem 3
Sem 4
Sem 5
Sem 6
Sem 7
Sem 8
gil
A B
A B E Sem 6 Sem 7 Sem 8 D
Sem 1
Sem 2
Sem 3
Sem 4
Sem 5
nfase: processo emprico

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
ACT
PLAN
Planejar
Planejar o sprint
Desenvolver
Realizar o sprint
CHECK
DO
Inspecionar (check)
Sprint review e retrospectiva
Adaptar
Lies para o prximo planejamento
O Framework do Scrum
Planejamento e preparao
Product Owner e Cliente Viso do produto
Requisitos funcionais e no funcionais Restries e User stories (prtica do XP)
Criao do product 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
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 e testvel)
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
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
Estimativas
Tempo e/ou complexidade? Fibonacci
1,2,3,5,8,13,21
Planning poker
As duas estratgias de uso de planning 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
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
1
Muito pequeno!
8
Frias!
13 21 40
Mais detalhes! Nem idia! Intervalo!
J L
Planning poker
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
VALOR
UStory1
Alta
UStory2
UStory4 Baixa UStory3
Baixa
Alta
COMPLEXIDADE
Calibrando a velocidade
Estimado Realizado
Estimado
Realizado
40 30 30 30
Estimado
30 28 31 30
Realizado
40 40 40
Estimado
30 30 30
Realizado
40 50 60
30 30 30
30 40 25 35 20 30
35 30 25
Calibrando a velocidade
Incio da sprint
Backlog do produto
Final da sprint
Backlog da sprint
Feito! Velocidade estimada = Feito!
Backlog da sprint
8
5
5
3
8
5
5
3
8
5
5
3
Velocidade real =
18
26
Feito! Quase
Nem iniciamos
5 5
8
5
3
Dividindo user stories

Register new user Edit existing user Register new user Edit existing user
View Invoice in HTML, PDF, or Excel format
As a helpdesk operator I want to see who is logged in
Administrate users
View Invoice in HTML, PDF, or Excel format
As a helpdesk operator I want to see who is logged in
Find user
Delete user
View Invoice in HTML, PDF, or Excel format As a helpdesk operator I want to see who is logged in
Find user Operations manual

100 simultaneous users
Operations manual
Operations manual
Delete user
Dividindo user stories

Quebrar em tarefas durante a reunio de sprint planning
Dividir
User admin
Register new user

User admin
Write failing test
Create DB schema
Write form validation
Do GUI design
Write serverside logic
Do integration test
Find user Administrate users
13
User admin
2 Edit existing
user
Como priorizar itens do backlog? Como planejar as tarefas?
User admin
Delete user
Ref: Henrik Kniberg
Desenvolvimento
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
Grfico de Burndown de uma Sprint de duas semanas
20
Trabalho que resta na sprint (pontos de user story)
15
10
Vamos terminar antes
10
11
12
13
14
15
16
Dias da sprint
20
15
10
No vamos conseguir cumprir a meta desta sprint

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Dias da sprint
20
15
10
No estamos atualizando o grfico de burndown
10
11
12
13
14
15
16
Dias da sprint
Grfico de Burndown da release ou do projeto

400
Trabalho que resta no projeto (pontos de user story)
O projeto vai terminar entre os sprints 14 e 16
300
200
100
10
11
12
13
14
15
16
Nro de sprints
Desenvolvimento
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
Para ajudar na execuo (taskboard)
Sprint review
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
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 o prximo sprint
Lies aprendidas
Fluxo do Scrum
24 horas
Daily Scrum
Objetivo do Sprint ??? Backlog da Sprint Cancelar Return Gift wrap Cupons Cancel Embrulho Backlog do produto
Sprint Planning 1
Sprint 2-4 semanas
Sprint Review
Retrospectiva
Sprint Planning 2
Produto a ser entregue (ou seu incremento)
Cupons
XP
Dinmica
Lembram disto? Como Mtodos geis podem ajudar a resolver ou minimizar os motivos de fracasso identificados?
Sucesso
Fracasso
Grupo 2
Grupo 1
Grupo n Grupo 3
Ref: Henrik Kniberg
Concluses
Quando temos problema em cronograma, modelos tradicionais 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 para determinadas 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
twitter.com/danicuki twitter.com/rafaelpri
Dinmica
Analista
Projetista
Programador
Testador
Cliente

Dinmica Pequenos Lotes
Grandes Lotes


Dinmica
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

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Métodos Àgeis - CBSoft

Enviado por

Direitos autorais:

Formatos disponíveis

Introduo a Mtodos geis de Desenvolvimento de Software

CBSoft Salvador Bahia Setembro de 2010

Quem usa Scrum e XP?

CBSoft Salvador Bahia Setembro de 2010

Quem usa Scrum e XP?

CBSoft Salvador Bahia Setembro de 2010

Quem usa Scrum e XP?

CBSoft Salvador Bahia Setembro de 2010

Quem usa Scrum e XP?

CBSoft Salvador Bahia Setembro de 2010

Quem usa Scrum e XP?

CBSoft Salvador Bahia Setembro de 2010

Quem usa Scrum e XP?

CBSoft Salvador Bahia Setembro de 2010

CBSoft Salvador Bahia Setembro de 2010

3 anos como gerente de Desenvolvimento na Locaweb

reas de atuao acadmica e profissional:

Outras no menos importantes:

Contexto e experincia na AgilCoop Cursos de graduao em XP desde 2001 Apresentaes

Assessorias em mtodos geis Artigos cientficos

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

Doutor em Cincia da Computao PUCRS (2009)

Contexto e experincia na PUCRS

Formou 11 mestres, 1 doutor

Contexto e experincia na PUCRS

Implantao de prticas de DDS nas empresas

Desenvolvimento de ferramentas para apoiar DDS

Contexto e experincia na PUCRS

CBSoft Salvador Bahia Setembro de 2010

O que so Mtodos geis?

Problemas com abordagens tradicionais

CBSoft Salvador Bahia Setembro de 2010

Ref: Henrik Kniberg

CBSoft Salvador Bahia Setembro de 2010

CBSoft Salvador Bahia Setembro de 2010

Quantos avies 10 pessoas produzem em 10 minutos?

Tenho como produzir 100 avies em 10 minutos? Tenho, mas:

Ento por que deixar tudo para o final?

CBSoft Salvador Bahia Setembro de 2010

Quantos avies 10 pessoas produzem em 10 minutos?

Tenho como produzir 100 avies em 10 minutos?

Avies restantes 150

0 Objetivo Sprint 1 Sprint 2 Sprints Sprint 3 Sprint 4 Sprint 5

CBSoft Salvador Bahia Setembro de 2010

150 Avies restantes

0 Objetivo Sprint 1 Sprint 2 Sprints Sprint 3 Sprint 4 Sprint 5

CBSoft Salvador Bahia Setembro de 2010

Novos ventos no desenvolvimento de software

ano, todo ms,

Relatrio do Chaos (Chaos Report)

Resultado dos projetos em 2004

CBSoft Salvador Bahia Setembro de 2010

Relatrio do Chaos (Chaos Report)

Resultado dos projetos em 2004

Projetos bem sucedidos ----- 16%

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

CBSoft Salvador Bahia Setembro de 2010

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

Como resolver o impasse?

CBSoft Salvador Bahia Setembro de 2010

O que desenvolvimento de software?

O que so mtodos geis?

Agile Manifesto (2001)