Oran en pleine nature, et ce qui nous a surpris

Une note de version décrit ce que fait une version. Il est moins courant de décrire ce qui s’est passé ensuite, en partie parce que la réponse est souvent légèrement embarrassante.

Voici trois choses sur lesquelles nous nous sommes trompés.

Nous nous attendions à ce que l'attribution des coûts soit utilisée pour les coûts

Oran 3.1 a attribué des dépenses par agent parce que les équipes ne pouvaient pas répondre au coût de quoi que ce soit. C'était exact et l'utilisation n'était pas celle à laquelle nous nous attendions.

La première chose que la plupart des équipes ont faite avec l’attribution par agent a été de ne pas réduire les dépenses. Il s'agissait de trouver des agents dont personne ne savait qu'ils étaient en fuite. L’attribution s’est avérée être un outil d’inventaire avant d’être un outil financier, car une ligne de coûts sans propriétaire reconnu est le signal le plus clair possible d’un oubli.

Cela a recadré notre façon de penser la propriété, et c'est en grande partie la raison pour laquelle 3.6 traite la propriété comme la propriété d'un agent plutôt que comme une convention.

Nous nous attendions à ce que les budgets soient généreux

Nous avons construit des budgets de disjoncteurs dans la version 3.2 en supposant que les équipes fixeraient un plafond bien au-dessus de l'utilisation prévue, comme filet de sécurité contre les comportements incontrôlables.

Beaucoup les ont délibérément serrés, proches de l'utilisation prévue, et ont utilisé le bloc comme signal plutôt que comme protection. Lorsqu’un agent atteignait sa limite, c’était de l’information : quelque chose changeait, regardez-le.

Nous avions construit un garde-corps et les équipes l'utilisaient comme détecteur de fumée. Cela fonctionne, et ce n’est pas à cela que sert cette fonctionnalité.

Nous nous attendions à ce que les évaluations soient écrites avant le déploiement

Oran 3.3 supposait que les critères seraient définis dès le départ, ce que nous recommandons et ce que presque personne ne fait.

Dans la pratique, la plupart des équipes ont rédigé leur première évaluation après qu'un agent ait produit quelque chose de mal, travaillant à rebours depuis l'échec. Les critères qui en ont résulté étaient plus restreints qu’un ensemble conçu et souvent plus utiles, car ils codaient un échec réel plutôt qu’imaginaire.

Nous avons arrêté de traiter cela comme si les équipes le faisaient de manière incorrecte. Un ensemble qui se développe à partir d’échecs réels converge vers quelque chose de bon et a l’avantage d’exister.

Qu'est-ce qui a tenu

L'asymétrie lecture-écriture. Les équipes accordent aux agents un accès large en lecture et un accès restreint en écriture, de manière cohérente, dans tous les secteurs dans lesquels nous travaillons. Construire la couche politique autour de cette hypothèse était juste.

La valeur d’un catalogue partagé. La duplication entre les équipes était aussi importante que prévu et Agent Hub l'a résolue comme prévu, ce qui est l'élément le moins surprenant de cette liste.

Pourquoi nous publions les miss

Parce qu’une plate-forme construite uniquement sur ce que ses créateurs attendaient s’éloigne de ce que font ses utilisateurs. Les trois surprises ci-dessus ont chacune changé quelque chose dans la version 3.6, et aucune d’entre elles n’aurait fait surface sur une feuille de route.

Si votre déploiement fait quelque chose avec Oran que nous n’avons clairement pas prévu, nous aimerions en entendre parler. C’est véritablement la chose la plus utile que nous recevions.

Suivant

La page des versions couvre toutes les versions à partir de Keter 1.0. L'adhésion à la communauté de développement ouverte est gratuite et les observations peuvent être envoyées à contact@capconsultor.eu.