Guia para acrônimos e abreviações do SAFe
ART Agile Release Train
BO Business Owner
BV Valor de negócio
BVIR Big Visual Information Radiator
CapEx Despesas de capital
CD Entrega contínua
CE Exploração contínua
CI Integração contínua
CFD Diagrama de fluxo cumulativo
CoD Custo do atraso
CoP Comunidade de Práticas
DoD Definição de feito
DoR Definição de pronto
DSU Reunião diária
EA Enterprise Architect
EO Epic Owner
FW Firmware
HW Hardware
I&A Inspect and Adapt
IP Inovação e planejamento (iteração)
KPI Key Performance Indicator
LPM Lean Portfolio Management
MBSE Model-Based Systems Engineering
MMF Minimum Marketable Feature
MVP Mínimo Produto Viável
NFR Requisitos não funcionais
OE Opportunity Enablement
OpEx Despesas operacionais
PDCA Planejar, fazer, verificar, ajustar
PI Incremento de programa
PM Product Management
PO/PM Product Owner/Product Manager
PO Product Owner
ROAM Resolvido, assumido,
aceito, minimizado
RR Redução de riscos
RTE Release Train Engineer
S4T SAFe® for Teams
SAFe® Scaled Agile Framework
SA SAFe® Agilist
SBD Set-Based Design
SM Scrum Master
SMART Específico, mensurável, alcançável,
realista, limitado no tempo
SoS Scrum of Scrums
SP SAFe® Practitioner
SPC SAFe® Program Consultant
STE Solution Train Engineer
SW Software
Tailoring – Customização ; Alfaiataria; Personalização
UX User Experience
VS Cadeia de Valor
VSE Value Stream Engineer
WIP Trabalho em andamento
WSJF Weighted Shortest Job First
XP Programação extrema
Glossário SAFe 4.5
Agile Architecture
Agile Architecture é um conjunto de valores e práticas que suportam a evolução ativa do design
e da arquitetura de um sistema durante a implementação de novas capabilities do sistema.
Agile Release Train (ART)
O Agile Release Train (ART) é um time de longa duração de times ágeis que, juntamente com
outros stakeholders, desenvolve e entrega soluções de forma incremental, usando uma série
de Iterações fixas, dentro do timebox do Incremento de Programa (PI). O ART alinha os times a
uma missão de negócio e tecnológica comum.
Agile Team
O Agile Team do SAFe é um grupo multifuncional de cinco a 10 pessoas com capacidade e
autoridade para definir, criar e testar alguns elementos de valor para a solução, tudo em um
timebox de iteração curto. Especificamente, o time ágil do SAFe incorpora as funções de Dev
Team, Scrum Master e Product Owner.
Architectural Runway
A Architectural Runway consiste nos códigos existentes, em componentes e na infraestrutura
técnica necessária para implementar features de curto prazo, sem atraso excessivo ou retrabalho
de design.
Built-In Quality
As práticas de Built-In Quality asseguram que cada elemento da Solução, em cada incremento,
atenda aos padrões adequados de qualidade ao longo do desenvolvimento.
Business Owners
Os Business Owners são um pequeno grupo de stakeholders que têm a principal
responsabilidade técnica e corporativa com relação à governança, à conformidade e ao Retorno
sobre Investimento (ROI) de uma Solução desenvolvida por um Agile Release Train (ART). Eles
são os principais stakeholders no ART que devem avaliar a adequação ao uso e participar
ativamente de determinados eventos do ART.
CapEx e OpEx
Despesas de capital (CapEx) e Despesas Operacionais (OpEx) descrevem as práticas Lean-Agile
contábeis financeiras em um budget de Value Stream. Em alguns casos, as CapEx poderão
incluir mão de obra capitalizada relacionada ao desenvolvimento de ativos intangíveis, como
softwares, propriedade intelectual e patentes.
Capabilities
Uma Capability é um comportamento de solução de alto nível que normalmente abrange
vários ARTs. As Capabilities são dimensionadas e divididas em várias features para facilitar sua
implementação em um único PI.
Communities of Practice (CoPs)
Communities of Practice (CoPs) são grupos organizados de pessoas que têm um interesse
comum em um domínio técnico ou de negócio específico. Elas colaboram regularmente para
compartilhar informações, aprimorar suas habilidades e trabalhar ativamente na promoção do
conhecimento geral do domínio.
Compliance
Compliance se refere a uma estratégia e a um conjunto de atividades e artefatos que permitem
que os times apliquem métodos de desenvolvimento Lean-Agile para criar sistemas que tenham
a mais alta qualidade possível e, ao mesmo tempo, assegurem que atenderão a qualquer norma
regulatória, industrial ou outros padrões relevantes.
Continuous Delivery Pipeline
O Continuous Delivery Pipeline (também conhecido como “pipeline”) representa o fluxo de
trabalho, as atividades e a automação necessárias para fornecer uma entrega contínua de valor
para o usuário final.
Continuous Deployment (CD)
Continuous Deployment (CD) é o processo que utiliza Features validadas do Continuous
Integration e os implementa no ambiente de produção, no qual eles são testados e preparados
para release. É o terceiro elemento no conjunto de quatro membros do Continuous Delivery
Pipeline of Continuous Exploration (CE), Continuous Integration (CI), Continuous Deployment e
Release on Demand.
Continuous Exploration (CE)
Continuous Exploration (CE) é o processo de explorar continuamente as necessidades do
mercado e do usuário, e de definir Vision, Roadmap e um conjunto de Features que atendam
a essas necessidades. É o primeiro elemento no grupo Continuous Delivery Pipeline de quatro
membros, precedendo Continuous Integration (CI), Continuous Deployment (CD) e Release
on Demand.
Continuous Integration (CI)
Continuous Integration (CI) é o processo de puxar features do Program Backlog e desenvolver,
testar, integrar e validá-las em um ambiente de homologação, no qual elas estarão prontos
para implantação e release.
Core Values
Os quatro Core Values de alinhamento, built-in quality, transparência e execução de programa
representam as crenças fundamentais que são essenciais para a eficiência do SAFe. Esses
princípios orientadores ajudam a ditar o comportamento e as ações de todos que participam
de um portfólio SAFe.
Customers
Customers são os compradores finais de cada Solution. Eles são uma parte integrante do
processo de desenvolvimento Lean-Agile e do Value Stream, bem como têm responsabilidades
específicas no SAFe.
Dev Team
O Dev Team é um subconjunto do Agile Team. Ele consiste em profissionais dedicados
que podem desenvolver e testar uma Story, uma Feature ou um componente. O Dev Team
geralmente inclui desenvolvedores e testadores de software, engenheiros e outros especialistas
dedicados necessários para completar uma parte vertical da funcionalidade.
DevOps
DevOps é um mindset, uma cultura e um conjunto de práticas técnicas. Ele fornece comunicação,
integração, automação e cooperação próxima entre todas as pessoas necessárias para planejar,
desenvolver, testar, implantar, liberar e manter uma solução.
Develop on Cadence
Develop on Cadence é um método essencial para gerenciar a variabilidade inerente do
desenvolvimento de sistemas em um sistema baseado em fluxo ao assegurar que eventos e
atividades importantes ocorram numa agenda regular e previsível.
Economic Framework
O Economic Framework é um conjunto de regras de decisão que alinha todas as pessoas aos
objetivos financeiros da solução e orienta o processo de tomada de decisões econômicas. Ele
contém quatro conceitos principais: Lean Budgets, financiamento e governança de Epics, tomada
de decisões descentralizada e sequenciamento de tarefas com base no Cost of Delay (CoD).
Enablers
Os Enablers suportam as atividades necessárias para ampliar a Architectural Runway a fim de
prover funcionalidades de negócio futuras. Isso inclui a exploração, infraestrutura, conformidade
e desenvolvimento da arquitetura. Eles são capturados nos diversos backlogs e ocorrem em
todos os níveis do Framework.
Enterprise
A Enterprise representa a entidade corporativa à qual cada portfólio SAFe pertence.
Enterprise Architect
O Enterprise Architect promove design adaptativo e as práticas de engenharia, além de
conduzir iniciativas arquiteturais para o portfólio. Os Enterprise Architects também viabilizam
a reutilização de ideias, componentes, serviços e padrões comprovados através de várias
soluções em um portfólio.
Epic
Um Epic é um contêiner para uma iniciativa de desenvolvimento de Solução grande o suficiente
para exigir análise, a definição de um Minimum Viable Product (MVP) e aprovação financeira
antes da implementação. A implementação ocorre em vários Program Increments (PIs) e segue
o ciclo “Build – Measure – Learn” (Construir – Medir – Aprender) do Lean startup.
Epic Owners
Os Epic Owners são responsáveis pela coordenação dos Epics de portfólio ao longo do sistema
Portfolio Kanban. Eles definem o Epic, seu Minimum Viable Product (MVP) e o plano de negócios
Lean e, quando aprovados, facilitam a implementação.
Essential SAFe configuration
A Essential SAFe configuration é o núcleo da estrutura e o ponto de partida mais simples
para a implementação. Ela é o bloco fundamental de todas as outras configurações do SAFe
e descreve os elementos mais importantes necessários para obter a maioria dos benefícios
do framework.
Features
Uma Feature é um serviço que atende às necessidades do stakeholder. Cada feature inclui
uma hipótese de benefício e critérios de aceitação, e é dimensionado ou dividido conforme
necessário para ser entregue por um único Agile Release Train (ART) dentro de um Program
Increment (PI).
Foundation
O Foundation contém os princípios de suporte, os valores, o mindset, o guia de implementação
e os papéis de liderança necessários para entregar valor com êxito em escala.
Full SAFe configuration
A Full SAFe configuration é a versão mais abrangente do framework. Ela auxilia empresas que
criam e mantêm grandes soluções integradas, o que exige centenas de pessoas ou mais e inclui
todos os níveis do SAFe: time, programa, large solution e portfolio. Nas maiores empresas,
várias instâncias de diversas configurações SAFe podem ser necessárias.
Innovation and Planning Iteration
A Innovation and Planning (IP) Iteration ocorre a cada Program Increment (PI) e atende a várias
finalidades. Ela atua como um buffer de estimativa para atender os objetivos de PI e provê um
período dedicado para inovação, educação continuada, PI Planning e eventos de Inspect and
Adapt (I&A).
Inspect & Adapt (I&A)
Inspect and Adapt (I&A) é um evento significativo, que ocorre ao final de cada Program Increment
(PI) quando o estado atual da Solution é demonstrado e avaliado pelo Train. Em seguida, os times
refletem e identificam itens de backlog de melhoria por meio de um workshop estruturado de
resolução de problemas.
Iteration
As iterations são os blocos de construção de desenvolvimento Agile. Cada Iteration é um
timebox padrão de duração fixa no qual os Agile Teams entregam valor incremental na forma
de software e sistemas funcionando e testados. A duração recomendada do timebox é de
duas semanas. No entanto, um período de uma a quatro semanas é aceitável, dependendo do
contexto de negócios.
Iteration Execution
A Iteration Execution é como os Agile Teams gerenciam seu trabalho ao longo do timebox
da Iteration, resultando em um incremento do sistema de alta qualidade, em funcionamento
e testado.
Iteration Goals
Os Iteration Goals são resumos de alto nível das metas de negócio e técnicas com as quais o
Agile Team concorda em cumprir numa Iteration. Eles são essenciais para a coordenação de um
Agile Release Train (ART) como um time de equipes auto-organizadas e autogerenciadas.
Iteration Planning
O Iteration Planning é um evento no qual todos os membros do time determinam com quanto
do Team Backlog eles podem se comprometer a entregar na Iteration que está por vir. O time
resume o trabalho como um conjunto de Iteration Goals comprometidos.
Iteration Retrospective
A Iteration Retrospective é uma reunião regular na qual os membros do Agile Team discutem os
resultados da Iteration, analisam suas práticas e identificam formas de melhorar.
Iteration Review
A Iteration Review é um evento baseado em cadência, no qual cada time inspeciona o
incremento ao final de cada Iteration para avaliar o progresso e, então, ajustar seu backlog
para a próxima iteration.
Large Solution Level
O Large Solution Level contém os papéis, artefatos e processos necessários para criar soluções
grandes e complexas. Isso inclui um foco mais forte na captura de requisitos no Solution Intent,
na coordenação de vários Agile Release Trains (ARTs) e Suppliers, e na necessidade de garantir
a conformidade com regulamentações e padrões.
Large Solution SAFe configuration
A Large Solution SAFe configuration é para o desenvolvimento das maiores e mais complexas
soluções que geralmente exigem vários Agile release trains e Suppliers, mas não precisam de
aspectos do nível de portfolio. Isso é comum em setores como o aeroespacial e de defesa,
automotivo e governamental, nos quais a large solution, e não a governança de portfólio,
é a preocupação principal.
Lean Budgets
Lean Budgets é um conjunto de práticas que minimizam a sobrecarga ao financiar e empoderar
os Value Streams ao invés de projetos, ao mesmo tempo em que mantém a governança
financeira e de adequação ao uso. Isso é possível por meio da avaliação objetiva dos sistemas
de trabalho, do gerenciamento ativo dos investimentos em Epics e dos ajustes dinâmicos
de budget.
Lean Portfolio Management (LPM)
A função do Lean Portfolio Management (LPM) tem o maior nível de tomada de decisões e
responsabilidade financeira para os produtos e Soluções em um portfólio SAFe.
Lean User Experience (Lean UX)
O Lean User Experience (Lean UX) é um mindset, uma cultura e um processo que
engloba métodos Lean-Agile. Ele implementa a funcionalidade em incrementos mínimos
viáveis e determina o sucesso ao medir os resultados em relação a uma hipótese de benefício.
Lean and Agile Principles
O SAFe se baseia em nove Lean and Agile Principles subjacentes e imutáveis. Esses princípios e
conceitos econômicos inspiram e informam os papéis e práticas do SAFe.
Lean-Agile Leaders
Lean-Agile Leaders são aprendizes de longo prazo responsáveis pela adoção com êxito do
SAFe e dos resultados que ele entrega. Eles ajudam e empoderam os times a elaborar sistemas
melhores ao aprender, demonstrar, ensinar e orientar sobre os princípios e as práticas LeanAgile do SAFe.
Lean-Agile Mindset
O Lean-Agile Mindset é a combinação de crenças, premissas e ações dos líderes e praticantes
do SAFe que adotam os conceitos do Agile Manifesto e do pensamento Lean. É o fundamento
pessoal, intelectual e de liderança para a adoção e a aplicação dos princípios e das práticas
de SAFe.
Metrics
Metrics são medidas acordadas usadas para avaliar como a organização está progredindo em
relação ao portfólio, à large solution, ao programa e aos objetivos de negócio e técnicos do time.
Milestones
Os milestones são usados para acompanhar o progresso em relação a uma meta ou evento
específicos. Há três tipos de milestones do SAFe: Milestones de Program Increment (PI), com
data fixa e de aprendizagem.
Model-Based Systems Engineering (MBSE)
Model-Based Systems Engineering (MBSE) é a prática de desenvolver um conjunto de
modelos de sistemas relacionados que ajudam a definir, projetar e documentar um sistema
em desenvolvimento. Estes modelos fornecem uma forma eficiente para explorar, atualizar e
comunicar aspectos do sistema para os stakeholders ao reduzir ou eliminar significativamente a
dependência em relação a documentos tradicionais.
Nonfunctional Requirements (NFRs)
Os Nonfunctional Requirements (NFRs) definem atributos do sistema como segurança,
confiabilidade, desempenho, capacidade de manutenção, escalabilidade e usabilidade. Eles
atuam como limitações ou restrições em relação ao design do sistema nos diferentes backlogs.
Portfolio Backlog
O Portfolio Backlog é o backlog de nível mais alto no SAFe. Ele fornece uma área de
armazenamento para os próximos Epics de negócio e enabler Epics destinados a criar um
conjunto abrangente de Soluções, que provê diferencial competitivo e melhorias operacionais
necessárias para atender aos Strategic Themes e facilitar o sucesso de negócio.
Portfolio Kanban
O Portfolio Kanban é um método usado para visualizar, gerenciar e analisar a priorização e o
fluxo dos Epics de portfolio, da concepção à implementação e conclusão.
Portfolio Level
O Portfolio Level contém os princípios, as práticas e funções necessárias para iniciar e reger
um conjunto de Value Streams de desenvolvimento. Este é o local em que a estratégia e o
financiamento de investimentos são definidos para value streams e suas Soluções. Este nível
também provê operações de portfólio Agile e governança Lean para as pessoas e os recursos
necessários para entregar as soluções.
Portfolio SAFe configuration
A Portfolio SAFe configuration ajuda a alinhar a execução do portfólio com a estratégia
corporativa, organizando o desenvolvimento Agile em torno do fluxo de valor, por meio de um
ou mais value streams. Ela fornece agilidade corporativa por meio de princípios e práticas para
a estratégia de portfólio e o financiamento de investimentos, as operações de portfolio Agile e
a governança Lean.
Pre-and Post-PI Planning
Os eventos de Pre– and Post–Program Increment (PI) Planning são usados para preparação
e acompanhamento posterior dos eventos de PI Planning dos Agile Release Trains (ARTs) e
Suppliers em um Solution Train.
Product Management
O Product Management tem autoridade de conteúdo para o Program Backlog. Eles são
responsáveis por identificar as necessidades do Customer, priorizando Features, direcionando
o trabalho por meio do Program Kanban e desenvolvendo Vision e Roadmap do programa.
Product Owner (PO)
O Product Owner (PO) é um membro do Agile Team responsável por definir as Stories e
priorizar o Team Backlog para direcionar a execução das prioridades do programa, mantendo a
integridade conceitual e técnica das Features ou componentes para o time.
Program Backlog
O Program Backlog é a área de armazenamento das Features futuras, que se destinam a
atender às necessidades dos usuários e entregar benefícios de negócios para um único
Agile Release Train (ART). Ele também inclui os enabler features necessários para compor a
Architectural Runway.
Program Increment (PI)
Um Program Increment (PI) é um timebox no qual um Agile Release Train (ART) entrega valor
incremental na forma de software e sistemas funcionando e testados. Normalmente, os PIs têm
a duração de oito a doze semanas. O padrão mais comum para um PI é de quatro iterations de
desenvolvimento, seguidas por uma iteration de Innovation and Planning (IP).
Program Increment (PI) Planning
O Program Increment (PI) Planning é um evento baseado em cadência e presencial, atuando
como o cerne do Agile Release Train (ART) ao alinhar todos os times do ART para uma Vision e
missão compartilhadas.
Program Kanban
Os sistemas Program e Solution Kanban são métodos para visualizar e gerenciar o fluxo de
Features e Capabilities, desde a concepção até a análise, a implementação e o release através
do Continuous Delivery Pipeline.
Program Level
O Program Level contém os papéis e atividades necessários para entregar soluções continuamente
por meio de um Agile Release Train (ART).
Refactoring
O refactoring é a atividade de melhorar a estrutura interna ou a operação de um código ou
componente, sem alterar seu comportamento externo.
Release Train Engineer (RTE)
O Release Train Engineer (RTE) é o líder servidor e coach do Agile Release Train (ART). As
principais responsabilidades do RTE são facilitar os processos e os eventos de ART e auxiliar os
times na entrega de valor. Os RTEs se comunicam com os stakeholders, escalam impedimentos,
ajudam a gerenciar riscos e impulsionam a melhoria implacável.
Release on Demand
Release on Demand é o processo pelo qual Features implantadas em ambiente de produção
são liberados de modo incremental ou imediato para os Customers com base na demanda
do mercado.
Roadmap
O Roadmap é uma agenda de eventos e Milestones que informa entregas de Solution
planejadas na linha do tempo. Ele inclui compromissos em relação ao Program Increment (PI)
imediatamente seguinte e oferece visibilidade sobre os entregáveis previstos nos próximos PIs.
SAFe Implementation Roadmap
O SAFe Implementation Roadmap consiste em uma visão gráfica e uma série de 12 artigos que
descreve uma estratégia e um conjunto ordenado de atividades que se mostraram eficazes em
uma implementação SAFe de sucesso.
SAFe Program Consultants (SPCs)
Os SAFe Program Consultants (SPCs) são agentes de mudança que combinam seu conhecimento
técnico do SAFe com uma motivação intrínseca de melhorar os processos de desenvolvimento de
software e sistemas da empresa. Eles desempenham uma função fundamental na implementação
SAFe de sucesso. Os SPCs são oriundos de vários papéis internos ou externos, incluindo líderes
de negócios e tecnologia, gerentes de portfólio/programa/projeto, líderes de processos,
arquitetos, analistas e consultores.
Scrum Master
Scrum Masters são líderes servidores e coaches de um Agile Team. Eles ajudam a orientar o
time sobre o Scrum, Extreme Programming (XP), Kanban e SAFe, e asseguram que o processo
Agile acordado esteja sendo seguido. Eles também ajudam a eliminar impedimentos e a promover um ambiente para o dinamismo de um time de alto desempenho, o fluxo contínuo e
à melhoria implacável.
ScrumXP
ScrumXP é um processo enxuto para entregar valor por times interfuncionais e auto-organizados
no SAFe. Ele combina o poder das práticas de gerenciamento de projetos do Scrum com práticas
de Extreme Programming (XP).
Set-Based Design
O Set-Based Design (SBD) é uma prática que mantém os requisitos e as opções de design
flexíveis pelo maior tempo possível durante o processo de desenvolvimento. Ao invés de optar
por uma única solução antecipadamente, o SBD identifica e explora simultaneamente várias
opções, eliminando escolhas menos eficazes ao longo do tempo. Ele aprimora a flexibilidade
no processo de design, comprometendo-se com solutions técnicas somente após validar as
premissas, o que produz melhores resultados econômicos.
Shared Services
Os Shared Services representam os papéis, as pessoas e os serviços especializados que são
necessários para o sucesso de um Agile Release Train (ART) ou de um Solution Train, mas que
não podem ser dedicados em tempo integral.
Solution
Cada Value Stream produz uma ou mais Solutions, que são produtos, serviços ou sistemas
entregues ao Customer, sejam internos ou externos à Enterprise.
Solution Architect/Engineer
Solution Architect/Engineer representa um indivíduo ou um pequeno time que define uma
visão técnica e arquitetural compartilhada para a Solution em desenvolvimento. Eles participam
na determinação do sistema, dos subsistemas e das interfaces, validam as suposições
tecnológicas e avaliam alternativas, trabalhando em conjunto com o Agile Release Train (ARTs)
e o Solution Train.
Solution Backlog
O Solution Backlog é a área de armazenamento para as próximas Capabilities e enablers,
sendo que cada uma delas pode abranger vários ARTs e tem como objetivo incrementar a
Solution e criar sua architectural runway.
Solution Context
O Solution Context identifica aspectos essenciais do ambiente operacional para uma Solution.
Ele fornece uma compreensão essencial dos requisitos, uso, instalação, operação e suporte da
própria solution. O Solution context influencia fortemente as oportunidades e restrições para o
lançamento sob demanda.
Solution Demo
O Solution Demo é onde os resultados do desenvolvimento do Solution Train são integrados,
avaliados e apresentados para os Customers e outros stakeholders.
Solution Management
O Solution Management tem autoridade de conteúdo para o Solution Backlog. Eles trabalham
com os customers para compreender suas necessidades, priorizar Capabilities, criar a Solution
vision e o roadmap, definir requisitos e orientar o trabalho por meio do Solution Kanban.
Solution Train
O Solution Train é a estrutura organizacional usada para criar grandes e complexas Solutions
que exigem a coordenação de vários Agile Release Trains (ARTs), bem como a contribuição dos
Suppliers. Ele alinha os ARTs com uma missão compartilhada de negócios e tecnologia usando
a solution Vision, o Backlog, o Roadmap e um Program Increment (PI) alinhado
Spanning Palette
O Spanning Palette contém vários papéis e artefatos que podem ser aplicáveis a um time,
programa, large solution ou contexto de portfólio específico. Elemento essencial da flexibilidade
e configurabilidade do SAFe, a spanning palette permite que as organizações apliquem apenas
os elementos necessários para sua configuração.
Spikes
Spikes são um tipo de Enabler Story de exploração no SAFe. Definidos inicialmente no
Extreme Programming (XP), eles representam atividades, como pesquisa, design, investigação,
exploração e prototipagem. A finalidade deles é obter o conhecimento necessário para reduzir
o risco de uma abordagem técnica, entender melhor um requisito ou aumentar a confiabilidade
de uma estimativa da story.
Stories
As stories são descrições breves de uma parte pequena de uma funcionalidade desejada,
escritas na voz do usuário. Os Agile Teams implementam pequenas fatias verticais de
funcionalidade do sistema e estas são dimensionadas de modo que possam ser concluídos em
uma única Iteration.
Supplier
Um Supplier é uma organização interna ou externa que desenvolve e entrega componentes,
subsistemas ou serviços que ajudam os Solution Trains a entregarem Solutions a seus Customers.
System Demo
A System Demo é um importante evento que fornece uma visão integrada das novas Features
da Iteration mais recente, entregue por todos os times do Agile Release Train (ART). Cada
demo oferece aos stakeholders do ART uma medida objetiva do progresso durante um
Program Increment (PI).
System Team
O System Team é um Agile Team especializado que suporta a elaboração e o uso do ambiente
de desenvolvimento Agile, incluindo Continuous Integration, automação de testes e Continuous
Deployment. O System Team provê o suporte à integração dos entregáveis dos Agile teams,
desempenha testes de Solution de ponta a ponta quando necessário e auxilia na implementação
e release.
Team Backlog
O Team Backlog contém User Stories e enabler Stories que se originam do Program Backlog,
assim como stories que surgem localmente do contexto local do time. Ele também pode incluir
outros itens de trabalho, representando tudo que um time precisa fazer para imcrementar sua
parte do sistema.
Team Kanban
O Team Kanban é um método que ajuda os times a facilitar o fluxo de valor ao visualizar o
fluxo de trabalho, estabelecer limites de Work In Process (WIP), medir o throughput e melhorar
continuamente seu processo.
Team Level
O Team Level contém os papéis, as atividades, os eventos e processos que os Agile Teams
criam e fornecem valor no contexto do Agile Release Train (ART).
Test-First
O Test-First é uma prática de Built-In Quality derivada do Extreme Programming (XP) que
recomenda a criação de testes antes de escrever o código com a finalidade de melhorar a
entrega, concentrando-se nos resultados pretendidos.
Value Stream Coordination
O Value Stream Coordination fornece orientações para gerenciar as dependências e explorar as
oportunidades em um portfólio.
Value Streams
Os Value Streams representam uma série de etapas que uma organização segue para criar
Solutions que fornecem um fluxo contínuo de valor para um Customer. Os value streams
no SAFe são usados para definir e entender os objetivos de negócio de nível de Portfolio e
organizar os Agile Release Trains (ARTs) para entregar valor mais rapidamente.
Vision
A Vision é uma descrição do estado futuro da Solution em desenvolvimento. Ela reflete as
necessidades de Customer e de stakeholder, bem como Feature e Capabilities propostos para
atender a essas necessidades.
Weighted Shortest Job First (WSJF)
Weighted Shortest Job First (WSJF) é um modelo de priorização usado para sequenciar
trabalhos (por ex., Features, Capabilities e Epics) para gerar o máximo benefício econômico.
No SAFe, o WSJF é estimado como o Cost of Delay (CoD) dividido pelo tamanho do trabalho.
A Definition of Ready (DoR) e a Definition of Done (DoD) são listas de critérios importantes para garantir a qualidade e o sucesso do projeto, mas em momentos diferentes do ciclo de vida do desenvolvimento.
Tailoring (Customização ; Alfaiataria; Personalização ) envolve a adaptação considerada para a abordagem, governança e os processos para torná-los mais adequados a determinado ambiente e ao projeto.
Fonte: © Scaled Agile, Inc. – scaledagileframework.com