Elaboração de um Product Backlog Efetivo

Scrum é um framework para gerenciamento de produtos, baseado em desenvolvimento iterativo e incremental. O seu ciclo inicia com uma lista de funcionalidades desejadas para o produto, priorizada pelo cliente, então o time escolhe as funcionalidades que se compromete em desenvolver, geralmente  com iterações de 1 a 4 semanas.

Podemos notar que esse ciclo é bem definido, tendo como ponto de partida o Product Backlog, mas o Scrum não tem nenhuma definição de como construir um Backlog. Sempre nos deparamos com as perguntas:

  1. Como chegar ao Backlog?
  2. Como construir algo que tenha valor?
  3. Como encontrar a real necessidade do cliente?
  4. Como definir o que é prioridade para o cliente no primeiro momento?

Tentando responder essas perguntas, depois de diversas experiências em vários clientes, nasceu o “PBB – Product Backlog Building”. O PBB tem como principal objetivo ajudar na construção de um Backlog de uma forma compartilhada, construindo um entendimento compartilhado, levando todos os envolvidos ao entendimento colaborativo do domínio do negócio, ou seja, todos compreenderem o contexto do negócio.

Tem como objetivo vivenciar na prática a construção de um Backlog através do Product Backlog Building (PBB) um processo de construção do Product Backlog que utiliza o Backlog Canvas como ferramenta. Essa dinâmica leva todos envolvidos do negócio a uma experiência prática de elaboração e definição de um Product Backlog Efetivo totalmente consistente e alinhado com os valores de negócio do cliente.

Principais objetivos:

  1. Ajudar na construção de um BACKLOG de um forma efetiva e colaborativa.
  2. Construir um entendimento compartilhado do negócio do cliente, facilitando a descoberta e compreensão do produto.
  3. Buscar uma maneira de descrever a experiência do usuário com o produto.
  4. Facilitar a descoberta e escrita de User Stories.
  5. Priorizar por alinhamento de expectativas e metas.
  6. Ter como resultado um Product Backlog totalmente alinhado com o valor de negócio do cliente.

PBB é representado por um canvas (Backlog Canvas) que tem um fluxo bem simples e de fácil compreensão, principalmente para facilitar o entendimento do cliente, pois sua participação é de suma importância nesse processo de construção.

O fluxo de uma forma linear ajuda a organizar a visão geral do negócio e alinhar o valor de negócio, a compreenção e o que o projeto irá agregar ao final, junto com a ferramenta “Backlog Canvas” que ainda deixa todo o levantamento de requisitos organizado de forma visual.

Nenhum comentário »

Categorias deste post

Agile, Gestão de Produtos, Portfólio, Requisitos, Scrum

Requisitos Ágeis “à moda da casa” !

Gravamos um vídeo sobre a nossa compilação de aprendizados na disciplina de requisitos!

Esclarecemos, em um quadrante – Why, What, Where e How – , quais técnicas, de levantamento de requisitos e funcionalidades, podemos utilizar em processos ágeis. Conectar essas técnicas e direcionar os profissionais envolvidos; através da prática de dinâmicas baseadas em “canvas”; a alcançar um alto nível de conhecimento sobre as características técnicas e de negócio deste produto, em tempo otimizado, é o objetivo do treinamento de Requistos Ágeis – que estruturamos a partir deste nosso aprendizado!

Este treinamento será ministrado, com super descontos, e com três instrutores no do Agile Trends 2014!

Assistam o vídeo e venham participar!

Videocast Adaptworks #4 – Requisitos Ágeis

Nenhum comentário »

Categorias deste post

Agile, Eventos, Gestão de Produtos, Product Owner, Requisitos, Videocasts

TeamStart – Vídeo do webinar sobre Estimativas Ágeis

Nesse webinar promovido pela Rally Software,  faço uma dobradinha com Andreano Lanusse para dar uma visão prática de como funcionam as estimativas ágeis num projeto de software. O vídeo,  com duração de 01:36h,  mostra uma série de dicas para escopo, classificação de tamanho, tratamento da incerteza, da complexidade, orçamentação, preparação e refinamento do backlog. Bons estudos!

Nenhum comentário »

Categorias deste post

Agile, Gestão de Produtos, Product Owner, Requisitos, Videocasts

Grooming Canvas – Todas as user stories estão no inferno!

Dentro do paradigma ágil, quando estamos num processo de desenvolvimento de um produto,  buscamos iniciar todos os nossos esforços de entendimento e até mesmo de desenvolvimento por aquilo que acreditamos que será o maior valor do produto.

O  próprio Scrum estimula que um Product Owner (vulgo PO) comece a “povoar“ seu Product Backlog aplicando um forte senso de priorização baseada em valor. E de maneira geral, muitas organizações tem uma enorme dificuldade em definir  ou consensualizar o que é valor. Mas isso é assunto para outro texto.

Contudo, ao longo do tempo, comecei a notar uma tendência forte entre os POs e times de produtos. Podemos nomear essa tendência com a famosa frase de “no final, tudo é importante!”

Isso acontece pois seria uma ingenuidade achar que conseguiríamos, de imediato, já iniciar o nosso pensamento sobre o produto pelo mais importante e excluir as funcionalidades que não agregam valor. Na verdade isso é bastante perigoso. O perigo se dá pois, na tentativa de começar um Product Backlog pelo seu topo de prioridade, ordem e valor, acabamos gerando o mesmo problema de excesso de funcionalidades nos produtos desenvolvidos. Na prática, muitos Product Backlogs tem um topo muito extenso.  E é aí que mora o perigo.

Ao meu ver, isso acontece pois muitos praticantes de agile se distanciaram de um item muito importante do manifesto ágil. Na verdade, o item em questão é um dos doze princípios ágeis (pois é, eles existem! Usa Agile e não sabia disso? Shame on you!). Mas especificamente,  estou me referenciando ao décimo princípio.

O Décimo princípio do Manifesto Ágil diz:  Simplicidade – A arte de maximizar a quantidade de trabalho não realizado – é essencial.  Esse princípio, na minha opinião, é matador!  Na prática ele  toca na ferida ou na maior dificuldade na adoção do pensamento ágil na criação de produtos. Essa dificuldade se dá pelo fato de que Agile preconiza o desapego de (muitas) partes desejadas para um determinado produto.   Quando se contrasta “coisas que tem valor” versos “coisas que não tem tanto valor”,  o exercício  de priorizar e descartar fica fácil. Mas quando se contrasta “coisas que tem valor” versos “coisas que também tem valor”, aí o desafio começa.

Meu amigo Rodrigo de Toledo menciona:  “Nos tempos atuais, o trabalho do profissional de informática deveria passar a se concentrar na SÍNTESE de sistemas. Devemos remover funcionalidades ao invés de gerar mais.” Sendo assim, um dos maiores desafios econômicos e culturais do desenvolvimento de software é criar e efetivar uma inteligência saudável de descartar o máximo possível de trabalho não feito, para poder focar na menor parte de maior valor do produto.

Para ajudar a resolver esse problema (veja bem, ajudar, não resolver, ok?) há algum tempo sugiro para os POs o seguinte exercício:  Vamos adotar a premissa de que “Todas as user stories têm baixo valor até que se prove o contrário!”. A ideia é transformar esse pensamento numa espécie de mantra ou numa regra que deve ser seguida a risca a cada item desejado para o Product Backlog.

Ao seguir essa regra, O PO precisa fazer um difícil exercício. Esse exercício é difícil pois como todos os itens já nascem com baixa prioridade, o PO, tem se esforçar em fazer aquele item merecer ir para o topo do Product Backlog.

É  importante alertar que o elemento que mostrarei em seguida, não oferece uma maneira explícita para identificar a priorização.  Cabe a cada PO identificar uma forma ou técnica para fazer essa priorização. O importante que essa priorização aconteça por critérios transparentes e passíveis de discussão dentro da organização.

Para apoiar esse exercício, criei uma espécie de canvas (ver figura abaixo) para guiar, de maneira visual, esse raciocínio.  A esse canvas chamo carinhosamente de Grooming Canvas, pois  sua aplicação serve exatamente para ajudarmos o processo de grooming (refinamento e organização) dos itens de um Product Backlog.  Essa prática de grooming, no fundo, tem um caráter contínuo no desafio em tornar os itens mais prioritários em estágio de DOR (Definition Of Ready).

GroomingCanvas-ManoelPimentel

Nesse canvas,  temos 2 eixos. No eixo vertical, temos a dimensão de valor seguindo a premissa de priorização que explicamos acima. E no eixo horizontal, temos a dimensão de tamanho. A dimensão de tamanho segue o mantra de “Todas as user stories são um ÉPICO/TEMA até que se prove o contrário!”. O tamanho é outro ingrediente importante nessa conversa.  Pois se algum item tem pouco valor de negócio, não precisamos investir (ou gastar) tempo em detalha-lo. A ideia do Épico ou Tema é uma forma de identificarmos e mostrarmos o quanto um item ainda está muito grande, ou há muita incerteza, ou ainda não está num tamanho suficiente pequeno para entrar em uma Sprint.  Dessa forma, por ser um TEMA/ÉPICO isso significa que aquele item precisa ser quebrado/desmembrado em itens menores e factíveis de entendimento, por exemplo.

Juntando as regras de que todas as user stories são grandes e também têm baixo valor, notamos que por padrão, os itens do backlog já nascem no final do mesmo (representado pelo canto inferior direito do canvas). E cada vez que vamos refinando e entendo mais sobre o seu contexto de negócio, o  item vai subindo ao topo do backlog (que no canvas é representado pelo canto superior esquerdo).

Uma maneira de compreender a dinâmica e os fenômenos que ocorrerão no canvas, é usando a metáfora Dantesca para classificar as coisas. Nessa visão (ver figura abaixo), é possível resumir que todo e qualquer item, já nasce no inferno (cruel, não?) e ele precisa ser trabalhado em termos de prioridade e redução de tamanho para poder merecer entrar no céu.

GroomingCanvas-DivinaComedia-ManoelPimentel

Esse canvas acaba sintetizando uma forma um pouco contra-intuitiva para priorizar e refinar itens de um Product Owner.  Pelo fato de ser contra-intuitivo, demanda um esforço maior por parte de um PO. Lembro-me que na primeira vez que usei essa abordagem era possível ouvir (metaforicamente) os estalos das sinapses na cabeça do pobre PO.

Infelizmente apliquei e acompanhei esse canvas em poucos projetos reais. Mas mostro-a de maneira frequente aos alunos do curso de Requisitos Ágeis aqui na Adaptworks.  E durante ou após o treinamento, sempre recebemos feedbacks muito positivos quanto à mesma. Dessa forma, o objetivo desse texto foi socializar essa simples abordagem.  Desejo que outras pessoas sintam-se estimuladas a experimentarem e nos falarem dos resultados/dificuldades encontradas em sua aplicação. Maiores dúvidas ou sugestões, sintam-se convidados a me contatar em manoel@adaptworks.com.br ou pelo meu twitter: http://twitter.com/manoelp .  Até lá!

4 Comentários »

Categorias deste post

Gestão de Produtos, Product Owner, Requisitos