Product Backlog im Scrum Guide
Strikt sortiert, das Wichtigste steht oben.
Wie beschreibt das Software Engineering (SE) die “frühe Phase” und was ist dabei ein wesentliches Merkmal?
Aus Sicht des Software Engineering ist die “frühe Phase” eine realistischere Beschreibung des Projektstarts.
Sie wird als eine “Ballung” von eng miteinander verknüpften Aktivitäten gesehen:
- Handlungen (Actions)
- Kommunikation
- Verständnisaufbau
- Lernen
Entscheidungsfindung
Wesentliches Merkmal: Diese gesamte Phase ist unabhängig von einem spezifischen Softwareprozessmodell (wie Scrum, Wasserfall etc.). Sie findet statt, bevor man sich auf ein Vorgehensmodell festlegt oder parallel zur Auswahl.
Was ist die “frühe Phase” (Early Phase) eines Softwareprojekts und welche Kernaktivitäten finden hier statt?
Die frühe Phase ist die grundlegende Planungs- und Analysephase zu Beginn eines Projekts, in der die Basis für die gesamte nachfolgende Entwicklung gelegt wird.
Kernaktivitäten:
- Verständnis der Domäne: Den fachlichen Kontext und das Problemfeld verstehen.
- Definition der Anforderungen: Festlegen, was das System genau tun soll.
- Erste Designentscheidungen: Die grobe Software-Architektur entwerfen.
- Kostenschätzung: Den voraussichtlichen finanziellen Aufwand ermitteln.
- Projektplanung: Den Ablauf, die Zeit und die benötigten Ressourcen planen.
Wie lassen sich die Aktivitäten der “frühen Phase” im V-Modell wiederfinden?
Die Aktivitäten der “frühen Phase” bilden die Grundlage für den linken Ast des V-Modells und werden dort konkretisiert.
Entscheidung zum Projektstart: Findet statt, bevor das V-Modell formal beginnt.
Domänen-Erkundung: Ist Teil der Anforderungsanalyse (oberste Phase links).
Anforderungsdefinition: Ist die Kernaufgabe der Phase Anforderungsanalyse.
Erste Designentscheidungen: Entsprechen der Architektur- bzw. Systemdesign-Phase.
Artefakte: Die Ergebnisse (z.B. Anforderungs- und Architekturdokumente) sind die festgeschriebenen Artefakte dieser frühen Phasen im V-Modell.
Welche Nachteile und strengen Konsequenzen ergeben sich, wenn man die “frühe Phase” starr nach dem V-Modell abbildet?
Die starre Struktur des V-Modells führt zu erheblichen Nachteilen in der frühen, unsicheren Projektphase:
Später Start: Das V-Modell beginnt formal erst nach der Projektentscheidung.
Hohes Risiko: Ein einmal gestartetes Projekt ist nur kompliziert und teuer abzubrechen.
Ungenaue Schätzung: Die Kostenschätzung muss vor der detaillierten Anforderungsanalyse erfolgen.
Strikte Trennung: Anforderungen und Design sind in komplett getrennten Phasen, was eine gegenseitige Anpassung verhindert (keine Optimierung möglich).
Inflexibilität: Anforderungen sind nach ihrer Definitionsphase “eingefroren” und können nicht mehr geändert werden.
Vorzeitige Festlegung: Anforderungen können das Design zu früh einschränken (z.B. durch die Vorgabe von Programmiersprachen).
Wie geht das agile Framework Scrum mit den Aufgaben der “frühen Phase” um?
Scrum integriert die Aktivitäten der frühen Phase in seinen kontinuierlichen und flexiblen Prozess, anstatt sie vorab starr festzulegen.
Product Backlog: Anforderungen und Design-Entscheidungen sind keine abgeschlossenen Phasen, sondern Einträge im Product Backlog, die ständig neu priorisiert werden können.
Kollaboration: Die Domänen-Analyse geschieht fortlaufend in enger Zusammenarbeit mit dem Auftraggeber (Product Owner).
Anpassungsfähigkeit: Das Backlog wird in jeder Iteration (Sprint) überprüft, geändert und aktualisiert. So wird sichergestellt, dass es immer aktuell bleibt.
Herausforderung: Scrum definiert nicht genau, wie man zum initialen (ersten) Product Backlog kommt, bevor der erste Sprint startet.
Was charakterisiert die Definition der “frühen Phase” (Early Phase) eines Projekts?
Die “frühe Phase” hat keine exakte, formale Definition.
Ihre Merkmale sind:
Nicht klar abgegrenzt: Der genaue Anfang und das Ende der Phase sind nicht eindeutig festgelegt.
Erfahrungsbasiert: Das Konzept dieser Phase und ihr Management basieren auf praktischen Erfahrungen aus vielen vergangenen Projekten, nicht auf einer starren Theorie.
Welche Nachteile oder Risiken birgt der flexible Umgang von Scrum mit der “frühen Phase”?
Die hohe Flexibilität von Scrum kann in der frühen Phase zu spezifischen Problemen führen:
“Magisches” Backlog: Es ist unklar, wie das erste Product Backlog entsteht; es scheint oft einfach “magisch” aufzutauchen.
Architektur-Risiko: Ein fehlendes initiales Design kann zu einer schlechten oder inkonsistenten Software-Architektur führen.
Hohe Redesign-Kosten: Spätere, grundlegende Änderungen an einer schlechten Architektur (Redesign) sind sehr kostspielig.
Mangelnde Stabilität: Der Grundsatz “Nichts ist fix, alles kann sich ändern” kann ohne gute Steuerung zu mangelnder Ausrichtung und Stabilität führen.
Welches Modell ist besser geeignet, um Anforderungen zu managen: V-Modell oder Scrum? Begründe die Antwort!
Es gibt keine pauschal “bessere” Methode; es kommt auf die Art der Anforderungen an.
V-Modell ist besser für stabile Anforderungen:
Das V-Modell ist ideal, wenn die Anforderungen von Anfang an klar, vollständig bekannt und stabil sind.
Warum? Das gesamte Modell baut darauf auf, dass die zu Beginn im Pflichtenheft definierten Anforderungen “eingefroren” werden. Der starre, sequenzielle Prozess bietet hohe Planungssicherheit, solange sich nichts ändert. Änderungen sind jedoch extrem aufwändig und teuer.
Scrum ist besser für unklare und sich ändernde Anforderungen:
Scrum ist überlegen, wenn die Anforderungen zu Beginn unklar sind, sich wahrscheinlich ändern werden oder erst im Laufe des Projekts entdeckt werden.
Warum? Scrum ist explizit für Flexibilität und Anpassung konzipiert. Anforderungen werden im Product Backlog kontinuierlich verfeinert und neu priorisiert. In kurzen Sprints kann das Team auf Feedback und neue Erkenntnisse reagieren, was das Risiko minimiert, am Ende ein Produkt zu entwickeln, das der Kunde nicht mehr will.
Warum ist das Verständnis der Domäne des Kunden ein so wichtiger, aber oft unterschätzter Aspekt in der Softwareentwicklung?
Das Verständnis der Domäne (also des Fachgebiets und Arbeitsumfelds des Kunden) ist aus zwei Gründen essenziell:
Grundlage für die Kommunikation: Nur so kann man den Kunden und seine Bedürfnisse wirklich verstehen.
Grundlage für die Anforderungen: Es definiert, was die Software leisten muss (Requirements).
Es ist ein zentraler Bestandteil von:
- Domain Engineering (gezielte Entwicklung für ein Fachgebiet)
- Requirements Engineering (Anforderungsanalyse)
- Dem generellen Projektverständnis
- Der Einbindung des Kunden und anderer Stakeholder
Priorisierung im Scrum
Nicht komplett strikt, man kann auch andere Items als das oberste nehmen.
Was ist der Unterschied zwischen expliziten und impliziten Anforderungen?
Explizite Anforderungen (Die Spitze des Eisbergs):
Das sind alle Anforderungen, die vom Kunden klar ausgesprochen, formuliert oder schriftlich festgehalten werden. Sie beschreiben, was das System tun soll.
Beispiel: “Das System muss für den Nutzer einen PDF-Export der Monatsrechnung erstellen.”
Implizite Anforderungen (Der Teil unter Wasser):
Das sind Anforderungen, die der Kunde als selbstverständlich voraussetzt und deshalb nicht extra erwähnt. Sie beschreiben oft, wie das System etwas tun soll (Qualität, Sicherheit, Bedienbarkeit).
Beispiel:
“Der PDF-Export darf nicht länger als 2 Sekunden dauern.” (Performance)
“Das System muss sicher vor unbefugtem Zugriff sein.” (Sicherheit)
“Das System muss auch auf einem Smartphone gut bedienbar sein.” (Usability)
Warum ist das wichtig? Das Nichterfüllen von impliziten Anforderungen führt oft zu Unzufriedenheit, selbst wenn alle expliziten Wünsche umgesetzt wurden.
Was bedeutet eine “andere Domäne” des Kunden, über die reine Fachsprache hinaus?
Eine andere Domäne bedeutet, dass sich ein ganzes Ökosystem unterscheidet. Man muss nicht nur die Sprache und den Kontext des Kunden verstehen, sondern auch viele weitere Aspekte berücksichtigen:
Personen & Prozesse:
* Andere Rollen und Verantwortlichkeiten im Unternehmen.
* Etablierte Best Practices und Arbeitsabläufe.
Annahmen & Erwartungen:
* Andere implizite Anforderungen, die als selbstverständlich gelten.
* Andere Erwartungen an das Endprodukt und die Zusammenarbeit.
Rahmenbedingungen:
* Technische Schnittstellen (Interfaces) zu bestehenden Systemen.
* Gesetzliche Vorgaben (Laws) und branchenspezifische Einschränkungen (Limitations).
Wie beeinflusst die Art eines Projekts die Intensität des Requirements Engineering (Anforderungsanalyse)?
Die Intensität des Requirements Engineering muss immer an die Projektart angepasst werden.
Kleine, schnelle “Wegwerf”-Projekte:
Anforderungen sind oft weniger wichtig und nicht die treibende Kraft.
Man lernt vieles erst während der Umsetzung (“on the fly”).
Große, langlebige Projekte:
Das genaue Erfassen, Überwachen und Prüfen von Anforderungen ist essenziell für den Erfolg.
Konsequenz: Passe den Lernprozess über die Anforderungen (und das gewählte Vorgehensmodell) immer an dein spezifisches Projekt an (Tailoring)!
Was sind “informelle Dokumente” in der frühen Projektphase und welche grundlegenden Anforderungen gibt es an sie?
“Informelle Dokumente” sind diverse Unterlagen, die zu Beginn eines Projekts entstehen und oft uneinheitlich sind. Sie können stammen:
* Vom Auftraggeber (z.B. E-Mails, Skizzen)
* Vom Hersteller (z.B. erste Entwürfe)
* Aus einem interaktiven Prozess (z.B. Workshop-Notizen)
Obwohl sie informell sind, gibt es drei zentrale Anforderungen an ihren Umgang:
* Ordnung: Wissen und Dokumente müssen systematisch geordnet werden.
* Nachvollziehbarkeit: Eine rekonstruierbare Änderungshistorie ist notwendig.
* Verständlichkeit: Die Gesamtheit der Dokumente muss verständlich sein.
Was ist ein “System Vision Document” und was sind seine Hauptmerkmale?
Das System Vision Document ist eine Vision, die alle Anforderungen und Wünsche an ein zukünftiges Produkt sammelt.
Hauptmerkmale:
* Kurz: Es fasst die Vision prägnant zusammen.
* Leicht verständlich: Jeder kann die Grundidee schnell erfassen.
* Guter Startpunkt: Ideal für neue Teammitglieder, um das Projektziel zu verstehen.
Wichtig: In dieser Phase geht es um die Vision, nicht um die Machbarkeit. Die Reduzierung auf realistische Anforderungen erfolgt erst in einem späteren Schritt.
Was ist eine Anforderungsliste (Requirements List) und wie sollte eine einzelne Anforderung darin formuliert sein?
Eine Anforderungsliste ist ein Dokument, das alle Anforderungen an ein System sammelt und strukturiert.
Merkmale der Liste (des Dokuments):
* Nummeriert: Jede Anforderung hat eine eindeutige Nummer.
* Gruppiert: Anforderungen sind thematisch geordnet (z.B. nach Funktionen).
* Listenform: Es ist eine übersichtliche Auflistung aller Punkte.
Merkmale einer einzelnen Anforderung (eines Eintrags):
Eine gute Anforderung ist…
* in natürlicher Sprache (Text) formuliert
* ein einfacher Satz.
* enthält genau eine Aussage über das System.
* kurz und klar verständlich.
Welchen Zweck erfüllen gut formulierte und strukturierte Anforderungen in einer Anforderungsliste?
Gut formulierte Anforderungen dienen vier wesentlichen Zwecken, die sich direkt aus ihrer Struktur ergeben:
- Definition der Systemgrenzen: Sie legen klar fest, was das System leisten soll und was nicht.
- Struktur: Durch die Gruppierung der Anforderungen wird das Projekt inhaltlich gegliedert.
- Nachverfolgbarkeit (Traceability): Durch die Nummerierung kann jede Anforderung über den gesamten Projektverlauf hinweg eindeutig identifiziert und verfolgt werden.
- Überprüfbarkeit (Checkability): Durch die klare Beschreibung wird sichergestellt, dass am Ende objektiv getestet werden kann, ob die Anforderung erfüllt ist.
Wie werden Anforderungen nach ihrer Verbindlichkeit und nach ihrer Art (funktional / nicht-funktional) kategorisiert?
Anforderungen werden auf zwei wichtigen Wegen klassifiziert:
Nach Verbindlichkeit (Wie wichtig ist es?)
Hier wird die Priorität festgelegt, oft mit Schlüsselwörtern (ähnlich der MoSCoW-Methode):
- Muss (Shall): Zwingend erforderlich. Ohne diese Anforderung ist das System nutzlos.
- Soll (Will): Wichtig, aber das System funktioniert prinzipiell auch ohne.
- Kann (Should): Optional, ein “nice to have”.
Nach Art (Was wird beschrieben?)
Funktionale Anforderungen: Beschreiben, WAS das System tun soll.
* Eine konkrete Dienstleistung oder Funktion (z.B. “Der Nutzer kann einen Report als PDF exportieren”).
* Ein Anwendungsfall (Use Case).
Nicht-funktionale Anforderungen: Beschreiben, WIE das System etwas tun soll.
- Geben zusätzliche Erwartungen an eine Funktion (z.B. “Der PDF-Export muss in unter 3 Sekunden abgeschlossen sein”).
- Beziehen sich auf Qualität (z.B. Benutzerfreundlichkeit, Sicherheit) oder die Infrastruktur.
Wichtig: Die Trennung zwischen funktional und nicht-funktional ist oft fließend und nicht immer eindeutig!
Welche drei wesentlichen Eigenschaften muss ein Anforderungsdokument als Ganzes erfüllen, um von hoher Qualität zu sein?
Das gesamte Set an Anforderungen muss drei zentrale Kriterien erfüllen:
Vollständig (Complete):
Es müssen alle Anforderungen enthalten sein, die für das System notwendig sind. Nichts Wichtiges darf fehlen.
Redundanzfrei (Without redundancy):
Jede Anforderung sollte nur ein einziges Mal formuliert werden. Dopplungen sind zu vermeiden.
Widerspruchsfrei (Consistent):
Die einzelnen Anforderungen dürfen sich nicht gegenseitig widersprechen.
Was ist der Unterschied zwischen formellen und informellen Beschreibungen von Anforderungen?
Formelle Beschreibungen 📐
Sie sind strikt und exakt, ähnlich einer mathematischen Formel.
Vorteil: Können oft direkt und automatisiert überprüft/getestet werden.
Nachteil: Sind sehr schwer zu erstellen, besonders für nicht-technische Aspekte wie z.B. eine gute “User Experience”.
Informelle Beschreibungen 🗣️
Sie sind weniger präzise und oft in natürlicher Sprache verfasst, z.B. eine Erzählung, was ein Nutzer tut.
Vorteil: Sind einfach und schnell zu erstellen.
Nachteil: Sind schwer eindeutig zu testen, da Interpretationsspielraum bleibt und Aspekte undefiniert sein können.
Was sind semi-formelle Beschreibungen und was ist ihr Kernmerkmal?
Semi-formelle Beschreibungen sind ein Mittelweg: Sie kombinieren eine strenge Syntax (Form) mit freien, informellen Aspekten (Inhalt).
Kernmerkmal: Eine feste Struktur (z.B. ein Template oder Formular) gibt den Rahmen vor, während der Inhalt in den einzelnen Elementen frei formuliert werden kann.
Beispiele:
- Formulare: Die Felder (Struktur) sind fest vorgegeben, aber was man in die Textfelder schreibt (Inhalt), ist frei.
- UML-Diagramme: Die Syntax zur Darstellung einer Klasse ist streng definiert, aber welche Klassen man beschreibt und wie man sie benennt, ist völlig frei.
Welche weiteren wichtigen Dokumenttypen werden in der frühen Phase genutzt und was ist ihr Zweck?
Neben Anforderungslisten gibt es weitere Dokumente, die je nach Projekt angepasst werden müssen
- Use-Case-Diagramme (Anwendungsfalldiagramme)
Sie definieren und visualisieren das System aus der Nutzerperspektive:
Was: Sie definieren die Anwendungsfälle (Use Cases).
Wer: Sie zeigen die Akteure (z.B. Benutzer) und ihre Beziehung zu den Anwendungsfällen.
Beziehungen: Sie stellen die Beziehungen zwischen den Anwendungsfällen dar. - Szenarien
Ein Szenario beschreibt einen einzelnen, konkreten Durchlauf eines Anwendungsfalls (es ist eine Instanz eines Use Cases).
Zweck: Sie konkretisieren Anforderungen und sind eine perfekte Grundlage für die Erstellung von Testfällen.
Modellierung: Kann als einfacher Text, als Sequenzdiagramm oder als Pseudo-Code erfolgen. - Sequenz
Zeitlicher ablauf ggf. sync und asynch. usw.. unvm.
Was ist ein Spezifikationsdokument (Pflichtenheft) und welche drei zentralen Funktionen erfüllt es?
Ein Spezifikationsdokument ist ein wohldefiniertes, klares und in natürlicher Sprache geschriebenes Dokument, das die Anforderungen an ein Produkt festhält.
Es erfüllt drei zentrale Funktionen:
Enthält die Anforderungen: Es ist die definitive Sammlung aller Anforderungen an das Produkt.
Grundlage für die Entwicklung: Das Entwicklungsteam nutzt es als fundamentale Arbeitsgrundlage.
Basis des Vertrags: Es dient oft als vertragliche Grundlage zwischen Auftraggeber und Auftragnehmer.
