Principe de simplicité

Le rasoir d’Ockham, connu également sous le nom de principe de simplicité ou principe de parcimonie s’énonce de manière simplifiée comme suit :

« Les entités ne doivent pas être multipliées par delà ce qui est nécessaire » (Guillaume d’Ockham – moine franciscain au XIVe siècle, http://fr.wikipedia.org/wiki/Guillaume_d’Ockham).

Dans la pratique cela consiste à ne pas utiliser de nouvelles hypothèses tant que celles déjà énoncées suffisent et utiliser à fond les hypothèses qu’on a déjà faites avant d’introduire de nouvelles hypothèses. Ceci paraitra d’une grande banalité mais force est de constater que dans de nombreux processus et méthodologies qui sont préconisées aujourd’hui, ce simple principe semble être en passe de tomber dans l’oubli.

Nous avons tous expérimenté les joies et les désillusions de toutes les méthodes qui devaient nous permettre de développer sans développer, de sortir nos produits sans rien faire, d’innover sans réfléchir, etc … J’avoue que j’exagère grandement car toutes les méthodologies, en particulier agiles, ont apporté leurs lots d’améliorations qui ont forcément laissées des traces dans nos organisations et dans l’esprit des individus. Le bilan est donc globalement positif mais très loin du « miroir aux alouettes » qui est continuellement martelé un peu partout.

La simplicité est donc à nouveau à l’ordre du jour dans un monde ou la réduction des dépenses, l’empreinte écologique, le retour au pragmatisme ont à nouveau la vedette.  Pour cela je vous engage à lire le post suivant http://lagestiondeprojet.com/2009/11/30/simplicite-ou-comment-reprendre-le-controle-de-nos-vies/ qui a le mérite de rappeler quelques éléments simples dans la gestion du quotidien.

Il est temps de reprendre le contrôle de nos équipes et de nos développements plutôt que de les confier à des gurus de SCRUM, XP, TDD ou RAD ! Comment faisions-nous avant pour ceux qui développent depuis plus de 20 ans ? La complexité des nouvelles technologies m’a-t-on opposé dernièrement ? Accroissement de la compétence moyenne des ingénieurs de développement est ma réponse. Ce que nous faisions il y a 20 ans, nous le conceptualisons différemment aujourd’hui et de manière tout aussi efficace pourvu que l’on accorde aux individus la place qui leur revient : celle de l’agilité ultime du cerveau ! Tous ces processus et méthodologies ont laissé croire que le développement logiciel pouvait se passer de compétences, d’implication, de volonté et d’investissements. Ce n’est pas ce que le Agile Manisfesto écrit ou préconise mais c’est ce que les « faiseurs de miracles » ont promu. Le résultat, malheureusement tangible à ce jour, c’est un métier qui n’a pas réussit à trouver l’écoute qu’il mérite. Je fais référence au travail des développeurs et technologues du logiciel qui sont encore vu comme de grands « bricoleurs » mais certainement pas comme des professionnels requérants des compétences très pointues et de plus en plus difficiles à acquérir.

Je fais un constat extrêmement simple : les projets qui réussissent sont réalisés par des équipes petites, soudées, fortement expérimentées et/ou formées ayant des objectifs simples avec un encadrement clair. Je fais un autre constat malheureusement simple lui aussi : tous les projets qui mettent en œuvre les méthodes agiles (ou qui le revendiquent) voient leurs effectifs grossir, les délais et les contenus non respectés, le désengagement s’installer car impliquant des processus déresponsabilisant !

Je terminerais par un exemple de simplicité qui m’a marqué voilà bien des années. C’est un échange qui a eu lieu entre Napoléon (1769 – 1821) et Laplace (1749 – 1827):

  • Napoléon : Monsieur de Laplace, je ne trouve pas, dans votre système mention de Dieu ?
  • Laplace : Sire, je n’ai pas eu besoin de cette hypothèse.
  • Devant les savants ayant déploré que Laplace fasse l’économie d’une hypothèse qui avait justement « le mérite de tout expliquer », Laplace répondit cette fois-ci à l’Empereur
  • Laplace : Cette hypothèse, Sire, explique en effet tout, mais ne permet de prédire rien. En tant que savant, je me dois de vous fournir des travaux permettant des prédictions

Advertisements