Folge 21

Requirements Engineering im agilen Umfeld. 

„Das heiß das agile Vorgehen hilft auf der einen Seite näher am Budget zu bleiben und auf der anderen Seite eine hohe Qualität halten zu können"

 

 

Hallo und Willkommen zurück zu "Informatiker erklären die Welt". Das Thema der heutigen Folge lautet: 'Requirements Engineering im agilen Umfeld'. Das hört sich erstmal sehr allgemein an, aber wir brechen das Thema heute in seine Einzelteile. Consistec inhouse Softwareentwickler Marcel Zinnow und Alexandra Bernhard erklären was typische Anforderungen, Missverständnisse, Herausforderungen, Lösungen und Ideen des agilen Engineerings sind. Es gibt viele Dinge zu erläutern.

Bleibt gespannt und viel Spaß beim Hören!

Transkription

Marcel: Hallo und herzlich willkommen zu einer neuen Episode von Querverlinkt. Vielleicht kennt mich der eine oder andere schon aus früheren Episoden. Mein Name ist Marcel, ich bin Leiter für Softwareentwicklungsprojekte bei der consistec. Als Gesprächspartner habe ich heute meine Kollegin Alexandra Bernhard mitgebracht. Alexandra stell dich doch mal bitte kurz vor. 

Alexandra: Ja. Hallo mein Name ist Alexandra Bernhard. Ich bin seit zweieinhalb Jahren bei der consistec, war zuvor schon in der Softwareentwicklung und im 'Requirements Engineering' tätig und das ist jetzt mein aktueller Schwerpunkt.

Marcel: Alexandra schön dass du da bist. In der heutigen Folge geht es um das Thema 'Requirements Engineering im agilen Umfeld' und du hast ja Erfahrungen in der Rolle des 'Requirements Engineers' bei uns. Darunter versteht man ja den Prozess für das Definieren, Dokumentieren und für das Ändern von Anforderungen. Erklär mal wie das in Verbindung mit dem agilen Umfeld zusammenhängt, ob das da überhaupt möglich ist in so einem Umfeld 'Requirements Engineering' zu betreiben.

Alexandra: Genau. Also erstmal zum 'Requirements Engineering' an sich. Also es geht hier halt nicht nur um die Dokumentation, sondern erstmal auch um die Erhebung von Anforderungen. Das heißt erstmal in Gesprächen oder mit anderen Methoden die Anforderungen des Kunden aufnehmen und diese dann nieder zu schreiben. Und dann ganz wichtig auch zu validieren. Das heißt mit den unterschiedlichen Stakeholdern zu sprechen und Kompromisse zu finden, wenn sich zum Beispiel Anforderungen widersprechen. Unter anderem auch das Anforderungsmanagement als Teil davon. Im Management geht es eben um Dinge wie Sachen zu priorisieren, ein Risiko einzuschätzen und später, wenn sich Anforderungen ändern, das Ganze nachvollziehbar zu gestalten und es insgesamt anzupassen.

Marcel: Worin unterscheidet sich eigentlich eine Software die man entwickeln will zu einem Produkt, was auf einer Fertigungsanlage entwickelt wird, wie zum Beispiel ein Sofa?

Alexandra: Was bei einem Softwareprojekt einfach häufig anders ist, ist dass es ein bisschen Innovationscharakter hat. Das heißt ich weiß am Anfang vielleicht gar nicht so genau was ich möchte, ich habe vielleicht nur eine Idee. Und hangele mich dann weiter vor. Ich glaube dieser Innovationscharakter. Es ist eben nicht etwas was schon tausend Mal produziert wurde, sondern einfach was neues. Bedingt durch diese Unschärfe die man hat in den Anforderungen. Und es wird erst besser je weiter man sich da vorgetastet hat, beziehungsweise wie weit man da schon in der Entwicklung ist. Weil dann wirkt die Vorstellung einfach besser. Und das ist die Besonderheit vom agilen Vorgehen, dass ich einfach weiß, dass ich das am Anfang noch nicht so genau weiß und deswegen auch meine Arbeit da noch nicht-. Ich definiere nichts ins Detail aus, wenn ich noch gar nicht weiß funktioniert es überhaupt im Groben. Je näher es dann an die Entwicklung geht, desto genauer weiß ich auch wie ich es haben möchte. Und dann spezifizieren ich es detaillierter aus. 

Marcel: Es ist ja alleine schon die Umgebung. Du hast bestehende Systeme und die Softwareentwicklung, die muss praktisch mit diesen bestehenden Systemen arbeiten. Das heißt du hast nicht irgendwie eine Softwareentwicklung von Grund auf komplett neu, wie jetzt bei beim Beispiel Sofa. Ich kann jetzt genau angeben so und so soll es aussehen, weil ich habe immer irgendwelche Probleme, Bedingungen, Constraints, die ich im Vorfeld gar nicht weiß. Die ich erst wenn der Entwickler an diesen Punkt kommt, ergeben und festgestellt werden. Und dann muss das Ganze auch noch aufgerollt werden. Dann muss diese Bedingung, die dann im Vorfeld- dieses Problem was auffällt, muss ja dann nochmal zurückgespielt werden zum Anforderungsmanager, um das nochmal neu zu bewerten. Um zu überprüfen, ob das denn überhaupt noch mit den Zielen vereinbar ist.

Alexandra: Das ist auch ein wichtiger Punkt. Das ist auch etwas was sehr früh eigentlich in den Prozess rein muss, dass man sich Gedanken macht was sind denn eigentlich meine Randbedingungen? Habe ich Restriktionen? Zum Beispiel in Formen von Systemen, die mit meinen Systemen zusammenarbeiten sollen. Vielleicht gibt es ja auch schon Randbedingungen, die vom Kunden kommen oder vielleicht auch aus dem Team. Wir wollen zum Beispiel mit Java entwickeln, dann wäre das auch eine Randbedingung. Das ist auch wichtig zu berücksichtigen. Das sollte man auch sehr früh im Projekt mit einbeziehen.

Marcel: Genau. Wobei es oft die Praxis auch gezeigt hat, dass diese Randbedingungen in den seltensten Fällen von Anfang an definiert werden können und festgehalten werden können. Und dass das oft während der Arbeit, während der Softwareentwicklung auffällt. Gerade dem Entwickler. Dem fällt das zu einem späten Zeitpunkt erst auf und dann kann man das ganze nochmal mit einfließen lassen.

Alexandra: Man tut sehr viel dafür, dass man den Überblick über alles behält. Aber einiges ist man sich halt nicht bewusst. Das muss man sich direkt notieren, dass man die nicht vergisst. Auch wenn man am Anfang halt schon merkt ich habe die und die 'Constraints' und diese dann auch sofort notieren. Weil das ist häufig etwas das vergessen wird und dann kann das später sehr schwierig werden, wenn man das nicht beachtet hat. Dann passt halt alles nicht mehr. 

Marcel: Ich kenne aus der Praxis die Projektmanagementmethode, 'Scrum'. Und ich kenne die agilen Werte. Und welcher Grad, was Requirements Engineering angeht, wird da nicht erwähnt-. Wie ist das in der Praxis? Wird da Requirements Engineering einfach weggelassen oder wie bildet sich das wieder, wie stellt sich das da?

Alexandra: Das ist so ein Missverständnis, das teilweise in der Praxis vorkommt, dass man denkt im Prinzip hat man durch Scrum schon alles gegeben was man braucht. Im Prinzip hat man unterschiedliche Möglichkeiten seine Anforderungen in Epics, Userstorys und so weiter herunter zu brechen. Aber das ist keines Wegs ausreichend, beziehungsweise sollte man das ergänzen. Auch durch klassische Methoden oder angepasste klassische Methoden.

Marcel: Du hast gerade eben die Begriffe Epics, Userstorys und Task verwenden. Kannst du die kurz erklären?

Alexandra: Also die Idee ist, dass man von groben Anforderungen und einer groben Granularität immer feiner wird. Das heißt ich habe auf der obersten Ebene die Epics, die mehrere Userstorys entsprechend enthalten können. Und Userstorys wiederum lassen sich in Tasks herunter brechen. Und je nachdem wenn man noch eine Ebene zwischendrin braucht hat man noch Features und eine Klammer um die Userstorys entsprechend zu bilden.

Marcel: Du hast eben von den Missverständnissen geredet. Ein Missverständnis war, dass in der Praxis die Dokumentation im agilen Umfeld für nicht so wichtig empfunden wird. Ist das so?

Alexandra: Ja, einer der Leitsätze ist Kommunikation über Dokumentation. Das heißt aber nicht, dass die Dokumentation nicht wichtig ist, sondern das die Kommunikationsebene nochmal mehr Bedeutung hat.

Marcel: Und das zweite Missverständnis habe ich jetzt so interpretiert, dass die Entwickler Epics, Userstorys und Task erwarten mit einer gewissen Detailtiefe. Und das hört sich an als würde es nicht zu der Vorstellung von Requirements Engineering im agilen Umfeld passen. Wie ist das denn genau gemeint?

Alexandra: Es ist so, dass im Scrum zum Beispiel die unterschiedlichen Detaillierungsgrade durch Epics, als das Grobkörnigste Element, bis runter zu den Tasks gegeben sind, um entsprechend aus Anforderungen rein und raus zu zoomen. Aber so gehen auch schon die Entwickler, beziehungsweise auch im Anforderungsmanagement, relativ intuitiv vor. Und benutzen auch andere Möglichkeiten der Dokumentation. Dazu zählen zum Beispiel die Prozessmodellierung, die man erstmal braucht um sich einen Überblick über die Fachlichkeit zu verschaffen, beziehungsweise wie der spätere Prozess einmal in der Software aussehen soll. Bis runter zu dem UI Design in Form von Wireframes und auch der Softwareentwurf zählt da dazu. Beziehungsweise auch Kontextmodelle, in denen man einfach sehen kann wie die Entwickelte Software mit der Umgebung interagiert.

Marcel: Genau. Also die Dokumentation ist ein zentrales Artefakt im Requirements Engineering. So habe ich das jetzt verstanden. Man erhält dadurch den Einblick in verschiedene Sichtweisen, es verschafft einen Überblick über das große Ganze. Du hast auch Beispiele genannt von verschiedenen Dokumentationen. Was ist denn der Sinn und Zweck, beziehungsweise ich kenne jetzt-. Ich habe viel erlebt, dass viele erwarten die Dokumentation wird gemacht um im Nachhinein das Festgehaltene auch als Nachweis zu haben. Man sagt: "Das wurde jetzt angefordert. Das ist im Budget drin. Und das muss dann auch entwickelt werden." Gibt es da noch andere Zwecke und Ziele der Dokumentation?

Alexandra: Ja leider wird teilweise hauptsächlich der Fokus darauf gelegt, dass man die Anforderung erstmal initial schätzen kann. Aber die Zwecke sind vielfältig für die Anforderungsdefinition. Zum Beispiel rechtliche Zwecke, wenn ich mich tatsächlich absichern muss. Das ist das eine. Aber man möchte auch zum Beispiel die spätere Wartung erleichtern. Das heißt, es hilft den Softwareentwicklern auch, wenn das System entsprechend dokumentiert ist. Und auch initial zum Beispiel möchte man vielleicht erstmal alle auf einen gemeinsamen Stand bringen und würde da entsprechend auch mehr Dokumentationsaufwand betreiben, als man es vielleicht später machen würde. Das kann dann auch sehr individuell gestaltet werden. Also mit Diagrammen oder ganz frei. Alles was dem Verständnis nützt ist dienlich.

Marcel: Also ich denke was auf jeden Fall klar sein sollte ist, dass Dokumentation nicht allumfassend sein kann. Jetzt ist es so, mit dem Kunden gibt es ein gegebenes Budget und man vereinbart einen festen Zeitrahmen. Und am Ende erwartet der Kunde , dass die Anforderungen geschätzt werden. Wie siehst du das gerade im agilen Umfeld?

Alexandra: Im agilen Umfeld geht man da gängiger Weise ein bisschen anders vor, beziehungsweise ist der Fokus und die Idee dahinter eine andere. Die Idee ist, dass man erstmal eine Vision formuliert. Das ist das aller gröbste, eine übergeordnete Vision und dann seine Ziele ableitet. Die Ziele müssen dann zum Beispiel auch in einer Form messbar sein, damit man auch feststellen kann hat man die tatsächlich erreicht. Und gut verständlich. Und die Ziele dienen dann erstmal als Leitplanken für die Anforderungsdefinition. Und am Ende des Tages ist es wichtiger, dass der Kunde seine Geschäftsziele erreicht. Und auch für die Softwareentwicklung ist es wichtiger, dass sie diese unterstützt, als Anforderungen, die man ursprünglich mal definiert hat exakt einzuhalten. Natürlich geht man nicht hin und hält es komplett frei, auch da würde man Anforderungen initial definieren, damit man eine Vorstellung hat, aber die Zielsetzung ist grundsätzlich eine andere. 

Marcel: Also verstehe ich das richtig? Egal ob im klassischen Projektumfeld oder im agilen-. Der Zeitrahmen und das Budget kann in beiden Fällen fix sein. Der große Unterschied ist dann in den Anforderungen. Im klassischen Umfeld werden die Anforderungen von Anfang an fix vorgegeben, auch die Anzahl an Anforderungen. Und im agilen Umfeld orientiert man sich eher an den Zielen. Es kann ein initiales Set an Anforderungen geben, aber man hat auch die Möglichkeit Anforderungen, wenn das Budget erschöpft ist oder der zeitliche Rahmen nicht eingehalten werden kann, fallen zu lassen. Wenn trotzdem das übergeordnete Ziel erreicht werden kann. Sehe ich das richtig so?

Alexandra: Leider ist das auch im agilen Kontext meistens so, dass der Kunde dann doch ein Budget tatsächlich fixieren möchte. Aber man hat da entsprechend mehr Stellschrauben als im klassischen Ansatz. Im agilen Ansatz würde man eher hingehen und sich auf die Geschäftsziele einigen, die Erfüllung von diesen Zielen und sich weniger auf die Anforderungen zu fixieren. Wenn das Budget dann tatsächlich einen Engpass darstellt, wird man eher die eine oder andere Anforderung weglassen. Oder vielleicht auch mal Anforderungen austauschen, um näher an das Geschäftsziel zu kommen und weniger an der Budget Schraube zu drehen und weniger an der Qualität. Qualität ist hier das was meistens sehr stark leidet, weil man das dann meistens doch nicht so genau definiert hat, wie qualitativ man das haben möchte. Und das führt dann am Ende zu Kundenzufriedenheit. Dass heißt, das agile Vorgehen hilft auf der einen Seite näher am Budget zu bleiben und auf der anderen Seite eine hohe Qualität halten zu können. 

Marcel: Insbesondere bei der Qualität möchte ich auch hier nochmal herausstellen: Es gibt einen Unterschied zwischen innerer und äußerer Qualität. Und die äußere Qualität ist das was der Kunde sieht was ihm leicht verständlich ist. Wie zum Beispiel die Benutzermaske, die der Endbenutzer es dann sieht, oder vielleicht irgendwelche Geschwindigkeiten. Er sieht die Reaktion, die kommt ganz schnell. Aber was wir als Softwareentwickler auch beachten müssen ist die innere Qualität. Das heißt wir müssen darauf achten, dass die Software auch Wartungsfreundlich ist oder dass auch gewisse Dinge beachtet werden, wie Architektur Design, die dem Kunden gar nicht so ersichtlich sind.

Alexandra: Genau. Man kann sich da eigentlich nicht mehr rausreden als Softwareentwickler in der heutigen Zeit. Da gibt es mittlerweile jede Menge Normen und es wir eigentlich erwartet und auch vorausgesetzt, dass die entsprechend eingehalten werden. Wenn man das nicht sowieso schon im Vertrag fixiert hat. Also sehr wichtig heutzutage.

Marcel: Jetzt hast du erwähnt, dass es im agilen Umfeld wichtiger ist die übergeordnete Geschäftsziele zu definieren und das man auch Anforderungen, wenn es Budget knapp wird oder der Zeitpunkt kommt wo es mit dem Projekt zu Ende geht, dass man auch Anforderungen fallen lassen kann. Ich kann mir vorstellen, dass das beim Kunden zu unmut führt. Dass er gar nicht erfreut ist, solche Kompromisse einzugehen. Wie ist das denn?

Alexandra: Also wichtig ist hier tatsächlich das gegenseitige Vertrauen. Es hilft auch sehr, wenn man sich viel in einer Kunden-Lieferanten Beziehung schon ein bisschen besser kennt. Oder es hängt auch davon ab, ob der Kunde schon in agile Projekte involviert war und das Vorgehen so ein bisschen kennt. Meistens besteht dann die Angst, dass vielleicht nicht drauf geachtet wird, dass das Geschäftsziel tatsächlich verfolgt wird. Auf der anderen Seite ist es für den Softwareentwickler wichtig, also für die Softwarefirma sehr wichtig, da auf den Kunden zu setzen. Weil wenn dieser während dem Projekt mit tausenden neuen Feature Wünschen kommt und praktisch seine Software vergoldet haben möchte, habe ich ein bisschen verloren, wenn das noch nicht so bis ins Detail herausgearbeitet ist.

Marcel: Jetzt kann ich mir vorstellen, dass ein Kunde nach dem Motto "Vertrauen ist gut, aber Kontrolle ist besser." kommt. Aber ich glaube da geht ein bisschen-. Da ist das Verständnis nicht bei den Kunden angekommen, dass gerade im agilen Umfeld die Kontrollmöglichkeit größer ist, weil der Kunde auch die Möglichkeit hat sich frühzeitig, dadurch das es ein iterative Prozess ist, Inhalte anzugucken und da noch rechtzeitig, falls es Probleme gibt oder Fehl Implementierungen, einzuwirken. Das wird oft gar nicht so gesehen.

Alexandra: Genau. Also eigentlich ist es der große Vorteil, dass man durch die Sprint Reviews die Möglichkeit hat als Kunde wirklich konkretes Feedback zu erhalten. Also das die Softwareentwickler entsprechend konkretes Feedback erhalten. Und das der Kunde sieht, was wurde für ihn da entwickelt. Das heißt er kann sagen, ob das in die richtige Richtung geht, fehlt ihm noch etwas, soll was nochmal geändert werden. Also er hat da eigentlich die Mittel an der Hand. Und das kann auch gerne immer wieder ergänzt werden. Wichtig ist, dass der Kunde sehr nah am Entwicklungsprozess ist. Und das ist in der Praxis nicht immer gegeben, wie man sich das wünscht.

Marcel: Genau. Nicht nur im Entwicklungsprozess. Auch schon am Anfang im Prozess der Anforderungsdokumentation des Requirements Engineerings sollte der Kunde von Anfang an mitarbeitet, auch iterativ. Die Dokumente müssen ja auch validiert werden, müssen überprüft werden, müssen abgestimmt werden. Und ich denke auch bei großen Projekten in denen es um große Geschäftsprozesse geht, um Geschäftslogik, vielleicht auch Portale die man baut, wo viel Kundeninteraktion nötig ist. Das es da wichtig ist, dass der Kunde dann auch wirklich von Anfang an, angefangen bei den Zielen, mitwirkt. Und dann kontinuierlich dabei ist und das dadurch auch unter Kontrolle hat.

Alexandra: Ja. Also es ist eigentlich ein großer Vorteil für den Kunden, dass er tatsächlich sieht was passiert. Was halt immer so eine Schwierigkeit darstellt ist tatsächlich den übergeordneten Blick für alles zu haben. Deswegen hilft es dann, wenn man die Anforderung auch auf höherer Ebene nochmal beschrieben hat, sodass der Kunde nicht nur sieht: "Hey. Das wurde jetzt tatsächlich im einzelnen Detail gemacht", sondern dass er das im Gesamtkontext immer noch irgendwo erkennen kann, dass das alles in die richtige Richtung läuft. Also auch hier kann man Requirements Methoden, beziehungsweise Dokumentation, verwenden um das noch mehr zu unterstützen.

Marcel: Jetzt hast du vorhin viel über die Ziele gesprochen, die mit dem Kunden vereinbart werden sollen. Kannst du da ein bisschen genauer formulieren was man darunter versteht, beziehungsweise wie das aussieht? Ich tue mich da schwer den Unterschied zwischen Ziele und Anforderungen und vielleicht auch Visionen, da den feinen Unterschied heraushören.

Alexandra: Auch hier geht es wieder im Prinzip darum erstmal vom groben zum feinen zu kommen. Also erstmal von einer groben Granularität, auch eben von der Geschäftsebene her, was möchte ich eigentlich erreichen, da habe ich ganz als übergeordnetes Element die Vision. Dann auf der nächsten Ebene die Ziele, die dann entsprechend messbar sind. Also das wäre ein Kriterium, dass für eine Zieldefinition wichtig ist. Sie sollen eindeutig definiert sein, sodass man das auch irgendwo versteht. Ein Ziel sollte auch irgendwo erreichbar sein, weil wenn ich etwas definiere, was ich gar nicht erreichen kann-. Ist es realistisch? Und ich muss wissen bis wann ich das erreicht haben will. Und somit habe ich wenn ich diese Ziele vorgegeben habe meine Leitplanken. Und wenn ich zum Beispiel Anforderungen erhebe, dann schaue ich ist das tatsächlich erreicht? Sind alle Ziele erreicht? Und wenn nicht, würde ich so eine Anforderung gegebenenfalls auch verwerfen.

Marcel: Jetzt kann ich mir vorstellen, dass man in der Praxis ganz oft mit Alt-Systemen zu tun hat. Der Benutzer oder auch der Kunde, der arbeitet ja schon in gewissen Systemen, in bestehenden Systemen. Und es existieren teilweise schon digitale Prozesse, so halbdigitale, halbautomatisierte Prozesse, manuelle Prozesse. Man verwendet schon bestimmte Tools. Und gerade da kann ich mir vorstellen, dass es beim Erreichen und Definieren der Ziele oft Missverständnisse gibt. Dass der Kunde da vielleicht auch an altbewährtem festhalten will. Dass das gar nicht so einfach ist. 

Alexandra: Das passiert häufig, dass der Kunde schon sehr detaillierte Vorstellungen hat. Vielleicht auch wie die Masken aussehen sollen. Je nachdem, wenn er ein bisschen technisch versiert ist, geht das teilweise runter bis auf die Datenbank und dann ist es eben die Aufgabe des Requirements Engineering, beziehungsweise des Anforderungsmanagers, dass er da das ein bisschen hinterfragt und dann auch mal sagt: "Lass uns nochmal eine Ebene zurück gehen. Lass uns mal erst auf das grobe gucken und dann nochmal herunterbrechen was eigentlich das Ziel ist. Teilweise gibt es dann viel bessere oder andere Lösungen, auf die man vielleicht im ersten Schritt gar nicht gekommen wäre, weil wenn man in seiner Fachlichkeit unterwegs ist hat man da schon sehr viel Erfahrung. Auf der anderen Seite ist es so, dass es sehr wichtig ist was die Fachexperten als Information liefern können. Wichtig ist auf den Kern des Ganzen zu kommen.

Marcel: Das ist ein bisschen die Kunst im Anforderungsmanagement, weil der Fachexperte spricht aus seiner eigenen Sicht. Er spricht darüber was er gewohnt ist, was er kennt. Auch bestehendes was er schon kennt. Und wir müssen dann im Rahmen der Digitalisierung übergreifend das Ganze über viele Fachbereiche unterstützen. Und das ist dann doch nochmal etwas anders, als wenn es nur der Einzelne sieht, der sein Ziel verfolgt, aber nicht das Große und Ganze sieht.

Alexandra: Genau. Also es gehört zur Validierung der Anforderungen dazu, dass man halt solche Dinge anspricht und mit den Stakeholdern gemeinsam ausdiskutiert. Und teilweise muss dann zwischen unterschiedlichen Anforderungen priorisiert werden. Es hilft tatsächlich das warum zu hinterfragen. Warum soll das genau so und so umgesetzt werden? Wenn es direkt von Anfang an sehr konkret ist, hilft es da nochmal nachzufragen.

Marcel: Genau. Jetzt ist es so oft so, dass ein Kunde eine schneller Umsetzung haben möchte und das Anforderungsmanagement überspringt und dann kommt es oft bei Entwicklern zu Problematik. Und dann herrscht Unklarheit und Unverständnis was die Anforderung betrifft. Jetzt wird in der Literatur von einem 'Sprint null' gesprochen. Kannst du uns da kurz was erzählen?

Alexandra: Also direkt eben mit Scrum zu starten ohne den Rahmen geklärt zu haben, wenn man neu in ein Projekt startet, führt eigentlich dazu das dann wahrscheinlich der erste Sprint sehr im Eimer ist. Und wirkt halt nach außen hin auch nicht so super toll. Das heißt in der Realität würden wir erstmal den Rahmen klären. Das fängt dann bei den Arbeitsbedingungen, beziehungsweise muss man auch klären ob Mitarbeiter noch Schulungen benötigen. Bis runter dass man das Systemdesign schon mal entwirft.

Marcel: Das kann dann auch schon mal passieren dass ein 'Sprint null' begonnen wird und sich im Nachhinein herausstellt, es ist noch lange nicht so weit wir müssen eigentlich nochmal einen größeren Umfang an Requirements Engineering betreiben um überhaupt mit der Umsetzung beginnen zu können. 

Alexandra: Das könnte auch passieren und dann muss man eben in der frühen Phase schon überlegen, wie man da gegensteuern kann. Das Gute ist man wird es halt sehr früh erkennen bevor der Schaden schon da ist oder intensiviert wurde.

Marcel: Du hast bereits viel Erfahrung im Bereich Requirements Engineering gesammelt. Was kannst du denn generell so Kunden empfehlen, die in größeren Softwareprojekten noch gar keine Ahnung und gar keine Kenntnisse haben und so etwas noch nie gemacht haben. Was sind denn so deine zwei drei Tipps, die du mitgeben würdest um mal überhaupt einen richtigen Start zu finden?

Alexandra: Also erstmal ist es wichtig, beziehungsweise extrem hilfreich, wenn die Entwickler sehr nah an den fachlichen Prozessen sind oder am Kunden. Und das sie verstehen was tatsächlich umgesetzt werden soll egal wie viel Investment man am Anfang betreiben muss. Man hat insbesondere zu Projektbeginn eine sehr große Unschärfe in der Anforderungsdefinition, eben weil der Entwickler die Fachdomäne nicht so tief kennt oder den speziellen Kunden nicht kennt. Und deswegen ist es so wichtig, dass der Kunde den Prozess begleitet und eben auch immer wieder Feedback gibt. Und weil man auch noch nicht weiß was schafft man jetzt tatsächlich in der Umsetzung der Anforderungen. Man muss die Anforderungen erst detailliert aufnehmen und mit dem Kunden dann bearbeiten, wenn man sie umsetzt. Ansonsten hat man die ganze Arbeit eigentlich umsonst gemacht, muss dann jeder-.

Marcel: Genau. Da fällt mir auch der schöne Begriff „Domain- driven Design“ ein, der gerade für die Entwickler zum Verständnis der Geschäftslogik der Geschäftsprozesse beim Kunden dient. Da möchte ich auch nochmal auf den Podcast verweisen. "Domain-driven Design"

Alexandra: Also es ist sehr wichtig initial zu klären: wer sind die relevanten Stakeholder? Wer liefert überhaupt Informationen zu Anforderungen? Wer muss später berücksichtigt werden? Wer sind die tatsächlichen Anwender? Man muss so etwas klären, damit man da niemanden vergisst. Wenn dann tatsächlich einer nicht direkt ins Projekt eingebunden wird, dass man so etwas wenigstens in Form von Personas in irgendeiner Art festhält. Und dann später nochmal daran denkt, dass man diese Person nicht komplett außen vor lässt. 

Marcel: Wir kommen ja jetzt auch langsam dem Ende entgegen. Mich würde am Ende noch interessieren was würdest du von einem Kunden wünschen?

Alexandra: Natürlich dass er sehr nah am Entwicklungsprojekt ist und da input liefert so viel er halt eben kann. Also das eine aktive Kommunikation stattfindet-. Auch so ein bisschen Partnerschaftliche Zusammenarbeit ist sehr wichtig, dass man da eine gewisse Vertrauensbasis hat, dass der andere da nicht Quatsch für einen umsetzt. Entwickler möchten gerne verstehen-. Zumindest die Entwickler in meinem Umfeld möchten gerne verstehen, was sie da entsprechend entwickeln. Deswegen ist das auch besonders wichtig.

Marcel: Genau deswegen arbeiten Entwickler in Sprints. Sprint ist ein fest definierter Abschnitt, indem die Entwickler die Software umsetzen. Und am Ende eines Sprints gibt es dann immer wieder Review Meetings, die nennen sich Review Meetings in denen sich das Produkt das erstellt wird nochmal angeguckt wird, nochmal evaluiert wird, um zu gucken ob man denn noch an dem Ziel arbeitet, welches man am Anfang definiert hat. Und das kann sich dann der Kunde anschauen.

Alexandra: Vielleicht ein wichtiger Aspekt ist Geduld haben. Ich meine dass sie verstehen dass wenn man neu ins Projekt kommt oder vielleicht die Fachdomäne noch nicht so gut kennt und dann entsprechend hinterfragen muss. Damit die Lösung, die hinten rauskommt tatsächlich gut ist. Das kommt auch darauf an was der Kunde braucht an der Stelle. Dazu muss man immer wieder hinterfragen warum ist das so? Warum wollt ihr genau den Weg gehen? Und sich auch Alternativen angucken und das ist das Wertvollste, wenn man da die Zeit bekommt.

Marcel: Vielleicht können wir als Fazit zum Schluss noch festhalten was genau der Requirements Engineering Prozess ist. Wir haben jetzt festgestellt es gibt kein einfaches Rezept, wie aus einem Rezeptbuch. Man kann nicht einfach das Rezept befolgen und am Ende wird das Projekt funktionierten, weil man sich daran gehalten hat. Es ist einfach von Projekt zu Projekt unterschiedlich. Man muss wirklich in dem Prozess drin sein und je nachdem was gerade für ein Problem auftritt muss man die Prozesse anpassen.

Alexandra: Genau. Das ist ganz wichtig, dass das im Prinzip-. Die Vorgehensweise kein Kochrezept sein kann, weil das Umfeld sehr unterschiedlich sein kann.

Marcel: Jetzt sind wir auch schon am Ende angekommen. Alexandra, ich danke dir für deine Mitwirkung und das nette Gespräch und die Zeit, die du dir genommen hast. Vielen Dank.

Alexandra: Danke ebenso. 

Marcel: Tschüss.

Alexandra: Tschüss.

So das war es schon wieder für heute. Wir hoffen euch hat das Thema gefallen und das ihr etwas mitnehmen könnt. Weiterführende Links zur aktuellen Folge findet ihr wie immer in den Shownotes. Und wenn ihr euch für die wunderbare Welt der Softwareentwicklung interessiert freuen wir uns natürlich, wenn ihr uns abonniert. Für unsere Folge am siebten Juli haben wir consistec CEO Dr. Thomas Sinnwell und einen ganz besonderen Gast für euch im Gepäck. Bis zum nächsten mal. Wir freuen uns auf euch!

Ihre Cookie-Einstellungen

Technisch notwendige (essenzielle) Cookies

Informationen zu den einzelnen Cookies

  • Mehr anzeigen

    Technisch notwendige (essenzielle) Cookies

    Notwendige Cookies helfen dabei, eine Webseite nutzbar zu machen, indem sie Grundfunktionen wie Seitennavigation und Zugriff auf sichere Bereiche der Webseite ermöglichen. Die Webseite kann ohne diese Cookies nicht richtig funktionieren.

    Name fe_typo_user
    Anbieter consistec.de
    Zweck Sichert die Anti-Spam-Maßnahmen bei Benutzen des Kontaktformulars
    Ablauf Session
    Typ HTTP
    Name conCookieSettings
    Anbieter consistec.de
    Zweck Speichert die Zustimmung zu Cookies
    Ablauf 30 Tage
    Typ HTTP
    Name mtm_consent_removed
    Anbieter consistec.de
    Zweck Wird von Piwik Analytics Platform (matomo) genutzt, um festzustellen, dass dem Tracking widersprochen wurde.
    Ablauf 1 Monat
    Typ HTTP
  • Mehr anzeigen

    Statistiken

    Statistik-Cookies helfen Webseiten-Besitzern zu verstehen, wie Besucher mit Webseiten interagieren, indem Informationen anonym gesammelt und gemeldet werden.

    Name matomo.php
    Anbieter consistec.de
    Zweck Erfasst Statistiken über Besuche des Benutzers auf der Website, wie z. B. die Anzahl der Besuche, durchschnittliche Verweildauer auf der Website und welche Seiten gelesen wurden.
    Ablauf Session
    Typ HTTP
    Name _pk_id#
    Anbieter consistec.de
    Zweck Erfasst Statistiken über Besuche des Benutzers auf der Website, wie z. B. die Anzahl der Besuche, durchschnittliche Verweildauer auf der Website und welche Seiten gelesen wurden.
    Ablauf 1 Jahr
    Typ HTTP
    Name _pk_ses#
    Anbieter consistec.de
    Zweck Wird von Piwik Analytics Platform (matomo) genutzt, um Seitenabrufe des Besuchers während der Sitzung nachzuverfolgen.
    Ablauf 1 Tag
    Typ HTTP
    Name _pk_testcookie..undefined
    Anbieter consistec.de
    Zweck Wird von Piwik Analytics Platform (matomo) genutzt, um zu überprüfen, ob der verwendete Browser Cookies unterstützt.
    Ablauf Session
    Typ HTTP
    Name _pk_testcookie.#
    Anbieter consistec.de
    Zweck Wird von Piwik Analytics Platform (matomo) genutzt, um zu überprüfen, ob der verwendete Browser Cookies unterstützt.
    Ablauf Session
    Typ HTTP