Successfully reported this slideshow.

Requisitos Ágeis

53

Share

Loading in …3
×
1 of 55
1 of 55

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Related Audiobooks

Free with a 14 day trial from Scribd

See all

Requisitos Ágeis

  1. 1. Requisitos Ágeis André Faria Gomes @andrefaria
  2. 2. leia o livro! http://www.amazon.com/Agile-Software-Requirements-Enterprise-Development/dp/0321635841
  3. 3. princípio Nossa maior prioridade é satisfazer o cliente entregando software de valor mais cedo e frequentemente
  4. 4. Princípio Abraçar a mudança, mesmo que o desenvolvimento esteja avançado. Processos ágeis apóiam a vantagem competitiva do cliente
  5. 5. Níveis
  6. 6. Épicos Investimentos PORTIFÓLIO Visão Arquitetura Releases Features Produtos PROGRAMA Roadmap Req. Não Funcionais Product Owner Estórias TÍMES Scrum Master Iterações
  7. 7. #1 time times pequenos definem, constroem, e testam estórias de usuários em uma série de iterações e releases.
  8. 8. product owner responsável pela gestão do backlog das estórias de usuário e outras coisas que o time precisa fazer • trabalha com gerentes de produto, analistas de negócio, clientes e outros interessados para determinar o requisitos • mantém o backlog e o prioriza baseado no valor de negócio • define objetivos para a iteração • Elabora estórias, participando de reuniões de review e aceitando estórias.
  9. 9. #2 program o desenvolvimento de sistemas em larga escala é atingido através de múltiplos times entregando releases sincronizados. (agile release train)
  10. 10. candência padrão de iterações e ART Agile milestones que tem qualidade e data Release fixada, mas escopo variável Train
  11. 11. PSIs O ART produz releases ou incrementos potencialmente entregáveis que geralmente são fixados entre 60 e 120 dias
  12. 12. gerente de produto responsável por definir as features do sistema no nível do programa •dono da visão e do backlog do programa (release) •gerencia o conteúdo do release •mantém o roadmap do produto •lidera um time de product owners
  13. 13. product product owner manager produto/tecnologia mercado/cliente time de desenvolvimento time de negócio foco na implementação foco no roi, portifólio, mercado dono da implementação dono da visão e roadmap dirige a iteração dirige o release
  14. 14. Visão responde as grandes perguntas para o sistema, aplicação ou produto que problemas essa solução resolve? que features e benefícios ela oferece? para quem? que performance, confiabilidade, ..., ela apresenta? quais plataformas, padrões, aplicações,..., suporta?
  15. 15. #3 portifólio temas de investimento são usados para guiar as prioridades de investimentos para a organização, assegurando que o trabalho realizado está alinhado a estratégia da organização. esses temas direcionam a visão do portifólio que será expressada através de diversas iniciativas épicas, que são alocadas para release (agile release train) ao longo do tempo.
  16. 16. organizações que possuem poucos produtos, ou produtos pequenos, o modelo de times (estórias, tarefas e testes de aceitação) pode ser suficiente, mais o modelo de programa (features e requisitos não-funcionais) pode ser suficiente para gerenciar a evolução dos produtos
  17. 17. grandes organizações que empregam centenas e milhares de pessoas e possuem muitos produtos, podem precisar de um modelo mais completo e níveis de abstração mais altos
  18. 18. temas de investimento determinam os objetivos da organização e guiam a visão de todos os programas. novos épicos são derivados desses temas
  19. 19. gerentes de Portifólio tomam decisões sobre os temas de investimento, como resultado encontram temas- chave sobre o que produto agregará de valor ao mercado para vantagem competitiva assim como diferenciais da solução
  20. 20. temas de investimento épicos features estórias de usuário
  21. 21. TEMA DE INVESTIMENTO: CONTABILIDADE
  22. 22. ÉPICO: ENCERRAMENTO DO EXERCÍCIO CONTÁBIL
  23. 23. FEATURE: APURAÇÃO DO RESULTADO
  24. 24. USER STOR Y #1 Como um usuário eu gostaria de calcular o lucro do exercício
  25. 25. USER STOR Y #2 Como um usuário eu gostaria de encerrar o exercício contábil
  26. 26. USER STOR Y #3 Como um usuário eu gostaria de distribuir o lucro para os sócios
  27. 27. Backlog do portifólio Épicos representam o mais alto nível da necessidade de um cliente. São iniciativas de desenvolvimento que tem como objetivo entregar valor à um tema de investimento. São identificados, priorizados estimados e mantidos no backlog do portifólio. no planejamento de releases os épicos são decompostos em features específicas e posteriormente serão transformados em mais estórias de usuário para implementação
  28. 28. Épicos podem ser expressados em bullets, na voz do usuário, como uma ou duas frases, em vídeo, protótipo ou qualquer outra forma que demonstre a intenção da iniciativa. o épico deve ficar no nível estratégico, não específico. em outras palavras, o só há necessidade de entrar nos detalhes em discussões posteriores sobre as features.
  29. 29. Épicos • são geralmente dirigidos por temas de investimentos, mas podem ser independentes • Não são implementados diretamente, ao invés disso, são quebrados em features, que podem ser quebradas novamente em estórias. • não são diretamente testáveis. ao invés disso são testados através de testes de aceitação associados com as features e estórias implementadas.
  30. 30. gestão do portifólio o time de gestão do portifólio toma decisões baseadas em: investimento em produtos existentes - melhorias, suporte e manutenção investimento em novos produtos e serviços - produtos que melhorarão a receita e ou ganharão novas fatias do mercado à curto-prazo investimento no futuro - produtos e serviços avançados que requerem investimento hoje porém não vão gerar receita tão cedo redução de investimento - (sunset strategy) para ofertas existentes que estão perto do fim da sua vida útil
  31. 31. trabalho no time
  32. 32. a unidade básica de trabalho para um time é a estória de usuário. eles definem, constroem, e testam no escopo de uma iteração
  33. 33. elimine os silos funcionais Comunicação vertical fricção entre os silos Testes e Qualidade Gestão de Produtos Desenvolvimento “fiz a minha parte” barreiras políticas
  34. 34. Gestão de Produtos Desenvolvimento Time B Time A Testes e Qualidade times cross-funcionais
  35. 35. Uma feature pode ser quebrada em várias estórias e essas estórias podem ser dividas em diversos times equipes com um mesmo release target
  36. 36. estórias são quebradas em tarefas Estória 51: selecionar uma foto para upload tarefa 51.1: definir testes de aceitação tarefa 51.2: controller e view tarefa 51.3: serviço de upload para amazon s3 tarefa 51.4: codificar teste de aceitação tarefa 51.5: documentar na ajuda do usuário
  37. 37. Uma estória deve possuir 1 ou muitos critérios de aceitação, a estória está pronta, quando todos os critérios de aceitação forem satisfeitos. Estes critérios devem ser transformados em testes unitários e funcionais automatizados
  38. 38. Ferramentas
  39. 39. Comunicação eficaz é chave, por isso é preciso uma linguagem comum entre entre o time de desenvolvimento e de produto (cliente)
  40. 40. card, conversation and confirmation
  41. 41. INVEST Independent Estimable Negotiable Small Valuable Testable
  42. 42. Estória Spike uma estória especial para reduzir riscos e incertezas
  43. 43. stakeholders quais as expectativas e participações sócios developer manager suporte patrocionador marketing / vendas treinamento
  44. 44. stakeholders do sistema em 3 níveis 3 quem instala, entrega, ou dá suporte terceiros quem trabalha com os resultados 2 1 quem usa o produto funcionários do cliente vendedores devices administradores contadores fornecedores força de vendas bancos implantadores
  45. 45. personas vendedor o que espera do sistema? usuário o que faz com os sistema? força de vendas o que espera do sistema? sistema o que faz com os sistema?
  46. 46. Acceptance Test Template Crispin and Gregory
  47. 47. Mockups
  48. 48. Cost of Delay (CoD) Quando o custo de atraso é o mesmo, o faça o menor trabalho primeiro.
  49. 49. Cost of Delay (CoD) se o esforço for o mesmo, faça a o que tiver o maior custo de atraso primeiro
  50. 50. Modelo de kano para priorização
  51. 51. roadmap Tempo release 1 release 2 release 2 feature a feature d feature h feature b feature e feature i feature c feature j
  52. 52. alinhamento de metas
  53. 53. leia o livro! http://www.amazon.com/Agile-Software-Requirements-Enterprise-Development/dp/0321635841
  54. 54. Obrigado @andrefaria http://blog.andrefaria.com http://blog.bluesoft.com.br

×