COBIT 2019

 6 (SEIS) Princípios de Governança  Garantir o alinhamento com os objetivos da organização. / Garantir a entrega de benefícios. / Otimizar o risco. / Otimizar os recursos. / Garantir transparência e prestação de contas. /
Promover avaliação contínua e melhoria.
 Componentes do Sistema de Governança  Incluem fatores que influenciam a implementação bem-sucedida de governança de TI, como  Processos / Estruturas organizacionais / Políticas e procedimentos /
Informações / Cultura, ética e comportamento / Pessoas, habilidades e competências / Serviços, infraestrutura e aplicações.
 Domínios e Objetivos de Governança e Gestão  são detalhados em 40 objetivos de governança e gestão, que substituem os antigos "processos" do COBIT 5.
 Domínio GOV – Avaliar, Dirigir e Monitorar (Governança)  Foco: Responsabilidade do corpo diretivo em avaliar necessidades, direcionar e monitorar o desempenho da TI.
1. EDM01 – Garantir o Estabelecimento do Sistema de Governança: Assegura que a estrutura de governança esteja definida, implementada e atualizada.
2. EDM02 – Garantir a Realização dos Benefícios: Garante que a TI contribua para o valor de negócio e os resultados esperados sejam atingidos.
3. EDM03 – Garantir Otimização de Riscos: Estabelece que os riscos sejam identificados, analisados e tratados de forma eficaz.
4. EDM04 – Garantir Otimização de Recursos: Garante que os recursos de TI (humanos, financeiros, tecnológicos) sejam utilizados com eficiência.
5. EDM05 – Garantir Transparência com as Partes Interessadas: Assegura que informações relevantes sejam comunicadas às partes interessadas com clareza.
 Domínio APO – Alinhar, Planejar e Organizar (Gestão Estratégica e Organizacional)  Foco: Definir estratégia, arquitetura, estrutura organizacional e processos.
6. APO01 – Gerenciar a Estrutura de Gestão de TI: Define e mantém a estrutura organizacional, papéis e responsabilidades da TI.
7. APO02 – Gerenciar Estratégia de TI: Garante o alinhamento da TI com a estratégia de negócio.
8. APO03 – Gerenciar Arquitetura Empresarial: Define a arquitetura corporativa e tecnológica para suportar os objetivos da organização.
9. APO04 – Gerenciar Inovação: Promove a identificação e adoção de inovações tecnológicas alinhadas ao negócio.
10. APO05 – Gerenciar Portfólio: Garante que projetos e programas estejam priorizados conforme a estratégia da organização.
11. APO06 – Gerenciar Orçamento e Custos: Planeja e monitora os custos relacionados à TI, garantindo uso eficiente dos recursos.
12. APO07 – Gerenciar Recursos Humanos: Assegura o desenvolvimento e gestão de competências da equipe de TI.
13. APO08 – Gerenciar Relacionamentos: Gerencia as relações entre a TI e suas partes interessadas, internas e externas.
14. APO09 – Gerenciar Acordos de Serviço: Define e monitora contratos e SLAs com fornecedores e clientes internos.
15. APO10 – Gerenciar Fornecedores: Controla contratos, desempenho e conformidade dos fornecedores.
16. APO11 – Gerenciar Qualidade: Estabelece práticas para garantir a qualidade dos produtos e serviços de TI.
17. APO12 – Gerenciar Riscos: Identifica, avalia e trata riscos relacionados à TI.
18. APO13 – Gerenciar Segurança: Define políticas e controles de segurança da informação.
 Domínio BAI – Construir, Adquirir e Implementar (Gestão de Soluções)  Foco: Gerenciar desenvolvimento, aquisição e entrega de soluções e mudanças.
19. BAI01 – Gerenciar Programas e Projetos: Controla escopo, tempo, orçamento e entrega dos projetos de TI.
20. BAI02 – Gerenciar Definição de Requisitos: Coleta e valida requisitos das partes interessadas.
21. BAI03 – Gerenciar Identificação e Construção de Soluções: Desenvolve e valida soluções tecnológicas.
22. BAI04 – Gerenciar Disponibilidade e Capacidade: Garante que os serviços estejam disponíveis e com desempenho adequado.
23. BAI05 – Gerenciar Ativos de TI: Controla ciclo de vida de ativos como hardware e software.
24. BAI06 – Gerenciar Configuração: Mantém informações atualizadas sobre os componentes da infraestrutura de TI.
25. BAI07 – Gerenciar Mudanças: Controla mudanças em sistemas e serviços de forma segura e documentada.
26. BAI08 – Gerenciar Aceite e Transição: Garante que novas soluções sejam aceitas e integradas adequadamente.
27. BAI09 – Gerenciar Entrega e Suporte de Serviços: Assegura a entrega de serviços de acordo com os requisitos.
28. BAI10 – Gerenciar Conhecimento: Promove a gestão do conhecimento técnico e organizacional.
29. BAI11 – Gerenciar Dados: Controla a integridade, segurança e disponibilidade dos dados corporativos.
 Domínio DSS – Entregar, Servir e Suportar (Gestão Operacional)  Foco: Garantir a entrega eficiente e segura dos serviços de TI no dia a dia.
30. DSS01 – Gerenciar Operações: Monitora e executa as operações de TI em conformidade com os processos.
31. DSS02 – Gerenciar Requisições de Serviço e Incidentes: Trata solicitações dos usuários e resolução de incidentes.
32. DSS03 – Gerenciar Problemas: Analisa causas de incidentes e evita recorrência de falhas.
33. DSS04 – Gerenciar Continuidade: Planeja e assegura a continuidade dos serviços de TI em casos de falhas graves.
34. DSS05 – Gerenciar Serviços de Segurança: Monitora ameaças e garante resposta a incidentes de segurança.
35. DSS06 – Gerenciar Controles de Processos de Negócio: Assegura que os controles internos de processos estejam operando corretamente.
 Domínio MEA – Monitorar, Avaliar e Analisar (Gestão de Monitoramento e Conformidade)  Foco: Medir desempenho e conformidade dos serviços e processos.
36. MEA01 – Monitorar, Avaliar e Analisar o Desempenho e Conformidade: Acompanha e avalia se os objetivos de TI estão sendo atingidos.
37. MEA02 – Monitorar, Avaliar e Analisar o Sistema de Controle Interno: Verifica se os controles estão funcionando como esperado.
38. MEA03 – Monitorar, Avaliar e Analisar a Conformidade com Requisitos Externos: Garante aderência a leis, regulamentações e contratos.
 Domínio APO (continuação) – Novos objetivos introduzidos no COBIT 2019
39. APO14 – Gerenciar Dados (aprimorado em 2019): Fortalece a governança de dados como ativo estratégico, com foco em qualidade, acesso e valor.
40. BAI12 – Gerenciar Privacidade: Introduzido para lidar com requisitos de privacidade e conformidade com leis como LGPD e GDPR.
 Fatores de Design  são elementos contextuais usados para personalizar a aplicação do COBIT em cada organização. Exemplos incluem  Estratégia corporativa / Tolerância a riscos
Ameaças e requisitos de conformidade / Tecnologia usada / Funções da TI (centralizada, descentralizada, terceirizada)
 Esses fatores ajudam a adaptar o sistema de governança às necessidades específicas de cada ambiente organizacional.
 Modelo de Maturidade (Níveis de Capacidade)  COBIT permite avaliar a maturidade dos processos de TI por meio de 6 níveis de capacidade. Isso ajuda na definição de metas realistas e no acompanhamento da
evolução.
 Nível 0 – Incompleto  processo não existe ou falha sistematicamente em atingir o propósito pretendido.
 Nível 1 – Executado  processo é minimamente executado e atinge seu propósito de forma básica. Ainda não há padronização, documentação formal ou controle sobre a execução.
 Nível 2 – Gerenciado  processo é executado de forma gerenciada. Já existem práticas documentadas, recursos designados e responsabilidades atribuídas. A execução é planejada, monitorada e ajustada, embora
possa haver variações. Já há um certo nível de controle e repetibilidade.
 Nível 3 – Estabelecido  processo está padronizado e bem definido, com procedimentos documentados, ferramentas apropriadas e integração com outros processos da organização. A execução segue padrões
formais, e há consistência e previsibilidade nos resultados. É um marco importante de maturidade organizacional.
 Nível 4 – Previsível  processo é monitorado com métricas precisas, e os resultados são estatisticamente previsíveis. A organização utiliza indicadores de desempenho (KPIs) para detectar desvios e promover
melhorias contínuas. O controle é quantitativo, com nível avançado de governança e padronização.
 Nível 5 – Otimizado  processo é continuamente melhorado com base em feedback e inovações tecnológicas. A organização promove melhorias proativas, usando lições aprendidas, benchmarking e automação. Há
uma cultura de excelência e inovação, com forte alinhamento estratégico.
ITIL 4
 Principais Componentes da ITIL 4
1. Sistema de Valor de Serviço (SVS – Service Value System)  é o coração da ITIL 4, descrevendo como todos os componentes e atividades da organização trabalham juntos para criar valor. Ele integra governança, práticas,
princípios e melhorias contínuas, garantindo alinhamento estratégico entre TI e negócios.
2. Cadeia de Valor de Serviço (SVC – Service Value Chain)  é um modelo operacional que detalha as atividades-chave necessárias para criar, entregar e manter produtos e serviços. Ela é composta por (6) seis atividades
centrais  Planejar / Engajar / Projetar e Transicionar / Obter e Construir / Entregar e Suportar / Melhorar
 Essas atividades se interconectam e podem ser combinadas de diversas formas, formando fluxos de valor que respondem às demandas do cliente.
3. Princípios Orientadores (Guiding Principles)  ajudam a tomar decisões estratégicas e operacionais  1. Foque no valor / 2. Comece de onde você está / 3. Progrida iterativamente com feedback / 4. Colabore e
promova visibilidade / 5. Pense e trabalhe holisticamente / 6. Mantenha as coisas simples e práticas / 7. Otimize e automatize
 Esses princípios são universais e aplicáveis a qualquer tipo de decisão organizacional.
4. Governança  é essencial para garantir que a organização opere de acordo com sua estratégia . Ela define autoridade, responsabilidades e mecanismos de monitoramento para que os serviços estejam sempre
alinhados aos objetivos do negócio.
5. Melhoria Contínua (Continual Improvement)  permeia todo o SVS, sendo um elemento essencial para evolução dos serviços. Modelo cíclico de 7 (sete) etapas  1. O que deve ser melhorado? / [Link] estamos
agora? / 3. Onde queremos chegar? / [Link] chegamos lá? / [Link] para chegar lá / 6. Verificamos se chegamos? / [Link] manter o momento?
 Este ciclo ajuda a mensurar, planejar e implementar melhorias significativas e sustentáveis.
 Práticas da ITIL 4: substituem os antigos “processos” da ITIL v3. A ITIL 4 define 34 práticas de gerenciamento. Cada prática é flexível, adaptável e integrável com outras metodologias modernas. São agrupadas em três
categorias:
1. Práticas de Gerenciamento Geral: incluem governança, estratégia, arquitetura, riscos, segurança, entre outras.
2. Práticas de Gerenciamento de Serviço: como gerenciamento de incidentes, mudanças, nível de serviço, disponibilidade, continuidade etc.
3. Práticas de Gerenciamento Técnico: como desenvolvimento de software, gerenciamento de infraestrutura e automação.
BPMN
QUATRO TIPOS DE SÍMBOLOS  representam o comportamento do processo.
1. OBJETOS DE FLUXO  divididos em três tipos:
 ATIVIDADES  trabalho que é executado, algo que é feito, simbolizados por quadrados.
 EVENTOS  ocorrências, algo que acontece, simbolizados por círculos.
 GATEWAYS  pontos de desvio que determinarão o caminho que o processo seguirá, simbolizados por diamantes.
2. SWIMLANES  dois tipos:
 PISCINAS  representam processos e participantes no processo.
 RAIAS  cada piscina possui várias raias, que simbolizam os papeis, áreas e responsabilidades no processo.
3. OBJETOS DE CONEXÃO  conectam objetos de fluxo.
 FLUXO DE SEQUÊNCIA  mostra em que ordem as atividades são executadas, e é simbolizado por uma linha cheia e uma seta adiante.
 FLUXO DE MENSAGENS  indica quais as mensagens que fluem entre dois processos/piscinas, e é representada por uma linha tracejada, um círculo aberto e uma seta aberta no fim.
 ASSOCIAÇÃO  conecta os artefatos aos objetos de fluxo, e é simbolizado por uma linha tracejada.
4. ARTEFATOS  trazem um maior nível de detalhe ao diagrama, pois permitem que informações extras sejam trazidas.
 ANOTAÇÕES permitem que o modelador descreva partes adicionais do fluxo do modelo ou notação.
 GRUPOS organizam tarefas ou processos que possuem relevância no processo como um todo.
 OBJETOS DE DADOS representam dados colocados no processo, dados que resultam do processo, dados que precisam ser coletados ou dados que devem ser armazenados.
DIAGRAMA DE COREOGRAFIA (Coreography Diagram)  tipo de diagrama que difere em propósito e comportamento da representação de um processo de negócio padrão (diagrama de orquestração). Define como processos
interagem uns com os outros.
DIAGRAMA DE ORQUESTRAÇÃO  mais conhecido e utilizado pela maioria das ferramentas de modelagem e define o fluxo das atividades do processo de uma organização.
OKR (Objective and Key Results ou Objetivos e Resultados-Chave)
Sistema de gestão usado por empresas que buscam nortear sua estratégia por meio de dados, ciclos curtos de aprendizado e foco no valor agregado aos seus clientes.
 Objetivos (Objectives) são descrições qualitativas curtas, envolventes e desafiadoras.
 Resultados-chave (Key Results) estabelecem e monitoram COMO saber se a organização está chegando no objetivo.
 Os resultados-chave são quantitativos, específicos e limitados no tempo. Recomenda-se que para cada objetivo existam de dois até cinco resultados-chave.
Metodologia de Ponto de Função (Function Points - FP)
APF  mensurar o esforço necessário para desenvolver ou manter um software com base na complexidade funcional, não no código.
 Componentes Funcionais  categoriza as funções em 5 tipos:
 Entradas Externas (EE) – dados que entram no sistema (ex: formulários).
 Saídas Externas (SE) – dados processados enviados para fora (ex: relatórios).
 Consultas Externas (CE) – combinações de entrada e saída simples.
 Arquivos Lógicos Internos (ALI) – base de dados mantida pelo sistema.
 Arquivos de Interface Externa (AIE) – base de dados usada, mas mantida por outro sistema.
 Cálculo  Cada componente recebe uma complexidade (baixa, média ou alta) e um peso. O total é ajustado por um fator de complexidade técnica para gerar os Pontos de Função ajustados (PFa).
 Aplicações  Estimativas de esforço e custo. / Comparação de produtividade entre projetos. / Contratos de desenvolvimento de software.
Story Points
Story Points  unidade relativa de medida de esforço, usada principalmente em metodologias ágeis (como Scrum), para estimar o trabalho necessário para completar uma user story (história de usuário). Objetivo: Avaliar o esforço
relativo, a complexidade, os riscos e a incerteza de uma tarefa, em vez de medir tempo diretamente.
 Como são atribuídos  Estimativas feitas em conjunto pela equipe. / Utilização de escalas como Fibonacci (1, 2, 3, 5, 8, 13...), T-shirt sizes (P, M, G) ou outras. / Baseadas na experiência da equipe e em comparações com
histórias anteriores.
 Rational Unified Process (RUP)
RUP  metodologia de desenvolvimento de software que oferece uma abordagem estruturada, iterativa e incremental para a produção de sistemas de software de alta qualidade. Ele combina boas práticas da engenharia de
software com foco em organização, documentação e gestão de riscos.
 Não é um processo rígido, mas sim um framework adaptável que pode ser ajustado conforme as necessidades específicas de cada projeto ou organização.
 Seu principal objetivo é guiar as equipes durante todo o ciclo de vida do desenvolvimento, desde a concepção até a entrega e manutenção do sistema.
 O processo é dirigido por casos de uso (use-case driven)
 O RUP é organizado em quatro fases principais:
1. Iniciação (Inception) – Define o escopo do projeto, os principais casos de uso, riscos iniciais e uma estimativa preliminar de tempo e custo. O objetivo é garantir o entendimento do problema e a viabilidade do projeto.
2. Elaboração (Elaboration) – Refina a visão do sistema, define sua arquitetura base, detalha os principais requisitos e resolve riscos técnicos. Ao final desta fase, espera-se ter uma arquitetura sólida e um plano mais
preciso.
3. Construção (Construction) – Consiste no desenvolvimento iterativo do sistema, com codificação, testes e integração contínuos. É a fase onde a maior parte do software funcional é construída.
4. Transição (Transition) – Envolve a entrega do produto ao cliente ou ao ambiente de produção. Inclui testes finais, treinamentos, correções e ajustes baseados no feedback do usuário.
 Paralelamente às fases, o RUP define disciplinas (ou workflows) que abrangem atividades técnicas e de apoio, como: modelagem de negócios, requisitos, análise e design, implementação, testes, configuração e
gerenciamento de mudanças, gerenciamento de projetos e ambiente de desenvolvimento.
CMMI (Capability Maturity Model Integration)
CMMI  busca elevar a qualidade, previsibilidade e eficiência dos processos organizacionais por meio da definição de práticas estruturadas e evolutivas. O CMMI é construído com base em níveis de maturidade, que representam
diferentes graus de sofisticação e controle dos processos de uma organização.
1. Inicial: processos são imprevisíveis, mal controlados e reativos. As organizações nesse estágio frequentemente dependem do esforço individual, e os resultados são inconsistentes. Não há práticas estabelecidas ou repetíveis.
2. Gerenciado: projetos são planejados e gerenciados. Existem práticas básicas de gerenciamento de projetos implementadas, como controle de requisitos, cronogramas e orçamento. Os processos são documentados em nível
de projeto, mas ainda não são padronizados na organização como um todo.
3. Definido: processos são padronizados, documentados e integrados em toda a organização. Existe um conjunto comum de processos organizacionais, adaptado para diferentes projetos. A gestão é mais proativa e baseada em
boas práticas consolidadas.
4. Gerenciado Quantitativamente: organização utiliza medições e controles estatísticos para monitorar e controlar os processos. A previsibilidade é elevada, e decisões são tomadas com base em dados quantitativos e métricas
de desempenho.
5. Otimização: processos são continuamente melhorados por meio de inovações e feedback quantitativo. A organização é capaz de se adaptar rapidamente a mudanças e busca constantemente a excelência operacional,
reduzindo variabilidade e eliminando causas de falhas.
[Link] (Melhoria de Processo do Software Brasileiro)
[Link]  define práticas organizadas em níveis de maturidade, que representam o grau de formalização, institucionalização e melhoria contínua dos processos de software. A principal característica do [Link] é a adoção
incremental, permitindo que as empresas evoluam de forma gradual, passo a passo, conforme sua capacidade. O modelo é estruturado em sete níveis de maturidade:
 Nível G – Parcialmente Gerenciado: Neste nível, a organização estabelece práticas básicas de gerenciamento, como planejamento e acompanhamento de projetos, e controle de requisitos. É o ponto de partida para empresas
que estão iniciando a institucionalização de seus processos.
 Nível F – Gerenciado: Amplia o controle sobre os processos, incorporando práticas como medição, garantia da qualidade e gerência de configurações. Há maior visibilidade sobre os resultados e a execução dos projetos.
 Nível E – Parcialmente Definido: Começa a definição dos processos organizacionais padrão, que servirão de base para os projetos. Os processos tornam-se mais consistentes e menos dependentes de indivíduos.
 Nível D – Largamente Definido: A organização passa a adotar e adaptar seus processos definidos com base em metas organizacionais. A gerência de recursos humanos e a verificação e validação dos produtos também são
incorporadas.
 Nível C – Definido: Todos os processos são padronizados, documentados e utilizados de maneira consistente em toda a organização. A organização começa a analisar e melhorar seus processos de forma sistemática.
 Nível B – Gerenciado Quantitativamente: Introduz a medição quantitativa dos processos e produtos. A organização utiliza dados e métricas para entender o desempenho de seus processos, reduzindo variações e
aumentando a previsibilidade.
 Nível A – Em Otimização: No nível mais alto, a organização realiza melhorias contínuas com base em análise quantitativa e inovações. Os processos são refinados de forma proativa, buscando a excelência operacional.
METODOLOGIA ÁGIL
SCRUM  baseado em código para gerenciar PROJETOS, PRODUTOS E PROCESSOS.
 CARACTERÍSTICAS  Adaptação em vez de planejamento / NÃO utiliza muita documentação / processos mais simplificados / facilita adaptação às mudanças de requisitos / permite entregas rápidas e menores /
Abordagem iterativa e incremental para aperfeiçoar e otimizar a previsibilidade e controle de riscos / PAPÉIS: são poucos, mas bem definidos.
 Usado em ambientes complexos, onde os requisitos e as prioridades mudam constantemente.
 Empirismo  afirma que conhecimento vem da experiência e da tomada de decisões com base naquilo que é verdadeiro e conhecido.
 3 PILARES FUNDAMENTAIS  Transparência, Inspeção e Adaptação (T.I.A).
 SCRUM TEAM (ST)  auto organizável (escolhe qual melhor forma para realizar próprio trabalho) e multifuncional (possui todas competências/não depende de outros de fora da equipe). Responsável por entregar
produtos de FORMA ITERATIVA/INCREMENTAL, maximizando oportunidades de realimentação (feedback).
 SPRINT  ciclos completos de desenvolvimento de DURAÇÃO FIXA (ATÉ 1 MÊS).
 Permite feedbacks constantes quanto ao que está sendo desenvolvido.
 FINAL DE CADA SPRINT  incrementos potencialmente entregáveis do produto. / Entrega-se incremento potencialmente funcional (capaz de entrar em produção!).
 SCRUM TEAM = Product Owner (PO) + Scrum Master (SM) + Development Team (DT).
 PO  macrogestão e gestão do produto / Maximizar valor do produto e do trabalho da equipe de desenvolvimento / único que pode gerenciar o Product Backlog (PB) / Pode delegar atividades de gerenciamento para ST,
mas ainda será considerado o responsável pelos trabalhos / Prioriza E Ordena itens do PB e seleciona aqueles que serão implementados / Garante o ROI / Expressa claramente itens do PB / Garante que PB seja visível,
transparente, claro para todos, e mostrar o que o ST vai trabalhar a seguir / Por garantir que o DT entenda os itens do PB no nível necessário.
 DT ≠ ST  SM pode ser do DT e o PO pode ser do DT, mas um SM jamais pode ser o PO!
 DT  3 e 9 integrantes  deve ser pequeno, de forma a se manter ágil e produtivo, e grande o suficiente de forma que a coordenação dos membros não cause problemas.
 Responsável pela MICRO-GESTÃO E CRIAÇÃO do produto.
 AUTO ORGANIZADOS  ninguém (nem mesmo o SM) diz ao DT como transformar o PB em incrementos de funcionalidades potencialmente utilizáveis.
 Multifuncionais  possuem todas habilidades necessárias para criar o incremento do Produto.
 Scrum NÃO RECONHECE TÍTULOS para os integrantes do DT que não seja desenvolvedor, independentemente do trabalho que está sendo realizado pela pessoa.
 INTEGRANTES DO DT PODEM TER HABILIDADES especializadas, mas a responsabilidade pertence aos desenvolvedores como um todo.
 Não contém times dedicados, tais como teste ou análise de negócios.
 Estruturados e autorizados pela organização para organizar e gerenciar seu próprio trabalho.
 SCRUM MASTER (SM)  responsável pela gestão de PESSOAS/PROCESSO.
 Deve garantir que o Scrum seja entendido/aplicado (garante que o ST adere à teoria/práticas/regras do Scrum).
 Ajuda os que estão fora do ST a entender quais interações SÃO ÚTEIS E QUAIS NÃO SÃO.
 Ajuda todos a mudarem estas interações para maximizar o valor criado pelo ST.
 Responsável por  ORIENTAR PO na criação e ordenação do PB + Garantir que regras do Scrum estejam sendo cumpridas e seus valores estejam sendo seguidos + AJUDAR remover impedimentos que o time
enfrente, fazendo isso sem o uso de qualquer autoridade + FAZER com que reunião flua adequadamente, embora não seja o responsável pela condução + AJUDAR treinar DT em autogerenciamento e
interdisciplinaridade + TREINAR o DT em ambientes organizacionais nos quais o Scrum não é totalmente adotado e compreendido + ENSINAR ST a criar itens do PB de forma clara e concisa + AUXILIAR PO na
comunicação clara da visão, objetivo e itens do PB para o DT.
 UTILIZA TÉCNICAS  facilitação/coaching para ST visualizar problema/encontrar melhor solução.
 ARTEFATOS
1. SPRINT (CORRIDA)  unidade básica de desenvolvimento; dura entre 1 semana e 1 mês (+/-); são um esforço dentro de uma "caixa de tempo" (duração específica) de um comprimento constante.
2. PRODUCT INCREMENT  final de cada sprint, entrega de um incremento do produt o, resultado do que foi produzido durante a sprint. Permite ao PO perceber o valor do investimento e vislumbrar outras
possibilidades.
3. BACKLOG  conjunto de requisitos priorizados pelo PO; UTILIZA 4 ARTEFATOS PRINCIPAIS:
 PB  lista priorizada de tudo que pode ser necessário no produto.
 SPRINT BACKLOG  lista de tarefas para transformar o PB, por uma Sprint, em um incremento do produto potencialmente entregável.
 BURNDOWN DE RELEASE  mede PB restante ao longo do tempo de um plano de release.
 BURNDOWN DE SPRINT  mede itens do Sprint Backlog restantes ao longo do tempo de uma Sprint.
3 FASES PRINCIPAIS:
1. PRÉ-PLANEJAMENTO (PRE-GAME PHASE)  Define sistema sendo desenvolvido. Cria-se PB + arquitetura de alto nível.
2. DESENVOLVIMENTO (GAME PHASE)  sistema desenvolvido em sprints, por meio de uma abordagem iterativa. A cada sprint, novas funcionalidades são adicionadas de modo tradicional , (análise, projeto,
implementação, etc).
3. PÓS-PLANEJAMENTO (POST-GAME PHASE)  Após desenvolvimento são feitas reuniões para analisar o progresso do projeto e demonstrar o software atual para os clientes. Aqui são feitas as etapas de integração,
testes finais e documentação.
KANBAN  método para GESTÃO DE MUDANÇAS com foco na visualização do trabalho em progresso (Work In Progress), identificando oportunidades de melhorias, tornando explícitas as políticas seguidas e os problemas
encontrados e, por fim, favorecendo uma cultura de melhoria evolutiva.
 PRÁTICAS DO KANBAN  Implemente mecanismos de feedback; / Gerencie e meça o Fluxo de Trabalho; / Visualize o Processo; / Limite o WIP (Work In Progress); / Torne as políticas dos processos explícitas; / Melhore
colaborativamente e com métodos científicos.
EXTREME PROGRAMMING (XP)  metodologia ágil de desenvolvimento de software para equipes pequenas e para projetos com requisitos vagos e em constante mudança.
 PRINCÍPIO  código-fonte = melhor documentação, pois qualquer outra se torna rapidamente desatualizada e perde sua confiabilidade.
 REQUISITOS  EXPRESSOS COMO CENÁRIOS (histórias do usuário)  implementados diretamente como uma série de tarefas.
 PROGRAMADORES TRABALHAM EM PARES  desenvolvem testes para cada tarefa antes da escrita do código.
 Sempre que há integração, há novos testes.
 DESENVOLVIMENTO INCREMENTAL  apoiado por pequenos e frequentes releases do sistema e por uma abordagem de descrição de requisitos baseada nos cenários do cliente. Ademais, o envolvimento do cliente
em tempo integral facilita o desenvolvimento e melhora a qualidade do produto.
 5 VALORES FUNDAMENTAIS
1. COMUNICAÇÃO  para se desenvolver um sistema, exige-se comunicar os requisitos de sistema para os desenvolvedores. Em metodologias formais de desenvolvimento de software, esta tarefa é realizada por
meio de documentação. XP favorece projetos simples, metáforas comuns, a colaboração dos usuários e programadores, a comunicação verbal frequente, e feedback.
2. SIMPLICIDADE  XP incentiva que se comece com a solução mais simples. Funcionalidades adicionais podem ser acrescentadas posteriormente. Codificação/projeto de necessidades futuras incertas
implicam risco de gastar recursos em algo não mais necessários, embora talvez atrasando aspectos cruciais.
3. FEEDBACK  ocorre quando TESTES UNITÁRIOS/TESTES DE INTEGRAÇÃO retornam o estado do sistema após a implementação das mudanças. Ademais, como os clientes participam do desenvolvimento de
testes, eles podem dar um feedback instantâneo. Quando o cliente traz um novo requisito, recebe um feedback de tempo e orçamento.
4. CORAGEM  permite que desenvolvedores se sintam confortáveis com o ato de refatorar o seu código, quando necessário. Eventualmente, há de se ter coragem para jogar fora um código ou para remover um
código obsoleto, não importa quanto esforço e tempo se gastou para produzi-lo. Além disso, coragem significa persistência, pois um programador pode se encontrar preso em um problema complexo durante um dia
inteiro sem conseguir resolver.
5. RESPEITO  RESPEITO PELOS OUTROS/AUTO-RESPEITO. Ninguém na equipe deve se sentir desvalorizado ou ignorado. Isso garante um alto nível de motivação e incentiva a lealdade dentro da equipe. Este valor
é muito dependente dos outros valores.
 PRÁTICAS XP
1. PLANEJAMENTO INCREMENTAL  requisitos são registrados em cartões de histórias e as histórias a serem incluídas em um release são determinadas pelo tempo disponível e sua prioridade relativa.
Desenvolvedores dividem essas histórias em tarefas.
2. PEQUENOS RELEASES  conjunto mínimo útil de funcionalidade que agrega valor ao negócio. Desenvolvido primeiro. Releases do sistema são frequentes e adicionam funcionalidade incrementalmente ao
primeiro release.
3. PROJETO SIMPLES  realizado um projeto suficientemente simples de modo que atenda aos requisitos atuais e nada mais.
4. DESENVOLVIMENTO TEST-FIRST  framework automatizado de teste unitário é usado par escrever testes para nova parte da funcionalidade antes que esta seja implementada. Portanto, primeiro se escreve o
teste, depois faz-se a implementação.
5. REFACTORING  Espera-se que todos os desenvolvedores recriem o código continuamente tão logo os aprimoramentos do código forem encontrados. Torna código simples de entender e fácil de manter.
6. PROGRAMAÇÃO EM PARES  desenvolvedores trabalham em pares, um verificando trabalho do outro e fornecendo apoio para bom trabalho. Utilizam mesmo mouse, teclado e monitor.
7. PROPRIEDADE COLETIVA  pares de desenvolvedores trabalham em todas as áreas do sistema, de tal maneira que NÃO SE FORMEM ILHAS DE CONHECIMENTO, com todos os desenvolvedores de posse de
todo o código. Qualquer um pode mudar qualquer coisa.
8. INTEGRAÇÃO CONTÍNUA  Tão logo tarefa seja concluída, é integrada ao sistema como um todo. Depois de qualquer integração, todos os testes unitários do sistema devem ser realizados.
9. RITMO SUSTENTÁVEL  GRANDES QUANTIDADES DE HORAS EXTRAS NÃO SÃO CONSIDERADAS ACEITÁVEIS, pois, no médio prazo, há uma redução na qualidade do código e na produtividade.
10. METÁFORAS  equipe se comunica sobre o desenvolvimento de software por meio de metáforas, caso consiga encontrar uma que realmente faça sentido dentro do contexto e possa facilitar a comunicação.
11. CLIENTE ON-SITE  representante do usuário final deve estar disponível em tempo integral para apoiar a equipe. Cliente é um membro da equipe de desenvolvimento e é responsável por trazer os requisitos
do sistema.
12. REUNIÕES EM PÉ  para não se perder o foco nos assuntos, produzindo reuniões mais rápidas, somente abordando as tarefas realizadas e tarefas a realizar pela equipe no futuro.