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.