Agile Toolkit

Prof. Pedro Paulo Oliveira

Visão do produto
Ao definir a concepção de um produto, é importantíssimo que seja definida e divulgada a visão do produto. A seguir,
entenderemos algumas práticas que o mercado utiliza para definir a visão de um produto.

Elevator Pitch

Elevator Pitch é uma espécie de diálogo breve e objetivo que um indivíduo utiliza para falar a respeito de um produto,
serviço ou uma organização, demonstrando seus benefícios e valores, despertando o interesse do interlocutor.
Para utilizar essa técnica basta preencher o template a seguir (Figura 1) para que a visão de um produto, por exemplo, seja
comunicada.

Figura 1: Template Elevator Pitch.

Propriedade Intelectual Saint Paul Educacional LTDA

Visão do produto
Modelo Kano
O modelo de Kano é uma técnica que busca a melhoria de processos, produtos ou serviços ou, até mesmo, a definição e
concepção de um produto. O foco está no cliente, ou seja, o que o cliente precisa? O que ele deseja?

A partir da distribuição dos itens que geram alta satisfação aos clientes/usuários, é possível, por exemplo, definir a visão de
um produto.

Figura 2: Modelo Kano.

Propriedade Intelectual Saint Paul Educacional LTDA

Visão do produto
MVP (Minimum Viable Product)

A ideia por trás do Minimum Viable Product (em português, Produto Minimamente Viável) é, como pode ser visto na Figura
3, desenvolver uma versão de teste do projeto, com o mínimo de investimento financeiro e de tempo, mas capaz de
entregar os mesmos valores do produto finalizado. Dessa forma, a ideia pode ser testada e, se aprovada, toda a estrutura
necessária para o desenvolvimento é aplicada.

Figura 3: MVP (Paulo Caroli).

Propriedade Intelectual Saint Paul Educacional LTDA

Escrita de itens de Product Backlog
A partir do momento que se tem definida a visão de um produto, times Ágeis geralmente iniciam a fase de definição de
itens de Product Backlog (times Scrum). Um item de Product Backlog pode ser qualquer coisa que esteja em um Product
Backlog. Como você já sabe, Product Backlog é uma lista priorizada de coisas a serem feitas para um produto, que pode ser
histórias de usuário, caso de uso, funcionalidades, features, etc.

História de usuário

Histórias de usuário (user stories) descrevem seus requisitos de forma ágil. Para discutir seus detalhes, é necessária a
comunicação face a face entre o time e o cliente, encorajando o trabalho em conjunto. Cada história segue um ciclo de
vida, normalmente nascendo como um épico (histórias grandes), sendo detalhada de acordo com sua prioridade. Elas são
textuais, não necessitam de ferramenta específica, são compreensíveis por todos do desenvolvimento ou do negócio e são
descritas em cartões, também chamados de cartões de história (story card). Outras formas de documentação
complementares podem ser utilizadas juntamente. O XP não impede isso desde que sejam úteis e necessárias, tais como
protótipos ou diagramas. Alguns exemplos de histórias de usuário: “Como um contador, eu quero registrar uma
movimentação de patrimônio”, “Como uma leitora, quero pesquisar livros por categoria”.

Propriedade Intelectual Saint Paul Educacional LTDA

Escrita de itens de Product Backlog
7 Dimensões do Produto

Basicamente, esta técnica tem como objetivo facilitar o levantamento de informações fundamentais para a criação de um
produto, analisando-o sob sete dimensões (aspectos) diferentes, a saber:

 Atores
 Interfaces
 Ações
 Dados
 Regra de negócio
 Ambiente
 Qualidade
A seguir, vamos entender o que quer dizer cada uma dessas dimensões. Como exemplo, utilizamos a construção de um
aplicativo móvel para ler um jornal digital.

Atores (personas) são todos os usuários que, de alguma forma, interagem com o produto. Exemplo: leitores de jornal
digital para tablets.

Propriedade Intelectual Saint Paul Educacional LTDA

Escrita de itens de Product Backlog
Interfaces são todas as telas, os fluxos ou as aplicações que precisam ser construídas para atender a uma necessidade de
negócio. Exemplo: interface contendo uma biblioteca atualizada com as edições de um jornal digital.

Ações (verbos) são tudo o que os usuários desejam fazer ao interagir com a aplicação. Exemplo: comprar uma edição do
jornal digital.

Conforme Figura 4, note que, neste momento, já podemos dar forma a algumas user stories ou épicos. Por exemplo:

Figura 4: User story

Dados são qualquer input, arquivos, dados da base, entre outros, que são fundamentais para o funcionamento da
aplicação. Exemplo: jornal digital (PDF, HTML).

Propriedade Intelectual Saint Paul Educacional LTDA

Escrita de itens de Product Backlog
Regras de negócio servem para suportar as necessidades de negócio e devem ser implementadas na aplicação. Exemplo: as
edições avulsas só poderão ser compradas via cartão de crédito.

Ambiente é (ou são) todas as plataformas ou sistemas que serão utilizados para suportar a aplicação. Exemplo: aplicação
WEB com suporte para flash.

Qualidade é (ou são) todos os requisitos que precisam ser contemplados em uma aplicação para atender às necessidades
dos usuários. Exemplo: a leitura do jornal poderá ser feita off-line.

Propriedade Intelectual Saint Paul Educacional LTDA

Mapeamento e priorização
Story Mapping

O Story Mapping, desenvolvido originalmente por Jeff Patton, é uma ferramenta poderosa para descobrir a solução certa
para seus usuários e para evoluir à medida que se obtêm insights.

É o processo de visualização do seu produto desde a visão inicial até as atividades dos key users e prováveis releases (Figura
5). Um Story Mapping proporciona um mapeamento multidimensional do seu produto, fornecendo uma estratégia de
desenvolvimento para um aprendizado rápido.

Figura 5: Story Mapping.

Propriedade Intelectual Saint Paul Educacional LTDA

Mapeamento e priorização
Técnica MoSCoW
A técnica MoSCoW é muito utilizada para priorização de escopo, priorização de requisitos, classificação de mudanças, etc.
Aplicando essa técnica, consegue-se, por exemplo, classificar e priorizar funcionalidades com base no seu valor de negócio.
Atualmente, o Dynamic Systems Development Method (DSDM) Consortium tem os direitos de propriedade intelectual da
técnica MoSCoW, os quais foram doados pelo seu criador Dai Clegg.

O M em MoSCoW quer dizer Must Have (Deve Ter), ou seja, tudo que é imprescindível para o produto. São aquelas
funcionalidades fundamentais da sua aplicação, sem as quais a aplicação perderia totalmente o sentido.

O S quer dizer Should Have (Deveria Ter), ou seja, tudo o que é importante ter no seu produto, mas que não é
imprescindível. São funcionalidades que, se porventura não forem desenvolvidas, não farão com que o produto perca o seu
valor de negócio.

O C quer dizer Could Have (Poderia Ter), ou seja, tudo o que seria bom ter, mas não é importante. É mais ou menos como a
cerejinha do bolo. Na maioria das vezes, clientes aceitam comer bolo sem
cereja, até porque bolos sem cerejas são mais baratos.

O W quer dizer Won’t Have for Now (Não Terá por Enquanto), ou seja, tudo o que não será desenvolvido por enquanto, pois
as features classificadas com Won’t Have for Now não geram valor de negócio no momento.

Propriedade Intelectual Saint Paul Educacional LTDA

 Estimativas e métricas
Story Points

Story Points são uma unidade de medida para expressar o tamanho geral de uma história do usuário, por exemplo. Quando
estimamos com Story Points, atribuímos um valor em pontos para cada item (Figura 6). O valor bruto que atribuímos não é
importante. O que importa são os valores relativos. Uma história que recebeu uma estimativa (tamanho) de dois pontos
deve ter o dobro de estimativa de uma história que recebeu um ponto. O número de Story Points associados a uma história
representa o seu tamanho.

Figura 6: Story Points.

Propriedade Intelectual Saint Paul Educacional LTDA

Estimativas e métricas
Planning Poker
Planning Poker combina a opinião de especialistas e a analogia em uma abordagem agradável para estimar, a qual resulta
em estimativas rápidas e confiáveis.

Cada equipe pode estimar de forma independente. O Product Owner participa do Planning Poker, mas não estima. Logo
no início, cada membro do time que irá desenvolver a história de usuário recebe um baralho de cartas, tendo cada carta
os seguintes valores: 0, 1, 2, 3, 5, 8, 13, 20, 40 e 100 (parecido com a escala de Fibonacci).

Para cada história de usuário a ser estimada, um facilitador, que geralmente é o Product Owner, lê a descrição e explica o
item para os membros do time. Após serem esclarecidas as dúvidas de negócio, cada membro apresenta sua carta com
base no seu entendimento do tamanho da história. Se todos apresentarem cartas com valores similares − por exemplo, 8
−, a estimativa de tamanho fica em 8 pontos e o time passa para a próxima história de usuário. Caso haja divergência no
entendimento, ou seja, um membro do time apresentou 13 e outro apresentou 2, é feita uma discussão para se chegar a
um consenso de por que cada membro escolheu cada carta. A partir dessa discussão, é realizada uma nova rodada de
estimativas até se chegar ao tamanho da história.

Propriedade Intelectual Saint Paul Educacional LTDA

Estimativas e métricas
Velocity

Velocidade é uma medida da taxa de progresso de uma equipe. É calculada somando a quantidade de Story Points
atribuída a cada história de usuário que a equipe concluiu durante a iteração.

Se a equipe completou três histórias, cada uma estimada em cinco pontos, então sua velocidade seria de 15
pontos. Se a equipe completou duas histórias de cinco pontos, sua velocidade seria de 10 pontos. Se uma equipe
completou 10 pontos da história na última iteração, nosso melhor palpite é que eles completarão 10 pontos da
história nesta iteração (empirismo). Como os pontos da história são estimativas de tamanho relativo, essa
afirmação continua sendo verdade se eles entregam duas histórias de cinco pontos ou cinco histórias de dois
pontos.

Throughput

Throughput é uma medida que determina quantos itens (história de usuário, por exemplo) foram entregues (prontas)
em uma quantidade de tempo. Olhando pela perspectiva de vazão (ou saída), é possível afirmar que o Throughput é
uma medida que determina o quanto determinado fluxo é capaz de processar.

Propriedade Intelectual Saint Paul Educacional LTDA

Estimativas e métricas
Lead Time

Para a indústria, Lead Time representa a latência entre a iniciação e a execução de um processo. No setor de bens
industriais, a redução de tal métrica representa um aspecto-chave da manufatura enxuta (lean manufacturing). No contexto
de desenvolvimento de software, pode-se considerar o Lead Time como o número de dias entre o início e o fim do processo
de entrega de um item de trabalho (por exemplo, história do usuário, bugs, etc.).

CFD (Cumulative Flow Diagram)

CFD é um tipo de visualização que trata essencialmente de entradas e saídas. Como o próprio nome pode sugerir, o
Cumulative Flow Diagram é uma excelente forma de compreender o fluxo de trabalho ao longo de um processo, afinal o
gráfico pode nos dar um panorama geral do que está acontecendo durante o desenvolvimento de um projeto ou produto.

O CFD é um instrumento de muito valor no processo de monitoramento em projetos ágeis, pois usando-o você poderá
rapidamente analisar: quanto de trabalho foi realizado, quanto de trabalho está em progresso e quanto de trabalho ainda
precisa ser feito.

Propriedade Intelectual Saint Paul Educacional LTDA

Referências bibliográficas
Highsmith, Jim. 2004a. Agile Project Management: Creating Innovative Products. Addison-Wesley Professional.

COHN, Mike. 2005. Agile Estimating and Planning. Prentice Hall PTR

Johnson, Philip M., Carleton A. Moore, Joseph A. Dane, and Robert

S. Brewer.

2000. Emprically Guided Software Effort Estimation. IEEE Software 17(6):51–56.

Propriedade Intelectual Saint Paul Educacional LTDA

Obrigado