Este artigo apresenta alguns pontos de atenção para obter resultados efetivos a partir da visão do DevOps, abordando as principais diferenças do Scrum para o DevOps. Partimos do desenvolvimento ágil, do Scrum, sendo o método de agilidade mais usado nas atividades de desenvolvimento de software. Resumo em 10 itens dos assuntos mais relevantes que podem ser usados ​​para ajustar e ajustar o DevOps.

DevOps

O DevOps pode ser visto como uma extensão da agilidade, agilidade levada ao extremo, onde a frequência de entregas e implantações é uma ordem de baixas, centenas ou milhares por dia.

O que mudou? O que precisa ser adaptado para quem pode executar essas ações com o máximo de estabilidade e confiança sem exportar uma organização para eternos incidentes?

O DevOps é um movimento que aumenta a integração de especialistas da TI que trabalha isoladamente apesar da alta dependência. O motivo? historicamente, uma construção de equipes de trabalho formadas por super especialistas, concentrando-se em questões técnicas (equipes de redes, desenvolvimento, banco de dados, servidores, operações) também está dividida também nos objetivos da organização em um fluxo com interesses muito particulares, como muitas vezes conflitantes com as necessidades do negócio.

 

10 itens dos assuntos relevantes mais que
podem ser usados ​​para ajustar e agilizar o DevOps

 

 

 

1 – Visão de Serviço ao usar o Produto

Uma das grandes mudanças trazidas pela agilidade tem sido uma capacidade de criar produtos em forma incremental e evolutiva com foco em resultados parciais de alto valor para o cliente. Originalmente nos modelos clássicos, como equipes de desenvolvimento elaborado, construindo software com especificações de amplificadores e escopo do escopo. A agilidade não interromper esse escopo nos ambientes de incremento que permite o feedback do produto fornecido.

Equipes que desenvolvem recursos

O foco em muitas condições continua como equipes que desenvolvem recursos, sem muita atenção aos requisitos não cumprem do produto, como escalabilidade, qualidade, resiliência, débito técnico, desempenho, melhorias, segurança, etc., muitas vezes com privilégios na construção de novas qualidades desconsiderando aspectos de uso, solicitar serviços. Como as equipes mantêm-se em muitas atividades, elas separam sem afetar as consequências e desconsideram os impactos dos aspectos que fazem parte do serviço.

 

2 – Aumento da qualidade do trabalho

Aumentar a qualidade permite que uma saia do TI do círculo vicioso de implantar rapidamente sem olhar para as consequências do trabalho mal feito. Os modelos tradicionais que são pressionados como equipes por prazos, um favor de disponibilizar novas funcionalidades, consequências desastrosas na organização. O aumento de incidentes, falhas no impacto ou negócios, clientes comprometidos, reputação e impostos, além de vulnerabilidades possíveis. Modelos como Scrum, precisam integrar práticas e disciplinas de engenharia no trabalho diário.

Processo de entrega e manutenção

Precisamos de uma visão de ponta no ponto do processo de entrega e manutenção. Uma baixa qualidade de origem, invisível muitas vezes para complexidade da solução, pode ser cada vez mais difícil de detectar e solucionar.

 

3 – Backlog multifuncional

Consequência, o backlog precisa ser multifuncional. Sempre que você não tiver os requisitos de funcionalidade que a equipe de desenvolvimento deve absorver os modelos clássicos do Scrum, como também não funciona, ou que melhorar a qualidade da solução como um todo.

Histórias de usuário

Como histórias de usuário inteiro registro de histórias de teste, histórico de segurança, histórico de operação, histórico de infraestrutura. Todas elas devem ser priorizadas para entrega de valor, não somente para entrega de novas funcionalidades. essa solicitação permite consolidar uma forma consistente como soluções e suas complexidades com equipes realmente colaborativas multifuncionais.

 

4 – Equipe multifuncional

Equipa multifuncionais e de alta capacidade de decisão, permitindo evoluir uma solução, o serviço para além do produto, com foco em qualidade, nas co-relações e impactos de uma solução robusta. Como construir uma interação necessária para envolver todas as exigências necessárias para uma participação ativa dos profissionais com suas especialidades? é um desafio que o DevOps flexibiliza a necessidade de manter equipes fixas e co-localizadas.

 

5 – Estabilizar e integrar o processo de Construção e Entrega

A Entrega Contínua permite a automação dos processos rotineiros de levar uma solução do código fonte até uma operação, de maneira estável, segura, eficiente, rápida e com risco controlado. Isso permite total aderência como práticas ITIL de Mudanças, além de criar um processo que permite que equipes de diferentes especialidades colaborem de maneiras com objetivos comuns, estimulando a transparência, o aprendizado, a empatia e a colaboração.

DoD

A Definição de Pronto (DoD) muda e é estendida para uma solução em operação. Se antes, o DoD focava em concluir o trabalho de abrangência, agora focado na estabilidade da solução em pequenos “implantáveis” em produção. Isso muda completamente como disciplinas dos profissionais no processo: Desenvolvimento orientado para tronco, TDD, Infraestrutura ágil, desconstruído Versões e foco em implantações estáveis ​​(implantar), reversão automática, resiliência, etc. tudo isso sustentado no fluxo de uma peça, pequenas quantidades, com pequenos impactos, pequenos riscos com mais frequência.

 

6 – Aumento da colaboração entre as equipes de especialistas

A colaboração envolve uma cultura que permite aprender como oportunidades, aprimoramento, responsabilidade pelas falhas, integração de especialistas, equipes e soluções. Estabelecemos uma boa colaboração e entendemos como medidas métricas em resultados de ponta no ponto do processo, visibilidade visível e transparência. Como as equipes de desenvolvimento têm continuado a permanecer isoladas, criando software em etapas, mas implantado de modo cascata com grandes lançamentos, grandes tentativas em testes e homologação e implantações com muito esforço.

Lean

Existe o conceito Lean do sistema puxado, que permite que as equipes estejam sendo executadas de acordo com a demanda, com foco no resultado. Assim, uma cultura de culpa, que é estimulada nos modelos verticais de gestão, é substituída pela colaboração, coragem e aprendizado. Um dos grandes medos é cobrado por capturar que não são cumridas. Com grande parte do processo realizado em forma automatizada, elimine muitos desperdícios do processo.

 

7 – Fluxo contínuo

O fluxo contínuo em Devops incorpora várias disciplinas: Integração Contínua para a equipe de Dev; Entrega Contínua para equipes de Desenvolvimento, Infra, QA e Testes, Operações e Segurança, Implantação Contínua para Infraestrutura e Operações e Operação Contínua com uma equipe de Operações. essas disciplinas são altamente dependentes e podem remover o isolamento de atividades clássicas por especialistas. Uma vez operando nesse modelo contínuo, afeta em forma positiva a colaboração de especialistas como também, a necessidade de trabalhar dentro dos limites de uma sprint.

Fluxo contínuo

O fluxo contínuo permite que tanto o planejamento como as entregas também sejam executadas regularmente sob demanda, não sendo mais necessárias para execução (estoques) em Planning, Releases, e Revisões. Elas acontecem ou decorrem de acordo com demanda. Ou incluir um trabalho com Kanban, que realmente será o modelo mais apropriado.

 

8 – De Product Owner para Service Owner

Se for necessário que a visão do Dono do Produto seja estendida para o Dono do Serviço, ou seja, que integre as melhorias da solução, reduza o dano técnico e os requisitos não funcionais, que use o diferencial de experiência do usuário para entrega de valor . Este papel é fundamental para direcionar claramente o sucesso do Serviço, deixar o domínio claro para entender o valor do serviço de TI.

 

9 – De Scrum Master para DevOps Master

Também é necessário que o Scrum Master seja o DevOps Master, alguém que possa ajudar nos impedimentos das disciplinas do DevOps em todo o ciclo de vida do Serviço, e não mais somente no Dev. A Liderança no DevOps exige um amplo domínio de entendimento de várias estruturas de mercado, além do Scrum. Analise resistências das equipes e faça um trabalho construtivo de colaboração.

 

10 – Ritos contínuos – Planejamento, Revisão e Retro

Agora, todos os ritos passam a ser contínuos, desde o planejamento, como revisões, retrospectivas, incidentes pós-morte, os diários, etc. Não faz sentido manter sprints de tamanho fixo, já que os tempos e demandas da operação são menores e menos importante. tempo para serem resolvidos. Neste ponto, podemos até ver o Scrum pode ser transformado no método Kanban.

Confira nosso vídeo sobre como

 

Assista ao nosso vídeo e confira como Evoluir do Scrum para o DevOps! Clique aqui .