Implication des parties prenantes

Impliquer le client et toutes les parties prenantes du projet dans sa réalisation est un enjeu fondamental pour la réussite d'un projet. Vous verrez sur cette page comment l'agilité favorise et facilite cette implication.

Partage de connaissances

La meilleure manière d’impliquer les gens dans un projet est de les tenir informés de ce qui s’y passe.

Le problème principal est que tout le monde est très occupé : réunions, mails, téléphone… Au final, trop d’information tue l’information.

De l’information disponible à tout moment

Les équipes agiles mettent l’information à disposition, et favorisent son accès, plutôt que de la pousser systématiquement vers toutes les parties prenantes du projet.

Une manière de tenir tout le monde informé et captivé par l’avancement du projet est d’alimenter des « radiateurs d’information » (on parle parfois aussi de « big visible chart », BVC).

Définition – Un radiateur d’information, c’est un grand affichage, bien visible, dans un endroit passant, permettant à toute personne intéressée par un projet d’en suivre l’avancement.

Voici un exemple de radiateur d’information de 2 mètres de large, affiché sur le mur de la cafeteria d’une équipe agile (© Alistair Cockburn) :

Radiateur d'information

Une implication continuelle

Le fait de « maintenir » les parties prenante dans le projet est une préoccupation quotidienne des équipes agiles.

Elle implique que l’on essaie, par tous les moyens, de faire participer ces gens à la vie du projet, du début à la fin :

  • En les faisant participer à la priorisation en fonction de la valeur.
  • En sollicitant leur feedback très régulièrement, par exemple lors de démonstrations des différents incréments de produit.
  • En privilégiant, dès que possible, la communication directe, en face à face : rien ne vaut une discussion (à côté d’un bon radiateur d’information ;) qu’un fil de mails, un coup de téléphone ou même un skype.

Definition of done

Pour bien s’entendre avec les parties prenantes du projet, il faut éviter les malentendus, principale source de conflit.

La plus grosse source de malentendu, dans un projet, est généralement le fait de ne pas être d’accord sur qu’est un travail terminé.

On appelle cela « definition of done », en français dans le texte « définition de terminé » ou « définition de fini ». Un des enjeux fondamentaux d’un projet agile est de se concerter, avec son client et toutes les parties prenantes, de ce qu’est cette fameuse definition of done.

Que veut dire « done » ? Qu’une fonctionnalité est livrée en production ? Qu’elle est déployée sur un environnement de test en attente de validation ? Qu’elle est développée et testée unitairement, mais pas encore déployée ? Qu’elle est « recettable » par le client ?

Pas si évident, n’est-ce pas ?

Il n’y a pas de définition universelle, de recette magique qui s’appliquerait à tous les projets, à tous les contextes. C’est la raison pour laquelle les équipes agiles doivent travailler, en collaboration avec leur client, pour établir ensemble cette définition, qui sera valable tout au long du projet.

Exemple de definition of done

  • Le code est écrit
  • Le code est testé unitairement
  • Le code est intégré et testé en intégration
  • La documentation est rédigée
  • Le statut du ticket original de la demande a été mis à jour

…mais ce c’est qu’un exemple : à chaque équipe de trouver celle qui convient le mieux à son contexte, et surtout de la partager.

À voir

Spécification collaborative

Comme mentionné plus haut, les parties prenantes doivent être impliquées à tous les niveaux, y compris dans les phases de spécification du produit.

Pour se comprendre et aboutir à des concensus, les équipes agiles utilisent différents outils.

Modèles

UML Unified Modeling Language

Les longs baratins ne sont décidément pas très agiles !

Ils est bien sûr nécessaire d’expliquer les choses, et de les détailler un minimum en langue naturelle (oui, sinon j’aurais belle mine de vous proposer ce genre de site…). Mais il est généralement plus efficace d’avoir recours, au maximum, à des représentations graphiques, facilement compréhensibles par tous.

Pour qu’elles soient facilement compréhensibles, il faut qu’elles soient représentées dans un langage abordable, ou encore mieux : dans un langage abordable et standardisé.

C’est notamment le cas d’UML : Unified Modeling Language, langage de modélisation unifié donc, qui permet notamment de représenter des cas d’utilisation d’un système, de clarifier les concepts en présence dans un système d’information, la cinématique d’un processus, et beaucoup d’autres choses encore.

En voici quelques exemples.

Diagramme de classes UML

UML diagramme de classes

Le diagramme de classes permet de clarifier quels concepts sont manipulés par le système, leurs caractéristiques et leur relations avec les autres concepts.

Diagramme de cas d’utilisation UML

UML diagramme de cas d'utilisation (use case)

Le diagramme de cas d’utilisation permet de représenter les fonctionnalités d’un système, les rôles qui sont censés utiliser ces fonctionnalités, et les liens entre tout ceci. On peut par exemple indiquer qu’un cas d’utilisation requiert l’exécution d’un autre cas (comme sur le diagramme ci-dessus).

Diagramme d’activité UML

UML diagramme d'activité

Le diagramme d’activité permet de décrire la cinématique d’un processus. C’est très utile pour expliquer comment doit se passer quelque chose, sous la forme d’une chronologie d’activités.

Wireframes

En plus des diagrammes, les équipes agiles ont parfois recours aux wireframes, qui sont des représentations simplifiées des interfaces graphiques attendues dans un projet.

En voici un exemple :

Wireframe

Personæ

Les personæ (ou personas) sont une manière de se représenter les profils des principaux utilisateurs et parties prenantes d’un projet ou d’un système. Ils permettent de compléter les modèles et wireframes, en permettant notamment d’imaginer des cas d’utilisation particuliers du système, de se mettre « à la place » des utilisateurs potentiels.

Concrètement, un persona est une personne imaginaire, qui possède des caractéristiques spécifiques correspondant à celles d’utilisateurs du système.

En voici un exemple :

Persona avatar

Nom
Marie
Description
Marie a 35 ans. Elle aime la gestion de projet. Elle gère des projets pour le compte de différentes entreprises publiques et privées depuis 10 ans, d’abord en tant que chargée de projets, puis, depuis 4 ans, comme chef de projets agile.
Valeurs
Marie recherche un outil de modélisation qui lui permettrait de représenter au mieux les cas d’utilisation des systèmes informatiques sur lesquels elle travaille, notamment pour des systèmes d’information dans le domaine de l’apprentissage en ligne. Elle n’aime pas les outils compliqués, et préfère la simplicité et l’efficacité.

Testez-vous !

Pourquoi les radiateurs d’information sont importants ?
  • Parce qu’ils permettent aux gens qui s’intéressent au projet d’être tenus informés de ce qui s’y passe.
  • Parce qu’ils permettent à l’équipe de ne pas avoir froid.
  • Les radiateurs d’information ne sont pas utilisés dans les projets agiles.
  • Les radiateurs d’information sont un outil de communication osmotique, c’est à dire qu’ils permettent de diffuser de l’information localement, auprès des personnes qui travaillent au même endroit.
Qui établit la « definition of done » dans un projet agile
  • Toute l’équipe, en collaboration avec les parties prenantes
  • Le chef de projet
  • Les développeurs uniquement
  • Le chef de service
Pourquoi UML est utile dans les projets agiles ?
  • Parce qu’un dessin vaut mieux qu’un long discours.
  • UML n’est utile que pour les développeurs.
  • Parce qu’il définit un langage standardisé et aisément compréhensible par toute l’équipe.
  • UML n’est pas utile dans le cadre d’un projet agile.
Qu’est-ce qu’un wireframe ?
  • Un type de diagramme UML
  • Une représentation schématique de ce qui est attendu en matière d’interface utilisateur
  • Une sorte de « prototype non fonctionnel » permettant de montrer ce que le client attend du logiciel
Pourquoi les personæ sont utiles dans un projet agile ?
  • Ils permettent d’envisager des cas d’utilisation auxquels l’équipe n’aurait peut être pas pensé, en se mettant à la place de certains types d’utilisateurs.
  • Ils permettent de décrire la cinématique d’un cas d’utilisation.
  • Ils apportent une information sur le coût du projet.

Commentaires