Dashboards de Projetos Ágeis no VSTS utilizando Widgets

Debatemos em fóruns anteriores a importância das métricas no gerenciamento de projetos ágeis e no ciclo de vida da aplicação.

Além de identificar problemas no processo de desenvolvimento de sistemas, garante a transparência das Sprints, o backlog em execução e os bloqueios que devem ser removidos da equipe.

Mensurar é ponto essencial no processo de Integração Contínua. Não há um bom deployment pipeline sem avaliar a qualidade do código, cobertura dos testes, build, release, entre outros.

E como começar utilizando o VSTS?

1. Acesse o seu projeto no VSTS. Na guia Dashboards, clique no símbolo da engrenagem e manage dashboards (no canto direito) para criar um novo painel. Ou clique em Edit para adicionar os Widgets ao modelo padrão de Dashboard.

dashboard-vsts-criacao

2. Em seguida, escolha a opção de Add Widget para incluir os paineis no Dashboard.

widget-vsts

3. Defina as métricas mais importantes para o seu time. Algumas sugestões de widget para compor o Dashboard Agile:

  • Burndown: gráfico que pode ser mantido para visualizar o trabalho restante
  • Countdown Sprint: exibe os dias restantes para acabar a Sprint
  • Query Title Pro: permite buscar queries criadas no work do VSTS e trabalhar com médias e sumarizações. Assim, podemos calcular a velocidade do time, em story points ou em horas (dependendo do template adotado). Veja mais neste post.
  • Chart for Build History: gráfico de acompanhamento dos builds da aplicação
  • Query Title: indicadores como de Bloqueios e Riscos podem ser visualizados utilizando este widget, associando com as queries do VSTS. Mais detalhes.
  • Chart for work items: cria gráficos com base nas queries do VSTS. Mais detalhes.
  • Cumulative flow diagram: visualiza o fluxo de trabalho e se há gargalo no processo – veja mais.

dashboard-vsts

 

 

Utilizando 5 Porquês (5-Why) na análise da causa raiz de sistemas TI

Foco na causa e não nos sintomas…

  • E como está a gestão dos problemas no seu time?
  • Quando novos bugs ou retrabalhos são gerados, há um método para avaliar a causa e consequência, como espinha de peixe de Ishikawa?
  • O plano de ação tem dedicado esforços para resolver os problemas mais críticos? Como a matriz GUT (Gravidade, Urgência e Tendência)
  • O follow-up garante a transparência no processo? De fato as causas dos problemas estão sendo atacadas?
  • Já trabalha com Pareto na análise de distribuição das ocorrências? 20% dos problemas são responsáveis por 80% das ocorrências?

Hoje vamos falar sobre o 5 porquês (5-Why) e como utilizar para determinar a causa raiz do problema. Trata-se de uma uma técnica criada por Taiichi Ono, um dos responsáveis pela criação do sistema Toyota de produção, funcionando muito bem para problemas simples.

Embora tenha surgido como ferramenta de gestão da qualidade total e melhoria contínua na indústria, também é muito aplicável no contexto de serviços, como de desenvolvimento de sistemas na área de TI. Reunindo a equipe, deixe a comunicação aberta para participação de todos os envolvidos no processo.

Problema: cadastro de novos produtos não está funcionando
(aberto um bug no VSTS de problema no módulo de produtos)

bug-vsts

Ao analisar a causa raiz do problema, percebemos que o erro encontrado no sistema era referente a um procedimento que deveria ser realizado, e que um treinamento ou informativo poderiam ter ajudado a evitar o problema.

5-porques

Concluindo o post, vale lembrar que o 5 porquês possui limitações e deve ser utilizada com outra ferramenta, por exemplo espinha de peixe – Ishikawa, para análise detalhada de problemas de maior complexidade.

espinha-peixe

 

 

 

 

 

 

 

Analytic Hierarchy Process (AHP) – método de apoio a decisões complexas

Analytic Hierarchy Process (AHP)
É um método de apoio a tomada de decisões complexas, baseado em procedimento abrangente e racional na estruturação do problema. Foi desenvolvido por Thomas L. Saaty em 1972, na Escola Wharton de Administração de Empresas da Universidade da Pensilvânia.

A essência AHP considera os julgamentos humanos e as informações numéricas, pois converte os julgamentos em valores numéricos. Isso permite o processamento e comparação de toda a extensão do problema.

Geralmente, utilizamos modelos de software como Expert Choice, Decision Lens, Make It Rational e Web-HIPRE para trabalhar com os dados e síntese dos resultados. Ou também o software desenvolvido pela Universidade Federal de Alfenas.

AHP

E como funciona?

  • Hierarquia: decompor o problema em subproblemas. Facilita a compreensão e permite análises independentes.
  • Elementos da hierarquia: tangível ou intangível, relaciona-se com os aspectos do problema de decisão.
  • Avaliação: avaliar as decisões sistematicamente, considerando seus elementos e comparando-os um ao outro. Os dados podem ser concretos ou com base no julgamento sobre a importância dos elementos. Um peso ou prioridade é derivado para cada elemento da hierarquia.

AHP-subcriterios.png


Aplicabilidade
Embora possa ser utilizado por indivíduos lidando com decisões simples, o AHP é mais útil quando equipes estão envolvidas em

  • Problemas complexos que necessitam de percepção humana
  • Resolução terá repercussão de longo-prazo
  • Dificuldade de quantificar ou comparar elementos da decisão
  • Problema de comunicação entre os elementos – especialidades, terminologias e perspectivas diferentes


Utilizando AHP

  • Objetivo: Comprar um carro
  • Critérios: Estilo, Confiabilidade e Consumo
  • Alternativas: Focus, Corolla, Civic, Fluence

AHP-criterios

Os dados são sintetizados de modo a determinar rankings relativos de cada alternativa. Podem ser usados métodos quantitativos e qualitativos para comparar os critérios e definir os pesos e prioridades. E baseado no julgamento humano, determinamos os critérios mais importantes:

  1. A confiabilidade é 2 x mais importante que o estilo
  2. O estilo é 3 x mais importante que o confiabilidade
  3. Confiabilidade é 4 x mais importante que o consumo

A Pairwise Comparation (comparação paritária) relaciona os pesos atribuídos aos critérios, expressando a importância de um critério relativo em relação ao outro:

pairwise

Passo 1
Converter a matriz de frações em decimais
pairwise-II

Passo 2 – Multiplicar as matrizes
Passo 3 – Somar as linhas e depois colunas. Depois normalizar, dividindo o valor de cada linha pelo o total da coluna
Passo 4 – Recomeça-se o processo. Compara-se o resultado anterior com o novo encontrado, até que uma nova interação não demonstra muita diferença

Claro, que este cálculo deve ser feito utilizando um software recomendado. O resultado então ficou:AHP-resultado

Pode-se calcular alternativas também, realizando para cada critério o mesmo processo. A medida de inconsistência entre a pairwise comparision da matriz pode ser expressa por: C.I. = λmáx – n
               n – 1

Post To Slack com VSTS – interação de build e release com mensagens

Post To Slack é uma extensão bem valiosa para os times de desenvolvimento que já trabalham com a ferramenta de colaboração Slack (tecnologia social) e VSTS em CD/CI.

aplicabilidade que vamos demonstrar neste Post é de postagem de mensagens nos canais dos grupos a cada promoção da Release em ambientes diferentes – por exemplo, servidor de Dev | Homolog | Produção.

E qual a finalidade disso? Fica algumas sugestões:

  • Notificar a equipe sobre a disponibilidade de uma nova release em um ambiente
  • Também pode ser utilizado nas tarefas de build
  • Facilidade na comunicação entre os membros do time
  • Apoiar o processo de gestão da mudança e transição de ambientes


Marketplace
Para começar a utilizar o Post To Slack, acesse o Marketplace da Microsoft (o link está disponível em Extensões do VSTS) e busque pelo nome: Post To Slack. Em seguida, será enviada a requisição para aprovação. No VSTS, acesse Extensões e na guia Requested, basta fazer a aprovação e acionar a instalação do mesmo.

post-to-slack

Post To Slack – VSTS
Após a instalação, já podemos utilizá-lo no Agent Phase das tarefas de Build Release. Mas, será necessária a configuração do Token para interagir com o Slack. No exemplo abaixo, utilizamos nas tarefas da Release, incluindo a mensagem e o canal do Slack onde serão publicadas.

post-to-slack-release

Slack
Feito o deploy da release mencionada anteriormente, a mensagem é postada no canal do Slack. E assim, o time todo será notificado, principalmente o responsável pela Release.

slack-vsts

 

 

 

VSTS – Pipeline de releases e gestão da mudança com aprovadores

Contexto: já vimos os benefícios e desafios dos processos de CI (Continuous Integration) e CD (Continuous Delivery) em outros posts. Além de habilitar esteiras velozes e eficientes para publicação de releases, é um dos pontos determinantes na adoção de práticas DevOps na empresa.

Este post é direcionado as empresas que possuem processos mais formais, regidos por compliance.release neste caso depende de aprovações como do gestor da mudança (change management) e outras áreas, como a homologação do solicitante (geralmente o Product Owner), antes de ir para a produção.

VSTS – Configurando aprovações no pipeline de releases
Iniciamos criando uma nova definição de release. Para isso, acesse o VSTS na opção de Build and Release. Em Releases, clique em + Create Release Definition. A janela abaixo será aberta com as configurações da release. Escolha os ambientes (environments) e artefatos que serão trabalhados.

release

Em seguida, todas as Releases criadas serão exibidas na tela. Neste exemplo já haviam outras releases criadas, por isso apareceram várias. Clique em Edit para configurar o Pipeline com os Artefatos e Tarefas da release.

releases.png

O Pipeline habilita a configuração Artefato (na esquerda) e dos Ambientes (na direita). É nesta área que definimos os aprovadores, triggers e agendamento das tarefas.

pipeline-releases

Artefato
Ao adicionar um novo artefato, escolha o tipo do artefato – Build | Source Control | etc., referencie o nome do projeto e as definições de Build (por termos escolhido o Build no source type). 
artifact-release

Environments
Ao adicionar os ambientes em + New Environment, podemos criar por exemplo, os ambientes de desenvolvimento, homologação e produção. Utilize a opção clone environment após a criação do primeiro ambiente para copiar as configurações (se aplicável) a fim de facilitar.

Com os ambientes criados, clique na própria caixa do ambiente para configurar as tarefas que serão executadas pelo Agent (lado direito da imagem abaixo).

release-environments

Também na configuração do ambiente, mas no canto esquerdo da caixa há uma imagem que representa triggers e aprovadores para pré ou pós deployment. Clique nela:
trigger-approval

Em seguida, será exibida uma tela com a configuração de Pre-deployment:

  • Triggers: define se o evento acontecerá After release | After Environment | Manual Only
  • Pre-deployment approvals: insira os usuários que precisam aprovar a release antes de subir em produção, ou mesmo no ambiente de QA.
  • Schedule: se o build (que inicia a execução das releases) não estiver automático, esta opção permite agendar a execução das releases.

 

O acompanhamento do deploy das releases está disponível na aba Logs. O status de cada etapa e em qual ambiente está sendo executado pode ser visto no lado esquerdo da tela.release-log

As aprovações podem ser gerenciadas na guia Summary da conta do aprovador. Ao clicar em Approve or Reject, será aberta a janela para realizar a aprovação.

release-approval

Kanban, produção empurrada e puxada em sistemas de TI

Produção Empurrada, Produção Puxada e Sistema Misto

Os conceitos de produção empurradaprodução puxada surgiram nas década de 50 e 60, com a necessidade de atender a demanda de clientes na indústria. A evolução do modelo ocorreu principalmente com o Sistema Toyota de Produção, modelo para suportar o JIT (Just In Timee Kanban, método visual para controle de produção e prever gargalos no processo.

toyota-kanbanImagem: Blog Toyota


Produção empurrada (push system)
A empresa trabalha com produção em grandes lotes, mais voltada para estoque. O planejamento é baseado em estudo de mercado (atender sazonalidades) e histórico de vendas. A divulgação dos produtos é outra forma para obtenção de caixa e justificar a produção em escala.

push-pull-system

Produção puxada (pull system)
Baseia-se na demanda e estoque reduzido, sendo a produção iniciada a partir da demanda do cliente. Para isso, deve ter um sistema eficiente de produção, sem gargalos e com prontidão no atendimento. O JIT (Just in Time) é um sistema muito conhecido e utilizado neste contexto. Visa a redução de custos, eliminação de desperdícios e estoque de produtos.

Sistema misto
Ocorre quando os dois conceitos (empurrada e puxada) são utilizados juntos pela empresa no fluxo de valor completo ou uma parte do processo.

Aplicando os conceitos em TI: Kanban Agile

Trazendo os conceitos industriais a TI, a principal aplicabilidade do Kanban é na área de  desenvolvimento de sistemas. As tarefas que estão no backlog do time devem ter uma esteira de publicação contínua e sem gargalos. Só assim, conseguimos atender as demandas do mercado, como campanhas publicitárias e mudanças de requisitos.

Quando aplicado o Sistema Kanban, devemos considerar:

  • Geração de valor das entregas
  • Visualização das tarefas e o limite de WIP (work in progress)
  • Sistema puxado
  • Tornar os problemas explícitos e engajar as pessoas na mudança

O widget de Flow do VSTS (Visual Studio Team Services) da Microsoft projeta a visualização das tarefas: backlog (proposed) x WIP (active / resolved) x concluído (closed):flow-vsts

Também considere as seguintes métricas:

  • Lead Time: tempo entre a criação da tarefa até a conclusão (estado final)
  • Cycle Time: considera o tempo entre a tarefa “em progresso” até a conclusão
  • Throughput: capacidade de vazão das tarefas
    throughput

E as estimativas das tarefas? No Kanban, a previsibilidade é obtida pelo comportamento observado do sistema. Se o Lead Time, por exemplo, tiver em média 3 horas, este é o tempo em que a tarefa deverá estar em produção. Em geral, a variação do Lead Time está associado ao WIP não limitado, bloqueios e o tipo de demanda.

O controle visual do processo pode ser configurado utilizando o VSTS. No board visualizamos as atividades que estão a FAZER (Proposed), EM PROGRESSO (Active / Resolved) e FEITO (Closed). O template utilizado do VSTS foi o CMMI, por isso fizemos uma relação dos status das atividades com o Kanban convencional.

vsts-kanban

 

Integração SonarQube com VSTS

Continuando o processo de CI (Continuous Integration) e CD (Continuous Delivery), o SonarQube é uma excelente ferramenta open source de análise de qualidade do código-fonte. Os times de desenvolvimento utilizam no processo de DevOps pipelines de integração contínua para inspecionar regularmente a qualidade dos Builds, entre eles, bugs, vulnerabilidades, code smellscode coverage.

A extensão do SonarQube pode ser instalada, acessando o Marketplace da Microsoft:

sonarqube-marketplace

Agora no VSTS, o primeiro passo é configurar o servidor SonarQube como um serviço endpoint do seu projeto. Acesse o Services no VSTS e escolha a opção + New Service Endpoint. Defina o nome da conexão e servidor de URL no SonarQube Server e o Authentication Token.

sonarqube-endpoint

A seguir devemos configurar a tarefa Prepare Analysis Configuration nas Definições de Build do VSTS. O nome do projeto, source e o servidor de endpoint do SonarQube são parametrizados nesta etapa.

sonarqube-vsts

E a análise do código pode ser acompanhada no servidor do SonarQube ou configurando o SonarCloud.

sonarqube