Quais metodologias de desenvolvimento de software influenciaram na criação do DevOps

A metodologia ou modelo da cascata é um processo de desenvolvimento de software com ênfase em uma progressão sequencial de um estágio do processo para o outro adaptado da engenharia de hardware. Uma das forças motrizes por trás deste modelo foi a ideia de que os bugs eram mais fáceis de corrigir o mais cedo no processo de desenvolvimento foram descobertos, e assim procurou garantir que cada fase do processo seria completamente concluída antes de qualquer trabalho foi iniciado na próxima . Os estágios originais foram especificação de requisitos, projeto, implementação, integração, teste, instalação e manutenção, e o progresso foi visualizado como fluindo de um estágio para outro.

O desenvolvimento de software no modelo de cascata tendeu a ser altamente estruturado, com uma grande quantidade de tempo gasto nas fases de requisitos e concepção, com a ideia de que, se ambos fossem concluídos corretamente para começar, reduziria o número de Erros que seriam encontrados mais tarde. Parte do apelo disso decorria dos altos custos de entrega e troca de software que foi distribuído em CD-ROMs ou disquetes para serem instalados manualmente. Como a fixação de um bug em tal software exigiria, por exemplo, a fabricação e distribuição de outro CD-ROM com um patch de software, era muito mais econômico gastar o tempo necessário para obter o design e as especificações na frente.

O método cascata faz sentido nestes casos em que o custo de entrega de software é alto ou para projetos com necessidades improváveis ​​de mudar. Como com toda a metodologia, o método da cascata tem seus prós e contras.

Projetos que exigem mais flexibilidade podem se beneficiar do exame de algumas metodologias mais iterativas ou ágeis também. Uma parte chave do DevOps é ser capaz de avaliar diferentes ferramentas e processos para encontrar o mais eficaz para o seu ambiente, mas não é tão rigidamente definido como proibir qualquer metodologia, mesmo as mais velhas como a Cascata.

Começou com a escrita do Manifesto Agile em 2001, ágil é o nome dado a um grupo de metodologias de desenvolvimento de software que são projetados para ser mais leve e flexível do que métodos anteriores, como cascata. Os desenvolvedores que criaram o Manifesto escreveram:

“Estamos descobrindo melhores maneiras de desenvolver software fazendo isso e ajudando os outros a fazê-lo. Através deste trabalho, passamos a valorizar:

Em meados dos anos 90, Ken Schwaber e Dr. Jeff Sutherland, dois dos criadores originais do Manifesto Ágil, uniram esforços individuais para apresentar um novo processo de desenvolvimento de software chamado Scrum. Scrum é uma metodologia de desenvolvimento de software que se concentra em maximizar a capacidade de uma equipe de desenvolvimento para responder rapidamente às mudanças nos requisitos do projeto e do cliente. Ele usa ciclos de desenvolvimento predefinidos chamados sprints, geralmente entre uma semana e um mês de duração, começando com uma reunião de planejamento de sprint para definir metas e terminando com uma revisão de sprint e retrospectiva de sprint para discutir o progresso e quaisquer questões que surgiram durante o sprint.

Uma das principais características do Scrum é o ”Scrum diário” ou “standup diário”, uma reunião diária onde os membros da equipe (bastante rapidamente) respondem cada três perguntas:

Essas reuniões, que ocorrem de manhã para ajudar as pessoas a se alinhar com o que estão planejando fazer naquele dia e ajudar-se mutuamente com quaisquer problemas de bloqueio, são frequentemente facilitadas pelo Scrum Master. O Scrum Master é um papel importante que também inclui responsabilidades como ajudar a equipe a se auto-organizar e coordenar esforços de trabalho, ajudando a remover bloqueadores para que a equipe continue fazendo progresso e envolvendo proprietários de projetos e partes interessadas para que haja uma compreensão compartilhada do que ” Feito “significa e que progresso está sendo feito. Os princípios do Scrum são frequentemente vistos aplicados de forma menos formal em muitas práticas de desenvolvimento de software hoje.

ITIL, anteriormente conhecida como Biblioteca de Infraestrutura de Tecnologia da Informação, é um conjunto de práticas definidas para o gerenciamento de serviços de TI. É publicado como uma série de cinco volumes que descrevem seus processos, procedimentos, tarefas e listas de verificação, e é usado para demonstrar a conformidade, bem como medir a melhoria nesse sentido. ITIL cresceu fora de uma tendência que viu o número crescente de organizações de TI na década de 1980 usando um conjunto cada vez mais diversificado de práticas. A British Central Computer and Telecommunications Agency desenvolveu um conjunto de recomendações como uma maneira de tentar padronizar essas práticas. Publicado pela primeira vez em 1989, os livros e práticas têm crescido ao longo dos anos, com as cinco seções principais na versão mais recente (2011), sendo estratégia de serviço, design de serviço, transição de serviço, operação de serviço e melhoria contínua de serviço.

É necessário pensar em como reduzir a carga de trabalho de gerenciamento. É necessário realinhar ITSM para DevOps, criando ITSM leve que é estritamente focado na continuidade do negócio com um conjunto de informações mínimas exigidas (IME). O IME definido para cada organização depende de seus negócios.

No campo da gestão de serviços de TI, a ITIL® * é estabelecida e operada como a forma de gerenciar infra-estrutura de sistemas de TI visando segurança e continuidade.

Mas a partir de hoje, o ambiente do ITIL está mudando pela incorporação de Agile e DevOps que exigem curtos ciclos de desenvolvimento e lançamentos frequentes por demanda do usuário de negócios. É difícil manter o gerenciamento original do ITIL, que é rígido e baseado em procedimentos, para atender a essa demanda. Precisamos de mais leve e rápido gerenciamento de serviços de TI para fins Agile e DevOps. Esta é uma questão chave.

O desafio é como remover a inconveniência, a fim de manter a velocidade e a frequência de Agile.

Chegamos à conclusão de que a gestão de serviços de TI deve focar-se estritamente na continuidade do negócio. Reorganizamos o gerenciamento de serviços de TI para o desenvolvimento Ágil e as operações Lean, o que significa coletar apenas informações essenciais para gerenciar elementos de continuidade de negócios do gerenciamento de serviços de TI.  E definimos esses dados, que são Padrões de Atividade Empresarial (PBA), Requisitos de Nível de Serviço (SLR), Acordos de Nível de Serviço (SLA), Pacote de Nível de Serviço (SLP) do Service Design Package (SDP), SAC (Critérios de Aceitação de Serviço) e Acordos de Nível Operacional (OLA), gerados quando e em que processo ou atividades.

A ideia é coletar dados quando eles são gerados em atividades no site e gravá-los. Quando os dados são necessários de um ponto de vista de gerenciamento de serviços de TI, um relatório de resumo deve ser gerado e a informação pode ser usada. Chamamos isso de gerenciamento de serviços de TI de peso leve. Não é um documento, é apenas informação.

Objetivos de Controle para Informação e Tecnologia Relacionada (COBIT) é um framework ISACA para governança e gerenciamento de informações e tecnologia lançado pela primeira vez em 1996. Um princípio central do COBIT é alinhar objetivos de negócios com objetivos de TI.

COBIT é baseado em 5 princípios:

Os objetivos da produção lean são garantir a entrega rápida de produtos de alta qualidade e focar a redução de desperdícios e de custos.  O uso dessas técnicas e ideias resulta em grande economia de recursos e redução dos custos, produtos de maior qualidade e menor tempo de entrada no mercado em varias indústrias.

A aplicação das técnicas lean não se limita a sistemas pequenos. Foram criadas e aplicadas a grandes organizações e até mesmo a economias inteiras. Tanto a teoria quanto a pratica são tão relevantes para equipes grandes como para equipes pequenas, e nossa experiência é de que funcionam. Entretanto, não pedimos que você simplesmente acredite no que dizemos.

Depois de um estudo de cinco anos sobre o futuro da produção automotiva e do Sistema de Produção Toyota (TPS), James P. Womack, Daniel T. Jones e Daniel Roos cunharam o termo Lean Production. Womack e Jones definiram os cinco princípios de Lean:

Essas ideias, especialmente a busca da perfeição através da identificação sistêmica e eliminação de resíduos, levou a definição de Lean como a maximização do valor do cliente e minimização de resíduos.

Os sistemas Lean concentram-se nas partes do sistema que agregam valor eliminando desperdícios em qualquer outro lugar, quer se trate de superprodução de algumas peças, produtos defeituosos que têm de ser reconstruídos ou tempo de espera em alguma outra parte do sistema. Sendo assim, estão os conceitos de Lean IT e desenvolvimento de software Lean, que aplicam esses mesmos conceitos à engenharia de software e operações de TI.

Os resíduos a eliminar nestas áreas podem incluir: