Pedaços de XP, FDD, Scrum e Kanban na

Análise de Negócio e Engenharia de Requisitos

Rafael Barbosa Camargo@rafajagua

Analista de negócios www.agilementoring.wordpress.com

www.caipiraagil.com

O que é Análise de Negócio?

Você sabe?

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)

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 produção de um documento de requisitos e sua manutenção ao longo do

tempo.

Engenharia de Requisitos

Um Requisito consiste da definição documentada de uma propriedade ou

comportamento que um produto ou serviço particular deve atender.

Análise de Negócios e Engenharia Tradicional

Toda a análise era realizada no início do projeto

Análise de Negócios Tradicional

Toda a análise era realizada no início do projeto

Análise de Negócios Tradicional

Toda a análise era realizada no início do projeto

Concentra conhecimentoReduz comunicação

Diminui as responsabilidadesGera CYA

Indica “certeza” (ou perda de confiança)Difícil manutenção

Não inclui todas as partesNão é colaborativa

Alto retrabalhoO que fazer primeiro?

Análise e Engenharia Tradicional

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

O que é Ágil?

Você sabe?

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

Transição para Scrum

Análise de Negócio Ágil

Vamos saber mais

Análise de Negócio Ágil

Engenharia de Requisitos Ágil

Product Backlog

OK, melhoramos a priorização e a definição

em conjunto sobre as porções de software a ser

desenvolvido

Mas não era suficientePrecisávamos de mais entendimento sobre aquilo

que seria desenvolvido na IteraçãoCasos de uso eram muito grandes e estavam

confusosA qualidade era duvidosa

Introduzindo XP

User Stories

VivaCompartilhada

Colaborativa

Accpetance Criteria

Planning Poker

OK, melhoramos o entendimento, a

comunicação e a validação sobre o que temos de

desenvolverTambém está melhor pra

estimar

Mas não era suficienteNã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

Introduzindo FDD

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

Visão

Feature Breakdown Structure

Feature Breakdown Structure

OK, temos uma visão de negócio ao longo do

ProjetoEstá mais fácil para fazer

Grooming e Priorizar

Mas não era suficienteNão tínhamos visão clara da evolução do

desenvolvimento do Projeto

Gráfico não estavam representando muito a realidade

Visão

Wish List

Story Mapping

OK, temos uma visão de negócio ao longo do

ProjetoE temos uma visão

melhor da evolução do projeto

Mas não era suficienteTí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

Wish List

Car Wall

Introduzindo Kanban

OK, temos uma visão de negócio, da evolução e

do Processo

Mas não era suficiente

Como fazemos para fazer uma documentação a ser entregue, exemplo: Manual, Funcionalidades

entregues

Wiki

OK, temos um meio rápido de documentar, de

forma colaborativa e simples

Mas não era suficiente

...

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

GanhosVisibilidade do Produto por todos os envolvidos

Compartilhamento de conhecimentoColaboração ativa de todas as partes

Percepção do valor de negócioPriorização rápida

Diminuição do retrabalhoAproximação de todos as papéisMelhoria contínua no processo

Novas dificuldades

Manter Story Mapping alinhado com Product BacklogManter FBS atualizada

Momento de realizar a documentação formalPerca de post it no Kanban

Momento de “congelamento” para SprintQuando usar Sprints

Nosso maior ganho foi a Cultura

Identifique, explore e eleve a nova restrição

Simplicidade: a arte de maximizar a quantidade de

trabalho que não precisou ser feito.

Espero que tenham ficado curiosos

Terminanos

Rafael Barbosa Camargo@rafajagua

www.agilementoring.wordpress.comwww.caipiraagil.com