Sempre li vários artigos falando da união do ITIL com o SCRUM. Vários autores falam sobre conceitos e práticas das duas metodologias, mas compartilho aqui um case de sucesso em que as duas metodologias são fundamentais para funcionamento de uma Software House.
Imaginemos um cenário de uma Software House que trabalha com desenvolvimento de E.R.P., em que o produto da empresa sofre mudanças e implementações diariamente, a empresa conta com uma equipe pequena de programados e seu Service Desk com uma forte demanda de incidentes, afetando diretamente o Kanban do SCRUM.
Pois bem, a ITIL talvez seja a metodologia ideal para blindar os prazos do SCRUM. Através das melhores práticas de Gestão da ITIL, é possível gerir e priorizar a demanda das ocorrências denominadas como incidentes e problemas.
Vejamos como, através das perguntas e respostas a seguir.
É preciso mensurar o número de incidentes? Entender a capacidade de processamento da equipe sobre esse número de incidentes?
Nesse cenário tão conturbado, todos programadores trabalham com incidentes e melhorias ao mesmo tempo, e não há uma definição de prioridade e prazo para interrupções, onde tarefas mudam de prioridade a todo momento. Este é um típico problema que as empresas que não contam com uma metodologia enfrentam.
Baseado nesse cenário, podemos ver que o SCRUM não consegue resolver esse problema sozinho, por quê toda a equipe trabalha com incidentes/melhorias simultaneamente, pois todos estão comprometidos com a SPRINT e as interrupções estão afetando todo SCRUM TEAM, sendo assim, primeiro é preciso acabar com o grande número de interrupções sobre toda equipe.
A solução a ser adotada para este caso é eleger um “Bombeiro” para tomar conta somente dos incêndios, onde será responsável por todos Problemas/Incidentes; esse membro não entrará no SPRINT e, portanto, suas tarefas não serão pontuadas.
Mas o “Bombeiro” irá suprir toda demanda?
No cenário acima a empresa trabalha com um E.R.P. que constantemente sofre novas implementações, geradas, por exemplo, a partir de solicitações feitas diariamente por clientes. Certamente sempre haverá incidentes, então, é necessário saber geri-los, entender o Product Backlog e criar uma ordem para execução (Priorizar) sobre o baseline.
E os incidentes que demandam grande tempo para serem solucionados, o que fazer?
Como o próprio nome já diz – “Bombeiro”, o mesmo não poderá apagar um grande incêndio sozinho e depois tomar medidas para que o fogo não volte a ocorrer. Haverá casos em que o “Bombeiro” deverá emitir uma Solução de Contorno para apagar o incêndio; já a solução definitiva poderá ser encaminha para o Product Backlog, onde o P.O. (Product Owner) definirá em qual SPRINT será executada.
Essa medida é fundamental para o sucesso do modelo, pois já que os incêndios aparecem a todo momento, o “Bombeiro” não pode ficar trabalhando muito tempo na solução de um caso, pois irá gerar uma grande fila, colocando a perder todo o processo…
Mas se o “Bombeiro” entender que não há mais grandes incêndios, o que fazer?
O “Bombeiro” deve investigar o que gera os incidentes, estudar o Product Backlog, identificar a causa raiz das tarefas, fazer a análise dos gaps (mudanças bruscas), criar soluções definitivas sobre os problemas, aportar melhorias para que o SCRUM TEAM trabalhe em soluções que evitem novos incidentes e/ou problemas.
O “Bombeiro” será um membro fixo ou haverá rodízio?
Ao contrário da profissão em que o bombeiro vive para salvar as pessoas e faz um juramento para fazer isso pelo resto de sua vida como vemos em filmes, na área de T.I isso é muito difícil, pois o “Bombeiro” da T.I. não conseguirá apagar fogo pelo resto de sua vida. Para que não fique tão estressante e desmotivador, é recomendável fazer um rodízio entre os membros da equipe para atuar como “Bombeiro”. A escolha do membro deve ser baseada no conhecimento técnico e características do Product backlog, assim aumentado a eficiência das soluções.
Quais os benefícios da rotatividade do “Bombeiro”?
Há uma série de benefícios:
- Empatia talvez seja o mais importante, pois esse sentimento será estimulado no decorrer do seu mandato de “Bombeiro”, pois é nesse período que irá se deparar com problemas muitas vezes gerado por ele próprio.
- Relacionamento, pois o uso das duas metodologias aplicando o conceito do “Bombeiro” estreita o relacionamento entre a equipe de atendimento e desenvolvimento, quebrando o paradigma de Suporte versus Desenvolvimento, colocando as equipes no mesmo banco e remando para o mesmo lado.
- Disseminação do conhecimento, porque com o “Bombeiro” não participando do SPRINT, a equipe precisará assumir tarefas que certamente iriam ser de responsabilidade do membro que está eleito como “Bombeiro”; desta forma, os SCRUM TEAM estarão absorvendo conhecimento através da responsabilidade forçada de tarefas em que ainda não são especialistas.
Caso você tenha algo a complementar ou alguma observação ou mesmo se discordar de algo, por favor, deixe seu comentário abaixo.
Um grande abraço!
