1. Organizational Aspects
1.1. Influence of Organizations on RE@Agile
1.1.1. Fokus von RE@Agile
1.1.1.1. Agile ist einfach in greenfield umgebungen wie startups, oder kleinen uternehmen anzuwenden. Es ist jedoch schwer Agile in grossen Unternehmen zu implmentieren, weil diese sich wie lebende Organismen verhalten und jeden "Eindringling" abwehren.
1.1.1.2. Agile ist ein Bereich der das komplette Business umfasst, der Fokus von RE@Agile liegt jedoch auf dem Bereich "(software) Entwicklung".
1.1.2. Organisational Change wird benötigt
1.1.2.1. Warum? :
1.1.2.1.1. Viele Scrum Implmeentierungen scheitern in der Software Entwicklung, weil der Rest der Organisation nicht in der Lage war sich so zu ändern um die Scrum Teams zu unterstützen.
1.1.2.1.2. Beispiele:
1.2. Agile Development in a non-Agile Environment
1.2.1. Interactions with Stakeholders outside the IT Organization
1.2.1.1. In Agile sthet der Kunde im Mittelpunkt der Produkt Entwicklung. Er muss also über die komplette Produktentwicklung eingebunden werden, dies ist Aufgabe des PO.
1.2.1.1.1. Wenn Kunde täglich erreichbar ist und eingebunden werden kann ist das optimal.
1.2.1.2. Es ist jedoch wichtig Faktoren zu erkennen die außerhalb der Kompetenz des Entwicklungsteams liegen und die direkte Kommunikation zwischen Kunden und Scrum Team verhindern. (z.B. geographische Verteilung, etc..).In diesem Fall muss eine effizientere Kundenkommunikation etabliert werden, wie z.B.
1.2.1.2.1. 1. wiederkehrende Einladung des Kunden nach vor Ort für Review und Planning Meetings
1.2.1.2.2. 2. Timeboxed intensive Sitzungen in einer frühen Phase mit den Ergebnissen festgehalten im Backlog
1.2.2. Product vs. Project Organization
1.2.2.1. Vergleich:
1.2.2.1.1. Traditionelle Software Projekte sind eher Projekt-orientiert
1.2.2.1.2. Agile Software Projekte sind eher Produkt-orientiert
1.2.2.2. Problematik aus der Verschiedenheit der Ansätze ist, dass zwar kann in traditionellen Projekten durchaus auch ein Produkt entwickelt werden, man sieht jedoch, dass die Unterschiede in der Terminologie und Betrachtungsweise beider Vorgehen, die Basis für Spannungen und Missverständnisse birgt.
1.2.2.2.1. Lösungsmöglichkeiten für die Problematik
1.2.3. The role of management in an Agile context
1.2.3.1. Disciplines and Teams:
1.2.3.1.1. Traditionell:
1.2.3.1.2. Agile:
1.2.3.2. IT Managers
1.2.3.2.1. Aufgabe:
1.2.3.3. Product Owner vs. Project Manager
1.2.3.3.1. Product Owner:
1.2.3.3.2. Project Manager
1.2.3.3.3. Ein agiler IT Manager muss klare Visionen für die Entwicklung setzen und eine klare Kommunikation der kulturellen Vorbedingungen durchführen.
1.2.3.4. Role of RE / RM:
1.2.3.4.1. Einordnung RE im Scrum Team:
1.3. Handling of complex problems by scaling (Motivation for scaling / Approaches for organizing teams / approches for organizing communication / Example Frameworks for Scaling / Impacts of Scaling)
1.3.1. Das ideal von Agile/Scrum:
1.3.1.1. Direkte, tägliche, nicht-hierarchische kommunikation
1.3.1.2. Kleine 5-11 mann teams
1.3.1.3. co-located team members
1.3.1.4. cross-funktional
1.3.2. Problem: In großen Unternehmen, kann jedoch das Ideal von Agile/Scrum aus unterschiedlichen Gründen nicht erfüllt werden:
1.3.2.1. Komplexe Probleme können stakeholder und wissen aus unterschiedlichen Bereichen des business erfordern, die nicht einfach von einem einzigen Team erfüllt werden können.
1.3.2.2. Komplexe Probleme könnten eine ganze menge an technischen Spezialisten und wissen erfordern das nicht einfach von einem einzigen Team erfüllt werden kann
1.3.2.3. Der Scope für ein betsimmtes Rollout datum ist durch ein einziges Team nicht machbar
1.3.2.4. Die Leute eines globalen Unternehmens könnten physikalisch weltweit verteilt sitzen
1.3.3. Lösung: Scaled Agile
1.3.3.1. Multiple Teams (meist Scrum) arbeiten zusammen an einem Produkt/Lösung und teilen ein gemeinsames Ziel.
1.3.3.2. Ziel:
1.3.3.2.1. Ziel ist es ein effektives Vorgehen zu schaffen, um komplexe Probleme zu lösen und dabei gleichzeitig so viele Vorteile von Agile wie möglich zu erhalten.
1.3.3.3. Hauptbestandteile
1.3.3.3.1. 1. Organisation von Scrum Teams
1.3.3.3.2. 2. Koordination der kommunikation zwischen den Teams
1.3.3.4. Beispiel Frameworks:
1.3.3.4.1. Scaled Agile Framework (SAFe)
1.3.3.4.2. Large-Scale Scrum (LeSS)
1.3.3.4.3. Nexus
1.3.3.4.4. Scrum@Scale
1.3.3.4.5. Disciplined Agile Delivery (DAD)
1.3.3.5. Impacts of Scaling
1.3.3.5.1. Im Falle von zusätzlichen Abstraktionsebenen zur Skalierung von Scrum ergeben sich für RE besondere Herausforderungen
1.3.3.5.2. Schlüsselfähigkeit der Kommunikationsfähigkeit eines RE/PO nimmt einen noch höheren Stellenwert ein
1.4. Balancing upfront and continious RE in the context of scaling
1.4.1. 5 Prozessschritte sind für RE bei Scaled Agile Vorgehen relevant (siehe Bild auf Seite 57)
1.4.1.1. 1. Initial Requirements Definition
1.4.1.1.1. Komplette upfront Definition der Reqs ist nicht erforderlich, es reicht für das erste Backlog als Baseline die Anzahl von Reqs aus, die notwendig sind, um die erste Iteration zu starten.
1.4.1.1.2. Hauptherausforderung:
1.4.1.1.3. Bestes RE Vorgehen:
1.4.1.2. 2. Level of Detail for Backlog Items
1.4.1.2.1. Das Detaillevel von Reqs schränkt den Lösungsraum für das Team ein.
1.4.1.2.2. Hohe Detaillevel:
1.4.1.2.3. Niedriges Detaillevel:
1.4.1.2.4. Bestes Vorgehen:
1.4.1.3. 3. Validity of Backlog Items
1.4.1.3.1. Validität hilft dabei unnötige Implementierungsarbeit zu verhindern
1.4.1.3.2. Die Validität eines BI kann nur festgestellt werden, wenn das BI genügend detailliert ist
1.4.1.4. 4. Feedback and Update of the Backlog
1.4.1.4.1. Faktoren die Einfluss auf die Modifikation des backlogs haben:
1.4.1.5. 5. Timing of the development cycle
1.4.1.5.1. RE kann nur an Items durchgeführt werden, die gerade nicht entwickelt werden
1.4.1.5.2. Länge der Iteration:
1.4.1.5.3. Entscheidung zur Iterationslänge sollte vom Team getroffen werden, basierend auf:
1.4.1.5.4. Änderung der Iterationslänge:
2. Inhalte die im RE Kurs fehlen:
2.1. Aus Kapitel 1 (Motivation und Mindset)
2.1.1. Brücke zwischen RE und Agile:
2.1.1.1. Abstraktion in der Software-Entwicklung:
2.1.1.1.1. 3 Ebenen:
2.1.1.1.2. 3 Prinzipien zur Unterscheidung der Ebenen:
2.1.1.2. im Vergleich von RE und Agile zeigt wieso beide manchmal als konfliktträchtig angesehen werden:
2.1.1.2.1. Hauptgedanken hinter RE und Agile
2.1.1.2.2. Die Übertriebene Befolgung beider Hauptgedanken in der Praxis führt zu einem Konflikt:
2.1.1.2.3. Der Konflikt ist jedoch nur SCHEINBAR:
2.1.1.3. Hauptunterschied RE und Agile / Andere Vorgehensweisen ist das Timing und der verwendete Prozess:
2.1.1.3.1. RE@Agile zeigt wie RE im Agilen Umfeld angewandt werden muss
2.1.1.3.2. Es wird der Begriff RE@Agile verwendet und nicht "Agiles Requirement Engineering" um klar zu machen, dass RE unabhängig vom Prozess ist
2.1.1.4. Annahme dass Agile Dokumentation komplett verbannt hat ist falsch:
2.1.1.4.1. Dokumentation ist immer noch willkommen, solange es die Entwicklung unterstützt oder Teil des Produktes ist.
2.1.2. RE@Agile und Conceptual Work:
2.1.2.1. Andere Gebiete (nicht Software) haben Vorgehensweisen für konzeptuelles Arbeiten entwickelt die ziemlich ähnlich zu Agile sind. Einige davon sind aus RE Sicht speziell sinnvoll um Innovationen und Produktvisionen zu entwickeln, diese werden hier kurz vorgestellt.
2.1.2.2. Alle 3 Techniken können innerhalb von Agile/Scrum integriert werden (eine oder mehrere Sprints z.b.) um z.b. bestimmte Aspekte eines Systems zu designen. Sie helfen dabei die limitierten Innovationstechniken von Agile zu beheben.
2.1.2.3. Innovationstechniken:
2.1.2.3.1. 1. Design Thinking
2.1.2.3.2. 2. Design Sprint
2.1.2.3.3. 3. Lean Startup
2.2. Aus Kapitel 2 (Fundamentals)
2.2.1. Unterschiede und Gemeinsamkeiten von Product Owner und RE
2.2.1.1. Schlüsselaktivitäten eines RE:
2.2.1.1.1. Requirements erheben
2.2.1.1.2. Requirements prüfen
2.2.1.1.3. Requirements dokumentieren
2.2.1.1.4. Requirements verwalten
2.2.1.2. Hauptverantwortung eines PO:
2.2.1.2.1. Sicherstellen, dass das Team permanent Business Value erzeugt
2.2.1.2.2. Stakeholder Management
2.2.1.2.3. Kontinuierliches Weiterleiten der am höchsten gerankten Backklog Items an das Team.
2.2.1.3. Schnittmenge:
2.2.1.3.1. Beide müssen die Schlüsselaktivitäten Erheben, prüfen, dokumentieren und verwalten durchführen.
2.2.1.4. Unterschiede (weniger formal):
2.2.1.4.1. Mehr Fokus auf aktuellen Zustand der Requirements, weniger Fokus auf Versionierung und Historie
2.2.1.4.2. Mehr Konversation und weniger schreiben
2.2.1.4.3. Story Cards statt Requirements Dokuments
2.2.1.4.4. Die Rolle eines PO ist breiter als die eines traditionellen RE da er die Gesamtverantwortung für das Produkt hat und für den Erfolg verantwortlich ist.
2.2.2. Value Driven Development und Simplicity as Essentiel Concept :
2.2.2.1. Ziel Agiler Methoden ist es kontinuierlich (Business) Value an den Kunden zu liefern.
2.2.2.2. Gute POs schaffen eine Balance aus Business Value und Risk Reduction
2.2.2.3. Zur Festlegung welche Requirements zum optimalen Value führen dienen:
2.2.2.3.1. MVP
2.2.2.3.2. MMP
2.2.2.4. 2 Arten von Value:
2.2.2.4.1. 1. Business Value
2.2.2.4.2. 2. Risk Reduction als Value
2.2.2.5. Einfachheit:
2.2.2.5.1. Einfachheit ist das Gegenteil von Perfektion, bedeutet jedoch nicht schlechte Qualität sondern minimaler Scope.
2.2.2.5.2. Prozess der Einfachheit:
2.2.2.6. Der Inspect und Adapt Zyklus von Scrum durch Retrospektive und Review meetings sollte auch für das RE angewendet werden.
2.3. Aus Kapitel 3 (Artifacts and Techniques)
2.3.1. Alle 4 Hauptaktivitäten des RE (Elicitation, Documentation, Validation, Management) müssen auch weiterhin im Agilen Umfeld durchgeführt werden
2.3.2. Artifakte:
2.3.2.1. Requirements Arten im Agilen Umfeld:
2.3.2.1.1. Funktional:
2.3.2.1.2. Qualität:
2.3.2.1.3. Constraint:
2.3.3. Techniken:
2.3.3.1. Documentation
2.3.3.1.1. Organisiert in Backlogs:
2.3.3.1.2. Der Fomalismus der Dokumentation kann minimiert werden, wenn Details verbal kommuniziert werden
2.3.3.1.3. Grad an Dokumentation hängt ab von:
2.3.3.1.4. 4 Typen von Dokumentation:
2.3.4. Summary Vorgehen:
2.3.4.1. Good Practice :
2.3.4.1.1. RE anfangen mit:
2.4. Aus Kapitel 4 (Organisatorisches)
2.4.1. Influence of Organizations on RE@Agile
2.4.1.1. Fokus von RE@Agile
2.4.1.1.1. Agile ist einfach in greenfield umgebungen wie startups, oder kleinen uternehmen anzuwenden. Es ist jedoch schwer Agile in grossen Unternehmen zu implmentieren, weil diese sich wie lebende Organismen verhalten und jeden "Eindringling" abwehren.
2.4.1.1.2. Agile ist ein Bereich der das komplette Business umfasst, der Fokus von RE@Agile liegt jedoch auf dem Bereich "(software) Entwicklung".
2.4.1.2. Organisational Change wird benötigt
2.4.1.2.1. Warum? :
2.4.2. Agile Development in a non-Agile Environment
2.4.2.1. Interactions with Stakeholders outside the IT Organization
2.4.2.1.1. In Agile sthet der Kunde im Mittelpunkt der Produkt Entwicklung. Er muss also über die komplette Produktentwicklung eingebunden werden, dies ist Aufgabe des PO.
2.4.2.1.2. Es ist jedoch wichtig Faktoren zu erkennen die außerhalb der Kompetenz des Entwicklungsteams liegen und die direkte Kommunikation zwischen Kunden und Scrum Team verhindern. (z.B. geographische Verteilung, etc..).In diesem Fall muss eine effizientere Kundenkommunikation etabliert werden, wie z.B.
2.4.2.2. Product vs. Project Organization
2.4.2.2.1. Vergleich:
2.4.2.2.2. Problematik aus der Verschiedenheit der Ansätze ist, dass zwar kann in traditionellen Projekten durchaus auch ein Produkt entwickelt werden, man sieht jedoch, dass die Unterschiede in der Terminologie und Betrachtungsweise beider Vorgehen, die Basis für Spannungen und Missverständnisse birgt.
2.4.2.3. The role of management in an Agile context
2.4.2.3.1. Disciplines and Teams:
2.4.2.3.2. IT Managers
2.4.2.3.3. Product Owner vs. Project Manager
2.4.2.3.4. Role of RE / RM:
2.4.3. Handling of complex problems by scaling (Motivation for scaling / Approaches for organizing teams / approches for organizing communication / Example Frameworks for Scaling / Impacts of Scaling)
2.4.3.1. Das ideal von Agile/Scrum:
2.4.3.1.1. Direkte, tägliche, nicht-hierarchische kommunikation
2.4.3.1.2. Kleine 5-11 mann teams
2.4.3.1.3. co-located team members
2.4.3.1.4. cross-funktional
2.4.3.2. Problem: In großen Unternehmen, kann jedoch das Ideal von Agile/Scrum aus unterschiedlichen Gründen nicht erfüllt werden:
2.4.3.2.1. Komplexe Probleme können stakeholder und wissen aus unterschiedlichen Bereichen des business erfordern, die nicht einfach von einem einzigen Team erfüllt werden können.
2.4.3.2.2. Komplexe Probleme könnten eine ganze menge an technischen Spezialisten und wissen erfordern das nicht einfach von einem einzigen Team erfüllt werden kann
2.4.3.2.3. Der Scope für ein betsimmtes Rollout datum ist durch ein einziges Team nicht machbar
2.4.3.2.4. Die Leute eines globalen Unternehmens könnten physikalisch weltweit verteilt sitzen
2.4.3.3. Lösung: Scaled Agile
2.4.3.3.1. Multiple Teams (meist Scrum) arbeiten zusammen an einem Produkt/Lösung und teilen ein gemeinsames Ziel.
2.4.3.3.2. Ziel:
2.4.3.3.3. Hauptbestandteile
2.4.3.3.4. Beispiel Frameworks:
2.4.3.3.5. Impacts of Scaling
2.4.4. Balancing upfront and continious RE in the context of scaling
2.4.4.1. 5 Prozessschritte sind für RE bei Scaled Agile Vorgehen relevant (siehe Bild auf Seite 57)
2.4.4.1.1. 1. Initial Requirements Definition
2.4.4.1.2. 2. Level of Detail for Backlog Items
2.4.4.1.3. 3. Validity of Backlog Items
2.4.4.1.4. 4. Feedback and Update of the Backlog
2.4.4.1.5. 5. Timing of the development cycle
3. Motivation and Mindset
3.1. Motivation:
3.1.1. IT und business werden immer schnelllebiger und traditionelle Wasserfall Methoden wurden für schnelle und ständige Änderungen der Requirements nicht entwickelt.
3.1.2. Wenn der Markt oder das Projekt schnelle und umfassende Änderungen benötigen, sind agile Methoden passend.
3.2. Mindset and Values:
3.2.1. Wenn man die Werte und Mindsets von RE (IREB) und Agile vergleicht, stellt man fest, dass diese sich nicht widersprechen.
3.2.2. Der wichtigste Wert von RE UND Agile ist es den Enduser glücklich zu machen und wird damit von beiden geteilt.
3.2.3. Einige Werte und Mindsetse von RE und Agile sind jedoch disjunkt -> Die Schnittmenge definiert jedoch RE@Agile Primer
3.3. Brücke zwischen RE und Agile:
3.3.1. Abstraktion in der Software-Entwicklung:
3.3.1.1. 3 Ebenen:
3.3.1.1.1. 1. Principles
3.3.1.1.2. 2. Practices
3.3.1.1.3. 3. Activities
3.3.1.2. 3 Prinzipien zur Unterscheidung der Ebenen:
3.3.1.2.1. Prescriptive
3.3.1.2.2. Abstrakt
3.3.1.2.3. Falsifiable
3.3.2. im Vergleich von RE und Agile zeigt wieso beide manchmal als konfliktträchtig angesehen werden:
3.3.2.1. Hauptgedanken hinter RE und Agile
3.3.2.1.1. RE: Bei RE geht es um die systematische Erhebung und Dokumentation von Requirements als eigentständinge Artifakte
3.3.2.1.2. Agile: Agile dagegen hebt die Wichtigkeit von Funktionierender Software anstatt umfassender Dokumentation hervor und schätzt Individuen und Werte höher als Tools und Prozesse
3.3.2.2. Die Übertriebene Befolgung beider Hauptgedanken in der Praxis führt zu einem Konflikt:
3.3.2.2.1. eine falsche Annahme bzgl. RE ist es zu glauben, man könnte ein komlpett umfassendes, konsistens und abgestimmtes RE Dokument erzuegen, das implementiert werden kann ohne weitere Änderungen.
3.3.2.2.2. eine ebenso falsche Annahme von Agile ist es anzunehmen, dass ein Entwicklungsprojekt ohne jede Vorbereitung starten kann und erfolgreich sein kann, nur durch das Liefern von Software in regulären Intervallen, die durch die Stakeholer reviewed und gefeedbacked wird.
3.3.2.3. Der Konflikt ist jedoch nur SCHEINBAR:
3.3.2.3.1. RE und Agile verfolgen das selbe Ziel: Die Lieferung funktionierender Software in hoher Qualität.
3.3.2.3.2. Agile kann funktioneirende Software auf effiziente und schnelle Weise liefern und RE unterstützt dabei indem es die passenden Techniken zur Verfügung stelle, um die Wünsche und Bedürfnisse der Stakeholder zu verstehen.
3.3.3. Hauptunterschied RE und Agile / Andere Vorgehensweisen ist das Timing und der verwendete Prozess:
3.3.3.1. RE@Agile zeigt wie RE im Agilen Umfeld angewandt werden muss
3.3.3.2. Es wird der Begriff RE@Agile verwendet und nicht "Agiles Requirement Engineering" um klar zu machen, dass RE unabhängig vom Prozess ist
3.3.4. Annahme dass Agile Dokumentation komplett verbannt hat ist falsch:
3.3.4.1. Dokumentation ist immer noch willkommen, solange es die Entwicklung unterstützt oder Teil des Produktes ist.
3.4. Benefits von RE@Agile:
3.4.1. 1. RE und Dev kompetenz im selben Team kann Handovers reduzieren
3.4.2. 2. inkrementelle Entwicklung erlaubt die Optimierung existierender Ideen.
3.4.3. 3. Backlog Refinement ist ein Principle zum Weiterentwickeln und Verifizieren von Requirements
3.4.4. 4. RE hilft dabei ein initiales Product Backlog zu erzeugen
3.5. Misconceptions von RE@Agile:
3.5.1. Falsch: 1. RE ist lediglich eine vorgelagerte analyse
3.5.1.1. RE ist prozessunabhängig und kann in allen Phasen eines Prozesses eingesetzt werden
3.5.2. Falsch: 2. Vorgelagert ist immer böse
3.5.2.1. Vorausgelagertes Denken wird auch von Agile nicht per se als schlecht angesehen. Wie und Wann vorausgelagertes Denken notwendig ist wird durch den Projektkontext bestimmt.
3.5.3. Falsch: 3. RE ist äquivalent zu Dokumentation
3.5.4. Falsch: 4. User Stories sind genug
3.5.4.1. 3 Cs
3.5.5. Falsch: 5. Dokumentation ist sinnlos, nur Code nachhaltigen hat Wert.
3.5.5.1. Projekt und Produktkontext beachten
3.5.6. Falsch: 6. Funktionierende Software ist die einzige Möglichkeit Requirements zu validieren
3.6. Pitfalls von RE@Agile:
3.6.1. Pitfall: 1. Requirements als uniformen Typ information betrachten
3.6.1.1. Requirements können in unterschiedlichem Detail level, abstraktionsgrad und Format existieren werden.
3.6.1.2. Beispiel: Produkt vision ist hoher Abstraktionsgrad und langlebig während ein kleiner Prototyp sehr geringe Abstraktion hat und kurzlebig ist
3.6.2. Pitfall: 2. das große Ganze aus den Augen verlieren
3.6.2.1. Wenn jeder nur auf den aktuellen Sprint fokussiert geht das große Ganze und die Vision verloren.
3.6.3. Pitfall: 3. Stakeholder mit Informationen überfrachten
3.6.4. Pitfall: 4. Jedes Thema auf inkrementelle und iterative Weise lösen
3.6.4.1. Nicht jedes Requirement Thema eines Systems sollte inkrementell entwickelt werden.
3.6.4.2. Themen mit additiver Komplexität sind optimal für inkrementelle Entwicklung geeignet. (z.b. Kaufprozess in einem Online Shop)
3.6.4.3. Themen mit voller kompletter komplexität sind nicht geeignet für inkrementelle Entwicklung da jedes neue Einsicht in ein Thema zu einem komplett neuen Verständnis führt. (Beispiel Berechnungen mit komplexen Eingabeparametern und simplen Ausgabeparametern, wie Versicherungspolicen)
3.6.5. Pitfall: 5. Inkrementelle Entwicklung kann unter umständen keine radikale oder disruptive innovation ermöglichen
3.6.5.1. Grund: Ein gegebenes Artifakt typischerweise nur lokal verbessert wird (bugfixing, hinzufügen fehlender Elemente)
3.6.5.2. Obwohl Agile Veränderung willkommen heißt unterstützt der inkrementelle Prozess von Agile typischerweise nur kontinuierliche innovation.
3.6.5.3. Radikale oder disruptive Innovation entsteht durch die Betrachtung vieler ideen und die rekombination existierender Ideen. => Das Entwickeln alternativer Ideen in Bezug auf Software wird typischer Weise als Verschendung in Agilen Umgebungen betrachtet.
3.6.5.4. Um also Radikale oder disruptive Innovation entstehen zu lassen, müssen practices angewandt werden (z.b. Lean Startup Ideas oder Design Thinking)
3.6.6. Pitfall: 6. Agile und kulturelle Veränderung gehen nicht hand in hand
3.7. RE@Agile und Conceptual Work:
3.7.1. Andere Gebiete (nicht Software) haben Vorgehensweisen für konzeptuelles Arbeiten entwickelt die ziemlich ähnlich zu Agile sind. Einige davon sind aus RE Sicht speziell sinnvoll um Innovationen und Produktvisionen zu entwickeln, diese werden hier kurz vorgestellt.
3.7.2. Alle 3 Techniken können innerhalb von Agile/Scrum integriert werden (eine oder mehrere Sprints z.b.) um z.b. bestimmte Aspekte eines Systems zu designen. Sie helfen dabei die limitierten Innovationstechniken von Agile zu beheben.
3.7.3. Innovationstechniken:
3.7.3.1. 1. Design Thinking
3.7.3.1.1. Eine Methode um sogenannte "Wicked" probleme zu lösen (z.b. wöchentlich definiert). Mischung aus Erhebungs- und Validierungstechnik
3.7.3.1.2. Kann über wenige Tage bis hin zu mehrern Wochen durchgeführt werden.
3.7.3.1.3. Der Prozess ist nicht strikt sequentiell -> Team kann entscheiden zu springen
3.7.3.1.4. Ergebnis ist eine Menge von prototypen, die validierte und innovative Lösungen für ein Problem darstellen.
3.7.3.1.5. Bestandteile:
3.7.3.2. 2. Design Sprint
3.7.3.2.1. 5 tägiger Prozess um Ideen zu entwickeln basierend auf Design, Prototyping und Testen mit dem Endkunden
3.7.3.2.2. RE relevant hier: Erhebungs und Validierungstechniken.
3.7.3.2.3. Jeder der 5 Tage wird einer der folgenden Tätigkeiten gewidmet:
3.7.3.2.4. Wichtiger Unterschied zu Agile:
3.7.3.3. 3. Lean Startup
3.7.3.3.1. Vorgehen um Geschäfte zu entwickeln und startups zu managen
3.7.3.3.2. RE relevant (Kombination aus Erhebungs und Validierungstechniken):
4. Fundamentals
4.1. Agile Methodes:
4.1.1. Crystal
4.1.1.1. Jedes Projekt soll sein eigenes zurechtgeschnittenes Prozessmodell haben
4.1.2. Lean Development und Kanban
4.1.3. Scrum
4.1.4. TDD
4.1.4.1. Test First
4.1.5. xP
4.1.5.1. Direkte Kommunikation zwischen Kunde und Programmierer
4.2. Scrum:
4.2.1. Obwohl Scrum nicht mit RE Techniken kommt, hat die Agile Community einige Good Practices dazu entwickelt
4.2.2. Good Practices:
4.2.2.1. Backlog Item:
4.2.2.1.1. Begriff für die Items des Product Backlogs
4.2.2.1.2. Generische Bezeichnung für jedwede Art von Information bzgl. des zu entwickelnden Produkts
4.2.2.1.3. Viele Backlog Items sind Requirements oder können zu requirements verfeinert werden
4.2.2.2. Requirements handling:
4.2.2.2.1. Requirements herunterbrechen zu:
4.2.2.2.2. Unterscheidung zwischen:
4.2.2.2.3. Gruppierung durch:
4.2.2.3. DEEP Product Backlog:
4.2.2.3.1. Detailed appropriately
4.2.2.3.2. Estimated
4.2.2.3.3. Emergent
4.2.2.3.4. Prioritized
4.2.2.4. INVEST Kriterium für Backlog Items:
4.2.2.4.1. Independent of each other
4.2.2.4.2. Negotiable
4.2.2.4.3. Valueable
4.2.2.4.4. Estimateable
4.2.2.4.5. Small enough to fit into one sprint
4.2.2.4.6. Testable
4.3. Unterschiede und Gemeinsamkeiten von Product Owner und RE
4.3.1. Schlüsselaktivitäten eines RE:
4.3.1.1. Requirements erheben
4.3.1.2. Requirements prüfen
4.3.1.3. Requirements dokumentieren
4.3.1.4. Requirements verwalten
4.3.2. Hauptverantwortung eines PO:
4.3.2.1. Sicherstellen, dass das Team permanent Business Value erzeugt
4.3.2.2. Stakeholder Management
4.3.2.3. Kontinuierliches Weiterleiten der am höchsten gerankten Backklog Items an das Team.
4.3.3. Schnittmenge:
4.3.3.1. Beide müssen die Schlüsselaktivitäten Erheben, prüfen, dokumentieren und verwalten durchführen.
4.3.4. Unterschiede (weniger formal):
4.3.4.1. Mehr Fokus auf aktuellen Zustand der Requirements, weniger Fokus auf Versionierung und Historie
4.3.4.2. Mehr Konversation und weniger schreiben
4.3.4.3. Story Cards statt Requirements Dokuments
4.3.4.4. Die Rolle eines PO ist breiter als die eines traditionellen RE da er die Gesamtverantwortung für das Produkt hat und für den Erfolg verantwortlich ist.
4.4. RE als kontinuierlicher Prozess:
4.4.1. RE in Agile ist keine separate Phase sondern ein kontinuierlicher prozess
4.4.2. Requirements und Product werden beide iterativ und inkrementell entwickelt
4.4.3. Die bekannten Requirements mit dem höchsten Business Value sollten als erstes "Ready for Implementation" sein
4.4.4. die weniger wichtigen Requirements in Bezug auf den Business Value werden erst verfeinert, wenn die wichtigen fertig sind
4.4.5. Obwohl die Requirements auf einer "need-to-know" basis verfeinert werden, gibt es einige Aspekte in Bezug auf Requirements die Vorgelagert geklärt werden sollten.
4.4.5.1. Beispiele:
4.4.5.1.1. Vision und Ziele
4.4.5.1.2. Stakeholder Analyse
4.4.5.1.3. Prodcut Scope
4.5. Value Driven Development und Simplicity as Essentiel Concept :
4.5.1. Ziel Agiler Methoden ist es kontinuierlich (Business) Value an den Kunden zu liefern.
4.5.2. Gute POs schaffen eine Balance aus Business Value und Risk Reduction
4.5.3. Zur Festlegung welche Requirements zum optimalen Value führen dienen:
4.5.3.1. MVP
4.5.3.1.1. minimum viable product
4.5.3.1.2. Kleinstes Produkt das ein End User Experience erzeugen kann und somit Feedback ans Team zurückliefert
4.5.3.2. MMP
4.5.3.2.1. Minimum Marketable Product
4.5.3.2.2. ziel ist es nicht nur frühes Feedback zu liefern und so die nächsten Requirements Steps zu definieren, sondern auch sofort wert zu erzeugen.
4.5.3.2.3. Ziel ist es bereits Cash Flow zu erzeugen und damit dann das Produkt kontinuierlich zu verbessern
4.5.4. 2 Arten von Value:
4.5.4.1. 1. Business Value
4.5.4.1.1. Oft kann Business Value für Profitorientierte Organisationen direkt adressiert werden:
4.5.4.1.2. Non-Profit Organisationen:
4.5.4.2. 2. Risk Reduction als Value
4.5.4.2.1. z.B. durch Informationsgewinn in einem Sprint
4.5.5. Einfachheit:
4.5.5.1. Einfachheit ist das Gegenteil von Perfektion, bedeutet jedoch nicht schlechte Qualität sondern minimaler Scope.
4.5.5.2. Prozess der Einfachheit:
4.5.5.2.1. 1. Eine einfache und potenitell inkomplette Antwort auf ein Problem zu erzeugen und so ein kleines Inkrement an Wert zu erzielen
4.5.5.2.2. 2. Die Möglichkeit gewinnen mehr über den Kontext zu lernen, basierend auf Erkenntnissen aus der echten Welt
4.5.5.2.3. 3. Adaptieren und Iterieren der Wert Erzeugung und Lieferung in einer gleichbleibenden Geschwindigkeit
4.5.5.2.4. 4. Ressourcen von nicht-profitablen Ideen einsparen und diese dafür neuen Ideen zuwenden -> Fail Fast
4.5.6. Der Inspect und Adapt Zyklus von Scrum durch Retrospektive und Review meetings sollte auch für das RE angewendet werden.
5. Artifacts and Techniques
5.1. Artefakte:
5.1.1. Spezifikationen vs. Product Backlog
5.1.1.1. Klassische Vorgehen:
5.1.1.1.1. Requirements werden in Spezifikationsdokumenten gesammelt
5.1.1.2. Agile Vorgehen:
5.1.1.2.1. Requirements werden im Product Backlog gesammelt
5.1.1.3. Unabhängig vom Namen der Requirements Sammlung sollten jedoch bestimmte Elemente auf jeden Fall erfasst werden:
5.1.1.3.1. Vision und Ziele
5.1.1.3.2. Funktionale Reqs
5.1.1.3.3. Nicht funktionale Reqs
5.1.1.3.4. Constraints
5.1.1.3.5. Glossar
5.1.1.4. Die rein mündliche Erfassung von Requirements ist nicht ausreichend.
5.1.2. Vision and Goals
5.1.2.1. Jedes Vorgehen sollte durch Visionen und Ziele geleitet werden
5.1.2.1.1. Diese Definieren die Produkt-Fähigkeiten, die bei Implementation das Produkt als erfolgreich betrachten lassen.
5.1.2.1.2. Jedes Requirement muss hinsichtlich der Ziele geprüft werden -> falls es keinem dient dann indikator dafür dass es keinen Business Value erzeugt
5.1.2.2. Agile "Product Vision":
5.1.2.2.1. Soll sicherstellen, dass jedes Ergebnis des Entwicklungsprozesses einen eigenen Business Value dazu beiträgt
5.1.2.3. Unterschiedliche Ziele der Stakeholder:
5.1.2.3.1. Meist sind die Ziele der Stakeholder unterschiedlich, und deshalb ist es wichtig dass sich die Stakeholder auf eine Gemeinsame Vision oder gemeinsame Ziele einigen.
5.1.2.3.2. Wenn dies nciht möglihc ist, dann ist das ein Signal dafür, dass unterschiedliche Varianten des Produktes erforderlich sind wie z.b. kleines und grosses iPhone oder gar komplett unterschiedliche Produkte wie iPhone und iPad.
5.1.2.4. Granularität der Ziele:
5.1.2.4.1. Unterscheidet sich im Agilen Umfeld meist bzgl. des Zeitraums
5.1.3. Context Model
5.1.3.1. Beschreiben die Eigenschaften der Umgebung (context) in der das System oder Produkt betrieben wird.
5.1.3.2. Nutzen:
5.1.3.2.1. Strukturierter Weg um relevante Annahmen bzgl. der Umgebung zu dokumentieren
5.1.3.2.2. Wichtig um ein gemeinsames Verständnis der Umgebung zwischen allen Stakeholdern zu schaffne
5.1.3.2.3. können dazu verwendet werden die externen schnittstellen des zu entwickelnden Produkts oder Systems zu spezifizieren
5.1.3.2.4. Schränkt den Raum ein, in dem Analysten freie Entscheidungen treffen können während die externen Schnittstellen mit den Umsystemen ausgehandelt werdne müsesn.
5.1.3.3. Techniken:
5.1.3.3.1. Context Diagramme
5.1.3.3.2. Use Case Diagramme
5.1.3.3.3. SysML Block Definition Diagramme
5.1.3.3.4. UML komponenten Diagramme
5.1.3.3.5. UML Klassendiagramme
5.1.3.3.6. Jede beliebige andere Notation, solange sie klar unterscheidet zwischen dem System/Produkt und externen Schnittstellen zu Personen und Systemen der Umgebung
5.1.4. Requirements, Granularität, Graphische Beschreibung und Textuelle Modelle, Quality Requirements and Constraints:
5.1.4.1. Requirements Werden erfasst basierend auf der Vision und den Zielen und der Beschränkung durch das Context Model.
5.1.4.2. Granularität von Requirements:
5.1.4.2.1. Stakeholder kommunizieren ihre Bedürfnisse meist in Levels unterschiedlicher Granularität (z.B. grob in Business Ziele und fein in Produktdetails.)
5.1.4.2.2. Funktionale und Qualitäts Requirements sollten daher auf unterschiedlicher Abstraktionsebene diskutiert und dokumentiert werden.
5.1.4.2.3. Siehe Bild auf Seite 37
5.1.4.2.4. Top-Down vs. Bottom-Up:
5.1.4.3. Notation von Requirements:
5.1.4.3.1. Textuell:
5.1.4.3.2. Graphisch:
5.1.4.3.3. Die Auswahl sollte basierend auf den Hauptzielen des RE erfolgen (siehe geeignet für)
5.1.4.4. Arten:
5.1.4.4.1. Funktional:
5.1.4.4.2. Qualität:
5.1.4.4.3. Constraint:
5.1.5. Definition of Ready and Done
5.1.5.1. Definition of Ready:
5.1.5.1.1. Zur Qualitätssicherung der Requirements
5.1.5.1.2. Good Practice
5.1.5.2. Definition of Done:
5.1.5.2.1. Zur Qualitätssicherung des Produktinkrements
5.1.5.2.2. Offiziell im Scrum Guide
5.1.6. Prototype vs. Increments
5.1.6.1. Um sofort die bedürfnisse der stakeholder zu verstehen und feedback zu bekommen.
5.1.6.2. Eine Möglihckeit dies zu machen ist durch minimale Produktinkremente
5.1.6.3. Agile Methoden versuchen "Wegwerf"-Prototypen zu verhindern, indem sofort hochqualitative inkremente des richtigen Systems erzeugt werdne.
5.1.6.4. RM schlägt 2 Typen vor:
5.1.6.4.1. Horizontale Produktinkremente
5.1.6.4.2. Vertikale Produktinkremente:
5.1.6.5. Spike:
5.1.6.5.1. Eine Entwicklungsiteration mit dem expliziten Grund einen bestimmten Bereich der Komplexität besser zu verstehen und so das Risiko zu reduzieren.
5.1.6.5.2. Prototyping ist eine valide Technik hierfür
5.1.7. Summary
5.1.7.1. Good Practice :
5.1.7.1.1. RE anfangen mit:
5.2. Techniques:
5.2.1. Elicitation
5.2.1.1. RE wird in Agile traditionell so durchgeführt:
5.2.1.1.1. intensive kommunikation zwischen Stakeholdern um REs zu erheben
5.2.1.1.2. Kann als Mix aus Interviews und Brainstorming Technik angesehen werden
5.2.1.1.3. Zusätzlich xP On Site customer etc...
5.2.1.1.4. weitere möglihckeiten:
5.2.1.2. RE Allgemein:
5.2.1.2.1. RE allgemein hat jedohc eine viel grössere Bandbreite an Techniken anzubieten
5.2.1.2.2. Beispiele:
5.2.1.2.3. RE im agilen Umfeld kann stark von non-agilem RE profitieren, indem die dort beschriebenen Techniken ausgewählt und angewendet werden.
5.2.2. Documentation
5.2.2.1. Organisiert in Backlogs:
5.2.2.1.1. Product Backlog
5.2.2.1.2. Sprint Backlog
5.2.2.2. Der Fomalismus der Dokumentation kann minimiert werden, wenn Details verbal kommuniziert werden
5.2.2.3. Grad an Dokumentation hängt ab von:
5.2.2.3.1. Projektgrösse
5.2.2.3.2. Anzahl Stakeholder
5.2.2.3.3. Rechtlichen Bedingungen
5.2.2.3.4. Sicherheitskritikalität
5.2.2.4. 4 Typen von Dokumentation:
5.2.2.4.1. 1. Rechtliche Dokumentation
5.2.2.4.2. 2. Dokumentation für Aufbewahrungszwecke
5.2.2.4.3. 3. Dokumentation für kommunikationszwecke
5.2.2.4.4. 4. Dokumentation für Denkzwecke
5.2.3. Validation and Negotiation
5.2.3.1. Validierung erfolgt durch frühes und häufiges Feedback auf Product Inkrements
5.2.3.1.1. eine Gute möglichkeit dies zu unterstützen sind automatische Regressionstests
5.2.3.2. Ziel der Validierung:
5.2.3.2.1. Fehlende RE identifizieren
5.2.3.2.2. Inkonsistente RE aufdecken
5.2.3.2.3. Falsche RE identifzieren
5.2.3.2.4. konfliktäre REs identifizieren
5.2.3.3. Ziel Negotiation:
5.2.3.3.1. Anwendung von Verhandlungs und konfliktlösungstechniken um bei Validierung aufgedeckte REs aufzulösen
5.2.3.4. Backlog Refinement:
5.2.3.4.1. Neben den fortlaufenden und anhaltenden Validierungen und Verhandlungen bzgl. des Product backlog kann in den Backlog refinement meetings auch folgende Techniken angewendet werden:
5.2.4. Management
5.2.4.1. Backlog
5.2.4.1.1. Das Hauptinstrument zur Verwaltung von REs in Agile sind ein oder mehr Backlogs
5.2.4.1.2. Im Unterschied zu klassischem RE sind Backlogs so designed nur die aktuellste und beste Version der Requirements zu beinhalten, die noch implementiert werden müssen.
5.2.4.1.3. Backlog Items werden typischerweise gelöscht sobald es implementiert ist
5.2.4.1.4. RE management Aktivitäten in Backlog:
5.2.4.2. Historisierung:
5.2.4.2.1. Kann auch in Agile gemacht werden, findet jedoch nicht im Backlog statt
5.2.4.3. Festlegung der optimalen RE management techniken:
5.2.4.3.1. Balance finden zwischen Overhead Minimierung (was eine schnelle Lieferung einer funktionierenden Lösung erlaubt) und langristigen Zielen der Organisation (rechtliches, compliance documetation etc...)
5.2.5. Conclusion
5.2.5.1. Alle 4 Hauptaktivitäten des RE (Elicitation, Documentation, Validation, Management) müssen auch weiterhin im Agilen Umfeld durchgeführt werden