Das Ziel definieren

“Nur wer sein Ziel kennt, findet den Weg”, Laozi

Ganz so eng würde ich es nicht formulieren, da auch und gerade in der Softwareentwicklung verschiedene Wege zum Ziel führen. Geht es aber um einen effizienten Weg, so ist klar, dass dieser möglichst ohne Holzwege auskommen sollte. Änderungsaufwände, weil ein Ergebnis nicht den Vorstellungen des Anwenders entspricht, sind in dieser Hinsicht natürlich kontraproduktiv.

Insofern ist es natürlich immens wichtig, dass Anwender und Entwickler möglichst früh eine gemeinsame Vorstellung darüber entwickeln, was das Ziel des nächsten Entwicklungsschrittes ist. Wird dieser Phase nicht genügend Aufmerksamkeit gewidmet, so sind Missverständnisse und enttäuschte Erwartungen vorprogrammiert.

Dies ist mitunter eine echte Geduldsprobe, weil die Beteiligten sich ausreichend Zeit nehmen müssen. Für viele Anwender ist dies schwierig, weil sie die Mitarbeit im Entwicklungsprojekt zusätzlich zu ihrem Tagesgeschäft erledigen. Auf Entwicklerseite ist insofern Geduld gefragt, dass die meisten Entwickler glücklicherweise gerne Software entwickeln, dadurch aber manchmal zu schnell in die Entwicklung einsteigen.

Geduld lohnt sich an dieser Stelle jedoch definitiv, weil so der Grundstein dafür gelegt wird, dass ein gutes Ergebnis erreicht wird, das den Erwartungen aller Beteiligten gerecht wird. Im folgenden habe ich einige bewährte Vorgehensweisen zusammengestellt, um diese Phase unabhängig vom Entwicklungsprozess und der Größe des Vorhabens erfolgreich zu gestalten:

Nehmen Sie sich die Zeit, die Fachdomäne zu verstehen

Ich weiß aus eigener Erfahrung, dass sich die Perspektiven eines Anwenders und eines Entwicklers fundamental unterscheiden. In meiner ersten Station nach dem Studium habe ich eine Anwendung zur Kostenrechnung entwickelt, die auch heute noch im Einsatz ist. Mittlerweile zähle ich ebenfalls zum Kreis der Anwender und ermittle mit der Software einige Kennzahlen für unser Unternehmen. Dieser Perspektivenwechsel war eine sehr wertvolle Erfahrung für mich, weil er mir vor Augen geführt hat, wie unterschiedlich die Fragestellungen sind, die sich Entwickler und Anwender stellen.

Naturgemäß verstehen Entwickler die wichtigen Bestandteile der Arbeit eines Anwenders nicht so gut, wie derjenige, der die Aufgaben täglich ausführt und im Detail weiß,

• warum die Aufgaben für das Unternehmen wichtig sind.
• wie die einzelnen Prozessschritte zusammenhängen und aufeinander aufbauen.
• welche Informationen zu welchem Zeitpunkt notwendig sind.
• welche weiteren Beteiligten an einem Prozess mitarbeiten.

Beim Erkunden der Domäne des Anwenders lohnt es sich, diese losgelöst von aktuellen Rahmenbedingungen wie z.B. der aktuell eingesetzten Software zu betrachten und sich schrittweise vom Gesamtkontext zu den Details vor zu arbeiten.

Richtige und falsche Fragen

Die Erkenntnis, dass es grundsätzlich keine falschen Fragen gibt, unterstütze ich natürlich. Nichtsdestotrotz gibt es Fragen, die das Design in eine falsche Richtung lenken können, wenn sie zu früh im Planungsprozess gestellt werden.
Beispielsweise ist es für ein gutes Benutzererlebnis wichtiger, den Prozess des Anwenders zu verstehen, als im Detail zu wissen, welche Daten gespeichert werden müssen.

Folgende Auflistung bietet einen Einstieg in die Analyse:

1. Warum wird der Prozess ausgeführt? Was will die Organisation des Anwenders damit insgesamt erreichen?
2. Wann, wie häufig und von wem wird der Prozess gestartet?
3. Welche Eingangsinformationen müssen vorhanden sein?
4. Was ist das Ergebnis des Prozesses und wer benötigt dieses?
5. Welche Teilschritte gibt es? Wer übernimmt diese und wer wird über den Fortgang informiert?
6. Wann ist der Prozess beendet?
7. Welche Daten entstehen in den Teilschritten? Zu welchen Schritten und für wen sind sie relevant?

Diese offene Herangehensweise stellt sicher, dass man sich nicht zu früh auf bestimmte, vermeintlich gesetzte Rahmenbedingungen festlegt. Verzichtet man beispielsweise darauf, sich detailliert mit den am Prozess Beteiligten zu befassen, kann das dazu führen, dass die Funktionalität in einem System umgesetzt wird, das von einigen Beteiligten gar nicht genutzt wird.

Entwerfen Sie ein gemeinsames Bild mit dem Anwender

Um die Zielvorstellung möglichst plastisch darzustellen, reichen Worte in den meisten Fällen nicht aus. Erst durch Diagramme und Bilder wird das angestrebte Ergebnis wirklich greifbar. Bereits am Anfang sollten die wichtigen Prozesse beispielsweise in Form von Swim Lane Diagrammen festgehalten werden.

Zur Darstellung von Oberflächen sind Wireframes gut geeignet. Noch besser sind natürlich Mockups, die es ermöglichen, dass der Anwender interaktiv durch die Anwendung navigiert.

Wichtig ist dabei, dass die Wireframes und Mockups ganz bewusst unfertig wirken und mehr Wert darauf gelegt wird, wie der Anwender mit der Oberfläche interagiert. So ist allen Beteiligten klar, dass dies nur ein Entwurf ist, der mit geringem Aufwand geändert werden kann.

Folgende Tools eignen sich gut zum Storyboarding:

• Visual Studio Storyboarding
• Pencil
• Nicht zuletzt: Papier, Bleistift und ein Kopierer

Warum Rapid Prototyping manchmal kontraproduktiv ist

Beim gemeinsamen Storyboarding liegt es natürlich nahe, Rapid Prototyping einzusetzen und die Ergebnisse des Designs umgehend mit einem programmierten Prototypen zu untermauern. Während dies bei kleinen Umsetzungsschritten in einer vorhandenen Systemumgebung durchaus ein gangbarer Weg ist, sollte man jedoch folgendes beachten:

• Rapid Prototyping kann dazu verleiten, wichtige Entscheidungen zu früh in der Designphase zu treffen und sich beispielsweise schon in der Anfangsphase darauf festzulegen, dass eine SmartClient-Anwendung erstellt werden soll. Dies führt dazu, dass andere, möglicherweise bessere Lösungen nicht mehr in Betracht gezogen werden.
• Beim Rapid Prototyping wird manchmal mehr in einen Prototypen investiert, als wirklich notwendig wäre. Sinn und Zweck eines Prototypen ist ja lediglich, dass Unsicherheiten verringert werden und ein besseres Gefühl für die sinnvolle Lösung erreicht wird. Immer unter der Prämisse, dass ein Prototyp auch weggeworfen werden kann, wenn man feststellt, dass er nichts sinnvolles in Richtung des Ergebnisses beiträgt. Die Grenze zwischen notwendigen Inhalten des Prototypen und Bereichen, die auch später implementiert werden können, verwischt beim Rapid Prototyping oft, so dass am Ende bereits viel Aufwand in den Prototypen geflossen ist und das Wegwerfen keine Option mehr ist.
• Das Ändern von Quelltext ist im Vergleich zum Ändern von Mockups verhältnismäßig aufwändig.
• Ein so erstellter Prototyp sieht oft schon sehr fertig aus und vermittelt dadurch den Eindruck, dass gar nicht mehr allzu viel zu tun ist. Da bei einem Prototypen aber immer noch wesentliche Funktionalitäten fehlen, sollte der weitere Aufwand zur Implementierung nicht unterschätzt werden.

Detaillieren Sie größere Vorhaben über mehrere Stufen

Während es vielen Stakeholdern genügt, die grobe Richtung eines Projekts zu kennen, ist es für Entwickler am einfachsten, auf Basis von überschaubaren Anforderungen zu arbeiten, deren gewünschtes Ergebnis klar definiert ist. Andernfalls ist das Risiko zu groß, dass das erreichte Ergebnis nicht den Erwartungen entspricht. Vor Entwicklungsbeginn müssen die Anforderungen also geschärft und möglichst feingranular aufgeteilt werden.

Da es in vielen Projekten aufgrund deren Größe und Komplexität nicht möglich ist, dies en bloc am Anfang zu erledigen, versprechen agile Vorgehensweisen gute Ergebnisse, weil die Detaillierung der Anforderungen Stück für Stück erfolgt und so Kurskorrekturen möglich sind. Nichtsdestotrotz ist es auch bei agilen Projekten sinnvoll, einen Zielrahmen für das Gesamtprojekt festzulegen, um sicherzustellen, dass das Projekt in die richtige Richtung läuft. Natürlich kann auch dieser Rahmen zwischenzeitlich geprüft und angepasst werden.

Der Microsoft Team Foundation Server unterstützt in seinen Planungstools die hierarchische Anordnung der Arbeitsaufgaben (“Work Items”):

• Initiativen dienen dazu, strategische Vorhaben für ein Produkt zu beschreiben.
• Features stellen zusammengehörige Funktionsgruppen dar.
• User Stories sind die Arbeitsaufgaben, die in agile Sprints eingelastet werden. Die Definition und das Priorisieren der User Stories übernimmt im Scrum der Product Owner als Vertreter der Anwender, wobei dieser von den Teammitgliedern unterstützt wird. Neben einer Beschreibung erhalten User Stories auch Akzeptanzkriterien, die definieren, welche spezifischen Bedingungen erfüllt sein müssen, damit der Produkt Owner die User Story abnehmen kann.
• Tasks sind die Arbeitsaufgaben der Teammitglieder. Im Sprint Planning werden diese erstellt, um die Anforderungen einer User Story abzubilden.

Es ist sinnvoll, in jeder Ebene das erwartete Ergebnis zu definieren - natürlich mit ansteigender Granularität. Die Pflege des aktuellen Zustands sollte auf allen Ebenen erfolgen, um einen schnellen und einfachen Überblick über den Stand zu gewährleisten, der für den jeweiligen Stakeholder-Kreis angemessen ist.

Es gibt viel zu tun, packen wir’s am Anfang an

Wie bereits eingangs erwähnt, ist die Zieldefinition je nach Projektgröße durchaus eine zeitliche Investition, die in der Hektik des Arbeitsalltags manchmal nicht die notwendige Aufmerksamkeit erhält. Es gibt jedoch wenige Investments, die sich in der Ergebnisqualität derart widerspiegeln, denn:

“Wer nicht genau weiß, wohin er will, der darf sich nicht wundern, wenn er ganz woanders ankommt.”, Mark Twain