transentis consulting

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.
  • Igor Tunjic
    Igor Tunjic
    Sunday, August 2, 2020
Einige Beispiele dafür, was beim Anforderungsmanagement in großen, verteilten Projekten schief gehen kann – und wie Sie das beheben können

Einführung

Wenn Sie ein Buch nehmen, das sich mit Anforderungsmanagement befasst, wird Ihnen in der Regel erklärt, wie man Anforderungsmanagement in einem einfachen Projekt von Grund auf durchführt.
Was Sie nicht so oft finden werden, ist eine Beschreibung, wie Sie sich verhalten sollten, wenn Sie sich einem Projekt anschließen, das bereits läuft und das bereits vor einigen Herausforderungen steht. Das Ziel dieses Blog-Eintrags ist es, Ihnen einige Ideen zu geben, was man tun kann, um mit Anforderungen in fehlerhaften Projekten umzugehen.
Was ich tun möchte, ist, die Einstellungen und Herausforderungen zu beschreiben, denen unser Team während eines realen Projekts begegnet ist. Mein Ziel ist es, Ihnen einen Eindruck davon zu vermitteln, welche konkreten Schritte wir unternommen haben, um die Situation zu verbessern, und wie gut die Verbesserungsmaßnahmen innerhalb des Projektsettings funktioniert haben.

Phase A des Projekts

Technischer Teil

Unser Team hatte die Aufgabe, eine Back-End-IT-Lösung für die Überwachung der Stunden der Dienstaufzeichnungen für Lkw-Fahrer zu entwickeln. Unser Kunde verfügte bereits über eine On-Board-Gerätelösung, die die täglichen Fahr- und Dienstzeiten (hours of service, HoS) des Fahrers aufzeichnete und den Benutzer darüber informierte, ob er sich an die Gesetzgebung hält. Die Aufgabe, die unser Team zu erfüllen hatte, bestand darin, das Backend des Systems zu entwickeln und es mit der bereits vorhandenen und produktiven On-Board-Lösung zu integrieren. Das zentrale System musste folgende Anforderungen erfüllen:
  • 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
Offensichtlich war die Aufgabe, ein System von verteilten Bordeinheiten zu synchronisieren, die über zwei verschiedene Kanäle mit dem Zentralsystem kommunizieren, keine triviale.

Organisatorischer Teil

Die auf den Geräten installierte SW wurde von einem Team außerhalb unseres Projektteams gebaut und gewartet. Unser Projektteam war für den Server-seitigen Teil des Systems verantwortlich. Auf unserer Seite hatten wir zwei Entwicklungsteams, die an verschiedenen Standorten außerhalb Deutschlands verteilt waren. Zusätzlich waren die Projektleitung und das Spezifikationsteam an verschiedenen Standorten in Deutschland verteilt. Die Kommunikation erfolgte hauptsächlich per E-Mail. Zur Erörterung täglicher Probleme sah das Projekt eine Reihe täglicher Treffen vor, die über webex abgewickelt wurden.
Es war klar, dass die Synchronisation der Arbeit zwischen so vielen verteilten Teams viele Probleme verursachte und eine Quelle von mehr als nur ein paar Rückschlägen innerhalb des Projekts war.

Herausforderungen

Ich trat dem Projekt 6 Monate nach Beginn der Entwicklung bei. Ich wurde dem aus 4 Mitgliedern bestehenden Spezifikations- und Fehlerbehebungsteam zugeteilt. Die Situation, auf die ich traf, war:
  • 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.
Darüber hinaus hatten wir mit folgenden Herausforderungen in Bezug auf das Projektmanagement zu kämpfen:
  • 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 Team definierte also folgendes als Ziel:
Eine Vorgehensweise für das Anforderungsmanagement zu etablieren, die folgende Anforderungen erfüllt:
  • 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

Verbesserungen in Phase A des Projekts

Ein geeignetes Werkzeug für die Spezifikation wählen

Um die oben erwähnten Anforderungen zu erfüllen, erkannte das Spezifikations-Team, dass wir ein Werkzeug benötigen, das uns bei dieser Aufgabe unterstützt. Die Verwendung einer einfachen Sammlung von Dokumenten im .doc-Format würde die Aufgabe nicht erfüllen.
Wie würde ein geeignetes Werkzeug aus Sicht des Spezifikations-Teams aussehen?
  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.

Rückverfolgbarkeit als Schlüsselvoraussetzung für eine Erfolgreiche Spezifikation

Wie oben definiert - eines unserer Hauptziele war es, die Rückverfolgbarkeit von den funktionalen Anforderungen bis zu ihrer Umsetzung auf Systemebene herzustellen. Zu diesem Zweck haben wir vor Beginn der Modellierung in unserem gewählten Werkzeug ein so genanntes Modell eines Modells (Metamodell) definiert, wie wir unsere Spezifikation im Idealfall strukturiert haben möchten:
Dieses Metamodell zeigt einige der Ziele auf, die wir mit unserem Ansatz erreichen wollten:
  • 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
Nach Abwägung all dieser Erwartungen haben wir uns für den Einsatz von Sparx Enterprise Architect (EA) entschieden.

Eine sehr kurze Beschreibung von Sparx Enterprise Architect:

  • 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.

Erfahrungen mit EA

Positiv
  • 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.
Negativ
  • 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 seine Verwaltung 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.

Phase B des Projekts

Eine Änderung der behördlichen Regelung zur Erfassung der Dienstzeiten von Fahrern bedeutete, dass unser Projekt die bereits ausgelieferte Systemfunktionalität anpassen musste, um der Regelung zu entsprechen. Da fast alle Teile des Projekts von der Änderung betroffen waren, war dies auch eine Gelegenheit, einige Dinge zu reparieren, die bei der ursprünglichen Implementierung nicht gut funktionierten. Die Budgetbeschränkungen erlaubten es jedoch nicht, eine völlig neue Implementierung durchzuführen. Stattdessen entschied man sich für einen gemischten Ansatz, d.h. unser Projekt sollte so viel Altcode wie möglich beibehalten und nur das absolut Notwendige neu implementieren. Eine Neuimplementierung würde für die Teile erfolgen, die noch nicht geliefert wurden, oder für die Teile, die aufgrund einer neuen Regelung angepasst werden mussten. Aus der Sicht des Spezifikationsteams bedeutete der neue Ansatz jedoch, dass wir die Spezifikation mehr oder weniger von Grund auf neu schreiben mussten. Damit erhielten wir auch die Gelegenheit, den neuen Ansatz für das Schreiben von Spezifikationen auf der Grundlage eines modernen Anforderungsmanagement-Tools auszuprobieren.

Polarion Anstatt von Enterprise Architect

Obwohl EA sich bei der strukturierten Erfassung von Anforderungen und der Modellierung von Lösungen als sehr nützlich erwiesen hat, wurde schnell klar, dass es nicht das Hauptwerkzeug sein konnte, das im gesamten Projekt verwendet wurde, da es insbesondere bei den Entwicklungs- und Testteams auf mangelnde Akzeptanz stieß. Auf der anderen Seite verwendete das Architekturteam EA weiterhin für die Modellierung von Datenstrukturen und die automatische Codegenerierung.
Was wäre die Lösung, die es dem Entwicklungs- und Testteam erlauben würde, am effizientesten mit dem Spezifikationsteam zusammenzuarbeiten?
Um die beste Lösung für das Projekt zu finden, befragte das Spezifikationsteam das Entwicklungs- und Testteam zu seinen Erwartungen an die zukünftige Spezifikation des Systems. Es folgten die Anforderungen der beiden Teams bezüglich der Spezifikation:
  • 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, Versionsverwaltung und Status leicht zu warten sein.
Darüber hinaus erkannte das Projektteam während einer Lessons-Learned-Session die Unzulänglichkeiten des derzeitigen Projektansatzes, Spezifikations- und Testelemente in verschiedenen Systemen ohne Verbindungen zwischen ihnen zu halten.
Daher wurde eine zusätzliche Anforderung in die Liste der Funktionen aufgenommen, die ein neues Werkzeug besitzen sollte:
  • 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.
Um diesen Anforderungen gerecht zu werden, beschlossen wir, einen Schritt von unserem ursprünglich vorgeschlagenen EA-Ansatz zurückzugehen und nach einem Werkzeug zu suchen, das die meisten der von den Entwicklungs- und Testteams gestellten Anforderungen erfüllen würde. Das Werkzeug, das am besten zu passen schien, war das Anforderungsmanagement-Tool Polarion System.
Kurze Beschreibung von Polarion
Polarion ist in erster Linie als Werkzeug für das Anforderungsmanagement und die Verwaltung des Anwendungslebenszyklus konzipiert. Es unterstützt den Anwender bei der Erstellung und Bearbeitung verschiedener Artefakte wie Use Cases, Requirements oder Test Cases. Die Bearbeitung von Artefakten erfolgt in Textform über einen wortähnlichen Editor. Dadurch ist er auch für unerfahrene Benutzer sehr einfach zu bedienen. Eine weitere Schlüsselfunktion von Polarion ist die Möglichkeit, verschiedene Artefakte über vordefinierte Beziehungen zu verknüpfen, z.B. können Anforderungen und zugehörige Testfälle über eine "Überprüfen"-Assoziation verknüpft werden. Diese Funktion kombiniert mit verschiedenen Filterfunktionen in Polarion ermöglicht eine schnelle und einfache Überwachung der Rückverfolgbarkeit im Projekt. Darüber hinaus bietet Polarion eine Historienfunktion für jedes definierte Artefakt, die z.B. sehr nützlich sein kann, um die Änderungshistorie einer Anforderung in einem Projekt zu verstehen.
Project Life Cycle Management mit Polairon
Die folgende Abbildung zeigt ein Metamodell der Spezifikation und die wichtigsten Entwicklungs- und Testobjekte, die das Projekt in Polarion verwendet:
Wie aus dem Modell ersichtlich ist, war es unser Ziel, eine einzige Plattform für die Koordinierung der Funktionsbeschreibung des Systems und deren Abdeckung und Vollständigkeit hinsichtlich der von den Entwicklungsteams durchgeführten Implementierung und Tests zu verwenden. Im Folgenden möchte ich einen kurzen Überblick über die Artefakte geben, die vom Spezifikations-Team verwendet wurden, um die gewünschte Funktionalität des Systems zu beschreiben.

Spezifikationen

Für die Spezifikation der Funktionalität des Systems definierte und verwendete das Team drei verschiedene Objektklassen in Polarion:
  • Anwendungsfälle
  • Anforderungen
  • GUI-Elemente
Anwendungsfälle
Anwendungsfälle waren das Kernelement der Spezifikation. Wir definierten die Anwendungsfälle in Polarion unter Verwendung der Anwendungsfall-Vorlage. Diese Vorlage enthielt die Standardelemente, die erforderlich waren, um die Mehrzahl der Anwendungsfälle für das Entwicklungs- und Testteam ausreichend gut zu beschreiben:
  • Vor- und Nachbedingung
  • Rollen und Berechtigungen
  • Grundlegender Pfad
  • Alternative Szenarien
  • Fehlerszenarien
Zusätzlich haben wir in seltenen Fällen, in denen eine textbasierte Beschreibung nicht ausreichend war, in EA modellierte Aktivitätsdiagramme eingefügt.
Anforderungen
Die Anforderungen wurden in zwei Hauptklassen gruppiert:
  • 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.
GUI-Elemente
Es wurden GUI-Elemente eingeführt, um dem Team eine bessere Vorstellung von der erwarteten Funktionalität des Systems zu vermitteln. GUI-Darstellungen wurden zunächst in einem Werkzeug namens Wireframe Scatcher gezeichnet. Nachdem die Zeichnung fertig war, wurde ein png-Export des Drahtmodells in ein GUI-Objekt in Polarion aufgenommen. Wie bei den Systemanforderungen wurden die GUI-Elemente mit mindestens einem Anwendungsfall verknüpft und innerhalb der schrittweisen Szenariobeschreibung des Anwendungsfalles verwendet.
Einer der Hauptvorteile der GUI-Spezifikation war die Möglichkeit, die vom Benutzer über das Front-End des Systems eingegebenen oder bearbeiteten Daten mit den im Back-End des Systems gespeicherten und verarbeiteten Daten zu verknüpfen. Dies geschah durch Spezifizierung der Daten (über Typ, Bereich, erlaubten Zeichensatz, Maximal- und Minimalwerte) im GUI-Element in Polarion. Sobald die Daten beschrieben waren, wurden sie mit dem im Enterprise Architect gespeicherten Datenmodell verknüpft, so dass Architekten und Systementwickler die Daten von der GUI zum Back End des Systems zurückverfolgen konnten.
Insbesondere stellte das Testteam fest, dass dieser Ansatz die Qualität der Testfälle verbesserte.

Pflege von Spezifikationsdokumenten mittels Tags

Für jedes der Artefakte, die für die Spezifikation verwendet wurden, verwendeten wir einen Satz von Tags, um den Status des Objekts hinsichtlich seiner Vollständigkeit, seiner Rolle im Gesamtbild des Projekts und seines Genehmigungsstatus zu verfolgen. Die wichtigsten verwendeten Tags waren:
  • 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

Akzeptanz von Polarion innerhalb des Projektteams

Polarion wurde innerhalb des Projektteams weitgehend akzeptiert. Folgende Eigenschaften von Polarion waren hauptsächlich dafür verantwortlich
  • 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.

Transformation von einem Wasserfall-Ansatz zu einem Agilen Ansatz unterstützen

Während der Durchführung der Phase B stellte sich heraus, dass die Gesamtleistung des Projektteams nicht den Erwartungen des Kunden entsprach. Weder die Liefergeschwindigkeit noch die Qualität der gelieferten Funktionalität entsprach den Erwartungen. Folgende Mängel wurden als Hauptgründe hierfür identifiziert:
  • 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.

Agiler Ansatz

Als Reaktion auf diese Probleme beschloss die Projektleitung, zu einem agilen Ansatz in Bezug auf die Entwicklung zu wechseln. Es wurde beschlossen, dem SCRUM-Framework mit seiner typischen Struktur von Sprints, Sprint-Teams, Sprint-Backlogs etc. zu folgen.
Erwartete Verbesserung
Mit der Einführung von SCRUM strebte die Projektleitung folgende Verbesserungen an:
  • 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.
Es ist klar, dass der Wechsel zu SCRUM eine bedeutende Anpassung in Bezug auf die Projektstruktur bedeutete. Insbesondere mussten wir die aktuellen Rollen im Projekt auf die vom SCRUM-Rahmen erwarteten Rollen abbilden.

Umgestaltung der Teamstruktur

Zu Beginn der zweiten Phase spiegelte unsere Teamstruktur noch den alten Wasserfall-Ansatz wider. Das Team bestand aus:
  • 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
Die Herausforderung bestand darin, diese eher unflexible Struktur in SCRUM-Rollen umzuwandeln.
Rollen:
Typischerweise muss ein Projekt nach SCRUM 3 Rollen definieren: Entwicklungsteam(s), Product Owner und SCRUM Master. Die folgende Tabelle zeigt, wie die Projektstruktur den SCRUM-Rollen zugeordnet wurde.
Entwicklungsteam
Der naheliegende Ansatz war, die bereits zusammenarbeitenden Entwicklungs- und Testteams zu einem SCRUM-Entwicklungsteam zu erklären.
Das Spezifikations-Team unterstützte das Entwicklungsteam, war aber nicht Teil des Entwicklungsteams. Zum Beispiel nahmen die Mitglieder des Spezifikations-Teams nicht an den täglichen Scrums teil.
SCRUM-Master
Im Rahmen von SCRUM ist ein SCRUM-Master eine Person, die für die Moderation des SCRUM-Prinzips innerhalb des Projekts verantwortlich ist. Diese Person soll ein Moderator sein, der für die Einführung des SCRUM innerhalb des Projekts verantwortlich ist. Das bedeutet, dass er dafür verantwortlich ist, zu erklären, wie SCRUM tatsächlich funktioniert, jedem seine Rolle im Team zu erklären und darauf zu achten, dass die SCRUM-Regeln in Bezug auf das tägliche Scrum-Meeting, die Scrum-Retrospektive usw. eingehalten werden. Außerdem ist es der SCRUM-Meister, der dafür verantwortlich ist, alle Hindernisse in Frage zu stellen, die das Entwicklungsteam an der Durchführung seiner Arbeit hindern könnten.
Dieser Teil wurde von dem/den Projektleiter(n) und dem Entwicklungsteam selbst übernommen.
Es wurde jedoch niemand mit der Aufgabe betraut, den SCRUM-Ansatz zu lehren und zu etablieren. Diese Aufgabe wurde vom Entwicklungsteam allein durchgeführt.
Product Owner
In SCRUM hat der Product Owner die Aufgabe, das Bindeglied zwischen externen Interessengruppen und dem Entwicklungsteam zu sein. Seine wichtigsten Aufgaben sind:
  • 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
Unsere bisherige Teamstruktur und die Komplexität des Projekts erlaubten es nicht, all diese Aufgaben von einer einzigen Person zu übernehmen. Stattdessen wurde jede dieser Aufgaben von einer oder einigen früheren Teamstrukturen übernommen. So wurde z.B. die Kommunikation mit externen Stakeholdern im Hinblick auf die gewünschte Funktionalität und die Priorisierung von Produkt-Backlog-Items vom Spezifikations-Team bzw. vom Projektleiter übernommen.
Herausforderung für das Spezifikationsteam bei der Implementierung des SCRUM-Frameworks
Das Spezifikations-Team musste seine Arbeit an den SCRUM-Ansatz des Entwicklungsteams anpassen. Auf der anderen Seite bestand der Kunde nach wie vor darauf, jegliche Funktionalität vor ihrer Implementierung formal zu genehmigen. Dies führte zu einer irgendwie widersprüchlichen Situation, in der ein Projekt nach außen einem "Wasserfall"-Ansatz folgte und nach innen (unter Verwendung von SCRUM) agil war.
Bei der Umstellung auf den SCRUM-Ansatz sah sich das Spezifikations-Team mit folgenden Herausforderungen konfrontiert:
  • 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.

Wie man einen Sprint Backlog in einem unklaren Projekt definiert

Kernstück von SCRUM ist der Sprint und sein Sprintrückstand. Das Sprint Backlog ist eine Untermenge von Artikeln aus dem Product Backlog, die am Ende des Sprints geliefert werden sollen.
Das Product Backlog in unserem Projekt hatte drei Quellen, aus denen es gefüllt werden konnte:
  • 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
Wie oben erwähnt, musste eine Funktionalität aus dem Produkt-Backlog vom Kunden spezifiziert und genehmigt werden, um Teil des Sprint-Backlogs werden zu dürfen:
Der Genehmigungsprozess sah wie folgt aus:
  • 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
Hinweis: All diese Schritte konnten nur deshalb effizient durchgeführt werden, weil Polarion es uns ermöglichte, unserem Kunden Zugang zu einem bestimmten Teil unserer Spezifikation zu gewähren. Dies geschah, indem wir ihm Rechte zum Lesen und Bearbeiten von Use Cases, Anforderungen und GUI-Elementen gewährten. Auf der anderen Seite hatte der Kunde keine Berechtigung, die mit diesen Objekten verknüpften Testfälle oder internen Probleme zu sehen. Hätten wir den alten Ansatz verwenden müssen, dem Kunden eine Word-Dokumentation und vielleicht eine Excel-Tabelle mit der Liste der Funktionen zur Genehmigung zu übergeben, hätte dies zu wesentlich längeren Genehmigungszeiträumen geführt.
Um ein Sprint-Backlog zu erstellen, mussten wir die Priorität und die Aufwandsschätzung der Objekte im Produkt-Backlog berücksichtigen.
Die Aufwandsschätzung wurde vom Entwicklungsteam unter Aufsicht des Spezifikationsteams vorgenommen. Laut SCRUM sollte das Entwicklungsteam etwa 10 % seiner Zeit für die Schätzung von Posten im Product Backlog verwenden. In unserem Projekt war dies nicht akzeptabel. Anstatt das gesamte Entwicklungsteam mit Schätzungspoker für die Posten im Rückstand zu blockieren, verfolgten wir einen anderen Ansatz. In unserem Projekt war es das Spezifikationsteam, das dafür verantwortlich war, die Schätzungen für die Posten im Rückstand anzufordern und zu sammeln. Wir verfolgten folgenden Ansatz, um die Schätzungen vom Entwicklungsteam zu erhalten
  • 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
Eine der Herausforderungen bestand darin, bei der Definition eines Sprintbacklogs einen guten Kompromiss zwischen kritischen Fehlern und neuen Funktionen zu finden. Normalerweise würde ein Fehler, der eine große Anzahl von Benutzern betrifft, über eine bereits genehmigte Funktionalität siegen und anstelle einer neuen Funktionalität implementiert werden. Auf der anderen Seite lag es im Hauptinteresse des Projekts, so viele neue Funktionen wie möglich zu liefern, da diese vertraglich vereinbart wurde und daher das Hauptkriterium war, an dem die Produktivität des Teams vom eigenen Management gemessen wurde. Daher wurde jede Sprint Backlog-Definition von intensiven Diskussionen innerhalb des Projektteams und zwischen dem Projektteam und dem Kunden begleitet.

Kommunikation innerhalb des Projekts

Da wir in verteilten Teams arbeiteten, mussten wir ein Instrument finden, mit dem wir Themen, Fragen, Probleme und Lösungen auf effiziente Weise kommunizieren konnten. Wir fanden, dass das "Slack"-Chat-Tool unseren Bedürfnissen perfekt entsprach. Es ermöglichte es z.B. dem Entwickler- und Testteam, sich direkt an das Spezifikationsteam zu wenden, falls es offene Fragen bezüglich der zu implementierenden Funktionalität gab. In vielen Fällen wurden Lücken oder Widersprüche innerhalb der Beschreibungen der gewünschten Funktionalität vom Test- oder Entwicklerteam angesprochen.

Ergebnisse und Zusammenfassung

Für eine so komplexe Aufgabe gibt es keine "out of the box"-Lösung. Anstatt zu versuchen, eine einzige werkzeugorientierte Lösung für alle Probleme zu finden, sollten Sie sich lieber darauf konzentrieren, alle Teile des Projekts parallel zu verbessern. Natürlich kann die Verwendung der richtigen Werkzeuge erhebliche Auswirkungen auf die Produktivität Ihres Teams haben, aber nicht weniger wichtig sind Fragen der Organisation, des Projektmanagements, der Kommunikation und nicht zuletzt des Vertrauens.
Unser Team begann mit der Einführung der Modellierungsumgebung Enterprise Architect von Sparx System, um ein tieferes Verständnis der technischen Seite und der Probleme zu erlangen, auf die wir im Projekt gestoßen sind. Im Laufe der Zeit haben wir unseren EA-Ansatz aufgrund von Widerständen, auf die wir innerhalb des Projektteams gestoßen sind, fast vollständig aufgegeben. Stattdessen entschieden wir uns für einen weniger modellbasierten, mehr auf Klartext basierenden Spezifikationsansatz, der den Anforderungen von Entwickler und Testteam besser entsprach. Wir evaluierten eine Reihe von Tools und entschieden uns schließlich für das Anforderungsmanagement-Tool Polarion von Polarion Software. Polarion wurde verwendet, um die Arbeit des Spezifikationsteams und der Entwicklungs-/Testteams zu koordinieren. Der Wechsel zu Polarion war ein wichtiger Beitrag zum Projekterfolg.
Neben der Umstellung auf moderne Anforderungsmanagement-Tools nahmen wir jedoch auch eine organisatorische Umstrukturierung vor. Während des Projekts wechselten das Entwicklungs- und das Testteam vom Wasserfall- zum agilen Ansatz. Sowohl der Wechsel der für das Anforderungsmanagement verwendeten Werkzeuge, der sich als mindestens ebenso erfolgreich und wichtig erwies wie die verbesserte Qualität der Spezifikation.
Upcoming Events

Training AI to Play The Beer Distribution Game

2 hours - 2021-10-27

Mastering The Complexity of Digital Transformation

2 hours - 2021-10-28

Modeling Growth Strategies For Professional Service Firms

2 hours - 2021-11-18

Go to event overview

Recent Blogposts

Meetup: Agile Transformation Tools

Olga Medvedeva - 2021-09-27

Meetup: Understanding The Beer Distribution Game

Olga Medvedeva - 2021-09-01

Introduction to The Business Prototyping Toolkit

Oliver Grasl - 2021-08-17

Go to blog overview

Email newsletter

Subscribe to our newsletter and stay up to date about the latest trends and news.

Name
Email
Subscribe to our newsletter and stay up to date about the latest trends and news.
  • transentis
Contact us

transentis consulting

Geisbergstraße 9

10777 Berlin


+49 30 9203833320

info@transentis.com