Beschäftigt man sich mit dem Internet und Websites als Werkzeug für Unternehmen, kommt man früher oder später an den Punkt, an dem man sich mit der Güte und Vorgehensweise bei der Erstellung von Code auseinandersetzen muss. Ähnlich wie im Lebenslauf; Fremdsprachen: „Französisch (fließend)“, heißt es auf den Agenturwebsiten dann unter Software-Entwicklung: „Agil mit Scrum“ oder so ähnlich. Das Wie der Entwicklung und Arbeit von Programmierern steht heute sehr stark im Fokus. Oft fragt man sich aber was hinter „agil“ oder „kontinuierlich“ steckt und warum die Methode genutzt wird. Wir möchten das hier einmal für unsere Arbeitsweise aufzeigen.
Die klassischen Software Entwicklungsmethoden haben für uns ausgedient. Wir sind heute an dem Punkt, dass Softwareprojekte nicht mehr linear ablaufen und auch nicht mehr am Reißbrett, mit dem Kalender in der Hand, geplant werden können.
Unsere Entwicklerteams müssen heute in allen Projekten auf unvorhersehbare Situationen reagieren können. Dazu kommt: Egal ob bei TYPO3 CMS Website, Onlineshop oder individueller Softwareapplikation, die künstlichen Projekteenden, an denen alle Anforderungen umgesetzt sind, gibt es nicht mehr – die Anforderungen sind heute theoretisch unendlich. Man schreibt 1.000 Seiten Pflichtenheft und hat dennoch das Wesentliche vergessen. Man läuft einfach Gefahr Quatsch zu produzieren.
Die Auflösung des starren Wasserfallmodells ging bei uns in eine Kombination aus mehreren Methoden und Werkzeugen über. Im Folgenden werden diese kurz benannt und deren Zweck dargestellt.
Der Programmierer Vincent Driessen hat vor ca. 4 Jahren in einem Blogbeitrag beschrieben, wie er mit Git1 Software entwickelt und hat mit diesem Beitrag ziemlich Staub aufgewirbelt. Warum? Kurz gesagt vereinfacht, beschleunigt und sichert seine Methode die Entwicklung von Codeteilen (Branching) sowie die Zusammenführung zu einem zentralen Gesamtcode (Merging).
Dieser Ablauf der Softwarenutzung wird in der folgenden Grafik dargestellt:
CC BY-SA | Original Artikel von Vincent Driessen
Ohne hier jetzt zu erklären, wie die Codeteile im Detail durch diesen Ablauf geschleust werden, sei gesagt, dass uns Git und das Vorgehen erlauben, auf kurzfristige Anforderungen zu reagieren. Wir können damit umgehen, dass Kunden über Nacht Anforderungen einkippen, ein Google-Update zügiger Maßnahmen bedarf und kritische Fehler schnellstens abgestellt werden. Wir schaffen es dazu noch, entspannt nach vorn zu arbeiten, so dass unsere Kunden und wir unsere Komfortzone nicht verlassen.
Stellen Sie sich eine Situation vor, in der eine dringliche Änderung am Code notwendig ist (Hotfix). Dann befähigt uns Git diese Anforderung sicher und schnell mit den restlichen Anforderungen abzustimmen, umzusetzen, zu testen und in das Livesystem zu übertragen.
Nach der Einführung von Git-Flow haben wir gemerkt, dass diese Vorgehensweise nicht immer funktioniert. Unser Problem: Bei Wartezeiten oder weil unvollständige Anforderungen vorliegen, kann ein geplanter Release nicht stattfinden. Ein Task kann einfach nicht abgeschlossen werden. Das ist eine Schwäche von Driessens Model. Abhilfe verschaffen wir uns durch eine Integrationsebene. Neue Features können auf dieser Ebene getestet, gefixt und vom Kunden eingesehen werden, bevor sie in den Develop-Branch übernommen werden. Alles, was sich in diesem Strang befindet, wird zwangsläufig mit dem nächsten Release veröffentlicht. Dahingehend haben wir den Ablauf an unsere Erfordernisse angepasst. Der HDNET-Workflow wurde geboren:
CC BY-SA | Original Artikel von Vincent Driessen
Bamboo2 ist eine Software, die am Ende des HDNET-Workflows zum Einsatz kommt. Bamboo testet, überwacht, macht Reportings und (der fast wichtigste Punkt) verteilt den neuen Code auf die passenden Server. Ein besonderes Merkmal der Software ist, dass bestimmte Skripte ablaufen können. So minimieren wir manuelle Aufgaben. Beispiel: An einem Magentoshop wurde ein Task über Git umgesetzt und in das Livesystem gespielt. Vor der Veröffentlichung muss im Magento Backend jedoch noch eine Kategorie angelegt werden. Bamboo erledigt dieses Anlegen, bevor der Code veröffentlicht wird. Kein händischer Eingriff notwendig – kein nicht funktionierender Code auf der Website.
Jira3 bildet bei HDNET das Rückrat aller Projekte. Die Software ein Ticketsystem zu nennen ist untertrieben. Hier laufen die Anforderungen zusammen, werden priorisiert und verteilt – die Verteilung erfolgt wahlweise nach Kanban oder Scrum. (Wir folgen hier entweder der Methode des Kunden oder bieten unsere an.) Kunden kommunizieren über Jira mit unseren Projektleitern. Ebenfalls können sie den Status überwachen und ihr Projekt planen. Alles was wir über das Projekt wissen, weiß so auch unser Kunde, da er Zugriff auf alle Informationen hat. Bamboo ist mit Jira verbunden und generiert direkt Aufgaben in Projekten.
agil – (lat. agilis: flink; beweglich) Die hier aufgezählten Werkzeuge und Methoden befähigen uns, angemessen zu agieren – die gesamte Palette macht uns beweglich. Agil ist aus unserer Sicht nicht zu sagen „Wir machen Projekte mit Scrum, weil wir so keine Lastenheft Vorlage für Onlineshops schreiben müssen“. Agil bedeutet für uns: Unsere Arbeit und Werkzeuge den Anforderungen unserer Kunden anzupassen. Diese Umstellung ist nie abgeschlossen und geht weit über die Prozessebene hinaus.
Agile Entwicklung ist für uns der einzige sinnvolle Weg, um komplexe Anwendungen fristgerecht und in Budget zu realisieren. Auf dem Weg dahin haben wir Lehrgeld bezahlt und leben diese Vorgehensweise nun wirklich. Für manch anderen sind „Agil“, „Scrum“ und „Kanban“ vielleicht ein paar nette Buzzwords für die Unternehmenspräsentation. Wir leben agil auch in anderen Geschäftsbereichen. Es eignet sich praktisch überall, wo Sie heute nicht wissen was die Zukunft bringt. Dazu mehr in einem folgenden Post. Horido!
(1) Tool zur Versionskontrolle: www.git-scm.com
(2) Bamboo
(3) Jira
