DevOps – geänderte Anforderungen führen zu neuen Bugs?!

In dem vorherigem Artikel ging es um ein immer wieder kehrendes Problem aus der Praxis – die Anforderung des Kunden hat sich geändert. Die Vorgehensweise zur Qualitätssicherung ist in diesem Artikel näher beschrieben.

Hier geht es um das Thema Automatisierung von alltäglichen, meist bekannten Prozessen:

  • geänderte Anforderung – neue Fehler?
  • Integration neuer Funktionen (Continous Integration)
  • automatische Builds mit anschließenden Tests

Fehler treten immer wieder auf, können aber durch folgende Schritte bereits frühzeitig festgestellt und behoben werden:

  1. Änderung am Code durchführen
    => geänderte Anforderung wird umgesetzt
  2. Alle Tests laufen lassen, um sicherzustellen, dass die bestehende Funktionalität weiterhin in Ordnung ist
    => Alles Tests sind weiterhin grün
  3. Sicherstellen, dass sich der geänderte Code auch weiterhin integrieren lässt und auch keine abhängigen Projekte betroffen sind
    => Es müssen alle Projekte, die die gemeinsame Codebasis verwenden, geprüft werden

Was ist bei der Integration neuer Funktionalität zu beachten? Auch hier gibt es immer wieder kehrende Schritte:

  1. Abholen der letzten stabilen Version der Software aus der Versionskontrolle
  2. Lokales kompilieren der neuen Codebasis
  3. Alle Tests lokal ausführen
  4. Alle auftretenden Fehler müssen behoben werden
  5. Sind alle Tests grün?
    => Die neue Codebasis kann eingecheckt werden

Durch den Check-In Vorgang lassen sich weitere Prozesse anstoßen, die weitestgehend automatisiert auf einem oder mehreren Build-Servern ablaufen können. Die meisten Build-Tools führen diese Workflow-Schritte bereits ohne größere Konfiguration aus.
Im folgenden ein Ausschnitt eines möglichen Build-Prozesses:

  1. Hole die letzte Version mit allen Projekten
  2. Kompiliere alle betroffenen Projekte
  3. Generiere eine eindeutige Build-Nummer
  4. Stelle das Kompilat auf einem (Test-) Server bereit
  5. Starte alle vorhandenen Tests
  6. Im Fehlerfall: Informiere den notwendigen Personenkreis, dass Fehler aufgetreten sind.
    => Prozess wird hier beendet
  7. Kein Fehler: Stelle das Ergebnis auf einer Staging-Umgebung bereit
  8. Konfiguriere alle weiteren Komponenten wie Datenbanken o.ä.
  9. Stelle die Software bereit, z.B. SQL-, Deploy-Skripte, etc.

Meine Empfehlung:

Aus eigener Erfahrung kann ich nur jedem Team – egal ob Entwicklung oder Betrieb – ans Herz legen, automatisierte Builds mit anschließenden Tests einzuführen. Jedes Teammitglieder sollte in der Lage sein, innerhalb weniger Stunden eine neue, stabile Softwareversion zu erzeugen. Dazu gehört aber nicht nur die Erstellung eines Setups oder der Skripte zur Bereitstellung der Software sondern auch die automatische Integration in die bestehende Software (Continous Integration). Bereits bei einer kleinen Änderung muss automatisch sichergestellt sein, dass der Rest der Software davon nicht beeinträchtigt wird. Eine ständige Integration von neuen Funktionen in eine Versionskontrolle gehört ebenso zu den Grundvoraussetzungen wie ein gesundes Maß an Automatisierung.

DevOps – ständig neue Anforderungen?!

In vielen Projekten kommt seit Jahren das Wasserfall-Modell zum Einsatz. Hier stehen mit Lasten- und Pflichtenheft alle Anforderungen zu einem Zeitpunkt X fest und es kann mit der Entwicklung begonnen werden. Der Ablauf ist in jeweils für sich abgegrenzte Phasen getrennt. Eine Phase muss abgeschlossen sein, bevor die nächste begonnen werden darf.

  1. Analyse
  2. Design / Konzeption
  3. Implementierung
  4. Testen (mit und ohne Kunde)

Der Kunde stellt fest, dass die Software soweit passt, aber das eine kleine Feature muss noch dringend umgesetzt werden.
„Ich will meine aktuellen Änderungen speichern können. Und die aktuellen Einstellungen sollen natürlich auch – Personen abhängig – geladen werden. Das hatten wir doch im Workshop XYZ so besprochen…“, wer kennt das nicht?

Das Team fällt aus allen Wolken!
Persistenz, personenspezifische Einstellungen – und das über alle Schichten hinweg. Der Abgabetermin ist nicht zu halten!
Ein möglicher Grund: Das Team war beim entscheidenden Workshop aus akutem Zeitmangel natürlich nicht dabei – zu viele offenen Punkte.

Ein weiteres Szenario:
Missverständnisse bei der Kommunikation der Anforderungen zwischen Kunde und dem Team bestehend aus Business-Analysten, Designern bzw. Entwicklern und dem Betriebsteam. Der Geschäftsprozess wurde völlig falsch verstanden…

Fakt ist, dass kurzfristige Änderungen der Anforderungen am bestehenden Prozess treten immer wieder auf.

Doch wie lässt sich sicherstellen, dass Änderungen keine Seiteneffekte und Fehler in anderen Bereichen verursachen?
Wie kann die bestehende Qualität mindestens auf demselben Niveau gehalten oder gar verbessert werden?

Mehr zu den Vorgehensweisen rund um die Qualitätssicherung und Testen habe ich in diesem Artikel beschrieben.

DevOps – Zwei Welten – ein gemeinsames Ziel

Zwei Welten – ein fließender Übergang

Das Entwicklungsteam sagt nach einer gewissen Zeit „fertig“, Version X.Y kann jetzt eingesetzt werden. In vielen Fällen wird dann diese neue Version der Software als Blackbox über den Zaun geworfen (Dev nach Ops). Es ist keine große Neuigkeit, dass beide Teams hier eng miteinander zusammenarbeiten (müssen/sollten), aber wie schaut es in der Praxis tatsächlich aus?

Nachfolgend ein paar essentielle Fragen, die beantwortet werden müssen:

  • Wann ist eine Software tatsächlich bereit zur Übergabe oder gar fertig?
  • Sind auch die nicht-funktionalen Anforderungen (NFA) eingehalten bzw. erreicht worden?
  • Gibt es eine Dokumentation, die die Änderung ausreichend beschreibt?
  • Gibt es eine formale Übergabe an den Betrieb?
  • Wie lassen sich solche alltägliche Herausforderungen meistern?
  • Auf was kann man frühzeitig achten, um Mauern zu überwinden und Brücken zu spannen?
  • Welche weiteren Hürden gilt es zu meistern?
  • Wer oder besser – welches Team trägt welche Verantwortung bei einer neuen Software Version?

Auf diese Fragen werde ich in den nachfolgenden Artikeln näher eingehen.

Agile Arbeitsmethoden – ein Zwischenfazit

In den letzten Artikeln habe ich die Vorteile von Agilen Methoden aus der Sicht- und Denkweise des Teams bzw. der einzelnen Teammitglieder beschrieben. Mindestens genauso wichtig ist hier aber auch die Sichtweise des Unternehmens. Die Entscheider, egal ob interne oder externe Kunden, haben meistens weder die Zeit noch den notwendigen technischen Hintergrund, um fachliche Fragen im Detail zu beurteilen.
Die Kollegen müssen sich auf die Aussagen der einzelnen Teams verlassen. Aber wie kommt ein Team oder Teammitglied zu einer validen, präzisen Aussage bei einem unbekannten Thema?
Klare Antwort: Sehr schwierig, aber nicht ganz unmöglich.

Es spielen hier sehr viele Faktoren eine Rolle, die mit einbezogen werden müssen.

  • Teamgröße
  • Know-how der einzelnen Teammitglieder
  • Eigener fachlicher wie technischer Hintergrund, objektive Schätzung?
  • Bekanntheitsgrad der gewünschten Technologie
  • Gemeinsames Unterfangen oder Last-man-Standing Projekt
  • Aktuelle Planung und Auslastung des Teams
  • Wer kümmert sich um die Qualitätssicherung?
  • Wie sehen die vor- bzw. nachgelagerten Prozesse aus?
  • Gibt es eine Vorgabe zur Testabdeckung?
  • Testabdeckung – wie hoch ist die Gefahr bei Änderungen Fehler zu verursachen?

Allein von den hier beispielhaft aufgeführten Punkten sind einige dabei, die ein nicht zu unterschätzendes Risiko darstellen.

Das Fazit:
Wie so oft – die Mischung macht den Unterschied aus. Aus Sicht des Unternehmens sollte ein heterogenes Team immer einer Gruppe von lauter Einzelkämpfer vorgezogen werden. Allein die Gruppendynamik, die wertvolle Ideen und Kreativität bringt, darf auf keinen Fall unterschätzt werden.
Schließlich besteht unsere tägliche Arbeit vor allem darin, neue Ideen zu entwickeln, zu forschen und Lösungen zu finden.

DevOps – was verbirgt sich hinter dem Begriff?

In den letzten Tagen und Wochen ist das Begriff „DevOps“ in aller Munde. Sogar auf der aktuellen Basta! Konferenz in Mainz ging Paul Stack in der Keynote auf diesen Begriff näher ein. Aber was bedeutet das für das tägliche Arbeiten? Nach welchen Kriterien wird man in welchen Bereich eingeordnet? Hier ist eine Begriffserklärung notwendig, um ein möglichst gutes Verständnis für die neue Rolle zu bekommen.

DevOps – eine kurze Erklärung

Es soll die Zusammenarbeit zwischen dem Entwicklungsteam (Dev steht für Development) und dem Betriebsteam (Ops steht für Operation) symbolisieren. Neben der Zusammenarbeit geht es auch um die Verantwortung, die beide Teams für Ihren Bereich tragen. Das schwierige dabei ist – wie so oft – der Übergang zwischen diesen Rollen zu finden und zu definieren. Viel zu oft entsteht eine Art Mauer, ein Gefälle oder sogar kaum zu überwindende Gräben. Hier stellt sich mir die Frage – wo beginnt und vor allem wo hört die jeweilige Verantwortung auf?

Dev – eine kurze Abgrenzungen

Zum Dev-Team gehört der komplette Entwicklungszyklus, d.h. die Berater, die Designer, Entwickler und Tester. In vielen Fällen funktioniert die Kommunikation hier schon sehr gut – man kennt sich, zieht im Team an einem Strang und schiebt die Aufgabe von Rolle zu Rolle weiter. Am Schluss entsteht ein Stück Software, dass aus Sicht des Dev-Teams fertig ist.

Ops – eine kurze Abgrenzungen

Zum Ops-Team gehören die Administratoren rund um die Infrastruktur, Applikation, die Web- und Datenbankserver, die Kollegen aus der Hotline und dem Support im 2nd und 3rd Level – kurz: das komplette Betriebsteam.
Sie sind dafür zuständig, dass die entwickelte Applikation stabil läuft und der Kunde zufrieden gestellt ist – und vor allem auch bleibt.
Neue Problemfälle werden vom Endkunden direkt an dieses Team gemeldet. Die Erfassung und Reproduzierbarkeit von auftretenden Fehlern ist das A und O der Tätigkeit. Ohne Betrieb gibt es keine Rückmeldung an das Entwicklungsteam. Ohne Rückmeldung gehen sehr oft wichtige Informationen verloren, die eine Verbesserung der Software ermöglichen.

XP, Pair Programming – unknown things, create something new due pairing!

Was man unter Pair Programming versteht habe ich hier beschrieben. Zuerst soll es um den Punkt Unbekannte Gewässer, etwas Neues wagen gehen. Dazu zwei wesentliche Fragen:

  1. Wie steigert man die Bereitschaft im Team für etwas Neues?
    Darauf gibt es eine einfache Antwort, die aber durchaus etwas Überwindung kostet: Vorleben, lasst Euer Umfeld die Begeisterung an der Sache spüren!

    Holt Eure Gesprächspartner ab, sprecht offen über Euer Vorhaben, eure Idee, eure Ziele – egal ob mit Kollegen, Freunden oder Familie! Nur wenn ihr von etwas überzeugt seid, schafft ihr es auch, andere in euren Bann zu ziehen. Ist der Grundgedanke einmal vermittelt, habt ihr bereits die Hälfte der Strecke geschafft! Der Rest ist nur noch eine Frage der Organisation und abhängig von der jeweiligen Situation.

  2. Lässt sich etwas Neues mit einem Fingerschnippen umsetzen?
    Auch hierfür gibt es eine einfache Antwort: Nein – Neue Ideen brauchen Zeit, um zu reifen.

    Man verlässt ungern seine gewohnte Umgebung. Der Weg zur Arbeit wird meistens der gleiche sein. Eine Veränderung an bekannten, geschätzten oder liebgewonnenen Dingen vermeidet man soweit wie einem möglich. Somit ist bei jeder Änderung – egal ob es nur eine Person oder eine ganze Gruppe betrifft – sehr viel Fingerspitzengefühl gefragt.
    Nicht jede Entscheidung ist sofort für alle transparent und/oder nachvollziehbar. Aber unabhängig davon, bleibt das Wichtigste, alle Personen frühzeitig abzuholen und in den Entscheidungsprozess einzubeziehen. Damit entsteht viel schneller ein breites, gemeinsames Verständnis bei allen Beteiligten.
    Nebenbei kann durch die Gruppendynamik berechtigte Kritik bewertet werden. Das trägt wiederum zur Teambildung bei – alle ziehen an einem Strang. Aus meiner Sicht ist das Glas immer halb voll.
    Bei solchen kontroversen Gesprächsrunden kann eine unabhängige Person als Moderator durch die objektive und sachliche Sichtweise unterstützen. Rund um das Thema Moderation bzw. Sicht- und Denkweisen gibt es sehr gute Fachliteratur.
    Meine Empfehlung:

Coding Dojo – Let`s talk about Pairing

Pair Programming – aber was versteht man darunter?
Pair Programming ist nichts anderes als ein dauerhaftes 4-Augen Prinzip – und das kennt jeder.

Bereits seit vielen Jahren werden die meisten sicherheitsrelevanten Aufgaben von mindestens zwei unterschiedliche Personen durchgeführt. Ein sehr aktuelles Beispiel ist das Team rund um ein Cockpit. Als effektive Maßnahme wird seit kurzem heftig darüber diskutiert aus den 4-Augen ein 6-Augen Prinzip zu machen – zumindest solange ein Augenpaar abgelenkt ist.

Aber zurück zur (Software-) Entwicklung und den agilen Prozessen. Im Folgenden ein paar grundlegende Punkte:

  1. Unbekannte Gewässer, etwas Neues wagen!
    • Wie steigert man die Bereitschaft im Team und/oder Unternehmen etwas „Neues“ zu testen oder gar einzuführen?
    • Lässt sich eine neue Methodik / Prozess / Arbeitsweise per Fingerschnippen einführen?
  2. Erforderliche Rahmenbedingungen
    • Ist ein gemeinsames Verständnis auf allen Ebenen vorhanden?
    • Welche bekannten Herausforderungen sind zu meistern?
    • Wie schaut der Vergleich zwischen Lehrbuch und Praxis aus?
    • Gibt es K.O. Kriterien?
    • Gefährliche Missverständnisse bzw. Schlussfolgerungen vermeiden
  3. Tägliche Hürden nehmen – in kleinen Schritte denken!
    • Welche Voraussetzungen können weiter verbessert werden?
    • Welche Vorbereitungen sind zu treffen?
    • Welche Fachliteratur eignet sich für den Einstieg?
    • Was ist bei der Zusammensetzung der Teams zu beachten?
  4. Die Unternehmenssicht (Wirtschaftlichkeit)
    • Wie lässt sich mit wenig Aufwand prüfen und belegen, welcher tatsächliche Mehrwert erzeugt wird?
    • Lohnt es sich tatsächlich, zwei Personen dauerhaft gemeinsam (im Paar) arbeiten zu lassen?
    • Welche Kosten entstehen aus Unternehmenssicht?
    • Welcher Nutzen entsteht – und wie lässt sich dieser messen?
    • Belegbare Zahlen im Vergleich – Zahlen, Daten, Fakten (ZDF)
    • Welche wissenschaftliche Arbeiten gibt es?

Fragen über Fragen – nur wo bekomme ich die ganzen Antworten her? Es gibt viel Literatur rund um das Thema Agile Methoden. Durch die Entwicklung der letzten Jahre und die Tendenz alles immer schneller fertigstellen zu müssen, haben sich einige wenige Methoden als nachhaltig erwiesen – dazu gehört für mich das Pair Programming.

Es dauert einfach seine Zeit, um sich mit einem Thema näher zu befassen. Denn neben reichlicher Literatur, vielen Tools und einigen „Masterplänen a la Lehrbuch“ auf der grünen Wiese, sind auch noch die jeweiligen spezifischen Projektbedingungen zu beachten. Meistens ist der erste Schritt der Schwerste.
Mein Ziel ist es, die selbst erlebten Erfahrungen kurz zu umreißen, an Euch weiterzugeben und damit Interessierte zu erreichen. Dies ist der Einstieg in eine Artikelserie, durch die ich sicherlich bei dem einen oder anderen etwas Licht ins Dunkle bringen kann.

Coding Dojo – Insights

Worauf es bei einem Dojo bzw. Code Kata ankommt, habe ich hier beschrieben.

Der Spaßfaktor soll absolut im Vodergrund stehen. Das ist einer der wichtigsten Lerneffekte der letzten Jahre für mich, frei nach Steve Jobs „You only do great work, if you love what you do“.

Hier geht es nicht darum, wie im Alltag unter Zeitdruck die übergebene Aufgabe schnellstmöglich abzuschließen. Sondern es geht um das Lernen, dabei Spaß zu haben, sich gemeinsam mit einem Thema zu beschäftigen und sein bisheriges Wissen mit anderen zu teilen. Daraus entsteht meistens eine Gruppendynamik, die einen voll in ihren Bann zieht. Ein Dojo soll als eine Übung für was neues sein, z.B. JavaScript.

Auch wenn Kollegen anfangs skeptisch sind, lasst euch nicht einschüchtern. Nehmt Euch die Zeit, klärt sie über die Theorie auf und haltet dann kleine Workshops ab – schnappt Euch eine leichte Übung wie z.B. FizzBuzz. Macht daraus einen kleinen Wettbewerb – klassische Methode vs. Pairing mit TDD.

Das Ergebnis wird nicht nur für Euch selbst verblüffend sein, sondern auch bei den anderen ein „Aha“ auslösen. Mit den ersten Multiplikatoren fängt dann das langsame Umdenken an. Geht auf die Leute zu, holt Euch sachliche Kritik ab. Dadurch verbessert ihr Euer eigenes Know-how rund um Workshops, Coaching und Co.

Fangt noch heute an – es kostet nicht viel Zeit und bringt Euch aber in kleinen Schritten nach vorne.

Viel Spaß beim Üben

Coding Dojo – Let`s do it

Was ein Dojo ist und was bei den ersten Schritten zu beachten ist, habe ich bereits hier beschrieben.

Wenn sich die Gruppe auf die grundlegenden Sachen geeinigt hat, kann es auch schon losgehen. Der erste Schritt ist hier meistens der Schwerste – wie fängt man denn am besten an?
Ein kleiner Tipp: Lest Euch die Aufgabenstellung erneut durch und zerschneidet sie in kleinste Teile mit dem Ziel pro Aufgabe mehrere Tests zu erstellen.

Nehmen wir beispielsweise das Kata FizzBuzz – hier geht es darum eine Zahlenreihe von 1 bis 100 auszugeben.
Bei jeder Zahl, die durch drei teilbar ist, soll Fizz ausgegeben werden. Bei jeder Zahl, die durch fünf teilbar ist, soll Buzz ausgegeben werden. Und wenn die Zahl durch drei und fünf teilbar ist, soll FizzBuzz ausgegeben werden.

Wie sieht dann der erste Test aus? Ganz klar. Nimm die erste Ziffer, die Du prüfen willst, und stelle fest, ob eine der Regeln angewendet werden kann. Danach nimm die zweite Ziffer, usw. Sobald sich die Kombination aus mehreren Regeln ergibt, wird es interessant, da hier auch die Reihenfolge relevant sein kann. Ganz wichtig bei den ersten Schritten – geht streng nach dem Test Driven Prinzip mit Red – Green – Blue vor. Ob ihr lieber Design oder Development nutzt, ist Euch überlassen
Red, d.h. Euer Test muss fehlschlagen.
Green, d.h. Euer Test hat funktioniert.
Blue, d.h. Refactoring – Zeit, um den geschriebenen Code zu verbessern.

Danach geht es mit dem nächsten Test (Red) weiter. Nehmt Euch die Zeit und probiert es aus.

Coding Dojo – Was ist das?

Der Begriff Dojo bezeichnet einen Trainingsraum für verschiedene japanische Kampfkünste. Aber was hat das alles mit Software oder Entwicklung zu tun?

Ein Coding Dojo ist in der IT Branche eine Art Übung an der viele Entwickler, Designer oder einfach interessierte Personen teilnehmen. Hierbei gibt es ein paar wichtige Regeln, die einem das Leben viel einfacher machen:

  1. Es gibt keine bessere oder schlechtere Lösung – es wird in Teams gearbeitet.
    =>  Werten ja, aber nicht Bewerten!
  2. Es wird nach der Methodik „Test First“ bzw. TDD vorgegangen.
    =>  Hier soll das Prinzip des Pair Programming geübt und vertieft werden (Pilot/Co-Pilot, 4-Augen Prinzip)
  3. Es geht hier vor allem um den Spaß am Lernen – egal welche Plattform, Sprache oder Aufgabe
    =>  Der Spaß am Programmieren und am gemeinsamen Erarbeiten einer Lösung steht hier an erster Stelle

Es werden kleine Gruppen gebildet und dann geht es auch schon los – die erste kleine Programmieraufgabe, ein sog. Kata, zu lösen.

Eine gute Übersicht erhält man auf den folgenden Seiten