Olá amigos do PTI,
Sempre abro meus cursos de Scrum dividindo a turma em grupos e pedindo que cada grupo elenque 3 perguntas que gostariam que fossem respondidas no decorrer do curso. Uma das perguntas que recebi foi um tanto interessante e curiosa: “Como unir o ITIL com Scrum?“.
No último dia de aula um dos alunos me cobrou: “Vitor, você ainda não falou sobre ITIL com Scrum!”. Resolvi então, entender melhor o contexto da pergunta, pois o ITIL cobre uma série de processos de gerenciamento de serviços de TI e precisava saber em qual processo esse aluno gostaria de visualizar a aderência.
Imagem via Shutterstock
O cenário descrito foi esse: “Minha empresa tem uma área de sustentação de TI que trata um backlog de melhorias acordado e priorizado com o usuário, porém, essa priorização sofre alterações toda hora, pois os incidentes são prioritários e geram atraso nos itens do backlog. Como o Scrum ajuda a resolver isso?”
Fiz algumas perguntas para entender o cenário: “Qual o volume de incidentes? A equipe que cuida desse backlog de melhorias, cuida também dos incidentes?”
Obtive como respostas: “Alto volume de incidentes e a mesma equipe cuida das melhorias e incidentes”.
Num cenário como este o Scrum em nada vai ajudar, pois por mais que se estabeleçam Sprints quinzenais (por exemplo), o Product Backlog será mutável, a prioridade irá mudar toda a hora.
Para funcionar precisamos quebrar alguns paradigmas: Sustentação é melhoria evolutiva e incidente é incidente. Vejo muitos gestores associarem a palavra sustentação à incidentes, problemas, erros: “Não vou pagar ou manter uma equipe só para acudir problemas”, dizem alguns gestores. Outros, por sua vez, incentivam esse tipo de prática: “Precisamos ter uma equipe para acudir o dia-a-dia”.
Minha opinião? Não existe essa história de “acudir o dia-a-dia”! Os sistemas devem ter vida própria, dependendo do mínimo de intervenções humanas. E a sustentação sempre irá existir, uma vez que todo o software vive em constante processo de evolução para atender as necessidades de negócio, necessidades dos stakeholders e necessidades tecnológicas. Um sistema não nasce e fica imutável para o resto da vida.
“Tá bom Vitor, mas como o Scrum resolve isso aí?”
Antes de falarmos em Scrum, vamos dar uma reestruturada na equipe. Alocar um ou dois membros da equipe para atuar somente nos incidentes. Atuar no incidente significa “tirar o boi do meio da estrada”, porém, alguém precisa garantir que o “boi não vai parar no meio da estrada novamente”. Quem garantirá? Cada vez que um incidente for detectado, cria-se um item de investigação e atuação na causa-raiz para ser catalogado no Product Backlog, priorizado pelo Product Owner e cuja atuação será do restante da equipe de sustentação.
O Product Backlog conterá somente itens de melhorias evolutivas e itens investigativos levantados pela equipe de incidentes. Estas melhorias e itens investigativos poderão ser desenvolvidos em Sprints fixas, gerando entregas únicas e evitando a geração de intermináveis e ingerenciáveis Ordens de Serviço ou RFCs (Requests For Changes).
Este conceito de pessoas atuando pontualmente em incidentes (“bombeiros”) e pessoas atuando em Sprints abrangendo melhoras evolutivas é abordada de maneira soberba no livro “Scrum e XP Direto das Trincheiras” de Henrik Kniberg.
“Mas Vitor, como não desmotivar o cara que fica resolvendo só incidente?”
É interessante utilizar um sistema de rodízio, cada semana ou cada mês troca-se o responsável pela atuação em incidentes. Porém, a abordagem de incluir um item investigativo no Product Backlog garante que a causa-raiz do incidente seja analisada e resolvida e, com isso, a tendência é que os incidentes diminuam drasticamente até não haver esta necessidade da equipe de “bombeiros”.
Abraços e até o próximo artigo ! 🙂
6 Comentários
E aí Vitor, tudo bem? Bacana seu artigo.
Gostaria de comentar que o texto parece deixar de lado a gestão de problemas e faz uma ponte direta entre gestão de incidentes e desenvolvimento de melhorias – ou deixa subentendida a gestão de problemas. Quando a organização tem maturidade em gerenciamento de serviços com certeza atua com gerenciamento de problemas.
Incidentes, como você bem sabe, são eventos que não prevemos e impactam nossa operação de alguma forma – ou o funcionamento de um software. Apagar o incêndio e tirar o boi da estrada pode ser, PODE SER, trabalho da equipe de gestão de incidentes – mas o gerenciamento da manutenção evolutiva acaba por se tornar responsabilidade do gerente de desenvolvimento em uma organização que atua com prestação de serviços por meio de softwares.
Digo PODE SER porque, em termos gerais, a não ser que quem presta o suporte tenha conhecimento técnico, o incidente vai ser registrado e escalonado funcional ou hierarquicamente e ficará sob os auspícios da gestão de problemas. A comunicação, neste ínterim, continua sob o escopo de atuação da gestão de incidentes.
Gostaria de agregar a resposta oferecida por ti o seguinte: não está boa esta relação porque não foi bem pensada. Deve-se remover a gestão de incidentes desta conexão direta com a área de manutenção e criar uma área intermediária de gestão de problemas. A identificação da causa raiz e o mapeamento de erros conhecidos e o gerenciamento das melhorias é trabalho da área de gestão de problemas em conjunto com a área de dev (ou manutenção evolutiva). Você precisa, em último caso, agregar as atividades do gerente de dev o papel de gerente de problemas.
Bom, estou tentando ajudar. Sei que cada resposta é um desafio e você entende melhor do que eu o cenário apresentado pelo seu aluno, até porque foi uma pergunta direcionada a você.
Parabéns pelos teus textos. Gosto muito de todos!
Desejo o melhor para todos e muito sucesso,
Frederico Aranha, PMP, ITIL Expert
[email protected]
Alias, complementando: seu gerente de desenvolvimento/produto/manutenção pode ser seu Owner. Tudo vai depender do jogo de papéis. Espero ter colaborado e, principalmente, entendido o cenário! 🙂
Ola, Vitor, parabéns pelo artigo, muito bom!
Queria aproveitar a boa colocação Frederico, excelente introdução do processo de Gestão de Problemas no assunto, pois é um processo que traz um grande retorno sobre os investimentos, mas não é frequentemente utilizado nas empresas.
Só queria discordar da colocação do Frederico em relação a “.. remover a Gestão de Incidentes dessa conexão direta com a área de manutenção..” pois na minha opinião, na prática isso não vai ocorrer, porque tanto as pessoas de suporte que vão solucionar os incidentes quanto as pessoas de projetos, que vão tratar do Backlog normalmente estão sob a gestão da mesma pessoa.
Já vi estruturas organizacionais que tentaram separar essas equipes, criando equipes de sustentação dos serviços e equipes de projetos sob gerencias diferentes, mas como o investimento para fazer isso é alto, não é uma situação fácil de encontrar. Na prática a estratégia que inicialmente parece boa, após um tempo se mostrou ineficiente pela falta de transferência efetiva de conhecimento entre essas equipes na transição dos projetos para a fase de operações.
Então, para mim essa interação do processo de incidentes com os equipes de manutenção sempre vão existir, mas claro de forma diferente da interação com o processo de Problemas.
Obrigado e um abraço,
Ricardo Canalonga.
Olá Frederico,
Primeiramente desculpas pela demora em minha resposta pois estava ausente da cidade.
Muito obrigado por contribuir com seu rico comentário e ponto de vista.
A ideia deste artigo é justamente como o Scrum pode ajudar em empresas/situações que não possuem a maturidade em separar gestão de incidentes de gestão de problemas.
O mundo ideal e de acordo com as boas práticas realmente seria com cada “macaco no seu galho”: gerência de manutenção com melhorias evolutivas, gerência de incidentes com incidentes e gerências de problemas com análise de causa-raiz, mas nem sempre este cenário é uma realidade e devemos lançar mão do “tailoring” ou “tailor-made” que consiste em utilizar um pouquinho de uma prática aqui, um pouco de um framework ali e criar um cenário que seja eficiente e eficaz para a melhoria do cenário atual !
Forte abraço,
Vitor
Grande amigo Ricardo,
Fico muito feliz com seu feedback, principalmente por você ser um grande especialista na gestão de serviços de TI !
Forte abraço,
Vitor
Ou seja, empresas que não se estruturam para usar o Scrum, logo não podem usar o scrum porque só vai dar caca.
Bom SABER!