En 2019, j’ai eu la chance d’être SCRUM Master et coach agile pour repenser le parcours web de recrutement de volontaires pour des études cliniques menées par un acteur de la cosmétique. J’aimerais partager avec vous les clés de la réussite de ce projet mais également certains enseignements que j’ai tirés de cette expérience. 

La phase de cadrage du projet : un incontournable 

Avant le commencement du projet, la phase de cadrage a permis aux 7 participants, dont le client qui était néophyte, de mieux comprendre l’agilité et surtout de cadrer le budget et les délais. 

En amont des 8 sprints prévus, ont été menés : 

• Une formation de 2 jours à l’agilité pour l’ensemble des intervenants. Elle a permis au Product Owner, aux membres de la DSI et aux utilisateurs clés de comprendre l’état d’esprit agile et le mode de collaboration que nous allions mettre en place avec le rôle de chacun. 

• Plusieurs jours d’ateliers de vision, personas et story mapping afin d’aligner tout le monde sur les objectifs du produit et de commencer à construire le Backlog Produit. A ces ateliers étaient présents la Product Owner, la Proxy Product Owner, les utilisateurs clés, l’interlocutrice DSI, un UX designer et un développeur. La présence de ces deux derniers leur a permis de capter beaucoup d’informations, de construire une UX Map (ou carte d’expérience) et d’échanger sur des questions ou problématiques techniques qui pouvaient déjà se présenter. 

Le Sprint 0 ou la préparation du projet : l’étape primordiale 

L’agilité nécessite de faire une bonne préparation, ou sprint 0, en amont des sprints. Au-delà de la liste des actions à mener, ce sprint a révélé certains points positifs qui ont par la suite permis de mener à bien ce projet. 

Réalisation de plusieurs POC

Le projet comprenait plusieurs points techniques à risque : 

• Serveur HDS (Hébergement de données de santé) : les données de santé étant des données sensibles, nous avons dû travailler avec des serveurs ayant des contraintes particulières (accès limités, encryptage des données, séparation des données, etc.) 
• Connexion de notre application à l’agenda Outlook de notre société avec un besoin fort d’écriture dans les agendas demandés par les métiers 

• Refaire tout le site vitrine de notre client 

Pour essayer de limiter les risques, et surtout ne pas s’engager sans savoir vraiment de quoi il retournait, nous avons réalisé des POC pour les deux premiers points. Ces POC nous ont permis : 

• De faire en amont le code source de base pour le projet 
• De vérifier le fonctionnement avec la DSI 

• De monter en compétence pour l’équipe de développement 

Pour le site vitrine, il se trouve que le site corporate du client venait d’être entièrement refait par SQLI. Nous avons donc étudié le fait de réutiliser son socle technique et de l’adapter à nos besoins : cette opération a permis de gagner du temps et du budget pour la partie « application » du projet. 

Mise en place des environnements 

La gestion des environnements techniques est toujours très consommatrice de temps et d’argent, aussi bien à la mise en place qu’à la maintenance sur le long cours. Nous avons donc décidé de monter en premier un environnement de développement et d’intégration entièrement opérationnel et disponible dès le premier sprint, ce qui nous a offert une visibilité sur le déploiement des suivants. 

Réalisation d’une première user story

L’importance de la première US (user story) à faire pendant le sprint 0 s’est confirmée pour ce projet. A partir d’une US très simple, nous nous sommes rendu compte de certains problèmes de déploiement que nous avions sur nos environnements (droits d’accès aux serveurs et packaging du produit notamment). Sans cette première US, nous n’aurions jamais pu livrer une seule US en sprint 1 ; n’hésitez pas à la faire ! 

Une organisation d’équipe dans l’esprit de SCRUM

L’équipe a su trouver une organisation dans l’esprit de SCRUM. Elle était composée comme suit (avec le temps alloué au projet pour chacun car cela a joué un rôle crucial dans la réussite du projet) : 

• Un Product Owner (PO) côté client avec 25% de son temps alloué au projet 
• Un Proxy Product Owner (PPO) avec 100% de son temps alloué au projet 
• Un UX Designer avec un nombre de jours fixes alloués au projet 
• Trois développeurs dont deux à temps plein et un à 80% 
• Un SCRUM Master/Coach agile à mi-temps 

Une DSI facilitatrice du projet

Nous avons eu la chance d’avoir une DSI qui a compris l’importance du travail « sans intermédiaire » dans les projets agiles, ce qui nous a permis de travailler directement avec les acteurs des métiers. En effet, nous voyons souvent notre interlocuteur (PO) « métier » être une personne de l’informatique qui fait le « passe plat » entre l’équipe et les acteurs des métiers. La DSI nous a donc fourni un soutien sur les sujets techniques lorsque nous en avions besoin, et le PO du projet était une personne directement du métier. 

Le rôle du PO : impliqué et à temps plein ! 

Pour moi, le rôle du PO est souvent sous-estimé en Agile. C’est pourtant lui qui porte le produit et qui définit ce à quoi il va ressembler. Nous avons eu l’occasion d’avoir ce que j’appelle un « vrai » PO ; une personne côté métier qui va utiliser l’application développée, qui connait les métiers et sait où chercher les informations sur les métiers. Notre PO a fait un travail colossal en amont pour définir avec les utilisateurs leur besoin, cadrer vis-à-vis à de la vision (et parfois dire non) et avoir 90% des informations de la user story lorsque nous l’abordions en séance d’affinage. Nous avons gagné beaucoup de temps en allers-retours inutiles et en discussions stériles.  

L’UX designer : comment l’intégrer ?

Vous avez sûrement dû vous poser la question « Comment intégrer les profils « spécifiques » dans un projet agile comme les architectes, les experts ou encore les UX Designer ? »
Le facteur primordial pour le rôle d’UX Designer est de l’impliquer le plus en amont possible dans le projet et tout le long. Dans notre cas, il a été présent dès le cadrage du projet (avant le sprint 0) ce qui a permis : 

• À notre client de se projeter plus facilement dans le projet grâce à des maquettes en fils de fer. Le client a également pu plus facilement exprimer son besoin grâce à ce travail. 
• À notre UX Designer de connaitre les besoins et contraintes du client pour proposer le meilleur design et parcours client.   

Pendant le sprint 0, il a travaillé avec nous sur l’affinage des premières US pour qu’il puisse fournir les maquettes dès le sprint 1. Il a aussi défini la charte graphique et les éléments principaux de navigation. Son activité n’est pas constante tout au long du projet : au début, il doit fournir tout le socle de l’UX dans lequel les développeurs n’ont qu’à piocher pour le design des nouvelles fonctionnalités, sauf si un nouveau comportement est attendu. Dans ce cas, une intervention sur ce sujet sera nécessaire. En revanche, je trouve important qu’il soit présent jusqu’à la fin pour garantir la cohérence jusqu’à la livraison du produit final et éviter toute dérive.  

Accepter le changement 

Les trois développeurs de l’équipe étaient expérimentés sur les technologies utilisées. Un point qu’il a fallu gérer a été l’acceptation des changements, à la suite des retours utilisateurs ou suite aux découpages des US. Le fait d’itérer sur un écran et/ou une fonctionnalité, de faire une solution simple avant la solution définitive n’était pas bien compris. Il fut crucial de leur expliquer que le but était que les utilisateurs puissent se projeter sur la fonctionnalité future. Cette partie de mon job m’a demandé beaucoup d’écoute active, de compréhension des peurs sous-jacentes à ces réactions pour les aider à trouver la meilleure solution. J’ai essayé de ne jamais leur souffler une solution mais de faire en sorte qu’ils trouvent la solution adaptée à leur projet. Ils ont rapidement vu l’intérêt de montrer les fonctionnalités et d’avoir des retours. 

La phase projet : au cœur du sujet 

Périmètre / Coût / Délais 

La première chose à souligner est que nous avons respecté le budget et le délai ! Le périmètre s’est quant à lui ajusté au fil du projet. Au début, le client a choisi uniquement les besoins « MUST » que nous avons alors affinés sur notre story mapping. A la clôture du projet, en partant du story mapping initial, nous avons réalisé 99% des « MUST », 79% des « SHOULD », 65% des « COULD » et 50% des « WOULD » (méthode MoSCoW) avec le même budget. Comment est-ce possible me direz-vous ? 

Voici les facteurs de réussite : 

• Une équipe stable et à temps plein pendant tout le projet 
• L’expérience des développeurs pour proposer toujours la solution la plus adaptée au besoin (et souvent la plus simple) 
• La réutilisation du socle technique d’un autre site du client qui nous a permis d’utiliser les ressources de ce socle pour des besoins métiers 
• Le PO à temps plein, impliqué, avec du pouvoir de décision et qui sait dire « Non » 
• Le travail en amont du PO avec les utilisateurs 
• Une vision claire et partagée avec tous, y compris avec les sponsors 
• L’utilisation de Drupal qui a permis une gestion facilitée des droits d’accès aux différents profils 

Si nous regardons le périmètre décrit initialement et le périmètre implémenté, nous nous rendons compte que certaines fonctionnalités n’ont pas été réalisées car elles sont devenues inutiles à la suite des retours utilisateurs. A l’inverse, et pour l’exemple, une démonstration nous a mis en lumière que le collaborateur à l’accueil du centre avait besoin tous les jours du planning des RDV pour faciliter l’accueil des volontaires, besoin qui n’avait jamais été évoqué. Nous avons pu ajouter ce retour dans notre backlog et le faire dans le sprint suivant car indispensable pour le bon fonctionnement de l’application. 

Le plus important d’abord 

Avec un projet agile, la priorisation doit être axée sur le plus important d’abord et non le plus compliqué ou risqué. Nous en avons fait l’expérience : un besoin primordial exprimé par les utilisateurs était la possibilité pour l’application de se connecter à leur agenda Outlook pour pouvoir lire leurs RDV et inscrire les nouveaux pris par les volontaires pour participer aux tests cliniques. Nous avions donc mis les US sur ce sujet dès le deuxième sprint. Malheureusement, suite à un problème sur l’accès sécurisé à Outlook, nous n’avons pas pu réaliser ces besoins qui se sont vus repoussés en sprint 6 (sur 8). La conséquence a été double : 

1. Nous avons dû avancer en imaginant la solution pendant 4 sprints, ce qui a été un changement de priorisation énorme pour le PO. Nous avons dû également développer des solutions alternatives en attendant d’avoir la solution Outlook pour pouvoir tester et avoir un logiciel opérationnel ; solutions qui ont bien sûr été défaites par la suite. 

1. Lorsque la solution Outlook a pu être implémentée, nous avons découvert plein de petites subtilités ou de problèmes sur les fonctionnalités liées, ce qui nous a demandé un important travail de tests, d’ajout d’US pour aménager les besoins pourtant validés par les utilisateurs aux nouvelles contraintes.  

Attention aux tests 

Une autre leçon que je retire de ce projet est l’importance des tests. Souvent en agile, nous négligeons un peu les tests car nous faisons les fonctionnalités au fur et à mesure. C’est là où des tests automatisés pourraient être fort utiles. Dans notre cas, les critères d’acceptation étaient bien notés dans les US, mais il manquait des tests plus globaux (ou TNR – Test de Non Régression) pour vérifier que l’ajout de ce besoin à la fonctionnalité globale ne l’avait pas altérée.  

Nous avions également prévu des tests métiers mais ceux-ci ont été réalisés avec un décalage d’au moins un sprint, du fait du manque de temps de la part de certains intervenants. La conséquence a été de voir des anomalies ou nouveau besoin tardivement et de devoir les gérer dans l’urgence lors des derniers sprints, mais tous les retours pertinents étaient pris en compte. Bref, une attention toute particulière sur les tests en général est à avoir en agile (et même en cycle en V) en gardant en tête le dicton « Just in time and just enough » (« Juste à temps et juste ce qu’il faut »).  

Si c’était à refaire, je préconiserais les points suivants : 

• Ajout de tests automatisés sur les fonctionnalités clés 
• Systématisation des TNR 
• Implication et dégagement du temps des métiers pour faire les tests « Just in time » 

Implication des métiers  

Les utilisateurs finaux ont été identifiés très tôt et nous avons tenu à ce qu’ils soient présents aux différentes cérémonies et aux tests. Nous avons ajouté des ateliers spécifiques avec eux en milieu de projet pour : 

• Leur rappeler l’importance de leur rôle 
• Leur demander si notre façon de communiquer avec eux était satisfaisante ou non et comment l’améliorer 
• Leur demander quels sont les nouveaux besoins qu’ils ont identifiés aux vues des précédentes démonstrations. 

Une implication forte de la part des intervenants métiers est primordiale pour la réussite d’un produit car sans eux nous ne pouvons que faire « un produit » et pas faire « LE bon produit ». 

Rédaction des spécifications

Attention, je vous vois venir en me disant que nous avions des spécifications donc nous n’étions pas tout à fait en agile ! Et bien si, car nous avons rédigé des spécifications non pas en amont des US pour dire à l’équipe de développement ce qu’il fallait faire, mais en aval de la discussion que nous avions eu lors de l’affinage de l’US. Ces spécifications servent uniquement pour la maintenance et les futures évolutions du produit. 

Il y a eu deux types de spécifications rédigées pendant ce projet : 

• Les spécifications techniques que la dev team a produites tout au long du projet soit dans l’US elle-même soit lors du sprint N+1 sur les US terminées du sprint précédent. 
• Les spécifications fonctionnelles qui ont été rédigées par moi-même sur les deux derniers sprints et sur les 2 premières semaines de garantie.  

Aussi bien l’une comme l’autre, le niveau de détails a posé quelques soucis par la suite (découverte de bugs et de contraintes techniques tardivement) et je pense que nous aurions dû les faire plus au fur et à mesure avec des validations intermédiaires.  

Transition avec l’équipe TMA (Tierce Maintenance Applicative) 

Lorsque nous avons démarré le projet, nous savions que l’application allait devoir être maintenue. Nous avons malheureusement traité ce sujet tardivement, ce qui n’a pas permis de fluidifier la passation. L’après–projet doit être géré au plus tôt, ainsi que le transfert de connaissances. La solution idéale pour moi est d’avoir une maintenance gérée directement par l’équipe initiale et qui continue à faire les évolutions.  

La contractualisation

Pour finir sur les points positifs, nous avons géré ce projet avec une contractualisation au forfait qui n’a pas été du tout contraignante pour plusieurs raisons : 

• Aucun suivi à la lettre du contrat quant aux périmètres engagés. Comme expliqué plus haut, nous avons suivi le besoin des utilisateurs tout en gardant en tête notre engagement.  
• Un suivi financier allégé niveau SQLI puisque nous avions le bon nombre de jours par personne et par sprint pour l’ensemble du projet. 
• Les indicateurs suivis étaient ceux de l’agilité (nombre d’US dans le backlog/réalisé, nombre de points dans le backlog/réalisé, velocity chart, burndown chart) et aucun engagement n’était fait dessus. 

En conclusion, ce projet est une réussite (utilisateurs satisfaits, client content, projet délivré dans les temps avec le budget respecté et l’équipe Scrum contente de son expérience) malgré quelques écueils grâce auxquels nous avons tous grandi pendant ce projet et tiré des enseignements pour les futurs projets. 

Aurélie Viars

agile coach SQLI