Agile                Eric Cavalcanti        ecavalcanti@gmail.com                      @ericoc
O Problema            Chaos Report             18%     2004                               53%                     29%     ...
Principais fatores de     insucesso          requisitos incompletos          falta de envolvimento          de usuários   ...
Como resolver?
Abordagem Tradicional
BDUF Big Design Up Front
Analista de Requisitos, Analista de Negócios,Engenheiro de Requisitos, Engenheiro de Qualidade,   Gerente de Configuração, ...
Processo!!
Ainda assim...
Ainda mais...Código Complexo.Manutenção difícil.Baixa produtividade.Cronograma sempre atrasado.Insatisfação de todos.Desig...
Por quê?
Previsibilidade
O desenvolvimento de software dependemuito mais das pessoas e da comunicação
“Ao contrário do cenário numa linha deprodução em massa, o software não é algoprevisível ou imune a mudanças”             ...
“Desenvolver software é como desenvolver novos produtos”                      Larman
“Desenvolver é como criar uma receita,enquanto produzir é seguir a receita”Poppendieck
“O desenvolvimento é um processo deaprendizado, que envolve tentativa e erros”                                       Larman
“Como a manufatura previsível, não pode ser comparada aosoftware, dificilmente as práticas e valores enraizados nesseparadi...
64% das funcionalidadesdesenvolvidas nos softwaresnão são utilizadasStandish Group
Muitas vezes, pelo fato do clientesó poder pedir uma vez, eleacaba pedindo coisas que não  tem certeza que precisa
Essas funcionalidadesfazem parte dos64% que ele nemrepara que estão lá,quando o software éentregue
70%         dos usuários utilizam asfuncionalidades básicas de um software.20%         utilizam as funcionalidadesintermed...
Cone da Incerteza                    Construx
É natural que osusuários tenham novas idéias e suas opiniões mudem quando vêem  as primeiras versões           do software
Os softwares mais famosose utilizados no mundo sãoos mais simples
“Menos é Mais”  A cabeça de Steve Jobs (Inside Steve’s Brain) - Agir 2008
DANIEL COOK
Abordagem Ágil
Final da década de 90 eXtreme Programming Feature Driven Development Scrum Adaptive Development Crystal Clear Dynamic Syst...
2001Kent Beck           Ron JeffriesMike Beedle         Jon KernArie van            Brian MarickBennekum            Robert...
Indivíduos e interação entre eles   mais que processos e ferramentas
Software em funcionamentomais que documentação abrangente
Colaboração com o clientemais que negociação de contratos
Responder a mudanças maisque seguir um plano
Princípios por trás do         manifesto ágil
Nossa maior prioridade ésatisfazer o cliente, atravésda entrega adiantada econtínua de software devalor
Aceitar mudanças de requisitos,mesmo no fim do desenvolvimento
Processos ágeis se adequam a mudanças, para que o cliente        possa tirar vantagens                 competitivas
Entregar software       funcionando com frequencia, na escala desemanas até meses, com         preferência aos   períodos ...
Pessoas relacionadas à negócios e desenvolvedoresdevem trabalhar em conjunto e diariamente,durante todo o curso do projeto
Construir projetos ao redor de  indivíduos motivados. Dando a eles oambiente e suporte necessário, e confiar               ...
O método mais eficiente e eficaz detransmitir informações é através de umaconversa cara a cara.
Softwarefuncional é amedida primáriade progresso.
Processos ágeis promovem um ambientesustentável. Os patrocinadores, desenvolvedorese usuários, devem ser capazes de manter...
Contínua atenção à excelênciatécnica e bom design, aumentaa agilidade.
Simplicidade: a arte demaximizar a quantidade detrabalho que não precisouser feito
As melhores arquiteturas,requisitos e designs emergem   de times auto-organizáveis
Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam                 seu comport...
Por que adotarabordagens ágeis?
STATE OFAGILE SURVEY2011    6.042 participantes                          VersionOne
STATE OFAGILE SURVEY2011  >80%                       90%      trabalham em        são pelo menos"esclarecido"  organizaçõe...
STATE OFAGILE SURVEY2011      45%      utilizam abordagem               ágil a mais de 2 anos                             ...
STATE OFAGILE SURVEY2011     Scrum e variantes de Scrum                são de longe os mais utilizados                    ...
STATE OFAGILE SURVEY2011               As razões mais comuns para a adoção ágil gira em torno de   tempo de aceleração par...
STATE OFAGILE SURVEY2011Princípios fundamentais ágeis atualmente em uso são Daily Standup, Iteration  Planning e Unit Test...
O Scrum
A origem  1995  Jeff Sutherland  Ken Schwaber                    1986
Se destaca dos demais métodos ágeis pelaênfase dada ao gerenciamento do projeto
Práticas de Engenharia                  de d              c lu         t in       No
Papéisdo Scrum
ProductProduct Owner   Determina a visão do produtoOwner                Define as funcionalidades                   Escolhe...
Pequenos (5 a 9 pessoas)         Desenvolve as funcionalidades                     Auto-organizável                     Au...
Scrum MasterLíder ServidorProtege o timeRemove impedimentosGuia do Scrum
Como funciona?
Então ao invés de um grande grupo gastandoum monte de tempo construindo uma grandecoisa, temos uma equipe pequena gastando...
Product Backlog Uma lista de coisas que  queremos que sejam       entregues
As funcionalidades sãogeralmente escritas em estórias de usuários.
Como um <perfil>,quero <funcionalidade>,para <valor de negócio>  Como um agente de viagens, quero reservar lugar,     para ...
O time estima o trabalhoassociado a cada estória.
As estórias são rankeadas em ordemde importância pelo product owner.
O product owner é o dono do    backlog do produto.
Team Velocity
Sprint Backlog
Executando a Sprint Sprint 1   Sprint 2   Sprint 3   Sprint 4   Sprint 5 Análise    Código      Testa            Análise  ...
Daily Scrum Meeting• O que você fez ontem?• O que você fará de hojepara amanhã?• Há algum impedimentoem seu caminho?      ...
Taskboard
Acompanhamento
Sprint Burndown
Sprint Review
Scrum Retrospective
Revisando...
Scrum of Scrums
Mude alguma coisa => Saiba como foi => Aprenda com isso         => Mude alguma coisa novamente. Falando de um modo        ...
Kanban
O Kanban é baseado numa idéia muito simples. As atividades em andamento devem ser limitadas. Algo    novo só deve ser inic...
O princípio do Kanban é que você inicia com o que              estiver fazendo agora.
Como Funciona?
Visualize o fluxo de trabalho             Divida o trabalho em partes,             escreva cada item em um cartão e        ...
Limite o trabalho em progresso (WIP- work in progress)Associe limites explícitos para quantos itens podemestar em progress...
Acompanhe o tempo de execução datarefaTempo médio para completar um item, algumas vezeschamado de “Lead Time”Otimize o pro...
ReferênciasLean Software Development: An Agile Toolkit, Mary Poppendieck e Tom Poppendieck, 2003, Addison-Wesley Professio...
Obrigado!              Eric Cavalcanti      ecavalcanti@gmail.com                    @ericoc
Agile
Agile
Agile
Agile
Agile
Próximos SlideShares
Carregando em…5
×

Agile

913 visualizações

Publicada em

Slides apresentados na disciplina in0953.2012 do Professor Silvio Meira

Publicada em: Tecnologia
0 comentários
2 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
913
No SlideShare
0
A partir de incorporações
0
Número de incorporações
7
Ações
Compartilhamentos
0
Downloads
37
Comentários
0
Gostaram
2
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Agile

  1. 1. Agile Eric Cavalcanti ecavalcanti@gmail.com @ericoc
  2. 2. O Problema Chaos Report 18% 2004 53% 29% 19% 2006 46% Fracassados 35% Comprometidos Bem sucedidos 24% 2009 44% 32% !"#$%&(")&*%+,-."/0$12""
  3. 3. Principais fatores de insucesso requisitos incompletos falta de envolvimento de usuários mudanças de requisitos e especificações falta de apoio de negócios falta de recursos
  4. 4. Como resolver?
  5. 5. Abordagem Tradicional
  6. 6. BDUF Big Design Up Front
  7. 7. Analista de Requisitos, Analista de Negócios,Engenheiro de Requisitos, Engenheiro de Qualidade, Gerente de Configuração, Líder de Projeto... Programadores
  8. 8. Processo!!
  9. 9. Ainda assim...
  10. 10. Ainda mais...Código Complexo.Manutenção difícil.Baixa produtividade.Cronograma sempre atrasado.Insatisfação de todos.Design degradado.Documentação defasada, excessiva e ilegível.Fracasso em grande parte dos projetos.
  11. 11. Por quê?
  12. 12. Previsibilidade
  13. 13. O desenvolvimento de software dependemuito mais das pessoas e da comunicação
  14. 14. “Ao contrário do cenário numa linha deprodução em massa, o software não é algoprevisível ou imune a mudanças” Larman
  15. 15. “Desenvolver software é como desenvolver novos produtos” Larman
  16. 16. “Desenvolver é como criar uma receita,enquanto produzir é seguir a receita”Poppendieck
  17. 17. “O desenvolvimento é um processo deaprendizado, que envolve tentativa e erros” Larman
  18. 18. “Como a manufatura previsível, não pode ser comparada aosoftware, dificilmente as práticas e valores enraizados nesseparadigma trazem algum benefício” Larman
  19. 19. 64% das funcionalidadesdesenvolvidas nos softwaresnão são utilizadasStandish Group
  20. 20. Muitas vezes, pelo fato do clientesó poder pedir uma vez, eleacaba pedindo coisas que não tem certeza que precisa
  21. 21. Essas funcionalidadesfazem parte dos64% que ele nemrepara que estão lá,quando o software éentregue
  22. 22. 70% dos usuários utilizam asfuncionalidades básicas de um software.20% utilizam as funcionalidadesintermediárias.10% utilizam as funcionalidades avançadas.Microsoft
  23. 23. Cone da Incerteza Construx
  24. 24. É natural que osusuários tenham novas idéias e suas opiniões mudem quando vêem as primeiras versões do software
  25. 25. Os softwares mais famosose utilizados no mundo sãoos mais simples
  26. 26. “Menos é Mais” A cabeça de Steve Jobs (Inside Steve’s Brain) - Agir 2008
  27. 27. DANIEL COOK
  28. 28. Abordagem Ágil
  29. 29. Final da década de 90 eXtreme Programming Feature Driven Development Scrum Adaptive Development Crystal Clear Dynamic Systems Development Method
  30. 30. 2001Kent Beck Ron JeffriesMike Beedle Jon KernArie van Brian MarickBennekum Robert C. MartinAlistair Cockburn Steve MellorWard Cunningham Ken SchwaberMartin Fowler Jeff SutherlandJames Grenning Manifesto Ágil Dave ThomasJim HighsmithAndrew Hunt
  31. 31. Indivíduos e interação entre eles mais que processos e ferramentas
  32. 32. Software em funcionamentomais que documentação abrangente
  33. 33. Colaboração com o clientemais que negociação de contratos
  34. 34. Responder a mudanças maisque seguir um plano
  35. 35. Princípios por trás do manifesto ágil
  36. 36. Nossa maior prioridade ésatisfazer o cliente, atravésda entrega adiantada econtínua de software devalor
  37. 37. Aceitar mudanças de requisitos,mesmo no fim do desenvolvimento
  38. 38. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas
  39. 39. Entregar software funcionando com frequencia, na escala desemanas até meses, com preferência aos períodos mais curtos
  40. 40. Pessoas relacionadas à negócios e desenvolvedoresdevem trabalhar em conjunto e diariamente,durante todo o curso do projeto
  41. 41. Construir projetos ao redor de indivíduos motivados. Dando a eles oambiente e suporte necessário, e confiar que farão seu trabalho.
  42. 42. O método mais eficiente e eficaz detransmitir informações é através de umaconversa cara a cara.
  43. 43. Softwarefuncional é amedida primáriade progresso.
  44. 44. Processos ágeis promovem um ambientesustentável. Os patrocinadores, desenvolvedorese usuários, devem ser capazes de manterindefinidamente, passos constantes.
  45. 45. Contínua atenção à excelênciatécnica e bom design, aumentaa agilidade.
  46. 46. Simplicidade: a arte demaximizar a quantidade detrabalho que não precisouser feito
  47. 47. As melhores arquiteturas,requisitos e designs emergem de times auto-organizáveis
  48. 48. Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo
  49. 49. Por que adotarabordagens ágeis?
  50. 50. STATE OFAGILE SURVEY2011 6.042 participantes VersionOne
  51. 51. STATE OFAGILE SURVEY2011 >80% 90% trabalham em são pelo menos"esclarecido" organizações que usam sobre técnicas de práticas de desenvolvimento ágil de desenvolvimento ágil software em um certo grau VersionOne
  52. 52. STATE OFAGILE SURVEY2011 45% utilizam abordagem ágil a mais de 2 anos VersionOne
  53. 53. STATE OFAGILE SURVEY2011 Scrum e variantes de Scrum são de longe os mais utilizados VersionOne
  54. 54. STATE OFAGILE SURVEY2011 As razões mais comuns para a adoção ágil gira em torno de tempo de aceleração para o mercado, gereciamento de mudanças de prioridade e aumento produtividade VersionOne
  55. 55. STATE OFAGILE SURVEY2011Princípios fundamentais ágeis atualmente em uso são Daily Standup, Iteration Planning e Unit Testing. O mais notável é o uso crescente de Kanban (24%). VersionOne
  56. 56. O Scrum
  57. 57. A origem 1995 Jeff Sutherland Ken Schwaber 1986
  58. 58. Se destaca dos demais métodos ágeis pelaênfase dada ao gerenciamento do projeto
  59. 59. Práticas de Engenharia de d c lu t in No
  60. 60. Papéisdo Scrum
  61. 61. ProductProduct Owner Determina a visão do produtoOwner Define as funcionalidades Escolhe as datas de release Dá o feedback Gerencia os stakeholders Aceita ou rejeita os resultados Prioriza de acordo com o ROI
  62. 62. Pequenos (5 a 9 pessoas) Desenvolve as funcionalidades Auto-organizável Auto-gerenciável Multifuncional Estima o esforço Defina as tarefasO Time Responsável pela qualidade
  63. 63. Scrum MasterLíder ServidorProtege o timeRemove impedimentosGuia do Scrum
  64. 64. Como funciona?
  65. 65. Então ao invés de um grande grupo gastandoum monte de tempo construindo uma grandecoisa, temos uma equipe pequena gastando um tempo curto construindo uma pequena coisa.Mas integrando regularmente para ver o todo. Henrik Kniberg
  66. 66. Product Backlog Uma lista de coisas que queremos que sejam entregues
  67. 67. As funcionalidades sãogeralmente escritas em estórias de usuários.
  68. 68. Como um <perfil>,quero <funcionalidade>,para <valor de negócio> Como um agente de viagens, quero reservar lugar, para facilitar o atendimento dos clientes corporativos
  69. 69. O time estima o trabalhoassociado a cada estória.
  70. 70. As estórias são rankeadas em ordemde importância pelo product owner.
  71. 71. O product owner é o dono do backlog do produto.
  72. 72. Team Velocity
  73. 73. Sprint Backlog
  74. 74. Executando a Sprint Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Análise Código Testa Análise Código Testa Análise Código Testa Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Análise Análise Análise Código Código Código Testa Testa Testa
  75. 75. Daily Scrum Meeting• O que você fez ontem?• O que você fará de hojepara amanhã?• Há algum impedimentoem seu caminho? 15 minutos
  76. 76. Taskboard
  77. 77. Acompanhamento
  78. 78. Sprint Burndown
  79. 79. Sprint Review
  80. 80. Scrum Retrospective
  81. 81. Revisando...
  82. 82. Scrum of Scrums
  83. 83. Mude alguma coisa => Saiba como foi => Aprenda com isso => Mude alguma coisa novamente. Falando de um modo geral, você quer o ciclo de feedback o mais rápido possível,Scrum + XP e ciclos feedbackfeedback para que seja possa adaptar o processo rapidamente. Em Scrum, a iteração básica de um de é o sprint. Há mais, porém, especialmente se você combinar com o XP (eXtreme Programm ing): Quando feito corretamente, Scrum + XP lhe oferece vários ciclos de feedback extremamente valiosos.
  84. 84. Kanban
  85. 85. O Kanban é baseado numa idéia muito simples. As atividades em andamento devem ser limitadas. Algo novo só deve ser iniciado quando uma peça detrabalho existente é liberada ou quando uma função automática inicia isso.
  86. 86. O princípio do Kanban é que você inicia com o que estiver fazendo agora.
  87. 87. Como Funciona?
  88. 88. Visualize o fluxo de trabalho Divida o trabalho em partes, escreva cada item em um cartão e coloque na parede Use colunas nomeadas para ilustrar onde cada item está no fluxo de trabalho
  89. 89. Limite o trabalho em progresso (WIP- work in progress)Associe limites explícitos para quantos itens podemestar em progresso em cada estado do fluxo detrabalho
  90. 90. Acompanhe o tempo de execução datarefaTempo médio para completar um item, algumas vezeschamado de “Lead Time”Otimize o processo para tornar o tempo de execução omenor e mais previsível possível.
  91. 91. ReferênciasLean Software Development: An Agile Toolkit, Mary Poppendieck e Tom Poppendieck, 2003, Addison-Wesley ProfessionalAgile Project Management with Scrum, Ken Schwaber, 2004, Microsoft ProfessionalThe Enterprise and Scrum, Ken Schwaber, 2007, Microsoft PressKanban e Scrum - obtendo o melhor de ambos, Henrik Kniberg e Mattias Skarin, 2009, C3 Media Inc.Kanban: Mudança Evolucionária de Sucesso para seu Negócio de Tecnologia, David Anderson,2011, Blue Hole PressAgile Estimating and Planning, Mike Cohn, 2005, Prentice HallUser Stories Applied: For Agile Software Development, Mike Cohn, 2004, Addison-WesleyProfessionalExtreme Programming Explained: Embrace Change (2nd Edition), Kent Beck, 2004, Addison-WesleyProfessionalTest Driven Development, Kent Beck, 2002, Addison-Wesley ProfessionalRefactoring: Improving the Design of Existing Code, Martin Fowler, Kent Beck, 1999, Addison-WesleyProfessional
  92. 92. Obrigado! Eric Cavalcanti ecavalcanti@gmail.com @ericoc

×