Requisitos ageis para times sem tempo

357 visualizações

Publicada em

Um overview do Universo Ágil e de como todo o time pode melhorar e agregar valor ao produto com práticas ágeis e testes de aceitação.

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

Sem downloads
Visualizações
Visualizações totais
357
No SlideShare
0
A partir de incorporações
0
Número de incorporações
4
Ações
Compartilhamentos
0
Downloads
12
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide
  • 13
  • 14
  • 15
  • 16
  • 18
  • 19
  • 24
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 49
  • 50
  • 51
  • 53
  • 54
  • Requisitos ageis para times sem tempo

    1. 1. KLEITOR Entusiasta da Vida, Qualidade, Colaborativos, Ágil, Teste e Testes Ágeis. 2 kleitor.franklint@gmail.com br.linkedin.com/in/kfranklint 99416-0873
    2. 2. 3 Um overview do Universo Ágil e de como todo o time pode melhorar e agregar valor ao produto com práticas ágeis e testes de aceitação.
    3. 3. 4 Repensando o saber. Essencialmente todos os modelos estão errados, mas alguns são úteis!! George E. P. Box
    4. 4. 5 Insanidade é fazer a mesma coisa repetidamente e esperar resultados diferentes. Definição de insanidade por Albert Einstein Repensando o fazer
    5. 5. 6 Repensando que o time todo pode tornar o produto melhor usando testes de aceitação e práticas ágeis!! Repensando o que, mesmo?
    6. 6. 7 Como capturar e modelar requisitos? -Use práticas Ágeis -Faça Testes de aceitação -Use pequenas fatias em pequenos ciclos -Use Histórias (User stories) -Use técnicas exploratórias Done=capturado+modelado+aceito+orientado a valor
    7. 7. 8 Quantas bolas há e de quais cores? 1 minuto. Valendo!!!
    8. 8. 9 Quantas bolas há aqui e quais as cores? 10 segundos. Valendo!!!
    9. 9. 10 Menores fatias de software ( requisitos ) são identificadas mais rápido, com menos esforço e com menos ambiguidade Ágil=Pequenos intervalos + pequenas fatias
    10. 10. 11 Teste de aceitação pra quê? Modelando um carro muito, muito veloz!!!
    11. 11. 12 Teste de aceitação pra quê? Modelando um carro muito veloz!!! Esse carro vai de 0 a 60 em 50s. Está rápido pra você? Não?! Me dê um teste! Qual a velocidade ideal? E agora, está rápido o suficiente? Mas, ao chegar a 60 ele para! E agora, está rápido o suficiente? Não?! Me dê um teste! Qual a velocidade máxima? E agora, está rápido o suficiente?
    12. 12. Fluxo do processo Ágil 13 Synchronizing Software Testing with Agile Requirements Practices , Jean McAuliffe, Dean Leffingwell Aceitação Pequenosintervalos Pequenasfatias Aprendizagem
    13. 13. 14 Gestão Ágil de Projetos Era uma vez… Então … tem essa etapa, aquela etapa…. e bem aqui entram as práticas ágeis. ÁGIL É UM ESTADO DE MENTE, NÃO UMA METODOLOGIA DE PROJETO
    14. 14. O que é “Ágil”, Afinal?  Agil não é metodologia, mas praticas úteis, principalmente comportamentais  Agil é adaptativo ao invés de prescritivo  Agil é orientado a pessoas ao invés de orientado a processo.  Maximiza o valor do negócio com processos e documentação right-sized, just-enough, e just- in-time 15
    15. 15. 16  Capacidade de rapidamente priorizar o uso de recursos quando requisitos, tecnologia e conhecimento mudam com o objetivo de lucrar em um mundo empresarial global turbulento  Uma resposta muito rápida às mudanças súbitas de mercado e ameaças emergentes através de interação intensiva com o cliente com base em: http://davidfrico.com/rico14n.pdf, Lean & Agile Enterprise Frameworks O que é “Ágil”, Afinal?
    16. 16. Resultado para empresas Empresas ágeis crescem suas receitas 37% mais rápido do que outras organizações e tem lucros mais elevados de 30% Pulse Report: 71% dos entrevistados disseram que o trabalho ágil lhes deu respostas mais rápidas às mudanças de condições de mercado 90% dos entrevistados (CEOs e CIOs) classificaram a agilidade organizacional como vital para o sucesso
    17. 17. Mundo Ágil e produtividade Amostras de mais de 8.000 projetos mostrou que equipes ágeis são, em média, 25% mais produtivas do que seus pares da indústria. http://www.deltamatrix.com/why-are-agile-teams-25-more-productive 18
    18. 18. Métodos Ágeis populares 19  Dynamic System Development Method (Dane Faulkner)  XP (Kent Beck)  Adaptive Software Development (Jim Highsmith)  Lean Software Development (Mary Poppendieck)  Crystal (Alistair Cockburn)  Feature Driven Development (Jeff DeLuca)  Scrum (Ken Schwaber)  Agile Rational Unified Process (RUP)  Rapid Software Testing (James Bach)
    19. 19. 20 Gestão ágil de projetos http://blog.procademysoftware.com/agile-project-management/ Por que pequenas fatias?
    20. 20. 21 Praticas Ágeis +Teste de aceitação, pra quê? Reduzir incertezas= exemplo+comunicação+colaboração+ pequenos ciclos+aceitação Conhecer o requisito não é suficiente para saber o que construir. O cliente precisar criar alguns testes. Entregas sem tempo precisam ser melhores que aquelas com prazo longo.
    21. 21. 22 Que testes de aceitação? Qualquer um que envolva o cliente e envolvidos Lista de requisitos, histórias, Casos de Uso, Diagramas, Paper prototype, Sistema... E a eficácia para o cliente e time?
    22. 22. 23 -Da concepção a pós-entrega -Orientado a Contexto -Descritivo e adaptativo -Resultados orientados a Valor -Oportunidade de enriquecer de descobrir novos requisitos -Multidmensional: múltiplas faces, múltiplos times Valoração pelo teste de aceitação
    23. 23. Ciclo de vida de projeto orientado a Alice Ciclo de vida orientado à incerteza Requisitos de negócios Requisitos funcionais desenvolvimento Entrega Suposições Hipóteses Experimentos Validação 24 Modelagem Orientada a teste Pra quê? Teste: da concepção a pós-entrega Todo o Time
    24. 24. 25 Sprints Ágeis
    25. 25. Valoração e entrega 26 O problema de sprints grandes com pouco feedback
    26. 26. Valoração e entrega Representando a incerteza 27 Requisitos são suposições no começo do projeto Mas, artefatos precisam ser escritos
    27. 27. Valoração e entrega Problema: sprint grande+pouco feedback 28 Ciclo de vida orientado à incerteza Suposições Hipóteses Experimentos Validação Analista especifica: UC, histórias, etc Testadores e desenvolvedores enriquecem, validam e descobrem novos requisitos Analista aplica teste de aceitação com o cliente ? Entrega Entrega Entrega
    28. 28. Menos útil: sprint grande+pouco feedback 29 -Produto com pouco valor agregado -Parte do time com o cronograma em dia e produto baseado fortemente em suposição -Parte do time realizando enorme esforço para agregar valor ao produto -Alto custo pouco ROI: Inconsistências e retrabalho -Pontos de dor: Falta de perspectivas, monotonia, etc.
    29. 29. Vamos fazer melhor? Sprint pequeno + muito feedback Lembra dos grãos? Lembra do Carro? 30 Suposições Hipóteses Experimentos Validação Clientes, analistas, testadores e desenvolvedores escrevem, enriquecem, validam e descobrem novos requisitos Entrega contínua + integração continua Teste de aceitação+comunicação+colaboração
    30. 30. Mais útil: sprint pequeno+muito feedback 31 -Melhor qualidade do que é produzido: capacidade humana de produzir bem com menos pontos de dor. -Mais fácil de alinhar escopo ( implementação, correção) -Menos erros repetidos multiplicados, analise mais inteligente da produtividade do desenvolvedor. -Minimizam riscos
    31. 31. Mais útil: sprint pequeno+muito feedback 32 -Produto com muito valor agregado -Cronograma inteligente=colaboração+comunicação+distribuição de esforço; -Produto orientado a teste de aceitação -Melhor ROI: custo x benefício - O time valida entre si e com o cliente.
    32. 32. No sprint 33 -Defina o escopo pequeno -Defina por histórias, features, fluxos de evento (UC) -Fale sobre riscos
    33. 33. 34 Entregue algo de valor a cada semana Seja Engajado, seja positivo, seja profissional Use o modelo 3C: card, conversation, confirmation Sprints Ágeis: Projeto
    34. 34. 35 -Use técnicas de estimativas mais adaptativas: planning poker, risk poker, T shirt size, etc -Envolva o time na estimativa -Lembre: às vezes o rápido atropela o Ágil. Prática Ágil: Projeto
    35. 35. 36 -Feedback = agilidade+ user centered -Reuniões eficazes -Retrospectivas e lições aprendidas -Fale sobre riscos em todos os sprints -Explore muito e explore sempre!!! Sprints Ágeis: comunicação Mapa e transferência de conhecimento
    36. 36. 37 Revisando as práticas ágeis... Até agora propomos juntos... -Ciclos pequenos -Entrega continua -Integração continua -Comunicação+colaboração -Cliente Satisfeito e Time realizado
    37. 37. 38 Teste de Aceitação
    38. 38. “O objetivo dos testes é agregar valor o mais cedo possível ao produto”. Modelagem projetando, modelagem executando Modelar comportamento do cliente..E SE.. 39 Teste para quê, mesmo?
    39. 39. 40 Alguns pontos de vista -Não!!! só depois do produto pronto -Aceitação do cliente como base, seja ele qual for; -Só como pré-entrega do produto é subutilizar a inteligência produtiva da empresa: muito gasto pouco ROI -No Ágil é executado em todo o ciclo de vida do produto -Aproxima o produto da necessidade do cliente no teste de aceitação final ( UAT ) -Agrega muito valor ao produto Teste de aceitação
    40. 40. 41 Testes de aceitação: como é feito? -Escrever ( desenhar) pequenos, múltiplos pedaços e dimensões de um requisito; -Explorar essas “features” -Ter o aceite do cliente -Feedbacks de pequenos ciclos
    41. 41. 42 feedback = agilidade+ user centered Teste de aceitação: comunicação Eu sei o que eu disse, mas já faz seis meses ... E eles construiram de acordo com a espec.. Ao invés do que o cliente queria
    42. 42. 43 Histórias ( um de vários modelos) Teste de aceitação: comunicação
    43. 43. 44 Histórias Use um Painel: Gestão À vista É palpável e gratificante pro cliente ver sua satisfação expressa
    44. 44. 45 Histórias Use um Painel: Gestão À vista Perfeitas para o time todo -Ótimas com o cliente -Padrão de comunicação para o time -Geram Casos de Uso -Podem decompor casos de Uso
    45. 45. 46 Histórias. Mas não só! Perfeitas para o time todo -Podem se transformar em código para o desenvolvedor -Podem ser padrão para time de teste -Instrumentação para UX
    46. 46. 47 Histórias. Mas não só! Perfeitas para gestão -Avaliar cronograma e produtividade: completude, aprovação -Visualiza múltiplas dimensões do Software -Feedback rápido do cliente -Análise de produtividade para desenvolvimento: completude e aceitação x bugs
    47. 47. 48 Você faz parte! Discussões de requisitos Quem sabe fará parte Apresentação de um produto VC ficou de fora! Analise de artefatos Quando realizar?Teste de aceitação
    48. 48. Software perfeito e outras ilusões 49 Explore!!!! ... O cliente é da área, então fica mais fácil Meu cliente esqueceu de me dizer...
    49. 49. 50 Quem precisa de Exploratórios? Não é “Testa Aeh”
    50. 50. 51 Quem precisa de Exploratórios? De debugadores a analistas de requisitos
    51. 51. 52 Quando explorar? Você faz parte! Discussões de requisitos Quem sabe fará parte Apresentação de um produto VC ficou de fora! Analise de artefatos
    52. 52. 53 Revisando as práticas ágeis... Neste fim de bate-papo propomos juntos... -Testes de Aceitação -Explorar requisitos -Integração continua -Comunicação+colaboração -Cliente Satisfeito e Time realizado
    53. 53. POSSO COLABORAR COM MAIS RESPOSTAS? 54 kleitor.franklint@gmail.com br.linkedin.com/in/kfranklint 92 99416-0873

    ×