Azure DevOps x Zendesk – Integração com service hooks

O Service Hooks é um recurso interessante do Azure DevOps para habilitar ações, baseadas em eventos que acontecem nos projetos do Azure DevOps. Por exemplo, criar uma notificação no Slack (em algum grupo específico) sobre um deploy bem sucedido. Ele funciona da seguinte maneira:

  • Publisher: define um conjunto de eventos.
  • Subscriptions: recebe os eventos e define as ações (Actions) a serem tomadas. Os consumidores (Consumer) são serviços externos que podem executar suas próprias ações, ao ocorrer algum evento.

service-hooks

Há vários serviços disponíveis no Marketplace que permitem a integração com o Azure DevOps Services. Veja a relação dos principais abaixo:

services-azure-devops

Neste post, vamos abordar a integração do Azure DevOps com o Zendesk.

1. Criando os conectores

O primeiro passo é instalar o IntegrateCloud Connector for VSTS no Zendesk. Vá no Marketplace e execute a instalação.

instalacao-integrate-cloud-azure

Você irá precisar de um Token (do lado do Zendesk) para permitir a integração com o Azure DevOps. Acesse no Zendesk a [Engrenagem de Admin] > Canais > API e ative o acesso por token, conforme imagem abaixo. Salve este token.

API-zendesk

Feito isso, acesse o Azure DevOps e configure o Service Hook do Zendesk para permitir a manipulação dos work items externamente. Para isso, acesse Project Settings > Service Hooks e adicione um novo Serviço do Zendesk.

  • A tela seguinte solicita Area Path e Work Item Type desejado.
  • Na última tela, insira a conta, usuário e token gerado no Zendesk.

new-service-hooks

Também adicione um token do lado Azure DevOps para prover a autorização da configuração do Service Hook, feito acima. Acesse “Personal access tokens” e insira um nome para ele. Salve este token também.

token-service-hooks

2. Integração de work items

Na sequência, crie um novo ticket (ou acesse algum já criado) no Zendesk e configure a área de Aplicativos (lado direito da tela). Insira a URL da conta do Azure DevOps e o Token que acabamos de gerar no passo anterior.

ticket-zendesk

Feita a autenticação, a tela abaixo (do IntegrateCloud Connector for VSTS) irá aparecer. Preencha o Projeto (Area Path) e a  Sprint (Iteration) que deseja publicar esse work item. Salve a modificação.

integratecloud-connector-vsts

Veja que o ticket criado no Zendesk agora foi criado como work item (pode ser do tipo task / bug / epic / feature / user story) no Azure DevOps. Pronto! A integração entre os dois está funcionando.

board-azure-devops

Lembrando que o Service Hooks é um recurso para para habilitar ações, baseadas em eventos e que pode ser utilizado na integração com diversos sistemas (conforme mostrado no início do artigo). Aqui fizemos uma demonstração com o Zendesk.

Priorização de requisitos e projetos – product management

Com a evolução contínua no modelo de negócios, onde as empresas precisam de adaptação rápida e time to market, um bom critério de priorização é primordial para avaliar os projetos (ou requisitos dos times) e evitar desperdícios, além de maximizar ao máximo a entrega de valor ao negócio.

Muitas empresas ainda estão viciadas no ciclo de receber/trabalhar/entregar muita demanda, porém isso entrega valor ao negócio? E quanto aos critérios de priorização? Desta forma, vamos abordar algumas técnicas de priorização que ajudam a direcionar o esforço das equipes, baseado em critérios.

Outro ponto é a aplicabilidade. As técnicas abaixo foram criadas com um propósito específico (a serem utilizadas em projetos ou requisitos), mas podem ser adaptadas a outros níveis (time, programa ou portfólio). Também vale avaliar se o mercado é B2C ou B2B, pois a validação de hipóteses com os usuários finais podem gerar indicadores que servem como critério de priorização (tais como conversão, churn, uso, etc.).

MoSCoW

O MoSCoW (Must haveShould haveCould have and Won’t have) é uma das técnicas de priorização, geralmente utilizada com timeboxing – deadline fixado e o foco é nos requisitos mais importantes. Ajuda a comunicar o que será feito de imediato ou não.

  • Must Have (Deve Ter): são as funcionalidades imprescindíveis para o projeto. Devem ser refinadas (ou aprofundadas) para melhorar o entendimento do time.
  • Should Have (Deveria Ter): é importante ter, mas não são imprescindíveis.
  • Could Have (Poderia Ter): seria bom ter, mas não são essenciais. Porém, entregá-las pode ser um diferencial ao cliente.
  • Won’t Have for Now (Não Terá por Enquanto): por hora não será feito, já que não gera valor ao negócio naquele momento.

moscow

RICE

Outro acrônimo para Reach (Alcance), Impact (Impacto), Confidence (Confiança) e Effort (Esforço). Os três primeiros itens da matriz são pontuados e divididos pelo último. Isso ajuda a medir o impacto de cada tarefa no todo e a determinar a prioridade mais alta do backlog.

Fórmula: R * I * C / E

  • Reach: qual o alcance desta tarefa (pessoas impactadas)?
  • Impact: o grau do impacto nas pessoas
    • Impacto Massivo: 3
    • Grande Impacto: 2
    • Médio: 1
    • Baixo: 0,5
    • Impacto Mínimo: 0,25
  • Confidence: quão confiante estamos nas estimativas
    • Alta confiança: 100%
    • Confiança média: 80%
    • Baixa confiança: 50%
    • Mínima confiança: 20% ou menor
  • Effort: o tempo necessário para concluir a tarefa

BASICO

A BASICO possui seis critérios que apoiam a priorização de projetos e processos. Cada critério é pontuado de 1 a 5 e o resultado é a soma dos critérios (1 = pior cenário; 5 = melhor cenário). As maiores notas são priorizadas.

  • Benefícios para a empresa
  • Abrangência dos resultados
  • Satisfação do cliente interno
  • Investimento necessário
  • Cliente externo satisfeito
  • Operacionalidade simples

GUT

Outra opção é a GUT que possui três critérios e pontuação de 1 a 5 também para classificar a prioridade dos projetos.

  • Gravidade: classifica as ações que você precisa realizar conforme o impacto que elas terão em outras atividades ou projetos;
  • Urgência: considera o tempo restante para resolver cada situação;
  • Tendência: é uma projeção da velocidade que um problema não resolvido pode levar para piorar.

gut

WSJF (Weighted Shortest Job First)

A técnica WSJF, criada por Don Reinertsen e recomendada no SAFe, apoia a priorização de features, maximizando o custo do atraso (COD – Cost of Delay) e a duração do trabalho. E assim, em regra geral:

  • Features com a mesma duração = priorizar as que possuem maior custo do atraso, pois assim minimizaria o custo total.
  • Features com o mesmo custo de atraso = priorizar as que podem ser lançadas mais rapidamente, pois assim minimizaria o custo do atraso.

Como o custo do atraso e duração das features podem variar muito de uma para outra, o WSJF contribui muito na priorização com a seguinte fórmula:

  • WSJF = Cost of Delay / Job Duration (Job size)

E o custo de atraso é calculado da seguinte forma:

  • Cost of Delay = User Business Value + Time Criticality + Risk Reduction and/or Opportunity Enablement

WSJFFonte: SAFe (Scaled Agile Framework)

Technical Certainty x Business Agreement

Entre as diversas matrizes que existem para priorização de requisitos, a matriz da Tech and Business Review da Lean Inception é uma que sintetiza bem o valor do negócio x esforço para construção das features. Possui nove quadrantes.

  • Technical Certainty: como o time de desenvolvimento avalia a complexidade para criar a funcionalidade.
  • Business Agreement: quão bem o negócio concorda com o que entra na feature.

As features de certeza técnica baixa (E) e valor de negócio baixo ($) são descartadas do MVP de imediato. Assim como, certeza técnica média (EE) e valor de negócio baixo ($); também são descartadas as features do quadrante certeza técnica baixa (E) e valor de negócio médio ($$). As demais serão avaliadas conforme a técnica da Lean Inception.

business-effort-matriz

Outras técnicas

  • Modelo Kano
  • QFD (Quality Function Deployment)
  • Opportunity Scoring
  • Buy a feature
  • Matriz de Eisenhower (Urgência X Importância)
  • Matriz Esforço x Impacto
  • Matriz de Custo x Benefício

Leitura recomendada

Disciplined Agile Delivery (DAD) vs Scrum vs SAFe

Já abordamos o Disciplined Agile Delivery (DAD) em posts anteriores, e um resumo de como está estruturado – em três fases: Inception, Construção e Transição. Os aspectos de arquitetura e design (Inception) e DevOps (Transição) são alguns dos pontos interessantes do DAD.

Também fornece mais flexibilidade nas recomendações do projeto, através dos melhores processos para cada tipo de projeto (dependendo do que será construído), ao invés de prover um plano prescritivo. O DAD possui quatro modelos de ciclo de vida: agile/basic, lean/advanced, continuous delivery, and exploratory.

Outros frameworks muito conhecidos e utilizados em agilidade são: o Scrum para desenvolver, entregar e manter produtos complexos e o SAFe (Scaled Agile Framework), que sincroniza o alinhamento, a colaboração e a entrega para um grande número de equipes.

Papeis

O DAD atribui o Team Lead como responsável por manter o time focado no cumprimento dos objetivos, remoção de impedimentos e a expertise em processos ágeis. Também inclui o Architecture Owner para decisões e prioridades técnicas. Os papeis secundários geralmente ocorrem em necessidade de escala.

DAD

Papeis primários
• Team Lead
• Product Owner
• Architecture Owner
• Team Member
• Stakeholders

Papeis secundários
• Independent Testers
• Specialists
• Domain  Expert
• Technical Expert
• Integrator

 

 

 

SAFe

Time
• Product Owner
• Scrum Master
• Time de desenvolvimento

Programa
• Product Management
• Release Train Engineer
• System Architect

Large Solution
• Solution Management
• Solution Train Engineer
• Solution Architect

Portfolio
• Lean Portfolio Management
• Epic Owners
• Enterprise Architect

Scrum

Time Scrum
• Product Owner
• Scrum Master
• Time de desenvolvimento

 

 

 

 

 

 

 

 

 

Artefatos

Enquanto o Scrum possui artefatos direcionados ao time (backlog do produto e da sprint, burn down e incremento), o DAD e SAFe são mais abrangentes em relação a perspectiva do projeto.

DAD

• Business and Technology Roadmap
• Initial Requirements and Architectural Vision
• Iteration Backlog

 

 

 

 

SAFe

Portfolio
• Investment Themes
• Business and Architecture Epics
• Portfolio Backlog and Vision

Programa
• Product Roadmap
• Program Backlog
• Architecture Runway
• Business and Architecture Features

Time
• Team Backlog
• Team PSI Objective
• Sprint Goals

Scrum

• Product Backlog
• Sprint Backlog
• Gráfico Burn Down
• Incremento

 

 

 

 

 

 

 

Processos

Em processos, o Scrum também possui uma boa estrutura a nível de time, enquanto o DAD e SAFe são mais abrangentes, por considerarem custos, sincronização entre times e estratégia de priorização de projetos.

DAD

Inception
• Formação de time, visão comum, escopo inicial, estratégia técnica, de custos, riscos e release plan

Construction
• Desenvolver a Potentially Consumable Solution, endereçando necessidades dos stakeholders (e mudanças) considerando a qualidade e uso da arquitetura acordada

Transition   
Deploy e o uso da solução
• Melhorias nos processos, ambientes e infraestrutura

SAFe

Portfolio
• Temas estratégicos, épicos, portfólio e budget aos value streams

Large Solution
• Capabilities, Large Solution (Backlog e Kanban)
e Solution Planning / Demo

Programa
• Features, Program Backlog, WSJF, PI (Program Increment) – System Demos e Inspect and Adapt

Time
• User Stories, Team Backlog, Sprint Backlog e conduzir as Sprints

Scrum

•  User Stories, Sprint Backlog e Sprints (Planning, Daily, Review e Retro) e criação do incremento

 

 

 

 

 

 

 

Por fim, vimos acima uma breve explicação e comparação entre DAD, SAFe e Scrum, que podemos resumir da seguinte forma:

  • DAD: é híbrido entre os métodos existentes e fornece flexibilidade para usar várias abordagens. Considera aspectos de iniciação e implementação (full delivery lifecycle). É people-first, learning-oriented e Hybrid agile.
  • SAFe: é mais prescritivo e fornece uma estrutura em diferentes níveis (time, programa e portfólio) que pode facilitar a transição para uma estrutura ágil, além de ser aplicável a um grande número de times (ágil em larga escala).
  • Scrum: aplicável a times individuais, usado para gerenciar o trabalho em produtos complexos. Consiste de times Scrum associados a papéis, eventos, artefatos e regras.

Leitura recomendada

Introdução ao Disciplined Agile Delivery 2a Edição: A Pequena Jornada de um Time Ágil partindo do Scrum até o DevOps por [Mark Lines, Scott Ambler, Alessandro Kieras, Adriano Tavares]SAFe 5.0 Distilled (English Edition) por [Knaster Richard, Leffingwell Dean]