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