Oran in freier Wildbahn und was uns überrascht hat

Ein Versionshinweis beschreibt, was eine Version tut. Es ist seltener, zu beschreiben, was als nächstes geschah, auch weil die Antwort oft leicht peinlich ist.

Hier sind drei Dinge, die wir falsch gemacht haben.

Wir haben erwartet, dass die Kostenzuordnung für die Kosten verwendet wird

Oran 3.1 ordnete die Ausgaben pro Agent zu, da die Teams nicht beantworten konnten, was etwas kostete. Das war richtig und die Nutzung entsprach nicht unseren Erwartungen.

Das erste, was die meisten Teams bei der Zuordnung pro Agent taten, war, die Ausgaben nicht zu reduzieren. Es handelte sich um Fundagenten, von denen niemand wusste, dass sie im Einsatz waren. Die Namensnennung erwies sich als Inventarisierungsinstrument, bevor sie ein finanzielles Instrument war, denn eine Kostenzeile ohne erkennbaren Eigentümer ist das deutlichste Signal dafür, dass etwas vergessen wurde.

Das hat unsere Denkweise über Eigentum neu definiert und ist ein wesentlicher Grund dafür, warum 3.6 Eigentum als Eigentum eines Agenten und nicht als Konvention behandelt.

Wir haben erwartet, dass die Budgets großzügig festgelegt werden

Wir haben in 3.2 Leistungsschalterbudgets erstellt, unter der Annahme, dass die Teams eine Obergrenze festlegen würden, die weit über der erwarteten Nutzung liegt, als Sicherheitsnetz gegen außer Kontrolle geratenes Verhalten.

Viele setzten sie stattdessen bewusst eng an, nahe an der erwarteten Nutzung, und nutzten die Sperre eher als Signal denn als Schutz. Wenn ein Agent an seine Grenzen stieß, war das eine Information: Etwas hat sich geändert, sehen Sie es sich an.

Wir hatten eine Leitplanke gebaut und die Teams nutzten sie als Rauchmelder. Es funktioniert und ist nicht der Zweck der Funktion.

Wir haben erwartet, dass Evaluierungen vor der Bereitstellung geschrieben werden

Oran 3.3 ging davon aus, dass die Kriterien im Voraus definiert würden, was wir empfehlen würden und was fast niemand tut.

In der Praxis schrieben die meisten Teams ihre erste Bewertung, nachdem ein Agent einen Fehler gemacht hatte, und arbeiteten rückwärts vom Fehler aus. Die daraus resultierenden Kriterien waren enger gefasst als ein entworfener Satz und häufig nützlicher, da sie eher einen tatsächlichen als einen eingebildeten Misserfolg kodierten.

Wir haben aufgehört, dies so zu behandeln, als ob Teams es falsch machen würden. Eine Menge, die aus tatsächlichen Misserfolgen entsteht, konvergiert zu etwas Gutem und hat den Vorteil, dass sie existiert.

Was hat gehalten

Die Lese-Schreib-Asymmetrie. Teams gewähren Agenten in allen Sektoren, in denen wir tätig sind, konsistent breiten Lesezugriff und eingeschränkten Schreibzugriff. Es war richtig, die Richtlinienebene auf dieser Annahme aufzubauen.

Der Wert eines gemeinsamen Katalogs. Die Duplikate zwischen den Teams waren so groß, wie wir erwartet hatten, und der Agent Hub hat sie wie erwartet behoben, was der am wenigsten überraschende Punkt auf dieser Liste ist.

Warum wir die Fehlschüsse veröffentlichen

Denn eine Plattform, die nur auf den Erwartungen ihrer Entwickler basiert, weicht von dem ab, was ihre Benutzer tun. Die drei oben genannten Überraschungen haben jeweils etwas in 3.6 verändert, und keine davon wäre auf einer Roadmap aufgetaucht.

Wenn Ihre Bereitstellung etwas mit Oran bewirkt, für das wir eindeutig nicht vorgesehen sind, würden wir gerne davon erfahren. Das ist wirklich das Nützlichste, was wir bekommen.

Als nächstes

Die Versionsseite deckt alle Versionen ab Keter 1.0 ab. Der Beitritt zur Open Development Community ist kostenlos und Kommentare können an contact@capconsultor.eu gesendet werden.