Ágil em larga escala – System Demo meeting

Após a introdução do framework SAFe (Scaled Agile) e de duas importantes reuniões – Scrum of Scrums e PO Sync, chegou a hora de falar sobre a System Demo, outro evento  imprescindível em projetos ágeis de larga escala, que provêm visibilidade das features entregues pelos times no ART (Agile Release Train).

System Demo é uma demonstração do trabalho realizado por todos os times durante a última iteração (Sprint). Um ótimo meio de coletar feedbacks e validar as dependências. Portanto, mantenha ativo o processo de CI (Continuous Integration) no seu time para facilitar as publicações e apresentações do sistema.

continuous-deployment-azure-devops
(exemplo do processo de Continuous Deployment no Azure Devops)

A integração dos sistemas, componentes, etc. no cada final de Sprint pode exigir capacidade e custo de transação inaceitável. Por isso, se você trabalha em estágios iniciais de CI, evolua gradativamente o CI e automação de testes para diminuir o custo de futuras integrações.

Figura: otimização de custo de “curva em U” para os esforços de integração

Algumas características sugeridas para a System Demo:

Frequência: a cada duas semanas, após a conclusão da Sprint.
Duração: o timebox sugerido para este evento é de uma hora. O tempo curto e direto ao ponto mantém o envolvimento de pessoas chaves na reunião.
Participantes: PM (Product Managers) e PO (Product Owners); um ou mais membros do time de sistemas; BO (Business Owners), Arquiteto, Infra e stakeholders necessários
Facilitador da reunião: PM (Product Managers) e PO (Product Owners)

E um roteiro sugerido para a System Demo:

1. Visão de produto: Epic > Feature > User Story. É importante cada time trazer um rápido overview do produto a todos presentes na reunião.

user-story

2. A representação das histórias e a carga realizada na Sprint. Também recomendo demonstrar se o critério de aceitação foi obtido.

sprint-story

3. E por fim, dedicar o maior tempo na demonstração do sistema em funcionamento no ambiente de homologação. Percorrer as featuresuser stories entregues na última Sprint e compartilhar se a DoD (definition of done) foi cumprida.

blog-leonardo.png

A última System Demo de cada PI (Program Increment) exige uma estruturação maior, percorrendo todas as features desenvolvidas naquela PI. Em geral, este evento acontece na I&A (Inspect and Adapt) e orienta o progresso daquela PI. Outras recomendações para uma boa System Demo:

  • Demonstrar somente aplicações testadas (evitar apresentação de slides)
  • Dividir a responsabilidade entre os líderes de desenvolvimento e os POs durante a demonstração.

 

 

 

Métricas DevOps – estamos no caminho certo?

Já iniciamos a Jornada DevOps e os seus benefícios para as organizações. E como avaliar então o progresso destas iniciativas e a das práticas DevOps em seu processo? As M-É-T-R-I-C-A-S são fundamentais para um direcionamento adequado dos três pilares do DevOps: pessoas, processos e ferramentas.

O livro Continuous Delivery – Jez Humble e David Farley – exalta a importância da visibilidade dos resultados: “Feedback is at the heart of any software delivery process. The best way to improve feedback is to make the feedback cycles short and the results visible. Measure what really matters… Once you know the cycle time for your application, you can work out how best to reduce it. You can use the Theory of Constraints to do this“.

by the book vale começar monitorando o Throughput (capacidade de vazão do time) com indicadores de frequência do deployment e lead time e a Stability (estabilidade destas implementações), verificando MTTR e taxa de falha em mudanças.

analise-desempenho-devops

Entre os principais benefícios das empresas High IT Performers estão: a evolução do time to market, melhor experiência do usuário, agilidade na resolução de problemas, etc.

beneficios-continuous-deployment
As métricas DevOps refletem este processo de continuous delivery, com foco em velocidade, qualidade e performance das aplicações. Ter um pipeline de publicações rápido e com poucas quebras em produção é o resultado esperado pelas empresas e um bom sinal de competitividade! Fica a recomendação de algumas métricas:

  • Velocidade: frequência de deploymentlead time, cycle time, builds e performance (por recurso, release, etc.).
  • Eficiência operacional: tempo de deployment, MTTD (Mean time to detection), MTTR (Mean time to recovery), disponibilidade e custo por release.
  • Qualidade: taxa de falha em mudanças, taxa de sucesso de deploy, cobertura dos testes automatizados, bugs e incidentes.
  • Efetividade organizacional: uso das aplicações e tráfego, custo das releases,  valor para o negócio – custo por release, estórias entregues, etc.

Change Management e DevSOXOps com Azure DevOps

Este post é direcionado as empresas regidas por compliance e que possuem um processo mais formal de publicação de releases em produção. Sem dúvida, precisamos trabalhar com o mínimo de intervenção manual, utilizando ferramentas para automatizar e rastrear os pontos de controle exigidos em auditorias.

E o que é SOX? E como as empresas que estão no Brasil são impactadas?
soxE quais as principais recomendações para as empresas neste cenário?
compliance

Azure DevOps (Microsoft) e o processo de Change Management


Teste técnico: um dos primeiros passos é a evidência do teste técnico. Que tal consolidar com o Quality Gates do SonarQube? Este step pode ser configurado no pipeline do Build/Release.

change-management-01

Homologação: os planos de teste (na área de testes do Azure DevOps) são criados e vinculados com os Work Items. Eles possuem os recursos de gravação ou screenshot para apoiar a validação do sistema. Em caso de erro, você pode abrir um novo bug para aquele Work Item.

O Request Feedback é outro recurso para solicitar a homologação do usuário e armazenar as evidências.

This slideshow requires JavaScript.

Procedimento de publicação: por fim, a configuração do pipeline no Azure DevOps permite o controle das releases e aprovação para a liberação em ambientes como o de QA e produção.

This slideshow requires JavaScript.

 

 

 

 

Pipeline de Build e Release – Azure DevOps

Vamos demonstrar em poucos passos como configurar o Build e Release (Azure Pipelines) no Azure DevOps.

azure-devops

Build

1. Definição de tarefas e as etapas do Build.

azure-devops-pipeline-03

2. O versionamento é essencial para o Continuous Integration e a gerência de configuração. O Get Sources é o local das configurações e apontamento para o código-fonte.

azure-devops-pipeline-04

3. A compilação do código-fonte e a análise da cobertura dos testes unitários. O IntelliTest pode apoiar nesta atividade.

 

azure-devops-pipeline-05.png

4. Também há uma etapa para incluir a análise de código. O SonarQube é uma recomendação para analisar bugscode smellsvulnerabilitiesduplications.

azure-devops-pipeline-06.png

Release

5. E o posterior deploy da aplicação, identificando as tarefas, variáveis e opções. Por aqui referencia-se o Build realizado.

azure-devops-pipeline-01.png

6. O processo de aprovações é muito válido para empresas regidas por compliance. Pode ser configurado aprovadores antes do deploy em cada ambiente – desenvolvimento, homologação, QA e produção.

azure-devops-pipeline-02.png

Cultura DevOps na sua empresa

Em posts anteriores, fizemos a introdução de ALM (Application Lifecycle Management), CI (Continuous Integration) / CD (Continuous Delivery Continuous Deployment) e da Jornada DevOps na organização. E como mudar então a cultura da empresa para que o DevOps seja implementado em seus processos?

Um dos pontos iniciais desta mudança é o patrocínio onipresente em diversas camadas da empresa. Este direcionamento certamente vai acelerar alguns dos itens abaixo, entre eles, a adoção de boas práticas em desenvolvimento (arquitetura escalável,  padrões, engajamento com CI e gestão da configuração) e operações (infra as code).

cultura-devops.jpgA integração entre as áreas e o compartilhamento do conhecimento devem fazer parte do dia-a-dia em seu ambiente de trabalho. Promova eventos como DOJOs, Webinars, entre outros para disseminar o conhecimento e manter seu time sempre em evolução de práticas e tecnologias. Pense em gamification e como engajar o time a melhorar seus testes, qualidade do código e processo de CI.

Em muitos casos de transformação digital, vimos que as empresas adotaram métodos ágeis e práticas DevOps como premissas para habilitar o time to market. Criar esteiras eficientes, capazes de colocar o tempo todo novas releases no mercado, tornaram-se essenciais para validar o aprendizado com o mercado e investir em features que realmente trazem retorno. O Lean Startup aborda mais destes pontos.

CI-CD.jpg

A estratégia de começar “pequeno” é a mais recomendável. Escolha um projeto piloto para consolidar as práticas, os processo e as ferramentas. Assim, com o ganho observado, fica mais fácil de propagar as demais equipes e engajá-los na adoção de práticas e ferramentas. Trabalhe com times multifuncionais! Eles precisam ter o conhecimento e empoderamento para entregar os produtos.

Tenha uma boa solução de ferramentas! Considere a automação de tarefas como do build, release e testes. Só assim você conseguirá escalar e ter um processo high performer. Uma boa gestão de ambientes (virtualização, containers, etc.) e versionamento do código-fonte são essenciais também. O Azure DevOps é uma ótima solução de DevOps.

azure-devops

Por fim, não esqueça de mensurar os resultados e compartilhar os benefícios. Como está a frequência do deployment e do check-in do seu time? Há quebras no build? Retrabalho de atividades? Qual a causa?

E o lead time? O ciclo de vida da aplicação possui gargalos? Possui métricas de qualidade? Quais são as métricas de análise de código? A área de testes tem KPIs? O time está engajado com testes unitários? Como está a taxa de falhas (change failure rate)? E o MTTR? Há feedbacks do usuário? Os critérios de aceitação estão sendo atingidos?

metrica-devops.png

O Azure DevOps possui a área de Analytics no pipeline de Build e Release para representar informações do processo de CI (Continuous Integration) como cobertura de código (em testes unitários), validação de testes, execução dos builds, etc.

build-quality

Palestra Agile Trends – Habilitando o Continuous Deployment em empresas regidas por SOX

Palestrante: Leonardo Matsumota
Cargo: IT Innovation Manager
Evento: Agile Trends (Florianópolis)
Tema: DevSOXOps – Habilitando o Continuous Deployment em empresas regidas por SOX e compliance
Data: 10/10/2018
Download do material: Apresentação DevSOXOps – Agile Trends

Agile-trends-01

Tópicos da apresentação

  • Cadência Ágil e DevOps na Educação
    • SAFe
    • Azure DevOps e ferramentas que utilizamos
  • SOX
  • Processo de Change Management anterior
  • Azure DevOps Boards
    • Estruturando os times de projeto e template de processo
    • Cadência dos times
    • Backlog: Epic >Feature > User Story
  • Continuous Integration / Continuous Delivery / Continuous Deployment
  • Configuration Management
  • Definições de Build
  • Cultura DevOps na organização
  • Pipeline
  • Compliance and auditing
  • Change Management com Azure DevOps
  • Métricas e Dashboard