1. Questões de prova
1.1. Agile disciplinado é um requisito essencial para uma implementação bem-sucedida do DevOps. (Literatura:Sucesso no Enterprise DevOps - seção 4i - Agile disciplinado.)
1.2. A colaboração entre todas as equipes envolvidas (Desenvolvimento e Operações, incluídas) é de grande importância.importância fundamental para obter maior valor comercial, através de maior comunicação, automaçãoe software de qualidade superior. (Literatura: DevOps eficaz, capítulo 6
1.3. Uma equipe de verdade garante um ritmo de trabalho constante e continuará trabalhando em direção a seus interesses comunsobjetivo. (Literatura: DevOps eficaz, capítulo 9)
1.4. Uma equipe de verdade garante um ritmo de trabalho constante e continuará trabalhando em direção a seus interesses comunsobjetivo. (Literatura: DevOps eficaz, capítulo 9) Isso se concentra em apenas fornecer serviços de TI rápidos e frequentes e operação confiável, a maioriaadequado para SoE e SoR. (Referência da literatura: C - Seção 8 - Implementação do DevOps)
1.5. Geralmente, os termos descritos no SLA são mais relevantes para Operações. Desenvolvimentodeve apoiar as Operações, facilitando o trabalho deles. É isso que torna o DevOpsdiferente do desenvolvimento regular. (Literatura: Entrega contínua, capítulo 12)
1.6. Qual é um bom motivo para implementar o DevOps em uma organização? Agregar valor e otimizar processos são as chaves para melhorar a continuidade dos negócios eagilidade da empresa. Você deve pensar no que significa que os serviços de TI devem sempre oferecer suporte aonegócios, qual é o valor e a finalidade do DevOps. (Literatura: Sucesso com Enterprise DevOps)
1.7. Qualquer equipe que adota o DevOps pode ser descrita como um compacto.Qual princípio se aplica melhor para fazer um Compact funcionar Os princípios de um compacto DevOps são comunicação contínua, compartilhada e claramente definidaobjetivos e ajuste dinâmico e reparos de entendimento. (Literatura: DevOps eficaz - Capítulo 2- Exemplo de um compacto)
1.8. Por que o fluxo de peça única é importante para a adoção do DevOps? É isso que o fluxo de uma peça alcança. O fluxo de uma peça permite escolher o recurso ou atualizar orecurso que fornece o maior valor e o coloca no próximo pipeline. Isso mantém você ágil. Pelo trabalhoem um único recurso, você tende a limitar o trabalho em andamento para que os recursos tambémacabado. (Literatura: Sucesso empresarial com DevOps)
1.9. Equipes com boas práticas de colaboração sincronizaram tíquetes de trabalho. Um CTO usado'Vá e veja', para investigar como a equipe de Operações funciona. Após a liberação, oA equipe de operações sempre redefine a infraestrutura operacional.Qual é o melhor conselho para aprimorar essa prática? Este é o caminho a seguir: compartilhando conhecimento e depois dando mais passos. (Literatura: EficazDevOps)
2. Operação e Dimensionamento
2.1. Operação
2.1.1. Banco de dados
2.1.1.1. Recomendação para Migração
2.1.1.1.1. Versione o banco de dados Use Schemas para manter a compatibilidade com versões anteriores e posteriores
2.1.1.1.2. Não utilize Dumps de produção, crie conjunto de dados personalizados, usando um conjunto de dados menor
2.1.1.1.3. Livro: Na maioria dos casos, não use dumps dos dados de produção para fins de testes. Crie conjuntos de dados customizados selecionando cuidadosamente um subconjunto dos dados de produção, ou a partir da execução de testes de aceitação ou capacidade
2.1.1.2. Aplicações que usam vários BDs
2.1.1.2.1. 1 - Testar as mudanças em um ambiente com BD de testes que se assemelhe à produção (Staging) 2 - Manter um registro de quais aplicações usam quais objetos do BD 3 - Trabalhar com os times das outras aplicações, para combinar quais mudanças podem ser feitas e quais aplicações são impactadas. 4 – Fazer com que as aplicações funcionem com diversas versões do BD, para permitir a migrações das aplicações dependentes.
2.1.1.3. Script
2.1.1.3.1. Versionar o banco de dados
2.1.1.3.2. Rollback sem perda de dados
2.1.1.3.3. Processo básico de implantação / inicialização para o BD:
2.1.2. Infraestrutura em nuvem
2.1.2.1. Razões para utilizar nuvem
2.1.2.1.1. 1 - Diminui esforços com aquisição, instalação e manutenção de equipamentos. 2 - Flexibilidade para expandir e contratar novos recursos 3 - Rápida adoção 4 - Possibilidade de possuir soluções padronizadas 5 - Adapta-se aos princípios devops 6 - Padronização da Stack 7 - Possibilidade de ter uma biblioteca de templates de máquinas virtuais
2.1.2.2. Razões para não utilizar nuvem
2.1.2.2.1. 1 - Achar que basta usar nuvem para adotar Devops 2 - Se a empresa já fez muitos investimentos em infraestrutura local 3 - Preocupações com segurança e noveis de serviço de terceiros 4 - Preocupações com fornecedores e plataforma lock-in (alto custo na troca de fornecedor ou plataforma) 5 - Questões de relacionadas a desempenho, onde servidores locais possuem melhor desempenho que servidores virtuais.
2.1.3. Gestão Holística da infraestrutura
2.1.3.1. Versione a infraestrutura
2.1.3.1.1. 1 - Mantenha a configuração da infraestrutura no controle de versão 2 - Conhecer o estado atual da infraestrutura por meio de instrumentação e monitoramento 3 - A infraestrutura deve ser autônoma.
2.1.3.2. Recomendações para gestão da infraestrutura
2.1.3.2.1. 1 - Instrumentalizar os aplicativos e ambientes para coleta de dados 2 - Armazenar os dados para que possam ser facilmente recuperados para análise 3 - Criar dashboards e mostrar as informações que tenha valor para operações e negócio 4 - Definir notificações e eventos adequados para reação em tempo hábil.
2.1.3.3. Resolvendo problemas mais rápidos
2.1.3.3.1. 1 - Controle de versão para todas as configurações de infraestrutura e monitorar rede. 2 - Habilitar logs nas aplicações (info, alertas e debug). 3 - Manter o ambiente de testes similar ao de produção * 4 - Usar ferramentas para analisar ocorrências
2.1.3.3.2. Armazene as bibliotecas no controle de versão
2.1.3.4. Componente (Microsserviços)
2.1.3.4.1. Benefícios
2.1.3.4.2. Diferenças entre Biblioteca e Componente
2.1.3.4.3. Tipo de dependências
2.1.3.4.4. Não crie equipes por componentes
2.1.4. Ger. De configuração e controle de versão
2.1.4.1. G. Configuração
2.1.4.1.1. 1 - Deve permitir fazer mudanças incrementais e implantá-las em quiser ambientes. 2 - Satisfaz todos os requisitos de conformidade e regulamentações que sua empresa está sujeita.
2.1.4.2. G. de ambientes
2.1.4.2.1. Devemos buscar a criação automatizada de ambientes (Ex: Pupet) Criação do ambiente deve ser mais rápida do que corrigir um erro existente.
2.1.4.3. Recomendações importantes:
2.1.4.3.1. 1 - Mantenha os binários independentes da informação de configuração 2 - Mantenha toda a informação de configuração em um só lugar
2.1.4.4. Mensagem de check-in agiliza solução de problemas
2.1.4.4.1. Uma boa mensagem de commit: Uma mensagem em vários parágrafos em que o primeiro parágrafo é um resumo e os demais acrescentam mais detalhes.
2.1.5. Práticas para continuidade de negócio
2.1.5.1. 1 – Infra autônoma 2 – Capacidade de saber o estado atual da infraestrutura por instrumentação e monitoramento 3 – Tudo o que é necessário para recriar o ambiente deve estar no controle de versão. 4 – Total alinhamento entre a equipe de desenvolvimento e a equipe de operações.
2.1.6. Mantenha os binarios independentes da informação de configuração
2.1.6.1. Mantenha toda a informação de configuração em um só lugar
2.2. Dimensionamento
2.2.1. Crescer e reduzir conforme necessário
2.2.2. Estrutura organizacional
2.2.2.1. Times pequenos
2.2.2.1.1. Podem ser altamente produtivos quando trabalham em um mesmo produto
2.2.2.2. Times funcionais
2.2.2.2.1. Divide as pessoas por especialidade. Benefícios. Como redução de custos e compartilhamento de recursos e conhecimento
2.2.2.2.2. Times funcionais podem trabalhar bem se não houver problema de comunicação. A dica é não reestruturar os times apenas por mudar, mas sim para resolver um problema especifico.
2.3. Bimodal
2.3.1. SOR
2.3.1.1. Foco em estabilidade, segurança e continuidade
2.3.2. SOE
2.3.2.1. Foco em volocidade, experimentação e inovação
2.3.3. Modelo Toyota
2.3.3.1. Recomendado para provedores de serviços de TI
2.3.4. Colaboração
2.3.4.1. Recomendado tanto para SOR como SOE
2.3.5. Entrega Continua
2.3.5.1. Recomendado para empresas digitais. Lançamentos rápidos e frequente de software
3. Adoção
3.1. Cultura organizacional
3.1.1. Os pilares para Devops
3.1.1.1. Colaboração
3.1.1.1.1. Pessoas diferentes com propósito comum para alcançar resultado específico
3.1.1.2. Afinidade
3.1.1.2.1. Interesse natural pelo sentimento de empatia e aprendizagem contínua.
3.1.1.3. Ferramentas
3.1.1.3.1. Aceleram as iniciativas quando bem aplicadas
3.1.1.4. Escala / Dimensionamento
3.1.1.4.1. Uso em diferentes organizações à medida que crescem, amadurecem ou ficam enxutas.
3.1.2. Aplicando os 4 pilares
3.1.2.1. Combine os 4 pilares para avançar com aspectos culturais e técnicos Resultados efetivos com Devops tem ligação com a mudança de cultura
3.1.3. Construção de time
3.1.3.1. Time
3.1.3.1.1. Um time é um grupo de pessoas trabalhando em direção a um objetivo comum interdependente entre si. Um sinal claro de que você tem um time e não um grupo é quando o time mantem um ritimo de trabalho constante em prol de um objetivo comum e comunicação eficaz.
3.1.3.1.2. Tamanho das equipes
3.1.3.1.3. Criar e desmanchar equipes de forma constante
3.1.4. Estilos de negociação e solução de conflitos
3.1.4.1. Competição
3.1.4.1.1. Foco em atingir metas pessoais às custas dos outros.
3.1.4.2. Fuga
3.1.4.2.1. Ambas as partes tentam evitar o conflito direto, mas tem comportamentos passivos-agressivos, conflitos indiretos e tensão. EX: Troca de e-mails com acusações veladas, críticas entre áreas
3.1.4.3. Meio-termo
3.1.4.3.1. Os envolvidos buscam uma solução aceitável e cedem um pouco das suas próprias necessidades para alcançar um resultado o mais justo possível (ganha- ganha)
3.1.4.4. Colaboração
3.1.4.4.1. Prioriza a criação do entendimento mutuo, aprendizado e garantia de que todos os lados realmente atendam às suas necessidades.
3.1.5. Como encarar problemas
3.1.5.1. Equipe sobrecarregada ou estressada: Folga, delegue atividades, peça ajuda profissional. A solução de longo prazo é identificar as caudas e criar ações sustentáveis.
3.1.5.2. Falta de confiança: Liderança pelo exemplo é um passo importante. Liderança deve ser justa e inspiradora
3.1.5.3. Interrupção na comunicação: O respeito com quem está falando cria confiança e empatia
3.2. Cultura Devops
3.2.1. Fatores da cultura devops
3.2.1.1. Comunicação eficaz
3.2.1.2. Empatia e confiança
3.2.1.2.1. Empatia
3.2.1.2.2. Confiança
3.2.1.2.3. Pessoal e recursos humanos
3.2.1.2.4. Mindset
3.2.1.3. Funções para devops
3.2.1.3.1. Devops Enginner: Melhora e suporta o processo automatizado
3.2.1.3.2. Coordenador de release Monitora o status operacional e o progresso da próxima versão do serviço de TI
3.2.1.3.3. Equipe de infraestrutura Equipe de redes, banco, etc..
3.2.1.3.4. Service Master Fornece serviços de TI Just in Time (JIT). Esse papel é como o “Product Owner” no Scrum
3.2.1.3.5. Process Master Lidera a equipe e atua como um facilitador. Esse papel é o mesmo que “Scrum master” no Scrum. Implementa o controle visual em todo o processo e foco em estabelecer um processo alinhado pro fluxo com fluxo de peça única
3.3. Antipadrões comuns de entrega de versão
3.3.1. Implantar software manualmente
3.3.2. Implantar em um ambiente similar ao de produção somente quando o desenvolvimento estiver completo
3.3.3. Gerência de configuração manual dos ambientes de produção
3.4. Corpo de conhecimento
3.4.1. Agile disciplinado
3.4.1.1. Uma equipe de desenvolvimento ágil disciplinada é a chave para o sucesso de uma implementação de DevOps.Agile disciplinado significa:1. Velocidade estabilizada2. Adaptabilidade à mudança3. Sempre libere código de alta qualidade sem erros
3.4.2. Entrega continua
3.4.2.1. Entrega contínua é a implementação automatizada da criação, implantação, teste de aplicativose liberar processos.Um foco principal é o teste, como testes de aceitação e testes de desempenho. * TPIO NEXT® 45 pode ser útil para melhorar a maturidade deste processo.Toda organização terá diferenças na implementação de seu pipeline de implantaçãodependendo do fluxo de valor para a liberação do software.Um fator chave de sucesso é estabelecer apenas um único pipeline de implantação para serviços de TI.
3.4.2.2. Um fator chave de sucesso é estabelecer apenas um único pipeline de implantação para serviços de TI.
3.4.3. G. de serviços de TI
3.4.3.1. É necessário realinhar o ITSM para DevOps, criando ITSM leve, estritamentefocado na continuidade dos negócios com um conjunto de informações mínimas necessárias (MRI). A ressonância magnéticadefinido para cada organização depende de seus negócios
3.4.4. LEAN TPS
3.4.4.1. Os conceitos de TPS, que incluem JIT e automação, podem ajudar.JIT significa construir uma cadeia de suprimentos alinhada ao fluxo com fluxo de uma peça. E automaçãosignifica automatizar o máximo possível e interromper todo o processo quando um defeitoocorre
3.4.5. 1. Agile Disciplinado 2. Entrega Contínua 3. Gerenciamento de serviços de TI 4. Lean
3.5. Conceitos
3.5.1. JIT
3.5.1.1. Eliminar estoque
3.5.2. One pice flow
3.5.2.1. Fluxo de uma peça
3.5.3. JKK
3.5.3.1. Faça bem feito na primeira vez
3.5.4. Obeya
3.5.4.1. Juntar as pessoas para aumentar a colaboração
4. Planejamento requisitos e desenho
4.1. Gestão de serviços com devops
4.1.1. Objetivo final da cultura devops é a entrega de valor em produção.
4.1.2. Foco é o resultado do negócio, não o escopo de um projeto de TI e pelos resultados de TI
4.1.3. É necessário estabelecer processos Just-in-time (JIT) para maximizar os resultados de negócio.
4.1.4. Devops precisa de uma arquitetura que permita um sistema automatizado de implantação rápida.
4.2. Termo de abertura e controle visual
4.2.1. Documento que autoriza a aplicação dos recursos
4.2.2. Não pode ser iniciado sem essa aprovação
4.3. Desenho da infraestrutura e arquitetura
4.3.1. Ambiente de teste deve ser semelhante ao de produção 1. A configuração de hardware dos servidores que formam o ambiente e toda a infra que os conecta. 2. A configuração do SO, serviços e BD necessários para suportar as aplicações.
4.3.2. Recomendações para infra e arquitetura
4.3.2.1. 1. As equipes de desenvolvimento e infraestrutura devem colaborar em todos os aspectos do gerenciamento e implantação do ambiente desde o início do projeto. 2. Usar técnicas ágeis para gerenciar infraestrutura, como provisionamento automatizado e manutenção autônoma. 3. Teste em ambientes semelhantes ao de produção para detectar problemas com antecedência 4. Planeje a continuidade do serviço 5. Gerenciamento de mudança de infra 6. Combine provisionamento automatizado e manutenção autônoma para garantir que a infra possa ser reconstruída em um período rápido e previsível em caso de falha.
4.3.3. Virtualização e Cloud colaboram para infra Ágil
4.3.3.1. 1. Provisionamento rápido de ambientes 2. Reduz o tempo para implantar software 3. Mais fácil oferecer infra como serviço 4. Padronização de hardware
4.3.4. Nuvem
4.3.4.1. 1. Acesso rápido, facilmente escalável 2. Implantar em uma stack completamente padronizada
4.4. Requisitos e acordos de nível de serviço (ANS)
4.4.1. Histórias de usuário
4.4.1.1. Funcionalidades, regras de negócio, valor para o negócio, valor comercial e condições de operação.
4.4.2. História de teste
4.4.2.1. Caso de teste de aceitação e critérios de aceitação de serviços.
4.4.3. História de operação
4.4.3.1. Prioridades de serviços de TI e condições de operação. Definimos contratos de nível de serviço e nível operacional.
4.5. Implementando uma estratégia de testes
4.5.1. Testar é uma ação multifuncional de todo o time e deve ser executada desde o inicio do projeto. Pensar em uma visão ampla de testes, escrevendo testes em múltiplos níveis (unitários, componentes e de aceitação).
4.5.2. Devemos priorizar testes automatizados, mas testes manuais também são essenciais para adicionar qualidade: Demonstrações, testes de usabilidade e testes exploratórios devem ser realizados continuamente ao logo do projeto.
4.5.3. Critérios de aceitação INVEST
4.5.3.1. Independente
4.5.3.1.1. De outras histórias para facilitar a negociação, a priorização e a implantação.
4.5.3.2. Negociável
4.5.3.2.1. Com o cliente, para um time manter um ritmo sustentável
4.5.3.3. Valorosa
4.5.3.3.1. Cada entrega deve agregar grande valor ao negócio do cliente
4.5.3.4. Estimável
4.5.3.4.1. O time consegue estabelecer quais história serão implementadas de acordo com sua velocidade.
4.5.3.5. Small (pequena)
4.5.3.5.1. Pode ser implementada dentro de uma interação
4.5.3.6. Testável
4.5.3.6.1. Permite a qualidade da entrega na visão do cliente
4.5.4. Estratégia para implementar testes automatizados
4.5.4.1. No inicio do projeto
4.5.4.1.1. Automatize todos os caminhos (Feliz e infeliz).
4.5.4.2. No meio do projeto
4.5.4.2.1. Automatize todos os caminhos na parte que falta desenvolver. Onde ja foi desenvolvido, escreva testes somente nas partes inportantes
4.5.4.3. Sistema legado
4.5.4.3.1. Refatore o Código para melhora-lo conforme a necessidade.
5. Desenvolvimento e implantação
5.1. Integração e entrega continua
5.1.1. Objetivo é manter o software em um estado funcional durante todo o tempo de desenvolvimento Equipes que trabalham com integração continua são capazes de entregar software muito mais rápido e com menos defeitos.
5.1.2. Requisitos básicos para IC funcionar
5.1.2.1. 1. Controle de versão 2. Processo automatizado de compilação 3. Aceitação da equipe
5.1.2.2. Livro: Se as pessoas não adotarem a disciplina necessária para que isso funcione, qualquer tentativa de integração contínua não levará às melhorias de qualidade esperadas
5.1.3. Passos que devem ser executados
5.1.3.1. 1. Verifique se o processo de compilação está rodando. Se está, espere ele terminar. 2. Quando o processo terminar, e os testes forem bem-sucedidos, atualize o código em sua versão de desenvolvimento de controle de versão. 3. Execute os scripts de compilação e de testes na máquina de desenvolvimento. 4. Se a compilação local funcionar, faça o check-in. 5. Espere que a ferramenta de IC execute com suas mudanças. 6. Se o processo falhar, pare o que estiver fazendo e conserte o problema imediatamente em sua máquina local, voltando ao passo 3. 7. Se o processo for bem-sucedido, pule de alegria e passe para a próxima ferramenta.
5.2. Pipeline de implantação
5.2.1. 1. É o processo de automação do fluxo de valor que leva o software do controle de versão ao ambiente de produção (cliente) 2. Seu objetivo principal é fornecer feedback rápido a todos no fluxo de valor sobre o status das mudanças. 3. Colabora com a correção imediata quando ocorre um erro em produção.
5.2.2. Visão ponta a ponta
5.2.2.1. • Equipe de entrega • Controle de versão • Compilação e testes unitários • Testes de aceitação automatizados • Testes de aceitação do usuário • Entrega ou release
5.2.3. Resumo dos estágios do pipeline
5.2.3.1. Estágio de Commit (IC)
5.2.3.1.1. • Garante que o sistema funciona em nível técnico • Compila, testes automatizados, analise de código • Se tudo ok, gera artefatos no controle de versão • Estagio de commit funciona como um segurança, impedindo que mudanças não aprovadas nos testes unitários avance a etapa no pipeline
5.2.3.2. Testes de aceitação (EC)
5.2.3.2.1. • Garante o sistema Ok (Funcional e não funcional). Comportamento atende às necessidades do cliente. • Configuração do ambiente, instalação de binários, Smock testes, testes de aceitação.
5.2.3.2.2. Dado / Quando / Entao
5.2.3.3. Testes paralelos (manual)
5.2.3.3.1. • Detecta defeitos não encontrados anteriormente • Recomendado fazer testes em paralelo
5.2.3.4. Implantação continua
5.2.3.4.1. Vai de forma automática para produção
5.2.4. Benefícios do pipeline de implementação
5.2.4.1. • Testes contínuos e feedback rápido
5.2.4.2. • Implantações em produção tornam-se parte rotineira do trabalho diário
5.2.4.3. • Autonomia para equipe desenvolver, testar e implementar com segurança.
5.2.5. Pepiline é projetado para:
5.2.5.1. Alcançar desempenho garantido
5.2.5.2. Obter conformidade
5.2.5.3. Implantação automatica
5.2.5.4. Alditoria
5.2.5.5. Gerenciar risco
5.2.6. Requisitos para o pipeline de implementação
5.2.6.1. Implementar da mesma forma em todos os ambientes Etapas anteriores do desenv, testes e homologa trarão aprendizado para produção.
5.2.6.2. Fazer testes de fumaça nas implementações Confirmar se funciona conexão com sistemas de apoio, banco de dados, serviços externos
5.2.6.3. Garantir a manutenção de ambientes consistentes Manter sincronismo dos ambientes
5.3. Implantação continua
5.3.1. Nível de maturidade máximo no Devops. Evolução da entrega continua
5.3.2. Na implantação contínua todas as alterações que passam nos testes automatizados são implementadas automaticamente em produção
5.3.3. A implantação continua depende de arquitetura que minimize os problemas em produção.
5.3.4. Release Azul – Verde
5.3.4.1. • Existe um ambiente 100% ativo e outro fica em Stand-by. • É o tipo mais simples de release de baixo risco, mas um problema que surge é como gerenciar o BD com duas versões do aplicativo em produção
5.3.5. Release Canário
5.3.5.1. • A implantação ocorre em um ambiente com poucos usuários (Ex: 10%) e aumenta gradativamente. • Minimiza os erros em produção e tem um impacto menor.
5.4. Ferramentas e DevOps
5.4.1. As ferramentas são aceleradoras e aumentam a velocidade ao impulsionar a mudança com base na cultura e na direção de cada organização.
5.4.2. A má implementação ou excesso de customização pode destruir uma ótima ferramentas.
5.4.3. A forma e a facilidade como as ferramentas são usadas impactam na aceitação de aspectos específicos da cultura
5.5. Matriz de maturidade
5.5.1. Níveis
5.5.1.1. Nível -1 – Regressivo Processos que não podem ser repetidos, pouco controlados e reativos.
5.5.1.1.1. Não é repetivel
5.5.1.2. Nível 0 – Repetível Processo documentado e parcialmente automatizado
5.5.1.2.1. Parcialmente automatizado
5.5.1.3. Nível 1 – Consistente Processos automatizados aplicados ao longo de todo o ciclo de vida da aplicação
5.5.1.3.1. Automatizado
5.5.1.4. Nível 2 – Gerido quantitativamente Processos medidos e controlados
5.5.1.4.1. Automatizado e com métricas
5.5.1.5. Nível 3 – Otimização Foco em melhoria de processo
5.5.1.5.1. Automatizado, metricas e melhoria.
5.5.2. Disciplinas
5.5.2.1. Gestão de compilação e integração contínua
5.5.2.1.1. Integração Continua
5.5.2.2. Ambientes e implantação
5.5.2.2.1. Implantação Continua
5.5.2.3. Gestão de entrega de versão e observância
5.5.2.3.1. Entrega COntinua
5.5.2.4. Testes
5.5.2.4.1. Testes automatizados
5.5.2.5. Gestão de dados
5.5.2.5.1. Gerenciamento de dados
5.5.2.6. Gerência de configuração
5.5.2.6.1. Gerenciamento da configuração
5.5.3. Decorar os 5 niveis e as 6 disciplinas
5.6. Praticas Lean
6. Fim de vida
6.1. Condições de fim de vida de um produto ou serviço
6.1.1. Fim da Vida, é tratado como uma história como outras condições A história vai dizer porquê, por exemplo. Não mais necessidade de negócio, substituição por um serviço mais barato / mais simples / mais eficaz
6.1.2. A história vai dizer quais são as condições, p.ex.:
6.1.2.1. 1. O que acontece com quaisquer dados / documentação / ferramentas / outros componentes 2. Como assegurar que qualquer serviço de substituição esteja pronto antes de fechar 3. Quando fechar e em que sequência
6.2. Quem pode desativar um serviço?
6.2.1. Service Master Fornece serviços de TI Just in Time (JIT). Esse papel é como o “Product Owner” no Scrum