Ich muss den Programmierern die Anforderungen für die Integration eines webbasierten Dienstes auf unserer Website erklären. Ich möchte die beste Struktur für eine solche Anfrage herausfinden.
Wie soll ich die gewünschten Funktionen aus nicht-technischer Sicht beschreiben?
Sie sollten keine Aufgaben für Techniker definieren. Stattdessen sollten Sie ein Wertversprechen und einige überprüfbare Akzeptanzkriterien beschreiben und dann Ihre technischen Experten loslassen, um eine Lösung zu finden, die den definierten Wert liefert, den Sie suchen.
User Stories sind ein gutes Mittel, um Werte zu definieren. Die Verwendung des Connextra-Standardformats „Rolle, Funktion, Grund“ ist ein guter Ausgangspunkt. Zum Beispiel:
Als Bankkunde
möchte ich eine Liste der letzten Transaktionen einsehen
können, damit ich mein Scheckbuch abgleichen kann .
Die Rolle (oder „Wertverbraucher“) definiert die beabsichtigte Zielgruppe des Features. Das Feature selbst beschreibt, was das Feature tun soll, und der Grund liefert einen gewissen Kontext darüber, warum der Benutzer das Feature möglicherweise möchte.
Die Funktion wird in Form von Ergebnissen beschrieben , anstatt die zugrunde liegende technische Implementierung anzugeben. Die Implementierung einzuschränken ist im Allgemeinen eine schlechte Idee. Stattdessen definieren Sie ein Geschäfts- oder UX-Ziel und lassen das technische Team den besten Weg finden, es zu erreichen.
Der Grund (oder "Kontext") ist ebenfalls sehr wichtig. Anhand des obigen Beispiels gibt es viele Möglichkeiten, eine Reihe von Transaktionen anzuzeigen. Indem Sie jedoch einen bestimmten Anwendungsfall (z. B. den Abgleich eines Scheckbuchs) beschreiben, geben Sie dem Team eine Anleitung, die ihm helfen kann, aus den verfügbaren Optionen die beste technische Implementierung auszuwählen, um das Ziel zu erreichen.
Das Wichtigste, was man tun kann, ob mit User Stories oder Spezifikationen, ist sicherzustellen, dass die Ziele testbar dargestellt werden . Wenn es nicht testbar ist, ist es schwierig, eine echte Einigung zwischen dem Geschäfts- und dem technischen Team zu erreichen.
Unter Verwendung der obigen Beispielgeschichte könnte man die Ausgabe der Funktion verwenden, um ein Musterscheckheft abzugleichen. Sie und das technische Team könnten wie folgt ein Konto für John Doe definieren:
Dies kann dann durch manuelle oder automatisierte Tests verifiziert werden. Wenn der Test bestanden wird, wurde das Feature erfolgreich bereitgestellt und kann in Zukunft sogar noch weiter verfeinert werden. Wenn die Tests fehlschlagen, wird offensichtlich immer noch eine funktionierende Lösung benötigt.
Vergleichen Sie die Ratschläge zu guten User Storys mit einer vagen User Story wie:
Wie jeder
möchte ich eine hübsche Liste von Transaktionen
mit einer attraktiven Schriftart sehen.
Diese Art von Geschichte ist völlig subjektiv und kann nicht getestet werden. Wer wird diese Funktion nutzen? Was ist "hübsch"? Welche Schriftart wird als attraktiv angesehen? Weder das technische Team noch das Geschäft können mit solchen handgewunkenen Kriterien Erfolg haben.
Andererseits ist Überspezifikation auch nicht Ihr Freund. Betrachten Sie dieses Beispiel:
Als Benutzer 321
möchte ich genau 10 Schecktransaktionen sehen, die
in einer serifenlosen 6-Punkt-Schrift mit dem Namen "Obscure Sans" angezeigt werden.
Diese Art von Spezifikation ist wahrscheinlich testbar, schränkt die Lösung jedoch übermäßig ein. Die implementierte Lösung gilt möglicherweise nur für einen einzelnen Benutzer, der mithilfe einer numerischen ID angegeben werden muss. Es adressiert nicht alle möglichen Grenzfälle (z. B. was passiert, wenn Benutzer 321 insgesamt nur 6 Transaktionen hat?) und erzwingt eine technische Implementierung, wie z. B. eine bestimmte Schriftartauswahl, die möglicherweise in allen Browsern funktioniert oder sogar lesbar ist in der angegebenen Schriftgröße.
Sowohl vage Geschichten als auch überspezifizierte Geschichten führen wahrscheinlich zu Fehlfunktionen oder regelrechten Fehlern. Wenn Sie jedoch irren müssen, dann zumindest auf der Seite der Testbarkeit!
Geschichten sollten immer betriebswirtschaftlich definiert werden. Warum muss es eine Web-Integration geben? Für wen ist es? Was genau muss es leisten?
Wenn es nicht direkt mit einer Geschäftsanforderung zusammenhängt (für die Webintegration unwahrscheinlich, aber theoretisch möglich), dann sollte es stattdessen eine Entwickleraufgabe sein und daher von einem Entwickler definiert werden.
Entwickler definieren Entwickleraufgaben. Nicht-Entwickler definieren Geschäftsgeschichten – wenn weitere technische Details ausgefüllt werden müssen, können die Entwickler dies selbst tun. Dies sollte idealerweise in Zusammenarbeit mit jemandem geschehen, der den geschäftlichen Aspekt versteht, um schnell Missverständnisse darüber aufzudecken, was die Geschichte eigentlich bewirken soll.
Stellen Sie sich vor, Sie gehen ins Krankenhaus und treffen sich mit einem Arzt, der Ihnen helfen soll, weil Sie Schmerzen in der Brust haben. Sagen Sie dem Arzt sofort: "Ich habe ein Herzproblem, ich habe gerade WebMD gelesen, ich brauche eine Herztransplantation, planen Sie sie für morgen"? Natürlich können Sie sicher verstehen, warum ein Arzt unter diesen Umständen grinsen könnte.
Was Sie normalerweise tun, ist zu sagen: "Ich habe Schmerzen in meiner Brust, es hat vor einer Stunde angefangen". Der Arzt könnte fragen: "Was hast du zu Mittag gegessen?". Sie könnten einen Bluttest machen oder ein EKG machen. Sie könnten zu dem Schluss kommen, dass Sie nur sauren Reflux haben.
Mein Punkt ist... Eine "Integration" ist eine Lösung. Kein Problem. Erklären Sie das Problem. Techniker werden abgeschreckt, wenn Nicht-Techniker mit Lösungen auf sie zukommen. Nicht-technische Menschen neigen dazu, wenn überhaupt, nur zufällig auf gute technische Lösungen zu stoßen (Betonung des Nicht-Technischen). Ja, ab und zu gibt es ganz versierte Leute, die die Ausnahme sind... Aber am besten stellt man sich dumm und lässt die Techniker selbst kommen. Sie hatten zu viele Zusammenstöße mit der Norm, die sie eines Besseren belehren.
Stimme @codegnome größtenteils zu und fasse nur meine 2 Cent zusammen und füge sie hinzu
Piotr Uryga