Wie kann man bei BDD Specifications Workshops erfolgreich sein?

Heute haben wir versucht, BDD durch einen Spezifikationsworkshop in unseren Softwareentwicklungsprozess einzuführen.

Für diesen Workshop hatten wir 2 Entwickler, 1 Tester und 1 Business Analyst. Der Workshop dauerte 1:30 Uhr und am Ende konnten wir einige BDD-Szenarien für unser neues Feature herausfinden. Wir haben versucht, uns darauf zu konzentrieren, die Szenarien zu finden, die wir verpassen könnten, und die schwierigen.

Am Ende des Workshops waren einige Leute tatsächlich mit dem Workshop unzufrieden.

Ein Entwickler hatte das Gefühl, seine Zeit verschwendet zu haben, da er die Szenarien direkt vom Business Analyst erhalten und mit ihr besprochen hatte. Die Business Analystin war mit unserer Berichterstattung über Szenarien nicht zufrieden (hatte das Gefühl, dass wir andere wichtige Dinge hätten verpassen können), aber was noch wichtiger ist, dass dieser Workshop auch Zeitverschwendung war, da sie all diese Szenarien selbst hätte herausfinden können und in kürzerer Zeit .

Dieser experimentelle Workshop dauerte 1h30, und am Ende waren wir nicht sicher genug, was wir getan haben ... sicher, wir hätten mehr Zeit damit verbringen können, aber ehrlich gesagt sind die meisten Leute nach 1h30 Brainstorming erschöpft, um Geschäfte zu machen Regeln aus dem BA-Gehirn.

Meine Frage ist also, wie diese Art von Workshop tatsächlich funktionieren kann. Wenn Sie in der Theorie ein neues Feature entwickeln müssen, platzieren Sie den Baum 'amigos' (dev / tester / ba) im selben Raum, damit sie zusammenarbeiten können, um anhand der Beispiele die unterschiedlichen Anforderungen für das neue Feature zu schreiben. Ich kann alle Vorteile davon sehen. Speziell in Bezug auf Wissensaustausch und gemeinsames Produkt / Endziel / erledigte Vision.

Unsere Schlussfolgerung aus diesem Experiment war, dass es tatsächlich kostengünstiger ist, zuerst einen BA zu haben, um selbstständig an den Beispielen zu arbeiten, und erst dann die Szenarien, die von den 3 'Amigos' überprüft / überarbeitet werden müssen.. Indem wir den BA alleine arbeiten lassen, sind wir tatsächlich zuversichtlicher, dass wir weniger Dinge verpassen werden + wir können die Szenarien danach noch überprüfen, um sie noch einmal zu überprüfen. Wir glauben nicht, dass eine einfache einmalige Brainstorming- / absichtliche Entdeckungssitzung tatsächlich ausreicht, um alle Anforderungen für eine neue Funktion ernsthaft abzudecken. Der Business Analyst ist tatsächlich die beste Person für solche Dinge. Das Beste, was wir tun können, ist zu überprüfen, was sie geschrieben hat, und zu prüfen, ob wir dann ein gemeinsames Verständnis haben (was dann dazu führen könnte, dass einige ihrer Szenarien neu geschrieben oder neue hinzugefügt werden, die sie möglicherweise übersehen hat).

Wie können Sie das in der Praxis effektiv umsetzen ?

Wenn Sie die Szenarien aus der Beschreibung ableiten können, sind Sie fertig.

Ein Anti-Muster, das ich in BDD oft sehe, sind Menschen, die das Bedürfnis verspüren, jedes Szenario im Detail durchzusprechen und aufzuschreiben .

Einige Szenarien sind so gut verstanden, dass es ausreicht, sie aus einer kurzen Beschreibung abzuleiten. Wenn ich zum Beispiel sage: "Ich möchte diese Woche die Anmeldefunktion", wissen Sie, wie das aussehen sollte. Sie wissen, dass es Szenarien für das richtige Passwort, das falsche Passwort, den falschen Benutzernamen gibt. Wir müssen diese nicht wirklich durchsprechen oder detailliert erfassen.

In ähnlicher Weise könnte ich sagen: "Hier ist das Formular für die Benutzerregistrierung. Wir müssen in der Lage sein, neue Benutzer zu erstellen, sie ihre Details bearbeiten zu lassen und sich selbst zu löschen, außer dass das Löschen nicht wirklich gelöscht werden sollte, sondern sie nur als gelöscht markieren sollte so können sie ihre Konten wiederherstellen, wenn sie wollen. "

Und Sie können fragen: "Ist die Kontowiederherstellung Teil dieser Funktion?"

"Sie können zwei Funktionen sein, wenn Sie wollen."

"Okay, wir haben also Szenarien zum Erstellen, Lesen, Aktualisieren und Löschen. Das sollte einfach genug sein. Lassen Sie uns über die Wiederherstellung von Konten sprechen. Das klingt interessanter."

Wenn die Beschreibung des Verhaltens für das Entwicklerteam ausreicht, um die Szenarien abzuleiten, müssen Sie sie im Allgemeinen nicht durchsprechen. Sie können dies tun, wenn Zweifel bestehen, aber Sie möchten möglicherweise nur erfassen, an welche Szenarien Sie sich erinnern müssen, wenn Sie überhaupt welche erfassen.

Wenn Sie es noch nie getan haben oder sich nicht sicher sind, sprechen Sie die Szenarien durch.

Konzentrieren Sie sich auf die Bereiche, die ungewöhnlich sind, insbesondere wenn es Funktionen gibt, die Sie noch nie zuvor ausgeführt haben. Dies sind fantastische Orte, um Gespräche zu führen und überraschende Beispiele aufzuschreiben. Normalerweise stelle ich zwei Fragen, basierend auf der BDD-Vorlage:

Gegebener Kontext
Wenn ein Ereignis
eintritt, sollte ein Ergebnis eintreten.

• Gibt es einen anderen Kontext, der für dasselbe Ereignis zu einem anderen Ergebnis führt?
• Gibt es ein anderes Ergebnis, das ebenfalls wichtig ist?

Wenn alle am Tisch gelangweilt aussehen, ist die Funktion, über die Sie sprechen, wahrscheinlich gut verstanden. Es ist oft genug zu sagen: "Es sollte wie X funktionieren , aber stattdessen mit Y. " Dies nennt Dan North das Ingwer-Kuchen- Muster. Es ist wie das Rezept für Schokoladenkuchen, aber mit Ingwer anstelle von Schokolade.

Selbst wenn der Geschäftsinteressent in der Lage ist, die Szenarien selbst abzuleiten, ist es für das Entwicklerteam sehr wichtig, mit ihm sprechen, seine Sprache lernen und verinnerlichen zu können. Diese Sprache wird dann in den Code übernommen, sodass sie in Zukunft bessere Gespräche führen und Neulingen im Projekt helfen können, zu verstehen, was vor sich geht. Wenn die Entwickler die Sprache nicht sprechen können , werden sie sie nicht verwenden .

Wenn der Geschäftsinteressent oder Analyst wirklich nicht die Zeit damit verbringen möchte, Dinge in der Sitzung zu erfassen, würden die Entwickler die Szenarien lieber in Zusammenarbeit mit den Testern aufschreiben und ihn dann bitten, sie zu überprüfen. Dies führt eher zu Missverständnissen als umgekehrt.

Manchmal funktioniert BDD nicht.

Eine andere Möglichkeit besteht darin, dass Sie ein Szenario finden, über das der Geschäftsinteressent unsicher ist. "Oh, daran hatte ich nicht gedacht! Ich bin mir nicht sicher." Anstatt zu versuchen, das Geschäft festzunageln und das Geschäft mit Sicherheit zu bestrafen, kann es sich lohnen, BDD an dieser Stelle aufzugeben und etwas Einfaches auszuprobieren, um Feedback zu erhalten und dem Geschäft etwas zu geben, über das sie iterieren können. Halten Sie es einfach, Änderungen vorzunehmen, und schreiben Sie die Szenarien, sobald Sie besser verstanden haben, was vor sich geht.

Gut gemachtes BDD kann wirklich helfen, Orte der Unsicherheit aufzudecken. Da jedes Projekt, das es wert ist, durchgeführt zu werden, einen Aspekt hat, der neu ist und noch nie zuvor durchgeführt wurde, besteht irgendwo eine gewisse Unsicherheit. Wenn Sie sich darauf konzentrieren, die Szenarien zu verwenden, um Unwissenheit bewusst zu entdecken , lernen Sie schneller, und das Lernen macht normalerweise einen großen Teil der für ein Projekt aufgewendeten Zeit aus.

Außerdem habe ich festgestellt, dass je mehr Entwicklerteams auf diese Weise zusammenarbeiten, desto mehr das Unternehmen bereit ist, ihnen mit Unsicherheit zu vertrauen, und desto mehr Innovationen beginnen. Innovative Unternehmen haben naturgemäß viel Unsicherheit in ihren Projekten.

Ich habe vor einiger Zeit einen Blog-Beitrag über Cynefin geschrieben , der mir wirklich hilft zu verstehen, wo die Gespräche am effektivsten sind. Wenn Sie es lesen und die vier Domänen verstehen, sind hier die Regeln, die ich verwende:

• Einfache und komplizierte Dinge (bekannt) sind oft gut verstanden und Sie müssen die Szenarien nicht im Detail durchgehen.

• Hochkomplexes Zeug (unbekannt) wird überhaupt nicht verstanden. Sie können dies feststellen, indem Sie die Szenarien durchgehen. Der Mangel an Sicherheit bedeutet, dass BDD hier nicht funktioniert. Wiederholen Sie daher etwas, das leicht zu ändern ist, und erhalten Sie stattdessen schnelles Feedback. Jede Praxis, die Ihre Optionen beibehält, wie z. B. AB-Tests, ist auch in diesem Bereich großartig.

• BDD arbeitet hervorragend im Zwischenraum (erkennbar) als Mechanismus zur Weitergabe von Wissen und zur Aufdeckung der beiden anderen Räume. Es ist kein Hammer und nicht alles ist ein Nagel. Wenn Sie die Zeit, die Sie mit Gesprächen verbringen, auf etwas konzentrieren können, geht es nicht um die Beispiele, die Sie finden können. Es geht darum , Beispiele zu finden, die Sie nicht finden können .

Die Länge des Meetings ist nicht Ihr Problem. Es ist in Ordnung, dass diese Besprechungen lange dauern. ABER jeder sollte sich sicher fühlen. Dass sie es nicht getan haben, ist dein Problem.

Ich würde ein kurzes Treffen vorschlagen, um eine Anforderung zu besprechen. Planen Sie ein paar Tage später ein zweites Treffen, damit jeder weiß, dass er bis dahin vorbereitet sein muss.

Dann sollten BA und Tester jeweils ihre Szenarien entwickeln, da beide Software auf sehr unterschiedliche Weise betrachten. Lassen Sie sie sie auf Karten schreiben und sie alle mindestens einen Tag vor dem zweiten Treffen irgendwo auf eine Tafel kleben. Lassen Sie alle in ihrer eigenen Zeit durchsehen und darüber nachdenken. Werfen Sie alle Duplikate weg und halten Sie alle Szenarien fest, die nicht berücksichtigt wurden.

Werfen Sie nichts weg, mit dem Sie nicht einverstanden sind, sondern markieren Sie es als umstritten. Wenn ein sehr kurzes Gespräch mit der Person, die es geschrieben hat, hilft, tun Sie das, aber speichern Sie es meistens.

DANN haben Sie Ihr Planungs- / Designtreffen. Haben Sie eine solide Agenda für dieses Meeting (beginnen Sie mit dem Kartenstapel, setzen Sie die umstrittenen oben ein) und lassen Sie es nicht vom Weg abkommen. Stellen Sie sicher, dass Sie aus diesem Meeting herauskommen und alle Streitpunkte gelöst sind.

Stellen Sie immer sicher, dass jeder in einer Besprechung auf das Thema dieser Besprechung vorbereitet ist!

Verwenden Sie niemals ein Meeting, um gemeinsam ein Brainstorming durchzuführen. Es verschwendet jedermanns Zeit.

Allgemeines Rezept für effektive Besprechungen:

• Lassen Sie die zu diskutierenden Punkte von jemandem vorbereiten
• Alle Teilnehmer müssen diese Gegenstände studiert (und nicht nur gelesen) haben
• Sammeln Sie vorher Kommentare und setzen Sie voraus, dass alle Teilnehmer diese studiert (nicht nur gelesen) haben
• Halten Sie das Meeting ab, um Entscheidungen zu treffen

Über die Beschwerden ...

Beginnen wir mit diesen:

Ein Entwickler hatte das Gefühl, dass er seine Zeit verschwendet hatte, da er die Szenarien direkt vom Business Analyst erhalten und mit ihr besprochen hatte.

Welches ist, was er in der Werkstatt tat. Das scheint mir eine launische und schlechte Ausrede zu sein. Ich würde vermuten, dass dieser Entwickler die Prüfung des Workshops und seine zeitlichen Einschränkungen einfach nicht mag (oder beides).

Der Geschäftsanalyst fühlte sich mit unserer Szenario-Berichterstattung nicht sicher (hatte das Gefühl, dass wir andere wichtige Dinge hätten verpassen können)

Wie unterscheidet sich das von dem, wenn sie es auf ihrer Seite tut und es von einem Entwickler überprüfen lässt, abgesehen von der Tatsache, dass mehr Leute es sich angesehen haben? Ich würde vermuten, dass dies nur das Ergebnis eines vielleicht etwas chaotischen Workshops ist. Sie können sicher sein, dass Sie über genügend Tests verfügen, indem Sie diese implementieren und integrieren. Sie können nie sicher sein, dass Sie alle Fehler gefunden haben, und wenn es um die Berichterstattung geht, ist es am besten, sie in Ihren User Stories darzustellen.

Noch wichtiger war jedoch, dass dieser Workshop auch Zeitverschwendung war, da sie all diese Szenarien selbst und in kürzerer Zeit hätte herausfinden können.

Ja, und ganz allein, in ihrem ummauerten Garten und ohne Wissen zu teilen. Auf diese Weise könnten zukünftige Workshops produktiver sein, da alle Teilnehmer ein wenig Wissen darüber erworben haben, wie sie mit diesen Dingen umgehen sollen.

Vielleicht war das Treffen diesmal langsam, das heißt aber nicht, dass es immer so sein wird. Und als externes Personal hätte ich, wenn ich etwas geschult hätte, um dies richtig zu machen, mehr Vertrauen, dass die Berichterstattung in einem Workshop mit 3 Teilnehmern mit unterschiedlichen Einstellungen besser war als mit einem einzelnen Diktator.

Wenn ein Entwickler diese Szenarien bereits mit ihr besprechen musste, bin ich mir ziemlich sicher, dass das Hin und Her in der Werkstatt viel schneller und effizienter ist als die Verwendung von "Ich mache meine Sachen alleine und gebe Sachen an" Sie, Sie überprüfen es alleine und melden sich bei mir und lassen Sie uns dies erneut tun.

Vorschläge

• Seien Sie positiv und betonen Sie, dass Sie es besser machen, wenn der Prozess richtig ist.

• Versuchen Sie, den Workshop zu rationalisieren und auf Kurs zu halten.

• Geben Sie vielleicht etwas Raum für die Analyse "einsamer Wölfe", indem Sie den Workshop beginnen, indem jeder ein paar Szenarien selbst entwirft (noch besser vor dem Workshop), sie dann durchsuchen und zusammenführen.

Und wenn Sie nicht der Meinung sind, dass dieses Brainstorming erforderlich ist, ist das in Ordnung: Lassen Sie den BA alleine arbeiten, aber führen Sie die Überprüfung dann zumindest als Workshop durch. Je mehr Augäpfel , desto besser, zu zitieren Eric S. Raymond ‚s Linus‘ Gesetz :

Given enough eyeballs, all bugs are shallow.

Sie haben hier bereits einige ziemlich gute Antworten, daher werde ich mich auf einen kleinen Aspekt konzentrieren, der bisher übersehen wurde. Die Rolle jedes der drei Amigos sollte in der Lage sein, die Sitzung zu übernehmen. Sie bieten jeweils unterschiedliche Werte und verstehen unterschiedliche Einschränkungen.

Im Allgemeinen sollte der BA in der Lage sein, den Hauptglückspfad zur Sitzung zu bringen, und er sollte auch in der Lage sein, die Hauptausfallszenarien aus geschäftlicher Sicht bereitzustellen. Das Test-Know-how sollte in der Lage sein, Randfälle und zusätzliche Szenarien zu identifizieren, die erforderlich sind, um zu beweisen, dass das System unter allen Umständen funktioniert. Die Aufgabe des Entwicklers besteht nicht darin, Szenarien hinzuzufügen, obwohl dies häufig bei technischen Fehlern der Fall ist. Durch seine Aufgabe wird auch sichergestellt, dass die Anforderungen vollständig verstanden werden, sodass sie Implikationen vermitteln und die Anforderungen mit einem Minimum an zusätzlicher Kommunikation implementieren.