DevOps – Definition of Done

Eine der zentralen Fragen, die jedes Team für sich alleine und dann mit allen weiteren, beteiligten Personengruppen klären muss:

Wann ist eine Software tatsächlich bereit zur Übergabe oder gar fertig?

Es gibt viele verschiedene Ansätze, wann eine Software als fertig gilt. Die Meinungen hierzu sind eher subjektiv und gehen hier sehr weit auseinander.
Das eine Extrem lässt die Software beim Kunden reifen – das ist vermeintlich auch als Bananensoftware bekannt. Beim anderen Extrem bekommt der Kunde überhaupt keinen Einblick in den derzeitigen Fortschritt des Projektes/Produktes.
Auch hier liegt die Wahrheit und meine klare Empfehlung in der Mitte beider Extreme:

  • Akzeptanzkriterien
    • alle MUSS Anforderungen sind zu erfüllen
    • KANN Punkte sollten soweit wie möglich erfüllt werden (80/20)
  • Funktionale Anforderungen müssen vollständig umgesetzt sein
  • Nicht-Funktionale Anforderungen sind zu beachten
  • Testabdeckung sollte so hoch wie möglich sein
    (mind. 60% mit Ziel 80% + x)
  • Codebasis MUSS zwingend sauber gehalten werden
    (Best Practices & Design Patterns)
  • Bestehende Funktionen dürfen NICHT beeinträchtigt werden
  • Neue Funktionen müssen sich in das Gesamtbild einfügen
    (Look & Feel, erwartetes Verhalten)
  • Neue Funktionen dürfen die Stabilität auf keinen Fall verringern
  • Die Bedienung der Software muss möglichst selbst erklärend sein
  • Eine Hilfe/Doku sollte bei Bedarf jederzeit erstellt werden können
  • Je nach Anwenderkreis ist eine technische sowie fachliche Dokumentation zwingend notwendig

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.

XP, Pair Programming – Additional Benefits vs. costs

Voraussetzungen:
Das Team muss harmonieren. Nur wenn die zwischenmenschliche Beziehung passt, sind die Grundvoraussetzungen erfüllt!

Zeit für die Einarbeitung – kalkulierbar?
Als allgemeingültig werden rund 3 bis 6 Monate an Einarbeitung in ein neues Projekt angesehen. Die tatsächliche Zahl ist natürlich abhängig von der Komplexität, den Vorkenntnissen und der Rolle, die es zu übernehmen gilt.
Es gilt: Je höher die Komplexität, desto höher die erforderliche Zeit. Je größer die Vorkenntnisse sind, desto schneller beginnt der produktive Einsatz.

Meine persönliche Empfehlung:
Gebt dem Pair rund zwei Wochen Zeit, sich aufeinander einzustellen.
Eine Vorhersage, wie lange es pro Team tatsächlich dauert, lässt sich nicht verallgemeinern. Bei dem einen Paar klappt das ab dem dritten Tag, bei einem Zweiten erst nach 10. Gebt den Teams genug Freiraum und die Möglichkeit zur Klärung der optimalen Arbeitsweise/- umgebung – vor allem bei einer Junior – Senior Konstellation. Auch ein Senior lernt nie aus.

Kleines Beispiel:
Lässt man alle anderen Faktoren weg und betrachtet ausschließlich die benötigte Zeit (netto) um eine zweite Person einzuarbeiten, kommt man – meiner persönlichen Einschätzung nach – mit rund 1/3 der durchschnittlichen Zeit für eine Einarbeitung aus. Das bedeutet für ein Unternehmen, dass beide Personen schneller produktiv eingesetzt werden können. Der Coach kann seinen eigentlichen Tätigkeiten nachkommen und die neue Person im Team wird von Anfang an stärker eingebunden, z.B. in das Tagesgeschäft. 

Weitere Faktoren:
Urlaub, Termine, Unterstützung von Kollegen verändern die Zeit (netto) natürlich, was zwangsläufig zu einem längeren Zeitraum führt.

Gefahren und Missverständnisse
Es muss immer beachtet werden, dass Pair Programming kein Allheilmittel darstellt. Auch diese Methode muss von Fall zu Fall geprüft werden, ob es dem Projekt oder dem Team den gewünschten Nutzen bringt.

Fazit:
Gehen wir aktuell von rund 2/3 der Zeit aus, die im klassischen Sinne benötigt wird, dann lassen sich immerhin bis zu 33% Arbeitszeit und somit Kosten für die Einarbeitung einsparen. Was das für ein Unternehmen in Zahlen bedeutet, lässt sich aus dieser Annahme leicht ableiten.

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 – Necessary business conditions (part two)

Dieser Artikel ergänzt die weiteren erforderlichen Rahmenbedingungen. Im ersten Teil ging es um ein gemeinsames Verständnis und den Nutzen eines aktiven Vorlebens. Dieser Artikel hingegen befasst sich mit den größten Herausforderungen und Hürden, die – meiner Meinung nach – zu vermeidbaren Missverständnissen führen können. Und diese kosten nicht nur Zeit, sondern stellen auch ein Risiko dar, das nicht unterschätzt werden darf.

Missverständnisse jeglicher Art sollten natürlich vermieden werden. Das klappt aber nur, wenn der Kunde und der Auftragnehmer das gleiche Verständnis für den Umfang und Inhalt der Aufgabe haben. Solche Hürden entstehen aber meistens dann, wenn eine Aufgabe oder Anforderung nicht präzise genug formuliert ist und somit Interpretationsspielraum zulässt. Damit sind den täglichen Herausforderungen Tür und Tor geöffnet, die dann meistens mehrfach vorkommen.

K.O. Kriterien, wie lassen sich solche Probleme vermeiden?
Ganz klare Antwort: offene Kommunikation im Team.
Dazu gehören akute Probleme, Herausforderungen und Hindernisse, die beseitigt werden müssen. Jedes Teammitglied sollte idealerweise einen guten Überblick über den aktuellen Stand haben, damit bei Planänderungen durch Urlaub oder Krankheit, zeitnah agiert werden kann. Es muss nicht jeder alles wissen, aber durch regelmäßige Absprachen und Informationsaustausch lassen sich zum Beispiel Aufwände bei unvorhergesehenen Vertretungen reduzieren.

Wie erreicht man im Team diese Offenheit?
Hier bieten sich regelmäßige Termine an, um die größten Herausforderungen transparent zu machen. Durch kleinere Workshops, sog. „Lessions learnt“, lassen sich Lösungswege viel schneller erarbeiten. Ein kurzes Branstorming, eine Zeichnung oder Skizzen auf dem Whiteboard eignen sich ebenfalls bestens, um ein breiteres Verständnis und Klarheit zu schaffen. Das WIR als Team muss hier an erster Stelle stehen!
Idealerweise lassen sich aus den Ergebnissen wiederum konkrete Maßnahmen ableiten, die ggf. weiter verfeinert, eingeplant und umgesetzt werden können. Nicht alles lässt sich sofort umsetzen, aber wenn eine Aufgabe erstmal benannt ist, im Team erklärt wurde, kann diese auch besser beurteilt, eingeschätzt und geplant werden.

Deswegen an dieser Stelle meine klare Empfehlung:
Sprecht die Punkte offen an, die Euch am meisten stören – sachlich, objektiv und mit Fakten hinterlegt.

Eine Buchempfehlung (neue Perspektiven und Sichtweisen)

XP, Pair Programming – Necessary business conditions (part one)

Als nächstes widme ich mich den erforderlichen Rahmenbedingungen. Die hier aufgezeigten Punkte sind Schlussfolgerungen aus meinen persönlichen Erfahrungen und stellen natürlich kein Allheilmittel dar. Trotzdem bleibt jeder der folgenden Punkte – meiner Meinung nach – zwingend erforderlich und sollte nicht ohne wichtigen Grund über Bord geworfen werden. Was als wichtiger Grund zu verstehen ist, muss jedes Team innerhalb eines Unternehmen projektabhängig für sich selbst entscheiden.
„It depends.“

Gemeinsames Verständnis:
Zu den zentralsten Rahmenbedingungen zähle ich in einem Projekt das gemeinsame Verständnis. Nur wenn jedes Teammitglied inkl. Projektleitung, Management und Kunde von ein und demselben Aspekt, Punk bzw. Aufgabe sprechen, kann das gesamte Team als Einheit gemeinsam an einem Strang ziehen. Ansonsten entstehen ungewollte Wechselwirkungen, die sehr schnell zu Missverständnissen führen können. Diese gilt es dann zeitnah aus dem Weg zu räumen, um unnötige Termine zur Klärung zu vermeiden. Aber auch hier gilt: Es gibt keine falschen Fragen!

Bekannte Herausforderungen erkennen und meistern:
Darunter verstehe ich die Erzählungen. Projektbeschreibungen oder Anekdoten, die einem auf Konferenzen oder Fortbildungen wie User Group Treffen zugetragen werden. Zusätzlich helfen hier die selbst erlebten Erfahrungswerte, um aus ihnen zu lernen. Projektinhalte lassen sich nicht 1:1 vergleichen, aber die Prozesse zur Durchführung sind doch meistens sehr ähnlich aufgebaut.

Vergleich zwischen Theorie und Praxis – Zwei völlig unterschiedliche Welten?
Das Lehrbuch verspricht uns die schöne grüne Wiese.  Dort finden wir viele gute Empfehlungen und Vorschläge rund um den Einsatz von Agilen Methoden – sei es SCRUM, XP, Kanban o.ä.  Die Praxis schaut hier meistens etwas anderes aus. Die täglichen Herausforderungen bestehen darin, dass einem immer genau die Situationen über den Weg laufen, die nicht im Buche stehen. Wichtig ist aus meiner Sicht zu lernen, was beide Welten miteinander verbindet, um daraus einen Mehrwert für das aktuelle Projekt, sein Team und natürlich die Firma zu generieren.

Mein erstes Fazit: Und täglich grüßt das Murmeltier – oder wie war das gleich nochmal? Aber im Ernst – mit dem gemeinsamen Verständnis als Fundament lässt sich viel effizienter ein tragendes Gerüst zur Überwindung von Vorbehalten bauen. Aktives Vorleben und gemeinsames Erleben sind für mich von größter Bedeutung. Aha Effekte erzeugen, Lernen und lernen lassen nehmen einen ähnlich großen Stellenwert ein. Auch hier gilt der Klassiker – Übung macht den Meister – egal ob bei Naturwissenschaften oder Sprachen.

Literaturempfehlung:

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.