Approches agiles

Importance des approches agiles

Les approches agiles sont très répandues dans la conception applications numériques.
Du point de vue du dialogue social un aspect important des démarches agiles est qu’un lien permanent est en principe maintenu avec les utilisateurs du futur logiciel tout au long du projet. Ce qui pendant toute la durée du projet leur donnerait, en théorie au moins, la possibilité de corriger certains aspects de l’application qui seraient trop négatifs quant au bien-être et citoyenneté au travail.
Ces approches présentent cependant des particularités qui peuvent limiter le dialogue social et la prise en compte des exigences en matière de bien-être et citoyenneté au travail.
Les exemples donnés sont issus de Scrum.

Avertissement : nous ne décrivons dans cette partie que les seuls aspects de Scrum1 qui nous ont paru essentiels pour le dialogue social. Aucune exhaustivité n’a donc été visée dans cette présentation.
Sur les démarches agiles, voir également le § concerné dans la page points-clés du projet informatique.

Nota : les enjeux pour le haut management

Le haut management est souvent très sensible à la promesse des approches agiles sur la rapidité de production de fonctionnalités utilisables. L’enjeu est ici de gagner du temps, et donc de l’argent.
Il ne faut pas négliger non plus les effets de « mode ».

  • À noter

La plupart des conseils déjà donnés pour les phases des démarches séquentielles (phases Cadrage à Maintenance) restent pertinents. Ils ne seront pas, sauf exception, repris ici.

  • Dogme à combattre/Nouveau paradigme à promouvoir

Le but ultime souvent affiché par les approches agiles est celui de la « maximisation de la valeur du produit » (c’est-à-dire du logiciel développé).
Il ne s’agit pas de s’opposer à cet objectif, mais il faut que soit définie collectivement, par le dialogue social, ce qu’est la « valeur du produit », afin d’y introduire les aspects de bien-être au travail.

Éléments de base

Sprint

Un sprint est une itération (voir le modèle itératif et incrémental). Elle dure entre une semaine et un mois en général. Pendant un sprint, l’équipe développe une liste d’éléments issus du backlog de produit, liste définie au départ du sprint.

Backlog

Product backlog (backlog produit, carnet de produit)

Selon la définition du Guide Scrum2 : « le Product Backlog est une liste ordonnée et émergente de ce qui est nécessaire pour améliorer le produit ». « C’est l’unique source du travail entrepris par la Scrum Team ».
Plus précisément : « Le Product Backlog produit liste toutes les fonctionnalités, les fonctions, les exigences, les améliorations et les corrections qui constituent des modifications à apporter au produit dans les versions futures »3.
Il contient les besoins exprimés sous forme de user stories (voir plus bas). Il est hiérarchisé et les tâches sont priorisées.
Un point essentiel est que le backlog évolue constamment, pendant toute la durée du projet. Chaque sprint l’enrichit des feedbacks remontés par les utilisateurs finaux, des anomalies identifiées et des nouveaux besoins qui ont pu émerger. Ce caractère par essence dynamique le différencie nettement d’un cahier des charges.

Sprint backlog (backlog de sprint, carnet de sprint)

Il contient la liste des tâches à accomplir pendant un sprint, pour réaliser concrètement les éléments du carnet de produit qui ont été affectés à un sprint, après avoir été convenablement affinés. « L’affinement du Product Backlog consiste à décomposer et à définir davantage les éléments du Backlog en éléments plus fins et plus précis. Il s’agit d’une activité continue visant à ajouter des détails, tels qu’une description, un ordre et une taille. Les attributs varient souvent en fonction du domaine d’activité »2.
Le backlog de sprint concerne l’équipe de développement.

User story

Un récit utilisateur est une phrase simple dans le langage de tous les jours permettant de définir avec suffisamment de précision le contenu d’une fonctionnalité à développer (voir plus bas).

  • Point de vigilance

S’ils ne l’ont pas rédigée eux-mêmes, le ou les utilisateurs (à l’origine d’une user story) doivent pouvoir vérifier sa rédaction avant qu’elle ne soit intégrée au backlog de produit.

  • Point de vigilance pour les acteurs du DS

Le carnet de produit évoluant constamment, il faut s’assurer régulièrement que des exigences liées au bien-être au travail n’ont pas été modifiées indûment.
Par ailleurs si de nouvelles exigences sur cette thématique émergent à la suite de tests d’éléments de l’application par des utilisateurs, il faut veiller à leur inscription dans le backlog de produit.

  • Rappel : carnet de dialogue social

Ce « carnet de dialogue social » (backlog de dialogue social) doit permettre le suivi de la prise en compte (mais aussi de l’évolution) des besoins issus du dialogue social, les difficultés rencontrées, les arbitrages faits, etc.
Il doit être initialisé dès le départ du projet.

Acteurs

Le Product Owner (PO) : il représente l’essentiel de la MOA (le côté métier, besoins). Il valide toutes les décisions autour du produit et du contenu du backlog de produit. Son rôle peut parfois être aussi celui de pilote du projet, avec la latitude de prendre des décisions stratégiques dans le projet.

Le Scrum manager (SM) : il correspond approximativement au chef de projet MOE, mais ce rôle peut être également parfois tenu par le PO. Le SM est responsable de la méthodologie employée, il accompagne les équipes dans l’utilisation des composantes de Scrum (événements, artefacts, etc.).
L’équipe de développement : rôle de réalisation de la solution technique. Les membres de l’équipe sont responsables de l’incrément, du backlog de sprint et donc de la manière dont sera réalisée l’application. Ils peuvent être également en charge de l’estimation de la charge et du temps de réalisation de chaque item.

Le PO, le SM et l’équipe de développement constituent l’équipe Core (noyau) de Scrum. Celle-ci intervient sur le projet conjointement aux autres parties prenantes : le Commanditaire (client) qui est l’initiateur du projet, le Financeur (quand il est distinct du Commanditaire) qui apporte le support financier au projet, les utilisateurs à qui le logiciel est destiné. Ces derniers ont un rôle essentiel pour les validations et l’orientation des décisions qui seront prises quant aux fonctionnalités de l’application.

Déroulement

Principe général

Le principe général est que les sprints vont se succéder tout au long du projet, chaque sprint devant produire un incrément à l’application développée.

Il convient cependant de distinguer ce qui précède le premier sprint (phase d’initialisation) de la suite des sprints « de croisière ».

Phase d’initialisation (avant-sprint, sprint 0…)

Les approches agiles peuvent être utilisées pour l’ensemble du projet, ou bien seulement à partir de la phase de réalisation (développement).
Dans les deux cas, ce dont on dispose en début de mise en œuvre de Scrum pour élaborer une première version du carnet de produit (product backlog) est assez différent.
Dans le second cas (approche agile seulement à partir de la phase de réalisation), les objectifs de l’application ainsi que les besoins (exigences fonctionnelles et non fonctionnelles) ont été exprimés et ont connu un premier affinement. Il s’agira alors de constituer la première version du backlog de produit sur cette base.
Dans le premier cas (approche agile sur l’ensemble du cycle de vie du projet), la situation au départ est comparable à l’entrée dans la phase Cadrage des méthodes séquentielles. Il faudra donc un travail de production et de compréhension des finalités et objectifs de l’application, des grandes fonctionnalités attendues, des liens qui les relient, des risques associés… pour être à même de construire la première version du backlog de produit.

  • Dogme à combattre : « vitesse = efficacité » (vs génération de dette sociale)

Dans la communication sur les approches agiles, la flexibilité et la réduction temps de développement espérés sont largement mises en avant.
Or la réduction de la durée d’un projet informatique peut entraver la bonne compréhension du travail tel qu’il s’effectue réellement. Ce peut notamment être le cas si les user stories sont écrites par le seul PO, sans entretiens suffisamment approfondis avec les futurs utilisateurs de l’application et sans validation des user stories de leur part.
Par ailleurs, un temps trop limité gênera (voire empêchera) la prise en compte des exigences non fonctionnelles non techniques et tout particulièrement celles concernant le bien-être et la citoyenneté au travail (concernant le traitement desquelles les équipes n’ont en général que très peu ou pas d’expérience).
Cette réduction de la durée du projet peut ainsi contrarier fortement la prévention efficace des risques sur la santé, le bien-être au travail, générant ainsi de la « dette sociale ».

  • Dogme à combattre : « vitesse = efficacité » (vs génération de dette technique)

La recherche de la vitesse d’exécution du projet peut également produire de la « dette technique », laquelle entraîne des coûts futurs parfois très importants. Cette « dette technique » peut aussi impacter les conditions de travail à moyen ou long terme par la dégradation des performances de l’application.

User stories (élicitation/expression des besoins)

Nota : le concept de user story est issu à l’origine de XP4 (et non de Scrum), mais est largement utilisé dans beaucoup d’approches agiles.
La user story est un cadre qui doit permettre d’exprimer un besoin d’un utilisateur, dans un langage non formel, que l’on veut simple et clair. Elle doit être écrite dans un langage compris par l’ensemble des acteurs du projet.
Les user stories constituent les unités de travail du backlog de produit, exprimées du point de vue de l’utilisateur.
Bien que représentant le point de vue d’un utilisateur, elles ne sont en général pas rédigées par ces derniers, mais par le Product Owner ou les AMOA (sur la base d’entretiens avec les utilisateurs, ou parfois uniquement sur la base des propres connaissances du PO).

Modèle classique pour une user story

Une user story suit en général le modèle suivant :
En tant que [qui, rôle], je veux/je souhaite [action] afin de [pourquoi : bénéfice attendu, valeur attendue]
Qui : l’utilisateur (au sens de la fonction remplie) ou le type d’utilisateur qui a ce besoin (c’est de son point de vue que l’on se situe).
La notion de persona4, issue du marketing peut être utilisée.
Action : décrit, en général assez brièvement, l’action que l’utilisateur veut ou doit entreprendre ou le résultat qu’il espère obtenir.
Pourquoi (bénéfice, valeur attendus) : la valeur ou le bénéfice que l’utilisateur espère retirer de son action. C’est la raison pour laquelle l’utilisateur veut effectuer l’action ou atteindre l’objectif. Permet d’identifier l’intérêt de la fonctionnalité, d’en justifier le développement, et d’aider à mieux évaluer la priorité de la user story.

Epics, thèmes

Une user story trop complexe (c’est-à-dire qui ne peut donner lieu à un seul sprint) est une epic et sera décomposée en user stories plus réduites.
Dans le backlog de produit, les epics peuvent être à leur tour rassemblées en thèmes (groupes d’epics partageant un même objectif…) ou en features (fonctionnalités).

Le cas des exigences non fonctionnelles (ENF)

Les approches agiles ne donnent pas une place importante (voire ne donnent pas de place du tout) à l’expression et au traitement des exigences non fonctionnelles.
Le backlog de produit ayant vocation à contenir tout ce qui apporte de la valeur au logiciel qui sera produit, il semble naturel qu’il traite du fonctionnel comme du non fonctionnel. Notons qu’un des intérêts de mettre les ENF dans le backlog de produit est d’avoir une source unique pour toutes les exigences.
Il est cependant parfois difficile de faire en sorte qu’une exigence non fonctionnelle soit réalisable en un seul sprint et soit testable. Il faut alors découper une ENF trop importante (ou transversale) en ENF plus réduites. Une bonne façon de faire semble de se centrer plus sur les critères qui permettront la validation de l’ENF réduite que sur sa description détaillée.

Critères d’acceptation d’une user story

Chaque user story doit être complétée avec des critères d’acceptation. La vérification de ceux-ci permet de confirmer (ou non) que la livraison de fin de sprint est bien conforme aux attentes. Cette validation peut être effectuée par le PO, seul ou en collaboration avec les utilisateurs concernés.
Les critères d’acceptation peuvent être rédigés par le PO, seul ou en collaboration avec les développeurs, mais peuvent aussi être rédigés avec d’autres acteurs impactés ou concernés.

  • Propositions à faire : modèle de user story complété

Les porteurs des besoins de bien-être et citoyenneté au travail peuvent proposer un modèle de user story complété par :
– le comment : tâche telle qu’elle est réellement effectuée
– les problèmes spécifiques de conditions de travail posés par la tâche
– les risques de santé, de dégradation du bien-être et de la citoyenneté au travail… liés à la tâche décrite tels qu’identifiés par l’utilisateur lui-même.

  • Point de vigilance : collectifs de travail

Dans les approches agiles, les utilisateurs (le « qui » des user stories) sont des individus. Les collectifs de travail ne sont pas en eux-mêmes considérés comme des utilisateurs.
Les porteurs des besoins de bien-être et citoyenneté au travail doivent pouvoir avancer des besoins/exigences concernant des collectifs de travail.
Il en est de même pour les besoins que les salariés considèrent importants pour l’organisation dans sa globalité (ex. : besoins garantissant des missions de l’organisation complémentaires à celles portées par le haut management).

  • Propositions à faire : modèle de user story complété

Les porteurs des besoins de bien-être et citoyenneté au travail peuvent proposer un modèle de user story complété par :
– le comment : tâche telle qu’elle est réellement effectuée
– les problèmes spécifiques de conditions de travail posés par la tâche
– les risques de santé, de dégradation du bien-être et de la citoyenneté au travail… liés à la tâche décrite tels qu’identifiés par l’utilisateur lui-même.

  • Point de vigilance / Propositions à faire : personae

Si l’équipe projet utilise des personae :
– nécessité d’une vigilance globale : car les personae peuvent être performatifs
– attention aux personae trop stéréotypés, qui seraient de simples clichés (porteurs de représentations dominantes parfois inconscientes)
– avant le début des entretiens pour l’écriture des user stories, se concerter avec les personnes concernées pour proposer des personae représentatifs des situations de travail réelles, de la diversité des vécus réels des utilisateurs.

  • Point de vigilance : bonne prise en compte des ENF de bien-être et citoyenneté au travail

Les exigences liées au bien-être au travail peuvent être, parfois majoritairement, des exigences non fonctionnelles .
Or les approches agiles encouragent parfois de fait les équipes projet à ne pas prendre en compte les ENF non strictement techniques.
Les porteurs des besoins de bien-être et citoyenneté au travail dans le projet doivent être très vigilants sur la bonne prise en compte des ENF sur ces thématiques.

  • Procédures du dialogue social

Les critères d’acceptation des user stories sont à définir collectivement, par le dialogue social.

  • Propositions à faire

Les porteurs des besoins de bien-être et citoyenneté au travail peuvent proposer des critères d’acceptation prenant en compte ces thématiques.

Notes et références

  1. « Scrum » n’est pas un sigle, c’est un terme de rugby anglais qui signifie « mêlée ». Pour l’historique de la métaphore, voir https://fr.wikipedia.org/wiki/Scrum_(d%C3%A9veloppement)#Historique
  2. Schwaber K. et Sutherland J. (2020) Le guide de Référence de Scrum. https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-French.pdf
  3. Schwaber K. et Sutherland J. (2016) Le Guide définitif de Scrum : les règles du jeu. https://scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-French.pdf
  4. Une persona (…) est une représentation fictive d’une personne dotée de caractéristiques socio-démographiques et psychologiques spécifiques, destinée à représenter un segment précis de la clientèle ou de l’audience. https://fr.wikipedia.org/wiki/Persona_(marketing)