O scrum ou o kanban é realmente útil para as equipes de SRE?

Práticas ágeis como scrum e kanban foram projetadas principalmente para o desenvolvimento de software.

O trabalho interrompido e não planejado é um componente significativo do que a maioria das equipes de SRE ( Site Reliability Engineering ) ou DevOps faz. Embora seja sempre útil usar um sistema de rastreamento como o Jira para gerenciar o trabalho, o sprint ou o kanban realmente funcionam para as equipes do SRE?

As restrições que vejo são:

• O trabalho é de natureza muito dinâmica, com prioridades mudando diariamente. Por esse motivo, a duração do sprint de duas semanas parece muito agressiva e acrescenta sobrecarga desnecessária.
• As pessoas que estão de plantão adicionam outra dimensão ao problema. Às vezes, mais de um membro da equipe pode se envolver em tarefas de plantão / post-mortem.
• A equipe não possui um único "produto" e, portanto, não se entrega a um processo de planejamento comum
• As reuniões stand-up diárias podem não fazer muito sentido devido à falta de sobreposição entre as tarefas
• A equipe pode estar trabalhando em tarefas relacionadas a mais de uma equipe parceira e, portanto, abrangendo vários projetos Jira. Como uma placa de sprint ou kanban permite apenas um projeto Jira, pode não ser capaz de caber em todo o trabalho.

Pelo que ouvi de muitos SREs com quem falei, o planejamento de sprint não funcionou para eles. Gostaria de ouvir da comunidade aqui qual é a experiência deles com o sprint e o kanban.

Também fiz essa pergunta no scrum.org:

O scrum pode ser usado efetivamente pelas equipes de SRE?

Nós não usamos o Agile para o grupo DevOps, mas nos integramos às equipes normais de Scrum. Quando algo é necessário pela equipe do DevOps, como otimizar o servidor de compilação, a equipe relacionada coloca um PBI em seu backlog com um rótulo 'DevOps'. Nosso lead possui um painel personalizado em Jira com todos os problemas rotulados como 'DevOps'. Eles trabalham com o Scrum Master para obter a priorização e, em seguida, um dos DevOps Engineers é encarregado de ser um membro ad-hoc da equipe Scrum pela vida útil desse problema. Isso nos ajuda a priorizar o trabalho com base nas prioridades de nossos "clientes", vincula nosso esforço ao sprint e nos permite obter "crédito" pelo trabalho que estamos realizando.

Antes disso, usamos o Kanban no Jira apenas para uma lista de tarefas. Infelizmente, às vezes precisávamos parar de trabalhar em algo que tínhamos planejado, porque uma das equipes precisava de algo. Agora, a menos que seja uma emergência, eles basicamente solicitam recursos do DevOps (pessoas / tempo) por meio do backlog e do Scrum Master comunicando essa necessidade ao nosso Lead.

O Agile funciona muito bem para esse tipo de ambiente caótico. No entanto, pelas razões que você destacou, o puro livro didático Scrum pode não ser o ideal. Como Scrum Master que faz uma boa quantidade de DevOps, usei os quadros Kanban em Jira para acompanhar o trabalho.

Vantagens do Kanban

• Visualização do trabalho que a equipe está fazendo.
• Identifica gargalos para a equipe.
• Ajuda a manter a equipe focada na mudança do trabalho.
• Permite que o trabalho seja adicionado a qualquer momento.
• Dá visibilidade ao trabalho que está sendo realizado para outras equipes que dependem dos SREs.
• Pode ser genérico para cobrir vários tipos de trabalhos.

Embora um stand tradicional não seja benéfico, considere modificá-lo. Uma boa reunião de pé destaca os bloqueadores que um membro da equipe pode enfrentar que outro membro da equipe sabe como resolver.

IMO: Sim, o Scrum pode ser usado efetivamente pelas equipes de SRE. Eu nunca ouvi ou li que os membros da equipe só podem trabalhar nos itens de trabalho do sprint; portanto, é um equívoco que você precise prestar contas de todo o seu tempo e esforço no escopo de um sprint; Além disso, sinto que há um equívoco de que todo o seu trabalho seja aplicável a sprints. Portanto, de forma convergente, você deve gerenciar algum trabalho com o Scrum e outros fora dele.

O Scrum, em sua essência, é uma estrutura (com artefatos e eventos) que é flexível e usada para melhorar continuamente a natureza do trabalho que é aceito pela equipe (ou aplicável a esse trabalho).

O que você precisa fazer é encontrar um equilíbrio entre o tempo e o esforço que você pode fornecer para o trabalho de sprint aceito e planejado que você e sua equipe podem oferecer e o tempo e o esforço para lidar com o trabalho não planejado fora do sprint.

Há uma medida de gravidade e prioridade em todos os itens de trabalho. Se você está pensando em Scrum, deve aceitar trabalhos com uma determinada gravidade. Você também deve considerar um trabalho que possa reduzir a gravidade do trabalho futuro (se possível). Eu também recomendaria que você iniciasse seus sprints com cerca de metade da capacidade (o que seria difícil de determinar, já que relacionar tempo e esforço de maneira capacitada no início) é fácil. O objetivo da sua equipe sempre deve ser oferecer o trabalho que sua equipe aceita; portanto, seja exigente e não exagere.

Eu acho que a natureza do seu trabalho é realmente comparável ao trabalho de correção de erros de produção para equipes de desenvolvimento. Portanto, convém consultar as equipes de manutenção da produção sobre a adoção e o sucesso do Scrum, e não necessariamente se limitar à experiência do DevOps Engineers no gerenciamento de programas e projetos.