Im Artikel Essenzielle Fähigkeiten einer Softwarefirma identifizierte ich die folgenden, zentralen Fähigkeiten, die m.E. jede Softwarefirma haben sollte: Kunden finden, verkaufen, Wert schaffen, lernen, managen, Mitarbeiter entwickeln. Unter Wert schaffen verstehe ich wiederum: Das, was der Kunde braucht, zu verstehen, zu planen, zu bauen und zu liefern. Heute möchte ich näher auf das Thema „Verstehen“ eingehen. Was bedeutet das?
Verstehen
Ihr Kunde und Ihre Softwarefirma sind Teile einer Wertschöpfungskette. Ihre Teams haben die Fähigkeit, Software zu entwickeln oder Dienste zu leisten. Ihr Kunde sucht diese Software oder Dienstleistungen, um seine eigenen Fähigkeiten zu steigern. Diese Fähigkeiten vermarktet er wiederum an seine Kunden und bekommt Geld dafür. Einen Teil des Geldes gibt er Ihnen für die gelieferte Software oder Dienstleistung.
Vision
Lassen wir die Kette der Vision des Kunden beginnen bzw. mit einem Ausschnitt daraus, einem seiner Geschäftsziele. Beispiel: Der Kunde gibt eine Zeitung heraus, zu der er auch einen Online-Auftritt im Web anbietet. Sein Ziel ist, die Zahl der Abonnenten zu steigern und mehr Zeitungen zu verkaufen. Im Kopf des Kunden ist die Idee, die Leser der Zeitung besser in den Online-Auftritt einzubinden, indem er ihnen die Möglichkeit gibt, die Artikel zu kommentieren und zu diskutieren. Das bindet die Leser besser an diese eine Zeitung, und außerdem bekommen die Redakteure dadurch mehr Ideen, worüber sie als Nächstes schreiben könnten.
Fähigkeit und Features
Sie bekommen also den Auftrag, den Online-Auftritt der Zeitung so anzureichern, dass der Dialog der Zeitung mit den Lesern möglich wird. Dieser Dialog soll später zu den Fähigkeiten des Kunden gehören, zu sehen auf der linken Seite des Bildes. Der Kunde hofft, diese Fähigkeit wird der Zeitung einen Wert einbringen, in Form von treueren Lesern oder mehr Abonnenten.
Im Gespräch mit Ihren Teams stellt der Kunde fest, dass folgende Features in der Software nötig sind, um die Fähigkeit zum Dialog auszubilden:
Artikel kommentierenDie Leser sollen zu einem Artikel, den sie gerade gelesen haben, Kommentare abgeben können. Die Website stellt die Kommentare nach dem Artikel dar.Kommentar moderierenDie Redakteure der Zeitung sollen eingehende Kommentare prüfen und bei ungeeignetem Inhalt ablehnen können.Die Redakteure der Zeitung sollen einzelne Benutzer sperren können, falls sie wiederholt ungeeignete Kommentare abgeben.Identität des Kommentierenden prüfenKommentare sollen nicht anonym sein, sondern jeweils einem bestimmten Benutzer der Website zuzuordnen sein. Der Benutzer muss sich also authentifizieren, bevor er anfängt, Kommentare einzugeben.
Während Sie diese Features mit dem Kunden gemeinsam analysieren, behalten Sie immer im Hinterkopf, dass die Features dazu dienen sollen, eine bestimmte Fähigkeit des Kunden auszubilden, nämlich den Dialog der Zeitung mit den Lesern. Aus Features, die Sie gemeinsam mit dem Kunden finden und analysieren, entsteht die erste Granularitätsstufe der Nachfrage. Das ist es, was der Kunde von Ihren Teams bekommen will und für was er bereit sein wird, zu bezahlen: Eine Lösung aus fertig entwickelter, lauffähiger, getesteter und angemessen dokumentierter Software, zu sehen in der Mitte des Bildes.
Story
Jedes Feature ist eine Gruppe von zusammengehörenden Funktionen des Systems. Die zukünftigen Benutzer des Systems können mit jeder dieser Funktionen eine Geschichte erzählen, die den Umgang des Benutzers mit dem System beschreibt – eine so genannte User Story. Zu den oben genannten Features könnten Ihre Teams mit dem Kunden die folgenden User Stories identifiziert haben:
Artikel kommentierenAls Leser möchte ich einen neuen Kommentar hinzufügen, um meine Meinung zu einem Artikel zu sagen und mit anderen Lesern ins Gespräch zu kommen.Als Leser möchte ich alle meine bisher eingegebenen Kommentare auflisten, um nachzusehen, ob ich noch etwas ändern möchte.Als Leser möchte ich einen eingegebenen Kommentar überarbeiten, um sicherzustellen, dass er wirklich meine Meinung wiedergibt.Als Leser möchte ich einen eingegebenen Kommentar zurücknehmen, weil ich inzwischen meine Meinung geändert habe.Kommentar moderierenAls Redakteur möchte ich neue Kommentare auflisten, um festzustellen, was die Leser über einen Artikel denken.Als Redakteur möchte ich einen einzelnen Kommentar sperren, um sicher zu sein, dass qualifizierte Äußerungen und offene Diskussion anstatt Zank und Streit auf der Website herrschen.Als Redakteur möchte ich einen kommentierenden Benutzer sperren, um notorische Streithähne auszuschließen.Identität des Kommentierenden prüfenAls Leser möchte ich mich anmelden, um kommentieren zu können und sicherzustellen, dass mir meine Kommentare später noch zur Verfügung stehen.Als Leser möchte ich mich abmelden, um sicher zu sein, dass niemand in meinem Namen einen Kommentar einstellt, wenn ich einen öffentlichen Computer verlassen habe.Als Leser möchte ich mein Kennwort zurücksetzen, wenn ich es vergessen habe.Als Leser möchte ich eine OpenID hinzufügen, um nicht immer für jede Website ein eigenes Kennwort merken zu müssen.
Beispiele
Menschen denken in Beispielen. Beispiele haben im Verstehensprozess eine ganze Reihe von Vorteilen:
- Beispiele sind eine Möglichkeit, um zu klären, was der Kunde mit einer User Story genau gemeint hat.
- Beispiele erforschen Grenzbedingungen, unter denen eine Story anders abläuft als normalerweise.
- Beispiele helfen, Geschäftsregeln zu finden, die in einer Story gelten müssen.
- Beispiele liefern Testdaten, mit denen die lauffähige Story später getestet werden kann.
- Beispiele lassen sich in Akzeptanz- oder Regressionstests verwandeln und automatisieren, um sicherzustellen, dass die Software auch bei Veränderungen nicht an Funktionalität einbüsst.
In natürlicher Sprache abgefasste Stories können noch mehrdeutig sein, weil natürliche Sprache von verschiedenen Personen unterschiedlich interpretiert wird. Deshalb ist es gut, wenn sich der Kunde, die Anforderungsanalysten, die Entwickler und die Tester zusammenfinden, um Beispiele zu den Stories miteinander durchzugehen. Das fördert das gemeinsame Verständnis und vergrößert die Chance, dass man gleich jetzt (und nicht erst beim Codieren) feststellt, was die wahre Bedeutung einer Story ist.
Ein Beispiel für Beispiele: Ihre Entwickler sind mit dem Kunden die Anforderungen durchgegangen und haben die oben genannten Stories aufgeschrieben. Dabei fiel den Entwicklern auf, dass noch nicht so recht klar ist, wann ein Kommentar nun wirklich „live“ auf der Website zu sehen sein wird: gleich nach der Eingabe oder erst nachdem ein Redakteur den Kommentar freigibt. Die Stories hören sich an, als ob der Kommentar erst einmal live geht und erst im Nachhinein durch einen Redakteur gesperrt werden kann. Die Entwickler formulieren deshalb das folgende Beispiel:
- Hans (ein Leser der Zeitung) fügt folgenden Kommentar hinzu: „Der Schreiberling, der diesen Artikel verfasst hat, hat ja wohl überhaupt keine Ahnung, von was er redet. Erstens weiß er nicht, worum es geht und zweitens drückt er es auch noch schlecht aus.“
- Die Website der Zeitung stellt den Kommentar sofort ins Netz.
- Rudolf (ein Redakteur) kommt am nächsten Tag ins Büro und lässt sich neue Kommentare auflisten. Er entdeckt den provozierenden Kommentar von Hans.
- Rudolf lässt das System diesen einzelnen Kommentar sperren.
- Die Website stellt ab jetzt nur noch den Anfang des Kommentars und die Bemerkung „vom Moderator gesperrt“ dar.
Dieses Beispiel kann zu mehreren gesunden Dialogen zwischen Fachbereich und Entwicklung führen. Einerseits könnte ein Gespräch über die Frage entstehen, ob die Redaktion jeden Kommentar zuerst genehmigen möchte, bevor er live auf die Website geht, um zu verhindern, dass solche Bemerkungen ins Netz kommen. Vielleicht möchten die Redakteure angesichts der großen Zahl von Kommentaren, die kommen werden, nicht jeden genehmigen sondern nur die unqualifizierten sperren. Vielleicht möchten die Redakteure aber später eine weitere User Story „Negativ gestimmte Kommentare automatisch erkennen“, um der großen Zahl noch Herr zu werden. Oder sie möchten eine Geschäftsregel, die sagt: Wenn drei Kommentare eines Lesers genehmigt wurden, werden von da an alle automatisch genehmigt.
Sie sehen, solch ein Beispiel führt zu intensiven Gesprächen über das, was die Software später tun soll.
Zusammenfassung
Das bedeutet für mich Verstehen: Aus der Vision und den Zielen des Kunden Fähigkeiten ableiten, die er gerne hätte. Dann diese Fähigkeiten mit Hilfe von Software-Features unterstützen. Diese Features in erzählbare Stories aufteilen und die mit Hilfe von Beispielen verständlich und später testbar machen.
