FOCUS– BEST PRACTICES 14 / UdZ 01.22 Erstellung des Pflichtenheftes lassen sich User-Storys nutzen. In diesem Fall werden die User-Storys durch detaillierte Angaben des Anbieters ergänzt, die die Art und Weise der Umsetzung des Anbieters in der Business-Software-Lösung wiedergeben. Dabei gibt der Anbieter auch an, ob die entsprechende Anforderung im Standard oder ausschließlich über eine Anpassungsprogrammierung gelöst werden kann. Die User-Storys lassen sich außerdem als Ergänzung zu einem detaillierten Pflichtenheft auf Funktionsebene nutzen, um dem Anbieter einen besseren Einblick in die Kundenwünsche geben zu können. Ob man als Unternehmen ausschließlich User-Storys oder ein detailliertes Pflichtenheft auf Funktionsebene nutzt, müssen Unternehmen individuell entscheiden. In jedem Fall sollten Unternehmen nicht auf die gemeinsame und detaillierte Spezifikation der Anforderungen mit dem Anbieter vor der Unterschrift des Vertrags verzichten. User-Storys in Ausschreibungsprojekten anzuwenden und die Vorteile für sich nutzen zu können, bedarf einer Methodik-Schulung. Da die Formulierung von User-Storys für die Anwender:innen häufig Neuland ist, ist es hilfreich, Beispiel-User-Storys vorzustellen und zu diskutieren, um so die Anwender:innen an die Methodik heranzuführen. Besonderes Augenmerk sollte auf der Granularität der User-Storys liegen, um insgesamt ein einheitliches Level zu garantieren. Die geläufigen INVEST-Kriterien können zur Reflexion als Leitlinien bei der Erstellung dienen und erhöhen die Anforderungsqualität. INVEST fasst als Akronym An integration of user stories in tendering projects that provides real benefits requires methodology training. Since users are typically not familiar with creating user stories, it is beneficial to present and discuss sample user stories in order to introduce users to the approach. Particular attention should be paid to the degree of detail of the user stories to ensure consistency. The well-established INVEST criteria can be used as guidelines in the story creation process to improve the quality of the requirements definition. According to the INVEST acronym, user stories should be independent, negotiable, valuable, estimable, small, and testable. Figure 2 shows the advantages and disadvantages of traditional requirements specifications and “agile” user stories. As already argued above, the goal is not to apply one or the other method, but to achieve the best possible result by cleverly combining both. The disadvantages of the respective method must be addressed in the course of the project. The requirements elicitation process using a combination of user stories and a traditional approach has been tested and refined in several selection projects. It became clear that it is beneficial for sustainable documentation and efficient communication to assign user stories to the relevant order processing steps. This can be easily recorded with the help of user story cards, where stakeholders can specify the associated process step or process stage. This creates a process-related link between the user stories and order Software for Business Software for People „BEST OF BOTH WORLDS“ AGILE PROJECT MANAGEMENT ➖Disadvantage or Challenge ➕Advantage User Orientation➕ Stakeholder Competence➖ User Stories are Solution Neutral➕ Meeting the Granularity➖ Support Change Management ➕ Fulfillment by Providers ➖ Difficult to Assess siii ➖Requires System Knowledge ➕System Orientation ➖Very Complex to Implement ➕fully ➕Basis for Contract Design CLASSIC PROJECT MANAGEMENT HYBRID PROCESS Specifications User Stories ➖keine Nutzerorientierung Helps With User ➕ Acceptance Tests Figure 2: Comparison of traditional requirements specifications and “agile” user stories in the context of software selection
RkJQdWJsaXNoZXIy NzcyMw==