Relato de uma jornada partindo da Análise e Engenharia Tradicional de Requisitos para uma abordagem ágil utilizando pedaços de várias metodologias e frameworks ágeis.

1. Pedaços de XP, FDD,
Scrum e Kanban na
Análise de Negócio e
Engenharia de Requisitos

2. Rafael Barbosa Camargo
@rafajagua
Analista de negócios
www.agilementoring.wordpress.com
www.caipiraagil.com

3. O que é Análise de Negócio?
Você sabe?

4. Análise de Negócios
Segundo o IIBA é:
“A Análise de Negócios é o conjunto de atividades e
técnicas utilizadas para servir como ligação entre
partes interessadas no intuito de compreender a
estrutura, políticas e operações de uma organização
e para recomendar soluções que permitam que a
organização alcance suas metas”.
(IIBA®, 2009, pg 3, BABOK)

5. O que é Engenharia de
Requisitos?
Você sabe?

6. Engenharia de Requisitos
A engenharia de requisitos é um processo que
engloba todas as atividades que contribuem
para a produção de um documento de
requisitos e sua manutenção ao longo do
tempo.

7. Engenharia de Requisitos
Um Requisito consiste da definição
documentada de uma propriedade ou
comportamento que um produto ou serviço
particular deve atender.

8. Análise de Negócios e
Engenharia Tradicional
Toda a análise era realizada no início
do projeto

15. Análise de Negócios Tradicional
Toda a análise era realizada no início
do projeto

16. Análise de Negócios Tradicional
Toda a análise era realizada no início
do projeto

17. Análise e Engenharia Tradicional
Concentra conhecimento
Reduz comunicação
Diminui as responsabilidades
Gera CYA
Indica “certeza” (ou perda de confiança)
Difícil manutenção
Não inclui todas as partes
Não é colaborativa
Alto retrabalho
O que fazer primeiro?

18. Aonde dói mais
Priorização
Drill Down
Visibilidade do Negócio
Funcionalidades macro
Entendimento e Comunicação
Compreensão e Validação
Visibilidade e Melhoria do Processo

19. O que é Ágil?
Você sabe?

20. Manifesto para o desenvolvimento ágil de software
Estamos descobrindo maneiras melhores de desenvolver software
fazendo-o nós mesmos e ajudando outros a fazê-lo. Através deste
trabalho, passamos a valorizar:
Indivíduos e interação entre eles mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os
itens à esquerda.

21. Transição para Scrum

22. Análise de Negócio Ágil
Vamos saber mais

23. Análise de Negócio Ágil

30. Engenharia de Requisitos Ágil

31. Product Backlog

32. OK, melhoramos a
priorização e a definição
em conjunto sobre as
porções de software a ser
desenvolvido

33. Mas não era suficiente
Precisávamos de mais entendimento sobre aquilo
que seria desenvolvido na Iteração
Casos de uso eram muito grandes e estavam
confusos
A qualidade era duvidosa

34. Introduzindo XP

35. User Stories

36. Accpetance Criteria
Viva
Compartilhada
Colaborativa

37. Planning Poker

40. OK, melhoramos o
entendimento, a
comunicação e a validação
sobre o que temos de
desenvolver
Também está melhor pra
estimar

41. Mas não era suficiente
Não tínhamos visão clara e fácil sobre o todo
Em certas situações, precisávamos de uma visão
Macro e rápida sobre as Funcionalidades

42. Introduzindo FDD

43. Feature
Modelo ARO para escrever nos Products Backlogs.
<ação> <resultado> <objeto>
Exemplos:
<calcular> o <total> de uma <venda>.
<calcular> a <quantidade total vendida por um
varejista> para uma <descrição de produto>.

44. Feature Breakdown Structure
Visão

45. Feature Breakdown Structure

46. OK, temos uma visão de
negócio ao longo do
Projeto
Está mais fácil para fazer
Grooming e Priorizar

47. Mas não era suficiente
Não tínhamos visão clara da evolução do
desenvolvimento do Projeto
Gráfico não estavam representando muito a realidade

48. Story Mapping
Visão
Wish List

49. OK, temos uma visão de
negócio ao longo do
Projeto
E temos uma visão
melhor da evolução do
projeto

50. Mas não era suficiente
Tínhamos muitos problemas de gargalos e ociosidade
Sentíamos que o processo não fluía bem, entre a concepção e a entrega
Temos mais visibilidade sobre o negócio, mas não muito sobre o processo

51. Car Wall
Wish List

52. Introduzindo Kanban

53. OK, temos uma visão de
negócio, da evolução e
do Processo

54. Mas não era suficiente
Como fazemos para fazer uma documentação a ser
entregue, exemplo: Manual, Funcionalidades
entregues

55. Wiki

56. OK, temos um meio
rápido de documentar,
de forma colaborativa e
simples

57. Mas não era suficiente
...

58. Priorização == SCRUM == Product Backlog
Drill Down == FDD == Feature Breakdonw Structure
Visibilidade do Negócio == Story Mapping
Funcionalidades macro == FDD == Features
Entendimento e Comunicação == XP == User Stories
Compreensão e Validação == XP == Acceptance Criteria
Visibilidade e Melhoria do Processo == Card Wall == Kanban

59. Ganhos
Visibilidade do Produto por todos os envolvidos
Compartilhamento de conhecimento
Colaboração ativa de todas as partes
Percepção do valor de negócio
Priorização rápida
Diminuição do retrabalho
Aproximação de todos as papéis
Melhoria contínua no processo

60. Novas dificuldades
Manter Story Mapping alinhado com Product Backlog
Manter FBS atualizada
Momento de realizar a documentação formal
Perca de post it no Kanban
Momento de “congelamento” para Sprint
Quando usar Sprints

61. Nosso maior ganho foi a Cultura

62. Identifique, explore e eleve a
nova restrição
Simplicidade: a arte de
maximizar a quantidade de
trabalho que não precisou ser
feito.

63. Terminanos
Espero que tenham ficado curiosos
Rafael Barbosa Camargo
@rafajagua
www.agilementoring.wordpress.com
www.caipiraagil.com