Pedaos de XP, FDD,

Scrum e Kanban na
Anlise de Negcio e
Engenharia de Requisitos
 Rafael Barbosa Camargo
@rafajagua

www.agilementoring.wordpress.com

www.caipiraagil.com
O que Anlise de
Negcio?

Voc sabe?
 Anlise de Negcios

Segundo o IIBA :
A Anlise de Negcios o conjunto de atividades e
tcnicas utilizadas para servir como ligao entre
partes interessadas no intuito de compreender a
estrutura, polticas e operaes de uma organizao
e para recomendar solues que permitam que a
organizao alcance suas metas.
(IIBA, 2009, pg 3, BABOK)
O que Engenharia de
Requisitos?

Voc sabe?
 Engenharia de Requisitos

A engenharia de requisitos um processo que

engloba todas as atividades que contribuem
para a produo de um documento de
requisitos e sua manuteno ao longo do
tempo.
 Engenharia de Requisitos

Um Requisito consiste da definio

documentada de uma propriedade
ou comportamento que
um produto ou servio particular deve atender.
 Anlise de Negcios e
Engenharia Tradicional
Toda a anlise era realizada no incio
do projeto
Anlise de Negcios Tradicional

Toda a anlise era realizada no incio

do projeto
Anlise de Negcios Tradicional

Toda a anlise era realizada no incio

do projeto
Anlise e Engenharia Tradicional
Concentra conhecimento
Reduz comunicao
Diminui as responsabilidades
Gera CYA
Indica certeza (ou perda de confiana)
Difcil manuteno
No inclui todas as partes
No colaborativa
Alto retrabalho
O que fazer primeiro?
 Aonde di mais
Priorizao

Drill Down

Visibilidade do Negcio

Funcionalidades macro

Entendimento e Comunicao

Compreenso e Validao

Visibilidade e Melhoria do Processo

O que gil?

Voc sabe?
Manifesto para o desenvolvimento gil de software
Estamos descobrindo maneiras melhores de desenvolver software
fazendo-o ns mesmos e ajudando outros a faz-lo. Atravs deste
trabalho, passamos a valorizar:

Indivduos e interao entre eles mais que processos e

ferramentas
Software em funcionamento mais que documentao abrangente

Colaborao com o cliente mais que negociao de contratos

Responder a mudanas mais que seguir um plano

Ou seja, mesmo havendo valor nos itens direita, valorizamos

mais os itens esquerda.
Transio para Scrum
Anlise de Negcio gil

Vamos saber mais

Anlise de Negcio gil
Engenharia de Requisitos
gil
Product Backlog
 OK, melhoramos a
priorizao e a definio
em conjunto sobre as
pores de software a ser
desenvolvido
 Mas no era suficiente
Precisvamos de mais entendimento sobre aquilo
que seria desenvolvido na Iterao
Casos de uso eram muito grandes e estavam
confusos
A qualidade era duvidosa
Introduzindo XP
User Stories
Accpetance Criteria

Viva
Compartilhada
Colaborativa
Planning Poker
 OK, melhoramos o
entendimento, a
comunicao e a validao
sobre o que temos de
desenvolver
Tambm est melhor pra
estimar
Mas no era suficiente
No tnhamos viso clara e fcil sobre o todo

Em certas situaes, precisvamos de uma viso

Macro e rpida sobre as Funcionalidades
Introduzindo FDD
 Feature
Modelo ARO para escrever nos Products Backlogs.
<ao> <resultado> <objeto>
Exemplos:

<calcular> o <total> de uma <venda>.

<calcular> a <quantidade total vendida por um
varejista> para uma <descrio de produto>.
Feature Breakdown Structure

Viso
Feature Breakdown Structure
OK, temos uma viso de
negcio ao longo do
Projeto
Est mais fcil para fazer
Grooming e Priorizar
Mas no era suficiente
No tnhamos viso clara da evoluo do
desenvolvimento do Projeto

Grfico no estavam representando muito a

realidade
Story Mapping

Viso

Wish List
OK, temos uma viso de
negcio ao longo do
Projeto
E temos uma viso
melhor da evoluo do
projeto
 Mas no era suficiente
Tnhamos muitos problemas de gargalos e ociosidade

Sentamos que o processo no flua bem, entre a concepo e a

entrega

Temos mais visibilidade sobre o negcio, mas no muito sobre o

processo
Card Wall

Wish List
Introduzindo Kanban
OK, temos uma viso de
negcio, da evoluo e
do Processo
 Mas no era suficiente
Como fazemos para fazer uma documentao a ser
entregue, exemplo: Manual, Funcionalidades
entregues
Wiki
 OK, temos um meio
rpido de documentar, de
forma colaborativa e
simples
Mas no era suficiente

...
 Priorizao == SCRUM == Product Backlog

Drill Down == FDD == Feature Breakdonw Structure

Visibilidade do Negcio == Story Mapping

Funcionalidades macro == FDD == Features

Entendimento e Comunicao == XP == User Stories

Compreenso e Validao == XP == Acceptance Criteria

Visibilidade e Melhoria do Processo == Card Wall ==

Kanban
 Ganhos
Visibilidade do Produto por todos os envolvidos
Compartilhamento de conhecimento
Colaborao ativa de todas as partes
Percepo do valor de negcio
Priorizao rpida
Diminuio do retrabalho
Aproximao de todos as papis
Melhoria contnua no processo
 Novas dificuldades
Manter Story Mapping alinhado com Product Backlog
Manter FBS atualizada
Momento de realizar a documentao formal
Perca de post it no Kanban
Momento de congelamento para Sprint
Quando usar Sprints
Nosso maior ganho foi a
Cultura
Identifique, explore e eleve a
nova restrio

Simplicidade: a arte de
maximizar a quantidade de
trabalho que no precisou ser
feito.
 Terminanos
Espero que tenham ficado curiosos

Rafael Barbosa Camargo

@rafajagua

www.agilementoring.wordpress.com
www.caipiraagil.com