Le « kick-off » de projet chez OVH

Temps de lecture estimé : 5 minute(s)

Dès mon arrivée chez OVH dans l’équipe responsable du Service Delivery, qui est garante de la production, j’ai souhaité mettre en œuvre la technique agile dite des kick-offs dans la gestion de projet. En tant que PaaS Manager, une de mes missions consiste à mettre en place et promouvoir les méthodes de Site Reliability Engineering1 (SRE) que j’utilise depuis plusieurs années, dans le cadre de mes précédentes expériences professionnelles. Aujourd’hui, cette discipline est bien implantée dans l’industrie logicielle pour laquelle elle a d’ailleurs été conçue. L’un de ses apports majeurs est de permettre la mise en place d’un logiciel ou d’une plateforme qui intègre, dès le démarrage, à la fois de l’agilité et de la fiabilité. Mais appliquer des principes SRE à OVH constituait en partie un défi. L’entreprise étant avant tout un fournisseur d’infrastructures informatiques, il était nécessaire d’adapter les méthodes à cette activité spécifique.

Parmi ces méthodes agiles, un outil tient une place stratégique : le kick-off. Ce moment où nous lançons un projet est l’occasion d’établir des objectifs communs et de déterminer pour quoi nous travaillons ; il permet d’avoir une vision macro du projet en amont, de confronter ses idées, d’éviter les silos, de clarifier le domaine du projet, d’en faire la promotion, d’informer les équipes et de créer de l’adhésion. Pour faire simple, le kick-off est crucial pour le bon démarrage d’un projet. Dans la suite de ce billet, je vais vous présenter un modèle suivi chez OVH qui se veut le plus générique possible.

Le kick-off et ses éléments principaux

Voici une liste de points à étudier avant de démarrer le projet et à consigner dans un document d’intention, le kick-off.

Objectifs inclus

Nous exposons ici les objectifs et attentes qui seront inclus dans le projet, toujours dans une liste à puces. Par exemple : « Le projet résout le problème Y. »

Objectifs exclus

Nous détaillons là les objectifs qui ne seront pas inclus dans le projet, encore dans une liste à puces pour être concis. Cette partie est importante ; elle permet de préciser de et clarifier le périmètre du projet.

Conception

Nous y retrouvons tous les éléments techniques du projet : un schéma d’architecture, une liste des technologies employées, les objectifs à remplir ou les facteurs de réussite. Cette section s’attarde sur : « Comment concevoir techniquement le projet ? »

Alternatives envisagées

Cette partie liste des alternatives envisagées lors des recherches sur le projet.

Risques

Nous exposons ici les risques financiers et techniques, mais également les dépendances que le projet va créer, aussi humaines que techniques.

Calendrier

Nous présentons alors la planification par une représentation schématique ou une phrase. Les périodes sont généralement exprimées par des « sprints » de deux semaines ou d’un mois, selon le niveau de maturité du projet lors de sa rédaction.

Une fois cette page de kick-off réalisée, nous envoyons un e-mail à toutes les personnes concernées de près ou de loin dans l’entreprise. Par ce biais, nous souhaitons communiquer le plus largement possible pour éviter les initiatives similaires et favoriser la participation. Chacun a, à cette occasion et pendant deux semaines, la possibilité de commenter et faire évoluer le contenu du kick-off. Une réunion s’ensuit à la fin de cette période pour valider le kick-off.

La réunion du kick-off

Nous souhaitons là obtenir un feu vert formel pour le projet et établir ce qui doit être résolu avant de pouvoir commencer. Nous nous assurons aussi que les parties prenantes ont bien saisi le contenu du projet et ses implications (par exemple, les besoins en ressources humaines ou logicielles). Les participants à cette réunion sont les responsables techniques, développement et projet, les managers, ainsi que les personnes intervenues sur le document de conception. La personne chargée de la réunion est couramment l’initiateur ou un chef de projet.

Le format de cette réunion se doit d’être court – 15 minutes maximum – car les participants ont déjà préalablement discuté, lu ou validé le projet. Ce kick-off n’est pas non plus une revue complète ou une réunion de brainstorming : manquer la préparation du kick-off repoussera inutilement votre projet. Durant cette réunion, il faut prendre en compte les retours qui seront formulés et recommencer l’itération.

Le développement ne devrait pas commencer avant que la conception ou les besoins en ressources ne soient d’abord validés par toutes les parties prenantes.

Après la réunion, un résumé des principaux points abordés doit être envoyé à tous les invités, qu’ils aient pu être présents ou non. Ce document inclut généralement, sans s’y limiter :

  • un « go » (feu vert ou green light), qui permet de lancer le projet. Si des réserves sont émises, comme des questions soulevées qui nécessitent davantage de recherches ou de prendre des mesures hors du périmètre, une autre réunion doit se tenir ;
  • les impacts validés lors de la réunion (les décisions affectant fortement l’architecture par exemple).

Selon l’ampleur du projet, sa visibilité, sa durée et parfois ses autres variables, cette liste peut être plus ou moins longue.

Les conditions d’un kick-off

Pour finir, un kick-off nous semble nécessaire si au moins une des conditions suivantes est remplie :

  • le projet demande au moins un mois en matière de ressources ;
  • le projet ajoute ou modifie ;
  • le projet a un impact sur des équipes différentes ;
  • le projet comprend la création ou la migration d’un service, d’une plateforme, d’un outil ou d’une application ;
  • le projet sera hébergé sur des machines possédant un nouveau type de configuration.

Cette liste n’est évidemment pas exhaustive.

 

 

 

 

1.  Le Site Reliability Engineering (SRE) est une discipline qui intègre des aspects de l’ingénierie logicielle et l’applique aux problèmes d’exploitation informatique. Les principaux objectifs sont de créer des systèmes logiciels ultra-évolutifs et fiables. La discipline est attribuée à Benjamin Treynor Sloss, vice-président de l’ingénierie chez Google, et à son équipe. Il a rejoint cette entreprise en 2003 et a été chargé de constituer une équipe pour garantir la santé des systèmes de production de Google à grande échelle.