Classes de serviços no desenvolvimento de software

Uma das premissas quando você está usando o método Kanban (com K maiúsculo) é usar as chamadas Classes de Serviços.

No livro “Kanban: Successful Evolutionary Change for Your Technology Business” David Anderson usa a fila de check-in de um aeroporto para exemplificar o que são classes de serviço:

Caso você tenha pago mais pela passagem (seja da classe executiva por exemplo) ou faz parte de algum programa de fidelidade de cartão de crédito, você terá prioridade maior na fila e passará mais rápido por essa etapa do processo.

Agora trazendo para o nosso mundo de desenvolvimento de software vamos pensar em resolução de defeitos em produção. Uma coisa é certa, em todo projeto de software (que tenha alguém usando), os defeitos irão aparecer e alguns deles necessitam que exista uma resolução mais rápida possível, em alguns lugares mais conhecido como “apagar incêndio”.

O termo apagar incêndio é muito mal visto em nossa área, porém isso não faz com que ele não exista, pelo contrário, cenários de urgência sempre irão existir. É claro que devemos entender os problemas e tentar solucioná-los para que não ocorram novamente, mas esse não é o tema desse texto e sim como usar classes de serviços do Kanban para ajudar a apagar os incêndios de seu projeto.

Há um tempo atrás em uma equipe que eu atuava como agile coach estávamos enfrentando exatamente a questão do apagar de incêndios e isso começou a atrapalhar o dia a dia da equipe em vários sentidos:

- O Product Owner da equipe se sentia constrangido em pedir para a equipe parar o que estava fazendo e atuar na solução de algum defeito que ganhou prioridade.
- A equipe, como estava focada em suas atividades além do abrupto chaveamento de contexto, acabava não puxando da forma mais rápida aquele defeito (Sim, tínhamos uma problema de comunicação também).

Com isso resolvemos mudar um pouco como o processo funcionava, primeiro criamos a classe de serviço Expedite em seguida combinamos com a equipe (formada por quatro desenvolvedores e qa), que a cada semana um deles seria o responsável por atuar nessa classe de serviço. Assim, quando algum cartão chegasse como Expedite, o Product Owner atribuiria a essa pessoa a missão de fazer com que esse cartão entrasse e saísse do nosso fluxo o mais rápido possível. Não necessariamente ela atuaria no problema mas sim asseguraria que ele seria resolvido.

Com essa mudança, em pouco tempo conseguimos verificar uma grande melhora em todo o processo e também na relação entre Product Owner e o time de desenvolvimento.

O resultado disso poder ser visto comparando os dois gráficos abaixo. O primeiro mostra o lead time dos cartões que não tinham a classe de serviço Expedite e o segundo mostra os cartões classificados com essa classe.

Trade-off usando Expedite

Usando Classes de Serviço como o Expedite temos uma penalização nos cartões com classes de serviços menos prioritárias (exemplo seria User Stories), podemos ver isso claramente com o aumento do lead time dessas tarefas.

Próximos passos

Temos testado outras formas de lidar com o Expedite, uma delas é o desenvolvedor que estiver responsável naquela semana para resolver os cartões Expedite não poder puxar nenhuma outra classe de serviço a não ser essa. Ok, mas e se não houver nada em Expedite? O desenvolvedor atua em dívidas técnicas que a equipe tem mapeado.