pedaços de xp, fdd, scrum e kanban na análise de negócios e engenharia de requisitos
Post on 16-Apr-2017
1.742 Views
Preview:
TRANSCRIPT
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
top related