Requisitos Ágeis

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 do cliente

Níveis

Épicos InvestimentosPORTIFÓLIO Visão Arquitetura Releases Features ProdutosPROGRAMA Roadmap Req. Não Funcionais Product Owner EstóriasTÍMES Scrum Master Iterações

#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• 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.

#2 program o desenvolvimento de sistemas em larga escala é atingido através de múltiplos times entregandoreleases sincronizados. (agile release train)

candência padrão de iterações e ART Agilemilestones que tem qualidade e data Release fixada, mas escopo variável Train

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 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

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

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?

#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.

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

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

temas de investimentodeterminam os objetivosda organização e guiam a visão de todos os programas.novos épicos são derivados desses temas

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

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 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

É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.

É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.

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

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 iteração

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

Gestão de Produtos Desenvolvimento Time B Time A Testes e Qualidade times cross-funcionais

Uma feature pode ser quebrada emvárias estórias e essas estórias podemser dividas em diversos times equipes comum mesmo release target

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

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

Ferramentas

Comunicação eficaz é chave, por isso é preciso uma linguagem comum entre entre o time de desenvolvimento e de produto (cliente)

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 suporte patrocionador marketing / vendas treinamento

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

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?

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 hfeature b feature e feature ifeature c feature j

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

http://blog.bluesoft.com.br	204
http://www.infoblogs.com.br	4
http://a0.twimg.com	3
http://feeds2.feedburner.com	1
http://paper.li	1
https://si0.twimg.com	1

Requisitos Ágeis

by André Faria Gomes

Accessibility

Categories

Upload Details

Usage Rights

6 Embeds 214

Statistics

Requisitos Ágeis Presentation Transcript