Requisitos Ágeis

  • 4,231 views
Uploaded on

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

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

More in: Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
4,231
On Slideshare
0
From Embeds
0
Number of Embeds
6

Actions

Shares
Downloads
0
Comments
2
Likes
23

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Requisitos ÁgeisAndré Faria Gomes @andrefaria
  • 2. leia o livro!http://www.amazon.com/Agile-Software-Requirements-Enterprise-Development/dp/0321635841
  • 3. princípio Nossa maior prioridade é satisfazer o clienteentregando software de valor mais cedo e frequentemente
  • 4. PrincípioAbraçar a mudança, mesmo que odesenvolvimento estejaavançado. Processos ágeis apóiam avantagem competitiva do cliente
  • 5. Níveis
  • 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. #1 time times pequenos definem, constroem, e testam estórias de usuários em uma série de iterações e releases.
  • 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. #2 program o desenvolvimento de sistemas em larga escala é atingido através de múltiplos times entregandoreleases sincronizados. (agile release train)
  • 10. candência padrão de iterações e ART Agilemilestones que tem qualidade e data Release fixada, mas escopo variável Train
  • 11. PSIsO ART produz releases ou incrementos potencialmente entregáveis quegeralmente são fixados entre 60 e 120 dias
  • 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. 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. 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. #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. 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. 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. temas de investimentodeterminam os objetivosda organização e guiam a visão de todos os programas.novos épicos são derivados desses temas
  • 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. temas deinvestimento épicos features estórias de usuário
  • 21. TEMA DE INVESTIMENTO:CONTABILIDADE
  • 22. ÉPICO:ENCERRAMENTODO EXERCÍCIO CONTÁBIL
  • 23. FEATURE:APURAÇÃO DORESULTADO
  • 24. USER STOR Y #1Como um usuário eu gostaria decalcular o lucro do exercício
  • 25. USER STOR Y #2 Como um usuário eu gostaria deencerrar o exercício contábil
  • 26. USER STOR Y #3Como um usuário eu gostaria dedistribuir o lucro para os sócios
  • 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. É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. É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. 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. trabalho no time
  • 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. 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. Gestão de Produtos Desenvolvimento Time B Time A Testes e Qualidade times cross-funcionais
  • 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. 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. 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. Ferramentas
  • 39. Comunicação eficaz é chave, por isso é preciso uma linguagem comum entre entre o time de desenvolvimento e de produto (cliente)
  • 40. card, conversation and confirmation
  • 41. INVESTIndependent EstimableNegotiable SmallValuable Testable
  • 42. Estória Spike uma estória especial para reduzir riscos e incertezas
  • 43. stakeholders quais as expectativas e participações sóciosdeveloper manager suporte patrocionador marketing / vendas treinamento
  • 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. 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. Acceptance Test Template Crispin and Gregory
  • 47. Mockups
  • 48. Cost of Delay (CoD)Quando o custo de atraso é o mesmo, o faça o menor trabalho primeiro.
  • 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. Modelo de kano para priorização
  • 51. roadmap Temporelease 1 release 2 release 2feature a feature d feature hfeature b feature e feature ifeature c feature j
  • 52. alinhamento de metas
  • 53. leia o livro!http://www.amazon.com/Agile-Software-Requirements-Enterprise-Development/dp/0321635841
  • 54. Obrigado @andrefaria http://blog.andrefaria.com http://blog.bluesoft.com.br