Eine Themenübersicht – Coding Dojo bis Pair Programming

Mit den hier gelisteten Artikeln möchte ich Euch einen Einstieg in die verschiedenen Methoden der Agilen (Software-) Entwicklung geben:

  1. Coding Dojo
  2. Agil, Pairing (XP), aber was steckt dahinter?
  3. Standard Prozesse

    Glossar:

    • XP: Extreme Programming
    • Pairing: Pair Programming, ist ein Teil von XP
    • Dojo, Kata: Übung
    • TDD: Ein Methodik, die den Test-First Ansatz verfolgt
    • DevOps: Development trifft auf Operations

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 – Testen, aber richtig! Klassisch vs. Unit Tests, TDD

Bei der Qualitätssicherung – und die besteht nun einmal hauptsächlich aus Testen – unterscheide ich zwischen dem SOLL und IST Zustand der klassischen Vorgehensweise und Unit Tests durch den Test-First Ansatz (Test-Driven-Development, TDD).

Die Vorgehensweise der Qualitätssicherung im klassischen Sinn (SOLL):

  1. Entwickler schreibt eine Methode, Klasse oder eine Applikation
  2. Wenn genug Zeit vorhanden, meistens nur optional
    • Manuelle Tests starten
    • Unit Tests erstellen
    • Integration Tests erstellen
  3. Wenn genug Zeit vorhanden, meistens nur optional
    • Es werden alle manuellen Tests von Anfang an neu gestartet
    • Es werden alle Unit Tests neu gestartet
    • Es werden alle Integrationstests neu gestartet
  4. Es werden gemeldete Fehler behoben

Die Vorgehensweise der Qualitätssicherung im klassischen Sinn (IST):

  1. Entwicklungsteam schreibt eine Methode, Klasse oder eine Applikation
  2. Es werden Fehler behoben (und ggf. ungewollt weitere erzeugt)
  3. Fehleranalyse dauert sehr lange, Kosten steigen pro Fehlerfall

Die Vorgehensweise der Qualitätssicherung bei Test Driven Development (Test-First Ansatz, ausgeführt zur Entwicklungszeit)

  1. Schreibe einen Test
  2. Starte alle Tests
  3. Stelle sicher, dass der/die Tests grün werden
    => der produktive Code muss geschrieben werden
  4. Starte alle Tests
    1. Der neue Test schlägt fehl (Red)?
      => Fehler beheben und weiter mit 4.
    2. Der neue Test ist okay (Green)
      => Produktiven Code aufräumen (Blue)
    3. Alle Tests sind okay und kein Bedarf den Code aufzuräumen
      =>  Schreibe einen neuen Test (weiter mit 1.)

Dadurch entsteht ein Zyklus, der mit einem fehlschlagenden Test beginnt (RED) und behoben wird (GREEN). Ggf. kann der Code vereinfacht und aufgeräumt werden (BLUE).
Es entwickelt sich dadurch nach und nach der produktive, aufgeräumte Quellcode – in kleinsten Schritten, überschaubar, lesbar und voll automatisiert.

Mein Fazit:
Der Idee hinter TDD steht für mehr Qualität, Stabilität, Wartbarkeit – und das zu jederzeit automatisiert per Knopfdruck

Weitere Empfehlungen zum Thema Unit Tests und Test Driven Development

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

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.

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)