framework Ágil como modelo de gestÃo de …a metodologia ágil não é uma ferramenta de gestão,...
TRANSCRIPT
FRAMEWORK ÁGIL COMO MODELO DE GESTÃO DE
PROJETOS INOVADORES: ANÁLISE E ILUSTRAÇÃO
Bernardo Melonio
Raquel Cristina Lopes Viana
Projeto de Graduação apresentado ao Curso de
Engenharia de Produção da Escola Politécnica,
Universidade Federal do Rio de Janeiro, como parte
dos requisitos necessários à obtenção do título de
Engenheiro.
Orientador: Adriano Proença
Orientador: Vinicius Cardoso
Rio de Janeiro
Dezembro de 2019
2
Melonio, Bernardo
Viana, Raquel
Framework ágil como modelo de gestão de projetos
inovadores: análise e ilustração – Rio de Janeiro: UFRJ/
Escola Politécnica, 2019
X, 63 p.: il.: 29,7 cm
Orientador: Adriano Proença, D. Sc
Projeto de Graduação – UFRJ/ Escola Politécnica/
Curso de Engenharia de Produção, 2019
Referências Bibliográficas: p. 75 – 78
1. SAFe 2. Ágil 3. Framework
I. Proença, Adriano II. Universidade Federal do Rio
de Janeiro , UFRJ, Curso de Engenharia de Produção III.
Framework ágil como modelo de gestão de projetos
inovadores: análise e ilustração
3
Agradecimentos
Agradecemos a nossa família e amigos que sempre nos apoiaram e nos deram o
suporte necessário para chegarmos até aqui. Muitas vezes vocês acreditaram mais em nós
do que nós mesmos.
Agradecemos também a todos professores do corpo docente da Escola Politécnica
da UFRJ por todos os ensinamentos ao longo do curso. Em especial, agradecemos aos
nossos orientadores, Adriano Proença e Vinícius Cardoso, e a professora Maria Alice, por
terem sido essenciais em nossa formação.
A todos, nosso muito obrigado, Bernardo Melonio e Raquel Viana.
4
Resumo do Projeto de Graduação apresentado à Escola Politécnica/UFRJ como parte dos
requisitos necessários para a obtenção do grau de Engenheiro de Produção.
FRAMEWORK ÁGIL COMO MODELO DE GESTÃO DE PROJETOS
INOVADORES: ANÁLISE E ILUSTRAÇÃO
Bernardo Melonio
Raquel Viana
Dezembro/2019
Orientador: Adriano Proença
Curso: Engenharia de Produção
Em um contexto de modelo de gestão de projetos, este trabalho de graduação possui como
objetivo o entendimento e descrição do modelo SAFe, um framework ágil escalável.
Elaborando uma proposta de sua aplicação metodológica para o caso “Fabricação de
Gelato”, em uma empresa do ramo alimentício, evidenciando os ganhos potenciais ao
empregar o framework proposto. Com isso, será possível entender o potencial impacto
gerado através do SAFe, quando comparado com métodos tradicionais de gestão de
projetos.
Palavras-chave: SAFe, ágil, Framework
5
Abstract of Undergraduate Project presented to POLI/UFRJ as a partial fulfillment of
the requirements for the degree of Industrial Engineer.
AGILE FRAMEWORK AS INNOVATIVE PROJECT MANAGEMENT
MODEL: ANALYSIS AND ILUSTRATION
Bernardo Melonio
Raquel Viana
December/2019
Advisor: Adriano Proença
Course: Industrial Engineering
In a project management model context, this graduation project aims to understand and
describe the SAFe model, an agile scalable framework. By creating a proposal of its
methodological application for the case “Gelato Manufacturing” of a food company,
highlighting the gains by applying the proposed framework. With this, it will be possible
to understand the potential impact generated through SAFe, when compared to
traditional project management methods.
Keywords: SAFe, agile, Framework
6
Sumário
1. INTRODUÇÃO 10
1.1 MOTIVAÇÃO 10
1.2 OBJETIVOS 11
1.3 MÉTODO E LIMITAÇÕES 11
1.4 ESTRUTURA DO TRABALHO 12
2. CONTEXTO 13
2.1 MÉTODOS ÁGEIS 13
3. O SAFe 19
3.1 VALORES DO SAFe 19
3.2 COMPETÊNCIAS FUNDAMENTAIS 23
3.3 A QUALIDADE TOTAL COMO COMPETÊNCIA 27
4. CONFIGURAÇÕES SAFe 32
5. ESSENCIAL SAFe 35
5.1 MÉTODOS ÁGEIS 37
5.2 DESIGN E ESTRATÉGIA 39
5.3 AGILE RELEASE TRAINS - ARTs 41
5.4 MÉTODOS DE DESENVOLVIMENTO 45
5.5 PAPÉIS E RESPONSABILIDADES 52
5.6 QUALIDADE 54
5.7 LIDERANÇA 55
6. ESTUDO DE CASO 58
7. ABORDAGEM SAFe NO CASO 62
7.1 VALORES 62
7.2 COMPETÊNCIAS 63
7.3 AGILE RELEASE TRAIN - ART 64
7.4 DESENVOLVIMENTO 64
7
7.5 PAPÉIS E RESPONSABILIDADES 69
7.6 QUALIDADE 71
7.7 POSSÍVEIS BENEFÍCIOS 71
8. CONCLUSÃO 74
9. REFERÊNCAS BIBLIOGRÁFICAS 75
8
Índice de figuras
Figura 1: Utilização de métodos ágeis. Fonte: VersionOne 10th annual report ............ 15
Figura 2: Benefícios do framework SAFe. Fonte: (SAFe, 2019) ................................... 21
Figura 3: Competência Lean-agile Leadership. Fonte: (SAFe,2019) ............................ 23
Figura 4: Competência Team and technical Agility. Fonte: (SAFe, 2019) .................... 24
Figura 5: Competência DevOps and Release on Demand. Fonte: (SAFe, 2019) ........... 25
Figura 6: Competência Business Solution and Lean Systems. Fonte: SAFe .................. 26
Figura 7: Competência Lean Portfolio Management. Fonte: (SAFe, 2019) .................. 26
Figura 8: Ciclo PDCA. Fonte: Campos, 1996, p.266 ..................................................... 30
Figura 9: Ciclo PDCA para melhoria de resultados. Fonte: Campos, 1996, p.266 ........ 31
Figura 10:. Fonte: (SAFe ................................................................................................ 36
Figura 11: Processo Lean UX. Fonte: Adaptado (SAFe, 2019) ..................................... 39
Figura 12: Modelo de Design. Fonte: Adaptado do livro “Value Proposition Design”
(2018) ............................................................................................................................. 41
Figura 13: Organização em silos. Fonte: (SAFe, 2019) ................................................. 42
Figura 14: Formação do Agile Release Train. Fonte: (SAFe, 2019) .............................. 43
Figura 15: Composição do Agile Release Train. Fonte: Adaptação (SAFe, 2019) ........ 43
Figura 16: Fluxo de valor nos Agile Release Trains. Fonte: (SAFe, 2019) ................... 44
Figura 17: Relação entre objetivos do PI e da equipe. Fonte: Adaptado (SAFe, 2019) . 48
Figura 18: Fatores DevOps. Fonte: (SAFe, 2019) .......................................................... 50
Figura 19: Objetivos da primeira PI. Fonte: Elaboração Própria ................................... 66
Figura 20: Objetivos da segunda PI. Fonte: Elaboração Própria .................................... 67
Figura 21: Objetivos da terceira PI. Fonte: Elaboração Própria ..................................... 68
9
Lista de siglas
SAFe - Scaled Agile Framework
ART - Agile Release Trains
DevOps - Development and operations
JIT - Just in time
JQT – Gestão pela qualidade total
PI - Program Increment
PO - Product Owner
ROI - Retorno sobre o investimento
SM – Scrum Master
BNDES - Banco Nacional de Desenvolvimento Econômico e Social
TI – Tecnologia da Informação
10
1. INTRODUÇÃO
1.1 MOTIVAÇÃO
Uma organização deve ser capaz de se adaptar, aprender e inovar para conseguir
responder às constantes mudanças enfrentadas atualmente. A gestão dessa nova realidade
tem sido um desafio. O desenvolvimento ágil de projetos, principalmente na área de TI,
já é amplamente conhecido e executado nas empresas. Porém, as empresas têm tido a
iniciativa de cada vez mais tentar escalar essa gestão ágil não somente para um projeto
ou área da empresa, mas para a organização como um todo.
Segundo artigo disposto na biblioteca digital do Banco Nacional de
Desenvolvimento Econômico e Social (BNDES), a indústria brasileira de alimentos tem
tradicionalmente baixo potencial inovador – por exemplo em pontos como fornecedores
de máquinas, químicos e embalagens -, pois as transformações em sua vasta maioria
resultam de inovações incrementais. Normalmente as empresas desse ramo necessitam,
para inovar mais radicalmente, de um alto investimento em pesquisa e maquinário.
Levando isso em consideração, esse setor se apresenta como uma oportunidade para
ilustrar uma possível aplicabilidade de métodos ágeis em desenvolvimento de projetos,
em uma empresa do ramo, sem, em primeira instância, ser necessário um alto
investimento.
A aplicação de métodos ágeis leva em consideração conceitos e obras de autores
já consagrados utilizados de forma a dar base ao método, mas de forma adaptada às
mudanças que ocorreram entre o período da criação desses conceitos e do tempo atual,
buscando um ganho de produtividade, transformar os sistemas mais rápidos, menos
burocráticos, mais eficazes e eficientes, logo, mais efetivos.
11
A maior motivação para o presente estudo é a vontade de abordar um tema que
não é intensamente abordado na grade curricular oficial do curso e discutir a aplicação da
metodologia ágil em larga escala, na forma de estudo de caso em uma empresa conhecida
e estruturada em seus processos do ramo alimentício no município do Rio de Janeiro, com
o intuito de uma possível mudança em seu portfólio.
1.2 OBJETIVOS
O principal objetivo deste trabalho é estudar a possibilidade de
modernização/atualização do gerenciamento de projetos, não relacionados ao
desenvolvimento de softwares, através de método ágil de forma escalável, o SAFe, Scaled
Agile Framework.
O SAFe é uma metodologia de aplicação em larga em escala, com base em
princípios ágeis, utilizando diversos outros métodos já existentes como o Scrum, XP e
Kanban e experiência obtida através de implementações de larga escala. A
implementação em larga escala significa a capacidade de se adaptar a expansões,
gerenciando grandes projetos com diversas equipes.
Dessa forma, o trabalho apresenta como objetivo um estudo de caso no ramo
alimentício. Contribuindo assim, para o entendimento de novas formas de designs gerais
de gestão.
1.3 MÉTODO E LIMITAÇÕES
Para o desenvolvimento do trabalho foi realizado um estudo sobre metodologia
ágil e metodologia ágil em larga escala. Somado a isso, foi utilizado o conhecimento
adquirido ao longo da graduação do curso de Engenharia de Produção, e experiências
vividas pelos autores, seja em cursos extracurriculares ou estágios técnicos. O método
12
utilizado baseia-se no entendimento do framework em questão, o Scaled Agile
Framework (SAFe), através primeiro de sua apresentação, seguido das ferramentas e
conceitos presentes na metodologia ágil, para então, na forma de estudo de caso, elaborar
uma possível aplicação da metodologia confirmando sua capacidade de se tornar
escalável.
O projeto se limitará a analisar o caso apresentado acerca da implementação de
sorvete Gelato, sem discutir sua possível aplicação a outros projetos da empresa. A análise
se dará em forma de estudo de caso, com uma proposta de implementação, sem apresentar
seus possíveis resultados.
Com relação aos benefícios da aplicação no caso apresentado, serão confrontados
os acontecimentos reais do caso e suas compreensões versus se fosse aplicada a base
teórica do framework SAFe desenvolvido, mas sem a sua implementação e avaliação na
prática.
1.4 ESTRUTURA DO TRABALHO
O presente trabalho é dividido em uma parte expositiva e explicativa da
metodologia, seguido de uma breve contextualização sobre a estrutura organizacional da
empresa fabricante de um produto alimentício, seguido de uma sugestão de
implementação do framework apresentado para a resolução do projeto de implementação
do sorvete Gelato.
13
2. CONTEXTO
2.1 MÉTODOS ÁGEIS
A metodologia ágil não é uma ferramenta de gestão, e sim, um conjunto de
diretrizes que podem ser aplicadas em diversas metodologias existentes. O mindset
proposto nos métodos ágeis almeja a uma entrega rápida e de alta qualidade, alinhando
as expectativas dos clientes com os objetivos da empresa.
Em fevereiro de 2001 nos Estados Unidos foi criado o manifesto ágil, um conjunto
de valores e princípios necessários para a execução de um projeto ágil. Ao todo, 17
autores se comprometeram e foram responsáveis pela elaboração e disseminação do que
foi criado. O manifesto apresenta os seguintes princípios (Manifesto ágil, 2001):
“Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e
contínua de software de valor.
Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos
ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.
Entregar software funcionando com frequência, na escala de semanas até
meses, com preferência aos períodos mais curtos.
Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em
conjunto e diariamente, durante todo o curso do projeto.
Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e
suporte necessário, e confiar que farão seu trabalho.
O Método mais eficiente e eficaz de transmitir informações para, e por dentro
de um time de desenvolvimento, é através de uma conversa cara a cara.
14
Software funcional é a medida primária de progresso.
Processos ágeis promovem um ambiente sustentável. Os patrocinadores,
desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos
constantes.
Contínua atenção à excelência técnica e bom design, aumenta a agilidade.
Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou
ser feito.
As melhores arquiteturas, requisitos e designs emergem de times auto
organizáveis.
Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se
ajustam e otimizam seu comportamento de acordo”
No contexto da gestão de projetos de software, em que o cenário profissional do
setor é um dos mais vorazes e competitivos, é necessário que as empresas estejam sempre
atualizadas, para entregarem projetos eficazes e de forma rápida. Os métodos então são
aplicados para que os resultados atinjam eficiência, segurança, qualidade e celeridade,
que forneçam um benefício e vantagem para a empresa (valor para empresa) e na visão
do cliente (valor para o cliente). Normalmente, vindo de novas formas de gerenciamento,
inovação para atingimento do que foi planejado.
Entendimento e execução de projetos que lidam diariamente com imprecisão e/ou
imprevisibilidade são características inerentes ao processo de desenvolvimento de
software. Entretanto, acabam sendo características muito presentes no desenvolvimento
de quaisquer projetos, variando apenas a intensidade dos fatores para os demais casos.
15
Como a Metodologia Ágil visa minimizar os riscos relacionados às incertezas dos
projetos e prepara a empresa para os imprevistos de maneira mais natural e rápida, ela
também proporciona melhor comunicação e, o mais importante, maior satisfação dos
clientes, ela acaba tendo um alto potencial de empregabilidade em projetos dos mais
variados tipos e nichos.
Atualmente, nas universidades, os cursos delimitam, normalmente, o ensino duas
delas: O Scrum e o Kanban, que serão explicados adiante no texto. Um estudo realizado
em 2016 pela VerionOne no seu décimo reporte anual, revelou que as empresas utilizam
mais o método Scrum, para aplicar o pensamento ágil dentro da corporação.
Figura 1: Utilização de métodos ágeis. Fonte: VersionOne 10th annual report
Métodos tradicionais de desenvolvimento tendem a valorizar a extensa análise e
a criação de definições rígidas dos requisitos de forma a prezar por uma segurança e
estabilidade, muitas vezes aparente, que lhe permitem menos alterações e correções
16
futuras, e assim, menos custos. Isso acaba tornando os processos pesados e orientados a
documentação, uma vez que cada etapa tem associada ao seu término uma documentação
padrão que deve ser aprovada para que se inicie a etapa imediatamente posterior. Como
o modelo Waterfall, que descreve uma lógica sequencial de desenvolvimento de software
mas torna inflexível a divisão do projeto em fases distintas dificultando possíveis
alterações (Soares, 2004).
Segundo o Project Management Body of Knowledge (PMBOK) (PMI, 2004), a
construção de grandes soluções adota uma abordagem sequencial e controlada por
estágios e fases distintas. O trabalho é planejado e dividido antecipadamente em
requisitos detalhados, com um cronograma e orçamento fixos predeterminados para todo
o ciclo de vida. O trabalho das grandes equipes geralmente é cada um isolado em sua
parte do sistema. O progresso é verificado em marcos, mas a primeira vez que ocorre uma
integração de ponta a ponta se dá no final do ciclo de vida, o que deixa pouco tempo - ou
orçamento - para ajustes. Logo, grandes soluções acabam esperando muito tempo, por
vezes anos, para receber algum feedback dos usuários. E quando acontece, as
especificações e seus componentes ficam obsoletos antes da implementação do sistema
que, usualmente, já ocorre com atraso, acima do orçamento e com recurso e qualidade
imprevisíveis. Gerando ainda gastos futuros acima do esperado com manutenção e
operação, e além disso, baixos lucros e problemas de negócio.
O Scrum, diferente dos métodos tradicionais de gestão, acaba por aceitar a
imprevisibilidade do projeto de forma transparente, para que se permitam mudanças. Já
o Kanban é uma metodologia originalmente criada no Japão pela empresa Toyota, na
década de 60, onde tinha um papel fundamental no sistema de produção puxada e no
conceito Just in time (JIT). Segundo Lubben (1989), é uma abordagem para operar um
17
sistema de manufatura simples e eficiente capaz de otimizar o uso dos recursos de capital,
equipamento e mão-de-obra, buscando eliminar qualquer função desnecessária no sistema
de manufatura que traga custos indiretos, que não acrescente valor para a empresa, e que
impeça melhor produtividade ou agregue despesas desnecessária no sistema operacional
do cliente.
Atualmente o termo Kanban não é utilizado da maneira original empregada em
seu surgimento, é empregado utilizando somente a parte visual da metodologia, onde o
fluxo de projeto no Kanban ocorre pela divisão de um quadro em três colunas: “Tarefas
para Fazer”, “Tarefas em Andamento” e “Tarefas Concluídas”. As tarefas que precisam
ser feitas devem ser descritas em detalhes, definindo responsável, cliente, data de entrega
e outros pontos que consideráveis relevantes. À medida que vão sendo feitas, as tarefas
mudam de coluna.
Atualmente, a utilização da parte visual do Kanban também tem se tornado bem
popular. Seja de forma a organizar o fluxo de tarefas/processos no âmbito pessoal ou
profissional. Porém, os quadros e post-its vêm sendo substituídos por ferramentas
colaborativas online que espelham a metodologia. Além disso, o número de colunas varia,
tendendo a aumentar conforme as necessidades de cada negócio ou pessoa.
Aspectos a serem sempre bem observados por quem aplica o método são aqueles
que podem acabar influenciando negativamente o resultado da aplicação dos métodos.
Uma série de mudanças e adaptações podem ocorrer no andamento do projeto, sendo
importante que os prazos estabelecidos sejam cumpridos. Ou se por acaso, quando
postergados, que isso seja feito de forma clara e não abusiva com relação ao cliente. O
caráter não engessado dos grupos de trabalho nos projetos pode vir a causar certa
desordem das funções a serem desempenhadas; por isso, a comunicação e endereçamento
18
das etapas e metas a serem realizadas são fundamentais. Diferente dos modelos
tradicionais onde pode ocorrer um excesso de etapas burocráticas, que geram
documentações muitas vezes desnecessárias, aqui o ponto é a possível ausência de
documentação ou documentação informal. Esse fator pode prejudicar comunicação e
eficiência no grupo de trabalho, mas deve ser contornado pela acessibilidade àquilo que
é documentado e nitidez das informações registradas.
19
3. O SAFe
3.1 VALORES DO SAFe
O framework Scaled Agile Framework (SAFe) foi uma proposta criada por Dean
Leffingwell e Drew Jemilo, com o objetivo de expandir o Desenvolvimento Ágil a nível
organizacional, sendo uma opção para aplicação de métodos ágeis em soluções
tecnológicas de software e ambientes virtuais. Utilizando conceitos e ferramentas
conhecidas como o Scrum e o Kanban. O SAFe se propõe a estabelecer as soluções
desenvolvidas de forma escalável, não somente para um setor ou área específica dentro
do ambiente corporativo.
A aplicação do SAFe não indica um roteiro exato a ser seguido, porém alguns
pontos em comum já foram observados em vários estudos de caso, enumerados no próprio
site da empresa, como no Centers for Medicare & Medicaid Services (CMS), agência
federal do Departamento de Saúde e Serviços Humanos dos Estados Unidos que
administra o programa Medicare e trabalha em parceria com governos estaduais para
administrar o Medicaid , Programa de Seguro de Saúde da Criança e os padrões de
portabilidade do seguro de saúde e NHS Blood and Transplant (órgão público não
departamental executivo do Departamento de Saúde e Assistência Social da Inglaterra
que é responsável por otimizar o suprimento de sangue, órgãos e tecidos e elevar a
qualidade, eficácia e eficiência dos serviços de sangue e transplante) onde ela foi aplicada.
Eles giram em torno do senso de urgência para a mudança e mobilização de pessoas.
Etapas vistas como positivas são:
Inflexão - aceitar a possibilidade de que você não esteja fazendo as coisas da
melhor maneira, desafiando até as crenças ou valores de uma pessoa, buscando uma
aceitação da mudança ao invés de sua resistência;
20
Treinamento de agentes de mudança enxutos e ágeis - indivíduos e comitês fracos
raramente têm todas as informações necessárias para tomar boas decisões, por isso,
equipes com a composição correta e confiança suficiente entre os membros podem ser
altamente eficazes em ambientes de rápida evolução;
Treinamento de executivos, gerentes e líderes - não basta que a gerência se
comprometa com a qualidade e a produtividade, ela precisa saber o que deve fazer. Uma
liderança forte se faz necessária pois “patrocina” a mudança e favorece o êxito na
implementação como um todo em uma organização;
Criação de um centro de excelência Lean-Agile - um grupo menor e mais dedicado
de pessoas é necessário para conduzir a transformação em toda a organização, uma vez
que maioria das pessoas qualificadas para conduzir a mudança tem responsabilidades em
tempo integral em suas funções atuais. A criação do centro de excelência pode vir a
acontecer já depois da implementação;
Identificação dos fluxos de valor - requer a compreensão do modelo
organizacional, otimizado para facilitar o fluxo de valor entre silos funcionais, atividades
e limites. Identificar o fluxo de valor a respeito da operação, dos sistemas que suportam
esse fluxo e das pessoas que alimentam e desenvolvem esses sistemas é fator chave;
Criação de um plano de implementação - para implementar uma mudança
organizacional dessa magnitude é necessário tempo dedicado à estratégia e ao
planejamento, porém, acredita-se ser melhor planejar um pouco, executar um pouco e
aprender um pouco, pois assim adota-se uma abordagem ágil e incremental;
Preparo do lançamento e sustentação e melhorias contínuas - são as aplicações do
que foi planejado e organizado com uso dos conceitos ágeis.
21
Essa metodologia é uma abordagem comprovada e bem documentada da
implementação de métodos ágeis em larga escala. Segundo seus próprios idealizadores e
disseminadores, em informações do site da empresa, com ela foi possível observar as
seguintes melhorias:
1. De 10 a 50% funcionários mais motivados
2. Um aumento de produtividade de 20 a 50%
3. Time to market mais rápido de 30 a 75%
4. Uma redução de defeitos de 30 a 75%
Figura 2: Benefícios do framework SAFe. Fonte: (SAFe, 2019)
Para que a metodologia SAFe, Scaled Agile Framework, ou Framework Ágil
Escalável em português, seja eficaz, é necessário que toda a organização tenha o mesmo
mindset. Para isso, o SAFe é pautado em quatro valores que ajudam a ditar o
comportamento e ação de todos os funcionários de uma organização que implementa a
metodologia. Os valores são fundamentais para a eficácia do SAFe, sendo considerado a
base da metodologia.
22
O primeiro valor é o Alinhamento. Toda metodologia ágil é pautada em mudanças
rápidas, e para acompanhar esse intenso ritmo é necessário um alinhamento dos objetivos
de negócio da empresa, para que todos trabalhem em direção de um objetivo comum.
Esse alinhamento é proposto durante toda a metodologia.
O segundo é Qualidade Integrada. Esse valor prega que os padrões de qualidade
devem estar ao longo de todo ciclo de desenvolvimento. Quanto maior o sistema, mais
importante é a qualidade endêmica, para que não haja ambiguidade sobre a importância
da qualidade interna em sistemas de grande escala. Para W. Edwards Deming, em seu
livro Saia da crise:
“A inspeção não melhora a qualidade, nem garante a qualidade. A inspeção é tarde
demais. A qualidade, boa ou ruim, já está no produto. A qualidade não pode ser
inspecionada em um produto ou serviço; deve ser construído nele. “ (Deming,
Edwards, 1982, p.29)
O terceiro valor é Transparência, sendo fundamental para manter a motivação na
equipe. Em uma execução ágil, é natural e esperado que aconteçam erros. Mas sem ela,
os fatos são obscuros e a tomada de decisões é baseada em suposições especulativas e na
falta de dados. A transparência é um facilitador de confiança, fornecido por meio de várias
práticas do SAFe: Executivos, Lean Portfolio Management - apresenta como propósito,
fornecer fundos de estratégia para as operações do portfólio Agile e governança lean- e
outras partes interessadas podem ver o Kanban do portfólio e os backlogs - lista ou resumo
de itens ou atividades a serem feitos - do programa, e eles têm um entendimento claro da
situação atual.
O último valor é a Execução de Programas. Esse valor é a atividade fim da
metodologia, é ele que prega a execução e contínua entrega de valor. O desenvolvimento
23
de soluções complexas é difícil, portanto, com os três primeiros valores presentes na
equipe o foco na execução é facilitado, e consequentemente, a execução e entrega de valor
dos produtos finais.
3.2 COMPETÊNCIAS FUNDAMENTAIS
O termo competências fundamentais é utilizado por Leffingwell e Jemilo, de
maneira a estabelecer os níveis de atuação no desenvolvimento dos processos e das
soluções pautadas nos métodos ágeis, como se fosse building blocks. Para evitar possível
engano com relação a mesma terminologia (core competencies) também utilizada por C.
K. Prahalad e Gary Hamel, em um artigo publicado para o Harvard Business Review em
1990 - criada para definir a principal ou principais competências de uma empresa,
caracterizando assim aquilo que a possa fazer se diferenciar das demais -, trataremos tais
competências como competências fundamentais.
O SAFe estabelece cinco competências fundamentais que são necessárias para
conseguir entender e implementar sua metodologia. Cada competência é um conjunto de
conhecimentos, habilidades e comportamentos relacionados, que juntos permitem que as
empresas obtenham a melhor qualidade e valor no menor tempo sustentável possível.
Cada competência é brevemente descrita a seguir, visando apresentar uma base para a
explicação aprofundada do framework mais à frente.
Figura 3: Competência Lean-agile Leadership. Fonte: (SAFe,2019)
24
A competência Liderança Lean-Agile descreve como os líderes conduzem e
sustentam a mudança organizacional, capacitando indivíduos e equipes a atingir seu
maior potencial. Eles fazem isso aprendendo, exibindo, ensinando e treinando a
mentalidade, valores, princípios e práticas Lean-Agile da SAFe. Ou seja, são facilitadores
essenciais para o sucesso da equipe. A responsabilidade final pela adoção bem-sucedida
da abordagem Lean-Agile está nos gerentes, líderes e executivos da empresa. O resultado
são funcionários mais engajados, com maior produtividade e inovação. No gerenciamento
de projetos clássico, existe um maior distanciamento entre os líderes e a equipe.
Normalmente, os líderes possuem maior experiência e responsabilidade, mas devido a
estrutura acabam não transmitindo isso para a equipe de forma positiva.
Figura 4: Competência Team and technical Agility. Fonte: (SAFe, 2019)
A competência Equipe e Agilidade Técnica descreve as habilidades críticas -
como colaboração, proatividade, determinação e adaptabilidade - e os princípios e
práticas necessários para criar equipes Agile de alto desempenho que produzem soluções
técnicas de alta qualidade e bem projetadas. O resultado é aumento da produtividade,
menor tempo de colocação no mercado e entrega previsível de valor. Em outros modelos,
as equipes formadas são fixas e o que varia é somente a demanda de projetos (tipo, prazos
e etc). Com construção de uma equipe técnica qualificada e específica para a resolução
de determinado tipo de projeto, observa-se uma melhora na qualidade e produtividade
25
daquilo que é entregado. Diferentemente do modelo Waterfall onde os projetos são
encaminhados aos setores já existentes no organograma da empresa.
Figura 5: Competência DevOps and Release on Demand. Fonte: (SAFe, 2019)
A terceira competência é DevOps e Liberação sob Demanda. Segundo a Linux,
DevOps é um termo criado para descrever um conjunto de práticas para integração entre
as equipes de desenvolvimento de softwares e operações/apoio envolvidas, com a adoção
de processos automatizados para produção rápida e segura de aplicações e serviços. A
princípio, as áreas de Desenvolvimento e Operações podem ser contraditórias em seus
objetivos, onde a primeira já se nota influenciada por um ambiente mais dinâmico e em
processo de entregas mais rápidas, mas a segunda ainda busca o mínimo de alterações
possíveis no ambiente produtivo, pois elas podem gerar um novo ponto de instabilidade.
O conceito acaba por propor novos pensamentos sobre o trabalho para a valorização da
diversidade de atividades e profissionais envolvidos e atitudes colaborativas. Ou seja, é
uma proposta de integrar diferentes tipos de conhecimento. Muitas vezes conhecimentos
tácitos daqueles que fazem a produção que, com esse trabalho desenvolvido em conjunto,
podem ser compartilhados e difundidos.
Essa competência descreve como implementar o DevOps, e um pipeline de
entrega contínua, fornece à empresa a capacidade de liberar valor, no todo ou em parte, a
qualquer momento necessário para atender à demanda do mercado e do cliente. Isso
26
permite que a organização reduza os custos de desenvolvimento, reduza os riscos e
manobre a concorrência.
Figura 6: Competência Business Solution and Lean Systems. Fonte: (SAFe, 2019)
Uma nova abordagem para criar essas grandes soluções é evidenciada na quarta
competência: Sistemas Lean e Soluções de Negócios, que descreve como aplicar os
princípios e práticas Lean-Agile à especificação, desenvolvimento, implantação e
evolução de aplicativos de software grandes/complexos e sistemas ciber-físicos focados
na entrega de valor baseado em fluxo, facilitando assim a tomada de decisões durante
todo o ciclo de vida do sistema e produtos. Aplicativos de streaming de música, filmes ou
jogos são um bom exemplo, pois necessitam de constante melhorias nos sistemas e tem
impacto direto na estrutura do negócio.
Figura 7: Competência Lean Portfolio Management. Fonte: (SAFe, 2019)
Um portfólio SAFe é uma instância única do Framework com um conjunto de
fluxos de valor para um domínio específico. Cada fluxo de valor fornece um conjunto de
soluções de software e sistema que ajudam a empresa a cumprir sua estratégia de
27
negócios, fornecendo valor diretamente ao cliente ou no suporte a processos de negócios
internos.
Sendo a última competência a Gestão de Portfólio Lean que alinha estratégia e
execução, aplicando abordagens de pensamento enxuto ao financiamento de estratégias e
investimentos, operações ágeis de portfólio e governança. Com isso, essas colaborações
dão à empresa a capacidade de executar os compromissos existentes de maneira confiável
e permitir melhor a inovação. A empresa que trabalha com serviço de streaming de
música, podcast e vídeo de origem sueca e fundada em 2006, Spotify, pode ser utilizada
como exemplo disso. Segundo Henrik Kniberg - consultor e um dos responsáveis
pelo design recente do modelo de gestão da empresa – em palestra do evento Agile
Sverige (Suécia Ágil) no ano de 2014, associou a abordagem própria de gerenciamento
de portfólio que simplifica processos para incentivar lançamentos pequenos e frequentes,
mas que permaneçam alinhados com as crenças da empresa, permitiu liberações
dissociadas dos serviços fornecidos que acabaram por favorecer seu planejamento
estratégico.
Logo, as cinco competências apresentadas funcionam em conjunto estabelecendo
os níveis de ação de alguns atores e setores chave para o desenvolvimento dos processos.
Além dessas competências fundamentais, e em alinhamento com os valores do SAFe,
identificamos que a qualidade é um valor que se encaixa com os conceitos apresentados.
De forma a complementar essas competências, será introduzido a seguir a definição de
Qualidade Total.
3.3 A QUALIDADE TOTAL COMO COMPETÊNCIA
Apesar do framework SAFe não classificar a qualidade total como uma
competência fundamental, é possível perceber o quanto a qualidade permeia o framework.
28
Além de todas as competências mencionadas anteriormente, o fator qualidade também se
mostra presente e de certa forma pode ser considerado como uma competência
fundamental. Esse conceito foi primeiramente associado à definição de conformidade às
especificações. Posteriormente o conceito evoluiu para a visão de Satisfação do Cliente
que passou a considerar fatores como prazo e pontualidade de entrega, condições de
pagamento, atendimento pré e pós-venda, flexibilidade, entre outros. Qualidade passou a
ser peça fundamental no posicionamento estratégico da empresa perante o Mercado.
Desenvolvido por estudiosos americanos como Deming, Juran e Feigenbaum, surge então
o termo Qualidade Total que representa a busca da satisfação, não só do cliente, mas de
todos os “stakeholders” (entidades significativas existentes na empresa) e também da
excelência organizacional da empresa.
A Gestão pela Qualidade Total (GQT) significa criar, intencionalmente, uma
cultura organizacional em que todas as transações são perfeitamente entendidas e
corretamente realizadas e onde os relacionamentos entre funcionários, fornecedores e
clientes são bem-sucedidos (Crosby, 1998). Ou seja, é uma abordagem abrangente que
visa melhorar a competitividade, a eficácia e a flexibilidade de uma organização por meio
de planejamento, organização e compreensão de cada atividade, envolvendo cada
indivíduo em cada nível, sendo útil em todos os tipos de organização.
Duas ferramentas conhecidas e difundidas são os 5S e o PDCA. Os 5S são
razoavelmente conhecidos na indústria como forma de melhorar a aparência do ambiente
de trabalho, aparentemente dirigidos à simples organização do espaço. São eles:
1. SEIRI (organização e senso de utilização)
2. SETON (arrumação e ordenação)
3. SEISO (Limpeza)
29
4. SEIKETSU (padronização)
5. SHITSUKE (disciplina)
No Japão, o programa 5S se mostrou uma ferramenta eficaz para criação de um
senso de “pertencimento” nas pessoas, que deu origem à motivação para participar mais
fundo e contribuir melhor em todas as atividades.
O Ciclo PDCA foi muito difundido nos meios industriais, mas hoje já se encontra
aplicado nos mais diversos setores e ambientes empresariais. Trata-se de um método
simples para organizar e sequenciar a busca soluções de problemas e melhoria de
processos. Esta é a sequência do ciclo PDCA:
P- Plan (Plano): Investigando as causas e consequências dos problemas é
elaborado um plano para que os problemas deixem de acontecer ou que pelo menos
possam ser isolados. Tudo isso através de um levantamento feito em cada área
investigando os principais pontos: problemas, causas, consequências, soluções possíveis
e tempo estimado para a resolução do problema.
D- Do (Fazer): Estágio de implementação do plano, onde é determinado o que
fazer, quem irá fazer e quando deverá agir.
C- Check (Verificar): Estágio onde as pessoas envolvidas para resolução do
problema ou melhoria do método atuarão para saber se as medidas tomadas para
eliminação do problema ainda estão sendo tomadas.
A- Action (Ação): Momento em que, percebendo que o problema (falha) voltou,
toma-se as medidas necessárias para correção.
30
Figura 8: Ciclo PDCA. Fonte: Campos, 1996, p.266
Ainda, de acordo Campos (1996), o método PDCA quando empregado para
melhoria de resultado consta de:
1- um ciclo de manutenção cujo objetivo é a previsibilidade dos resultados. Para
isto, no ciclo de manutenção, deve-se cumprir os padrões, atuando no resultado e nas
causas dos desvios, quando indicado no procedimento operacional;
2- um ciclo de melhorias, pode ter como um dos objetivos obter competitividade
para a empresa através da melhoria contínua dos resultados. As melhorias são
conseguidas pela análise do processo e adoção de novo padrão.
31
Figura 9: Ciclo PDCA para melhoria de resultados. Fonte: Campos, 1996, p.266
Ou seja, o ciclo PDCA passa a ser aplicado a cada interação no desenvolvimento dos
processos e se torna um condicionante a qualidade do produto final – em alinhamento
com o valor SAFe Qualidade Integrada. Assim, o conceito de Qualidade Total passa a
permear todos os níveis de atuação, o que caracteriza uma competência, e pode ser
qualificado como uma competência adicional.
32
4. CONFIGURAÇÕES SAFe
O modelo SAFe propõe distinguir quatro configurações, cada uma adequada a
diferentes realidades.
A primeira configuração, é a mais simples, é a “Essencial”. Ela apresenta
elementos mínimos suficientes para o sucesso da implementação, e somente três
competências fundamentais: Liderança Lean-Agile, Equipe e Agilidade Técnica e
DevOps e Liberação sob Demanda. Essa versão é considerada a base para todas as outras.
A segunda configuração, chamada de “Large Solutions” é para empresas que estão
criando grandes e complexas soluções, mas que não exige a criação do nível de portfólio,
usada geralmente em casos que se tenha um ou dois projetos complexos que necessitem
de diversos times diferentes para realizar a entrega, sendo mais comum em indústrias
aeroespaciais e de armas. Essa configuração apresenta as seguintes quatro competências
fundamentais: Liderança Lean-Agile, Equipe e Agilidade Técnica, DevOps e Liberação
sob Demanda e Sistemas Lean e soluções de Negócios.
Outra configuração possível é a chamada “Portfólio”, desenvolvida para prover
estratégia de portfólio e investimento, além de um portfólio ágil. Essa configuração é mais
robusta que as outras duas e apresenta como competências fundamentais: Liderança
Lean-Agile, Equipe e Agilidade Técnica, DevOps e Liberação sob Demanda e Gestão de
Portfólio Lean. Deve ser usada por organizações que estão interessadas em alinhar seu
desenvolvimento ágil a um ou dois fluxos de valores a diversos times ágeis.
A última configuração possível, e mais completa é a “Full” que suporta a
construção de grandes e integradas soluções que tipicamente requerem um grande número
33
de funcionários para o desenvolvimento e manutenção. Essa configuração utiliza todas as
competências fundamentais já apresentadas.
Um framework deve ser visto como uma proposta, e nunca como uma regra, uma
vez que no mundo corporativo cada empresa apresenta diferentes particularidades. Cabe
analisar o problema, escolher o framework adequado, e caso necessário, fazer as devidas
adaptações.
Devido ao perfil da organização que será considerada no caso estudado, será
criado um framework com base na primeira configuração citada, “Essencial”, para que a
organização consiga rodar de maneira básica e eficiente alguns projetos pertinentes de
maneira ágil.
Analisou-se que a utilização de qualquer outro dos frameworks disponíveis seria
de extrema dificuldade, com potencial geração de desperdícios e aproveitamento
ineficiente das ferramentas disponíveis.
O framework Portfólio SAFe, por exemplo, é melhor empregado para fornecer
estratégia de portfólio e financiamento de investimentos. Situações que não se aplicam a
empresa em questão, uma vez que o escopo de atuação é limitado e os investimentos são
padronizados. Já o framework Large Solution SAFe, apesar de ser indicado para empresas
que que querem construir grandes e complexas soluções, possui uma aplicabilidade mais
rebuscada e necessidade de conhecimento interno maior das características de seus
processos.
Uma vez que uma organização como a analisada pode ter dificuldades iniciais de
adesão da metodologia, devido ao desconhecimento da mesma e falta de engajamento das
partes necessárias para seu funcionamento. Então, faz sentido a utilização de um modelo
34
básico com um subconjunto que reúna e descreva os elementos mínimos necessários para
uma melhor implementação.
Como a visão essencial apresenta as funcionalidades básicas, e dado os motivos
apresentados anteriormente, foi escolhido explorar esta configuração que servirá como
base para o desenvolvimento de um framework adaptado a realidade do caso do sorvete
Gelato, que será detalhado mais à frente.
35
5. ESSENCIAL SAFe
Nessa configuração, temos o seguinte framework:
36
Figura 10:. Fonte: (SAFe
37
5.1 MÉTODOS ÁGEIS
No canto superior esquerdo, podemos ver que o framework pode se aplicar a
empresas, que apresentam estratégia, missão e valor, ou ao governo, ajudando
organizações do setor público.
Na lateral esquerda, temos:
● Visão: Uma descrição do estado futuro da Solução em desenvolvimento. Reflete
as necessidades do cliente e das partes interessadas.
Assim como no ambiente corporativo de forma geral, a Visão deve fornecer e
limitar um contexto mais amplo descrevendo mercados, segmentos de clientes e
necessidades do usuário estipulando algo ambicioso e alcançável. No caso do
SAFe, ela deve ser aplicada em qualquer nível, e por isso se encontra à esquerda
na área de medições. Embora seu foco esteja tipicamente na solução, uma visão
do portfólio também é relevante, refletindo como os fluxos de valor irão cooperar
para alcançar os objetivos da empresa. As equipes ágeis também podem ter sua
própria visão para comunicar sua parte no desenvolvimento da solução. Ambas
sempre alinhadas com a visão geral.
● Equipe do sistema: É uma equipe ágil especializada que auxilia na criação e
suporte do ambiente de desenvolvimento ágil, geralmente incluindo o
desenvolvimento e a manutenção da entrega. No SAFe, elas não são
independentes. Pelo contrário, fazem parte dos ARTs, Agile Release Trains – uma
equipe duradoura de equipes Agile, que desenvolve, distribui e, quando aplicável,
opera uma ou mais soluções em um fluxo de valor - e são muito úteis nos
complexos desafios de integração em grande escala. Como inicialmente a
transição para o Lean-Agile exige um trabalho adicional de infraestrutura para
38
integração dos ativos de solução, equipes do sistema são formadas e ajudam na
construção desses ambientes e sistemas de solução. Além de demonstrar a solução
à medida que ela evolui.
Após amadurecimento da infraestrutura, as Equipes do Sistema são às vezes
eliminadas de um ART, e as responsabilidades pela manutenção e uso dos
sistemas passam a ser desempenhadas pelas equipes de desenvolvimento. Em
soluções maiores, é mais provável que o conhecimento especializado permaneça
com uma ou mais equipes de sistema, onde a centralização de certas pessoas,
habilidades e ativos técnicos oferece o melhor valor econômico.
● Lean User Experience (Lean UX): É uma mentalidade, cultura e um processo que
abrange os métodos Lean-Agile, como visto anteriormente. Ele implementa a
funcionalidade em incrementos mínimos viáveis e determina o sucesso medindo
os resultados em relação a uma hipótese de benefício. Incentivando uma visão
muito mais abrangente do porquê de um recurso existir, da funcionalidade
necessária para implementá-lo e dos benefícios que ele oferece. Um processo
Lean-UX deve passar de uma abordagem especializada em silos para um modelo
de design multifuncional e colaborativo. Ao obter um feedback imediato para
entender se o sistema atenderá aos objetivos reais de negócios, cria-se um sistema
de circuito fechado para definir e medir valor.
O processo Lean UX, pode ser descrito da seguinte forma:
39
Figura 11: Processo Lean UX. Fonte: Adaptado (SAFe, 2019)
A hipótese do benefício é criada, em seguida um design colaborativo de solução.
Com uma hipótese e um design, as equipes podem prosseguir para implementar a
funcionalidade em um Recurso Comercializável Mínimo (MMF), que deve ser a
funcionalidade mínima que as equipes podem criar para saber se a hipótese do benefício
é válida ou não. Em seguida, deve-se avaliar e analisar se as funcionalidades criadas,
cumpriram a hipótese de benefício criado. É possível notar sua diferença para o modelo
tradicional de gerenciamento de projetos, em que seu design não é colaborativo e não é
feito em etapas, apresentando primeiro seu recurso comerciável mínimo.
5.2 DESIGN E ESTRATÉGIA
Segundo Bruce Archer (1965), engenheiro mecânico britânico e mais tarde
professor de Design Research no Royal College of Art, o desafio mais fundamental das
ideias convencionais sobre design tem sido a crescente defesa de métodos sistemáticos
de solução de problemas, emprestados de técnicas computacionais e da teoria de
gerenciamento, para a avaliação de problemas de design e o desenvolvimento de soluções
de design.
40
Tendo sua base nos domínios da arquitetura e design industrial, as pesquisas em
design de engenharia se desenvolveram e hoje possuem as mais variadas áreas de atuação,
desde o design industrial até o design thinking. Logo, mudanças de aplicação de
metodologias, sistematicamente, implicam em uma mudança de design, muitas vezes
física e nos processos.
Num olhar estratégico, uma mudança de design deve carregar valor. Caso
contrário, ela será apenas uma mudança sem objetivos. Sendo assim, segundo o livro
Value Proposition-Design, a criação da proposta de valor é de extrema importância. E
não importando a área ou setor da empresa, todos possuem clientes, comunicam-se, não
devem se basear em suposições, mas sim buscar a empatia com o cliente e gerar valor.
Por isso é necessária uma combinação entre o entendimento das necessidades do cliente
e a criação da proposta de valor. Nessa análise são levados em consideração fatores como:
as dores do cliente, cadeia de valor, tipo de produto/serviço oferecido, possíveis riscos e
benefícios. Tudo isso para aplicar um modelo de: Design, Teste e Evolução.
Na etapa de Design é criado o conceito da solução, onde os fatores citados acima
devem ser bem apurados. Em seguida, na fase Teste, ocorrem análises do que foi
desenvolvido e sua aplicação na prática, normalmente em algum tipo de amostra ou
ambiente que possa ser controlado. Para que se possa deduzir, aprender e propor
melhorias. Que serão melhor avaliadas e colocadas em prática ou não na fase de
Evolução. As fases são representadas através de um ciclo, uma vez que melhorias
contínuas, com o tempo, podem alterar o design inicial.
41
Figura 12: Modelo de Design. Fonte: Adaptado do livro “Value Proposition Design” (2018)
5.3 AGILE RELEASE TRAINS - ARTs
Um dos problemas mais comuns no desenvolvimento tradicional: as equipes que
trabalham na mesma solução operam de forma independente e sem sincronia. Isso torna
extremamente difícil integrar todo o sistema rotineiramente.
Organizadas em torno dos fluxos de valor significativos da empresa para criar
soluções que ofereçam benefícios ao usuário final e existindo apenas para cumprir essa
promessa, os Agile Release Trains (ART) alinham as equipes a uma missão de negócios
e tecnológica comum. Agile Release Trains (ART) é a integração de equipes ágeis, sendo
multifuncionais e tendo todos os recursos - software, hardware, firmware e outros -
necessários para definir, implementar, testar, implantar, liberar e, quando aplicável,
operar soluções.
Em uma organização funcional, os desenvolvedores trabalham com
desenvolvedores e os testadores trabalham com outros testadores, arquitetos e
engenheiros de sistemas trabalham uns com os outros, e as operações funcionam sozinhas.
42
Embora haja razões pelas quais as organizações evoluíram dessa maneira, o valor não flui
rapidamente, pois deve atravessar todos os silos, como mostra a imagem a seguir.
Figura 13: Organização em silos. Fonte: (SAFe, 2019)
Em vez disso, o ART auxilia o desenvolvimento de um pensamento do sistema
como um todo, facilitando o fluxo de valor da ideia através da implantação e liberação, e
nas operações, como mostra a figura a seguir.
43
Figura 14: Formação do Agile Release Train. Fonte: (SAFe, 2019)
A equipe ágil do SAFe é multifuncional e tem as seguintes responsabilidades:
● Definir – Elaborar e projetar recursos e componentes
● Criar – Implementar recursos e componentes
● Testar – Executar casos de teste para validar recursos ou componentes
● Implantar – Mover recursos para ambiente de teste a produção
Figura 15: Composição do Agile Release Train. Fonte: Adaptação (SAFe, 2019)
44
Uma consideração primária a ser feita para o desenvolvimento de uma solução é
o tamanho, que é definido e determinado pelo Engenheiro do ART - explicado nos
próximos tópicos. Baseado no número de Dunbar, que sugere um limite no número de
pessoas com quem se pode formar relacionamentos sociais efetivos e estáveis, o limite
superior é estabelecido. O limite inferior é baseado em observação empírica dos criadores
do framework SAFe. Sendo assim, segundo eles, ARTs eficazes normalmente consistem
em 50 - 125 pessoas. No entanto, grupos com menos de 50 pessoas ainda podem ser muito
eficazes e oferecem muitas vantagens sobre as práticas, dependendo do tamanho da
empresa. Dada essas restrições de tamanho dos grupos, existem dois padrões principais
na configuração de design dos ARTs: Único ART - quando fluxos de valor são menores;
e Vários ARTs - quando fluxo de valor é maior. Nesse último caso, as empresas criam
Trem de Soluções, que alinham os ARTs a uma missão compartilhada e coordenam os
esforços de ARTs e fornecedores, ajudando a gerenciar o risco e a variabilidade inerentes
ao desenvolvimento de soluções em larga escala com o suporte de funções, artefatos e
eventos adicionais do SAFe.
Figura 16: Fluxo de valor nos Agile Release Trains. Fonte: (SAFe, 2019)
45
Ao longo do fluxo de valor, os ARTs têm papéis fundamentais. Um fluxo de valor
pequeno, pode ser implementado com somente um ART, ao passo que fluxos de valores
maiores, podem necessitar de diversos ARTs.
O pipeline de entregas contínuas dos ARTs pode ser dividido em quatro partes:
● Exploração contínua: Responsável pela visão holística da hipótese, da ideia da
solução, e de métricas de sucesso.
● Integração contínua: Responsável pela entrega da parte técnica da solução, como
seu desenvolvimento e teste
● Desenvolvimento contínuo: Responsável por escalar a solução e acompanhar seu
desenvolvimento
● Entrega sob demanda: Responsável pela entrega final, seja por completo ou
incremental, medição do real impacto após a entrega do produto, e aprendizado
com o feedback.
5.4 MÉTODOS DE DESENVOLVIMENTO
Como outros frameworks, o SAFe também se abastece de conceitos criados
anteriormente, que possibilitam uma melhor organização e comunicação entre membros
de um time. Para o completo entendimento, será explicado brevemente dois métodos que
serviram como base para a criação do SAFe: o Kanban e o Scrum.
O Kanban, atualmente, é visto como um conceito relacionado com a utilização de
cartões como post-it para indicar o andamento dos fluxos de gestão. Neles são destacados
o andamento de tarefas como “para executar/ backlog”, “em andamento”, ou “finalizado”.
Conforme as tarefas forem avançando no desenvolvimento, os post-it vão sendo
46
colocados na fase correspondente. Esse método ajuda visualmente a todos da equipe
saberem como anda o andamento de suas tarefas, criando uma visão global do projeto.
Já no Scrum, os projetos são divididos em ciclos, chamados de sprints, que
representa um conjunto de atividades que deve ser realizado em um período de tempo.
No início de cada sprint, é feito uma reunião de planejamento, onde os itens do backlog
serão priorizados.
Em seguida, o time começa a executar as atividades planejadas, mantendo
atualizado o Kanban da sprint. Além disso, todo dia é feita uma reunião de atualização,
que cada membro deve informar o que fez no dia anterior, o que fará nesse, e quais as
dificuldades que está enfrentando. O intuito dessa reunião, é passar o andamento das
tarefas para a equipe, assim como as dificuldades de execução, para que de uma forma
colaborativa, a equipe consiga avançar.
Ao final da Sprint, é feita a reunião de Review, ou revisão, em que o que foi feito
é apresentado e avaliado se a equipe conseguiu cumprir o objetivo da sprint, essa reunião
é feita com todos os envolvidos no desenvolvimento, e os clientes finais do projeto. Após
essa reunião, é feita a reunião Retro, em que a equipe se avalia, e decide quais pontos
devem melhorar para a próxima Sprint.
O método Scrum foi adaptado para o SAFe, porém manteve seus rituais
apresentados. Uma mudança é a não utilização do termo “sprint” e sim “incremento”.
Vale ressaltar, que além do backlog, para o SAFe, precisa ser definido os Non Functional
Requirements - NFRs, ou requerimentos não funcionais, que são atributos que servem
como restrição do design, como confiabilidade, desempenho, capacidade de manutenção,
usabilidade e escalabilidade.
47
O método de entrega do SAFe é em incrementos, ou seja, a solução é liberada de
uma forma ‘lite’, básica, no início, para só depois ir recebendo incrementos e
aperfeiçoando-se.
Como apresentado na imagem do framework, sua entrega começa, assim como no
Scrum, com uma etapa de planejamento, chama de Program Increment planning (PI
planning), um evento presencial que alinha todas as ARTs a uma missão e visão
compartilhadas.
Os objetivos do PI e os planos de iteração são criados de baixo para cima, pelas
equipes do Agile que estimam e identificam sua parte da solução durante o PI Planning.
Eles são resumidos, definidos em pequenas sentenças de fácil entendimento, até o nível
de programa e depois selecionados, identificados por sua relevância, para o nível de
solução. A seguir um exemplo (display) de como é organizada essa cadeia de iterações.
O exemplo se tratada de um aplicativo de corrida, que tem como objetivos da
solução publicar o aplicativo para IOS, prova de conceito do radar – Se resume em
denominar um modelo prático que possa provar o conceito teórico estabelecido do radar
que é um sistema de detecção de objetos, auxiliando o carro de corrida utilizado no
aplicativo a detectar objetos ao longo do caminho- e a melhoria da experiencia do usuario.
48
Figura 17: Relação entre objetivos do PI e da equipe. Fonte: Adaptado (SAFe, 2019)
O intuito é resumir os objetivos da equipe nos objetivos do PI planning em um
formato adequado para comunicação de gerenciamento. Eles precisam ser SMART (do
inglês: Específico, Mensurável, Alcançável, Realista e com Tempo Limite) para que não
sejam nebulosos e não verificáveis, assim como os objetivos de expansão precisam ser
mapeados e ambos alinhados com o valor de negócio estabelecido no âmbito estratégico.
O que no Scrum é chamado de sprint, no SAFe é chamado de Program Increment
(PI), e geralmente tem a sua duração em torno de 8 a 12 semanas. Antes de se começar
a rodar o incremento, são definidos com base no backlog e suas features os objetivos da
PI. Features são requisitos de parte do produto final a ser entregue.
Cada feature que deve ser entregue do backlog, vai demandar objetivos
específicos, que devem ser entregues pelo time. Ao longo desse tempo do PI, são rodados
diversos ciclos PDCAs, sempre que possível, e o objetivo de cada iteração deve estar
49
alinhado com os objetivos do PI. Na figura, por exemplo, a feature “Melhorar controle de
movimentos” irá determinar alguns objetivos e parâmetros necessários para a entrega.
Durante o desenvolvimento da PI, os enablers são responsáveis por suportar as
atividades e trazer visibilidade a todo o trabalho necessário para suportar uma entrega
condizente com os requerimentos. Com o passar do desenvolvimento, muitos enablers
acabam se tornando uma NFR, virando um requisito. Por exemplo, é possível existir um
enabler que acaba com bugs em determinada etapa do desenvolvimento, e depois de
implementado, passando a ser um requisito para toda a solução.
Ao final de cada PI, existe uma inspeção e adaptação, podendo ser
correspondentes a retrospectiva e revisão do Scrum. Nessa etapa, o ART avalia a solução
entregue, compara com os objetivos definidos anteriormente, avalia o que deve ser
melhorado, e inicia-se uma nova PI.
Um elemento muito importante para a mantimento e continuidade do fluxo de ágil
na organização é o “Architectural Runway”. Que consiste em código, componentes e
infraestrutura técnica, dependendo do projeto, necessários para dar suporte à
implementação de recursos de alta prioridade e de curto prazo, sem atraso e re-projeto
excessivos. Uma não estruturação ou investimento suficiente nesse elemento, implica
numa quebra nas entregas contínuas dos ART’s a cada novo recurso empregado,
dificultando assim o ciclo de desenvolvimento.
Para garantir uma entrega integrada, o SAFe utiliza o conceito de DevOps, que
consiste nos seguintes fatores:
50
Figura 18: Fatores DevOps. Fonte: (SAFe, 2019)
● Cultura responsabilidade compartilhada - entrega rápida de valor em todo
o fluxo de valor, incluindo tudo que contribui para a criação de valor
(Gerenciamento de produtos, desenvolvimento, testes, segurança,
conformidade, operações). A cultura permeia e fortalece todos os
conceitos de DevOps da figura acima, uma vez que influencia naquilo que
gera valor para empresa e para os clientes no produto final;
● Automação - necessidade de remover a intervenção humana para reduzir
erros e tempo de colocação no mercado, além de melhorar a qualidade. Tal
conceito origina-se da TI onde a automatização é “algo mais natural”,
entretanto, ele é bem aplicável a outros ambientes uma vez que facilita a
aceleração dos fluxos existentes nos processos;
51
● Fluxo enxuto – aplicação de definições como trabalho em processo (Work
in Progress - WIP), tamanho do lote, comprimento de filas para um fluxo
de valor e feedback mais rápidos. Definições essas que quando
influenciadas por uma automatização bem fundamentada e baseadas em
bons indicadores, acabam por favorecer um “melhor fluxo enxuto”;
● Medição - compreender e medir o fluxo de valor através do pipeline,
promovendo assim a aprendizagem e melhoria contínua. Segundo Peter F.
Drucker, professor e autor de negócios ligados a administração, “O
trabalho é um processo, e todo o processo tem de ser controlado. Para
tornar o trabalho produtivo, portanto, requer-se a construção dos controles
adequados para o processo de trabalho”. E ainda, “Nada é menos
produtivo do que tornar eficiente algo que nem deveria ser feito”. Ou seja,
para se aprender e acelerar o processo, reduzir a taxa de retrabalho e
melhorar a produtividade e qualidade, necessita-se de indicadores com os
quais se pode fazer as mudanças necessárias, inclusive suprimindo as
atividades não necessárias;
● Restauração - criação de sistemas que permitirão correções rápidas de
problemas de produção por meio de reversão automática e recursos de
correção para frente (correção na produção). A essência aqui é mudança
rápida e com poucos riscos. Esse importante conceito é totalmente
fortalecido por todos os outros (automatização, fluxo enxuto, medição e
cultura), ou seja, ele será menos aplicado à medida que os conceitos
anteriores sejam bem aplicados. Mas isso, não o torna menos importante
ou desnecessário, pelo contrário, ele também influencia nos outros
conceitos pois conforme as correções dos problemas são feitas durante o
52
processo (sem interrupção), o prejuízo para a empresa e cliente é menor e
o ciclo desses conceitos em DevOps continua em funcionamento.
Com tais fatores descritos acima, na concepção de DevOps, o desenvolvimento de
projetos acontece com a junção dos diferentes conhecimentos que cada colaborador
possui referente ao seu setor ou campo de trabalho específicos, facilitando assim, a
transmissão de informações e evitando uma possível falta percepção de informações
relevantes.
5.5 PAPÉIS E RESPONSABILIDADES
Um estudo de 2015 detalhado na Harvard Business Review constatou que quase
75% das equipes interfuncionais examinadas eram disfuncionais devido à falta de clareza
de governança, bem como à falta de responsabilidade, metas específicas e suporte
organizacional prioritário. Ao mesmo tempo, membros da equipe multifuncional
geralmente vêm com suas próprias agendas que estão frequentemente ligadas às
prioridades de seu departamento. Da mesma forma, eles podem ser territoriais e
propensos a proteger seu terreno. E eles costumam usar seu próprio jargão e abreviação,
extraídos de suas áreas profissionais e funcionais e que não são bem compreendidos pelos
outros. Uma vez que ocorre a “desmontagem de silos” para a construção das equipes
multifuncionais, é natural que os membros executem diversas tarefas. Sendo assim, os
papéis citados a seguir são de extrema importância para a execução de tarefas, pois
determinam as funções e responsabilidades que cada ator possui dentro da equipe.
O time deve contar pessoas executando os seguintes papéis:
● Scrum Master (SM): É um membro exclusivo da equipe Agile que passa grande
parte do tempo ajudando outros membros da equipe a se comunicar, coordenar e
cooperar; geralmente, essa pessoa ajuda a equipe a cumprir suas metas de entrega.
53
O SM tem um papel mais ligado a gestão geral da equipe, não necessariamente
irá se envolver a fundo nos aspectos técnicos do desenvolvimento das soluções.
● Product Owner (PO): É o membro da equipe Agile que atua como intermediário
da equipe com o Scrum Master. Isso permite que a solução atenda efetivamente
às prioridades do programa (recursos e capacitadores), mantendo a integridade
técnica. Idealmente, o PO, Product Owner, é colocado junto ao resto da equipe,
onde eles compartilham gerenciamento, incentivos e cultura. Mas o PO também
participa das reuniões mais relevantes de Gerenciamento de Produto sobre
planejamento e refinamento do Programa Backlog / Visão. Então, o PO deve ser
uma figura capaz de transitar entre esses dois ambientes, ele deve ser uma pessoa
com grande capacidade de comunicação e entendimento sobre as técnicas.
● Time de desenvolvimento: São o núcleo do desenvolvimento Agile. Eles
trabalham em equipes pequenas e multifuncionais e desenvolvem a solução. É o
grupo que responsável por aplicar as técnicas e ferramentas disponíveis para o
melhor resultado do planejamento. A seleção de seus integrantes é crucial para o
produto final alcançado ao final do projeto.
● Business Owners: São um grupo de pessoas que possuem a responsabilidade de
governança, conformidade e retorno do investimento (ROI), por uma solução
desenvolvida pelo ART.
● Product Management: Tem autoridade na criação do Backlog, sendo responsável
por identificar a necessidade do cliente, priorizar features, guiar o trabalho
através do Kanban e desenvolver a visão da solução. Realiza o link entre o
cliente, apontando tudo aquilo que possa influenciar o mesmo, e o processo de
54
desenvolvimento do produto. Além de coordenar os níveis de prioridade que
surgem no processo.
● Arquiteto de sistema: É responsável por definir e comunicar uma visão técnica
e arquitetural para o ART, com a intenção de ajudar e garantir que o
desenvolvimento da solução esteja de acordo com as necessidades do cliente
previamente estabelecidas.
● Engenheiro do ART: Seu principal papel é facilitar os processos dos ARTs e
ajudar os times a entregar uma solução de valor, além de se comunicar com
stakeholders, gerenciar riscos e impulsionar melhorias.
5.6 QUALIDADE
A garantia da qualidade é fundamental para a entrega de um produto de
excelência. Criar um time ágil que entrega com total qualidade demanda tempo e
dedicação. No modelo Waterfall a não obrigatoriedade de feedback entre as fases se
reflete de forma negativa. Juntamente, o fato de uma etapa só iniciar depois do término
da etapa anterior, força uma extrema sincronização entre os membros da equipe, muitas
vezes o desenvolvimento se vê interrompido provocando atrasos nos prazos
estabelecidos. Com um modelo de time ágil, as entregas passam a ter maior controle e
qualidade, pela troca de informações e acompanhamento contínuos. O SAFe provê
algumas técnicas para isso, mas a essa etapa depende diretamente do tipo de produto que
se está sendo produzido.
● Fluxo de entrega – a qualidade integrada permite o pipeline de entrega
contínua, juntamente com a integração contínua do DevOps as alterações
incorporadas nos componentes são testadas em vários ambientes antes de
chegar à produção;
55
● Qualidade da Arquitetura e design – iniciam a qualidade incorporada e
determinam até que ponto um sistema pode suportar as necessidades atuais
e futuras dos negócios. A qualidade na arquitetura e no design torna os
requisitos futuros mais fáceis de implementar, os sistemas mais fáceis de
testar e ajuda a satisfazer os NFRs;
● Qualidade do Componentes – os recursos de um sistema são executados
por seus componentes. A velocidade e a facilidade com que novos recursos
podem ser adicionados depende da rapidez e confiabilidade que os
componentes podem modificá-lo;
● Qualidade do sistema - confirma que os sistemas funcionam conforme o
esperado e que todos estão alinhados com as alterações a serem feitas;
● Qualidade da Liberação - permite que a empresa avalie a eficácia da
hipótese de benefício de um Recurso. Quanto mais rápido uma
organização libera, mais rapidamente aprende e mais valor gera.
5.7 LIDERANÇA
A liderança é responsável por espalhar os quatro Core Values (Valores Centrais)
e o mind set lean-agile, já mencionados, para toda a organização, de forma a garantir um
time alinhado e voltado para a entrega do produto.
Para isso, a liderança pode seguir um roadmap de implementação sugerido pelo
SAFe, com os seguintes passos:
● Treinando agentes da mudança.
Para começar uma mudança organizacional, é necessário treinar papéis chaves
para a implementação do SAFe. Para isso, podem ser fornecidos treinamentos e
56
certificações para os funcionários identificados como agentes da mudança, para assim, se
ter algumas pessoas na organização certificadas da metodologia
● Treinar a gerência, líderes e executivos
Com essas pessoas entendendo a metodologia, é mais fácil conseguir passar o
conhecimento para os outros funcionários da organização
● Identificar fluxos de valor e ARTs
Como elementos chaves para a execução da solução, é necessário decidir esses
dois pontos fundamentais para a execução
● Criar o plano de implementação
Com uma mudança de grande porte, é necessário se planejar. Porém, é sempre
importante ter em vista que não se deve pensar demais no problema. Segundo a citação
de Reinertsen: “Quanto mais detalhado nossos planos, mais longo os ciclos se tornam”.
É sempre melhor planejar um pouco, executar, aprender com isso, e melhorar.
● Lançamento do primeiro ART
Nessa etapa é necessário treinar os líderes envolvidos no lançamento, formar e
organizar os times ágeis, trainar Product Owners e Scrums Masters, e preparar o backlog.
● Treinar os times ágeis
Pessoas chaves já foram treinadas, agora é necessário treinar os times que vão
executar o desenvolvimento.
● Auxiliar a execução do ART
Apesar de todos os colaboradores estarem treinados, é necessário ter em mente
que conhecimento não é sinônimo de entendimento. Para conseguir colocar em prática
um conhecimento, é necessário tempo e prática. Por isso, um auxílio nesse início se faz
necessário.
● Escalar
57
Com o domínio da metodologia, e o crescente desenvolvimento, a empresa vai
começar a escalar a solução, cada vez mais englobando entregas mais complexas.
58
6. ESTUDO DE CASO
Será estudado a aplicação da framework SAFe em um projeto de implementação
de uma nova linha de sorvetes. A empresa estudada está inserida em um mercado
altamente competitivo, o da indústria alimentícia, e acredita em seus funcionários para
inovar e manter seu market share.
Existem diversas iniciativas de projeto de inovação de produto acontecendo
simultaneamente e muitas deles sem uma estruturação ou embasamento teórico que
auxiliem em seus desenvolvimentos. Esse cenário é o retrato do caso de um projeto em
particular que será abordado ao longo deste trabalho.
Um produto vendido pela empresa em suas lojas físicas são as pizzas, sendo
oferecidas em forma de fatia ou no sistema rodízio. Apesar dos insumos necessários
serem feitos na fábrica, e as pizzas montadas nas lojas, existe um fator extra que ajuda a
compor alguns pratos de pizza doce: o sorvete. A empresa em questão compra sorvete de
terceiros, estoca em suas lojas, e serve a bola de sorvete com algumas fatias específicas
de pizzas doces.
O engenheiro de produção da empresa, notando a quantidade grande de sorvete
utilizada em todas lojas físicas, enxergou a oportunidade de fabricar seu próprio sorvete,
diminuindo a dependência dos fornecedores do produto final e seu custo atrelado.
Pensando em criar um diferencial do produto, analisou a escolha de produzir Gelato, um
tipo de sorvete artesanal, dessa forma, a identidade da empresa, que é conhecida por suas
produções artesanais, seria também mantida.
A empresa estudada foi fundada na década de 70, se enquadrando no setor
alimentício. A estrutura inicial da organização era bem simples, contando com apenas
com 5 funcionários. Em 1990 duas novas lojas foram inauguradas, porém somente 19
59
anos após sua fundação, com a criação de sua quarta loja, é que a rede começa a crescer
e tomar dimensão.
Vinte e cinco após a sua criação resolveu-se criar uma fábrica a fim de centralizar
e padronizar os produtos vendidos em suas lojas.
Contando com um total de 95 funcionários próprios, a fábrica é responsável pela
preparação de todos os produtos vendidos nas lojas – pães, massas, molhos, coquetéis,
(salgadinhos), doces e tortas – com exceção da pizza, que tem a montagem feita nas lojas,
apesar da massa, molho e ingredientes saírem do local. Um grande diferencial da
companhia frente aos seus concorrentes, é a sua produção artesanal, mantendo um alto
padrão de qualidade.
A fábrica conta com um quadro de funcionários enxutos, divididos por setores
com base em seus produtos, como padaria, coquetéis, confeitaria e massas, além da área
administrativa, composta por funcionários responsáveis pelo funcionamento do negócio.
O setor de tortas é onde se concentra o maior volume de produção, e
consequentemente o maior número de funcionários. São produzidas cerca de 35.000
tortas por mês, quando não há nenhum tipo de evento especial. Dada a natureza perecível
das tortas, seus pedidos só podem ser produzidos para consumo em curto prazo, não pode
ser feito estoque. A torta depois de pronta, é encaminhada para um frigorífico, onde é
mantida até a chegada o caminhão que irá fazer a rota logística e entrega dos produtos.
A empresa apresenta uma constante preocupação com a área de Pesquisa e
Desenvolvimento. Todo o conhecimento e evolução do processo produtivo gerou
demandas específicas no setor de produção da fábrica, que foram supridas com o
desenvolvimento de máquinas e equipamentos específicos para o processo produtivo.
Esse desenvolvimento é feito em parceria com produtores de maquinários industriais e
trazem altos ganhos de produtividade e de controle da qualidade na produção, sem
60
perder sua característica artesanal, uma vez que o maquinário auxilia a produção, sem
eliminar completamente a necessidade humana para executar sua produção. Além disso,
existe uma constante preocupação de criação contínua de novos produtos, com os
cozinheiros e confeiteiros da Fábrica possuindo liberdade criativa para criarem novos
produtos e sabores, caso aprovados internamente, tais produtos são produzidos e
enviados às lojas da empresa normalmente em datas/ocasiões especiais, e dependendo
da recepção do público são adicionados no rol de produtos fixos produzidos pela fábrica
Visando esse mindset de inovações pregada pela empresa, o engenheiro de
produção resolveu colocar em prática a sua ideia de produção dos sorvetes Gelatos.
Porém, para iniciar a produção, seria necessário a compra de uma máquina própria. Após
uma pesquisa sobre as vantagens do novo produto, a diretoria da empresa aprovou a
sugestão, porém sem fornecer nenhum apoio estrutural a sua execução.
A companhia comprou uma máquina e iniciou uma sequência de testes do
produto, no entanto apresentou diversas dificuldades, como as relatadas abaixo:
● Insumo
Em busca de reduzir o custo de produção, foram utilizados muitos ingredientes
iguais aos da produção de tortas. Porém, o Gelato exige produtos mais frescos e de uma
qualidade superior
● Fórmula
Apesar da pesquisa prévia, a proporção dos ingredientes pode variar dependendo
de temperatura ambiente e outros fatores. A falta de um estudo mais profundo da receita
levou a execução de diversos testes até chegar a um produto aceitável.
● Validade
61
O gelato deve ser consumido em até dois dias, o que exigiria uma fabricação
constante, assim como uma alta saída por parte das lojas.
● Transporte
O transporte do sorvete, se fosse feito em larga escala, necessitaria de uma frota
de caminhões específicos, mantendo a temperatura necessária para manter o sabor e
refrescância característico do Gelato
Esses foram alguns pontos destacados pela empresa como motivadores para o não
prosseguimento da execução do novo produto. Os testes realizados geraram para a
empresa o um custo, atrelando a isso o custo da hora trabalhada do Engenheiro de
produção, que por precisar se dedicar sozinho ao projeto, deixou outras obrigações de seu
cargo de lado, resultado em um descrédito do projeto, fazendo com que a diretoria
cancelasse a ideia de vendas do sorvete Gelato.
Contudo, se a empresa fornecesse o suporte e o conhecimento para a execução do
projeto através do framework SAFe, o resultado poderia ser diferente. A empresa poderia
ter se preparado melhor para a entrada do novo produto, ou identificado fatores
impeditivos do novo negócio antes de ocorrer a perda financeira.
62
7. ABORDAGEM SAFe NO CASO
Caso a empresa usasse o framework SAFe em toda a concepção do projeto, desde
a sua criação até o desenvolvimento, teria apresentado um resultado diferente do atual. A
primeira grande diferença se encontra na base do desenvolvimento do projeto.
7.1 VALORES
Os valores pregados pelo SAFe apresentam um papel fundamental no sucesso da
implementação do framework. É possível perceber através de uma comparação com o
framework, quais os valores que a empresa em questão necessita implementar.
● Alinhamento: É possível perceber que diferente do que o framework
estabelece, a empresa não possui um alinhamento entre seus funcionários
visando desenvolvimentos ágeis.
● Qualidade Integrada: Esse valor é atualmente utilizado na empresa, uma
vez que todos seus processos devem exibir um alto índice de qualidade,
deixando claro a seus funcionários a importância desse fator para a
companhia como um todo.
● Transparência: Atualmente a empresa não demonstra grande preocupação
com esse fator, ficando bem evidente na representação do caso Gelato,
uma vez que decisões foram pautadas de maneiras especulativas e sem
uma grande transparência, tanto por parte da gerência quanto do
engenheiro de produção que está desenvolvendo o projeto.
● Execução de programas: Valor chave para o desenvolvimento através do
SAFe, porém ausente na empresa. A empresa não apresenta uma
preocupação na entrega contínua de valor.
63
Dessa forma, para a aplicação do SAFe a empresa necessitaria estabelecer e
difundir novos valores entre seus funcionários.
7.2 COMPETÊNCIAS
Diferente do que a competência “Liderança Lean Agile” prega, a liderança da
empresa em estudo não conduz ou sustenta mudanças organizacionais. Apesar da
liderança incentivar projetos, ela não se envolve ou suporta nenhum deles.
O framework proposto neste trabalho inclui a competência “Equipe e Agilidade
técnica”, em que descreve princípios e práticas necessárias para o funcionamento da
equipe. No caso do Gelato um grande erro foi a ausência de equipe. Somente um
funcionário foi responsável pela ideação e implementação do projeto, tornando seu
desenvolvimento míope, uma vez que o responsável pelo projeto era um engenheiro de
produção, sem o conhecimento gastronômico, que para o projeto em questão, se
apresentou relevante no momento de criação da receita.
A terceira Competência fundamental apresenta é “DevOps e liberação sob
demanda”. Essa competência descreve como desenvolver um projeto com entrega
contínua de valor, indo a contraponto do que aconteceu no caso da empresa apresentada.
A entrega contínua de valor é um elemento essencial para o sucesso do projeto, uma vez
que por causa disso, o projeto consegue ir apresentando pequenas funcionalidades,
analisando sua resposta e adaptando-se quando necessário. A empresa se preocupou
somente com o objeto final, porém não levou em consideração o fato de que quanto mais
tempo se passa entre uma entrega e outra, mais custo a empresa gera, sem
necessariamente agregar valor. Devido aos gastos, e falta de um valor aparente, a diretoria
da empresa resolveu não continuar com o projeto. Caso o engenheiro tivesse entregue um
64
valor contínuo, adaptando-se às mudanças, ele poderia ter mostrado a diretoria o real valor
do projeto.
7.3 AGILE RELEASE TRAIN - ART
Devido ao tamanho da solução para o caso especificado, para realizar a entrega
desejada, seria necessário somente um agile release trains (ART), sendo composto por
dois times, multidisciplinares, como relatados a segur:
● Time 1: Composto por três gerentes responsáveis pelas três lojas físicas
que mais geram lucro para a companhia e dois funcionários da área
administrativa, um do setor financeiro e um engenheiro responsável pela
produção. Além dessa equipe de desenvolvimento, integraria ao time um
Scrum Master e um Product Owner.
● Time 2: Composto por dois funcionários da confeitaria e um funcionário
do setor administrativo responsável pela qualidade da produção. Além
dessa equipe de desenvolvimento, integraria ao time um Scrum Master e
um Product Owner.
7.4 DESENVOLVIMENTO
Para o desenvolvimento do projeto através do SAFe, seriam utilizados o Kanban
e o Scrum, respeitando o método e rituais apresentados previamente neste trabalho.
O projeto de implementação do sorvete Gelato no cenário atual apresenta um
único item em seu backlog: Produzir o sorvete. Caso o projeto estivesse sendo executado
com o SAFe, ele incluiria no seu backlog, os seguintes itens:
● Estudo de viabilidade financeira
● Estudo de viabilidade de produção
65
● Estudo do mercado
● Planejamento de produção
● Teste em mercado
● Produção
● Melhorias na produção
● Comercialização
Dessa forma, seria possível entregar um valor contínuo, aprendendo com os erros
e as particularidades do mercado.
Para o desenvolvimento do projeto, a equipe dividiria o projeto, e suas entregas,
em diversos incrementos, conforme sugere o SAFe. Seguindo também, os princípios
recomendados, como o planejamento do incremento.
Com base no backlog de entregas, cada iteração está separada abaixo, com seu
respectivo objetivo:
● Incremento 1
Os objetivos do time 1 no primeiro incremento é entender o mercado e a
viabilidade do projeto para a empresa. Nessa etapa seria feito um estudo
de viabilidade financeira da máquina necessária para a fabricação, de
capacitação de funcionários, a viabilidade técnica de armazenamento e
transporte do produto e realizar uma pesquisa de mercado com seus
clientes. Essa pesquisa de mercado levaria em consideração, desde o início
do processo, os potenciais clientes e suas dores e desejos com relação ao
produto. A equipe 2 é responsável por estudar a viabilidade da receita, seus
ingredientes e modo de preparo. Dessa forma, ao fim do incremento, os
três primeiros itens do backlog estariam entregues.
66
Figura 19: Objetivos da primeira PI. Fonte: Elaboração Própria
● Incremento 2
O objetivo do segundo incremento, para o time 1 é estudar a melhor
localização para o aparelho. Atualmente, a fábrica é superdimensionada,
permitindo mudanças de layout. Devido a particularidade da produção e
armazenamento do Gelato, essa fase consiste em encontrar a melhor
posição na fábrica para o início da produção. Enquanto o time 2 é
responsável por planejar os processos da etapa de produção de forma mais
eficiente e rodar a primeira produção, seu MMF, recurso mínimo viável.
67
Com esse primeiro produto pronto, será possível testar a reação do público
ao sorvete nas lojas, para no próximo incremento, analisar possíveis
melhorias ao produto.
Figura 20: Objetivos da segunda PI. Fonte: Elaboração Própria
● Incremento 3
O objetivo do terceiro incremento consiste basicamente em fornecer o melhor
produto e iniciar o processo produtivo. O time 1 é responsável por identificar
possíveis melhorias no processo, seja de fabricação, quanto de armazenagem.
68
Com base nessas melhorias, o time 2 é responsável por iniciar o processo
produtivo em maior escala.
Figura 21: Objetivos da terceira PI. Fonte: Elaboração Própria
Para auxiliar na colaboração ao longo de todo o ciclo de valor, é fundamental
todos os membros das equipes terem em mente o conceito de DevOps. O framework SAFe
foi desenvolvido para projetos de TI, e devido ao ajuste a um projeto fora dessa área,
algumas adaptações se fazem necessárias. Levando e consideração o projeto em questão,
DevOps deve ter elementos já mencionados e explicados anteriormente:
69
● Cultura de responsabilidade compartilhada: Fundamental para a criação
de times colaborativos, principalmente em uma organização que apresenta
funcionários operários de fábrica e funcionário do nível de gerência.
● Fluxo lean: Responsável por auxiliar na entrega contínua de valor da
solução ao longo do desenvolvimento
● Medição de valor: Fundamental medir a evolução do progresso. Nesse
caso em específico é necessário a medição de tempo e consumo de
ingredientes da produção, assim como validade do produto.
● Recuperação - Componentes de baixo risco: Garante que os componentes
projetados sejam de baixo risco ou com uma recuperação rápida a falhas,
garantindo uma contínua entrega de valor.
Foi retirado dos princípios do DevOps a característica “Automatizar tudo”, visto
que diferente de um projeto de TI, muitas coisas não podem ser automatizadas. Somado
a isso, um dos diferenciais da empresa é sua produção menos industrializada frente aos
concorrentes, dessa forma, deve-se tomar muito cuidado em relação a automatização na
linha de produção dos produtos finais da companhia, visando manter suas particularidades
e vantagens competitivas.
7.5 PAPÉIS E RESPONSABILIDADES
Para o desenvolvimento do projeto o engenheiro assumiu todos os papéis e
responsabilidades para si, uma vez que não apresentava uma equipe para auxiliá-lo. No
entanto, com o auxílio de uma equipe e com papéis e responsabilidades bem delimitados,
não existiria uma sobrecarga de funções, permitindo que cada membro da equipe
conseguisse contribuir de forma plena.
70
O SAFe apresenta três importantes papéis para a composição da equipe: Scrum
Master, Product Owner e equipe de desenvolvimento. Cada equipe deve ter pessoas
dedicadas a esses papéis. Devido ao número reduzido de funcionários, algumas pessoas
irão assumir o mesmo papel, em diversos times. Suas importâncias e responsabilidades já
foram descritas anteriormente. Tendo em vista o cenário da empresa, em que acontecem
diversos projetos de forma paralela, caso a empresa decidisse suportar-los, a diretoria
precisaria capacitar um funcionário na metodologia Scrum, para que o mesmo pudesse
exercer o papel de Scrum Master no desenvolvimento dos projetos. No caso apresentado,
o Product Owner seria o engenheiro de produção, uma vez que ele apresenta qualificações
técnicas necessárias para fazer o intermédio entre a equipe e o Scrum Master, executando
esse papel nos dois times propostos. As equipes de desenvolvimento, como mostrado
anteriormente, é composta pelos seguintes funcionários:
● Funcionário(s) da confeitaria: Responsável por contribuir com o conhecimento
gastronômico para o projeto
● Gerentes das lojas físicas: Responsáveis por entender o público e as reais
necessidades das lojas
● Funcionário(s) da área administrativa: Responsável por entender o negócio,
fornecedores, e a realidade financeira da empresa.
Devido ao enxuto quadro de funcionário da empresa, os papéis de engenheiro do
ART, arquiteto de sistema, product management e business owner seriam gerenciados
pelo administrador da fábrica, uma vez que ele possui uma relação entre os stakeholder e
a equipe, possuindo um conhecimento técnico para gerenciar riscos e impulsionar
melhorias além do conhecimento do negócio e limitações da companhia.
71
Com o ART sugerido, em conjunto com as iterações apresentadas, seria possível
um desenvolvimento contínuo e adaptável. Vale ressaltar que as iterações sugeridas são
o início de um projeto de solução, e ao longo de seu desenvolvimento, objetivos poderiam
mudar com base em descobertas feitas ao longo da iteração. O fluxo proposto é baseado
em uma entrega contínua, assumindo poucas dificuldades encontradas na viabilidade de
solução, porém, com o desenvolvimento do projeto, caso dificuldades fossem se
apresentando, o objetivo da iteração seguinte iria precisar ser adaptado.
7.6 QUALIDADE
Como um pilar fundamental para o desenvolvimento do projeto no framework SAFe, a
qualidade deve estar presente.
A garantia da qualidade do desenvolvimento desse projeto em questão ficaria por
conta dos seguintes fatores:
● Entrega contínua, garantindo ao produto adequação ao mercado e a realidade da
fábrica.
● Testes em que ao final de cada iteração a equipe rodaria um ciclo PDCA (Planeja,
executa, verifica e age). Dessa forma, ao final de cada iteração seria verificado o
que deve ser mudado para se adequar melhor ao resultado final esperado.
● Garantia da qualidade da arquitetura, onde seria garantido que o produto final de
cada iteração acrescentasse valor ao produto final, e que a equipe seria capaz de
executar.
7.7 POSSÍVEIS BENEFÍCIOS
Em um projeto de entrega contínua através de métodos ágeis, prever o real
resultado se torna um muitas vezes impossível, uma vez que o princípio desse tipo de
72
desenvolvimento de projeto é adaptação com base no que ocorre ao longo do
desenvolvimento. Porém, para o caso do sorvete gelato é possível levantar algumas
hipóteses de output, como as descritas a seguir.
● O primeiro resultado possível é a empresa conseguir fornecer o tipo de produto
previsto, aumentando seu lucro ou diferencial competitivo, uma vez que suas
concorrentes não apresentam esse tipo de produto. Dessa forma, ao invés da
empresa gastar dinheiro em uma máquina esperando que seu resultado seja
positivo, a empresa investiria na máquina tendo a certeza de um retorno.
● Outro resultado que pode ser apresentado com o estudo de viabilidade é que
devido a perecividade do produto, não compensaria a venda somente atrelado a
pratos servidos no restaurante, que era a ideia inicial do problema, sendo
necessário vendo potes fechados do sorvete avulso ao público, fazendo com que
a empresa agregasse em seu portfólio um novo produto. É possível perceber que
dessa forma, antes da empresa investir capital em um negócio, ela já saberia que
seria necessário adaptá-lo para fazê-lo ser lucrativo. Caso esse fosse o output da
fase de viabilidade, as interações apresentadas precisariam ser adaptadas, uma vez
que antes de fornecer essa solução, seria necessário entender o mercado e perceber
se existiria público para a nova solução.
● Outro resultado possível é a inviabilidade de produção ainda na primeira iteração,
obrigando as equipes a pensar em uma nova solução para diminuir os custos com
os sorvetes atuais que a empresa compra. Dessa forma, a empresa não precisaria
ter comprado a máquina de fabricação de sorvetes gelatos.
73
É possível observar que existem diversas possibilidades de acontecimentos ao
longo do projeto, variando seu desenvolvimento e solução final. Porém, vale ressaltar que
em todos eles a relação custo/retorno é mais atrativa utilizando o framework SAFe.
74
8. CONCLUSÃO
A aplicabilidade do SAFe tem um caráter adaptativo as mais diversas situações
que se pode encontrar. Suas competências e os papéis estabelecidos para os colaboradores
atuantes prezam pela construção de princípios sólidos e metas claras, mas adaptáveis a
execução conforme a necessidade, buscando garantir a agilidade, qualidade e eficiência
dos processos e produtos/serviços oferecidos. Levando sempre em consideração a visão
do cliente através das entregas e feedbacks contínuos.
Tendo isso em vista, o trabalho apresenta uma forma de aplicação do framework
SAFe a projetos não relacionados a área da tecnologia da informação. Seus fundamentos
podem ser adaptados a diversas realidades, como a da empresa atual que está inserida em
um ramo alimentício. É possível perceber que, com as corretas adaptações, um projeto
formulado e executado através do framework apresentado é capaz de obter resultados
significativos, que geram mais valor à empresa.
Além do valor gerado através da solução entregue, vale resultar um valor que
muitas vezes não é percebido pela alta gerência. Uma forma estruturada de inovação
motiva funcionários a contribuir, gerando cada vez mais resultados. Outro ganho para os
funcionários, e consequentemente para a empresa, é a difusão de conhecimentos como o
Scrum.
Dessa forma, para a empresa que já busca em seus funcionários pró atividade em
sugerir novos projetos, é possível perceber que através do estudo pequeno caso do Gelato,
os benefícios para a empresa. Caso a solução fosse escalável para a empresa como um
todo, como sugere o SAFe, seus ganhos seriam ainda maiores.
75
9. REFERÊNCAS BIBLIOGRÁFICAS
ARCHER, Bruce. Systematic method for designers. Grã Bretanha, 1965
IBC. A vida de Peter Drucker – Histórias, frases e livros. Disponível em <
https://www.ibccoaching.com.br/portal/frases/frase-coaching-peter-drucker/> Acesso
em Dezembro de 2019
CAMPOS, V. F. Gerenciamento da rotina do trabalho do dia-a-dia. Belo
Horizonte, 1996
Cola da Web. Gestão da Qualidade Total - GQT. Disponível em
<https://www.coladaweb.com/administracao/gestao-pela-qualidade-total-gqt> Acesso
em dezembro de 2019
C. K. PRAHALAD, Gary Hamel. The core competence of the corporation.
Harvard Business Review, 1990
DEMING, Edwards. Saia da Crise. 1982
GRANDE, Marcia. Gestão da Qualidade. Disponível em
<https://edisciplinas.usp.br/pluginfile.php/2503309/mod_resource/content/0/Qualidade_
conceitos.pdf> Acesso em dezembro de 2019
Gaea Consulting, Por que entrega contínua é importante para sua empresa.
Disponível em: <https://gaea.com.br/por-que-entrega-continua-e-importante-para-sua-
empresa/> Acesso em novembro de 2019
76
Kotter, John P. Leading Change. Harvard Business Review Press. Edição
Kindle
Linux. Disponível em <https://www.4linux.com.br/o-que-e-DevOps> Acesso em
novembro de 2019
LUBBEN, Richard T. Just in time, uma estratégia avançada de produção.
Edição, 1989
Manifesto Ágil, 2001. Disponível em <https://www.manifestoagil.com.br/>
Acesso em novembro de 2019
MATINELLI, Fernando. Gestão da Qualidade Total. Brasil, 2009
MATSUMOTA, Leonardo. Ágil em larga escala: Inception e preparação para
PI Planning -SAFe. Disponível em <https://iMasters.com.br/agile/agil-em-larga-escala-
inception-e-preparacao-para-pi-planning-safe> Acesso em dezembro de 2019
OSTERWALDER, Alex; Pigneur, Yves; Bernarda, Greg; Smith, Alan. Value
Proposition Design. 1ªEdição, 2018
PRATT, Mary. Equipes multifuncionais: Uma nova estratégia para o sucesso
dos negócios. Disponível em: <https://cio.com.br/equipes-multifuncionais-uma-nova-
estrategia-para-o-sucesso-dos-negocios/> Acesso em novembro de 2019
SIDONIO, Luiza; CAPANEMA, Luciana; GUIMARÃES, Diego Duque;
CARNEIRO, João Vitor Amaral. Inovação na indústria de alimentos: importância e
dinâmica no complexo agroindustrial brasileiro. Disponível em
<https://web.bndes.gov.br/bib/jspui/bitstream/1408/1512/1/A%20mar37_08_Inova%C3
77
%A7%C3%A3o%20na%20ind%C3%BAstria%20de%20alimentos_P.pdf> Acesso em
dezembro de 2019
Profissionais TI. 12 Características do SAFe. Disponível em
<https://www.profissionaisti.com.br/2016/01/12-caracteristicas-do-safe-scaled-agile-
framework/> Acesso em novembro de 2019
PROJECT MANAGEMENT INSTITUTE (PMI). A Guide to the Project
Management Body of Knowledge – PMBOK® Guide 2004 Edition, Pennsylvania-
USA 2004
Scaled Agile Framework. Disponível em:
<https://www.scaledagileframework.com/> Acesso em outubro 2019.
SUTHERLAND, Jeff; Sutherland, J.J. Scrum: A arte de fazer o dobro
do trabalho na metade do tempo. Edição revista, 2019
VersionOne. VersionOne 10th Annual State of Agile Report. Disponível em
<http://www.agile247.pl/wp-content/uploads/2016/04/VersionOne-10th-Annual-State-
of-Agile-Report.pdf> Acesso em novembro de 2019
SOARES, Michel dos Santos. Comparação entre Metodologias Ágeis e
Tradicionais para o Desenvolvimento de Software. Artigo Unipac 2004. Disponível
em <http://www.dcc.ufla.br/infocomp/index.php/INFOCOMP/article/view/68> Acesso
em dezembro de 2019
Site Jumpers. Estratégia No Spotify: Dos Okrs Para O Spotify Rhythm.
Disponível em <http://www.jumpers.cc/estrategia-no-spotify-dos-okrs-para-o-spotify-
rhythm/> Acesso em dezembro de 2019
78
Wikipedia. NHS Blood and Transplant. Disponível em
<https://en.wikipedia.org/wiki/NHS_Blood_and_Transplant>. Acesso em dezembro de
2019
Wikipedia. Centers for medicare and Medicaid services. Disponível em <
https://en.wikipedia.org/wiki/Centers_for_Medicare_and_Medicaid_Services> Acesso
em dezembro de 2019