Agile Release Train – CrossInstitute

Étiqueté : #AgileReleaseTrain #SAFeforteam #RolesActivitiesAreas

Ce sujet contient 3 réponses, 4 participants et a été mis à jour pour la dernière fois par Laurent, le il y a 2 années et 7 mois.

4 sujets de 1 à 4 (sur un total de 4)

Auteur

Messages
7 juin 2021 à 17h31 #5394

Sabine IBANEZ
Participant

Peut-on avoir un explicatif clair et exhaustif des rôles et des activités/compétences que nous avons dans un Agile Release train ? J’aimerais comprendre les périmètres d’intervention de chacun dans le train et entre les trains. J’aimerais comprendre l’utilité (la singularité) des rôles et leur nombre requit selon l’ampleur du projet; exemple : Toujours 1 seul RTE qu’il y ait 5 trains ou 12. Il est préconisé d’avoir 2 system Architect/Engineering au-delà de 5 trains, ect…
Y-aurait-il un exemple concret qui nous permet d’ancrer tout cela ?
Je ne comprends pas pourquoi dans le support de cours “SAFe for Team”, page 52, les disciplines principales sont le PM, le system Architect/Engineering, le lean Ux et le Shared Services. Je n’ai pas bien compris ce que sont les 2 derniers.
L’équipe technique, le PO et le Scrum master ne le sont pas car ils agissent en micro ?

Par avance merci.
Sabine

8 juin 2021 à 6h30 #5413

contact@crossthink.fr
Maître des clés

Bonjour sabine,

Tout d’abord sachez que lean UX est une approche, inspirée du lean startup, qui vise à d’abord satisfaire les utilisateurs d’un produit en développement. Les shared services quand à eux sont un modèle commercial qui permet d’exploiter les ressources dans l’ensemble d’une organisation, ce qui permet de réduire les coûts avec des niveaux de service client convenus. Ils sont mis en avant car indispensable à l’objectif de Safe qui vise à mettre en avant la qualité et l’efficacité. Le PO et SM ne sont pas mentionné car ils n’agissent pas au meme niveau de l’organisation voila tout.
Voici un petit récapitulatif des roles:
Scrum Master – Guide l’équipe de façon continue dans le cadre des réunions, des processus, des bonnes pratiques et des cérémonies.
Product Owner – Est responsable de la valeur produite par l’équipe Agile.
Membre d’équipe – Constitue le cœur des équipes Agile. Il s’agit de travailleurs pluridisciplinaires et collaboratifs axés sur la livraison incrémentielle.
Release Train Engineers (RTE) – Ils sont chargés de faciliter l’exécution des programmes, d’éliminer les obstacles qui entravent le workflow et d’assurer la gestion des risques et des dépendances.
Responsable Produit – Il est responsable de la vision et de la stratégie relatives au produit ; il communique avec les parties prenantes internes et externes pour définir et satisfaire les exigences des clients.
Architectes/ingénieurs système – Ils définissent et conçoivent l’architecture globale du système, en adoptant une vue d’ensemble pour s’assurer que les principaux éléments et interfaces du système fonctionnent ensemble de manière fluide.
Business Owners – Ils sont les parties prenantes internes clés de l’ART ; ils sont responsables de la réalisation des résultats économiques escomptés de l’ART.

Il n’y a pas de réponse préconstruite pour définir le nombre de personnes derriere chaque roles, meme s’il est vrai que le RTE étant un peu le “chef d’orchestre” semble plus efficace s’il est seul. Pourrait t’on faire jouer en symbiose un orchestre avec 2 chef d’orchestre ?
Gardez tout de meme ceci en tete :
Lorsqu’il s’agit de structurer vos équipes Agile, il est important de réfléchir aux questions suivantes pendant la phase de planification de projet. Quel type de support incrémentiel est-il nécessaire pendant la phase de développement du produit ? Comment les besoins changent-ils une fois le produit mis à la disposition des clients ? Quel soutien commercial et marketing continu est-il nécessaire tout au long du cycle de vie du produit ? Les réponses à ces questions aideront à déterminer qui recruter pour ces rôles.

Bonne continuation

1 septembre 2021 à 17h18 #6164

Yannick PRUD’HOMME

Participant

Dans une organisation où il y a un Product Manager pour 2 équipes Scrum de 10 personnes chacune. En tout, une vingtaine de personnes pour ce train, faut-il faire un PI Planning de 2 jours toutes les 5 semaines?

6 septembre 2021 à 19h51 #6303

Laurent

Maître des clés

Bonjour Yannick,

Le but du PI planning étant de pouvoir synchroniser les équipes je dirais qu’il est necessaire de les faire. Par contre le framework prevoit toutes les 8 semaines. Toutes les 5 semaines cela me parait trop court.

Excellente soirée

4 sujets de 1 à 4 (sur un total de 4)

Vous devez être connecté pour répondre à ce sujet.