In der Softwareentwicklung ist die erfolgreiche Umsetzung von fachlichen Anforderungen entscheidend für den Erfolg eines Projekts. Auch bei agilen Methoden wie Scrum spielt die Erfassung und Dokumentation der Anforderungen eine zentrale Rolle. Meine nachfolgenden Gedanken beleuchten die Bedeutung einer gründlichen Analyse fachlicher Anforderungen vor der Implementierung und dass dies Zeit und Ressourcen spart sowie die Qualität der Software verbessert.
Der abgeschlossene Roll-Out wird oft schon als Erfolg und Abschluss eines Projects oder Projektphase gesehen. Wie in jeden Projekt wird am Ende die Anwender i.e. Kunden des Projekts entscheiden, ob es ein Erfolg ist oder nicht. Im Softwareprojekt zeigt erst die Nutzung durch den Anwender, ob sich die Investition gelohnt hat. Können sie arbeiten wie erwartet? Verstehen sie die (neuen) Funktionen? Und hat die Arbeit im System einen Mehrwert für sie? Erst das entscheidet über den wahren Erfolg der Software. Anwender haben genau dann einen Mehrwert, wenn ihre Anforderungen erfüllt werden, wenn ihnen die notwendigen und vereinfachenden Funktionen für ihre Arbeit bereitgestellt werden.
Im Umkehrschluss ist die Nutzung der Anwendung der letzte ultimative Test ob ihre Anforderungen erfüllt werden. Um genau das zu erreichen, sollten die Anforderungen vor der Implementierung erkannt, erhoben und dokumentiert werden. Das kann auf sehr unterschiedliche Weise wie Use Cases, User Stories oder auch Prosa erfolgen. Nicht immer (um nicht zu sagen fast nie) ist dies die direkte Transkribierung der Wüsche und Äußerungen der Anwender. Der Product Owner muss zuhören, verstehen und daraus die Anforderungen und Funktionen zur Erfüllung der Anforderungen ableiten. Benutzer drücken das, was sie benötigen typischerweise nicht in system-kompatiblen Ideen aus (und müssen das auch gar). Dafür gibt es die Rolle und das Team um den Produktmanager bzw. Product Owner.
Die fachlichen Anforderungen sollten als aller erstes im Projetverlauf geklärt sein und den Rahmen/Scope für die Implementierung festlegen. Nicht jedes technische Detail muss schon festgelegt werden, die stabile Fachlichkeit ist wichtig. Fachliche Abhängigkeiten und Prozesse, Feldwerte und Inhalte müssen festgelegt sein und sollten auf die Bedürfnisse der Anwender zugeschnitten werden. Bestehen hier Zweifel oder Unsicherheit wird es während der Implementierung bestenfalls zeitaufwendige Rückfragen, Klärungsrunden und Verzögerungen geben (um die Anforderungen nun erst im Verlauf der Implementierung zu erheben). Schlimmstenfalls interpretieren die Entwickler die Anforderungen selber und implementieren, das was sie denken. Diese erfundenen Anforderungen bemerken Projekte dann frühestens in der Testphase (und zwar egal ob agil im Sprint oder klassisch am Ende des Wasserfalls). Der Aufwand die eigentlich gewünschten Anforderungen erst dann zu erheben und erneut zu implementieren ist enorm. Sollten die fehlerhaften Anforderungen auch noch durchrutschen sind wir wieder beim Anwender, der die Applikation oder Funktion nicht (wie erwartet) nutzt und Rückmeldung über nicht erfüllte Erwartungen gibt, die teuerste Form der Anforderungserhebung.
All das kostet Kraft und Zeit für Iterationen, die vermeidbar sind, wenn die fachlichen Anforderungen vor der Übergabe an die Implementierung vollständig durchdacht werden. Dies gilt auch und ganz besonders für agile Teams, da eine schlecht formulierte Anforderung im Sprint zu erheblichen Problemen und nicht selten zur Aufgabe der User Story oder gar des Sprint Ziel führen kann. Es hat sich in meiner Arbeit immer wieder gezeigt: Frühzeitig aufgenommene Anforderungen, die vom Product Owner mit seinem Team durchdacht und designt wurden, sparen erheblich Ressourcen und können SCRUM Teams in sehr schneller Folge unglaubliche Funktionen liefern lassen. Zu spät aufgenommen Anforderungen erzeugen Feedback-Loops im Testing oder sogar nach dem Rollout, die teuer und zeitaufwändig sind.
Erst mit einer vollständigen fachlichen Dokumentation der notwendigen Anforderungen sollte m.E. eine Implementierung starten. Dies steht aus meiner Sicht auch nicht im Widerspruch zu SCRUM oder anderen agilen Methoden. Wenn der Product Owner nicht weiß wo die Reise hingeht, dann wird es holprig. Die "Kunst" ist sich tatsächlich auf des MVP i.e. notwendige zu beschränken und von dort aus weiterzuentwickeln. SCRUM ermöglicht es uns die Vision und Priorisierung nur immer wieder regelmäßig zu überprüfen und einfacher Anzupassen als des z.B. das V-Modell zulässt. Und SCRUM verlangt im kleinen genau das … nur fachlich vollständig verstandene und beschriebene User Stories dürfen in einen Sprint.
Tun Sie sich, dem Team und den Anwendern den Gefallen Anforderungen vor der Implementierung zu erfassen und nach Projektfortschritt zu detaillieren.