Das Requirements Engineering wird in agilen Projekten oft dem Product Owner (PO) zugedacht. Das Development Team hingegen sieht sich eher nur als «Requirements-Empfänger». In diesem Blog gehe ich dem Gedanken nach, dass der Einbezug des Development Teams in das Requirements Engineering ein Projekte beschleunigen könnte und für Weiterentwicklungen des Produkts eigentlich sogar unerlässlich ist.
Während in Projekten mit robusten Vorgehensmethoden das Requirements Engineering zeitlich und zuständigkeitsmässig meist klar definiert ist, werden die Anforderungen im agilen Projektumfeld schrittweise ermittelt und kontinuierlich verfeinert. Üblicherweise bringt die Person mit der PO Rolle die Requirements als erste Grobbeschreibung für ein Feature in das Produkt-Backlog, welche dann im Austausch mit dem Development Team verfeinert wird, bis das Team sieht, wie und mit welchem Aufwand eine Lösung realisiert werden kann. Bei alldem bleibt die Sichtweise des Development Teams sehr lösungsspezifisch und die PO-Person behält die Rolle als «Requirements-Lieferant».
Aktives Mitgestalten der Requirements durch das Development Team
Die Frage ist, ab wann ein Development Team für ein Feature verpflichtet sein soll. Es könnte aus meiner Sicht Sinn machen, dass schon bei dem Zeitpunkt, wo die detaillierten Bedürfnisse der Benutzer*Innen aufgenommen werden, sich das Development Team zum ersten Mal vorübergehend den Requirements Engineering Hut aufsetzt und die Verantwortung für ein Feature übernimmt. Denn wenn sich das Development Team direkt und umfassend mit der Problemstellung auseinandersetzt und auch allfällige Spielräume der Benutzer*Innen kennt, wird es auch in der Lage sein, die Lösungsvariante mit dem besten Kosten/Nutzen-Verhältnis und einer akzeptablen Lieferfrist auszuwählen. Ein anderer Vorteil des frühen Einbezuges des Development Teams ist, dass schon während der Anforderungserhebung realitätsnahe Prototypen erstellt werden können.
Das Requirements Engineering hört nicht nach der Anforderungserhebung auf
Bei langlebigen, kontinuierlich weiterentwickelten SW-Produkten ist es jeweils beim Bereitstellen einer neuen Version wieder an der Zeit, sich noch einmal um die umgesetzten Anforderungen zu kümmern. Es gilt dabei zu dokumentieren, wozu und für welche Benutzergruppe die in einer Version enthaltenen Features gedacht sind. Diese Dokumentation entspricht in grossen Teilen dem Zusammenfassen der Requirements, welche in agilen Projekten bis zu diesem Zeitpunkt vermutlich auf mehrere Jira-Issues, physikalischen Story-Cards und anderen, eventuell nicht einmal versionsspezifisch zuordenbaren Dokumenten verteilt sind.
Eine solche Dokumentation dient einerseits der Traceability der Requirements. Andererseits wird sie enorm hilfreich sein, wenn das SW-Produkt weiterentwickelt oder abgelöst werden soll. (Kennen Sie die Anforderung «das neue Produkt muss dasselbe können wie das Vorgängerprodukt»?). Sie hilft auch, Fehlanwendungen zu verhindern oder zumindest als solche zu erklären, wenn es einmal dazu kommen sollte. (Wenn z.B. eine Serviceschnittstelle, welche nur für gelegentliche Wartungsarbeiten eingeführt worden ist, von jemandem für den automatisierten Datenaustausch in operativem Betrieb verwendet wird und nach einem Versionswechsel nun nicht mehr gleich funktioniert.)
Dieser Dokumentationsaufwand soll unbedingt durch das Development Team bei jeder Produktversion erbracht werden. Wenn das später gemacht werden muss, dann ist der Aufwand enorm viel höher und zudem sieht der Product Owner diese Tätigkeit ziemlich sicher ausserhalb seines Zuständigkeitsbereiches.
Fazit
In agilen Projekten finden viele Arbeiten des Requirements Engineerings im Bereich des Development Teams statt und wenn das schon frühzeitig beim Erheben der Detailanforderungen geschieht, dann könnte sich das auch positive auf die Projektdauer auswirken.
