15.08.2010
/ Von Christoph Mathis

Es ist immer problematisch, einen so komplizierten Sachverhalt auf ein paar Schlagworte zu reduzieren. Ich probiere es trotzdem einmal und hoffe, daß es ein bißchen nützen möge. Diese konkreten Punkte sind mir in meinen Softwareprojekten immer wieder untergekommen. Bei der Vorbereitung unserer Kurse zum „Certified Scrum Developer“ hatte ich endlich einen Anlaß, sie zusammenzufassen:

  • Entwickle das richtige System
  • Beweise es kontinuierlich
  • Liefere zielgerichtet neue Funktionalität
  • Liefere bei jedem Sprint
  • Trage zur richtigen Architektur und zum richtigen Design bei
  • Arbeite kooperativ
  • Bilde Dich weiter und hilf anderen zu lernen

Entwickle das richtige System

Ein alter Kalauer sagt, das zweitwichtigste sei, etwas richtig zu machen. Das wichtigste ist, das richtige zu machen. Das hat eine ganz reale Anwendung in der Softwareentwicklung: jeder Schritt in der Entwicklung muß von Anforderungen her motiviert sein. Viel zu oft werden spekulative Verallgemeinerungen oder gar spekulative Features realisiert, für die es letztlich gar keinen „business case“, keine geschäftliche Motivation gibt. Das ist einer weit verbreiteten Lücke in der Kette der Übergabe von Anforderungen geschuldet: Kunden spezifizieren Anforderungen in ihrer Welt, ihrer Begrifflichkeit und Granularität. Das reicht oft nicht aus, um die Realisierung hinreichend genau zu leiten. Was hilft, ist Diskussion der Anforderungen. Dabei entsteht ein gegenseitiges Verständnis und evtl. verändern sich dabei auch die Anforderungen: Arbeite mit dem Product Owner am Verständnis. Nutze User Stories als Werkzeug und achte darauf, daß das gemeinsame Verständnis durch Akzeptanztests gefestigt wird. Übrigens: technische Anforderungen können oft nur vom Entwickler-Team erkannt oder sinnvoll formuliert werden. Dann muß ich das auch tun und so dazu beitragen, daß das richtige und das beste System entwickelt wird.

Beweise es kontinuierlich

Oft gehen Akzeptanzkriterien direkt in die Formulierung von Akzeptanztests ein, die damit die Rolle einer ausführbaren Spezifikation bekommen. Das bietet eine riesige Chance, kooperativ alle Fähigkeiten im Team einzubinden. Insbesondere die Rolle der Tester verändert sich massiv, sie stehen nicht am Ende eines Mini-Wasserfalls, sondern sind mitten in der Entwicklung dabei. Manchmal übernehmen sie teilweise die Rolle eines Analysten, der Geschäftszusammenhänge für die Umsetzung in Software aufbereitet. Am besten funktioniert das mit Werkzeugen, die es erlauben, automatisch ablaufende Testskripte schon vor der dazu gehörigen Realisierung zu schreiben. Das heißt: setze Akzeptanzkriterien direkt und nachvollziehbar in Tests um.

Liefere zielgerichtet neue Funktionalität

Die Zielsetzung heißt: gemeinsam wandelt das Team effektiv und zuverlässig Anforderungen in neue Funktionalität um. Die Mittel der Wahl, die den Stand der Kunst repräsentieren, heißen Testgetriebene Entwicklung und Pair Programming. Für eine Testgetriebene Entwicklung gibt ausgezeichnete Gründe:

  • Jede Zeile Code ist durch einen Test, d.h. ein Stück ausführbare Spezifikation begründet. Das stellt sicher, daß keine „goldenen Wasserhähne“ eingebaut werden, die niemand braucht.
  • Die Software ist unendlich viel flexibler. Das wird allein schon dadurch erreicht, daß man bei der Entwicklung jedes Stück Code auf Verbesserungsmöglichkeiten abklopft: das Refactoring bei jedem Schritt
  • Ich hänge nicht mehr fest: durch die Aufteilung der Entwicklung in kleine, reversible Einzelschritte kann ich jederzeit einen Schritt zurückgehen und neu aufsetzen – im Gegensatz zum Fall, in dem ich mit dem Debugger eine Fehler in der Arbeit von mehreren Tagen suchen muß.

Es gibt keine Möglichkeit, Wissen und Fähigkeiten in einem Team schneller zu verbreiten als mit Pair Programming.

  • Neue Techniken lassen sich ohne Risiko im laufenden Projekt erarbeiten
  • Gefährliche Wissensmonopole werde aufgelöst oder verhindert, das Team erhöht seine Handlungsfähigkeit

Das heißt: Um zielgreichtet und zuverlässig liefern zu können, arbeite testgetrieben und mit Pair Programming.

Liefere nach jedem Sprint

Ein Sprint, nach dem keine fertige Software ausgeliefert wird, wird zum puren Ritual. Seine Funktion zum Inspizieren des Entwicklungsstands, die Gelegenheit zum Nachsteuern, die genaue Aussage über Stärken und Defizite geht verloren. Die Motivation und das Interesse gehen verloren, das Commitment wird wertlos. Das Team wird in einem negativen Feedback-Kreis gefangen: die Menge der unfertigen Arbeiten nimmt zu, man kann sich nicht auf Arbeitsergebnisse verlassen, die Entwicklungsgeschwindigkeit sinkt. Deshalb: Plane realistisch, beende angefangene Arbeiten und liefere nach jedem Sprint getestete Software.

Trage zur richtigen Architektur und zum richtigen Design bei

Zwei Aspekte einer guten Softwarelösung sind von außen nur schwer zu beurteilen:

  • Die innere Qualität, das heißt, die Einhaltung von Strukturierungsprinzipien
  • Manche nichtfunktionalen Eigenschaften der Software

Manche der nichtfunktionalen Eigenschaften kann man durch Qualitätsmetriken erfassen – das sollte man auch tun. Andere erschließen sich nicht so leicht: wenn über die Zeit viele Änderungen stattgefunden haben, stellt sich manchmal die Frage, ob die Gesamtstruktur der Software noch adäquat ist oder ob tiefgreifende Änderungen durchgeführt werden müssen, um die Entwicklung zu unterstützen – agile Architektur ist emergent, d.h. die Strukturen entwickeln sich tendenziell weiter. Um das zu erkennen und ggfls. zu thematisieren, muß man einen Blick über den Tellerrand wagen, sich mit dem Gesamtbild beschäftigen und nicht nur mit dem aktuellen Arbeitsschritt. Man muß auch einen Blick dafür entwickeln und gezielt weiterpflegen. Mit anderen Worten: arbeite daran, ein Systemarchitekt zu werden.

Arbeite kooperativ

Softwareentwicklung ist eine Teamarbeit. Wir arbeiten gemeinsam an einem Resultat und wir lernen voneinander. Von Alistair Cockburn stammt die Gleichung „Entwicklungstempo = Lerntempo“. Das funktioniert nur dann, wenn ich kooperativ im Team arbeite und wenn wir voneinander lernen. Kooperation geht aber über das Team hinaus. Ich muß mit dem Product Owner und meinen Kunden zusammenarbeiten, ich muß ihre Probleme und Ziele verstehen, um den besten Beitrag zur Lösung zu erbringen. In keinem Fall funktioniert diese Kooperation, wenn ich meinen Gegenüber nicht respektiere und versuche, ihn zu verstehen. Das heißt dann vollständig: arbeite kooperativ im Team, mit dem Product Owner und Deinen Kunden, respektiere Deine Kollegen.

Bilde Dich weiter und hilf anderen zu lernen

Bob Martin startete eine Diskussion auf der Konferenz Agile 2008 mit einem Beitrag „Software Craftsmanship over Crap“. Das bringt eine Diskussion auf den Punkt, in der deutlich wird: ich bin für die Resultate meiner Arbeit verantwortlich. Gute Software entsteht nur, wenn ich selbst dazu motiviert bin – Außenmotivation funktioniert nicht. Ich kann nur dann auf der Höhe der Zeit bleiben, wenn ich selbst die Initiative zu kontinuierlicher Weiterbildung ergreife. Und der Stand unseres Handwerks (meinetwegen: unserer Kunst) wird sich nur dann signifikant verbessern, wenn wir selbst daran arbeiten.

Artikel wurde in den Warenkorb gelegt.