Voraussichtlicher Erscheinungstermin: Ende 2021

Um nachhaltig Software zu entwickeln, sind klare Anforderungen die absolute Voraussetzung. Aber wie sehen die für dich als Entwickler aus? Reicht es, wenn du mit einem Product Owner einfach ein paar Mal über User Stories sprichst und ein paar Notizen machst? Meiner Erfahrung nach, ist das nicht genug. Selbst eine Definition of Done greift noch zu kurz (wenn es sie überhaupt gibt).

Klarheit für dich als Entwickler ist einfach etwas anderes, als Klarheit für einen Product Owner oder Auftraggeber oder Manager. Du musst Anforderungen technisch umsetzen. Deshalb sollte schon eine Anforderungsanalyse auch "auf die Technik schielen". Für die folgenden Phasen im Entwicklungsprozess - Entwurf und Codierung - sind konkrete technische Anhaltspunkte wichtig, ohne die du in Unklarheiten läufst, die dann zu Rückfragen und Konflikten führen, die wiederum Unzuverlässigkeiten in deiner Lieferung Vorschub leisten.

Der Gedanke der Agilität, Anforderungen iterativ-inkrementell umzusetzen, ist absolut angemessen. Dass du dich mit dem Product Owner in engen Feedbackschleifen drehst, ist nötig - doch es ist meiner Ansicht nach nicht hinreichend. Der Product Owner hat schlicht einen anderen Fokus als du. Seine Verantwortlichkeit ist die Lieferung von Wert an den Auftraggeber. Deine Verantwortlichkeit als Entwickler jedoch ist die Lieferung von Qualität.

Nachhaltige Softwareentwicklung beginnt für mich mit dieser Erkenntnis: Wertlieferung und Qualitätsproduktion müssen entkoppelt werden. Daraus folgt dann, dass die Definition dessen, was Wert darstellt, nicht gleich der ist, was Qualitätsinkremente sind. Der Softwareentwicklungsprozess wird somit um eine Phase reicher: die Analyse von Wertinkrementen.

Im agilen Vorgehen involviert der Product Owner dich in die Definition von Wertinkrementen. Danach bist du dann auf dich gestellt. Für den Product Owner ist das optimal, denn er kann sich nun schon etwas anderem zuwenden. Du machst das mit der Umsetzung ja schon. Aus meiner Sicht ist das eine vorzeitige Optimierung. Du beginnst zu früh mit der Lösungsfindung, denn eigentlich ist die Analyse noch unvollständig.

In diesem Buch möchte ich dir ein verfeinertes Vorgehen vorstellen. In dem dauert die Analyse zusammen mit dem Product Owner etwas länger, weil sie Wertinkremente noch in Qualitätsinkremente zerlegt. Erst die sind für eine Umsetzung konkret genug.

Den Kern der erweiterten, entwicklerorientierten Analyse bildet eine systematische Zerlegung der Anforderungen in Artefakte von technischer Bedeutung. Die reicht hinunter bis zu Nachrichtendatentypen und Funktionen - aber keine Angst, der Product Owner wird von solchen Details verschont. Wichtig ist, dass dir das Analyseziel klar ist. Du willst eindeutige Ansatzpunkte für dein weitere Arbeit als Programmierer haben.

Diese Zerlegung braucht allerdings ein passendes Vorgehen als Kontext. In dem ist die Iteration noch wichtiger. Deshalb unterscheide ich zwischen Lieferungen von Wert und Aufforderungen zum Feedback. Sauberer Code braucht sozusagen Hyper-Agilität.

Und dieses Vorgehen funktioniert wiederum nicht im luftleeren Raum. Es hat als Voraussetzung, dass du die Ruhe bekommst, die du für hohe Qualität brauchst. Das funktioniert nur, wenn sich der Umgang mit dem Schätzen und Deadlines verändert.

Slicing, Spinning, Forecasting sind die Begriffe, unter denen ich dir eine Sicht auf die Anforderungsanalyse vermitteln will, die dir als Programmierer taugt. Der Pendelschwung hin zur Product-Owner-getriebenen iterativen Softwareentwicklung war nach Jahrzehnten des Wasserfalls nötig. Doch damit solltest du als Programmierer nicht zufrieden sein - und der Product Owner auch nicht. Langfristig hohe Produktivität gibt es nicht, ohne deinen Bedürfnissen als Programmierer wieder Raum zu geben. Du sollst mit besserem Ausgangsmaterial in die Umsetzung starten.

Was erwartet dich konkret in diesem Band? Ich habe meine Vorstellung von einer "entwicklergerechten" Anforderungsanalyse in mehrere Lektionen/Kapitel eingeteilt, die ich auch in Trainings vermittle. Schau dir einfach mal das Inhaltsverzeichnis an. Jedes Kapitel besteht aus einem Erklärungsteil und Übungsaufgaben. Der Text ist mit vielen Abbildungen und Code aufgelockert. Insgesamt sollte das Buch dir ca. 8+ Stunden Lesespaß geben. Und zur Bearbeitung der Übungsaufgaben kannst du auch nochmal 12-16 Stunden rechnen. Das sage ich nicht zur Abschreckung, sondern will dir zeigen, dass du hier einiges Material hast, um dich als Software Craftsman solide mit der Thematik Clean Code Development auseinander zu setzen - auch wenn ich dich hier ein wenig vom reinen Codieren abbringen will. Das Buch ist ernsthafte Lektüre für deine Weiterbildung.

Schau dir am besten einmal die Probekapitel an; oder stelle Fragen in der Community zum Buch und rund um Clean Code Development. Dann bist du hoffentlich entschlossen, es damit zu versuchen: für mehr Zuverlässigkeit bei deinen Softwarelieferungen und mehr Wert deiner Software für den Kunden.

Ich wünsche dir viel Freude bei der Programmierung!

-Ralf Westphal, info@ralfw.de

Ver. 0.2.0.20210811