Simplicité

23 Jun 2016  —  2 minutes

La complexité engendre des coûts de conception, de maintenance et augmente les risques d’erreurs. De nombreuses équipes agiles utilisent les concepts de simplicité suivants (on les retrouve souvent sous forme de poster sur les murs de ces équipes):

KISS

KISS est l’acronyme de Keep It Simple, Stupide (Reste simple, idiot). Dans la conception d’un système, il est préconisé de commencer par des versions simples qui fonctionnent et de n’introduire de la complexité que quand on y est contraint.

Pour illustrer ce principe d’autres ont préféré détourner l’acronyme : > Keep it simple, stupid - Keep it stupidly simple - Keep it simple and stupid - Keep it simple, silly - Keep it small and simple - Keep it sweet and simple - Keep it simple and straightforward - Keep it short and simple - Keep it simple and smart - Keep it strictly simple - Keep it super-simple - Keep it sober and significant - Keep it short and sweet

DRY

DRY est l’acronyme de Don’t Repeat Yourself (Ne vous répétez pas). Ce principe cherche la simplicité par la factorisation du code.

YAGNI

YAGNI est l’acronyme You Ain’t Gonna Need It (Tu n’en auras pas besoin). L’idée de ce principe est de n’ajouter les fonctionnalités que quand c’est strictement nécessaire.

Poka yoke

Poka yoke signifie anti-erreur en japonais, c’est la version industrielle de la simplification. Il s’agit de trouver des solutions pour apporter un feedback très rapide sur les erreurs ou prévoir un système résistant aux étourderies : un détrompeur, une forme asymétrique, une prise réversible. Dans le domaine du logiciel on pourra par exemple : utiliser le typage fort, déclencher une erreur s’il manque un composant, rendre un appel de méthode idempotent, etc.

Conslusion

En simplifiant au niveau technique (KISS, DRY, Poka yoke) et au niveau fonctionnel (YAGNI, Poka yoke) on réduit les coûts de maintenance et on baisse les risques d’erreurs. Seulement attention, faire simple implique de pouvoir amender tout ou partie du système en permanence, pour ajouter chaque nouvelle petite fonctionnalité. Ce qui impose d’avoir une bonne stratégie de test et s’assurer ainsi que chaque changement ne présente aucune régression.


Sources:

Albiez Olivier

Je suis artisan logiciel et coach agile chez Azaé, passionné des méthodes de travail et de l’auto-organisation dans les entreprises. Curieux par nature, je suis toujours à la recherche de ce qui peut améliorer le travail collectif d’une organisation. Je suis récemment co-fondateur de Deliverous. Je suis signataire des manifestes Artisans du Logiciel et Agile.

Clavier Thomas

Je suis coach agile chez Azaé, enseignant à l’université de Lille 1 et co-fondateur de Deliverous, mes sujets de prédilection sont l’agilité, devops, docker, le lean startup et l’artisanat logiciel. Depuis plus de 10 ans, j’essaye de transformer le travail en un jeu, faire progresser les geeks et challenger les managers, poser des questions pour faire progresser les équipes.