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

1.722 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
0 comentários
7 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

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

Nenhuma nota no slide
  • Começo da minha carreira
  • cascata
  • Primeiro passo, estabelecer a visão
  • Reunião com sponsors, gerentes, chefes
  • Por se uma análise especialista e não envolver todos os papéis, a visão fica deturpada
  • Inicia-se a análise. Pilhas de documento, uso errado da UML
  • Muita documentação já gerada e aprovada
  • Dificuldades e desafios que enfrentamos
  • Dificuldades e desafios que enfrentamos
  • Fizemos a transição para Scrum
  • Iterações e incrementos
  • Mudamos a forma como analisávamos o negócio
  • Colaboração – todos os perfis e impactados, membros do time - Compartilhar
  • Tornar mais visual, fácil de compartilhar e colaborar, dar visibilidade e entendimento
  • Modelo mais visual
  • Visibilidade, entendimento, compartilhamento
  • Práticas ludicas – Product Vison Box – Product Vision Board
  • Práticas ludicas – Mapa mental
  • A engenharia
  • Auxilia na Priorização, simples pra fazer ao lado do P.O, foco no ROI
  • Ficou mais fácil pra priorizar, se planejar e pensar nas mudanças
  • Precisávamos de uma forma de poder descrever com mais qualidade aquilo que seria feito
  • Entendimento e comunicação a nível de Sprints – INVEST. User Stories Writing Workshops
  • Critérios de Aceite ajudam a validar se atendemos o negócio e se a qualidade é adequada
  • Melhorou muito a estimativa, balizou o ritmo do Time,
  • Um método para ir se aprofundando
  • Grooming do backlog – reuniões rápidas sobre o que vem na próxima 1 ou 2 sprints
  • Não estava suficiente
  • Não estava suficiente
  • A FDD nasceu num projeto em  Cingapura , entre 1997 e 1999, a partir do Método Coad (uma metodologia completa para Análise, Desenho e Programação Orientados por Objetos, desenvolvida por Peter Coad nas décadas de 1980 e 1990) e das técnicas de gerenciamento iterativo, incremental e enxuto de projetos utilizadas por Jeff De Luca, um gerente de projetos australiano. Seu lema é  "Resultados freqüentes, tangíveis e funcionais" .
  • Modelo de descrição simples de funcionalidade, auxiliar para estimativas iniciais, não perde tanto tempo
  • Uma visão drill down no entendimento de negócio, suas áreas
  • Drill Down no nível de histórias
  • Temos agora uma visão mais simples e compartilhada sobre o negócio, está mais fácil pra fazer o grooming
  • O software não dava uma visibilidade compartilhada e não propiciava muita colaboração
  • Auxilia na compartilhamento da visão, priorização, releases
  • Temos agora uma visão mais simples e compartilhada sobre o negócio, está mais fácil pra fazer o grooming
  • O software não dava uma visibilidade compartilhada e não propiciava muita colaboração
  • Jogamos o processo na parece, demos visibilidade no processo e no negócio
  • Passamos mais além e começar a melhorar o processo segundo os princípios do Kanban
  • Temos agora uma visão sobre o que vai acontecer, do que está acontecendo, de como fazemos, e isso da suporte para melhorar ainda mais
  • Uma coisa é modos de comunicar e disseminar entendimento, outra coisa é documentar
  • Documentação após projeto, definições, duvidas. Muito mais colaborativo, dinâmico e simples
  • Temos agora uma visão sobre o que vai acontecer, do que está acontecendo, de como fazemos, e isso da suporte para melhorar ainda mais
  • Sempre há o que melhorar
  • Transparência, Inspeção e Adaptação Resultados Tangíveis e Entregas Frequentes Feedback, Comunicação, Simplicidade, Respeito e Coragem Visualizar o fluxo, Melhore de forma Colaborativa, Gerencie o Fluxo, Deixe as políticas explicitas, Acompanhe o Tempo de Ciclio e Limite o Wip Learning and Coolness
  • 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

    ×