11. 04. 2024
Business Service Monitoring, NetEye, SLM
Das Research & Development Team (kurz R&D) ist das größte Team unserer Business Unit. Unsere Verantwortung liegt darin, qualitativ hochwertige Software zu entwickeln, diese an unsere Kunden auszuliefern und zu pflegen. Außerdem stellen wir gemeinsam mit unserem Service & Support Team den 2nd-Level Support zu unseren Lösungen bereit.
Die System Integration Business Unit war immer schon eine der am schnellsten wachsenden Abteilungen unseres Unternehmens. Dieses schnelle Wachstum stellte uns vor große Herausforderungen in unterschiedlichsten Bereichen. Die schwierigsten waren unter anderem: die Arbeitsteilung, die Priorisierung der Aufgaben, Effiziente Nutzung der Zeit, Wissenstransfer im Team und dementsprechend die Integration neuer Kollegen.
Um die Zeit zwischen den Releases neuer Features so gering wie möglich, gleichzeitig aber die Produktqualität und die Motivation der Team-Mitglieder so hoch wie möglich zu halten, mussten wir einschreiten und wichtige Entscheidungen treffen. Die Idee der „Agile Transformation“ war geboren.
Als erstes organisierten wir unser Team um. Aus mehreren, kleineren, produktspezifischen Teams wurde ein großes R&D Team. Dieses “neue” Team war nun in der Lage flexibler zu arbeiten, neue Mitarbeiter effizienter einzugliedern und das angesammelte Wissen gleichmäßig unter allen Mitgliedern zu verbreiten. Als krönenden Abschluss waren wir im Frühjahr 2016 in der Lage vom ursprünglichen Wasserfall-ähnlichen Modell, komplett auf agile Entwicklung um zu steigen.
Die Agile Transformation, wurde von Professor Werner Wild, der in der IT-Welt für seine Kompetenz im Bereich Agile Development bekannt ist, begleitet. Diese „Transformation“ hatte positive Auswirkungen auf jegliche Aspekte die mit Produkverbesserungen, Änderungen oder Fehlerbehebungen verbunden sind.
Um meine Ausführungen verständlich und lesbar zu halten, wird jeder Artikel meiner Serie einen Aspekt unseres Entwicklungsprozesses bzw. unserer Organisation behandeln.
In diesem ersten Teil, möchte ich einen generellen Überblick über die Umstrukturierung unseres Teams, unserer Workflows, der organisatorischen Änderungen und unserer Ziele geben.
Agile Methoden & Task Management
Der erste Schritt der Transformation war die Suche nach den Ursprüngen der erkannten Schwächen und das Untersuchen von möglichen Lösungen, um zu verstehen ob bereits existierende Ansätze den Schwächen entgegenwirken können *und* gleichzeitig zu unserem Team passen. Bereits früh entschieden wir uns für die Prinzipien des Lean Software Development als Basis und für ein Multi-Kanban Setup für das Task Management. (Dazu wird es später einen separaten Artikel in dieser Serie geben.)
Als digitale Unterstützung bauen wir auf den Atalassian Stack (BitBucket, JIRA, Confluence und HipChat für Source Code-, Issue- und Knowledge Management.
In der realen Welt, nutzen wir drei Kanban Boards und zwei große Monitore für unser Dashboard/Andon, um zu verfolgen was im Team gerade passiert. Außerdem haben wir unseren Arbeitstag neu organisiert. Wir unterteilten jeden Tag in vier sogenannte „Timeslots“ zu jeweils zwei Stunden. Um diese einhalten zu können und Unterbrechungen zu minimieren, haben wir auch die anderen Teams dazu bewegt unsere neuen Zeiten zu respektieren.
Diese neuen Werkzeuge lieferten uns schlussendlich den Beweis für all das, was wir in der Analyse-Phase bereits vermutet hatten:
Es wurden zu viele Aufgaben gleichzeitig priorisiert und wir liefen dadurch Gefahr, Issues wiederholt in die aktuelle Prioritätenliste aufzunehmen, schlussendlich an allem aber nur stückchenweise zu arbeiten.
Sobald wir unsere Aufgaben in der Realität vor uns hatten, indem wir sie auf Kanban-Kärtchen schrieben und an die Kanban-Boards hefteten, war es für das Team extrem befriedigend zu sehen wie die übervolle Liste der offenen Issues stetig kürzer und kürzer wurde. Ab diesem Zeitpunkt, konnten wir uns auf ein Maximum gleichzeitiger Arbeitsaufträge pro Arbeitsschritt einigen (Anzahl der Issues pro Spalte des Kanban-Board), und alles daran legen dieses auch einzuhalten.
Für eine sinnvolle Quantifizierung des Arbeitspensums, definierten wir einen ungefähren maximalen Zeitaufwand pro Kanban Karte: Wir einigten uns auf einen bis maximal sechs Timeslots. Bei zwei Stunden pro Timeslot, bedeutet dies also 2 Stunden, bis maximal zwei Arbeitstage (der letzte Timeslot jedes Arbeitstags ist flexibel und wird daher nicht geplant). Größere Tasks mussten also in mehrere, kleine Sub-Tasks aufgeteilt werden. Mehrere kleine, einfache Aufgaben fassten wir in logisch übergeordnete Aufgaben zusammen.
Die wichtigsten Vorteile dieser Vorgehensweise sind:
- Vorhersagbarkeit: Wir wissen, dass in den meisten Fällen, spätestens zwei Tage nachdem ein Task in die Entwicklungs-Liste gekommen ist, derselbe in der Spalte „Done Done“ sein wird (=Cycle Time) und somit abgeschlossen ist.
- Schnelle Auslieferung: Mit dieser Vorgehensweise und unserer neuen automatisierten Infrastruktur, können unsere Kunden nun sofort nach Beendigung der Entwicklung von neuen Features profitiern.
- Eliminierung von „Waste“: Ein unfertiger Task steigert den Wert eines Produkts nicht. Da wir nun konstant und kontinuierlich neue Features abschließen und ausliefern, profitieren unsere Produkte *direkt* von unseren Entwicklungen.
- Qualität: Drei der vier Schritte auf unserem Kanban stehen direkt oder indirekt mit Verbesserung der Code-Qualität in Verbindung. (Development, Testing, Review)
Automatisierung
Die neu eingeführte Automatisierung bei Entwicklung und Deployment bedarf einer geeigneten und ebenfalls automatischen Qualitätskontrolle. Aus diesem Grund haben wir einen Großteil der vorher teils zeitaufwändigen, manuellen Entwicklungs- und Deployment-Schritte automatisiert. Für jeden dieser Automation-Jobs nutzen wir den kontinuierlichen Integrationsagenten Jenkins (vorher Hudson), welcher das Thema eines separaten Artikels sein wird. Hier möchte ich Ihnen nur einen kurzen Überblick geben:
- Kontinuierliche Integration: Automatisierte Builds, direkt von unseren Entwicklungs- und Maintenance Branches aus dem Source Code Management.
- Kontinuierliches Deployment: Automatisiertes Deployment neuer Pakete, welche Bugfixes und Features von BitBucket in den richtigen Repositories veröffentlichen
- Kontinuierliches Testen: Ein Set von Integrations- und Unit-Tests (+ 4 Selenium Test Instanzen), die immer ausgeführt werden wenn ein Commit auf ein Repository gepusht wird. Ergänzt wird dies durch visuelles Feedback über erfolg/scheitern auf unserem Dashboard/Andon, um das Lean Development Prinzip „Fail Fast“ zu erfüllen.
Zusätzlich haben wir uns selbst darin geübt, zu erkennen, wenn wir ähnliche Tasks mehrfach ausführen und darüber nachzudenken *ob* und *wie* diese automatisiert werden können. Nur so können wir die wertvolle Zeit jedes Team-Mitglieds effizient einsetzen.
Die gesamte Automatisierungsinfrastruktur unterliegt einem laufenden Optimierungsprozess. Die Zeit die wir diesen Skripts widmen müssen, wird fortschreitend jedoch immer geringer werden. Die Zeit die wir bis jetzt durch unsere Automatisierung eingespart haben übertrifft bereits jetzt die bisher investierte Zeit bei weitem. Praktische Beispiele solcher Automatisierungen aus unserem täglichen Arbeitsalltag sind der gesamte Release-Prozess, die Generierung und der Ausdruck von Kanban Cards und das Time Tracking.
Den Überblick behalten
Wie vorhin bereits erwähnt, bauen wir stark auf Automatisierung, wir brauchen aber auch sofortiges Feedback darüber was gerade gut, oder eventuell auch einmal schlecht läuft. Um das zu überwachen, nutzen wir die Open Source Lösung Dashing. Dabei handelt es sich um eine einfach einzurichtende und einfach erweiterbare Lösung zur Darstellung unterschiedlichster Dashboards in unserem Büro. Diese Dashboards nutzen wir um Notfälle, den Build-Fortschritt, letzte Deployments, den Status der Jenkins Jobs, Projektfortschritte und andere wesentliche Kennzahlen für das Tagesgeschäft unseres Teams darzustellen. Auch dieses Thema wird zu einem späteren Zeitpunkt genauer behandelt werden.
Tägliche Standup-Meetings und wöchentliche Retrospective-Meetings wurden eingeführt, um die Wissensverteilung, aber auch unsere Selbstreflexion zu fördern. Das hilft uns Verlangsamungen zu erkennen und alle aktuellen Themen im Team mitzubekommen. Außerdem hat jedes Team-Mitglied so die Möglichkeit wichtige Themen anzusprechen.
Vor unserer Transformation, lag das Wissen nur bei einzelner Personen die üblicherweise an den selben Produkten oder Modulen entwickelten. Neue Kollegen, oder Team-Mitglieder die an anderen Produkten arbeiteten, hatten Schwierigkeiten sich Wissen selbständig, nur durch Lesen, anzueignen. Um dem entgegenzuwirken und Wissen effizient zu teilen, begannen wir sehr früh im Prozess intensiv alles zu dokumentieren. Dies geschah nicht nur im Code, sondern auch strukturiert in Atlassian Confluence, was alle Team-Mitglieder dazu ermutigte nun auch an nicht vertrautem Code zu arbeiten. Das Ergebnis davon ist, dass seither alle Team-Mitglieder in der Lage sind an allen Projekten und Produkten arbeiten zu können.
Ziele
Wie Sie sehen, befanden wir uns in einer Ausganssituation, in der sich unsere Umstände und Umgebung änderten, wir aber Schwierigkeiten hatten unsere Organisation diesen Änderungen anzupassen. Gemeinsam haben wir es geschafft, den Ursprung unserer Unzulänglichkeiten zu finden. Mit Professor Wild haben wir uns selbst Ziele gesetzt und diese so definiert, dass deren Erreichung automatisch die Lösung einer oder mehrerer Schwierigkeiten mit sich brachte.
Ein Beispiel ist die limitierte Task-Dauer von 1-6 Timeslots. Für die Realität bedeutet das, eine Task Cycle Time von weniger als 2 Tagen. Dies ermöglicht uns die benötigte Entwicklungszeit vorherzusagen und den theoretischen Maximalaufwand zu schätzen. In Kombination mit den Kanban-Boards, wird so das gleichzeitige Arbeitspensum reduziert, was wiederum die verlorene Zeit durch Kontextänderungen und unfertige Tasks verringert. Es liegt auf der Hand, dass dies unweigerlich nicht nur zu Zeit- sondern auch zu Geld-Einsparungen führt.
Eine weitere Hilfe zur Vermeidung verschwendeter Ressourcen war die Investition in die Automatisierung von Tasks. Die Zeit die wir in die Automatisierung von wiederkehrenden Aufgaben investiert haben, hat sich bereits mehrfach rentiert. Vorher konnte das Deployment eines Pakets bis zu einer Stunde dauern (vom letzten Commit bis zum Deployment auf dem RPM Repository), jetzt dauert das maximal drei Minuten.
Automatisierte Tests, Pair Programming, Code Reviews und ein eigener Schritt auf der Kanban Spalte für das manuelle Testen, hatten (und haben) signifikante positive Auswirkungen auf die Qualität unseres Codes.
Die Agile Transformation, hat eine Arbeitsumgebung geschaffen, welche es uns erlaubt schnell und effizient auf neue und sich ändernde Anforderungen sowohl an der Software, als auch an das Team, zu reagieren. Abschließend bleibt mir nur noch ehrlich zu sagen, dass es meiner Meinung nach ein voller Erfolg war.
Benjamin Gröber
R&D Software Architect at Wuerth Phoenix
Hi, my name is Benjamin, and I'm Software Architect in the Research & Development Team of the "IT System & Service Management Solutions" Business Unit of Würth Phoenix.
I discovered my passion for Computers and Technology when I was 7 and got my first PC. Just using computers and playing games was never enough for me, so just a few months later, started learning Visual Basic and entered the world of Software Development. Since then, my passion is keeping up with the short-lived, fast-paced, ever-evolving IT world and exploring new technologies, eventually trying to put them to good use. I'm a strong advocate for writing maintainable software, and lately I'm investing most of my free time in the exploration of the emerging Rust programming language.
Author
Latest posts by Benjamin Gröber
25. 11. 2022
Development
What is the perfect development team size?