O Planning Onion é um modelo de planejamento para projetos de software que divide o processo em diferentes camadas, cada uma com duração e detalhamento distintos, começando pela estratégia e avançando até reuniões diárias. O autor, Roger Ritter, enfatiza a importância da cultura organizacional e critica a visão linear do modelo, sugerindo que a adaptação e a flexibilidade são essenciais para o sucesso. O artigo defende que a divisão do planejamento em partes menores pode facilitar a entrega de valor em cada fase do projeto.

1. Roger Ritter
Software Engineering, Software Quality and Projects

Planning Onion
Muitos gerentes de projetos ainda se
perguntam o que irá mudar
quando começarem a utilizar
o framework Scrum ou o framework
Kanban ou Scrum com Kanban, ‘como
assim não haverá documentação?’ ou
‘Qual é o tempo ideal para planejar um
projeto de software?’
Estas são algumas das perguntas mais
frequentes quando cogita-se em fazer
alguma migração de metodologia de
desenvolvimento. Mas como já diziam
alguns dos professores que tive:
- Tá difícil, complicado? Método Jack
resolve, é só dividir em partes! (Neste
caso, em anéis!)
Planning Onion
Segundo Fábio Cruz (2014), o Planning
Bem vindo ao
RogerRitter.com.br!
Meu nome é Roger
Ritter e trabalho com
qualidade e teste de
software desde 2010,
atualmente no Dpto
de Informática na
Universidade de Passo
Fundo.
Creio nos valores do
desenvolvimento ágil
de software , na sua
gestão e em seu
empirismo. Que a
automação de teste
possa ajudar o
trabalho do testador e
que a simplificação e
uma boa
comunicação muitas
vezes é o melhor
caminho para alguns
dos problemas da
engenharia de
software.
uPlace AvaLiter Sobre

2. Onion ou PO é um termo inglês que
teve origem a partir da cebola como
base em seus anéis, ou camadas.
Representando os diferentes níveis de
planejamento que deve-se realizar
em projetos de software.
Cada nível tem duração e
detalhamento diferente de outro,
sendo que deve-se seguir a ordem
externa para interna, ou seja, das
camadas maiores para as menores.
Analogicamente, isto significa que na
maior camada mais superficial e menos
detalhado deve ser seu planejamento,
enquanto o menor deve ser o mais
detalhado e determinístico possível.
Segundo Roach (2011), os níveis são os
momentos que deve-se realizar os
planejamentos na seguinte ordem¹:
1. Estratégia;
2. Portfólio;
3. Produto;
4. Release;
5. Iteração;
6. Daily;
1. Estratégia – A Estratégia ou
Visão Estratégica, é a primeira e
mais importante da lista, pois
define o que a empresa é, e
o que ela deseja se tornar,
definindo a camada que
regulamentará todo o restante
da execução. Esta camada trata
mais sobre a estratégia em geral
do que sobre a confecção de um
produto, mas deve-se derivar
Procurar em RogerRitter.com.br
Tags
Falha de Software
Gerência de Projetos
Relato de
Campo Testes
Não Funcionais Testes
Ágeis
Tópicos
recentes
A importância
dos Testes não
Funcionais
Planning Onion
Minhas
Experiências em
Testes Ágeis

3. aqui os prazos e os objetivos
estratégicos.
2. Portfólio - A camada de
Portfólio representa o portfólio
de projetos, que consiste em
ferramentas e como elas
devem interagir, buscando
sempre a integração.
Geralmente o proprietário desta
camada é uma gerência que
tenha uma visão ampla das
diversas linhas de produtos, no
qual as decisões devem apoiar a
Visão Estratégica e os objetivos
como o prazo e o orçamento do
projeto.
3. Produto – A camada de Produto
é o produto em questão do
projeto, pois após planejar o
Portfólio, temos vários projetos,
e ao selecionar um destes
projetos temos um
produto que uma equipe deverá
representar. Cada equipe define
uma visão sobre o produto e
descreve um roteiro de
execução. O Gerente de Projeto
valida roteiros de acordo com a
Visão Estratégica já definida e
após termos um portfólio, um
projeto destacado no qual
derivou um Produto, podemos
passar para a próxima camada, a
Release. Lembrando que
analogicamente a quarta camada
é menor que a terceira, portanto,
deverá ser mais curta.

4. 4. Release - A Release representa
um backlog priorizado
representando os planos que
seguem em direção à visão do
produto. A versão de entrega é
um módulo ou parte utilizável e
de valor que precisa ser
entregue em uma data ou prazo
específico ao cliente. O Gerente
de Projeto nesta camada,
normalmente trabalha para
priorizar partes de mais valor e
assim criar um plano de
iterações.
5. Iteração - A iteração, ou Sprint, é
um conjunto de características
(estórias) que pretende-
se entregar ao cliente. Ao
planejar, o Gerente de Projeto
revisa o plano de lançamento e o
divide em iterações
no backlog, priorizando as
entregas dos principais recursos
ou de maior valor para o cliente.
Utiliza-se nesta camada, a
orientação do plano de
lançamento já definido pelo
Gerente de Projeto que
determina a prioridade para
liberar novos incrementos. As
estórias são criadas e
compartilhadas com a equipe
que se compromete a
desenvolver um conjunto de
estórias em cada iteração nas
reuniões de planejamento.
6. Daily – Na camada mais curta a
equipe deve-se reunir

5. diariamente em 15 minutos
como o Daily Meeting do
Scrum onde relatam o que foi
concluída desde a última
reunião, qual é o plano diário e
se existem obstáculos que
alguém pode ajudar a remover.
Crítica ao Planning Onion
Berteig (2011) faz pelo menos
duas críticas ao novo conceito de
Planning Onion:
A Cultura está em falta – Berteig
(2011) acredita que a a cultura é mais
importante que a estratégia, não basta
planejar se as pessoas não tem a
cultura de executar o planejado.
Aprendizagem em Sentido Único –
Um dos maiores problemas é o sentido
único de Estratégia > Portfólio >
Produto > Release > Iteração > Daily,
que segundo Berteig (2011), limita o
aperfeiçoamento dos produtos e
algumas vezes também do processo,
defendendo que se a Estratégia estiver
equivocada todo o resto também
estará, pois trata-se de um efeito
cascata.
Conclusão
Dividir o problema em partes menores,
muitas vezes fará com que este se
torne menos complexo. A promessa do
PO também é esta, onde cada etapa do
projeto é planejado uma parte, em um
detalhe menor ou maior com o objetivo
de focar no valor a ser entregue

6. naquele momento. O PO adere as
metodologias ágeis de
desenvolvimento de software
proporcionando respostas mais
assertivas para as perguntas feitas no
início deste post. Visando as críticas,
concordo com elas e portanto não
trato como uma recomendação a
migração de um framework mais
flexível como o Scrum, por exemplo,
para implantar o PO. Mesmo assim,
acredito que o PO pode ser um passo
para posteriormente efetuar a
implantação de algum outro
framework.
Referências
FÁBIO CRUZ, “Planejando em Vários
Níveis”, (www.fabiocruz.com.br), 2014.
Artigo disponível online, através deste
link.
BERTEIG, M. “The Agile Planning Onion
is Wrong”, (www.agileadvice.com), 2011.
Artigo disponível online, através deste
link.
ROACH, T. “What does the Planning
Onion Mean to
You?”, (myagilemind.wordpress.com),
2011.
Artigo disponível online, através deste
link.
—
¹ – Fábio Cruz (2014) determina cinco

7.  Minhas Experiências
em Testes Ágeis
A importância dos
Testes não Funcionais

níveis, removendo a primeira camada
de ‘Estratégia’; Em outros links como
este, observa-se através da leitura e de
um vídeo seis níveis igualando ao
Roach (2011), porém removendo a
camada de ‘Produto’ e incluindo uma
última camada denominada de
‘Continue’ ou ‘Continuação’.
 Posted on 28 de abril de 2014 by roger
 Leave a comment
 Posted in Gerência de Projetos
 Tagged Gerência de Projetos
Edit
Deixe uma resposta
Conectado como roger. Desconectar?
Comentário
Você pode usar estas tags e atributos de HTML: <a
href=""title=""><abbrtitle=""><acronym
title=""><b><blockquotecite=""><cite><code>
<deldatetime=""><em><i><qcite=""><strike>
<strong>
Publicar comentário