Review, Abnahme, oder entwickeln im Pair?

Wir schreiben Unit-Tests, damit wir Vertrauen in den Produktiv-Code haben, dass er das Richtige macht. Doch wer sagt, dass der Test das Richtige fordert? Bewährt hat sich TDD im Pair mit dem Fachexperten - doch versteht der nicht immer, was der Programmierer schreibt. Wie werden programmier-fremde Fachexperten in die Entwicklung integriert?

Reviews und Abnahmen

messgeraetIn der Softwareentwicklung hat sich folgendes Vorgehen durchgesetzt: Entwickler schreiben Software; im Anschluss prüfen Fachexperten und Qualitätssicherer auf fachliche Korrektheit. Agile Engineers bezeichnen dieses Vorgehen als wasserfall – etabliert als Adjektiv hier bewusst klein geschrieben.

Doch immer wieder stelle ich fest, dass auch Sprints im Agilen Umfeld wasserfall sind – nur eben viel kürzere. Die Probleme bleiben aber die selben: Staus, Stapel, verzögerte Feedback-Schleifen, Engpässe, Flaschenhälse, Wartezeiten und in letzter Konsequenz, dass Sprints nicht fertig werden.

Eingangskontrolle

Abstrakt betrachtet lässt sich der Mini-Wasserfall wie folgt erklären: Eine Produktionseinheit erzeugt Output – dieser wird in der nachfolgenden Einheit einer Eingangskontrolle unterzogen. Bestanden, beginnt die Einheit mit der Weiterverarbeitung. Nicht bestanden, läuft das Werkstück wieder zur vorherigen Einheit zurück.

Damit ist der Produktionsfluss unterbrochen (man stelle sich ein Förderband vor). In der realen Welt würden Lagerplätze und parallele Teilförderbänder notwendig werden. Es entstehen Lagerkosten und Produktionseinbußen – und damit hohe Kosten.

Was in der realen Welt mit physischen Gütern plausibel erscheint, wird in der IT leider durch ein virtuelles Ticket im Issue-Tracker verschleiert – was nicht heißt, dass es keine hohen Kosten verursacht.

Ausgangskontrolle

ampelJede Produktionseinheit muss also in die Lage versetzt werden, das Werkstück so zu produzieren, das es von der nachgeschalteten Einheit nicht mehr kontrolliert werden muss. Übertragen kann das als Ausgangskontrolle gesehen werden.

Damit ist nicht gemeint, die Kontrollprozedur vom Beginn der nachgeschalteten Einheit an des Ende der vorherigen Einheit zu holen. Auch ist mit Kontrolle keine Tätigkeit der Feststellung gemeint. Nein – es geht darum, dass jede Einheit bereits während der Produktion in der erforderlichen Qualität produziert, die von den folgenden Einheiten (und letztlich dem Kunden) vorausgesetzt wird.

So kann sich jede Produktionseinheit auf die reine Wertsteigerung konzentrieren, ohne davor eine Feststellung oder Überprüfung auf Vorhandensein von Wert durchzuführen.

TDD im Pair mit dem Fachexperten

Überragen auf die Softwareentwicklung lässt sich das auf eine ganz schlanke Weise realisieren: Der Fachexperte schaut sich ein Stück Software nicht erst an, wenn es fertig ist. Er entwickelt bereits selbst mit – zusammen mit einem Softwareentwickler und befähigt ihn in erster Näherung, das Richtige zu entwickeln.

Chancen statt Hindernisse

pairingDie üblicherweise darauf folgende Kritik an diesem Vorschlag scheint so plausibel, dass sich kaum einer traut, sie zu hinterfragen:

  • der Fachexperte kann nicht programmieren
  • der Fachexperte kann dem Entwickler nicht die ganze Zeit zugucken
  • Fachexperte und Entwickler verstehen sich nicht

Das klingt zunächst einleuchtend. Es heißt aber nicht, dass es niemals funktionieren kann. Die hier geäußerte Kritik bezieht sich auf den Status-Quo. Wesentliche Faktoren werden von der Kritik aber vergessen:

  • Zeit: der Fachexperte wird im Laufe der Zeit programmieren können – learning by doing.
  • Maßstab: der Fachexperte wird einfachen Code für einfache Problemstellungen schreiben können – das ist völlig ausreichend.
  • Ergebnis: der Fachexperte soll automatisierte Tests schreiben und lesen können, keinen Produktiv-Code in der Qualität eines Senior-Softwaredevelopers. Denn Tests bilden die Brücke zwischen Fachwissen und Code.

Hinter der Idee verbirgt sich also keine vollumfängliche Ausbildung oder Studiengang. Die Idee ist, Fachexperte und Entwickler schreiben zusammen die Tests – am besten nach dem TDD Leitbild, bevor der eigentliche Produktiv-Code geschrieben wird.

People over Tools

Zugegeben, diese Idee ist nicht neu und sie wird in vielen Organisationen gelebt. Die notwendige Vorarbeit, Wissen und praktische Anwendungen dazu liefern Dan North mit Behavior-Driven-Development (BDD) und Gojko Adzic mit Specification by Example (SbE). Ich sehe es also nicht als notwendig an, ein weiteres Konzept und Leitbild zu erfinden. BDD und SbE haben mich persönlich geprägt und sind in meinem alltäglichen Wirken verankert.

Als notwendig sehe ich um so mehr die konkrete Umsetzung in Team und Praxis. Konkret beobachte ich, dass das Handling und die Toolchain um die ausführbare Spezifikation, bzw. der Living Documentation mehr im Fokus stehen, als das gemeinsame Erarbeiten, Sprechen, Diskutieren und Erschaffen einer solchen Spezifikation. Sind Entwickler nur noch damit beschäftigt, die Toolchain zu pflegen und die notwendige DSL anzupassen – und das während der Fachbereich und Product-Owner spezifizieren – erwacht man schnell im System des Selbsterhalts, das viel Geschäftigkeit, aber wenig Wert produziert.

Die Einführung eines entsprechend schwergewichtigen Apparats ist eine Revolution, die nicht alle darin beteiligten Menschen verschiedener Bereiche und Expertisen einfach so mitmachen (wollen).

Ich empfehle eine evolutionäre Annäherung an die ausführbare Spezifikation. Der Einstieg kann erheblich erleichtert und Erfolge schneller erzielt werden, konzentriert man sich zu Beginn nicht auf Prozesse und Tools, sondern auf die wesentlichen Ressourcen, die bei Fachexperten, QA, Testern und Entwicklern vorhanden sind: Wissen und Handwerk.

Vorhandenes Wissen und Handwerk nutzen

Für das konkrete Vorhaben, Fachexperte und Entwickler vor eine IDE zu setzen sehe ich den Einsatz von Wissen und Handwerk wie folgt: Der Fachexperte hat das Wissen über die Domäne und – im konkreten Fall eines Qualitätssicherers – wie er Software strapazieren muss um ihr Fehler zu entlocken. Der Entwickler bringt das Handwerk mit, dies in automatisierte Tests zu gießen.

Im Sinne der Verständlichkeit, Lesbarkeit, Nachvollziehbar und Überprüfbarkeit von Testcode ist es ratsam, möglichst nahe an einer natürlichen Sprache zu sein. Eine objektorientierte Sprache wie Java ist aber nicht dafür konzipiert, menschliche Sprache zu verarbeiten. Für den nächsten Artikel möchte ich deshalb zeigen, wie bereits die entwicklungsnahen Unit-Tests mit einem Fachexperten geschrieben werden können, ohne ihn abzuhängen.

Quellenangaben
MaxyM/shutterstock.com
Yotsatorn Laonalonglit/shutterstock.com
Don Pablo/shutterstock.com
Vasilev Evgenii/shutterstock.com