Aktionen

Viele Augen sehen mehr

Aus PQWiki


Schnelligkeit
★★☆
Einfachheit
★★☆
Agilität
★☆☆

Ziele

* Vervollständigung der Realisierungsvorgaben
  • Stärkung der Zusammenarbeit und des Wissensaustauschs
  • Steigerung der Motivation der Mitarbeiter

Motivation/Problemstellung

Die Realisierungsvorgaben des Pflichtenheftes umfassen häufig nicht alle kritischen Aspekte einer Software. Die komplexen Abhängigkeiten zwischen den Schichten oder Modulen erkennt man teilweise erst während der eigentlichen Umsetzung. Anforderungen an die Qualität werden zudem nicht mit der gleichen Sorgfalt bei der Planung berücksichtigt wie funktionale Anforderungen.

Wünschenswert wäre es, bereits während der Erfassung der Anforderungen, spätestens aber zu Beginn der Umsetzung eine möglichst vollständige Abdeckung zu erreichen. Indem für alle diejenigen Anforderungen und Problemstellungen, die ein Mindestmaß an Komplexität überschreiten, bewusst auf das Knowhow und die Sichtweisen möglichst vieler Personen zurückgegriffen wird, sorgt das hier beschriebene Best-Practice „Viele Augen sehen mehr“ für eine möglichst vollständige Spezifikation.

Erfahrungsgemäß begrüßen Entwickler die Möglichkeit, ihren Erfahrungsschatz auf Teamebene einzubringen. Dieses Best-Practice fördert den Team-Geist, den eigenen Stellenwert und die Motivation der Beteiligten ganz erheblich. Man erhält die Möglichkeit, sich sehr früh mit dem Produkt zu identifizieren, dessen Ausprägung man von Anfang an mitbestimmt.

Kurzbeschreibung

Würfel.jpeg
Dieses Best-Practice sieht vor, in kurz gehaltenen Gesprächsrunden mit intensivem Workshop-Charakter unter Beteiligung einer heterogenen Personengruppe Anforderungen der Software zu beleuchten und deren Beschreibung zu vervollständigen. Neben Spezialisten, die die Facette einer Anforderung besonders gut überblicken, werden auch Personen aus Randgebieten eingebunden. Die Workshops sollten nicht länger als eine Stunde in Anspruch nehmen, dafür aber so oft wiederholt werden, bis ein zufriedenstellendes Ergebnis erzielt wurde. Wichtig ist, dass ein offenes Gesprächsklima gepflegt wird, damit auch Randaspekte zu ihrem Recht kommen, die sonst unberücksichtigt bleiben würden. Unter diesen Voraussetzungen werden Risiken frühzeitig benannt, der Qualitätsgedanke im Allgemeinen hochgehalten; man zeigt früh Interesse an der Wiederverwendbarkeit, der Generalisierung und Verständlichkeit der Lösung. Ausschlaggebend für den erfolgreichen Einsatz dieses Best-Practice ist die Kombination einfacher und bewährter Mittel, die für sich genommen trivial erscheinen, aber im Zusammenspiel Entscheidendes erreichen. Wichtig ist also, dass die Meetings kurz gehalten, gut vorbereitet und zeitnah nachbearbeitet werden und dass der Personenkreis viele Interessen und Sichtweisen abdeckt, um eine möglichst vollständige Erfassung sämtlicher Aspekte der Spezifikation zu erreichen.

Input

Teilbereich eines Kundenprojekts Systemanforderung Lösungsbedürftige Fragestellung

Output

Anforderungsspezifikation Liste der Qualitätsmerkmale und deren Realisierungsansätze

Rahmenbedingungen

Rolle (Ausführender)

Moderator (meist der Projektverantwortliche) Entwicklerteam

Werkzeuge, Hilfsmittel

Laptop, PC, Whiteboard, Flipchart

Vorkenntnisse und Erfahrungen

Grundlegende Fachkenntnisse eines Bereichs

Ort und Umgebung

Tagungsraum

Weitere Teilnehmer

Product-Owner, Stakeholder

Voraussichtliche Dauer

Max. 1 h pro Zyklus

Vorgehensweise

Vorbereitung

Ein Moderator (meist der Projektverantwortliche) arbeitet sich in die Kundenanforderung oder in den zu spezifizierenden Bereich ein, den er vorstellen möchte. Der Moderator fungiert in der Regel auch als technischer Ansprechpartner für Rückfragen.

Der Moderator bereitet eine kurze Präsentation vor, die aber nicht den Eindruck einer vorab gefällten Designentscheidung erwecken sollte, die lediglich noch der nachträglichen Legitimation bedarf.

Das Gespräch an sich erfordert keine weiteren Vorbereitungen, da es von den anwesenden Personen mitgetragen wird.

Durchführung


Nach der kurzen Vorstellung durch den Moderator, beginnt die offene Diskussion in der Runde. Als Gesprächsgrundlage können Scribbles, Wireframes, UML-Diagramme oder jede andere Art der Präsentation und Visualisierung dienen. Nicht geeignet sind Ideensammlungen wie zum Beispiel Mindmaps. Die Anforderungen sollten technisch und begrifflich klar erfassbare sein.

Die Teilnehmer stellen üblicherweise zuerst Fragen, ob dieser oder jener Aspekt bereits berücksichtigt wurde; sie erkundigen sich, auf was es dem Auftraggeber besonders ankommt, welche Realisierungsmöglichkeiten der Kostenrahmen zulässt usw. Im weiteren Verlauf des Meetings beleuchten sie den ausgewählten Teil des Projektvorhabens genauer, schätzen Risiken und Entwicklungschancen ab, erarbeiten bevorzugte Lösungsansätze. Dem Moderator ist es ebenfalls erlaubt, seine Gedanken hinsichtlich der Realisierung zu äußern und Vorschläge zu unterbreiten. Dies ergibt sich natürlicherweise aus dem Umstand, dass er sich bisher am Intensivsten mit dem Thema auseinandergesetzt hat. Im Folgenden signalisiert er jedoch permanente Gesprächsbereitschaft und achtet ganz allgemein auf die Gesprächskultur.

Der Moderator notiert sich die Ideen und die bereits gefällten Entscheidungen genauso wie – zur späteren Klärung – die neuen Fragestellungen, die sich aus der Diskussion ergeben haben.

Nachbereitung

In der Regel reicht ein Iterationsschritt nicht aus, um alle Aspekte der Anforderung zu erfassen. Ziel des Best-Practice muss es sein, sich iterativ an die Lösung heranzutasten. Wie viel Zeit letztlich investiert werden muss, hängt unter anderem auch von der Komplexität der Anforderung ab. Alle konkreten Verbesserungsideen, die unterbreitet wurden, werden in die nachfolgende Präsentation eingearbeitet. Das Nachfolge-Meeting darf keinesfalls zu spät angesetzt werden.

Gütekriterien/Empfehlungen

Das Best-Practice dient dazu, die Anforderungen hinsichtlich ihrer Vollständigkeit zu ergänzen. Das Best-Practice ersetzt nicht die gesonderte Erstellung eines Pflichtenhefts. Es kann durchaus auch dabei helfen, unklare oder schwammig formulierte Anforderungen gleich zu Beginn der Umsetzung zu finalisieren. Letzteres sollte nicht die Regel sein, kommt in der Praxis jedoch immer wieder vor.

Risiken

Das Best-Practice setzt eine Gesprächskultur voraus, die fachliche Anforderungen als neue Herausforderungen begreifen. Der Team-Gedanke muss bereits etabliert sein. Ist das Gesprächsklima nicht offen, wird der Eindruck vermittelt, dass nicht jede Meinung und Idee willkommen sind. Die Gefahr besteht dann, dass die Bereitschaft zur Beteiligung und zur aktiven Mitarbeit rasch abnehmen.

Schlagworte

Teamentwicklung, Team-Geist, Motivation, gemeinsame Lösungsfindung, Zusammenarbeit, Abdeckungsgrad, Vollständigkeit, nicht-funktionale Merkmale, Qualitätsgedanke, Verständlichkeit, Realisierungsvorgabe

Weiterführende Informationen

Informationen im Internet

Literatur

Die Idee zu dem Best-Practice im Rahmen agiler Vorgehensweisen der Softwareentwicklung geht auf Frank Sembowski zurück. Es wurde seit der Einführung im Jahr 2011 zuerst in der YellowMap AG (http://www.yellowmap.com/) regelmäßig erfolgreich