"Agile" ist mehr als ein Mindset
In diesem Artikel zeigen wir, das Agile mehr als eine Arbeitsweise ist – es ist eine Versicherung für jedes Produkt, ob Website oder Applikation.
Was heisst Agil?
Das Wort "agil" kommt aus dem lateinischen und zeugt von großer Beweglichkeit – etwas ist regsam und wendig. Eigentlich Eigenschaften die man sich für seine Produkte und genutzten Werkzeuge wünscht.
Mit dem Agile Manifesto wurde dem Begriff 2001 eine neue Dimension in der Organisation gegeben. Scrum, Kanban und viele weitere wollen die 12 Prinzipien als Alternative zum hierarchischen Taylor-Prinzip umsetzen. Diese Agile-Prinzipien enthalten unter anderem
den Fokus auf motivierte Mitarbeitende, denen man Vertrauen entgegenbringt
Ausrichtung an Kundenanforderung
die Betonung von sich selbst organisierenden Teams
Technische Exzellenz als Grundlage und Treiber von Agilität
Auch wir haben uns entschieden, brudi agil zu organisieren und dezentrale Entscheidungen auf Basis von Kompetenz und Rollen zuzulassen. Die Gründe dafür können auf unserer Ethos-Seite nachgelesen werden.
Software ist ein kollaborativer Prozess. Das Entwickeln von Software ist eine kollaborative Reise, welche lange vor dem Prototypenbau beginnt und weit über den Go-Live hinaus geht.
AX • Dedicated Software
Das agile Mindset
Für viele ist "agiles Mindset" inzwischen das Unwort der agilen Bewegung. Es bezeichnet wie kein anderes Wort die herrschende Ohnmacht. Es dient als die Generalentschuldigung: Wenn irgendwo nicht richtig agil gearbeitet wird oder werden kann, dann liegt es am fehlenden agilen Mindset.
Das klingt wie Vorwürfe an Agile-Transformationsberater*innen, welche vielleicht auf Biegen und Brechen ein Callcenter agil machen wollen. Denken wir jedoch an die 12 Prinzipien des Agile-Manifesto, fällt da mehrfach der Begriff Software. In diesem Artikel wollen wir nun hervorheben, das Agilität mehr als eine Arbeitsweise ist – es ist eine Versicherung für jedes Produkt, ob Website oder Applikation.
Agile Produkte für mehr Flexibilität und Kontrolle
IT Sicherheit ist ein Katz- und Maus-Spiel. Lücken werden entdeckt, Lücken werden geschlossen. Technologien entwickeln sich, werden überholt und neu eingeführt. Datenschutz-Verordnungen (DSGVO) werden angepasst und Betriebssysteme nicht mehr unterstützt. All diese Faktoren der digitalen Umwelt erfordern eine ständige Anpassungsfähigkeit von Websites und Applikationen.
Und dann kommen noch die eigenen Ansprüche und wechselnde Anforderungen an das Produkt dazu. Ein neues Logo, zusätzliche Interaktionsmöglichkeiten mit den Kund*Innen, ein neues Feld für die Mitarbeitenden - all das soll realisiert und getestet werden können, ohne dass ganze Systeme abgelöst werden müssen oder gar erst ein ganz neues Projekt mit einem Dienstleistenden aufgegleist werden muss. Und falls diese nicht agil sind, muss vor dem Projektstart der Änderung auch der ganze Ablauf im Wasserfall geplant werden. Mike Shiva macht leider keine exakten Prognosen für die technologische Zukunft, deshalb hinkt man bei starrer Projektplanung immer einen Schritt hinterher.
Ein weiterer Nachteil am starren Modell ist das "fertige Produkt". Nach der Planungsphase gibt es keine vorgesehenen Möglichkeiten mehr, Einfluss auf dieses Produkt zu nehmen. Die Kontrolle gibt es erst bei der Abnahme – nicht wie in agilen Modellen, wo sich Auftraggeber und Entwickler wiederkehrend austauschen, um das Produkt up-to-date zu halten.
CI/CD - Kontinuierliche Integration & Entwicklung
Allenfalls ist die Situation geläufig: Ein Dienst oder eine Applikation ist aufgrund von Wartungsarbeiten temporär unerreichbar. Nervig wenn man privat gerade eine Website besuchen will, teuer wenn es eine Unternehmensapplikation betrifft. Doch hatte Netflix oder die SBB-App schon einmal Wartungsarbeiten? Ich kann mich auch nicht erinnern, aber an die neuen Funktionen sehr wohl. Zum Start der genannten Beispiele gab es diese Ausfälle übrigens schon. Bis Einer nach dem Anderen auf Continuous Delivery gesetzt hat. Aber wie funktioniert diese kontinuierliche Auslieferung?
Der Trick dabei ist,
die Applikation in Microservices aufzuteilen,
automatisierte Tests zu schreiben,
sowie der dynamische Betrieb in der Cloud.
In diesem Artikel geben wir einen Einblick in Microservices und wie die AX Suite helfen kann, den Wechsel zu Microservices mit CI/CD zu stemmen.
AX • Dedicated Software
Microservices sind losgelöste Programmteile, welche dadurch separat aktualisiert und skaliert werden können. Die automatisierten Tests garantieren dabei, dass die anderen Programmteile wie gewünscht weiter funktionieren, wenn ein Service mit Abhängigkeiten erneuert wird. Diese werden meist auf einer Testinstanz durchgeführt, bevor das Update veröffentlicht wird. Der Betrieb in der Cloud oder die cloud-native Strategie macht die Weiterentwicklung noch wahrlich kontinuierlich: Das Update wird in der Cloud released. Das bedeutet keine Notwendigkeit, eine Applikation zu updaten, beim nächsten Aufruf wird automatisch die neuste Version zur Verfügung gestellt. Doch auch wenn die alte Version gerade noch benutzt wird – falls das Datenmodell nicht grundlegend geändert wurde, funktionieren beide Versionen parallel. Eine mit den neuen Funktionen und eine ohne.
Erhalte alle Vorteile von modernen cloud-computing Modellen und kontinuierlicher Integration.
AX • Dedicated Software
Agil bleiben
Fortlaufende Integration und Entwicklung, gepaart mit einem agilen Entwicklungspartner wie brudi, bietet grösste unternehmerische Freiheit, wie sie in vielen Innovationsprojekten notwendig ist. Plötzlich dürfen Anforderungen hinzu kommen oder geändert werden, ohne das Abhängigkeiten den Aktualisierungsprozess verunmöglichen.
Gemeinsam mit den DevOps werden alle Dienste auch nach der Veröffentlichung auf dem neusten Stand gehalten, aufgedeckte Lücken geschlossen und Bugs im Nu behoben. Ganz schön agil.
DevOps Automation macht Ressourcen per Self-Service und Automatisierungen dort verfügbar, wo sie am dringendsten benötigt werden.
AX • Dedicated Software