Muitas pessoas e organizações quando vão procurar algum modelo de gerenciar seus serviços e processos, pensam que ITIL e Scrum não podem funcionar juntos. Mas será que é isso mesmo?
Várias vezes por semana podemos ter uma nova versão de produção e muitas vezes mudando requisitos e prioridades. Isso é o dia a dia em ambientes ágeis. Mas no final do dia, os gestores e profissionais acabam ficando com diversas dúvidas, por exemplo:
- Como essa abordagem de entrega de projeto (geralmente: SCRUM) se encaixa nos processos existentes de Gerenciamento de Serviços de TI (normalmente: ITIL)?
- Como administramos, por exemplo, o crescente trade-off entre flexibilidade e estabilidade?
- Como podemos garantir que os requisitos de serviço operacional sejam refletidos em uma fase inicial de um projeto ágil?
- Como papéis ITSM e papéis SCRUM se juntam?
- ITIL e SCRUM podem coexistir? Sim, definitivamente!
ITIL e SCRUM não se contradizem. Não há incompatibilidade. O SCRUM é uma maneira específica de fornecer projetos, é uma abordagem iterativa, adaptativa e incremental para o gerenciamento de projetos. ITIL é sobre o melhor gerenciamento de serviços de TI. É uma coleção holística de ideias e processos sobre como definir, projetar, fazer a transição, executar e, finalmente, melhorar continuamente os serviços (-> esse é o ciclo de vida do serviço).
A ITIL leva em consideração o ponto de vista operacional, reconhecendo que o valor para o cliente é entregue durante a operação de serviço e, portanto, os requisitos operacionais devem ser refletidos em uma fase inicial do Desenho de Serviço. ITIL é agnóstico em qual metodologia PM é usada. Então ITIL e SCRUM são bastante complementares. Semelhante se você olhar para ITIL e Prince. O desafio é como os dois interagem.
Como eles se encaixam?
Scrum e ITIL
ITIL e SCRUM se encaixam perfeitamente em alto nível. Do ponto de vista da ITIL, o SCRUM começa com o Service Design e termina com a entrega de um produto ou serviço (iniciado várias vezes).
- Design de Serviço: A partir do caso de negócios aprovado, os requisitos são reunidos em forma de histórias de usuário e priorizados. O resultado é o backlog do produto priorizado.
- Transição de Serviço: Isso é feito através de sprints com timebox (geralmente entre 1 à 6 semanas em cada sprint). Cada sprint começa com uma reunião de planejamento de sprint, na qual as histórias de usuário são incluídas para o próximo sprint.
As reuniões diárias em pé ajudam a acompanhar o progresso e a eliminar os impedimentos. O sprint termina, por um lado, com a reunião de revisão do sprint, na qual o novo / alterado serviço ou produto é formalmente aceito. Por outro lado, há a Reunião do Retrospectiva da Sprint, que resulta nas lições aprendidas
Quais são os desafios?
Não esqueça de operações!
Um problema com projetos puramente baseados em SCRUM é que eles não se importam com a Operação de Serviço e se concentram muito no utilitário (requisitos funcionais) de um novo produto ou serviço. Soluções são descartadas e, especialmente, os aspectos de garantia de um novo serviço (capacidade, disponibilidade, segurança e continuidade) não são levados em consideração e, no final da cadeia, o serviço não entrega seu valor.
O DevOps fornece algumas ideias sobre como resolver isso. Uma das grandes contribuições do ITIL é que esses aspectos operacionais já estão refletidos em um estágio inicial da fase de Design de Serviço. Aplicado ao SCRUM, isso significaria que, já durante a criação de Histórias do Usuário e o Backlog do Produto, esses requisitos são reunidos. Durante o sprint, as equipes que cuidam desses aspectos (por exemplo, infraestrutura) precisam fazer parte do Time Scrum.
Do ponto de vista operacional, o Gerenciamento de Mudanças age como um protetor do ambiente produtivo, identificando os riscos de cada mudança e evitando impactos negativos. Em termos mais gerais, você pode colocar todas as alterações em um item de configuração em Controle de Mudanças (por exemplo, lista não processada do produto, que é criada no design de serviço).
O Controle de Mudanças também é um grande tópico no SCRUM, por exemplo, cada sprint termina com uma reunião de revisão de sprint, na qual o proprietário do produto revisa e aprova o sprint. Ou no Service Design, o proprietário do produto atua como um gatekeeper para cada história do usuário (controle de alterações sobre os requisitos).
Então, colocando essa imagem juntos, há muitos casos de controle de alterações.
Quanto controle de mudança você precisa?
Equilibrar flexibilidade e estabilidade através de modelos de delegação e alcançar um ambiente de serviço controlado
Para alcançar o equilíbrio certo entre flexibilidade e estabilidade, é fundamental:
- decidir o que você deseja colocar sob controle de mudanças e
- além disso, aplicar os modelos de delegação corretos. Por exemplo:
- O controle de Mudanças do Product Backlog é delegado ao Product Owner: as equipes de Operação de Serviço também devem estar envolvidas para garantir que os requisitos operacionais de garantia também sejam incluídos nas histórias do usuário;
- O Controle de Mudanças sobre os resultados do sprint é delegado ao Product Owner e, caso o sprint seja incluído em uma versão futura, o CAB operacional regular, age como um aprovador também;
- O Controle de Mudanças sobre o Backlog da Sprint é delegado ao Dono do Produto, ao Time Scrum e ao Scrum Master e à Equipe de Planejamento da Release regular.
Usar metodologias ágeis de projeto significa lançamentos frequentes. O teste pode se tornar uma dor real. Isso se refere menos ao teste de nova funcionalidade, mas sim ao teste de regressão (verificando se a funcionalidade existente foi afetada por uma nova versão, repetitiva). Automatizar os testes de regressão é fundamental. As equipes de fábrica de teste precisam ser envolvidas desde o início e, com base no backlog do produto, os casos de teste de desenvolvimento precisam ser desenvolvidos e automatizados.
Integrando funções e papéis de SCRUM e TI
Scrum e ITIL
- Proprietário do Serviço ITIL e Proprietário do Produto SCRUM: Se falarmos sobre serviços existentes, faz sentido que as duas funções sejam incorporadas na mesma pessoa. Ambas as funções atuam como uma voz do cliente e conhecem o lado das necessidades. No lado do software, isso geralmente é representado pelo proprietário do aplicativo.
- Gerenciamento de Mudanças: O Scrum Master e o Product Owner precisam fazer parte do CAB se for o lançamento de um sprint. O Product Owner atua como aprovador do CAB a partir de um ponto de vista do backlog do sprint.
- CSI Manager e Scrum Master: O aprendizado contínuo é um conceito integral no Scrum: Em reuniões retrospectivas de sprint, melhorias de processo são identificadas. Nas reuniões diárias, os impedimentos que impedem o sucesso são eliminados. Tudo isso está acontecendo sob responsabilidade do Scrum Master. Melhorias estruturais fora do processo Scrum devem ser consideradas a partir da perspectiva geral de desenvolvimento organizacional e tornar-se parte do registro CSI, portanto, o Scrum Masters e o CSI Manager devem entrar em contato regularmente.
Conclusão
Entendeu como ITIL e SCRUM podem atuar juntos? Se você quer ficar mais por dentro de conteúdos como esses, se cadastre na nossa newsletter semanal! Clique aqui.
