À l’époque et maintenant

Dans un message reçu récemment, Martin Alaimo me demande :

Dans la communauté agile d’Amérique latine se déroule en ce moment une discussion très intéressante. Il s’agit de la signification de ce principe du manifeste agile : “Les meilleurs architectures, exigences, et conceptions émergent d’équipes auto-organisées”.

Le sujet de la discussion est la signification d’“émerger”, et au fond, quelle est la signification de “l’architecture émerge”.

Je voudrais donc vous en faire part pour avoir vos impressions en tant que signataire du manifeste agile.

  1. À l’époque en 2001, au moment de la signature du manifeste, quel était le sens dans lequel le mot “émergent” était utilisé en ce qui concerne les architectures ?
  1. 13 ans après, est-ce qu’il y aurait quoi que ce soit que vous changeriez/adapteriez/ajouteriez en ce qui concerne l’architecture dans le monde agile ?

Je ne peux me prononcer sur ce que chacun pouvait penser à ce moment là. Je ne suis même pas certain de ce que je pensais. Voici ce que j’ai, et nous avons, pu avoir à l’esprit. Ou plutôt ce que j’ai à l’esprit maintenant.

Historiquement, les approches plus lourdes (que les méthodes agiles - NdT) de développement logiciel ont inclues une séparation entre l’architecture et la conception, du “simple code”. Nous ressentions que c’était loin d’être l’idéal. La programmation est le processus d’exprimer une conception dans un certain langage. De même que nos pensées modèlent nos mots, nos mots modèlent nos pensées. La fin de la phrase est conditionnée non seulement par ce que nous pensons que nous voulons dire, mais par la manière dont nous commençons à le dire. Et quelques fois nous revenons en arrière et nous réécrivons le début, à cause de ce que nous trouvons à la fin.

Le paragraphe précédent est un exemple, car je ne suis pas revenu dessus pour le corriger. C’est un exemple de quelque chose qui a besoin d’être revu. Il a débuté en abordant le sujet du logiciel et s’est transformé en quelque chose traitant du langage, de la pensée et de l’influence de l’un sur l’autre. Cette partie de l’article pourrait être mieux conçu avec un passage sur le langage d’abord suivi d’une séquence comportant une analogie sur le logiciel. Mais je ne vais pas faire cela, pour montrer comment un texte peut survenir, ou au moins peut s’esquisser, pour être changé. C’est la partie du sujet qui nous intéresse.

Toutefois, là où je pensais vraiment y venir avec ce paragraphe c’était d’aborder le sujet des personnes. En informatique, il s’agit des personnes. Peut être que j’aborderai ce sujet … mais pas tout de suite.

À l’époque à Snowbird, nous percevions que le code devait influencer la conception. Ce n’était une voie à sens unique. Peu importe la quantité de conception que nous avions fait en tant que telle, dès le moment où nous commencions à l’exprimer en code, la conception devait changer. Nous l’exprimions de la manière dont le code nous disait comment la conception voulait être. C’est très anthropomorphique. Trés métaphorique. Nous savions cela. Presque aucun d’entre nous n’a jamais entendu vraiment le code nous parler. (À l’exception d’un gars : tu te reconnaitras.)

Ces découvertes de conception se produisent constamment tout au long de la vie du projet, si tant est que vous y restez ouvert. Pour leurs rester ouverts, vous devez garder le code vivant : donc en le revoyant. Toutefois, pour leurs rester ouvert, vous avez aussi besoin de très bons concepteurs présents, pour écouter, lorsque le code parle.

Et voilà (en français dans le texte - NdT) ! Il y a les personnes. J’étais certain qu’elles arriveraient. Les personnes doivent être auto-organisées. Et elles doivent avoir la capacité, pas simplement le droit, d’améliorer la conception. Elles améliorent la conception au fil du temps. Elle change. Elle émerge.

Si le programme doit rester vivant, la conception doit changer, elle doit émerger. Si cela doit arriver, l’équipe doit le faire. Si l’équipe doit le faire, elle doit s’organiser pour le faire. La meilleure manière de s’organiser est de réagir dans l’instant. Pour réagir dans l’instant, vous devez vivre dans l’instant présent.

Une équipe auto-organisée est la meilleure manière pour garder une équipe dans l’instant présent, la meilleure manière pour réagir dans l’instant présent, la meilleure manière d’améliorer la conception au moment voulu.

Les meilleurs résultats émergent des équipes auto-organisées.

Auteur : Ron Jeffries
Source : Emergent design
Date de parution originale : 2 novembre 2014

Traducteur : Nicolas Mereaux
Date de traduction : 19/11/2014

Licence Creative Commons
Ce(tte) oeuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.