Découvrez un exemple d’implémentation SAFe® avec Jira


Publié par
Edouard Dorcier

29 novembre 2017

La méthodologie Agile est généralement utilisée pour de petites équipes, de l’ordre d’une dizaine de personnes. Si vous souhaitez l’appliquer à des équipes plus importantes, la méthodologie Scaled Agile Framework (SAFe) sera plus appropriée. Son principe consiste à découper l’ensemble du travail de l’entreprise jusqu’à atteindre une granularité suffisante pour l’utilisation de méthodes Agiles.

Cette méthode se scinde en plusieurs niveaux :

  • une équipe (Team) sélectionne les fonctionnalités (Features) qu’elle souhaite développer. Ces fonctionnalités sont créées par le Responsable produit (Product Owner). L’équipe redécoupe ensuite ces fonctionnalités en Stories avant de les inclure dans un Sprint de 2 semaines. Tous les 5 sprints un Program Increment (PI) Planning est effectué durant lequel les équipes se synchronisent et définissent les prochains développements.
  • les équipes sont regroupées dans un Agile Release Train (ART), piloté au niveau du Program. Chaque fois qu’une fonctionnalité peut être livrée, cette décision étant prise par le Business Owner, elle est intégrée dans l’ART. Les équipes d’un même ART interviennent sur le même programme et doivent donc être synchrones sur les releases et les itérations car des composants peuvent dépendre les uns des autres. Le but est de livrer à l’utilisateur des fonctionnalités rapidement et régulièrement.
  • au-dessus les Large Solution Trains regroupent plusieurs ART au sein de thématiques communes, les Capabilities. Elles doivent normalement tendre vers le déploiement d’une Solution correspondant à ces thématiques.
  • enfin le plus haut niveau du framework est la couche Portfolio. Son objectif est d’aligner les programmes sur la stratégie et vision de l’entreprise via des epics, tout en prenant en compte une dimension investissement-risque.

Nous ne nous attarderons pas ici sur la méthode qui est relativement dense, mais plutôt sur sa mise en place afin de vous permettre d’engager une première réflexion sur l’adéquation de Jira Software avec votre démarche. Si vous souhaitez en savoir plus sur SAFe, une description complète de la méthode est disponible sur le site officiel de Scaled Agile Framework.

Essential SAFe et Jira Software

Dans la méthode SAFe chaque équipe est libre de choisir sa propre méthode de travail. Jira Software propose une option pour implémenter deux des méthodes agiles les plus utilisées : Kanban et Scrum, mais rien n’empêche une équipe de n’utiliser que les fonctionnalités de Jira Core.

Note:Nous pouvons noter que ces méthodes sont clairement nommées dans les schémas de présentation SAFe. Le glossaire SAFe est disponible ici.

Nous allons ici tenter de vous donner une vue la plus large possible du Program.

Un exemple de mise en oeuvre

Un seul projet et trois types de demandes

Nous ne prenons en compte ici qu’un seul Program, représenté par un projet (la clé utilisée dans les exemples à suivre sera PROGRAM) qui regroupera l’ensemble des demandes.

Les Business Owners ont pour mission d’alimenter le projet en fonctionnalités puis de vérifier et valider leur réalisation.

Les différentes équipes de développement ont la possibilité, durant les PI planning, de s’assigner ces fonctionnalités puis de les développer en suivant les Stories associées. Des sous-tâches peuvent être créées dans chaque Story pour faciliter le découpage du travail de réalisation durant les différents sprints.

Le concept d’assignation par groupe

Une équipe de développement doit être capable de s’assigner des demandes, de créer les Stories et les sous-tâches pour isoler son travail de celui des autres équipes.

Pour rester le plus proche possible des fonctionnalités natives de Jira Software nous allons utiliser un champs personnalisé de type Group Picker que nous appellerons Assigned team. Nous pouvons dès lors à partir de ce champ créer des tableaux Jira pour chaque équipe.

Visibilité du travail par équipe

Les tableaux sont définis ici à l’aide d’un filtre JQL. Pour plus de détails, vous pouvez consulter ce guide sur la recherche JQL dans Jira. Notre besoin nous éloigne quelque peu des fonctionnalités natives de Jira puisque nous souhaitons ramener dans notre requête 3 niveaux de demandes (Features, Stories, Subtasks). Nous aurons donc besoin de faire appel à une app Jira.

Exocet, une app développée par Valiantys, nous permet d’ajouter des opérations pour créer les Stories et les sous-tâches et ensuite de copier la valeur du champs Assigned team, niveau par niveau. Cette option est légèrement complexe à mettre en oeuvre mais simplifie considérablement la requête de recherche des demandes pour le tableau.

 

project = PROGRAM AND "Assigned team" = TEAM1

L’intégration d’une nouvelle équipe se fera ensuite simplement en suivant ces étapes :

  1. créer le groupe et définir ses membres
  2. donner à ce groupe les mêmes droits que les autres (Système d’autorisation et rôles projet)
  3. créer le tableau

Visibilité de plus haut niveau

Les Business Owner peuvent également avoir un rôle particulier défini dans Jira. De même rien ne les empêche de créer un tableau de plus haut niveau afin de suivre le travail des différentes équipes. Vous pouvez utiliser le filtre JQL ci-dessous pour alimenter ce tableau :

project = PROGRAM AND issuetype in (Feature, Story)

Lier les demandes Jira entre elles

Les demandes Jira liées sont un bon moyen de casser les silos entre les équipes et donc d’améliorer la communication. Si par exemple la Story de l’équipe A nécessite la livraison d’une fonctionnalité développée par l’équipe B, il est évident que l’équipe A ne doit pas démarrer trop tôt. Grâce aux demandes liées, l’équipe A prend conscience de cette inter-dépendance, voit quelle équipe travaille sur la demande liée et sait donc quand la fonctionnalité bloquante sera livrée. Elle peut dès lors se concentrer sur d’autres tâches l’esprit libre.

Enabler : type de demande

Pourquoi ne pas gérer les Enablers comme des demandes Jira à part entière ? Ces éléments de SAFe définissent des contraintes dont la résolution est nécessaire à la réalisation d’une ou plusieurs fonctionnalités et qui sont souvent gérées par des équipes externes. En les liant comme toute autre demande, les utilisateurs ont ainsi accès aux informations de ces demandes particulières avec une gestion externe et/ou transverse comme leur avancement, leur date estimée de résolution et bien d’autres informations.

Les limitations de Jira Software

Comme nous l’avons vu ici, le premier niveau de SAFe (Essential) peut être mené à bien en utilisant Jira Software couplé à quelques apps. Mais certains aspects n’ont pas encore été adressés.

La principale limitation vient des différences de nomenclature entre Jira et SAFe. Par exemple, les fonctionnalités de SAFe correspondent aux epics dans Scrum et donc dans Jira. Toutes les fonctionnalités pratiques prévues par Jira (epic Link, epic Name, lignes de nages ou swimlanes dans les tableaux) sont indisponibles dans SAFe. Nous pourrions envisager une entorse à la règle pour les normes mais dans ce cas une extension du périmètre SAFe sera difficilement réalisable.

SAFe ne se limite pas à Essential, qui constitue la première étape avant une extension à un périmètre bien plus vaste. Nous avons vu que nous devions déjà gérer trois niveaux de demandes sur ce niveau. L’étape suivante (Large Solution) requiert un nouveau type de demande et de nouvelles autorisations. Et l’étape au-dessus un niveau de plus.

Nous pourrions par exemple ajouter un projet LARGE qui contiendrait l’ensemble des Capabilities du projetCependant les fonctionnalités associées seraient créées dans ce projet puis déplacées ou copiées dans les projets PROGRAM correspondants ce qui alourdirait considérablement la gestion des différents éléments.

Est-ce que Portfolio for Jira est la bonne solution ?

Portfolio for Jira est une app proposée par Atlassian pour la planification et la gestion de tâches dans un portefeuille de projets, permettant d’organiser le travail des équipes en le répartissant.

Hiérarchie des demandes

Une première fonctionnalité apportée par Portfolio for Jira est la hiérarchisation des types de demandes. Si on se réfère à SAFe, on peut dénombrer dans l’ordre :

  • Story
  • Feature
  • Capability
  • Epic

On comprend très vite l’intérêt de cette hiérarchisation qui permet de visualiser en cascade toutes ces demandes et de les grouper simplement.

Concept d’équipe

Les équipes remplacent avantageusement ici les groupes dont nous parlions plus tôt. Il s’agit d’un regroupement de personnes dont nous définissons les compétences et la disponibilité. Ces deux éléments croisés vont permettre à l’équipe de s’organiser et de définir sa vélocité en rapport avec les fonctionnalités qui lui sont attribuées.

Un plan pour chaque programme

Encore une fois la nomenclature entre SAFe et Jira prête ici à confusion. Un ART dans SAFe correspond à un plan dans Portfolio for Jira. Un plan est un regroupement de demandes Jira pouvant se trouver dans plusieurs projets. Ces plans permettent à un utilisateur d’agréger des données issues de plusieurs projets (versions, composants…) et de les intégrer en un seul endroit.

Le RTE (Release Train Engineer) peut ensuite modifier l’ensemble des données à sa guise et planifier le travail des équipes sur plusieurs semaines. Les changements ne sont pas immédiatement visibles par les autres équipes mais doivent faire l’objet d’une validation (commit) pour être reportées dans Jira.

Ainsi le plan peut être peuplé de demandes qui n’existent pas encore dans Jira pour planifier en avance. Cette planification est réaliséee tout en gardant une vue sur les demandes déjà associées à des projets Jira et en recevant des informations sur l’avancement opérationnel.

Les équipes de bas niveau restent normalement maîtres de leur planning personnel. Leurs estimations peuvent différer des hypothèses prises à un niveau plus haut. Il convient de communiquer pour ne pas se retrouver avec un décalage important entre le prévisionnel et le réalisé et pouvoir remonter au plus vite les alertes dues à ces dérives !

Un programme pour chaque Value Stream et Large Solution Train

Encore un peu plus de confusion (sourire). Un programme dans Portfolio for Jira correspond à un regroupement de plans. Ils permettent d’obtenir une vision de plus haut niveau des différents projets en cours.

Une découpe possible revient à faire correspondre cette notion de programme avec les notions de Large Solution Train et de Value Stream. L’agrégation d’un ensemble de Programs (SAFe) en leurs seins permettra au STE (Solution Train Engineer) ou au Portfolio Manager d’avoir une vision globale de l’avancement des Capabilities et des Epics au sein des différents ART et d’intégrer les fonctionnalités futures, de les découper et de les chiffrer sans influer sur le travail de production en cours. Cette planification pourra faire l’objet d’une présentation aux équipes concernées avant sa validation et donc sa mise à disposition.

Vers l’infini et au-delà ?

Les étapes précédentes sont déjà conséquentes à mettre en place (et nous ne parlons pas seulement d’administration et de configuration Jira). Mais il est bon de noter que la notion de programme peut encore être étendue dans Portfolio for Jira en effectuant une consolidation de plusieurs programmes. On obtient alors la vision de plus haut niveau dans la méthode SAFe : Portfolio. Encore un terme dont les définitions divergent. Portfolio en plus d’être le nom de l’app désigne une notion plus vague de portefeuille de projets qui peut être largement étendue.

Il est possible de regrouper des programmes au sein d’un programme de niveau supérieur dans Portfolio.

SAFe est un sujet complexe, c’est certain, mais savoir garder le contrôle et gérer les équipes de développement dans les grandes entreprises l’est tout autant. Si vous avez besoin d’accompagnement pour mettre en place cette méthodologie agile,contactez Valiantys.