Dans la série gestion de projet, conception de logiciel et Open Source, et pour faire suite à l’article de Nicolas, Contribuer à un projet Open Source, on vous propose aujourd’hui de découvrir une méthodologie peu connue en Europe et particulièrement absente en France, à savoir l’ODM.
Avant de rentrer dans le vif du sujet, faisons un petit rappel sur les méthodes existantes pour nous rafraichir la mémoire. Bon… à l’origine, on retrouve la méthode R.A.C.H.E sponsorisée par Mac Gyver et viable dans n’importe quel contexte peu importe les outils mis à notre disposition. Tout le monde s’est essayé à cette dernière, parfois même avec succès.
L’ère numérique a vu l’émergence d’une pléthore de méthodologies dans le but d’organiser et manager les projets qui sont au cœur des organisations. Ces méthodes, telles que Merise, UML, Gantt, Pert, TDD, Waterfall ou encore le fameux cycle en V, ont su faire leurs preuves au point d’être encore enseignées dans les écoles supérieures d’informatique en France en ce début d’année 2017.
D’autres méthodes sont ensuite apparues à partir des années 90, alors que la demande en développement informatique se fait de plus en plus forte. Ce sont les fameuses méthodes novatrices qui se concentrent principalement sur le projet, l’accompagnement des clients et une gestion différente des équipes et du planning. Ces méthodes, vous les connaissez très certainement : les très populaires Agile et Scrum qui vont bien souvent de pair, et d’autres méthodes dans la même veine comme Lean, Extreme Programming, Behavior Driven Development (grossièrement une extension au Test Driven Development) et bien d’autres.
Rappelons enfin la rédaction en 2001 du manifeste Agile. Celui-ci met en exergue 12 principes qui sont au cœur de l’Agilité mais également au service des acteurs du monde de l’informatique. Il s’agit d’un message fort adressé à une industrie en pleine expansion qui n’a de cesse d’évoluer et de remettre en question chaque découverte ou avancée.
Voilà maintenant 16 ans que l’Agilité a pris une place significative dans le domaine de la conception de logiciel. Avec un retour d’expérience conséquent, on constate que la méthode en elle-même est efficace à partir du moment où elle est correctement intégrée et maitrisée. Cependant, on constate de plus en plus que certains concepts Agile tendent à être délaissés, voire sous-estimés. Au point dans certains cas de s’éloigner des principes qui composent le Manifeste Agile.
L’évolution de l’informatique en général ne suppose-t-elle pas l’émergence de nouvelles méthodologies pour s’adapter aux nouveaux projets ? Pour s’adapter à un monde du travail en perpétuelle mutation ? Pourra-t-on encore se permettre de suivre aveuglément des méthodes dogmatiques ? L’agilité vit-elle ses dernières heures ?
Autant de questions sans réponses car, malgré toutes nos expériences, nous ne possédons tout simplement pas le recul nécessaire à l’heure actuelle pour accepter, par un consensus commun, une méthodologie, une technologie, une seule façon de faire qui serait la mieux adaptée à l’environnement numérique de demain.
Après cette brève introduction qui pourrait faire l’objet de plusieurs articles, voire de la rédaction d’un véritable essai sur ces questions historiques, on peut enfin entrer dans le vif du sujet en nous concentrant sur ce qui nous intéresse.
ODM est un acronyme pour Open Development Method. On pourrait le traduire par Méthode de Développement Ouvert, ce qui ne sonne pas très bien malheureusement… Nous allons donc nous en tenir à ODM dans le cadre de cet article.
ODM se présente comme une synthèse qui s’inspire de multiples méthodologies qui ont fait leurs preuves, mais dont certaines lacunes sous-jacentes ont permis son apparition. Elle s’inscrit en outre dans une nouvelle perspective adaptée à ce que l’on appelle aujourd’hui le village numérique, ou encore la ville-monde. Bref, la Terre 2.0.
En réalité, cette méthodologie est née de la volonté de prendre le meilleur de chacune des méthodologies citées ci-dessus, comme l’Agilité par exemple, tout en s’affranchissant de certaines problématiques qui résident au cœur des projets collaboratifs, comme différents time zones au sein d’une même équipe.
Vous l’aurez compris, ODM provient du monde de l’Open Source. De cet espace remarquable que l’on trouve dans l’Internet et qui fait pousser de nombreux projets géniaux qui font avancer le monde à pas de géant !
Bien que cette méthodologie semble essentiellement adaptée à l’Open Source, ce serait une erreur de la réfuter dans d’autres contextes. Attention il ne faut pas tout abandonner pour autant au profit de l’ODM. Toutefois, les principes véhiculés par cette méthodologie sont intéressants, presque fondamentaux pour apprécier davantage notre travail et nos productions.
On doit l’émergence de l’Open Development Method à son plus fervent défenseur qui se trouve être son initiateur : Ahmad Nassri. Il ne tarit pas d’éloges pour présenter son bébé et s’y prend visiblement de manière réfléchie.
Tout part du constat d’une série de problématiques qui se posent quotidiennement.
En réalité, une chose est commune à l’ensemble des projets informatiques et A. Nassri le résume très bien : « Get Shit Done ».
Ne soyez pas trop surpris en découvrant ces termes peu accommodants. Cette expression traduit seulement l’état d’esprit de la plupart des équipes de développement à l’égard des projets, notamment dans les situations délicates.
A. Nassri analyse son rôle en tant que développeur, mais pas seulement. Il part en effet du constat que la vie elle-même est asynchrone. On ne répond pas forcément toujours à son téléphone, on ne fait pas toujours tout dans l’immédiat et certains même se reconnaitraient si nous évoquions la procrastination.
Mr. Nassri serait-il philosophe à ses heures perdues ? Peut-être bien… Il s’agit en tout cas d’une véritable prise de position qui peut parfaitement se transposer aux projets de conception logiciel, que ce soit dans l’Open Source ou dans le contexte d’une entreprise.
Ok, ok, on y vient… C’est que le contexte est important. Après tout, qui n’a jamais voulu contribuer à un projet génial ?
C’est précisément là tout l’intérêt de l’ODM. En effet, cette méthodologie change la donne en modifiant le référentiel du développeur au sein des projets. Ici, la gestion de projet n’est plus au centre de toutes les attentions. C’est désormais le développeur qui se trouve au cœur de sa propre contribution, dont le but premier est de faire évoluer le projet.
Pour faire plus simple, l’idéologie qui se cache derrière l’ODM, c’est la contribution par la motivation. La motivation de l’individu est au service du projet et constitue en elle-même un facteur de réussite. Chaque développeur devient alors un véritable acteur du projet !
Très bien ! Mais qu’est ce qui nous dit que le projet n’est pas simplement un projet à la R.A.C.H.E ?
Petit rappel : ODM s’inspire de ce qui se fait de mieux en prenant en compte toutes les méthodes existantes. Nous serions donc tentés de dire que cela n’est pas bien grave si c’est fait à l’arrache…
Mais ce serait tomber dans la facilité. ODM met justement en place des principes qu’il est primordial de respecter. On s’apercevra par ailleurs que ces principes ne sont pas forcément très éloignés de ceux exposés dans le manifeste Agile. Nous allons justement les voir ensemble.
Au nombre de sept, ces principes définissent l’ensemble du projet. On s’apercevra alors très vite que la gestion de projet découle naturellement si on parvient à les respecter.
La qualité ne se suffit jamais à elle-même. Il ne faut pas se contenter de dire « mon code est beau, il est bien fait et c’est ça qui compte ». Non, malheureusement dans ce cas, seule la partie émergée de l’iceberg est traitée.
La qualité d’un code passe par sa lisibilité, sa maintenabilité et son évolutivité. On parlera ainsi de design pattern et d’architecture logicielle.
Il est également nécessaire de prendre en compte le contexte et le périmètre du projet. Par exemple, une application web doit pouvoir tourner physiquement sur un serveur et intégrer des données existantes qui proviennent de plusieurs endroits, avec des technologies différentes, et fournir des services en conséquence. Ainsi, votre application et le serveur qui va l’héberger doivent s’inscrire dans un paysage numérique existant qu’il faut prendre en compte dès les premières phases de la conception. On parlera dans ce cas d’urbanisme.
On ne peut donc tout simplement pas se contenter de dire : « c’est bon, ça va tourner partout, pas de problème ». La qualité, c’est penser à l’architecture du code dans le but de le rendre souple, malléable ou tout bonnement accessible aux autres acteurs du projet.
A contrario des tendances Agile / Scrum qui préconisent la mise en place de réunions quotidiennes en se posant les questions suivantes :
ODM nous propose une réflexion plus intimiste et ontologique afin de répondre efficacement à la problématique de la qualité. Il s’agit de se poser quatre questions en permanence dès lors que l’on souhaite contribuer :
Que faut-il entendre par économique ? Il est nécessaire d’admettre ces deux notions d’optimisation et de refactoring. Cette optique est aux antipodes de la philosophie de base du Shadok :
Pourquoi faire simple quand on peut faire compliqué ? – Claude Piéplu
Nous pouvons d’ailleurs nous poser ces quatre questions en toutes circonstances, peu importe la méthodologie.
Nous pourrions presque affirmer que dans le sens commun, personne n’aime rédiger de la documentation. C’est lourd, rébarbatif et on s’en passerait bien.
En réalité, un projet Open Source sans documentation, c’est un projet qui n’inspire pas l’envie de s’investir. C’est un projet qui nous prendrait trop de temps à analyser, comprendre, voire interpréter. Sérieusement, combien de projet Open Source désactivent la page Wiki en se contentant de fournir un Readme de 3 lignes ?
Pour résumer efficacement, Ahmad Nassri emprunte une citation à Dick Brandon :
Documentation is like sex : when it’s good, it’s very, very good ; when it’s bad, it’s better than nothing. — Dick Brandon
On pourrait même s’aventurer à ajouter :
… and when there is none, we are frustrated. — Myself
Et c’est exactement le piège dans lequel il ne faut surtout pas tomber. Documenter, c’est aussi faire plaisir aux contributeurs d’un projet. Vous verrez qu’ils seront toujours plus enclins à participer et à être force de propositions.
Pour finir, une bonne documentation ne se contente pas seulement de dire que telle méthode fait ci et que telle variable fait ça… Elle tend surtout à expliquer les choix qui ont conduit le développeur à mettre en place son code de cette façon précise.
Pour reprendre cette citation très répandue :
Testing proves the existence of bugs, not their absence. – Woody Williams
Et pour aller plus loin, on peut se référer à l’excellent article de Tim King . Bien qu’il date de 2007, il n’en reste pas moins toujours actuel.
Les tests seront toujours la garantie de fournir un développement de qualité. Et contrairement aux idées reçues, ils nous permettent de gagner du temps en réfléchissant aux problèmes qui pourraient survenir en amont du développement.
Justement, une dernière citation pour la route qui me vient à l’esprit :
First, solve the problem. Then, write the code. - John Johnson
Dans un projet de conception de logiciel, chacun a son mot à dire. Mais qu’est-ce que ça veut dire en réalité ? On se fout bien souvent des propos du chef marketing quand il s’agit de développer une nouvelle fonctionnalité…
À tort, parce que son point de vue va peut-être profiter au projet, tout comme le petit adolescent boutonneux peut avoir l’idée du siècle en matière d’ergonomie ou d’expérience utilisateur pour son jeu vidéo préféré. Il ne faut donc jamais négliger les propos et la vision d’autrui car ils sont le plus souvent porteurs de richesse.
Pour reprendre les propos de Nicolas dans son article :
Si vous ne vous sentez pas capable de corriger une anomalie, ça n’empêche pas votre implication dans le ticket sous toutes ses formes. — Nicolas Cavigneaux
ODM nous fournit sur son site officiel une liste de règles à respecter pour que tout se passe bien en toutes circonstances. En voici donc la traduction :
Cela peut paraître évident, mais on voit en réalité des exemples tous les jours qui nous prouvent que ça ne l’est pas pour tout le monde. Pour qu’un projet soit porteur de sens, il est nécessaire d’interagir avec le reste du monde. Une seule personne ne suffit jamais pour changer les choses, ou tout simplement pour construire et créer.
Comme évoqué plus haut dans ce présent article, la vie est asynchrone, impactant ainsi le déroulement de nos projets.
Par ailleurs, c’est assez rare pour un développeur de travailler sur un seul projet, non ? Comment fait-il alors pour gérer plusieurs projets ? Il attend que le premier soit terminé pour basculer sur un autre projet ? Malheureusement non !
Lorsque que l’on pose une question, lorsque qu’on soumet une solution possible ou encore lorsqu’on propose un choix de couleur pour un site, il faut laisser le temps à la personne en face d’étudier vos propos et de prendre le temps de vous répondre en toute connaissance de cause.
Il ne faut pas perdre de vue que les autres, comme vous, ont des projets professionnels en cours. Ils ont peut-être d’autres choses à faire que de guetter un fil de discussion pour pouvoir répondre instantanément à toutes vos questions.
La transparence se confond bien souvent avec la confiance et à plus forte raison qu’elle est justifiée et justifiable.
Là où l’Agilité se contente de définir des sprints et des user stories, on ne mesure finalement que l’avancement et les performances de l’équipe.
Avec l’ODM, on mettra également en avant les réflexions que chaque membre de l’équipe a mené pour faire avancer le projet. Ainsi, la transparence est l’acte de montrer aux clients ce que l’on a véritablement fait pour le projet à l’instant “ T “.
Le client sera toujours plus satisfait d’une équipe qui se pose des questions pertinentes sur les processus métier inhérents à l’application en cours de développement par exemple, plutôt que de se contenter de fournir l’information prévue en fonction du planning.
Effectivement, il est important de faire un point avec son client concernant le budget destiné au projet, de communiquer sur l’avancement du développement.
Mais grosso modo, la transparence selon l’ODM passe aussi par la discussion et il est toujours plus bénéfique de révéler au client les points faibles de son application plutôt que de lui dissimuler toutes sortes de problèmes. D’où la confiance !
Du point de vue de l’équipe, celle-ci sera toujours plus motivée dans un environnement propice à la transmission d’informations de manière rapide et correcte. Cela rappelle par ailleurs l’un des principes du manifeste Agile.
Laissons-nous le soin de nous exprimer quand cela s’avère nécessaire.
Pour faire simple, soyons notre meilleur critique et laissons les autres nous critiquer car il n’existe pas de meilleure façon d’apprendre, de prendre du recul et de comprendre.
La démocratie dans le monde du développement, c’est aussi permettre au développeur de prendre des décisions qui impacteront le projet, conformément à la documentation et au cahier des charges. Le but étant également l’épanouissement personnel.
L’Open Development Method, c’est aussi aller toujours plus loin !
On peut prendre l’exemple d’une charte graphique pour un site. On peut imposer les couleurs dominantes qui devront apparaître, et pour beaucoup cela est suffisant, on se contente de respecter la charte et… voilà.
L’ODM préconise justement de ne pas se contenter de communiquer la charte graphique, mais aussi d’en expliquer les choix de couleurs. On peut aisément deviner les raisons sous-jacentes liées à cette explication. On veut évidemment faire rentrer les contributeurs dans le projet. Et si ces contributeurs décident eux-mêmes de s’impliquer, c’est parfait ! C’est qu’ils se sont retrouvés dans le projet.
Remember ! Chacun fait marcher sa propre motivation au service du projet.
En réalité, l’Open Development Method préconise surtout une chose à garder à l’esprit en permanence : EVERYTHING MATTERS !!!
J’espère sincèrement que le sujet vous a plu et que vous voudrez en savoir plus sur cette méthode peu connue par chez nous et qui mérite au moins qu’on s’y attarde quelques instants.
Qui sait ? Peut-être avez-vous l’âme d’un contributeur ?
En complément, voici quelques références que vous pouvez consulter librement si le cœur vous en dit :
L’équipe Synbioz.
Libres d’être ensemble.
