Ici, nous nous intéressons à tout ce qui se passe en amont du projet agile : comment le product owner recueille les besoins et les bonnes pratiques à adopter.
Dans les grands comptes industriels, on rencontre souvent le même scénario : le product owner (PO) doit recueillir les besoins auprès d’un client de niveau supérieur, que nous nommerons ci-après Responsable Métier (RM). Le PO devient de ce fait ce qu'on appelle aussi un "customer proxy", sorte de "facade" de besoins supérieurs vis-à-vis de l'équipe de développement. Le premier appartient à un département technique, proche du métier informatique, qui joue (entre autres) le rôle d’intégrateur système informatique entre son propre client en amont et les sous-traitants en aval. Ce département est couramment nommé « Industrial Unit » (IU). Le second appartient à un département métier, plus proche du métier commercial, dont la responsabilité et de définir les besoins système en assurant sa cohérence au sein d’un système plus vaste, souvent composé de hardware. Ce département est couramment nommé « Business Unit » (BU).
Le véritable enjeu se situe entre le responsable métier et le product owner. Une bonne symbiose entre RM et PO est la clef de la réussite du projet agile.
- Le PO doit relire systématiquement les exigences produites par le RM
- Le PO questionnent le RM tant qu’il n’a pas obtenu une compréhension suffisante des exigences pour permettre l’autonomie des développements.
- Le PO doit comprendre les besoins « mieux que la BU elle-même »
- PO et RM maintiennent des points de rendez-vous hebdomadaires permettant de lever les ambiguïtés résiduelles et de définir les priorités pour les prochaines itérations
- Le RM invite le PO à des réunions BU si elles apportent un résultat en matière d’expression de besoin (et non s’il s’agit de brainstorming ou d’ateliers très en amont)
- Le PO produit de son côté un product backlog « à plat », prêt à être « consommer » par l’équipe de développement.
- Le PO ne doit pas cumuler ce poste avec celui de « chef de projet » au sens du référentiel société
- RM et PO doivent être mobilisés quasi-exclusivement sur l’alimentation des développements.
- Le RM doit impliquer le PO de façon proactive
- RM et PO doivent se rendre mutuellement très disponibles
- Le RM doit comprendre les préoccupations du PO et pourquoi il a besoin de telle information à tel moment
- Ce phénomène « contamine » (positivement !) toute la chaîne de production d’exigences en amont (gens du système, intégrateurs, etc). Une sensibilisation de tous ces acteurs est nécessaire en cas de découverte de ce nouveau paradigme qu’est l’agilité (changement des habitudes de travail, implication très en amont etc)
- Le RM doit fournir tôt au PO des données de tests représentatives de l’utilisation finale du produit. Pour cela, il identifie les personnes clefs : responsables d'intégration/validation etc
- Le RM et le PO élaborent ensemble des tests bout-en-bout AVANT la dernière itération de livraison de la version officielle afin de compléter les validations itératives et d’anticiper la recette.
Des itérations de production d’exigences (non techniques) sont menées en avance des itérations de développement d’au moins une itération (deux ou trois souhaitables, cela dépend de l’organisation en amont).
A l’issue d’une itération de production d’exigences, on a un ensemble fonctionnel autonome nécessaire et suffisant pour lancer son développement. Cet ensemble contient :
- Une situation claire de l’incrément à produire au sein du périmètre global
- Les exigences matures du document d'exigences concernant cet incrément (si on en obligé d'en produire un !)
- Les données de tests représentatives
Une organisation vraiment agile se reconnaîtra avant tout à sa capacité à surmonter les barrières classiques MOA/MOE. Par exemple, la livraison officielle d’un sous-ensemble d’exigences fonctionnelles en entrée d’itération doit néanmoins laisser la place à des allers-retours souples, fréquents et conviviaux pendant l’itération, à l’image de la relation product owner – scrum master du côté développements. La valeur « communication » du manifeste agile doit rester au cœur de la méthode.