Dans cet épisode, nous essayons une nouvelle organisation où l’OPS prend une casquette de formateur, d’accompagnateur et de point de contact privilégié pour les équipes de dev.
J’ai testé pour vous “l’OPS en tant que point d’entrée/sortie du SI”
Le modèle d’organisation
La production ne peut pas se passer de certains processus quand le nombre des équipes de développement devient de plus en plus grand. Les demandes se multiplient, les besoins se diversifient en fonction des technologies choisies et des contraintes métier.
Toujours dans le même contexte client (cf. épisodes 1, 2 et 3), la vélocité de l’équipe OPS ne répondait plus aux attentes du métier. Les produits de l’équipe transverse nécessitant une plus forte interaction entre les architectes, data scientists et ops. Le management a décidé de refondre les équipes, et de ne plus distinguer les ressources humaines par profil : archi, dev, testeur, ops, etc, mais par produit.
Par exemple : un produit « Plateforme » a vu le jour, et l’équipe était constituée de profils différents travaillant sur la création du socle hébergeant les applications. Un autre produit « Sécurité » a également vu le jour, et l’équipe était constituée du RSSI, d’un architecte, d’un développeur et d’un OPS à titre d’exemple.
Mais pour répondre aux demandes métier / dev / management, il fallait bien avoir des points de contact, des personnes à disposition pour pouvoir adresser ces demandes et être en support. Une nouvelle équipe a vu le jour, composée de 7 profils support IT, architectes, OPS, un responsable d’équipe et un scrum master à mi-temps, et organisée en Kanban pour une vingtaines de projets de développement.
Objectifs : Être le point d’entrée et l’accompagnateur des équipes projets avant le démarrage des développement jusqu’à leur donner la main sur leur RUN, traiter leurs demandes des plus simples et processées aux plus complexes et au plus challengeantes, et faire le relai entre les équipes de développement de produits métier et les équipes de développement de produits transverses du socle technique.
Les avantages
Pour les tâches de Build, nous avons défini des releases tous les 2 mois, en priorisant de grands chantiers en concertation avec les produits de la plateforme (infra, data, archi). La priorisation se fait au fil de l’eau, en fonction de la charge de run. Un sens de responsabilité et un engagement fort sont des prérequis indispensables au bon fonctionnement de ce mode d’organisation. Les chantiers de build étaient portés par des référents dans l’équipe, et le daily permettait de solliciter les autres pour une aide ponctuelle.
Le framework Kanban apporte une réelle souplesse, et une adaptation quasi quotidienne aux charges de build et de run. La force de cette méthodologie de travail est que la rigueur de priorisation, de structuration des tâches sous forme de tickets dans un backlog et de reporting d’activité ne sont pas perdues par rapport à Scrum.
Pour le run, un référent et son backup ont également été désignés pour chaque ensemble d’applications. Ainsi, nous limitons le turnover pour l’application en face, qui connaît son interlocuteur privilégié, et les membres de l’équipe proposaient un accompagnement aux petits soins ! Et pour accentuer le partage et le challenge, les référents tournaient toutes les 2 à 3 releases.
Les limitations
L’idée d’un « Backup » pour un référent OPS sur un périmètre métier ou applicatif paraît une bonne idée sur le papier, mais sur le terrain, chacun est pris dans son quotidien entre les réunions, les points d’équipe, les demandes et sollicitations en tout genre, et le build qu’il ne faut pas négliger. Quand le référent s’absentait, cela se ressentait tout de suite sur la satisfaction client, le délai de traitement des tickets, et les connaissances n’étaient pas partagées convenablement.
Pour remédier à cette limitation, nous avons désigné 1 référent et 1 contributeur pour plusieurs applications. Au lieu d’avoir une ressource « au cas où », on avait une ressource active et présente dans les réunions et les échanges. Le binôme s’organise selon ses envies et ses domaines d’expertise pour traiter au mieux l’accompagnement des projets. Ce binôme était tout aussi bien pour traiter le build que pour traiter le run.
Enfin, tout le monde n’a pas la sensibilité au métier de l’OPS, on ressent rapidement des différences entre une équipe accompagnée par un référent avec un background en développement et une autre accompagnée par un référent avec un background production/exploitation. Les sujets mis en avant, les traitements de certaines demandes n’étaient pas de la même qualité et n’avait pas la même implication de la part de celui ou celle qui traitait.
Un mini bilan de cette organisation
Toujours avoir un coordinateur (Service Delivery Manager) à portée de main ! Il permet de réguler les sollicitations et créer des moments d’équipe pour faire baisser la tension du quotidien (cf. épisode 3)
Même en Kanban, et malgré toute la bonne volonté des personnes, des moments de rétrospective sont nécessaires pour faire baisser les tensions.
La polyvalence est un très bon point dans l’équipe, mais le maintien d’une cohérence technique ou d’architecture n’est pas un réflexe et on peut très facilement dévier en essayant de répondre à un besoin d’une équipe de développement. Les releases review et autres moments de partage de problématiques techniques comme des ateliers de conception ne sont pas à négliger.
On ne le répétera jamais assez, mais sans une équipe engagée, motivée, polyvalente sur le découpage, la réalisation, l’engagement client, rien de tout cela ne peut être mené correctement.
Comme toute équipe en Kanban, le build est pénalisé vis-à-vis du run s’il n’y a pas de rigueur dans le switch et dans la limitation des sollicitations. L’auto-organisation n’est pas aisée à atteindre et n’est pas donnée à toutes les équipes, alors gardez un Service Delivery Manager à portée de main, c’est bien utile :-).