Organisation agile ops

Bonjour le monde :slight_smile:

je viens de rentrer dans une boite qui a une équipe ops qui se veut agile avec une utilisation de SCRUM (JIRA) dans toutes les taches. Le principal projet, qui est la mise en place d’une nouvelle plateforme totalement indépendante (un gros cluster KUBE avec un portail pour les projets qui vont tourner dessus), me semble adapté à SCRUM bien l’équipe de “dev” (les ops quoi) soit assez disparate (sysadmin, réseau, archi, …) et donc les US ne peuvent pas être prise par n’importe quel membre de l’équipe, se qui me semble opposé à la philosophie de SCRUM.
Le produit vient d’être mis en production et les tickets utilisateurs commence à tomber (euphémisme). L’équipe a été divisé de façon assez flou en RUN et BUILD (ITIL !!!) et donc le RUN est en charge de gestion des incidents/tickets. Je ne trouve pas que SCRUM soit adapté à ce fonctionnement.
Avez-vous des conseils/REX sur ce type d’orga ?

Merci de vos réponses.

Tu peux regarder du côté des squads agile, je n’ai pas pratiqué, mais c’est une solution (la seule “officielle” que je connais) qui résout les problématiques d’interaction entre équipe dans une grande structure composée de plusieurs équipes agile en mode scrum.

Pour moi, le scrum, c’est pas agile.
Y a un taff à faire (un ticket), une fois qu’il est fait et validé, ça part en prod. Pas besoin d’attendre un “sprint” qui n’est au final qu’un cicle en “V” de quelques semaines.

Il n’y a pas d’obligation d’attendre la fin du sprint pour mettre en prod, dans mon dernier boulot on faisait 1 à 2 MEP par semaine malgré un sprint de 3 semaines.

Le concept de squad est intéressant (merci pour la découverte) mais j’ai un peux de mal à voir l’adaptation à mon environnement.Je suis plus à la recherche de retour d’équipe ops travaillant en agile (SCRUM, KANBAN, Scrumban, …) et comment elles ont adapté ces méthodes à leurs besoins. Entre autre , le Scrum me semble inadapté à la gestion d’incident (ne pas confondre avec un bug dans une équipe de dev). Comment les équipes plateformes fonctionnent serait intéressant.

En vrai, tu n’es pas obligé de respecter la méthodologie à la lettre, s’il y a un point qui te dérange. Tu as le droit de l’adapter.

J’aime faire le distinguo entre le travail planifié, comme des évolutions, nouvelles fonctionnalités, maintenance (mise à jour du cluster par exemple), et le travail non planifié comme des incidents de prod, ou toute autre interruption.
Pour le travail planifié, SCRUM peut être utilisé. Pour le non-planifié, un KANBAN, avec lequel on gère une capacité dans la ligne “en cours” fonctionne mieux.
Quid des équipes qui font les deux ? C’est simple: pour toi, une équipe build aura un profile du type 80% planifié, et 20% non planifié. Une équipe run aura un profil inverse. À ajuster bien sûr.
Voilà comment je réconcilie les deux.

1 « J'aime »