Roger RitterSoftware 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 OnionSegundo 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

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

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

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 OnionBerteig (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ãoDividir 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

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ênciasFÁ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

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 respostaConectado como roger. Desconectar?

Comentário

Você pode usar estas tags e atributos de HTML: <a

href="" title=""> <abbr title=""> <acronym

title=""> <b> <blockquote cite=""> <cite> <code>

<del datetime=""> <em> <i> <q cite=""> <strike>

<strong>

Publicar comentário