Get in touch
Schnell, aktuell und stabil. Was haben alle diese Adjektive gemeinsam? Sie beschreiben etwas, sind aber kontextabhängig. Erst der Zusammenhang gibt den Adjektiven ihre eigentliche Bedeutung.
Mit dem Fahrrad 20 km/h zu fahren, erscheint schnell, dieselbe Geschwindigkeit mit dem Auto jedoch nicht. Am 26. Dezember 1952, als die Tagesschau zum ersten Mal auf Sendung ging, waren die Nachrichten tagesaktuell. Heutzutage sind Nachrichten aktuell im Minutentakt. Ein Internetprovider bezeichnet die Verfügbarkeit einer Webseite mit 96 bis 98 % als stabil. Aber würde man die Onlineplattform Facebook auch als stabil bezeichnen, wenn sie sieben Tage im Jahr nicht erreichbar wäre?
Das Arbeiten mit Anforderungen stellt alle Beteiligten vor große Herausforderungen. Zu Beginn müssen die Anforderungen richtig erfasst werden. Anschließend müssen sie an alle Beteiligten (korrekt) weitergegeben werden, damit alle auf dem gleichen Wissensstand sind. Bereits bei der Weitergabe der Anforderungen können erste Fehler entstehen. Welche Risiken bestehen und wie diese minimiert werden können, schauen wir uns in den nächsten Abschnitten an.
Anforderungen werden in einem Kommunikationsprozess weitergegeben. Wie aus dem Alltag bekannt ist, führt Kommunikation zwischen Parteien oft zu Missverständnissen. Dies liegt unter anderem an den Erfahrungen, die wir in unserem Leben gesammelt haben. Sei es, weil die einzelnen Individuen kulturelle Unterschiede aufweisen oder aus unterschiedlichen Fachbereichen kommen. Menschen nehmen aufgrund ihres Wissens, ihrer Erfahrungen und ihrer daraus resultierenden Annahmen, Situationen unterschiedlich wahr und interpretieren diese subjektiv. Aufgrund dessen können unterschiedliche Personen ein und dieselbe Anforderung anders aufnehmen, abweichende Informationen daraus ziehen und diese unterschiedlich interpretieren.
Nehmen wir als Beispiel die folgende Anforderung:
„Schaffung eines Mittels zum Schutz einer kleinen Gruppe von Menschen vor den feindlichen Elementen ihrer Umwelt. [1]"
Der/Die Product Owner:in stellt im Backlog Refinement die User Stories vor. Alle am Meeting beteiligten Personen tauschen sich über die Anforderungen aus. Danach bespricht das Team die Informationen mittels unterschiedlicher Kommunikationsformen. Für die Teammitglieder bedeutet das eine Unmenge an Informationen und es werfen sich viele Fragen auf, auch im Detail. Das Team besteht aus unterschiedlichen Persönlichkeiten mit unterschiedlichen fachlichen Rollen. Jedes dieser Mitglieder verfügt über ein entsprechend individuelles Vorwissen und hat deshalb einen anderen Fokus auf die vorgestellte User Story. Wenn dem/der Product Owner:in beispielweise etwas völlig klar ist, dann heißt das nicht, dass es einem anderen Teilnehmenden auch genauso klar ist. Der/Die Entwickler:in kann eine Information überlesen, überhören oder falsch interpretieren. Dinge werden fehlerhaft beobachtet, aber nicht dokumentiert, was dann im Anschluss Erinnerungsfehler zur Folge hat, die bei der Implementierung zu Abweichungen führen können.
Der Sprint startet. Der/Die Entwickler:in will eine User-Story umsetzen. Dabei kann auffallen, dass Informationen fehlen. Im Backlog Refinement war ihm/ihr die User Story noch klar und somit war es auch klar, was zu tun war. Was ist geschehen? Das Backlog Refinement ist zwei Wochen her und in dem Meeting wurden zusätzliche Informationen in verbaler Form ausgetauscht, die niemand dokumentiert hat. Die User Story hat aber nur mit den ergänzenden Informationen Sinn ergeben.
Falls der/die Entwickler:in merkt, dass Informationen fehlen, kann er/sie sich diese noch beschaffen. Gravierender ist es, wenn Fakten aus Mangel an Informationen falsch interpretiert und als Konsequenz die Anforderungen nach einer abweichenden Vorstellung umsetzt werden. Dies ist dann der Anfang einer Kette von Fehlern.
Kommunikation lässt oft Freiraum für Interpretationen.
„Ich weiß nicht, was ich gesagt habe, bevor ich nicht die Antwort des Anderen darauf gehört habe.“
Dieses Zitat von Norbert Wiener bringt es auf den Punkt. Ich weiß zwar, welche Information ich meinem Gegenüber übermitteln wollte, jedoch weiß ich nicht, wie dieser sie letztendlich interpretiert hat. Unter anderem können Interpretationsfehler aus den folgenden Gründen entstehen:
1. Generelle/individuelle Interpretationsfehler (resultierend aus einem besonderen Jargon, einer fehlenden gemeinsamen Sprache, einem nicht geteilten Wortschatz, unbekannten Fachbegriffen, unterschiedlichen Kulturen und Hintergründen etc.)
2. Mehrdeutigkeit im Sinne der Verwendung unpräziser Formulierungen
In Nordamerika ist es kulturell üblich, bei formellen Anlässen anderthalb Armlängen Abstand zu seinem:r Gesprächspartner:in zu halten. In Lateinamerika dagegen nur eine halbe. Spricht ein:e Nordamerikaner:in mit einem:r Lateinamerikaner:in, bewegt sich der/die Nordamerikaner:in immer einen Schritt zurück und der/die Lateinamerikaner:in einen Schritt hin zum/zur Gesprächspartner:in [3]. Neben kulturellen Unterschieden können auch Unterschiede in den Fachbereichen zu Interpretationsfehlern führen. Zwar werden dieselben Begriffe benutzt, haben aber je nach Fachbereich allerdings unterschiedliche Bedeutungen. Zudem wird die ein und dieselbe Situation von jedem Individuum unterschiedlich und damit subjektiv wahrgenommen.
Jedem/Jeder Softwareentwickler:in ist der Ausdruck „Code Smells“ bekannt, der von Martin Fowler in seinem Buch „Refactoring: Improving the Design of Existing Code“ vorgestellt wurde. Weniger bekannt ist „Requirements Smells“ [4]. Requirements Smells zeigen Merkmale von unpräziser Sprache in der Form von Mehrdeutigkeit auf, die oft zu Interpretationsfehlern führen. Nachstehend sehen wir zwei Beispiele von Requirements Smells:
Können Sie sich noch an die Anforderung zu Beginn des Artikels hinsichtlich dem Schutz einer Gruppe erinnern, die zu einem Interpretationsfehler geführt hat? Falls ja, dann schreiben Sie diese kurz nieder. Überprüfen Sie anschließend, ob diese übereinstimmt mit Ihrer Erinnerung. Auch minimale Abweichungen in der Problemstellung können zu unterschiedlichen Lösungen führen. Wenn in dem genannten Beispiel aus „Schutz einer kleinen Gruppe von Menschen“ die Anforderung wird „Schutz einer Gruppe“, kann dies zu einer ganz anderen Lösung führen, die nicht zu dem Problem dieser Gruppe passt.
Gerade bei agilen Vorgehensmodellen gibt es Methoden, die das Team optimal nutzen kann, um die vorgestellten Risiken zu minimieren. Nehmen wir als Beispiel das Backlog Refinement. Vor dem Backlog Refinement kann das Team die einzelnen Stories, die es im Meeting bespricht, an einzelne Story Heros verteilen. Diese können die Stories gezielt auf Requirements Smells analysieren. Dies hat einerseits den Vorteil, dass die Entwickler:innen sich mit den Stories bereits im Vorfeld vertraut machen und andererseits können die Entwickler:innen im Backlog Refinement die Stories selbst vorstellen. Folglich kann der/die Product Owner:in Beobachtungsfehler, Erinnerungsfehler, Interpretationsfehler und Mehrdeutigkeit in der Problemstellung schnell(er) identifizieren und diese sofort klarstellen.
In der agilen Softwareentwicklung liegt die Priorität auf der Fehlervermeidung. Die Anforderungen bilden dabei die Basis des Softwareentwicklungsprozesses.
Entstehen hierbei
können sich diese durch den ganzen Softwareentwicklungsprozess ziehen. Je später die Fehler entdeckt werden, desto höher sind die Kosten, diese zu beheben. Der optimale Zustand ist es, die vorgestellten Risiken vor der Implementierung zu identifizieren und zu korrigieren. Zeit in die Berichtigung zu investieren lohnt sich, denn ein gemeinsames Verständnis der Anforderungen vermindert Arbeitszeit und Kosten bei der Entwicklung und verkürzt die Dauer bis zur Implementierung. Eine Möglichkeit dies zu tun, ist die vorgestellte Einführung von Story Heros.
Fotos: Unsplash
