© 2017 by aequos

aequos solutions

902 Gilbert Langevin, Montréal, H2J4G6

+ (1) 514-928-0486

contact@aequos.ca

  • Twitter - Grey Circle

Un démarrage de projet, à quoi ça sert?

21.03.2017

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, etc.). 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 d’expliquer la manière dont nous avons répondu à toutes ces problématiques 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 »

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.

 

Aequos est une entreprise qui se place en tant que fournisseur de services, spécialisée dans le développement et l’intégration de solutions logicielles collaboratives basées sur les plateformes SharePoint/Office 365 et Azure. Nous développons et intégrons nos solutions selon les préceptes agiles et plus particulièrement SCRUM avec les outils appropriés pour supporter cette méthode.

 

Notre application de SCRUM

 

Voici notre processus global tel qu’il est appliqué chez Aequos :

 

  • Le backlog

 

En entrée de tout projet, une liste des fonctionnalités priorisée dans un « backlog » et exprimée 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 et/ou architecte, le PO (« Product Owner ») 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 de développement 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 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.

 

  • 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: Aequos é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 déterminer un budget global), principe allant à l’encontre de la philosophie agile. Nous y reviendrons plus tard dans la suite de l’article.

 

Genè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. 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.

 

 

Quel était le problème ?

 

À l’époque, et de par nos expériences passées, bien qu’ayant une application rigoureuse de SCRUM au quotidien dans le passé, plusieurs problèmes demeuraient encore dans le déroulement des projets entraînant 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 et demi (type présentation PowerPoint ou autre).

  • Des notes rédigées après des réunions avec des personnes sans grand rapport avec le projet décrivant brièvement les requis (typiquement, des notes prises après des réunions d’avant-vente avec le client).

 

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 (« nous voulons un moteur de recherche »). Mais encore…

 

 

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 (la fameuse « contingence ») pour anticiper le risque que nos suppositions se révèlent fausses en cours de projet.

 

« Quand un développeur ne sait pas ce qu’il y’a à faire, il le suppose… pour le meilleur ou pour le pire »

 

3- Bricolage et effet boule de neige

 

Pour peu que le projet soit effectivement signé, l’équipe de développement rencontrait alors fréquemment des problèmes de délimitation de périmètre pour chaque fonctionnalité entraînant 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 en cherchant désespérément les « failles » de notre application de SCRUM, 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. Chacun possédait un fragment de l’information et avait sa propre compréhension. Difficile, dans cette situation, d’envisager que le projet se passe sans accrocs par la suite…

 

C’est ici que la phase de démarrage de projet prend tout son intérêt. En voici les principales étapes :

 

 

Les objectifs de la phase de démarrage de projet 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 planifier 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 vous, 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 vous initier 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 fait 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 et se rendre disponible tout au long u projet.

De même, le PO est le contact privilégié entre vous 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. Attention, cela ne veut pas dire que leurs commentaires ne sont pas importants, bien au contraire. Cependant, il s’agit de faire appel à eux pour des questions précises aux moments opportuns.

Préparer les futures discussions

 

Tout comme le domaine du développement logiciel, le votre 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 permet 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 : Vous avez une bonne idée de ce que vous voulez, et vous avez 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 : Vous avez une idée globale de ce que vous voulez, mais vous n'avez encore rien formalisé ou vous souhaitez 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 (de 1 à 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. Il est très probable que vous deviez débloquer un budget pour la réalisation de votre projet, notre but est donc de vous donner un chiffre relativement cohérent selon les détails du backlog que nous aurons déterminé ensemble.

 

Pourquoi plusieurs jours consécutifs ?

 

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

  • 1 ou 2 animateurs selon la ta taille du groupe et l’envergure supposée du projet.

 

Nous essayons d’imposer 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.

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

 

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. Bien que n’importe quelle salle de conférence puisse faire l’affaire, différentes zones de travail doivent être prises en compte :

 

Les différentes zones de travail:

 

  • 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.

 

  • 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.

 

Nous bannissons l'utilisation des ordinateurs portables ! C’est le meilleur moyen pour ne rien écouter…

 

Bris de glace

 

  • 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

 

  • 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 nous allons 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

 

  • 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...)

 

  • Déroulement de l'exercice

 

  1. Nous écrivons ce modèle de phrase sur un tableau et nous indiquons un numéro pour chaque espace vide à compléter après les mots clés.

  2. Nous demandons à tous les participants de compléter les bouts de phrases manquants en utilisant un post-it par numéro (environ entre 5 et 10 minutes).

  3. Nous faisons la synthèse directement au tableau en juxtaposant les post-it de tout le monde. Ici notre rôle est de challenger les différences et approfondir les similitudes. Attention à ne pas dépasser le temps, cet exercice pouvant être très chronophage.

 

Si les participants éprouvent de la difficulté à exprimer la vision, nous commençons généralement 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

 

  • 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. Nous cherchons 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.

  2. Chacun rédige sur un post-it différent ses objectifs et les mets au tableau une fois terminés.

  3. La synthèse est faite au tableau en rassemblant les similitudes et en challengeant la pertinence par rapport à la vision initiale.

 

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 (pour s’assurer d’une certaine cohérence). 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é. Nous insistons 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 il en résulte qu’1 ou 2 objectifs. L’important est qu’ils soient atteints à la fin de l’horizon décidé.

Équipe

 

  • 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 :

 

 

Il est possible de faire 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

 

Attention à ne pas lister toute l’entreprise (genre les managers des managers) ! Il est important de garder ça dans le contexte du projet, ce n’est pas un organigramme.

Contraintes haut niveau

 

  • 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. Il s’agit souvent de contraintes non fonctionnelles et transversale à la solution à développer.

 

  • Déroulement de l’exercice

 

  1. Sous forme de discussion ouverte (de 5 à 20 minutes). Nous proposons généralement des exemples de contraintes communes et vérifions si elles s’appliquent effectivement dans le projet comme par exemple (liste non exhaustive) :

    • Besoins en termes de mobilité (affichage sur ordinateur seulement ou téléphone, tablette, etc.)

    • Mécanismes d’accès et d’authentification (comment se connectent les utilisateurs? à partir d’où (interne, externe)?

    • Navigateurs à supporter (IE x, Edge, Firefox, Chrome, Safari, etc)

    • Normes particulières à rencontrer (ex.: normes ISO)

    • Esthétisme du UI/UX (vise-t-on un prix international de design?). Qui se charge du design par exemple?

(Optionnel) Événements probables

 

  • 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

 

  • Nous dessinons 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.

 

 

 

Il est bien important de ne lister que les événements pouvant arriver pendant le projet et non avant ou après et 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.

 

Cet exercice est surtout réservé aux projets de grande envergure de 6 mois à 1 an. Pour des projets moins long, cet n’est exercice n’est pas forcément pertinent (le plus important étant peut-être de savoir si telle ou telle personne par en vacances ou non durant cette période).

User Stories

 

  • Objectif(s)

 

Appelées également dans la littérature agile « 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 principaux 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 (permet de faire gagner du temps).

 

Nous utilisons la technique du Mind Mapping pour la définition des stories.

 

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 rapidement.

En résumé, la technique du « Mind Mapping » consiste à formaliser un besoin dans un format équivalent à celui qu’un développeur aurait de toute façon utilisé lors de la phase de conception en utilisant les principes de programmation orientée objet.

 

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 donc 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 votre contexte métier 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 (CUD).

  • 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 nous aider à identifier ces différences.

 

(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, nous dessinons son cycle de vie en commençant par le moment de sa création pour les scénarios que vous souhaitez approfondir.

  • Nous identifions les grandes étapes pour ce scénario et nous interrogeons les participants (Qui fait l’action ? Pourquoi ? Que se passe-t-il ensuite ? À partir de là, que puis-je faire ? Etc.)

  • Nous traçons enfin les limites du périmètre du système à développer.

     

     

 

Dans cet exemple, le simple fait de dessiner le processus existant de publication d’une nouvelle dans un intranet permet de faire apparaître 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 :

 

 

  • 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).

  • Une user 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 : Nous évitons 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…). Nous gérant plutôt ce cas de figure avec une contrainte qui augmentera l’estimation.

 

  • Déroulement de l’exercice

 

  • Nous notons tous les types au tableau sous forme de bulles

  • Nous prenons un exemple concret avec un type d’information

  • Nous parallélisons le travail en demandant de le faire par équipe de 2 sur des types différents à leur discrétion

 

 

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.

 

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 contrainte « 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 :

 

 

Plan de livraison et définition du « Minimal Viable Product »

 

  • 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 vous 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

 

Scénario #1 : Priorisation en « lots »

  • Nous regroupons toutes les stories par cas d’utilisations ou par thématiques et les listons au tableau (ex : gestion de contenus, social, etc.).

  • Pour chaque élément, nous demandons la priorité associée (1 = priorité maximum)

  • Nous traçons ensuite la ligne entre le MVP et les différentes autres phases

 

Scénario #2 : Priorisation granulaire

  • Vous priorisez story par story en faisant 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 nous le permet, nous demandons 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 :

 

É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 :

 

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. Il s’agit d’un format « one pager ».

 

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 espace central pour stocker toutes les différentes informations d’un projet. Celui-ci sert également à partager tous documents et informations utiles avec vous tout au long du projet.

(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 vous, 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.

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, vous souhaitez 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 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 (gestion de projet ou les séances de grooming par exemple).

 

Quel format?

 

  • En points et non en heures ou jours

  • Ordre de complexité relative entre les stories

 

Comment? 

 

  • Planning poker en points de complexité relative

  • Établissement d'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à ». "0" signifierait qu'il n'y ait absolument aucun travail (technique ou organisationnel) à réaliser.

  • 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 :

 

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. Il faudra donc être flexible sur les deux autres variables…

 

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 du coût d'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

 

Remarques

 

  • Nous prévoyons 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 manière que ce soit (choix arbitraires, compromis, temps de travail supplémentaire, baisse des attentes, 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 vous 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.

  • 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.

 

Au plaisir de démarrer un projet ensemble!

 

Remplir le formulaire de contact

 

Aequos.

 

 

 

 

 

 

 

 

 

 

 

 

Share on Twitter
Please reload