Wie man mit Anforderungen in "Problemprojekten" umgeht

Einige Beispiele dafür, was beim Anforderungsmanagement in großen, verteilten Projekten schief gehen kann – und wie Sie das beheben können

• Synchronisierung von Fahrer-HoS, die über Funk (over the air, OtA) oder über USB übertragen werden können, mit bereits in der Datenbank gespeicherten Daten. Die Hauptherausforderung bestand darin, dass das System null Fehlertoleranz aufweist, d.h. die Dienststunden des Fahrers können als eine Kette von Daten betrachtet werden, wobei jedes Segment der Kette von seinem Vorgänger abhängig ist. Daten, die in falscher Reihenfolge ankommen oder fehlende Daten führen unweigerlich zu einer falschen Berechnung hinsichtlich der verfügbaren Arbeitszeit der Fahrer in einem Zeitrahmen. Daher mussten die Daten über ein zuverlässiges Übertragungsprotokoll übertragen werden, und die Datenverarbeitungsalgorithmen im Back-End mussten robust sein.
• Ermöglicht es Benutzern, Dienststunden im System anzuzeigen, hinzuzufügen, zu bearbeiten oder zu löschen. Daher musste das System eine benutzerfreundliches Interface bieten, die es dem Benutzer ermöglicht, diese Aufgaben effizient durchzuführen.
• Wenn ein Fahrer bei einem Bordsystem angemeldet ist, musste das Zentralsystem feststellen, ob die Informationen des Geräts über die Fahrerprotokolle aktuell sind. Wenn geräteseitig Informationen fehlten, musste das Zentralsystem eine Aktualisierung der Fahrer-Protokolldaten bereitstellen.
• Anzeige von Fahrzeugspuren auf einer digitalen Karte für einen gewünschten Zeitraum. Daher sollte das System GPS-Koordinaten verwenden, die von Geräten aufgezeichnet und zusammen mit den Betriebsstunden übertragen wurden

• Die Funktionalität wurde teilweise implementiert - Teile der Implementierung sind nirgendwo dokumentiert oder durch die Spezifikation gerechtfertigt
• Die Spezifikation der gewünschten Funktionalität war unvollständig. Fertige Teile waren oft von schlechtem technischen Niveau.
• Die Spezifikation wurde in Word-Dokumenten festgehalten. Jede Änderung der Spezifikation erforderte einen zeitaufwändigen Prozess, bei dem das Dokument im SVN gesperrt, das Dokument bearbeitet, die Teammitglieder zur Überprüfung gebeten und das Dokument erneut hochgeladen werden musste.
• Aufgrund der Unvollständigkeit und des schlechten technischen Niveaus der Spezifikation wurde die Spezifikation vom Entwicklungsteam beim Schreiben des eigentlichen Codes oft nicht verwendet.
• Die implementierte Lösung wurde von unserem internen Testteam und vom Testteam des Kunden permanent getestet. Beide Teams fanden eine große Anzahl von Fehlern. Die Ursache für die Fehler war unklar.
• Eines der Hauptprobleme des Projekts war die fehlende Rückverfolgbarkeit von den funktionalen Anforderungen bis zur implementierten Lösung. Alle an der Projektimplementierung beteiligten Teams wünschten sich mehr Klarheit über die Frage, wie eine bestimmte Anforderung im System widergespiegelt wird.
• Niemand im Projekt schien zu wissen, was konkret schief läuft, doch jeder wusste, dass im Projekt etwas schief läuft.

• Die Entwicklungsteams kamen aus verschiedenen Ländern und Zeitzonen, was eine effiziente Kommunikation zwischen den Teams erschwerte.
• Die Entwicklung folgte dem Wasserfall-Ansatz, wobei jedem Entwicklungsschritt eine genehmigte funktionale Spezifikation vorausgeht
• Aufgrund des Mangels an genehmigten Spezifikationen war den Entwicklungsteams irgendwie unklar, was genau implementiert werden sollte. In diesem Fall haben sie, um keine Zeit zu verlieren, etwas implementiert, das ihrer Meinung nach am besten den Erwartungen des Kunden entsprach.
• Die Kommunikation, um die Entwicklungsbemühungen zwischen verschiedenen Teams zu synchronisieren und sicherzustellen, dass Schnittstellen, Datenstrukturen usw. aufeinander abgestimmt sind, war eine Herausforderung

• Das Entwicklungs- und Testteam in die Lage versetzen, die SW gemäß Ihrer Spezifikation tatsächlich zu entwickeln
• Das Spezifikations-Team in die Lage versetzen, schnell auf Änderungen der gewünschten Funktionalität zu reagieren, die im Projekt auftreten könnten
• Verbesserung der Gesamtqualität der Spezifikation
• Bereitstellung einer klaren und funktionell korrekten Spezifikation komplexer Anforderungen
• Die Spezifikation für jedes Mitglied des Projektteams leicht nutzbar machen
• Dem Kunden ermöglichen, das Design und die Funktionalität des Systems auf effiziente Weise zu überprüfen und zu genehmigen
• Einbeziehen von Kundenwünschen, Ergänzungen und Korrekturen in die Spezifikation

1. Es würde es uns ermöglichen, Anforderungen einfach zu erstellen, zu gruppieren und zu klassifizieren.
2. Es würde die UML-Modellierung zur Beschreibung komplexer Anwendungsfälle unterstützen (z.B. durch die Verwendung von Aktivitätsdiagrammen).
3. Es würde es ermöglichen, die Umsetzung der Anforderung im System zu verfolgen, angefangen bei der Definition der Anforderung selbst, über die Verfolgung ihrer Implementierung bis hin zu den verwendeten Komponenten und den beteiligten Datenbankschemata (falls erforderlich).
4. Es würde es ermöglichen, die Arbeit auf verschiedene Verantwortungsbereiche aufzuteilen, z.B. wenn das System in verschiedene (logische) Module aufgeteilt werden kann - wir würden erwarten, dass verschiedene Teammitglieder in der Lage sind, die Spezifikationsarbeit an jedem Modul unabhängig voneinander durchzuführen.
5. Es würde es ermöglichen, Grundlinien und Prioritäten zu setzen.
6. Es würde mit einer Lösung für die Versionskontrolle aufwarten.
7. Und last but not least: Das Tool würde es ermöglichen, ein pdf- oder .doc-Anforderungsdokument automatisch anzupassen und zu generieren, wenn Ihr Kunde es wünscht.

• Identifizieren Sie für jeden Geschäftsfall mindestens einen Anwendungsfall, der diese Funktion im System repräsentieren würde
• Leiten Sie durch die Definition des Anwendungsfalles für die Geschäftsfunktionalität eine Reihe von funktionalen Anforderungen auf der obersten Ebene ab. Nennen Sie diese Anforderungen der Ebene 1.
• Beginnen Sie gleichzeitig bereits mit der Definition der Einschränkungen oder nicht-funktionalen Anforderungen, die Ihr Produkt erfüllen soll
• Jede funktionale Anforderung muss durch einen Geschäftsfall begründet und durch einen Anwendungsfall realisiert werden
• Um einen Anwendungsfall detailliert zu spezifizieren, verwenden Sie jedes UML- oder Nicht-UML-Modell, das Ihnen geeignet erscheint. Mögliche Wege, die Funktionalität eines Anwendungsfalles zu spezifizieren, können Aktivitätsdiagramme, Sequenzdiagramme, aber auch eine einfache Klartextbeschreibung sein.
• Definieren Sie ein logisches Datenmodell, das Geschäftsobjekte beschreibt, die im zukünftigen System verwendet werden sollen.
• Verwenden Sie die im logischen Datenmodell definierten Klassen, um das Anwendungsfallverhalten detailliert zu spezifizieren. Beispielsweise kann es sinnvoll sein, die Datenobjekte innerhalb eines Aktivitätsdiagramms zu referenzieren, um zu erklären, welche Daten innerhalb der Aktivität verarbeitet werden.
• Identifizieren Sie während der detaillierten Definition eines Anwendungsfalles die Anforderungen L2 (Stufe 2), die die Anforderungen L1 detaillierter beschreiben
• Definieren Sie logische Systemeinheiten, die Ihre Systemfunktionalität auf logische Weise zerlegen
• Ordnen Sie die Systemkomponenten logischen Systemeinheiten zu
• Ordnen Sie jeden Anwendungsfall der logischen Systemeinheit zu

• Der Kern der EA ist das Modell. Modell bedeutet Objekte und die Beziehung zwischen ihnen. Oft werden ein Modell oder seine Teile über Diagramme visualisiert
• Objekte in EA können Anforderungen, Anwendungsfälle, Klassen usw. sein.
• Assoziationen zwischen Objekten werden in der EA-Datenbank gespeichert. Sie sind Teil des Modells und hängen nicht von einem bestimmten Diagramm ab.
• Assoziationen können über ein Modelldiagramm konstruiert und visualisiert werden (z.B. Assoziationen zwischen Klassen in einem UML-Klassendiagramm oder ein Diagramm, das Verbindungen zwischen Anforderungen und realisierten UCs (Anwendungsfälle) zeigt)
• Pakete werden zur Strukturierung des Modells verwendet
• EA unterstützt den Benutzer mit einem Werkzeugsatz, der bereits an die gewünschte Modellierungstechnik angepasst ist, z.B. Klassenelemente und Assoziation, wenn der Benutzer ein Klassendiagramm erstellen möchte.

• Mit Hilfe der Paketstruktur in EA konnten wir eine strukturierte und vollständige Ansicht der Spezifikation erstellen, die bis zu diesem Zeitpunkt auf verschiedene Dokumente verteilt war. Die Paketstruktur mit geöffneten Anwendungsfälle und Anforderungen ist im Bild unten zu sehen

• Die Modellierung innerhalb von EA ermöglichte es dem Team, komplexe Abhängigkeiten zwischen Datenobjekten und Geschäftsregeln besser zu verstehen. Durch die Definition des Domänenmodells über das UML-Klassenmodell waren wir in der Lage, Interdependenzen zwischen verschiedenen Geschäftsdatenobjekten aufzuzeigen, die bisher nicht eindeutig identifiziert werden konnten.
• Durch die Verwendung der UML-Aktivitätsdiagramme konnten wir einige der komplexesten Anwendungsfälle modellieren, die zuvor in einer einfachen Sprache beschrieben wurden, wobei die schriftliche Beschreibung sehr komplex und mehrdeutig ist. Durch die Verwendung von Datenobjekten in den Aktivitätsdiagrammen konnten wir zeigen, welche Geschäftsobjekte in welchem Anwendungsfall und in welchem bestimmten Schritt des Anwendungsfalles verwendet wurden. Die in den Aktivitätsdiagrammen verwendeten Datenobjekte bezogen sich auf die im Domänenmodell definierten Geschäftsobjekte. Dadurch waren wir in der Lage, nicht nur eine visuelle Darstellung eines komplexen Anwendungsfalles zu liefern, sondern auch das Domänenmodell mit den Anwendungsfällen zu verbinden (Rückverfolgbarkeit).

• Die Verknüpfung von Anforderungen und Anwendungsfällen über einen "Realisierungs"-Konnektor ermöglichte es uns, die Realisierung der Anforderung zu verfolgen. Wir waren in der Lage, Anforderungen zu identifizieren, die offensichtlich von keinem der definierten Anwendungsfälle abgedeckt waren und daher keine klare Umsetzungsspur hatten. Das Verbinden von Anforderungen und Anwendungsfällen ist in EA eine einfache Aufgabe, entweder mit Hilfe eines Diagramms oder einer Beziehungsmatrix. Das Bild unten zeigt, wie eine Beziehungsmatrix in EA verwendet werden kann, um zu überprüfen, ob alle Anforderungen durch mindestens einen Anwendungsfall realisiert sind.

• Die Paketstruktur von EA ermöglichte es uns, die Arbeitsbereiche auf einfache Weise zu strukturieren. Dadurch war es möglich, die verfügbaren Ressourcen effizienter auf bestimmte Aufgaben zu verteilen.
• Die Versionierung der EA-Pakete über svn ermöglichte es dem Team, gleichzeitig an verschiedenen Paketen zu arbeiten, ohne Konflikte zu verursachen.

• Die Modellierung in UML erwies sich als "Expertenwissen" innerhalb des Projektteams. Beide Testteams - das eine auf unserer Seite und das andere auf Kundenseite - fanden es schwierig, Testfälle aus UML-basierten Beschreibungen von Use Cases (oft über Aktivitätsdiagramme) abzuleiten. Beide Teams erklärten, dass sie eine informellere, aber leichter lesbare Beschreibung eines Anwendungsfalles im Klartext bevorzugen.
• Die Modellierung in EA erfordert ein hohes Maß an Modellierungsdisziplin, um nützlich zu sein. Informationen müssen in vordefinierter Weise gespeichert werden. In der Regel ist es der Teamleiter, der definiert, wo ein bestimmter Satz von Informationen gespeichert werden soll, und der dies im Modellierungsregelsatz beschreibt. Abweichungen von den vordefinierten Modellierungsregeln führen dazu, dass Informationen irgendwo im Modell gespeichert werden. Jeder, der das Modell verwendet, wird es schwer haben, die Informationen zu finden und zu extrahieren.
• Das Entwicklungs- und Testteam wollte EA nicht für die Speicherung seiner Artefakte verwenden, da es den EA für sein Management für ungeeignet hielt. Testfälle und Implementierungsaufträge wurden in einem anderen System gespeichert. Daher war die vollständige Rückverfolgbarkeit nicht gewährleistet.
• Die Mehrheit des Teams hatte keine Erfahrung in der Verwendung von EA und wollte keinen signifikanten Teil ihrer Projektzeit für das Erlernen der Verwendung des Tools aufwenden.

• Die Funktionalität ist in einer Benutzergeschichte in einfachem Englisch zu spezifizieren, anstatt UML und Aktivitätsdiagramme zu verwenden, da beide Teams dazu neigen, in einfachem Englisch geschriebene Anforderungen besser zu verstehen als Beschreibungen über UML-Diagramme
• Die Anwendungsfälle müssen eine Beschreibung des Basisszenarios, der Akteure, der alternativen Pfade und der Fehlerszenarien mit den vom System angezeigten Fehlermeldungen enthalten.
• Aktivitätsdiagramme dürfen nur in Ausnahmefällen verwendet werden, z.B. wenn das Basisszenario zu komplex ist, um es im Klartext zu beschreiben. Aber auch solche Anwendungsfälle müssen zusätzlich zu dem Diagramm zumindest eine Erklärung über die Benutzergeschichte in einfacher englischer Sprache enthalten, um Missverständnisse zu vermeiden, die sich aus dem Diagramm ergeben.
• Das Front-End des Systems - das vom Benutzer zur Interaktion mit dem System verwendet wird - muss beschrieben und visualisiert werden. Daher soll das Spezifikations-Team eine spezielle Klasse von Elementen definieren, die GUI-Elemente genannt werden. Alle Daten, die vom Benutzer über die Schnittstelle angezeigt oder bearbeitet werden, müssen im Hinblick auf den zulässigen Zeichensatz, die Länge und andere Einschränkungen definiert werden. Ferner muss klar sein, wie die über das Front-End eingegebenen, bearbeiteten oder gelöschten Daten mit den in der Datenbank des Systems im Back-End gespeicherten Daten übereinstimmen.
• Komplexe Regeln, Algorithmen usw. sind als separate Anforderungen aufzubewahren und in den Benutzergeschichten zu verweisen, wo sie für ein tieferes Verständnis der Systemfunktionalität wichtig sein könnten.
• GUI-Elemente, die vom Spezifikationsteam definiert wurden, sind in den Benutzergeschichten zu erwähnen, wenn dies zum besseren Verständnis der gewünschten Funktionalität angemessen erscheint.
• Das Entwicklungsteam muss die Möglichkeit haben, die Implementierungsaufträge und Testfälle mit der Benutzergeschichte zu verknüpfen, die sie implementieren oder testen sollen. Die Benutzergeschichten müssen in Bezug auf Versionierung, Versionsmanagement und Status leicht zu warten sein.

• Alle Fehler, die entweder bei internen Tests oder auf Kundenseite entdeckt werden, werden zusammen mit Anwendungsfällen, Implementierungsaufträgen und Testfällen gespeichert, so dass jeder Benutzer des Systems leicht erkennen kann, auf welche Funktionalität sich ein Fehler bezieht.
• Da die Zustimmung des Kunden für den Beginn der Implementierung einer der spezifizierten Funktionalitäten erforderlich ist, soll dem Kunden die Möglichkeit gegeben werden, die Spezifikationselemente auf möglichst effiziente Weise einzusehen, zu kommentieren und zu genehmigen oder abzulehnen. Daher wäre die bevorzugte Lösung anstelle der Einsendung eines offiziellen Spezifikationsdokuments, dem Kunden die Möglichkeit zu geben, im gleichen System wie das Projektteam zu arbeiten.

• Anwendungsfälle
• Anforderungen
• GUI-Elemente

• Vor- und Nachbedingung
• Rollen und Berechtigungen
• Grundlegender Pfad
• Alternative Szenarien
• Fehlerszenarien

• Kundenanforderungen, die die Erwartungen und Anforderungen des Kunden an das System speichern, wie sie in der zwischen uns und dem Kunden vereinbarten Arbeitserklärung definiert sind. Diese wurden verwendet, um den Fortschritt des Systems im Hinblick auf die Vollständigkeit des zwischen unserem Kunden und seinem Kunden unterzeichneten Vertrags zu überwachen. Jede Kundenanforderung wurde mit mindestens einem Anwendungsfall verknüpft, um den Fortschritt der Implementierung zu überwachen.
• System- oder interne Anforderungen: Anforderungen, die vom Spezifikations- und Entwicklungsteam definiert wurden, um das System ordnungsgemäß zu implementieren. Häufig wurden diese Anforderungen verwendet, um komplexe Verarbeitungsroutinen oder Datenmanipulationsregeln zu definieren, die in einem bestimmten Anwendungsfall eingehalten werden mussten. Jede dieser Anforderungen war mit mindestens einem Anwendungsfall verbunden (zur Rechtfertigung der Definition der Anforderung). Um die Anwendung der Spezifikation zu erleichtern, wurden die Systemanforderungen in den Szenarien des Anwendungsfalles, in denen sie eine Rolle spielen könnten, direkt miteinander verknüpft. Z.B. wenn es in dem Szenario einen Schritt gäbe, der besagt "System schließt Datenobjekt X in Struktur Y ein", würde eine Anforderung als Verknüpfung folgen, in der die Regeln und Einschränkungen für das Einfügen von Daten in das System detailliert erläutert würden.

• Priority zur Beschreibung der Priorität des Artikels im Hinblick auf die Gesamtfunktionalität des Produkts. Dies war wichtig, um zu verstehen, welche Funktionalität ein "must have" und welche ein "nice to have" innerhalb des aktuellen Entwicklungszyklus war.
• Complexity zur Beschreibung des geschätzten Arbeitsaufwandes für Entwicklung und Test
• Planned/delivered Release zur Beschreibung, in welchem Release die im Objekt beschriebene Funktionalität geliefert werden sollte und wann sie schließlich geliefert wurde. Dies war besonders wichtig, um dem Kunden den Inhalt eines bestimmten Releases mitzuteilen, der seinerseits für die Vorbereitung der Tests der Lieferung wesentlich war. Auf der anderen Seite war es für das Projektteam absolut unerlässlich, um den Überblick darüber zu behalten, welche Funktionalität bereits implementiert und geliefert wurde.
• Status, der den Status des Artikels in Bezug auf die Spezifikation beschreibt (in Bearbeitung, abgeschlossen, genehmigt)
• Module, das beschreibt, zu welchem logischen Teil des Produkts die Artikelwege gehören (z.B. HOS-Modul oder Fahrzeugverfolgungsmodul). Diese Klassifizierung war besonders wichtig für die effiziente Zuordnung von Arbeitspaketen zu Entwicklungsteams

• Es ist einfach, Artikel nach Attributen wie z.B. ihrer Priorität, Kategorie und Komplexität zu filtern und zu ordnen. Auf diese Weise können alle Benutzer leicht eine Ansicht der Projektelemente erstellen, die für ihre Aufgabe im Projekt am besten geeignet ist. Außerdem kann der Moderator die Ansicht während einer Diskussion mit dem Team schnell ändern und anpassen.
• Die Elemente lassen sich leicht bearbeiten und lesen. Es ist kein Expertenwissen erforderlich, um eine einfache Textbeschreibung eines Anwendungsfalles oder eines Testfalles in Polarion zu erstellen oder zu verstehen.
• Es ist einfach, einem Benutzer Lese- und Schreibberechtigungen für eine Teilmenge von Polarion-Elementen zu erteilen. Dies ermöglichte es uns z.B., dem Kunden Zugang zu unserer Spezifikation zu gewähren und ihm die Möglichkeit zu geben, direkt an der Spezifikationsarbeit mitzuwirken, indem er Artikel genehmigt oder kommentiert, falls aus seiner Sicht etwas unklar war. Dies erleichterte die Diskussion mit dem externen Kunden erheblich.
• Es ist einfach, Kategorien für Polarion-Artikel zu definieren. Daher ist es einfach, das Projekt zu strukturieren.
• Es ist einfach, historische Versionen eines Polarion-Gegenstands abzurufen. Änderungen zwischen zwei Versionen werden hervorgehoben und es wird verfolgt, wer welche Änderung vorgenommen hat. Dies erwies sich als eine sehr nützliche Funktion, wenn strittige Punkte mit einem Kunden besprochen werden.

• Entscheidung, große Teile des Legacy-Codes im System zu belassen, um Entwicklungszeit zu sparen. Diese Entscheidung bedeutete, dass die Entwickler vor dem Problem standen, Code zu pflegen, mit dem sie nicht vertraut waren. Wie bei vielen anderen SW-Projekten ändert sich das Entwicklerteam im Laufe der Zeit, wobei Personen das Projekt verlassen und ihr spezifisches Wissen mitnehmen. Die Pflege alter Codeteile und die Integration neuer Codeteile in den Altcode waren zeitaufwändig. Dies führte zu Leistungseinbußen bei der Bereitstellung der neuen Funktionen.
• Viele Fehler konnten erst entdeckt werden, als das Produkt mit Benutzern aus der realen Welt in Produktion ging. Dies führte zu einer erheblichen Anzahl kritischer Fehler, die nach der Lieferung des Produkts in die Produktion behoben werden mussten. Die Behebung von Fehlern in einem bereits ausgereiften Stadium eines Projekts war sehr aufwendig.
• Das Entwicklungsteam musste das produktive System sehr schnell liefern, da die Marketingabteilung ein festes Veröffentlichungsdatum festgelegt hatte. Dies führte dazu, dass das System im Eiltempo entwickelt wurde, ohne allzu viel Wert auf klare Strukturen, Modularisierung und sauberen Code zu legen. Daher war die Fehlerverfolgung und Fehlerbehebung eine Herausforderung, da viele Teile des Codes Abhängigkeiten hatten, die nicht offensichtlich waren.
• Die Geschäftsanforderungen änderten sich während des Projekts je nach dem Feedback der Produktbenutzer. Dies führte zu der Forderung nach einer beträchtlichen Anzahl neuer Funktionen, die in das System implementiert werden sollten. Die Aufwandschätzungen für diese Aufgaben wurden vom Kunden oft bestritten und führten zu sehr intensiven und zeitraubenden Diskussionen.
• Die Integration unseres Teils des Systems mit dem verteilten Teil des Systems (Bordgeräte) erwies sich als ziemlich schwierig. Bei mehreren Gelegenheiten musste das BE-System aufgrund von Fehlern auf der Seite des Geräts angepasst werden. Jede Änderung an den Teilen des Systems, die mit den Geräten in den Fahrzeugen interagierten, musste gründlich getestet werden, bevor sie in die Produktion ging. Die Tests waren in Bezug auf die Ressourcen sehr kostspielig. Es war jedoch nicht immer einfach, dem Kunden zu erklären, warum bestimmte Tests so kostenintensiv waren.

• Schnellere Bereitstellung lauffähiger Systeminkremente, damit der Kunde das System schneller evaluieren und sein Feedback schneller geben kann
• Den Teamzusammenhalt erhöhen, indem Scrum-Teams gebildet werden und sich jeder im Team für die Durchführung verantwortlich fühlt
• Flexibilisierung des Teams im Hinblick auf Änderungen der Geschäftsanforderungen, die Code-Änderungen erforderlich machen
• Effizienzverluste minimieren, die durch plötzliche Änderungen der Prioritäten im Projekt entstehen. In der Vergangenheit sind wir sehr oft auf eine Situation gestoßen, in der die Entwicklung für eine Produktfunktionalität aufgrund eines kritischen Problems unterbrochen werden musste, für das der Kunde darauf bestand, dass es sofort behoben werden musste. Eine Unterbrechung bedeutete immer einen Verlust an Arbeitszeit aufgrund des Aufwands, der für die Reorganisation der Arbeit erforderlich war. Indem wir den Kunden zur Einhaltung der festgelegten Sprintstruktur zwangen, hofften wir, die Anzahl der Situationen zu minimieren, in denen unvollendete Arbeiten unterbrochen werden mussten, um etwas aus Kundensicht Wichtigeres zu tun.

• Projektleiter
• Entwicklungsleiter auch als Ersatz für den Projektleiter
• Spezifikationsteam, bestehend aus 5 Mitgliedern
• Architekt für Back-End-Funktionalität
• Architekt für Front-End-Funktionalität
• 2 Entwicklungsteams mit jeweils 5-9 Mitgliedern. Zwei Teams waren nicht in der gleichen Stadt
• 2 separate Testteams, die die Arbeit des Entwicklungsteams unterstützen

• Erstellung eines Produkt-Backlogs
• Teilnahme an der Definition von Sprint-Rückständen
• Klärung der Erwartungen bezüglich der Funktionalität gegenüber dem Entwicklungsteam
• Verfolgen der Prioritäten von Artikeln im Produkt-Backlog
• Definition von done für einen Sprint bereitstellen

• Die Spezifikationsdokumente Daher musste das Spezifikationsteam das Entwicklungs- und Testteam unterstützen, um den besten Weg zu finden, diese Elemente in das Produkt- und Sprint-Backlog aufzunehmen.
• Der Kunde bestand auf der formalen Genehmigung jeder Funktionalität vor ihrer Implementierung. Der Erhalt einer formalen Genehmigung war aufgrund fehlender Ressourcen zeitaufwändig. Auf der anderen Seite bestand das Projektmanagement darauf, dass so viele Funktionen wie möglich so schnell wie möglich geliefert werden sollten.
• Priorisieren von Funktionselementen und entdeckten Fehlern, um zu entscheiden, was in den nächsten Sprint aufgenommen werden soll
• Sicherstellen, dass die Aufwandsabschätzungen für neue Funktionen oder Fehlerbehebungen durchgeführt werden
• Bereits genehmigte Funktionen erneut mit dem Kunden besprechen, für den Fall, dass sich während eines Sprints die Implementierung als zu komplex erweist, und versuchen, einen Weg zu finden, diese zu lösen.

• Funktionalität, die ursprünglich in einem Vertrag vereinbart und vom Spezifikationsteam spezifiziert wurde
• Fehler und Mängel, die entweder vom Kunden oder von unserem Testteam gemeldet wurden
• Vom Kunden gewünschte Funktionalität, die nicht Teil des ursprünglichen Vertrags war, sich aber für den Geschäftsfall als wichtig erwies

• Das Spezifikations-Team kennzeichnet die zu genehmigenden Artikel als fertig gestellt und wartet auf die Genehmigung
• Eine Liste mit einer Anfrage für die Polarion-Suche wird an den Kunden gesendet
• Nach einer Überprüfungsphase würde der Kunde die Artikel entweder genehmigen oder ablehnen. Im Falle einer Ablehnung war der Kunde verpflichtet, Kommentare zu dem abgelehnten Artikel mit Gründen und offenen Fragen, die zur Ablehnung führen, hinzuzufügen.
• Nicht genehmigte Punkte würden in einer Sitzung zwischen dem Kunden und dem Spezifikationsteam diskutiert, um eine Lösung für offene Fragen zu finden

• Identifizieren Sie das Mitglied des Entwicklungsteams, das sich am besten mit der gewünschten Funktionalität auskennt (normalerweise wurde diese Person vom Leiter des Entwicklungsteams vorgeschlagen)
• Identifizieren Sie das Mitglied des Entwicklungsteams, das sich am besten mit den für diese Funktionalität erforderlichen Tests auskennt
• Erhalten Sie die Aufwandsabschätzungen für Entwicklung und Tests
• Vergleichen Sie den Aufwand für eine ähnliche Funktionalität, wenn eine solche im System vorhanden ist.
• Falls erhebliche Zweifel bestehen, bitten Sie das Entwicklungsteam um Klärung