1. Requisitos
Ágeis
André 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 cliente
entregando software de valor
mais cedo e frequentemente

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. Níveis

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. #1
time
times pequenos definem,
constroem, e testam estórias
de usuários em uma série de
iterações e releases.

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. #2 program
o desenvolvimento de
sistemas em larga
escala é atingido
através de múltiplos
times entregando
releases sincronizados.
(agile release train)

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. PSIs
O ART produz releases
ou incrementos
potencialmente
entregáveis que
geralmente 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 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. 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 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. 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 milhares
de pessoas e possuem muitos produtos, podem precisar de
um modelo mais completo e níveis de abstração mais altos

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. 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 de
investimento
épicos
features
estórias de
usuário

21. TEMA DE INVESTIMENTO:
CONTABILIDADE

22. ÉPICO:
ENCERRAMENTO
DO EXERCÍCIO
CONTÁBIL

23. FEATURE:
APURAÇÃO DO
RESULTADO

24. USER STOR Y #1
Como um usuário
eu gostaria de
calcular o lucro
do exercício

25. USER STOR Y #2
Como um usuário eu
gostaria de
encerrar o exercício
contábil

26. USER STOR Y #3
Como um usuário eu
gostaria de
distribuir 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 em
mais 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.

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

32. trabalho no time

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

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

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

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

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

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

39. Ferramentas

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

41. card, conversation and confirmation

42. INVEST
Independent Estimable
Negotiable Small
Valuable Testable

43. Estória Spike
uma estória especial para reduzir riscos e incertezas

44. stakeholders
quais as expectativas e participações
sócios
developer manager
suporte
patrocionador
marketing / vendas
treinamento

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

46. 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?

47. Acceptance Test Template
Crispin and Gregory

48. Mockups

49. Cost of Delay (CoD)
Quando o custo de atraso é o mesmo, o faça o menor trabalho primeiro.

50. Cost of Delay (CoD)
se o esforço for o mesmo, faça a o que tiver o maior custo de atraso primeiro

51. Modelo de kano
para priorização

52. roadmap
Tempo
release 1 release 2 release 2
feature a feature d feature h
feature b feature e feature i
feature c feature j

53. alinhamento de metas

54. leia o livro!
http://www.amazon.com/Agile-Software-Requirements-Enterprise-Development/dp/0321635841

55. Obrigado
@andrefaria
http://blog.andrefaria.com
http://blog.bluesoft.com.br