MISSÃO: KANBAN - Parte II- ESTABELECER AS CLASSES DE SERVIÇO E TORNAR AS POLÍTICAS EXPLÍCITAS
Dando sequência à série de posts Missão: Kanban (clique aqui para ler o primeiro post da série), hoje falaremos um pouco mais sobre os encontros do time de desenvolvimento para construção do sistema Kanban. No post de hoje falaremos sobre o segundo e o terceiro encontro, que tiveram como objetivo principal estabelecer as classes de serviço e tornar as políticas explícitas, respectivamente.
Recordando que a série Missão: Kanban está sendo compartilhada em cinco posts com publicação semanal e que este é o terceiro post da série (a agenda de publicações completa com o link dos posts anteriores está disponibilizada no final deste post).
TENHA UMA BOA LEITURA!
ENCONTRO 2 — ESTABELECER AS CLASSES DE SERVIÇO
§ Tarefas
- Definir os tipos de classes de serviço;
- Estabelecer uma política de priorização entre as classes de serviço.
§ Resultados esperados
- Classes de serviço definidas e priorizadas;
- Classes de serviço representadas no board do time.
Após uma semana do primeiro encontro e de pilotagem do processo elaborado pelo time, nos reunimos novamente para acrescentar um novo item dentro do nosso fluxo de trabalho: as classes de serviço.
O time já possuía um conhecimento básico sobre classes de serviços, uma vez que tínhamos no Scrum Board a divisão dos itens de trabalho entre “Urgente”, que recebia os bugs em ambiente de produção e “Padrão”, onde basicamente o time colocava os itens a serem trabalhados na Sprint. Era um método simples que tinha como objetivo garantir a prontidão no tratamento de erros no ambiente de produção.
AS CLASSES DE SERVIÇOS
Para esta etapa, primeiramente apresentei ao time um resumo das quatro classes de serviço do Kanban, conforme livro Kanban — Mudança Evolucionária de Sucesso Para Seu Negócio de Tecnologia (David J. Anderson).
EXPEDITE (Expedição)
Itens de grande urgência e que necessitam serem trabalhados e entregues o quanto antes pois podem trazer grandes impactos em pouco tempo.
A expedite é conhecida por aumentar os níveis de estoque e aumentar o lead times de outros itens de trabalho.
FIXED DATA (Data Fixa de Entrega)
Item que precisa ser entregue em um prazo fixo, geralmente relacionado a uma situação eventual, e que faz sentido apenas se entregue antes do acontecimento.
Também pode ser algum tipo de implementação regulatória.
STANDARD (Classe Padrão)
Itens de trabalho comuns orientados segundo uma priorização por algum tipo de critério (urgência, valor de entrega, etc).
As políticas e o acordo de nível de serviço para um item de classe padrão podem variar de acordo com o tipo de item.
INTANGIBLES (Intangíveis)
Itens de trabalho que são difíceis de mensurar seus ganhos ou impactos em um primeiro momento, mas que a médio ou longo prazo podem tanto causar prejuízos, caso não sejam cumpridos, quanto trazer bons resultados.
Após um breve debate sobre as classes de serviço e o impacto que elas teriam sobre a realidade do time e o fluxo de trabalho mapeado, o time optou por manter as classes de serviços já utilizadas (Expedite e Standard) e incluir neste primeiro momento a classe de serviço “Fixed Data”. O time optou por não utilizar a classe de serviço “Intangible” uma vez que, analisando o contexto histórico das demandas, não foram identificados itens que se aplicariam nesta classe de serviço.
Devido ao isolamento social estamos atuando no formato home office, ou seja, sem board físico. Desse modo, o time escolheu cores para representar as classes de serviços dentro do board virtual, deixando as lanes do board direcionadas para as iniciativas e produtos que o time está atuando (a exceção fica por conta do Expedite, que está representado na primeira lane do fluxo). O time acredita que este formato, além de facilitar a sua auto-organização orientada aos produtos, também fornece a flexibilidade necessária na resposta às demandas dos clientes. O time também acordou que a classe de serviço do item de trabalho deve ser definida antes do item entrar na etapa de downstream.
Para evidenciarmos quão adaptável e abrangente é o sistema Kanban, nessa etapa o time Atlantis optou por utilizar as quatro classes de serviços sugeridas por David Anderson, representando-as através de lanes específicas no board. Neste caso foi definida uma cor de card para produto que o time atua.
ESTABELECER UMA POLÍTICA DE PRIORIZAÇÃO ENTRE AS CLASSES DE SERVIÇO
Para este momento inicial o time optou por estabelecer apenas uma regra sobre a prioridade de classes de serviço. Foi definido que os itens que estiverem na classe de serviço Expedite seriam prioritários frente aos demais, seguindo o formato de priorização aplicado pelo time aos itens urgentes.
APRENDIZADOS ADQUIRIDOS NO ENCONTRO
§ As classes de serviço facilitam a auto-organização e delegam poder aos membros da equipe;
§ As classes de serviço determinam prioridade dentro do sistema;
§ Itens de trabalho devem ser atribuídos para uma classe de serviço de acordo com o impacto no negócio;
§ As classes de serviço devem ser claras, apresentadas visualmente com o uso, por exemplo, de cartões de cores diferentes ou raias diferentes no board.
ENCONTRO 3 — TORNAR AS POLÍTICAS EXPLÍCITAS
§ Tarefas
o Elaborar as políticas do fluxo de trabalho;
o Tornar as políticas públicas.
§ Resultados esperados
o Políticas definidas e publicadas no board virtual do time de desenvolvimento.
ELABORAR AS POLÍTICAS DO FLUXO DE TRABALHO
Conforme apontado no relato sobre o primeiro encontro do projeto Missão Kanban, o time seguia o framework Scrum e possuía um fluxo de trabalho focado no downstream. Este foco na entrega também estava evidenciado nas políticas do time.
Enquanto o time possuía uma política de Definition of Ready (DoR) para os itens de trabalho e esta política validava todo o fluxo de upstream apenas no momento da planning, haviam duas políticas de Definition of Done (DoD), sendo uma para os itens de trabalho, outra para a Sprint e Release, conforme imagem abaixo:
A política de DoR e as políticas de DoD tinham um fator em comum: eram validadas no final da sua etapa no fluxo. Algo que fazia sentido quando falávamos de validação de sprint e release, mas que deixava alguns gaps a respeito da validação dos itens de trabalho, uma vez que, por exemplo, a prática de code review só era validada depois que o item já havia sido testado.
Estas políticas fizeram sentido na época em que foram implementadas, uma vez que a proposta do time era atuar com uma metodologia de entrega com timebox, mas o desafio proposto pela Missão Kanban trouxe a necessidade de revisar e atualizar estas políticas para que o time passasse a ser orientado a um fluxo contínuo de entrega.
Em seu livro sobre Sistema Kanban, David Anderson diz que é “importante entender o processo como um conjunto de políticas que governam o comportamento e que estão sob controle gerencial”. Desse modo, o primeiro passo foi acordar com o time que esta etapa envolveria apenas as políticas que estariam dentro do seu alcance e da Gerência imediata. Para efeito de contexto, o processo de Gestão da Mudança é orientado por uma política organizacional e centralizado pelo time de Governança, ou seja, não faz sentido despender esforços em definir uma política do time para este processo.
Alinhamento feito, chegou a hora de formalizar as regras do jogo. Neste exercício, percorremos o board virtual definindo uma política de trabalho para cada etapa. Como o Sistema Kanban utiliza um sistema puxado, elaboramos as políticas considerando sempre a visão da etapa posterior. Isso é, ao invés de perguntarmos “O que preciso para garantir que a etapa foi concluída?”, a pergunta que o time fazia era: “O que preciso para que o item de trabalho esteja pronto para ser puxado para a próxima etapa?”. Ou seja, o objetivo não era termos uma visão “Done” da etapa em si, mas sim trabalhar em uma visão de “Ready” para a etapa posterior.
Além de auxiliar no desenvolvimento de uma visão de sistema puxado dentro do nosso fluxo de trabalho (e criar esta cultura dentro do time), atuar com esta visão de “Ready”, também gera um sentimento de co-responsabilidade, uma vez que deixa claro que o objetivo de conclusão de uma etapa está relacionado ao início do trabalho da etapa seguinte.
Abaixo as políticas geradas pelo time para as etapas do fluxo de trabalho:
Neste primeiro momento focamos apenas nas políticas para puxar itens de trabalho dentro do fluxo. Políticas para classes de serviço e escalonamento serão vistas em um outro momento.
TORNAR AS POLÍTICAS PÚBLICAS
Com a conclusão da dinâmica, as políticas foram inseridas na ferramenta que utilizamos como board virtual, afinal, sempre vale lembrar que o board Kanban deve ser algo visual, ou seja, as políticas de trabalho devem estar expostas para que todos possam ver e entender o fluxo de trabalho do time.
APRENDIZADOS ADQUIRIDOS NO ENCONTRO
§ A melhor maneira de definir uma política de Done de uma etapa é usar a visão de Ready da etapa posterior;
§ As políticas do fluxo de trabalho evidenciam um comportamento colaborativo do time de desenvolvimento;
§ Com o passar do tempo, mudanças nas políticas podem ser necessárias, porém não podem ser constantes pois geram mudanças na operação e o desempenho do sistema;
§ Kanban é um processo definido por um conjunto de políticas que governam a operação do sistema;
§ Mudanças nas políticas para puxar associadas a um conjunto de classes de serviço podem ser feitas sazonalmente para lidar com flutuações na demanda.
Muito obrigado a todos que chegaram até o fim deste post, e até a próxima semana, quando falaremos sobre o 4º encontro com o time.
AGENDA DE POSTAGENS
- 17/06/2020 — Seção 1 (Idealizando a Missão: Kanban) — Leia aqui!;
- 24/06/2020 — Encontro 1 (Mapear o Fluxo de Trabalho) — Leia aqui!;
- 01/07/2020 — Encontro 2 (Estabelecer as Classes de Serviço) e 3 (Tornar as Políticas Explícitas);
- 08/07/2020 — Encontro 4 (Limitar o Work in Progress); e
- 15/07/2020 — Encontro 5 (Gerenciar o Fluxo de Trabalho) e Seção 3 (Considerações Finais e Próximos Passos).
