Software Engineering kann ein komplexes Thema sein. Es ist sicherlich für Unternehmen und es ist kein Geheimnis, dass es schnell sehr komplex werden kann.

Es braucht nicht viel: eine weitere Integrationsanforderung, ein kniffliges Stück Arbeit automatisieren, nur eine weitere harmlose kleine Geschäftsanforderung erfüllen … Es summiert sich schnell.

Und das ist nur die Software selbst. Was ist mit allem, was wir mögen/wollen/müssen, um eine Bewerbung zu verpacken? Das SDLC bietet eine Fülle von Komplexitäten, die es zu überwinden gilt, und manchmal kann sich alles ein wenig überwältigend anfühlen.

Hier bei Kingfisher haben wir derzeit über 60 Scrum-Teams und ~1100 Ingenieure, die alle zu unserem „Digital Estate“ beitragen, und darüber hinaus machen wir Fortschritte durch eine Dev(Sec)Ops-Transformation. Manchmal, um ehrlich zu sein, fühlt es sich an, als würden wir uns auf einer exponentiellen Wachstumskurve der Komplexität befinden.

Verstehen Sie mich nicht falsch, Kingfisher ist damit sicherlich nicht allein – wenn wir uns umschauen, sehen wir, dass dies eine allgemeine Tatsache ist – die Natur des Tieres, wenn Sie so wollen, und unsere Erfahrung und unser Training (und Twitter) sagen es uns ist es. Dies ist ein großer Teil dessen, was eine Karriere im Software Engineering so spannend macht. Aber was tun wir, um diese Komplexität zu mildern?

Hintergrund

Als meinen ersten Beitrag hier dachte ich, dass es nützlich sein könnte, etwas Kontext und Einblick in die digitale Abteilung von Kingfisher zu geben.

Wir führen derzeit vier Hauptarbeitsprogramme durch, von denen jedes eine Reihe von „Domänenteams“ enthält (Sie würden auch den Begriff Produktteam hören, aber dazu in einem späteren Beitrag mehr), die Lösungen für ihre jeweilige Geschäftsdomäne bereitstellen. Ganz zu schweigen von den Teams und Systemen, die all diese Geschäftsfähigkeiten untermauern. Jedes Domänenteam wird dann in eine Reihe von Funktionsteams aufgeteilt. Auf Domänenebene gibt es eine Governance-Schicht: Jede Domäne sollte mindestens Folgendes haben:

• ein Produktmanager,
• ein technischer Leiter und
• ein Lieferkontakt

Aber wie Sie als belesener Fachmann wissen werden, gehört viel mehr dazu, als nur eine einzige Governance-Ebene hinzuzufügen.

Der Beginn unserer „digitalen Transformation“ vor einigen Jahren ermöglichte und förderte ein uneinheitliches Teamwachstum, förderte mehr oder weniger einen Mangel an zentraler Governance und begünstigte stattdessen Programmautonomie, um eine ausreichend hohe Liefergeschwindigkeit zu erreichen. Das hat gut funktioniert und wir haben sehr viel erreicht, aber wir haben auf dem Weg zwangsläufig viele (verschiedene Formen von) Schulden angehäuft, und irgendwann fing alles wieder an, sich zu verlangsamen.

Evolution

Eine der jüngsten Lösungen zur Bewältigung unserer Komplexität in großem Maßstab bestand darin, eine neue Rolle einzurichten – den Principal Software Engineer – zu dem ich gehöre.

Auch dies ist keine neue oder einzigartige Lösung. Es braucht nicht viel, um zu entdecken, dass dies schnell zu einer ziemlich allgegenwärtigen Rolle in der Industrie wird (wenn es das nicht schon ist). Für uns sitzt ein PSE neben unseren Programmmanagern und der Produktleitung auf Programmebene. Unsere Rolle besteht im Wesentlichen darin, innerhalb und zwischen unseren Programmen ein gewisses Maß an Konsistenz herzustellen und aufrechtzuerhalten und dazu beizutragen, unsere zukünftige Ausrichtung kohärenter zu definieren.

Eine der ersten Aktivitäten, die wir für vernünftig hielten, bestand darin, unsere Prinzipien zu definieren, um die gewünschten Verhaltensweisen voranzutreiben und einen konsistenten Rahmen für unsere Abteilung als Ganzes bereitzustellen.

Die erste Version unserer Prinzipien ist jetzt „live“ und wir arbeiten gemeinsam daran, unsere Entscheidungsfindung auf der Grundlage dieser Prinzipien zu gestalten. Sie sind der erste und grundlegendste Schritt, an dem sich unsere Teams ausrichten können, und helfen dabei, ein gemeinsames Vokabular zu erstellen und unsere Roadmap zu steuern.

Die Prinzipien selbst sollen nicht revolutionär oder kontrovers sein. Vielmehr spiegeln sie eine Sammlung bewährter Best Practices wider, die entweder etabliert oder relativ neu sind. Als solche sind sie sowohl ambitioniert als auch ein Spiegelbild aktueller Aktivitäten.

Es ist auch wahr, dass ihre Zahl ziemlich hoch ist – 30! — und das war uns schon früh im Formulierungsprozess bewusst. Letztendlich haben wir uns darauf geeinigt, dass es als Ausgangspunkt besser ist, mehr Details als weniger bereitzustellen. Was wir nicht tun wollen, ist „den Ozean zum Kochen zu bringen“, obwohl ein Kritiker diese Verleumdung leicht von sich geben könnte. Vielmehr spiegeln sie das Eingeständnis und meine anfängliche Behauptung wider, dass Softwareentwicklung komplex ist und dass alle unsere Teams in unterschiedlichem Maße voneinander isoliert sind und sich daher Prioritäten und Schwerpunkte zwangsläufig unterscheiden.

Wir gehen davon aus und hoffen, dass sich diese Prinzipien im Laufe der Zeit ändern und an Zahl abnehmen werden, da einige von ihnen in die gemeinsamen Arbeitsweisen und natürlichen Verhaltensweisen unserer Teams übergehen.

Die nächste Entscheidung, die wir trafen, bestand darin, unsere Prinzipien in vier logische Gruppierungen zu kategorisieren:

• Organisatorisches
  Als Abteilung ist Engineering verpflichtet, unsere IT-Strategie zu verfolgen und anzuwenden. Unsere Organisationsprinzipien sollten unsere Architekturprinzipien sowohl nähren als auch von ihnen nähren und eine Grundlage für unsere Betriebs- und Implementierungsprinzipien bilden.
• Architektur
  Letztendlich ist Engineering mit den Architekturprinzipien unserer Organisation ausgerichtet, aber hier nennen wir einige dieser Prinzipien, die relevant sind.
• Operativ
  Geleitet von unseren organisatorischen und architektonischen Prinzipien müssen wir sicherstellen, dass wir gut gerüstet sind, um schnell auf Kunden- und Marktanforderungen zu reagieren und unseren Kunden ein zuverlässiges Erlebnis zu bieten, während wir gleichzeitig sicherstellen, dass wir wirtschaftlich arbeiten, um unsere Auswirkungen auf die Unternehmenskosten und -kosten zu reduzieren die natürliche Umgebung.
• Implementierung ( ich bin mir ziemlich sicher, dass das ein richtiges Wort ist? )
  Aufbauend auf den organisatorischen und architektonischen Prinzipien, wie wir unsere Anwendungen schreiben und zusammenstellen, muss sichergestellt werden, dass wir qualitativ hochwertige Softwarelösungen in dem Tempo liefern, das unser Geschäft erfordert.

Wir haben dann festgestellt, dass wir die Prinzipien jeder Kategorie gruppieren können, um Schlüsselthemen hervorzuheben und hervorzuheben, warum wir die einzelnen Prinzipien festgelegt haben.

Um unseren Teams zu helfen, den Zweck und die Vorteile jedes Prinzips zu verstehen, haben wir uns schließlich von TOGAF inspirieren lassen und eine Erklärung und Begründung für jedes Prinzip bereitgestellt.

Unsere Prinzipien also, ohne die blutigen Details unserer Begründungen:

Ich weiß zu schätzen, dass ein Bild mit so viel eingebettetem Text nicht für alle zugänglich ist, und ich entschuldige mich dafür.

Wir hoffen, dass diese Prinzipien unseren Teams eine solide Grundlage bieten, auf der sie gedeihen können, und dass wir unsere DIY-Marken in Großbritannien, Irland, Frankreich, Polen, Rumänien, Spanien und Portugal effektiv unterstützen und ihnen helfen können, für anhaltenden Erfolg zu sorgen.

Wenn Sie daran interessiert sind, uns auf unserer Reise zu begleiten, besuchen Sie bitte unsere Karriereseite .

Danke fürs Lesen!