Démarrer un projet agile: un retour d’expérience

Démarrer un projet agile: un retour d’expérience


Depuis plusieurs années maintenant, l’agilité est devenue une pratique courante et bien ancrée dans le monde du développement logiciel. Cependant, l’expression de celle-ci ne se limite bien souvent qu’à la seule phase d’implémentation (développement itératif sous forme de sprints, mêlée quotidienne, rétrospective, revue de sprint, bla-bla). Dans le contexte d’un prestataire de services, il existe toujours une étape plus ou moins floue dans le déroulement d’un projet:  celle de la définition et de la compréhension du besoin initial. Bien que vous pratiquiez l’agile, que se passe-t-il vraiment entre le moment ou un client vous sollicite pour un éventuel projet et celui du premier jour de son développement? Comment faites-vous pour construire votre backlog? Comment vous assurez-vous de fournir une estimation du travail global fiable pour que votre client prévoie le budget approprié? Cet article a pour objectif de vous expliquer la manière dont nous avons répondu à toutes ces problémtaiques en mettant en place une méthodologie de « démarrage de projet ».

Être agile, c’est aussi rester cohérent tout au long d’un projet, de la manière dont vous définissez les besoins, les organisez, jusqu’à vos manières de les implémenter.


 Notes importantes:

  • La pratique de démarrage de projet étant évolutive et adaptable par nature, le contenu de cet article peut être soumis à des modifications régulières. D’ailleurs n’hésitez pas à réagir sur le sujet dans les commentaires et partager vos idées pour démarrer un projet agile!
  • Ceci est un retour d’expérience issue d’une réalité qui peut être différente de la votre…Le contenu de cet article est donc loin d’être l’unique vérité sur le sujet.

Notre contexte de travail

Avant toute chose, pour mieux comprendre pourquoi nous avons mis en place cette façon de faire, il est important de connaître notre contexte de travail et les contraintes qui s’y appliquent.

Je travaille donc dans une entreprise qui se place en tant que fournisseur de services, spécialisée dans la création et la mise en place de solutions logicielles entièrement personnalisées et/ou basées sur les plateformes SharePoint/Office 365. Le panel des projets s’étend donc d’applications métiers totalement sur mesure à des intranets d’entreprise en passant par des sites web. Nous développons nos solutions selon les préceptes agiles et plus particulièrement SCRUM. Nos équipes sont donc composées de Scrum Masters ainsi que de développeurs habitués et formés à ce cadre de travail. À ce titre, nous disposons d’outils adéquats et de pratiques de développement éprouvées. Bref, tout cela pour dire que, d’un point de vue « opérationnel » de l’agilité, nous disposons déjà d’une base solide.

Notre application de SCRUM

Voici notre processus global tel que nous l’appliquons chez nous (à quelques variantes près selon les équipes) :

Notre application de SCRUM

  • Le backlog

En entrée de tout projet, une liste des fonctionnalités priorisée dans un « backlog » et exprimées sous forme d’user stories (nous détaillerons le format pour ces dernières plus loin dans l’article).

  • Le « backlog grooming »

Cette étape permet spécifier dans le détail le comportement et les critères d’acceptations des user stories potentielles prévues pour le prochain sprint (selon leur ordre de priorité). C’est à ce moment que l’on s’intéresse, par exemple, à savoir si le bouton est bleu ou rouge et placé à tel ou tel endroit dans l’interface. Généralement, un analyste (le plus souvent le Scrum Master lui-même), le PO et au moins un développeur sont présents lors de cette réunion.

Le « grooming » est fait en parallèle du déroulement d’un sprint de développement, l’objectif étant que la majeure partie du travail de spécification soit déjà réalisé avant l’étape de sprint planning.

Note : il s’agit d’une étape récurrente qui se concentre sur le court terme. Il n’est donc pas nécessaire (et pertinent) de « groomer » trop de stories d’un coup.

  • Sprint planning

Le sprint planning sert à confirmer les user stories avec l’équipe juste avant leur implémentation et lever les dernières ambiguïtés. À ce titre, elles sont systématiquement réestimées à ce moment, ce qui parfois peut changer leur priorité dans le backlog.

Le PO sélectionne les user stories qu’il souhaite voir implémentées lors du prochain sprint et les mets dans un « Sprint Backlog ». À quelques exceptions près, il s’agit des mêmes que celles de l’étape de grooming. L’équipe de développement, le PO et le Scrum Master sont présents à cette étape.

  • Pourquoi séparer « grooming » et « planning » ?

Lors du « grooming », il se peut que certains éléments ne soient pas encore connus pour certaines « user stories » (par exemple une information technique manquante, un document, etc.). Cette étape, réalisée en parallèle du développement, permet donc de mitiger ce point, et lever les alertes lorsqu’un bloquant ne permet pas de débuter le développement d’une fonctionnalité. Le PO ou l’équipe dispose alors de plus de temps pour rassembler les informations manquantes avant le début du sprint. Cela fait partie de ce que nous appelons notre « DoR » (« Definition of ready »).

  • Sprint de développement

Les fonctionnalités identifiées dans le sprint backlog sont développées. Leur spécification ne peut pas être modifiée pendant cette période.

De manière générale, la durée de nos sprints est de 2 semaines : assez pour développer quelque chose apportant de la valeur et assez court pour être réactifs aux changements. De même nos équipes peuvent aller de 2 à 5 développeurs.

  • Revue de sprint

La revue de sprint sert à présenter au PO les fonctionnalités développées dans le cadre du sprint. En règle générale, la démonstration se contente de démontrer point par point les critères d’acceptations de chacune de stories et ainsi valider la conformité par rapport au besoin initial. En aucun cas, la revue de sprint n’est destinée à exécuter des tests exhaustifs (QA) !

Ici le PO a la possibilité d’inclure les personnes de son choix à la réunion.

  • Rétrospective de sprint

Étant donné que l’agilité s’inscrit également dans une philosophie d’amélioration continue, la rétrospective sert à identifier ce qui s’est bien passé, ce qui s’est mal passé, et les choses à éviter ou améliorer pour les prochains sprints. À cette étape, pas de langue de bois, on se dit clairement les choses dans le but d’avancer ensemble ! En pratique, la revue de sprint et la rétrospective sont réalisées dans la même journée.

  • Produit fonctionnel

À chaque fin de sprint, nous livrons une version fonctionnelle de l’application. Pour permettre cela, il est donc impératif de disposer d’un processus de déploiement automatisé adapté permettant à la fois de fournir au client une version utilisable dans un environnement dédié contenant les dernières fonctionnalités et aussi minimiser le temps de déploiement pour l’équipe de développement.

  • Période de tests et ajustements

À la suite de la revue de sprint, nous allouons une période d’une semaine pour permettre au PO d’effectuer des tests fonctionnels complets et valider les fonctionnalités développées. Son rôle est donc très important à ce niveau.

Si des anomalies ou bugs sont soulevés, alors ils seront corrigés, non pas immédiatement au sprint suivant, mais au sprint d’après (entre temps un autre sprint a commencé). Au même titre que les user stories, ils sont priorisés et estimés selon leur gravité.

Pour replacer la phase de démarrage de projet dans notre contexte, il faut donc garder en tête les deux contraintes suivantes :

  • Contrainte #1: Étant donné que nous travaillons en agile, toutes les fonctionnalités d’un projet doivent obligatoirement être exprimées dans un backlog priorisé sous forme d’user stories avant de pouvoir être réalisées dans le cadre de sprints de développement.
  • Contrainte #2: Étant un fournisseur de services, un projet ne peut pas commencer sans qu’une proposition n’ait été remise ainsi qu’un contrat signé. Ce point est important, car elle nous oblige donc à fournir en amont une estimation globale et totale de l’effort requis pour la réalisation du projet (permettant de budgeter), principe allant à l’encontre de la philosophie agile. Nous y reviendrons plus tard dans la suite de l’article.

Génèse du démarrage de projet

Tout d’abord, le terme « démarrage de projet » n’est pas apparu de nulle part. L’idée provient en effet d’une conférence issue de l’Agile Tour Montréal 2014 que plusieurs personnes chez nous ont eu l’occasion de voir et qui nous a fait beaucoup réfléchir sur nos façons de faire. Il s’agit d’une session donnée par Isabelle Thérien sur la manière de démarrer un projet dans un mode de gestion agile. Le contenu de la session est disponible ici.

Nous nommons « phase de démarrage de projet » toutes les étapes intervenant entre le moment ou un client exprime le souhait de développer un nouveau système ou application (via une sollicitation directe ou indirecte) et celui de son premier jour de développement dans le cadre d’un sprint.

Démarrage de projet

Quel était le problème ?

À l’époque, bien que nous avions une application rigoureuse de SCRUM au quotidien, plusieurs problèmes demeuraient encore dans le déroulement de nos projets entrainant soit des retards soit des dépassements de budgets. Voici la séquence que l’on observait globalement entre ces deux moments clés et les conséquences que cela engendrait :

1- Récupération des informations du projet

Le processus commençait par la récupération de toutes les informations concernant le projet à réaliser. Ici, nous pouvions avoir, au choix :

  • Un cahier des charges ou un document d’analyse détaillé de 350 pages (à peine exagéré) rédigé par un consultant externe ou un analyste d’affaires pour le compte du client et expliquant tous les requis du projet (c’est par exemple un cas de figure qui se rencontre fréquemment dans le cadre d’appels d’offres).
  • Des bouts de mails ou des documents de synthèse d’approximativement 2 pages.
  • Des notes rédigées après des réunions avec des personnes pas rapport décrivant brièvement les requis (typiquement, des notes prises après des réunions d’avant-vente).

Dans tous les cas, et de manière générale, les besoins exprimés dans ces documents étaient souvent loin de prendre en compte l’avis de tout le monde (et en particulier les utilisateurs finaux pour qui le système était à la base destiné…). De même, les fonctionnalités étaient souvent orientées très technique du genre, « nous souhaitons un moteur de recherche ou un service web qui fait telle affaire » …Phénomène encore plus prononcé avec les projets SharePoint/Office 365…

2- Déchiffrage, tentative d’estimation et proposition

La prochaine étape consistait à réaliser une estimation de l’effort total nécessaire sur la base de ces informations. Étant donné qu’il demeurait quasi impossible de commencer un projet en prenant les besoins tels quels, nous devions ici systématiquement les retravailler (et accessoirement les comprendre) et les mettre au format adéquat (comprenez, dans un backlog exploitable dans des sprints de développement). De plus, comme nous n’étions généralement pas experts du domaine du client, il fallait sans cesse éclaircir les points d’incompréhension ou approfondir le besoin engendrant des allers-retours incessants.

Finalement, pour éviter de perdre trop de temps, le réflexe naturel était donc de faire des suppositions, des hypothèses ou de chercher des similitudes avec des réalisations existantes. Nous faisions donc rentrer inévitablement une grosse part d’incertitude qui traduisait nécessairement un risque et donc gonflait logiquement nos estimations.

Nous nous retrouvions donc avec une estimation approximative et artificiellement rehaussée pour anticiper le risque que nos suppositions se révèlent fausses en cours de projet.

3- Bricolage et effet boule de neige 

Pour peu que le projet soit effectivement signé, nous rencontrions fréquemment des problèmes de délimitation de périmètre pour chaque fonctionnalité entrainant soit des dépassements de coûts soit des conflits avec le client sur des points de détails non abordés auparavant (par exemple qui justifiaient une estimation revue à la hausse par rapport au budget initial dû à un bricolage à réaliser sur la technologie cible SharePoint qui n’était pas prévue pour ça à la base). De même, certaines stories mettaient plusieurs sprints à se finir. En bref, on ne savait jamais vraiment ce que ça devait faire, quand cela devait finir et si cela répondait vraiment au besoin. Nous perdions donc beaucoup de temps à redéfinir les choses, parfois de manière très éloignée de ce qui était imaginé initialement. En fin de compte, il arrivait que le client doive « couper » dans ses fonctionnalités pour que cela rentre dans son budget ou sa date de livraison. Il arrivait également que du travail non prévu initialement vienne bousculer le planning, comme des preuves de concepts à ou bien des wireframes ou des maquettes à réaliser.

Plutôt que s’attaquer aux conséquences, nous avons donc raisonné à la racine du problème : à aucun moment, il n’y avait eu de vraie discussion entre nous et le client assurant une compréhension mutuelle des attentes envers le projet. Difficile, dans cette situation, d’envisager que celui-ci se passe sans accrocs par la suite…

C’est donc pour cette raison que nous avons mis en place cette fameuse « phase de démarrage » dont voici les principales étapes :

Étapes de la phase de démarrage

Les objectifs sont les suivants :

  1. Réduire considérablement le risque de part et d’autre avant de démarrer un projet en instaurant une vraie discussion en amont permettant une compréhension globale et commune du système à développer.
  2. Renforcer la confiance client/fournisseur en confrontant les idées pour construire ensemble un backlog prenant en compte les réalités de chacun.
  3. Mettre de côté la technologie pour s’intéresser aux besoins réels et construire un backlog axé véritablement sur la valeur d’affaires (et non basé sur une pensée unique).
  4. Aller au bout de la philosophie agile sans la restreindre seulement à sa partie opérationnelle.
  5. Éviter d’emblée une relation conflictuelle pour la suite du projet où chacun se prévoit sa petite marge de risque de son côté. Les estimations sont faites en toute connaissance de cause.
  6. Réduire considérablement la durée des étapes de backlog grooming et de planning en définissant les éléments majeurs de chaque fonctionnalité bien à l’avance.
  7. Casser les silos en définissant une approche unifiée et connue de tous les intervenants.
  8. Définir un cadre clair et efficace à la définition d’user stories pour toutes les équipes de développement.

La suite de ce guide explique la mise en œuvre de chacune des étapes ainsi que ses objectifs.

S’assurer des prérequis

Avant de vous lancer dans un démarrage de projet, il est impératif de s’assurer de quelques prérequis.

(Optionnel) Comprendre l’agilité

Comme énoncé dans le chapitre « Notre contexte de travail », nous travaillons exclusivement en mode agile et adaptons nos méthodes de travail en conséquence que cela soit au niveau des outils ou de l’organisation du travail. Si cela est devenu une habitude pour nous, cela ne l’est pas forcément pour nos clients, particulièrement pour les grosses entreprises possédant des habitudes plus traditionnelles. Dans ce cas, nous réserverons optionnellement une journée d’introduction/formation pour initier le client aux concepts de l’agilité et aux techniques d’estimations. Inutile ici de rentrer dans les détails, dans tous les cas, l’apprentissage se fera tout au long du développement du projet.

Planifier les ateliers en invitant les bonnes personnes

Avant de planifier les ateliers de démarrage, il est bien important d’identifier les bonnes personnes :

  • Un « Product Owner » compétent et engagé ayant à cœur la réussite de son projet

Un « Product Owner » (ou PO pour les intimes) est LA personne responsable des fonctionnalités à développer dans le cadre du projet. Sa désignation ne doit pas se faire par défaut au risque de grosses désillusions pouvant mener à l’échec du projet ! À ce titre, elle doit nécessairement posséder une bonne compréhension d’ensemble du ou des domaines d’affaires concernés et être à même de pouvoir challenger les utilisateurs sur leurs besoins. De même, il doit savoir faire des compromis le moment venu.

De même, le PO est le contact privilégié entre le client et l’équipe de développement. Lorsque l’on parle fonctionnel, il est le seul ayant le pouvoir de décision final.

  • Des assistants au PO

Il serait utopique (et potentiellement dangereux) de penser qu’une personne détienne à elle seule l’intégralité de la connaissance sur les fonctionnalités du système à développer. C’est pourquoi, il est coutume d’identifier en périphérie du PO, des personnes pour l’aider dans sa tâche. Généralement celles-ci sont-elles même représentatives d’un domaine d’affaires particulier (par exemple les ressources humaines ou les finances, etc.).

Le choix de ces personnes se fait à la discrétion du PO. Cependant, nous recommandons généralement de ne pas trop multiplier les intervenants sous peine de ralentir la prise de décision et par conséquent, le développement du projet (5 personnes maximum semblent être un bon chiffre).

Attention toutefois, ces personnes ne peuvent pas interagir directement avec l’équipe de développement. Elles peuvent seulement guider le PO dans ses choix !

Note : faire participer des personnes issues des TI est très rarement bénéfique et fait rapidement tomber les discussions dans des détails techniques peu pertinents à ce stade du projet (des exceptions peuvent arriver bien sûr). Par conséquent, mettez d’emblée un bémol au moment de planifier vos ateliers.

Préparer les futures discussions

Tout comme le domaine du développement logiciel, celui de nos clients se révèle parfois complexe, avec ses propres règles et codifications. Pour faciliter une compréhension mutuelle des contraintes de chacun, il est dans l’intérêt commun de démystifier en amont le plus possible ces spécificités avant l’élaboration du backlog. Cela vous permettra de poser les bonnes questions et gagner en efficacité lors des ateliers.

Pour cela, il existe deux façons de faire (qui peuvent être combinées) :

  • Scenario #1 : Votre client a une bonne idée de ce qu’il veut, et il a formalisé le tout selon plusieurs documents, schémas, etc. (par exemple dans le cas d’un appel d’offres) ? Parfait ! L’idée est de prendre le temps de lire et d’étudier toutes les informations pertinentes permettant de préparer un plan personnalisé pour les exercices de définition de backlog. En résumé, extraire les questions pertinentes relatives à la documentation. Attention, on ne rédige pas de backlog ici.
  • Scenario #2 : Votre client a une idée globale de ce qu’il veut, mais il n’a encore rien formalisé ou il souhaite tout simplement étayer le travail existant ? Aucun problème ! Dans ce cas de figure, nous proposons la rédaction de ce que nous nommons : un « questionnaires préliminaire ».

Explications :

Comme un projet n’est jamais la traduction des besoins d’une seule et unique personne, la meilleure façon de connaître les attentes d’un système à développer est encore de demander leur avis aux premiers concernés : les utilisateurs eux-mêmes.

Cependant, selon la taille des organisations, il peut être très fastidieux de soumettre un questionnaire nominatif à chacun des utilisateurs (aussi bien pour la diffusion que pour l’exploitation des réponses). C’est pourquoi, nous privilégions l’envoi de questionnaires à seulement quelques groupes représentatifs du système. Ces groupes sont représentés par les personnes identifiées comme assistants du PO (ou autre si pertinents), agissant en tant que représentants d’un groupe pour un domaine d’affaires.

Chaque responsable doit remplir ce questionnaire en traduisant les besoins des utilisateurs du groupe qu’il représente. Il est ainsi libre de consulter qui il le souhaite pour l’aider dans sa tâche.

Au final, il en va de la responsabilité du PO de s’assurer que tous les questionnaires soient correctement remplis et d’en assurer l’acheminent à notre équipe une fois complétés. Généralement, une période d’environ 2 à 3 semaines est nécessaire selon la taille de l’organisation pour y répondre. Après cette période, nos équipes se chargent de la compilation des réponses pour établir un plan et une série de questions à aborder lors de l’atelier qui cadrera les discussions.

Dans la réalité, l’exploitation des réponses est à titre indicatif et sert surtout à vérifier que rien d’important n’a été oublié au cours des ateliers. Pour la rédaction et la diffusion des questionnaires, nous utilisons TypeForm, un outil de questionnaire en ligne.

Que retrouve-t-on dans un questionnaire ?

Dans ce genre d’exercice, le but n’est pas de connaître les détails, mais plutôt d’identifier des grandes fonctionnalités, les façons de faire ainsi que les types d’informations manipulées pour poser les bonnes questions par la suite. Dans le cadre d’une évolution de système existant, nous cherchons par exemple à identifier les irritants/bloquants ou, au contraire, les choses essentielles à garder.

Déroulement des ateliers

L’étape principale d’un démarrage de projet prend la forme d’un atelier sur plusieurs jours (généralement 2 ou 3 selon la taille du projet) visant à obtenir en sortie :

  • une compréhension globale et commune du projet par tous les participants, traduite sous forme d’une charte de projet.
  • une liste de fonctionnalités priorisées dans un backlog, permettant une estimation réaliste du coût de développement total. Votre client doit très certainement débloquer un budget pour la réalisation de son projet, votre but est donc de lui donner un chiffre relativement cohérent selon les détails du backlog que vous aurez déterminé ensemble.

 Pourquoi 3 jours ?

Tout simplement car répartir cet atelier sur une période discontinue fait perdre totalement la dynamique d’un groupe. Pour l’avoir expérimenté, nous vous le déconseillons. La créativité et la productivité sont au maximum lorsque l’atelier est fait de manière continue avec les mêmes personnes (ce qui semble logique finalement…).

 Qui doit y participer ?

  • Le PO (obligatoire)
  • Les assistants du PO
  • 2 animateurs

 Conseils

  • D’un point de vue du fournisseur, mener un atelier à seulement une seule personne est peu envisageable. C’est en effet un exercice assez intense au niveau intellectuel et physique qui nécessite au moins 2 personnes. Alternez les rôles d’animateur et de preneur de notes pendant les journées.
  • Imposez une limite de 5 personnes au total. Au-delà, cela demande beaucoup de discipline.

Quel est le contenu de ces journées ?

Un projet ne se limite pas uniquement à la définition de ses fonctionnalités. C’est pourquoi nous abordons également tout le contexte global lié à celui-ci (ses objectifs, les personnes impliquées, etc.) pour permettre une meilleure compréhension de l’ensemble.

Chacune des journées est divisée en un certain nombre d’exercices, chacun ayant une durée approximative (« Timebox ») et des objectifs prédéfinis. Nous favorisons une approche ludique et interactive permettant de former une cohésion d’équipe forte. Dans la pratique, nous offrons généralement le lunch et organisons un 5@7 pour se changer les idées au milieu des trois jours.

Voici la liste des exercices :

  • Bris de glace
  • Nom du projet
  • Énoncé de la vision
  • Objectifs d’affaires
  • Équipe
  • Contraintes
  • Événements probables
  • Fonctionnalité du backlog
  • Plan de livraison
  • (Bonus) Wireframes et maquettes

Mise en place de la salle

L’organisation de la salle de travail est un élément important dans le bon déroulement des ateliers et ne doit pas être prise à la légère. Voici notre organisation :

Room1

Setup salle #2

  1. Les différentes zones de travail: Pour faire référence à un certain Laurent D. « Un mur, ça ne sert à rien, autant le mettre à profit ». En effet, au lieu d’utiliser des tableaux mobiles, nous écrivons directement sur le mur (ne faites pas ça sans peinture spéciale 😉 !). De même, certains exercices sont réalisés à même la table.
  1. L’agenda de l’atelier: 3 colonnes « À faire », « En cours », « Terminé » avec un post-it par exercice permettant de suivre le fil de la journée.
  1. La zone « fil conducteur »: zone réservée aux éléments en fil conducteur pendant les 3 jours (glossaire, todos, charte de projet). De même ici, se trouve tout autres schémas transversaux liés au projet permettant une meilleure compréhension globale (organigramme ou structure d’entreprise, processus métier, etc.) et dessinés en cours d’atelier.

Vos armes durant l’atelier :

Matériel

  •  Conseils
  • Bannissez l’utilisation des ordinateurs portables ! C’est le meilleur moyen pour ne rien écouter…

Bris de glace (10 minutes)

  •  Objectif(s)

Que faites-vous en dehors du travail ? Quels sont vos loisirs ? Bref on apprend à se connaître. Après tout nous allons travailler ensemble. Cet exercice peut paraître un peu simpliste, mais il est bien important de mettre à l’aise tout le monde dans ce genre de rencontre. La confiance mutuelle est un facteur essentiel.

  •  Déroulement de l’exercice

Un tour de table bien classique !


Nom de projet (20 minutes)

  •  Objectif(s)

Parce que c’est toujours plus sympa d’avoir un nom de code pour un projet. Attention, il ne s’agit pas du nom de l’application que vous allez développer, mais juste un nom plus convivial pour tout le monde, autre que le classique « projet de site web du client X ou Y » qui ne fait pas vraiment rêver.

Cet exercice est aussi là pour jauger les personnes présentes. On remarquera tout de suite les personnes « leaders » et celles plus effacées. De même, rien qu’avec un nom, on peut tout de suite déceler l’orientation d’un projet.

  •  Déroulement de l’exercice
  • Brainstorming ouvert. Chacun énonce des noms à la volée qui sont marqués au tableau. Après 5 minutes, on procède à un vote directement au tableau.

Énoncé de la vision (60 minutes)

  •  Objectif(s)

Certainement un des exercices le plus important de l’atelier. Il s’agit ici de définir l’objectif principal du projet en une phrase compréhensible par tous. En gros on cherche ici à répondre à la question « Pourquoi fait-on ce projet finalement ? ». L’objectif est de permettre à tout le monde (touchant de près ou de loin au projet) de comprendre son but, sans pour autant connaître tous les détails.

Pour nous aider, nous partons généralement du modèle de phrase suivant :

  • Pour (A qui bénéficie le système à développer ?)
  • Qui (Quel problème cherche-t-on à résoudre ou améliorer ?/ Quel est notre souhait principal ?)
  • Le (projet X ou Y) est un/une (nature/description du système)
  • Qui (bénéfice principal, raison de l’utiliser)
  • Contrairement à (alternative),
  • Notre produit (ou le projet X ou Y) (se différencie ainsi…)
Exemple d'énoncé de vision

  •  Déroulement de l’exercice
  1. Écrivez la phrase sur un tableau et indiquez un numéro pour chaque espace vide à compléter après les mots clés.
  1. Demander à tous les participants de compléter les bouts de phrases manquants en utilisant un post-it par numéro (laisser environ entre 5 et 10 minutes).
  1. Faites la synthèse directement au tableau en juxtaposant les post-it de tout le monde. Ici votre rôle sera de challenger les différences et approfondir les similitudes. Attention à ne pas dépasser le temps, cet exercice pouvant être très chronophage.
  •  Conseils
  • Si les participants éprouvent de la difficulté à exprimer la vision, commencez par définir ce que le système n’est pas en le comparant avec soit un autre système de l’entreprise ou un outil externe.

Objectifs d’affaires (60 minutes)

  •  Objectif(s)

Cet exercice va permettre d’identifier les objectifs d’affaires secondaires (après celui énoncé dans la vision) selon les principes S.M.A.R.T. On cherche ici à déterminer les critères permettant de savoir si, après X temps, le projet s’est révélé être un succès ou échec selon les attentes de la vision initiale.

  •  Déroulement de l’exercice
  1. Les critères S.M.A.R.T sont expliqués brièvement à tous les participants.
  1. Chacun rédige sur un post-it différent ses objectifs et les mets au tableau une fois terminés.
  1. La synthèse est faite au tableau en rassemblant les similitudes et en challengeant la pertinence par rapport à la vision initiale.
  •  Conseils
  • Généralement, un horizon d’un an est suffisant pour la définition des objectifs. Au-delà, cela devient moins réaliste et vous pouvez être sûrs que tout le monde aura oublié d’ici là. Notez qu’il est possible de réduire la période selon la taille du projet (3 mois est généralement un bon chiffre pour commencer à mesurer des choses).
  • Chaque objectif doit être en lien direct avec la vision énoncée précédemment. Si ce n’est pas le cas, vous pouvez être amené à redéfinir cette dernière au besoin.
  • La notion la plus importante dans cet atelier est la notion de mesurabilité. Insistez bien sur ce point ! S’il n’est pas possible de mesurer un objectif, comment peux-t-on dire que celui-ci a été rempli ?
  • Les sondages ou questionnaires restent les meilleurs outils pour mesurer des objectifs qualitatifs, par exemple, mesurer la satisfaction globale des utilisateurs par rapport à nouvelle solution. D’ailleurs, cela peut être exprimé plus loin en tant que fonctionnalité à part entière du système à développer.
  • Ce n’est pas grave si vous n’avez qu’1 ou 2 objectifs. L’important est qu’ils soient atteints à la fin de l’horizon décidé.

Équipe (60 minutes)

  •  Objectif(s)

Pour optimiser la communication tout au long du projet, il est important d’identifier les personnes impliquées de près ou de loin dans le projet ainsi que leur rôle, aussi bien du côté du client que du côté du fournisseur.

  •  Déroulement de l’exercice
  1. Dessiner ce schéma au mur puis de demander aux participants de placer les intervenants du projet selon leur pertinence :

Exercice de détermination de l'équipe

En vrai

  •  Conseils
  • Faites le parallèle avec un envoi de mail :
    • To: Po SM, et personnes à l’intérieur du cercle qui sont concernées au quotidien.
    • Cc: Personnes à l’extérieur du cercle
  • Faites attention à ne pas lister toute l’entreprise (genre les managers des managers) ! Gardez ça pertinent dans le contexte du projet, ce n’est pas un organigramme.

Contraintes haut niveau (30 minutes)

  •  Objectif(s)

Nous souhaitons ici mettre en lumière tout aspect particulier du projet qui pourrait avoir une influence sur le périmètre des fonctionnalités à venir.

  •  Déroulement de l’exercice
  1. Sous forme de discussion ouverte. Les animateurs proposent des pistes de contraintes, parmi lesquelles nous trouvons parfois :
    • Besoin de mobilité (affichage sur ordinateur seulement ou téléphone, tablette, etc.)
    • Navigateurs à supporter (IE x, Edge, Firefox, Chrome, Safari, etc)
    • Performance de l’application
    • Normes particulières à rencontrer (ex.: normes ISO)
    • Esthétisme du UI/UX (vise-t-on un prix international de design?)
  •  Conseils
  • Pour les points plus qualitatifs (esthétisme, performance, etc.), vous pouvez leur demander de quantifier l’importance sur une échelle de 1 à 5.

Événements probables (60 minutes)

  •  Objectif(s)

C’est un fait : le déroulement d’un projet informatique n’est jamais un long fleuve tranquille. Bien souvent il peut survenir un certain nombre d’événements probables ou improbables durant la phase de développement (et même après) ayant un impact direct sur le projet. Dans cet atelier, nous tentons d’identifier ces événements en favorisant ceux avec un impact positif et éviter ceux négatifs. En d’autres termes, nous faisons de la gestion de risques. Pour chacun, nous évaluons un plan d’action pour le favoriser ou au contraire le réduire. Le plan d’action peut se traduire en une seule phrase simple.

  •  Déroulement de l’exercice
  • Dessiner le schéma suivant au tableau. Sur l’axe des abscisses, la probabilité que l’événement se produise. Sur l’axe des ordonnées, le degré d’impact de celui-ci sur le projet (favorable ou non)
  • Les participants notent chaque événement selon la position qui lui parait la plus pertinente
  • Synthèse directement au tableau et rédaction du plan d’action pour chaque.

Exercice d'événements probables

  •  Conseils
  • Il est bien important de ne lister que les événements pouvant arriver pendant le projet et non avant ou après.
  • Se limiter à des choses vraiment pertinentes sur lesquelles on peut agir. Trop d’événements paraît peu réaliste et surtout difficile à gérer, essayer de réduire au maximum. Attention, cet exercice est chronophage si non cadré correctement.

User Stories (1,5 jours)

  •  Objectif(s)

Appelées également dans la littérature « Product Backlog Items », leur définition suit généralement un formalisme bien particulier permettant un découpage optimal de la charge de travail dans un mode de fonctionnement agile. L’ensemble des fonctionnalités constitue le backlog du projet.

Dans cet exercice, il ne s’agit pas d’analyser les fonctionnalités dans le détail (pour une raison de temps évidente) mais plutôt de définir l’information minimale nécessaire à une estimation réaliste du coût de réalisation de celles-ci par une équipe de développement. Pour chaque fonctionnalité, on cherche notamment à obtenir (par ordre d’importance) :

  • Un profil d’utilisateur et l’action qu’il doit réaliser.
  • Une description succincte de la fonctionnalité (une phrase décrivant brièvement le fonctionnement de l’action).
  • Des exemples si le comportement nécessite des précisions. L’exemple est en effet un réflexe naturel pour clarifier les ambiguïtés. Cette pratique est empruntée du formalisme BDD (« Behavior Driven Development»). Les exemples viennent souvent clarifier un critère d’acceptation en particulier.
  • Les contraintes et les éventuelles particularités qui s’y appliquent et qui pourraient faire varier significativement le coût de réalisation.
  • Les premiers critères d’acceptations permettant de valider les principaux comportements de la fonctionnalité.

Notez que selon le type de votre projet, il se peut qu’un backlog de démarrage générique et optimisé selon notre expérience soit déjà rédigé (comme c’est le cas pour les sites web ou les intranets d’entreprises avec SharePoint). Dans ce cas, celui-ci est complété et enrichi selon les besoins (permets de faire gagner du temps).

Nous utilisons deux techniques pour la définition des stories :

  • La technique du User Story Mapping
  • La technique du Mind Mapping

Nous ne parlerons ici que de la deuxième, tout simplement car nous n’utilisons plus la première. Elle demeurait en effet trop complexe à assimiler pour des personnes non initiées et ne donnait pas les résultats escomptés en plus de prendre beaucoup de temps. En revanche nous vous la conseillons si vos participants sont déjà habitués au cadre de travail agile. Pour comprendre notre « ancienne façon de faire » (utilisant cette technique), vous pouvez consulter cet article.

La technique du Mind Mapping

Si l’informatique se nomme également la technologie de l’information, ce n’est pas sans raison. En réalité, chaque action dans un système informatique manipule un ou plusieurs types d’informations primaires plus ou moins complexes.

Le « Mind Mapping » consiste simplement à identifier ces types dans un système ou une application puis à en déduire les actions qui s’y rattachent le tout sous la forme d’un graphe logique. Cette technique est particulièrement bien adaptée pour les applications de type « gestion », c’est-à-dire utilisable directement par des personnes physiques par le biais d’interfaces. De plus, étant très visuelle, les participants l’assimilent généralement plus rapidement que la technique du User Story Mapping.

Définition des types d’information

  •  Objectif(s)

Les types d’informations représentent des entités que le système va traiter à travers différentes actions. C’est le principe même de la programmation orientée objet qui traduit des entités du monde physique (une personne, une voiture, etc.) en une entité informatique. On associe généralement à ces types des métadonnées correspondant à leurs caractéristiques intrinsèques (l’âge ou le poids pour une personne, ou la couleur ou la marque pour une voiture, etc.).

Voici quelques exemples pour mieux comprendre :

  • Dans une application de gestion des relations clients (CRM), on manipule des clients, des fournisseurs, des contrats, des factures, etc.
  • Dans un site web, ou un intranet, on manipule des pages, des documents, des nouvelles, des alertes, etc.

Bref, les types représentent tout ce qui fait du sens dans le contexte métier de votre client et qui peut être manipulé de manière unitaire dans le système. Chaque type d’information est associé obligatoirement à 4 actions au minimum que l’on nomme communément par l’acronyme « CRUD » (Create, Read, Update, Delete). Cependant, en pratique nous n’en créons souvent seulement que deux (CUD + R) :

  • Une pour la création, la modification et la suppression unitaire d’une information de ce type (CDU).
  • Une pour la visualisation du détail de cette information (R) correspondant en réalité à l’affichage de ses métadonnées.

Pourquoi distinguer une story de visualisation ?

 Cette action implique une interface pour laquelle il faut potentiellement produire un wireframe, ou une maquette et ensuite implémenter un design (CSS, etc.), ce qui représenterait une charge de travail trop importante pour être traitée dans une seule et même story (encore une fois dans un souci de découpage optimal de la charge de travail).

  •  Déroulement de l’exercice
  • Après avoir expliqué le concept, chaque participant écrit sur des post-its les types d’informations et les colle à plat sur la table.
  • Des regroupements logiques sont faits selon les types. Le but ici est de distinguer les types d’informations vraiment distincts. Par distincts, on entend les types d’informations qui ne répondent pas aux mêmes actions. Par exemple, si un document de type « procédure » et document de type « guide » possèdent sensiblement les mêmes actions avec le même comportement (ex: opérations CRUD seulement),  alors il n’est pas nécessaire de les distinguer en deux types distincts (car leur différence se situe uniquement au niveau d’une métadonnée « type »). L’exercice suivant sur la compréhension des processus d’affaires peut vous aider à identifier ces différences.

Exemple de travail sur les user stories

Regroupement_jpg

  • Conseils
  • Réaliser l’exercice sur une table plutôt qu’un tableau, cela rend les choses plus dynamiques.
  • Essayer de faire le plus de regroupements générique possibles (distinction types et sous types).

(Optionnel) Comprendre les processus d’affaires existants

  •  Objectif(s)

Chaque type d’information possède un cycle de vie dans un ou plusieurs scénarios d’utilisation global. Cependant, un type peut se matérialiser à la fois dans l’application à développer mais aussi en dehors. C’est ici que l’on aborde la délicate question des processus d’affaires de l’entreprise. Cet exercice va permettre donc de comprendre :

  • Si la future application s’insère dans un processus plus global. Si oui, à quel niveau ?
  • Quelles sont les limites du système à développer ?
  • De mettre en évidence les problématiques actuelles et réfléchir sur les axes d’améliorations possibles pour les scénarios critiques de l’application.

On s’assure ici que :

  • La vision est bonne et que l’application fait bien, à première vue, ce qui a été défini.
  • L’application ne va pas empiéter sur les plats de bandes d’une autre application et être redondante dans l’écosystème de l’entreprise. Par exemple les informations sur un « client » peuvent transiter par plusieurs systèmes hétérogènes.
  •  Déroulement de l’exercice
  • Pour chaque type d’information, dessinez son cycle de vie en commençant par le moment de sa création pour les scénarios que vous souhaitez approfondir.
  • Identifiez les grandes étapes pour ce scénario et challengez les participants (Qui fait l’action ? Pourquoi ? Que se passe-t-il ensuite ? À partir de là, que puis-je faire ? Etc.)
  • Tracez les limites du périmètre du sytème à développer.

Exemple de processus de publication existant d'une nouvelle dans un intranet

Dans cet exemple, le simple fait de dessiner le processus existant de publication d’une nouvelle dans un intranet permet de faire apparaitre une duplication de contenu dans la séquence. Dans ce cas, le périmètre du projet peut donc soit être étendu à la résolution de cette problématique soit la laisser de côté pour le moment.

Déduire les user stories

Une fois les types d’informations connus, il suffit de déduire les actions à partir de ceux-ci :

InfoMindMap

  •  Quelques règles
  • Nous n’utilisons pas le format habituel « En tant que…je veux + action », mais simplement un couple profil + action sans justification (beaucoup trop long à définir sinon…) comme le montre la figure ci-dessus.
  • Tout est une story ! (story technique, story de documentation, …). Avant tout, on cherche une répartition optimale de la charge de travail ! Les stories techniques sont par exemple très souvent ajoutées après l’atelier par l’équipe de développement (Mettre en place l’environnement de développement, etc.).
  • Si vous avez trop de stories techniques, c’est que vous vous êtes plantés dans l’approche quelque part. La technique du Mind Mapping vous permet justement de vous abstraire de la technique et réfléchir sur le besoin d’affaires.
  • Une story doit toujours être indépendante de toute technologie (dans la mesure du possible).
  • Si la question vous est posée, une story est différente d’un cas d’utilisation classique. Pour faire le parallèle avec le cas d’utilisation, celui-ci serait une agrégation de toutes les actions possibles sur une information. La story elle est une action parmi les autres donc beaucoup plus granulaire et donc plus facile à caler dans des sprints à des moments différents selon la valeur qu’elle apporte.
  • Le plus difficile dans une story, c’est de savoir le moment où elle se termine vraiment. On définit alors des critères d’acceptation (définit de manière rapide lors de la phase démarrage puis affinés lors des ateliers de groomings) qui sont un contrat entre le PO et l’équipe. Si tous les critères d’acceptation sont validés, alors la story est considérée comme terminée.
  • Consistance des stories : évitez-les stories pas vraiment finie qui seront vraiment complétées une fois une autre terminée (genre il manque le branding qui viendra à la fin…). Gérez plutôt ce cas de figure avec une contrainte qui augmentera l’estimation.
  •  Déroulement de l’exercice
  • Notez tous les types au tableau sous forme de bulles
  • Faites un exemple vous-même avec un type d’information
  • Paralléliser le travail en demandant de le faire par équipe de 2 sur des types différents à leur discrétion.
  •  Conseils
  • Écrivez les stories directement dans JIRA (ou tout autre gestionnaire de backlog) au fur et à mesure, sinon vous perdrez trop de temps à la fin de l’exercice pour le faire. L’intérêt d’être en binôme prend tout son sens ici.
  • Cet exercice est le cœur de la phase de démarrage. Faites-en sorte que votre client soit impliqué le plus possible. Essayez de ne pas le faire à sa place.
  • Lorsque vous définissez une story, faites-le de manière exhaustive (voir le format au début de cette section) pour ne pas à avoir à repasser dessus après.

Résultat d'une mind map sur un système

Définition des contraintes

Une contrainte est une particularité à prendre en compte lors de la réalisation d’une user story pouvant influer de manière significative sur son estimation. La contrainte la plus courante est celle du design mobile. Dans ce cas, on préfèrera gérer le travail d’adaptation mobile au niveau de chacune des stories (quitte à avoir une estimation plus haute) permettant de livrer une fonctionnalité finale à la fin du sprint, plutôt que de créer une story globale technique qui « repassera » sur toutes les stories en fin de projet.

  •  Conseils

Il est important de s’entendre sur la définition et la portée d’une contrainte = critère d’acceptation pour chaque contrainte de la même manière que les user stories. Par exemple, la cntrainte « mobile » signifie tel ou telle résolution sur tels ou tel type de téléphone/tablette.

Un exemple complet

Pour illustrer le résultat final de ce que l’on cherche à obtenir, voici un exemple complet de définition d’une user story dans une solution d’intranet d’entreprise :

ExempleStory


Plan de livraison et définition du « Minimal Viable Product » (1 heure)

  • Objectif(s)

Dans cet atelier, nous définissons l’ensemble des fonctionnalités du backlog formant le produit minimal (MVP) qu’il serait acceptable pour le client de livrer en production. De même, nous découpons le projet en livraisons séparées, priorisées et indépendantes pour les rendre flexibles à au budget et à l’échéancier. C’est aussi ça l’agilité : avoir la possibilité de répartir dans le temps et dans les coûts le développement d’un projet.

  •  Déroulement de l’exercice

Ici, deux manières de faire.

Scénario #1 : Vous êtes à court de temps :

  • Regroupez toutes les stories par cas d’utilisations ou par thématiques et listez les au tableau (ex : gestion de contenus, social, etc.).
  • Pour chaque élément, demandez la priorité associée (1 = priorité maximum)
  • Tracez ensuite la ligne entre le MVP et les différentes autres phases

MVP

Scénario #2 : Vous avez encore du temps :

  • Dans votre backlog, priorisez story par story
  •  Conseils
  • Faites attention aux relations de précédence ! (Par exemple une page ne peut pas être vue avant d’être créée…)

[Bonus] Dessiner des wireframes

  •  Objectif(s)

Si le temps vous le permet, vous pouvez demander aux participants de dessiner la maquette « fils de fer » de la page d’accueil du système. Cette étape permet de vérifier que des besoins « cachés » n’aient pas été oubliés :

Wireframes


Éléments en fil conducteur

Comme mentionné dans le paragraphe « Mise en place de la salle », une zone est réservée aux éléments agissant comme fil conducteur et enrichie à mesure des exercices :

Éléments en fil conducteur

Un glossaire

Tout simplement pour se comprendre sur des mots ou notions. Dès qu’un mot ou une notion n’est pas compris par une des deux parties, sa définition est écrite dans le glossaire.

La charte de projet

La charte de projet représente le résumé haut niveau du projet et l’entente passée entre le « Product Owner » et nous. A la fin des ateliers, chacun repart avec sa copie qui devra être visible en tout temps par le client et de l’équipe de développement. Celle-ci est le plus souvent imprimée format « poster » pour être bien visible. Voici des exemples de chartes :

Exemple de charte sous format informatique

Charte affichée pour l'équipe de développement

La liste de choses à faire

Des points à confirmer ou infirmer ? Des preuves de concepts à planifier ? Des informations non disponibles à l’heure actuelle à récupérer ? Pas de panique, la liste de choses à faire est faite pour ça : noter les devoirs de chacun au fur et à mesure des exercices.

Le site de projet

Nous utilisons un site SharePoint Online pour stocker toutes les différentes informations d’un projet. On retrouve à l’intérieur :

  • Un bloc-notes partagé
  • Une librairie d’images pour les photos de l’atelier
  • La vision et la charte de projet
  • Tous les documents utiles au projet.

N’oubliez pas de partager le site avec le client (très simple avec SharePoint Online!)

Site de projet

Créer les wireframes et maquettes

Il y a fort à parier que beaucoup de fonctionnalités définies dans le backlog du projet impliquent des interfaces graphiques. Ainsi à la suite des ateliers, nous identifions les interfaces de l’application pour lesquelles la production de maquettes est la plus pertinente. Par exemple, la page d’accueil est évidemment un incontournable, le reste pouvant varier selon le type de système que vous développez. En pratique, le nombre d’interfaces maquettées ne dépasse pas cinq en ciblant les principales. Les autres maquettes sont faites à mesure des fonctionnalités abordées dans les sprints (Il est donc important de prévoir cette charge de travail dans la globalité).

Chez GSoft, nous avons la chance de disposer d’une équipe de design dédiée pour la réalisation de ces tâches. Ainsi nous produisons pour chaque interface :

  • La maquette « fils de fer » qui s’intéresse avant tout au placement des éléments. Par conséquent, elles ne contiennent ni couleurs ni artefacts graphiques élaborés.
  • Une fois approuvée par le client, s’en suit une étape de réalisation de maquettes finales représentant le rendu final tel qu’il sera implémenté. À l’inverse des maquettes « fil de fer », ces dernières reprennent la charte graphique de l’entreprise ainsi que tous les éléments dans le contexte final. C’est à ce moment où nous récupérons le matériel graphique du client comme des logos, des codes couleur ou toutes autres indications graphiques qui pourraient être utiles.

Étant donné qu’il est rare qu’un client nous arrive déjà avec des maquettes ou des concepts existants, nous proposons systématiquement deux styles différents pour l’application (par exemple un style plus traditionnel et un autre plus « funky » selon les standards actuels).

  •  Conseils
  • Comptez un délai d’une semaine entre la production des maquettes fils de fer et leur approbation. Dans la pratique, si nous ne recevons pas de réponse passé ce délai, nous considérons qu’elles conviennent au client et passons à la prochaine étape.
  • Il est important de faire comprendre à votre client qu’un « wireframe » n’a pas de couleurs et que c’est normal à ce stade-ci 😉 !
  • Pour aider vos designers, spécifiez les composants devant se trouver sur chaque interface. Seulement pour le MVP.

(Optionnel) Réaliser les preuves de concepts (POC)

Des inquiétudes quant à la faisabilité technique de certaines fonctionnalités qui pourraient mettre en péril la réalisation du projet de manière globale ? Tout comme nos clients, nous pensons qu’il vaut mieux s’en assurer à l’avance avant de se retrouver devant le fait accompli en cours de projet. Pour cela nous réservons du temps avant le début du projet pour réaliser une ou plusieurs preuves de concepts. À la fin de celles-ci, deux possibilités :

  • La POC confirme la faisabilité du besoin concerné. Dans ce cas, selon la complexité, le besoin est estimé et priorisé en connaissance de cause. Si l’estimation est trop élevée, une autre solution peut être envisagée ou bien le besoin peut être retiré du backlog.
  • La POC infirme la faisabilité du besoin. Dans ce cas, soit une autre solution est envisagée, soit le besoin est retiré du backlog.

Ne pas utiliser les POC à outrance… Trop de POC pourrait paraître un peu « louche » pour un client dans le sens ou vous n’apparaissez pas vraiment sûr de ce qui vous faites pour une firme « d’experts ».

Estimer le coût de réalisation du projet

La dernière étape consiste à fournir une estimation du coût de réalisation global du projet pour les fonctionnalités du backlog identifiées. Bien que dans une approche agile, il n’est pas coutume d’estimer un projet dans sa globalité avant de démarrer, le client souhaite très certainement planifier un budget et une date de livraison approximative pour s’organiser correctement.

L’estimation globale comprend donc :

  • L’évaluation unitaire de chaque fonctionnalité du backlog sur la base des informations recueillies pendant les ateliers de démarrage. N’étant pas une science exacte et étant soumise à une multitude de facteurs environnants, il est bien important de faire comprendre qu’elle peut varier au cours du projet (c’est le concept même de l’agilité). Toutefois, l’objectif d’un démarrage de projet est aussi de limiter l’écart possible entre l’estimation initiale d’une fonctionnalité et sa réévaluation au moment d’être ajoutée à un sprint. Une différence trop importante signifierait que nous avons échappé un détail important lors des ateliers, ce que nous tentons d’éviter. Si par exemple une story initialement estimée à 2 points passe à 8 lors d’un sprint planning, cela signifie que l’on a oublié un point majeur lors de la définition de la story. Cela peut arriver bien sûr, mais il faut que cela reste marginal.
  • Les éventuels coûts de licences associés aux outils tiers ou produits identifiés lors des ateliers
  • Les coûts fixes ou semi fixes.

Quel format?

  • En points et non en heures ou jours
  • Ordre de complexité relative entre les stories

Comment?

  • Planning poker entre les membres de l’équipe de développement. Si possible celle pressentie pour développer le projet en cas d’issue positive (ou à défaut des compétences expériences similaires).
  • Établir un étalon maximum et minimum

Quand?

  • Au démarrage de projet pour l’estimation globale
  • À chaque sprint planning

Qu’estime-t-on?

  • Compliqué VS Complexe
  • Compliqué : peut se découper en unité plus granulaire
  • Complexe : ne peut se subdiviser de manière simple
  • Durée de réalisation
  • La prise en compte des contraintes

Quelques règles

  • Le pointage 0 n’existe pas du genre « SharePoint le fait déjà » ou « Le code existe déjà »
  • L’échelle de pointage est la même pour toutes les équipes
  • Pointage trop haut = subdivision systématique
  • L’estimation d’une story ne peut dépasser la vélocité de l’équipe…
  • Une story ne peut être implémentée dans deux sprints différents.
  • Toujours un sprint supplémentaire pour la correction et l’ajustement du dernier sprint de développement.

Nous avons pour habitude de fournir les pistes prévues d’implémentation pour chaque story pour garantir un maximum de transparence.

Contractualisation agile

Le mode de contractualisation agile peut se révéler un point sensible (comprenez, générateur de conflits) s’il n’est pas abordé dès le début.

Bien souvent, il est coutume de représenter les 3 principales variables macroscopique d’un projet de la manière suivante :

Variables communes d'un projet

Cette modélisation insiste sur le fait que ces 3 variables sont en réalité intrinsèquement liées entre elles. Le postulat : « Je veux toutes les fonctionnalités, le plus rapidement possible et le moins cher possible » n’est donc pas atteignable ni même réaliste. Cela signifie que, si l’une des variables est immuable, il faudra alors obligatoirement agir sur les deux autres pour pouvoir la respecter.

Traditionnellement, dans les projets informatiques, deux modes de contractualisation s’affrontent :

  • Les projets forfaitaires (« Fixed-Bid ») : Ici, le coût du projet est fixe et déterminé à l’avance peu importe ce qui peut se passer.
  • Les projets « Time & Materials » : Ici, le projet est facturé à l’utilisation.

Dans un contexte agile, le mode de contractualisation le plus adapté est intuitivement de type « Time & Materials ». Cependant, cela ne signifie pas qu’il est impossible de fonctionner de manière forfaitaire. L’inconvénient majeur avec ce type de contrat, est que vous fixez d’ores et déjà la variable budget comme étant immuable. Si votre client n’est pas au fait du principe précédent, attendez-vous alors à de longues heures de négociation au moment de faire des compromis…

  •  Calcul des coûts

Pour passer d’un système de points à un coût bien réel, il est important de comprendre les éléments fondamentaux impliqués dans le calcul pour un projet agile :

  • La vélocité: Le nombre de points par sprint qu’une équipe de développement est capable de « brûler ».
  • La durée d’un sprint (en heures ou en jours)
  • Le taux horaire des différents intervenants (développeurs, architectes, etc.)

Le coût de développement se calcul donc selon la formule théorique suivante :

  • Nombre de sprints = Nombre de points du backlog (ou de la release concernée) / Vélocité estimée par sprint
  • Effort de développement (heures ou jours) = (Nombre de sprints * Durée d’un sprint)
  • Coût de développement = Durée de développement * Nombre d’intervenants * Taux horaire
  •  Conseils
  • Prévoyez toujours un sprint supplémentaire pour la correction et l’ajustement du dernier sprint de développement.
  • Au coût de développement, s’ajoutent des coûts fixes ou semi fixes qui ne peuvent pas être traités dans le cadre de sprints (buffer pour la réalisation de maquettes, gestion de projet, temps de déploiement, architecture et conception préliminaire etc.).
  • La valeur de la vélocité étant soumise à une multitude de facteurs plus ou moins aléatoires (nombre de personnes, expériences de chacun, domaines de compétences, réalisation similaires, affinités, etc.) sa détermination en devient très difficile. Sachez seulement que la vélocité évolue tout au long d’un projet et que sa détermination ne se fait pas à la légère.

Conclusion

 Il est utopique de penser que se limiter à des discussions ponctuelles en amont d’un projet avec un client puisse mener à sa compréhension optimale. Si celui-ci se révèle en apparence un succès, cela signifie qu’une des deux parties a, un moment donné, du compenser pour l’autre d’une quelconque façon que ce soit (choix arbitraires, compromis, temps de travail supplémentaire, etc.) …

L’agilité n’est pas synonyme d’absence de spécifications. La différence avec des méthodes plus traditionnelles, est que l’on privilégie ici, avant tout l’efficacité grâce à un format court et intuitif allant directement à l’essentiel.

La phase de démarrage nécessite pour le client de mobiliser X nombre de personnes pendant au maximum 3 jours, ce qui constitue un frein majeur. Cependant, dans bien des cas, nous arrivons à réaliser en seulement 3 jours, l’équivalent de mois de travail pour certains.

Les réunions de « grooming » dans le processus opérationnel agile constituent le prolongement naturel de la phase de démarrage. À ce titre, ils ne doivent pas être négligés sous peine de retomber dans les conséquences vues plus haut.

Avoir uniquement une application opérationnelle stricte de SCRUM ne suffit pas à faire de tous les projets, des succès assurés (Cf. point 1) ! ​

La définition des besoins et l’organisation de la charge de travail sont les points les plus importants d’un projet au-delà de l’aspect technologique.

 La phase de démarrage de projet n’est pas un atelier d’analyse fonctionnelle mais de définition de besoin et de découverte de système.

 Même si vous ne faites pas de l’agile, cette phase peut vous aider grandement dans la définition et la planification du travail à faire.

La phase de démarrage est avant tout un exercice de communication complété par une expertise fonctionnelle, incarnée par un fournisseur, venant structurer les discussions.

Pièges à éviter et conseils généraux

À mesure de réaliser ce genre d’ateliers, nous avons identifié quelques pièges à éviter. Voici quelques conseils pour mener à bien vos ateliers :

Animation des ateliers

  • Adaptez le rythme. N’oubliez pas que votre challenge sera de réussir à faire exprimer des besoins exploitables à travers un backlog en mode agile à des personnes qui, la plupart du temps, n’ont jamais fait ça de leur vie.
  • Travailler avec tout le monde. Ne laissez personne mobiliser la parole sans arrêt (il y en a toujours un ou une ;)).
  • Ne JAMAIS proposer des solutions techniques du genre « avec <insérez votre technologie/produit ici> c’est super facile ! » (Même si vous connaissez déjà la réponse).
  • Ne pas tomber dans le détail, ce n’est pas le but des ateliers et cela vous fera perdre beaucoup de temps. Une erreur très fréquente lors des premiers essais.
  • Ne pas hésiter à recadrer les participants si les discussions dérivent trop.
  • Prenez le résultat de chaque exercice en photo. Elles serviront à alimenter le site de projet et à se remémorer ce qui a été fait.
  • Selon le type de projet, savoir être force de proposition (site web ou intranet).
  • Si un participant bloque à exprimer une idée, demandez-lui de dessiner ! Une image vaut mille mots…
  • Sachez quand vous relayer. L’animation des ateliers est épuisante, alternez la prise de notes et l’animation.

Après les ateliers

  • Ne pas perdre le momentum! Si vous laissez trop de temps entre les ateliers et les autres étapes, vous perdrez l’effet galvanisant, et vous oublierez ce qui a été dit. Enchainez donc les étapes d’après rapidement jusqu’à produire la proposition finale.
  • Vous allez certainement oublier de choses, et c’est normal. Dites-vous que si cela n’a pas été mentionné c’est que cela n’était pas vraiment important au final…
  • Assurez-vous qu’une personne bien précise soit en charge de faire le suivi des différentes étapes (suivis des todos, planification des POC ,etc.).

Remerciements

À Laurent Duberger, mon partenaire d’ateliers de démarrage, pour la relecture.

À l’équipe GSoft pour avoir rendu possible la mise en place de cette méthodologie.

Sources et références

Présentation d’Isabelle Therrien sur le démarrage de projet agile (dont est inspiré en très grande partie cet article!)

Pour aller plus loin, ma présentation sur l’agilité avec SharePoint

+ There are no comments

Add yours