Share ZU:
7 September 2017 @ Frank Stöckel

Ping-Pong ohne Pong

This entry is part 5 of 5 in the series Textuelle Anforderungen

Tischtennis oder Tennis sind in unserer Gesellschaft beliebte Spiele bzw. Disziplinen, an denen wir uns gerne messen und Spaß haben. Das Prinzip basiert darauf, dass jeder Spieler für sich seinen Schlag vorbereitet und ausführt (Ping). Der andere bekommt den Ball und reagiert in gleicher Weise wieder durch eine selbständige Vorbereitung und Ausführung des Gegenschlages (Pong).

In der Entwicklungsrealität haben wir dieses Prinzip in vielen Bereichen auch übernommen. Um dies näher zu beleuchten, zunächst ein Beispiel dazu.

Im Rahmen der Abstimmung von Anforderungen zwischen Entwicklungspartnern als Teil des Anforderungsmanagements / Requirements Engineering erhebt zunächst der Anforderungsautor die Anforderungen, dokumentiert sie und schickt sie danach dem Partner mit der Bitte um Feedback. Der Lieferant kommentiert die Anforderung und setzt einen entsprechenden Status in Form eines Attributwertes. Es gibt hierzu einige Regeln, die zu beachten sind. Beispielsweise darf der Anforderungstext nur vom Autor geändert werden oder die Kommentare dürfen nur vom Lieferant eingetragen werden. Ansonsten kann es zu Datenverlust oder Datenfehlern kommen.

                 
Bild – Ping / Pong in der Abstimmung von Anforderungen

Diese Abstimmungsprozesse werden in vielen Unternehmen, Gremien oder auch Standards in Genüge ausführlich definiert. Dazu kommt noch, dass Anforderungsmanagementwerkzeuge diese Austauschprozesse immer besser unterstützen. Z. B. schreibt der Auftraggeber seine Anforderungen auf, schickt sie dem Lieferanten (Ping), der sie kommentiert und dann wieder zurückschickt (Pong). Dabei gibt es zwei Datenbanksysteme, in denen diese Anforderungen und ihre Eigenschaften mit unterschiedlichen Zugriffsrechten verwaltet werden. Der Abstimmungsprozess kann durch Änderungsanträge noch weiter formalisiert werden. Der Autor kann seine eigenen Anforderungen nur in dem Fall ändern, wenn der Entwicklungspartner in Form eines Statusattributes dazu sein Befürworten kommuniziert hat. Die Nachteile von so einem formalen stark Ping-Pong getriebenen Vorgehen liegen auf der Hand:

  • Abhängig von der Toolumgebung ergibt sich ein hoher Aufwand bei der Ausleitung und Integration der Daten auf beiden Seiten. Nach meinen Erfahrungen kann dies einige Stunden und bei umfangreicheren Datenmodellen bis zu einem Tag auf beiden Seiten bedeuten.
  • Oft ist es so, dass während solcher Ausleitungen und Integrationen in den Datenbanken nicht weitergearbeitet werden kann. So wird die eigentliche fachliche Arbeit an den Anforderungen damit erschwert.
  • Bei der Ausleitung und Integration können Fehler durch Schwächen der Werkzeuge oder auch durch Bedienungsfehler von Menschen vorkommen, die die Arbeit an den Anforderungen auf beiden Seiten erschweren können. Fehleranalyse, Korrekturen und wiederholtes Ausleiten bzw. Integrieren führen zu weiteren Verzögerungen und zusätzlichen Aufwänden.

Betrachten wir die hier grob beschriebene Abstimmung von Anforderungen anhand eines exemplarischen Beispiels noch ein wenig detaillierter.

In einem ersten Schritt wird aus Sicht des Auftraggebers die Anforderung initial formuliert. Oft mit impliziten Annahmen seitens des Auftraggebers.  In der ersten Abstimmungsrunde (Ping/Pong) lösen diese Anforderungen beim Partner / Lieferant (1. Ping) Unverständlichkeit aus. Nach dem Pong, welches erst nach einigen Tagen oder Wochen wieder beim Auftraggeber ankommt, werden die Anforderungen aufgrund der Kommentare vom Partner verbessert. Damit ist nun zunächst die Anforderung verständlich geworden. Danach werden nun Mehrdeutigkeiten sichtbar, die vom Lieferanten auch wieder kommentiert werden, die im nächsten Ping-Pong-Wechsel weiter ausgeräumt werden. Mit jedem Ping-Pong wird die Anforderung nun besser.

Stellen wir uns nun vor, der Auftraggeber würde im Beisein des Lieferanten dieselbe Anforderung mit ihm direkt abstimmen. Im Gespräch zwischen den beiden ist zu erwarten, dass nach wenigen Momenten zumindest die Anforderung verständlich und eindeutiger vorliegt. Versuchen Sie in Ihrem Alltag so ein Gespräch, welches sie selber mit einem Kollegen über eine Anforderung führen, daraufhin zu analysieren, wie viele Ping-Pongs im Gespräch wirklich stattfinden. Meine Erfahrungen sind hier, dass in einem Gespräch teilweise sehr viele Ping-Pong-Wechsel stattfinden. Durch das interaktive Gespräch zwischen den Beteiligten wird diese Anforderung in wenigen Minuten durch viele Ping-Pongs direkt im Gespräch sehr schnell signifikant verbessert und auch abgestimmt. Niemand wird auf die Idee kommen einen Nutzen in der Dokumentation dieses detaillierten Wechselspiels zu sehen.

Würde dieses Szenario jedoch über einen strikten werkzeugunterstützten formalen Ping-Pong-Prozess durchgeführt werden, so würde diese Abstimmung Wochen dauern. Des Weiteren besteht die Gefahr, dass bestimmte Anforderungen nicht final abgestimmt werden können, da die Projektzeitpläne so viel Ping-Pong-Wechsel nicht zulassen. Es wäre der Versuch all diese Interaktionen zwischen zwei Beteiligten zur Verbesserung bzw. Abstimmung zu dokumentieren. Die Abstimmung von Anforderungen in einem Gespräch läuft quasi in Zeitlupe ab.

In meinen vielen Beratereinsätzen konnte ich schon reichlich solche prozess- und toolgesteuerte Abstimmungsprozesse erleben, die auch noch andere Effekte mit sich bringen. Sie stellen für das Management oft eine Möglichkeit dar, den Abstimmungsstand anhand von Metriken aufzuzeigen. Die dann wiederum die Möglichkeit bieten, Schuldige zu finden und Eskalationsmunition zu liefern.

Ich plädiere hiermit für Kollaborationsmodelle, bei denen die Autoren mit den Entwicklungspartnern an der Entwicklung von Systemen, Produkten und / oder Software eng zusammenarbeiten. Feedback könnte direkt bei der Erstellung oder Abstimmung der Anforderungen eingebracht werden und verwertet werden. Nachdem die Anforderung bzw. Anforderungen gemeinsam erstellt werden, werden Sie den relevanten Partnern zur Info zugeschickt (Ping bleibt also). Pong fällt weg.

Alle Entwicklungspartner arbeiten gemeinsam in einer Datenbank zusammen, in der die Entwicklungsartefakte (Anforderungen, Testfälle etc.) gemeinsam erstellt, abgestimmt, priorisiert etc. werden und auch der Status dazu zentral und gemeinsam festgelegt wird. Nach jeder Arbeitssession werden die erarbeiteten Stände zur Info an die relevanten Partner geschickt (Ping). Die Bearbeitung der Daten inkl. deren Eigenschaften findet jedoch gemeinsam in einer zentralen Toolumgebung (Datenbanken, zentral abgelegtes Word- oder Excel-Datei) statt. Es hört sich zwar aufwendig an, den Lieferanten aktiv in bestimmte Anforderungsarbeiten einzubinden, es ist aber in jedem Fall schneller und damit auch effizienter als umfangreiche formalisierte Austauschprozesse mit den oben geschilderten Nachteilen. Selbstverständlich muss das Vorgehen für ein Kooperationsmodell zwischen unterschiedlichen Entwicklungspartnern an die konkrete Projektphase und deren Zielsetzung angepasst bzw. entwickelt werden. Dieses Kollaborationsmodell kann selbstverständlich für unterschiedliche Anforderungsaktivitäten wie z. B. Erhebung, Dokumenation, Abstimmung und Ableitung von Anforderungen  verwendet werden.

Folgende Vorteile ergeben sich:

  • Effizientere Entwicklung von Anforderungen (keine Ping-Pongs mehr, keine Sperrzeiten durch Ausleitungen oder Integrationen etc.)
  • Höhere Anforderungsqualität
  • Weniger Ressourcen im Werkzeugunterstützungsbereich
  • Vertrauensaufbau zwischen den Beteiligten, durch direkte Zusammenarbeit

Aus „Ping-Pong“ wird „Ping“.

 

 

Series Navigation<< Formulierungstipps – Teil 3

Frank Stöckel

Kontaktieren Sie Frank Stöckel

Herr Frank Stöckel ist als Principal Consultant im Bereich Requirements Engineering (RE) tätig. Seine Schwerpunkte liegen in der Einführung von Requirements Engineering in Entwicklungsunternehmen mit Hilfe von Assessments, Seminaren, Workshops und Coaching. Fokus hierbei stellen wichtige initiale Pilotprojekte dar, die dann in unternehmensweite Prozessverbesserungsmaßnahmen führen, um RE langfristig in Entwicklungsunternehmen zu etablieren. Herr Stöckel führt Werkzeugauswahlverfahren für RM Tools durch, erarbeitet Konzepte zur Realisierung und Einführung von DV-Lösungen unter Einbindung von Werkzeugen des gesamten Entwicklungsprozesses. Darüber hinaus hat er in den letzten Jahren insbesondere in der Automobilindustrie Produktivstellungen (Roll-Outs) sowie Prozessentwicklungen von Anforderungsmanagement inkl. angrenzenden Prozessdisziplinen wie Projekt- und Testmanagement, Änderungsmanagement, Systemmodellierung, Lieferantendatenaustausch etc. erfolgreich geleitet. Kenntnisse in Modellierungstechniken runden sein Profil ab. Als erfahrener Trainer gibt er sein vielfältiges Wissen weiter, z.B. auch als akkreditierter Trainer für den Kurs „Certified Professional Requirements Engineering - Foundation Level".