Quel est donc ce métier ?
A l’origine, il y a eu Scrum Agile. De mon point de vue, un type génial a réconcilié le financier et l’informaticien.
Au financier il a dit: « Les projets vont coûter moins chers, sont livrés au fur et à mesure. Quand vous considérez que le produit est suffisant, vous arrêtez d’y mettre de l’argent ».
Au développeur il a dit: « Tu vas passer ton temps à développer et grâce à l’automatisation, tu seras déchargé de plein de tâches comme la documentation, la gestion projet… »
Cela a fonctionné un certain temps mais il y a eu quelques dérives. Par exemple les specs rédigées sur un post it forçant les équipes à courir dans tous les sens face à une maitrise d’ouvrage qui ne sait pas ce qu’elle veut; la multiplication des cérémonies, des équipes qui prennent de la marge sur le backlog; et enfin, malgré des scrum de scrum, la gestion des dépendances inter « pizza team ».
SAFe: Scaled Agility Framework
Les grandes organisations ont besoin de quelque chose de plus cadré tout en conservant Agile. Nous avons un mix méthode de projets classique et Scrum.
A la différence de scrum, il y a une vision à facilement 1 an et un découpage en tranches de 2 mois: Le PI (Program Increment).
Le Program Increment est constitué de 4/5 sprints développés par un ensemble de Squads (le nouveau nom de la pizza team).
Dans un train, il y a différents acteurs:
- RTE: Release Train Engineer. C’est la suite du Scrum Master adapté à SAFe. Une personne est responsable du suivi des livraisons, tenue des délais, des dépendances entre les Squad et est garant des cérémonies.
- Chef de projet: Présente la trajectoire, des plannings…
- Architecte Train: Une personne qui définit l’architecture et les briques à utiliser par les équipes.
- Les squads: des équipes entre 10 et 30 personnes.
- Le métier. C’est celui qui a un portefeuille d’applications et.. les sous.
Un train a régulièrement une bonne dizaine de Squads.
La cérémonie de PI Planning regroupe plus de 200 personnes pendant 2 jours afin de décider de ce qui va être développé et de gérer les dépendances avec d’autres trains. Il est courant voire souhaitable de synchroniser les PIP de tous les trains en même temps.
Pour vulgariser, il y a un Train par service, qui reflète l’organisation. Par exemple facturation, CRM, BI.
Revenons à notre architecte train
Je bute un peu sur les compétences nécessaires à ce poste.
C’est un architecte.
Dans l’organisation, vous avez l’Architecte Entreprise (pose la gouvernance, les concepts généraux, l’alignement au choix d’entreprise), l’Architecte Solution (définit l’architecture d’un cas d’usage avec une approche fonctionnelle), l’Architecte Train (reprend l’architecture dans un cadre technique qui « colle » avec le terrain).
C’est un ingénieur
Il a une bonne connaissance des sujets techniques du Train. Il est garant de la qualité et promeut le DevSecOps
C’est un leader
Il aide les équipes à mettre en oeuvre ses architectures, les accompagne, apporte du support, les challenge et participe aux cérémonies SAFe
C’est un politique
Il fait le lien avec le métier pour rendre compte du train, présenter l’organisation, présenter les choix et les faire valider.
Dans mon cas, il est rattaché au RTE, son bras droit en quelques sortes.
Doit il être développeur ?
Nous sommes dans la zone sensible entre accompagner et faire. Je considère que c’est un plus lorsque je m’adresse à un dev, à un tech lead mais je dois reconnaître que ce n’est pas un avis partagé.
En synthèse
C’est un métier passionnant avec un terrain de jeu large en terme de technos, d’équipes, de projets. Il m’a fallu plusieurs mois pour intégrer les divers besoins requis.
Et vous, êtes-vous en phase avec cette définition de poste ?
Comment voyez vous votre architecte train ?
