Edit 15.01.2023: Möglichkeit zu Diskussionen haben wir bei LinkedIn: http://tinyurl.com/dvfbtfht
Allgemeines zu SYS.1
SYS.1 ist nicht Bestandteil des VDA-System-Scopes. Wenn du als Zulieferer arbeitest, kommt die Anforderungserhebung vielleicht bei dir gar nicht so ausgeprägt vor. Wenn du jedoch im agilen Sinn direkt im Markt stehst, ist dies ein wichtiges Thema für den Umgang mit Backlogs. Ein normales Scrum Product Backlog stellt eine Liste von Kundenanforderungen dar, die auch zur Verwaltung der Arbeit verwendet wird. Egal welches Framework du einsetzt, auf der obersten Ebene gibt es immer ein Product Backlog, das 1:1 in Beziehung zu einem Produkt steht. Aus Sicht von Automotive SPICE verwenden wir das als Speicherort für Kundenanforderungen.
Diskussion der Base Practices
BP1: Obtain stakeholder expectations and requests
Hier geht es darum, wie du an die Stakeholder-Anforderungen kommst, also wie du dein Product Backlog füllst. Im Assessment musst du hier beschreiben, wie du vorgehst. Am besten beschreibst du, wie du mit den Stakeholdern zusammenarbeitest (Workshops, Regelmeetings) und kannst entsprechende Protokolle / Dokumentation vorweisen. Das Backlog an sich ist ohnehin das wichtigste Artefakt zur Steuerung deiner Entwicklung, dass das Product Backlog für die Stakeholder immer einsehbar ist und als zentrales Dokumentationswerkzeug verwendet wird, sollte im agilen Umfeld ohnehin klar sein. Wenn du Anforderungen einsammelst, musst du diese in irgendeiner Form verarbeiten und sortieren. Hier ist z.B. die Arbeit mit Story Maps, EPICs, zugeordneten Meilensteinen / Releases nützlich. Daneben gelten natürlich weiterhin die klassischen Tugenden, wie die Markierung von funktionalen, nicht-funktionale und prozessuale Anforderungen. Da in einem Backlog normalerweise nur die funktionalen Anforderungen verwaltet werden, musst du überlegen, was du mit dem Rest machst. Die nicht-funktionalen Anforderungen sollten in die DoD, dann musst du aber definieren, wie Du das horizontale Tracing machst. Dasselbe gilt für prozessuale Anforderungen: Wo notierst du sie und wie kannst du sie sie tracen? Möglichkeiten wären, alles in dein Backlog-Tool zu füllen und entsprechende Filter einzurichten, oder in deinem Wiki alles zusammenzuführen.
BP2: Agree on requirements
Da du bei agilen Ansätzen ohnehin zusammen mit den Stakeholdern auf dem Product Backlog arbeitest, sollte eine Zustimmung von dieser Seite leicht zu erzielen sein. Die Frage ist, wie du diese für dich und den Assessor leicht dokumentieren kannst. Stakeholder zieren sich oft, explizit etwas freizugeben. Falls Du eine solche Freigabe auf einzelne PBIs bekommen kannst: super. Anderenfalls musst du dokumentieren, in welchem Meeting / Workshop das „Agreement“ aus Deiner Sicht zustande kam. Bei jedem PBI sollte ersichtlich sein, ob es „agreed“ ist, durch entsprechende Labels oder Workflow-States in deinem agilen Backlog-Werkzeug.
Das PAM weist darauf hin, dass es beim „Agreement“ nicht nur um die Stakeholder geht, sondern auch z.B. um Entwicklungspartner. Überlege also auch hier, wie du zu der erforderlichen Zustimmung kommst und wie du sie dokumentierst. Auf jeden Fall sollte in deiner Definition of Ready aufgeführt sein, dass das PBI „agreed“ sein muss um „ready“ zu sein.
BP3: Analyze stakeholder requirements changes
Backlog Items zu generieren ist das eine, die Änderungen darauf zu verwalten das andere. Hier sind agile Backlog Tools oft schwach aufgestellt und bieten kein Konfigurationsmanagement und kein Baselining. Bei Scrum und skaliertem Scrum musst Du hier zwei Dinge nachweisen können: Wie und wo treten Änderungswünsche auf? Nur in bestimmten Meetings? Oder auch per Email oder Telefon? Wie dokumentierst Du diese Wünsche? Eine Möglichkeit ist, dies als Kommentare an den PBIs transparent zu machen. Das PAM erwartet ja, dass Du hier auch den Impact der Änderung diskutierst. Der Zweite Punkt ist mehr werkzeugbezogen: Wie kannst Du nachweisen, welche Änderungen wann eingeflossen sind und wann die PBIs zueinander konsistent sind (Baselining)?
BP4: Communicate requirements status
Wie wird der aktuelle Stand und Änderungen des Product Backlogs in der Organisation verteilt? Aus agiler Sicht ist das Backlog einfach öffentlich und alle können sich informieren. Ein solches Vorgehen führt aber zu Diskussionen im Assessment, auch wenn die Guidelines ein Pull-System unterstützen. Alle mit Email-Newslettern zuzuspammen ist weder stilvoll, noch wirst du damit die gewünschte Streuung der Informationen erreichen. Mein Vorschlag ist ein Mittelweg: Pflege in Deinem Wiki eine Seite mit der Änderungshistorie des Product Backlogs. Alle Beteiligten können hier sehen, wann zuletzt am Backlog etwas verändert wurde (Stakeholder Workshop, Backlog Refinement usw.).
Hinweise zu Level 2
Bezüglich des Dokumentenmanagement musst du herausfinden, wie du das in deinem Werkzeug zum Backlog Management abbilden kannst. Kannst du mit dem Werkzeug einen Workflow abbilden? Konfigurationen und Baselines erstellen?
Die operative Arbeit wird hier bei Product Ownern liegen. Hier kommt das bereits erwähnte administrative Backlog ins Spiel: Du musst die entsprechenden Tätigkeiten definieren, einplanen und monitoren. Vielleicht ist es einfacher für dich, das mit entsprechenden Quoten für bestimmte Themengebiete zu argumentieren (siehe Beschreibung von MAN.3).