Pedaços de XP, FDD,   Scrum e Kanban na  Análise de Negócio eEngenharia de Requisitos
Rafael Barbosa Camargo           @rafajagua      Analista de negócioswww.agilementoring.wordpress.com      www.caipiraagil...
O que é Análise de Negócio?       Você sabe?
Análise de Negócios                  Segundo o IIBA é:“A Análise de Negócios é o conjunto de atividades e técnicas utiliza...
O que é Engenharia de     Requisitos?   Você sabe?
Engenharia de RequisitosA engenharia de requisitos é um processo que engloba todas as atividades que contribuem    para a ...
Engenharia de Requisitos   Um Requisito consiste da definição  documentada de uma propriedade oucomportamento que um produ...
Análise de Negócios e  Engenharia TradicionalToda a análise era realizada no início             do projeto
Análise de Negócios Tradicional  Toda a análise era realizada no início               do projeto
Análise de Negócios Tradicional  Toda a análise era realizada no início               do projeto
Análise e Engenharia Tradicional              Concentra conhecimento                Reduz comunicação            Diminui a...
Aonde dói mais                     Priorização                     Drill Down              Visibilidade do Negócio        ...
O que é Ágil?  Você sabe?
Manifesto para o desenvolvimento ágil de software Estamos descobrindo maneiras melhores de desenvolver software fazendo-o ...
Transição para Scrum
Análise de Negócio Ágil     Vamos saber mais
Análise de Negócio Ágil
Engenharia de Requisitos Ágil
Product Backlog
OK, melhoramos a priorização e a definição  em conjunto sobre asporções de software a ser       desenvolvido
Mas não era suficientePrecisávamos de mais entendimento sobre aquilo       que seria desenvolvido na Iteração  Casos de us...
Introduzindo XP
User Stories
Accpetance Criteria            Viva       Compartilhada        Colaborativa
Planning Poker
OK, melhoramos o    entendimento, acomunicação e a validação  sobre o que temos de      desenvolver Também está melhor pra...
Mas não era suficiente Não tínhamos visão clara e fácil sobre o todoEm certas situações, precisávamos de uma visão   Macro...
Introduzindo FDD
FeatureModelo ARO para escrever nos Products Backlogs.         <ação> <resultado> <objeto>                  Exemplos:     ...
Feature Breakdown Structure              Visão
Feature Breakdown Structure
OK, temos uma visão de  negócio ao longo do        ProjetoEstá mais fácil para fazer  Grooming e Priorizar
Mas não era suficiente      Não tínhamos visão clara da evolução do            desenvolvimento do ProjetoGráfico não estav...
Story Mapping        Visão       Wish List
OK, temos uma visão de negócio ao longo do       Projeto  E temos uma visãomelhor da evolução do       projeto
Mas não era suficiente         Tínhamos muitos problemas de gargalos e ociosidadeSentíamos que o processo não fluía bem, e...
Car Wall           Wish List
Introduzindo Kanban
OK, temos uma visão denegócio, da evolução e      do Processo
Mas não era suficienteComo fazemos para fazer uma documentação a ser  entregue, exemplo: Manual, Funcionalidades          ...
Wiki
OK, temos um meiorápido de documentar,de forma colaborativa e        simples
Mas não era suficiente         ...
Priorização == SCRUM == Product Backlog    Drill Down == FDD == Feature Breakdonw Structure        Visibilidade do Negócio...
Ganhos Visibilidade do Produto por todos os envolvidos       Compartilhamento de conhecimento       Colaboração ativa de t...
Novas dificuldadesManter Story Mapping alinhado com Product Backlog              Manter FBS atualizada   Momento de realiz...
Nosso maior ganho foi a Cultura
Identifique, explore e eleve a        nova restrição   Simplicidade: a arte de  maximizar a quantidade detrabalho que não ...
Terminanos   Espero que tenham ficado curiosos              Rafael Barbosa Camargo                    @rafajagua         w...
Pedaços de XP, FDD, Scrum e Kanban na Análise de Negócios e Engenharia de Requisitos
Pedaços de XP, FDD, Scrum e Kanban na Análise de Negócios e Engenharia de Requisitos
Pedaços de XP, FDD, Scrum e Kanban na Análise de Negócios e Engenharia de Requisitos
Pedaços de XP, FDD, Scrum e Kanban na Análise de Negócios e Engenharia de Requisitos
Pedaços de XP, FDD, Scrum e Kanban na Análise de Negócios e Engenharia de Requisitos
Pedaços de XP, FDD, Scrum e Kanban na Análise de Negócios e Engenharia de Requisitos
Pedaços de XP, FDD, Scrum e Kanban na Análise de Negócios e Engenharia de Requisitos
Pedaços de XP, FDD, Scrum e Kanban na Análise de Negócios e Engenharia de Requisitos
Pedaços de XP, FDD, Scrum e Kanban na Análise de Negócios e Engenharia de Requisitos
Pedaços de XP, FDD, Scrum e Kanban na Análise de Negócios e Engenharia de Requisitos
Pedaços de XP, FDD, Scrum e Kanban na Análise de Negócios e Engenharia de Requisitos
Pedaços de XP, FDD, Scrum e Kanban na Análise de Negócios e Engenharia de Requisitos
Pedaços de XP, FDD, Scrum e Kanban na Análise de Negócios e Engenharia de Requisitos
Pedaços de XP, FDD, Scrum e Kanban na Análise de Negócios e Engenharia de Requisitos
Próximos SlideShares
Carregando em…5
×

Pedaços de XP, FDD, Scrum e Kanban na Análise de Negócios e Engenharia de Requisitos

1.825 visualizações

Publicada em

Relato de uma jornada partindo da Análise e Engenharia Tradicional de Requisitos para uma abordagem ágil utilizando pedaços de várias metodologias e frameworks ágeis.

Publicada em: Tecnologia
  • Seja o primeiro a comentar

Pedaços de XP, FDD, Scrum e Kanban na Análise de Negócios e Engenharia de Requisitos

  1. 1. Pedaços de XP, FDD, Scrum e Kanban na Análise de Negócio eEngenharia de Requisitos
  2. 2. Rafael Barbosa Camargo @rafajagua Analista de negócioswww.agilementoring.wordpress.com www.caipiraagil.com
  3. 3. O que é Análise de Negócio? Você sabe?
  4. 4. Análise de Negócios Segundo o IIBA é:“A Análise de Negócios é o conjunto de atividades e técnicas utilizadas para servir como ligação entre partes interessadas no intuito de compreender aestrutura, políticas e operações de uma organização e para recomendar soluções que permitam que a organização alcance suas metas”. (IIBA®, 2009, pg 3, BABOK)
  5. 5. O que é Engenharia de Requisitos? Você sabe?
  6. 6. Engenharia de RequisitosA engenharia de requisitos é um processo que engloba todas as atividades que contribuem para a produção de um documento de requisitos e sua manutenção ao longo do tempo.
  7. 7. Engenharia de Requisitos Um Requisito consiste da definição documentada de uma propriedade oucomportamento que um produto ou serviço particular deve atender.
  8. 8. Análise de Negócios e Engenharia TradicionalToda a análise era realizada no início do projeto
  9. 9. Análise de Negócios Tradicional Toda a análise era realizada no início do projeto
  10. 10. Análise de Negócios Tradicional Toda a análise era realizada no início do projeto
  11. 11. Análise e Engenharia Tradicional Concentra conhecimento Reduz comunicação Diminui as responsabilidades Gera CYA Indica “certeza” (ou perda de confiança) Difícil manutenção Não inclui todas as partes Não é colaborativa Alto retrabalho O que fazer primeiro?
  12. 12. Aonde dói mais Priorização Drill Down Visibilidade do Negócio Funcionalidades macro Entendimento e Comunicação Compreensão e Validação Visibilidade e Melhoria do Processo
  13. 13. O que é Ágil? Você sabe?
  14. 14. Manifesto para o desenvolvimento ágil de software Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através deste trabalho, passamos a valorizar: Indivíduos e interação entre eles mais que processos e ferramentas Software em funcionamento mais que documentação abrangente Colaboração com o cliente mais que negociação de contratos Responder a mudanças mais que seguir um planoOu seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.
  15. 15. Transição para Scrum
  16. 16. Análise de Negócio Ágil Vamos saber mais
  17. 17. Análise de Negócio Ágil
  18. 18. Engenharia de Requisitos Ágil
  19. 19. Product Backlog
  20. 20. OK, melhoramos a priorização e a definição em conjunto sobre asporções de software a ser desenvolvido
  21. 21. Mas não era suficientePrecisávamos de mais entendimento sobre aquilo que seria desenvolvido na Iteração Casos de uso eram muito grandes e estavam confusos A qualidade era duvidosa
  22. 22. Introduzindo XP
  23. 23. User Stories
  24. 24. Accpetance Criteria Viva Compartilhada Colaborativa
  25. 25. Planning Poker
  26. 26. OK, melhoramos o entendimento, acomunicação e a validação sobre o que temos de desenvolver Também está melhor pra estimar
  27. 27. Mas não era suficiente Não tínhamos visão clara e fácil sobre o todoEm certas situações, precisávamos de uma visão Macro e rápida sobre as Funcionalidades
  28. 28. Introduzindo FDD
  29. 29. FeatureModelo ARO para escrever nos Products Backlogs. <ação> <resultado> <objeto> Exemplos: <calcular> o <total> de uma <venda>. <calcular> a <quantidade total vendida por um varejista> para uma <descrição de produto>.
  30. 30. Feature Breakdown Structure Visão
  31. 31. Feature Breakdown Structure
  32. 32. OK, temos uma visão de negócio ao longo do ProjetoEstá mais fácil para fazer Grooming e Priorizar
  33. 33. Mas não era suficiente Não tínhamos visão clara da evolução do desenvolvimento do ProjetoGráfico não estavam representando muito a realidade
  34. 34. Story Mapping Visão Wish List
  35. 35. OK, temos uma visão de negócio ao longo do Projeto E temos uma visãomelhor da evolução do projeto
  36. 36. Mas não era suficiente Tínhamos muitos problemas de gargalos e ociosidadeSentíamos que o processo não fluía bem, entre a concepção e a entregaTemos mais visibilidade sobre o negócio, mas não muito sobre o processo
  37. 37. Car Wall Wish List
  38. 38. Introduzindo Kanban
  39. 39. OK, temos uma visão denegócio, da evolução e do Processo
  40. 40. Mas não era suficienteComo fazemos para fazer uma documentação a ser entregue, exemplo: Manual, Funcionalidades entregues
  41. 41. Wiki
  42. 42. OK, temos um meiorápido de documentar,de forma colaborativa e simples
  43. 43. Mas não era suficiente ...
  44. 44. Priorização == SCRUM == Product Backlog Drill Down == FDD == Feature Breakdonw Structure Visibilidade do Negócio == Story Mapping Funcionalidades macro == FDD == Features Entendimento e Comunicação == XP == User Stories Compreensão e Validação == XP == Acceptance CriteriaVisibilidade e Melhoria do Processo == Card Wall == Kanban
  45. 45. Ganhos Visibilidade do Produto por todos os envolvidos Compartilhamento de conhecimento Colaboração ativa de todas as partes Percepção do valor de negócio Priorização rápida Diminuição do retrabalho Aproximação de todos as papéis Melhoria contínua no processo
  46. 46. Novas dificuldadesManter Story Mapping alinhado com Product Backlog Manter FBS atualizada Momento de realizar a documentação formal Perca de post it no Kanban Momento de “congelamento” para Sprint Quando usar Sprints
  47. 47. Nosso maior ganho foi a Cultura
  48. 48. Identifique, explore e eleve a nova restrição Simplicidade: a arte de maximizar a quantidade detrabalho que não precisou ser feito.
  49. 49. Terminanos Espero que tenham ficado curiosos Rafael Barbosa Camargo @rafajagua www.agilementoring.wordpress.com www.caipiraagil.com

×