Requisitos   ÁgeisAndré Faria Gomes @andrefaria
leia o livro!http://www.amazon.com/Agile-Software-Requirements-Enterprise-Development/dp/0321635841
princípio  Nossa maior prioridade é    satisfazer o clienteentregando software de valor mais cedo e frequentemente
PrincípioAbraçar a mudança,    mesmo que odesenvolvimento estejaavançado. Processos   ágeis apóiam avantagem competitiva  ...
Níveis
Épicos InvestimentosPORTIFÓLIO           Visão     Arquitetura               Releases Features ProdutosPROGRAMA         Ro...
#1     time     times pequenos definem, constroem, e testam estórias de usuários em uma série de      iterações e releases.
product ownerresponsável pela gestão do backlog das estórias de    usuário e outras coisas que o time precisa fazer•   tra...
#2 program o desenvolvimento de  sistemas em larga   escala é atingido através de múltiplos  times entregandoreleases sinc...
candência padrão de iterações e      ART                                      Agilemilestones que tem qualidade e data    ...
PSIsO ART produz releases   ou incrementos   potencialmente   entregáveis quegeralmente são fixados entre 60 e 120 dias
gerente de produto    responsável por definir as   features do sistema no nível do               programa      •dono da vi...
product                      product   owner                     managerproduto/tecnologia        mercado/clientetime de d...
Visão responde as grandes perguntas para    o sistema, aplicação ou produto   que problemas essa solução resolve?  que fea...
#3 portifólio  temas de investimento são usados paraguiar as prioridades de investimentos para    a organização, asseguran...
organizações que possuem poucos produtos, ou produtos pequenos, o modelo de times (estórias,tarefas e testes de aceitação)...
grandes organizações que empregam centenas e milharesde pessoas e possuem muitos produtos, podem precisar deum modelo mais...
temas de investimentodeterminam os objetivosda organização e guiam a    visão de todos os      programas.novos épicos são ...
gerentes de Portifólio             tomam decisões sobre os temas                 de investimento, como             resulta...
temas deinvestimento   épicos  features estórias de   usuário
TEMA DE INVESTIMENTO:CONTABILIDADE
ÉPICO:ENCERRAMENTODO EXERCÍCIO  CONTÁBIL
FEATURE:APURAÇÃO DORESULTADO
USER STOR Y #1Como um usuário eu gostaria decalcular o lucro  do exercício
USER STOR Y #2 Como um usuário eu    gostaria deencerrar o exercício      contábil
USER STOR Y #3Como um usuário eu   gostaria dedistribuir o lucro  para os sócios
Backlog do portifólio  Épicos representam o mais alto nível da necessidade de um cliente. São iniciativas de   desenvolvim...
Épicos   podem ser expressados em bullets, na  voz do usuário, como uma ou duas frases,   em vídeo, protótipo ou qualquer ...
Épicos•   são geralmente dirigidos por temas de    investimentos, mas podem ser    independentes•   Não são implementados ...
gestão do portifólio o time de gestão do portifólio toma decisões baseadas em:investimento em produtos existentes - melhor...
trabalho no time
a unidade básica detrabalho para um time é a estória de usuário. eles  definem, constroem, e testam no escopo de uma      ...
elimine os silos funcionais                                                               Comunicação vertical            ...
Gestão de Produtos Desenvolvimento                      Time B                               Time A Testes e Qualidade    ...
Uma feature pode ser quebrada emvárias estórias e essas estórias podemser dividas em diversos times equipes comum mesmo re...
estórias são quebradas                            em tarefasEstória 51: selecionar uma foto para uploadtarefa 51.1: defini...
Uma estória deve possuir 1 oumuitos critérios de aceitação,a estória está pronta, quandotodos os critérios deaceitação for...
Ferramentas
Comunicação eficaz é chave, por isso é preciso uma linguagem comum entre entre o time de    desenvolvimento e de produto (...
card, conversation and confirmation
INVESTIndependent   EstimableNegotiable    SmallValuable      Testable
Estória Spike  uma estória especial para reduzir riscos e incertezas
stakeholders     quais as expectativas e participações                                    sóciosdeveloper manager         ...
stakeholders                       do sistema em 3 níveis3   quem instala, entrega, ou dá suporte                  terceir...
personasvendedor          o que espera do sistema?usuário           o que faz com os sistema?força de vendas   o que esper...
Acceptance Test Template                  Crispin and Gregory
Mockups
Cost of Delay (CoD)Quando o custo de atraso é o mesmo, o faça o menor trabalho primeiro.
Cost of Delay (CoD)se o esforço for o mesmo, faça a o que tiver o maior custo de atraso primeiro
Modelo de kano   para priorização
roadmap                                     Temporelease 1    release 2   release 2feature a    feature d   feature hfeatu...
alinhamento de metas
leia o livro!http://www.amazon.com/Agile-Software-Requirements-Enterprise-Development/dp/0321635841
Obrigado      @andrefaria     http://blog.andrefaria.com     http://blog.bluesoft.com.br
Requisitos Ágeis
Upcoming SlideShare
Loading in...5
×

Requisitos Ágeis

4,785

Published on

Apresentação de André Faria sobre Requisitos Ágeis.

Published in: Business
2 Comments
28 Likes
Statistics
Notes
No Downloads
Views
Total Views
4,785
On Slideshare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
0
Comments
2
Likes
28
Embeds 0
No embeds

No notes for slide

Requisitos Ágeis

  1. 1. Requisitos ÁgeisAndré 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 clienteentregando software de valor mais cedo e frequentemente
  4. 4. PrincípioAbraçar a mudança, mesmo que odesenvolvimento estejaavançado. Processos ágeis apóiam avantagem competitiva do cliente
  5. 5. Níveis
  6. 6. Épicos InvestimentosPORTIFÓLIO Visão Arquitetura Releases Features ProdutosPROGRAMA Roadmap Req. Não Funcionais Product Owner EstóriasTÍ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 ownerresponsá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 entregandoreleases sincronizados. (agile release train)
  10. 10. candência padrão de iterações e ART Agilemilestones que tem qualidade e data Release fixada, mas escopo variável Train
  11. 11. PSIsO ART produz releases ou incrementos potencialmente entregáveis quegeralmente 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 managerproduto/tecnologia mercado/clientetime de desenvolvimento time de negóciofoco na implementação foco no roi, portifólio, mercadodono da implementação dono da visão e roadmapdirige 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 paraguiar 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 doportifólio que será expressada através dediversas 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 milharesde pessoas e possuem muitos produtos, podem precisar deum modelo mais completo e níveis de abstração mais altos
  18. 18. temas de investimentodeterminam os objetivosda 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 deinvestimento épicos features estórias de usuário
  21. 21. TEMA DE INVESTIMENTO:CONTABILIDADE
  22. 22. ÉPICO:ENCERRAMENTODO EXERCÍCIO CONTÁBIL
  23. 23. FEATURE:APURAÇÃO DORESULTADO
  24. 24. USER STOR Y #1Como um usuário eu gostaria decalcular o lucro do exercício
  25. 25. USER STOR Y #2 Como um usuário eu gostaria deencerrar o exercício contábil
  26. 26. USER STOR Y #3Como um usuário eu gostaria dedistribuir 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 emmais 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, suportee manutençãoinvestimento em novos produtos e serviços - produtos quemelhorarão a receita e ou ganharão novas fatias domercado à curto-prazoinvestimento no futuro - produtos e serviços avançadosque requerem investimento hoje porém não vão gerarreceita tão cedoredução de investimento - (sunset strategy) paraofertas existentes que estão perto do fim da sua vida útil
  31. 31. trabalho no time
  32. 32. a unidade básica detrabalho 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 QualidadeGestã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 emvárias estórias e essas estórias podemser dividas em diversos times equipes comum mesmo release target
  36. 36. estórias são quebradas em tarefasEstória 51: selecionar uma foto para uploadtarefa 51.1: definir testes de aceitaçãotarefa 51.2: controller e viewtarefa 51.3: serviço de upload para amazon s3tarefa 51.4: codificar teste de aceitaçãotarefa 51.5: documentar na ajuda do usuário
  37. 37. Uma estória deve possuir 1 oumuitos critérios de aceitação,a estória está pronta, quandotodos os critérios deaceitação forem satisfeitos.Estes critérios devem sertransformados em testesunitários e funcionaisautomatizados
  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. INVESTIndependent EstimableNegotiable SmallValuable 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óciosdeveloper manager suporte patrocionador marketing / vendas treinamento
  44. 44. stakeholders do sistema em 3 níveis3 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. personasvendedor 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 Temporelease 1 release 2 release 2feature a feature d feature hfeature b feature e feature ifeature 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

×