Zum Inhalt springen

Blogeintrag

Wie die Gurken Ihr Smart Home verbessern

Tools 

Wie die Gurken Ihr Smart Home verbessern. Gurken (Cucumber) können nicht nur Ihr Gesicht auffrischen, sondern auch Ihre Anforderungen. Wie das geht, erfahren Sie in diesem Artikel.

Sie sind hier schon richtig. In diesem Artikel geht es nicht um eine Gartengestaltung, auch nicht um die Innendekoration Ihres Esszimmers. Im folgenden Artikel möchte ich Ihnen eine (fast wahre) Geschichte erzählen. Ich möchte Ihnen zeigen, wie Cucumber (engl. Gurke) und ein damit verbundenes agiles Vorgehen Ihre Anforderungen konkretisiert und zu einem besseren Verständnis zwischen Entwicklungsteam und Anwender führt.

Cucumber ist eine Werkzeug um Kunde, Entwickler und Tester auf eine gemeinsame Sicht der Kundenprobleme und Anforderungen zu fördern. Das Werkzeug ist eine Ausprägung aus dem Bereich des Behavior-Driven Development (siehe Wikipedia).  Die Idee dahinter ist, dass Entwickler, Tester und Endanwender an einem Tisch zusammenkommen, gemeinsam die Problemstellung und die daraus abgeleitet Anforderung erörtern und das erwartete Verhalten anhand von Beispielen gemeinsam festlegen.

Ich möchte Ihnen das Vorgehen anhand eines Szenarios näher bringen: Gegeben ist eine Familie, Eltern mit ihren beiden Kindern (3 und 5 Jahre alt), die kurz davor ist, in ein Haus einzuziehen. Nach den Vorstellungen der Eltern soll das Haus "smart" sein. Um ehrlich zu sein, die Frau steht dem Vorhaben eher skeptisch gegenüber.

Lassen wir kurz die Geschichte fiktiv abzweigen: In einer "klassischen" Welt würde die Familie damit beginnen ihre Anforderungen an das Smart Home in einem Dokument zu spezifizieren und einem Unternehmen zur Umsetzung übergeben. Nach erfolgter Umsetzung hat sich aber leider in der Anwendung gezeigt, dass die ursprünglichen Annahmen sich teilweise als nicht richtig herausgestellt haben; beispielsweise schaltet sich das Licht im Bad automatisch ein, sobald eine Person den Raum betritt. Nur leider ist das Licht in der Nacht im Bad viel zu hell, sodass man als Workaround den Bewegungsmelder im Bad mittlerweile deaktiviert hat. Mittels (teuren) Change Requests lassen sich natürlich nachträglich Änderungswünsche einbringen.

In unserem Fall hat sich die Familie aber für eine agile Herangehensweise entschieden und hat die "Agile Smart Home Solutions" engagiert. Im ersten Schritt beginnt das Entwicklungsteam die Lebenssituation und deren Probleme im Wohnalltag zu erörtern. Sie beginnen erste User Stories in der Runde (die sogenannten 3 Amigos - Kunde, Entwickler und Tester) gemeinsam  zu definieren:

Als Bewohner möchte ich die Beschattung steuern, damit ich im Zimmer nicht von der Sonne geblendet werde.

 

Gemeinsam beginnen sie nun in der Runde das konkrete Verhalten mittels Cucumber (u.a. Satzschablone - Gegeben, Wenn, Dann) festzulegen:

Szenario: Raffstore schließen

Gegeben Raffstore vollständig geöffnet
Wenn der Bewohner länger als 1 Sekunde auf die Ab-Taste drückt
Dann schließt der Raffstore vollständig

Szenario: Öffnen der Blende

Gegeben Raffstore ist vollständig geschlossen
Wenn der Bewohner kürzer als 1 Sekunde auf die Hinauf-Taste drückt
Dann wird die Blende um 15 Grad geöffnet

 

Nach erfolgter Umsetzung beobachten die Eltern, wie die Kinder mit den Raffstores spielen und sie immer wieder auf und zu fahren lassen:

Als Eltern möchte ich den Raffstore bei "wilder" Betätigung sperren, sodass die Raffstore-Motoren langfristig keinen Schaden nehmen.

Szenario: Raffstore bei "wilder" Betätigung sperren

Gegeben Raffstore gestoppt
Wenn der Bewohner innerhalb 1 Sekunde mehr als 3 mal eine Bewegungsanforderung betätigt
Dann bleibt der Raffstore gestoppt.

 

Mehrere Wochen später stellt die Familie ein weiteres Optimierungspotential fest. Sie möchten die Raffstores nicht mehr manuell steuern. Außerdem wäre es wünschenswert, könnten die Raffstores automatisch bei Regen schließen. Die Firma "Agile Smart Home Solutions" beschließt für das weitere Vorgehen eine Optimierung in der Vorgehensweise, da sich in der letzten Retrospektive gezeigt hat, dass sehr viel Zeit für das Spezifizieren der Szenarien benötigt wird. Oft wären im ersten Schritt nur Stichwörter für die Szenarien ausreichend. Das detaillierte Spezifizieren der Szenarien kann später im Anschluss erfolgen. Dazu setzen sie nun Example Mapping ein, siehe Quelle.

Die Farben der Post-Its haben folgende Bedeutung:

  • Gelb: User Story (Stichwörter)
  • Blau: Regeln bzw. Akzeptanzkriterien
  • Grün: Beispiele bzw. Szenarien
  • Orange: Offene Fragen (z.B. das erwartete Verhalten ist unklar)

In der Abbildung 1 ist ein erster Zwischenstand in der Kommunikation der 3 Amigos zu sehen. Vermutlich werden noch weitere Regeln dazukommen, was ein Indiz dafür ist, dass die Story zu groß wird. Das wird insbesondere an einer hohen Anzahl an blauen Post-Its verdeutlicht. In diesem Fall würde sich eine Aufteilung der Story anbieten. Auch wird durch diese Methodik schnell sichtbar, ob die Story noch zu viele Unklarheiten beinhaltet (orange Post-Its) und hier noch weiterer Abstimmungsbedarf besteht.

 

Example Map

Abbildung 1: Example Map

Nach dieser Session sollte idealerweise nach einer halben Stunde ein gemeinsames Verständnis der Story erreicht worden sein. Das Team beginnt danach damit, die Stichwörter in Cucumber-Szenarien zu erfassen und somit die Prüfung der Szenarien auch automatisieren zu können, siehe Tutorial.

Um die Zeit zur Erfassung der Szenarien effizienter zu nutzen, entwickeln wir bei Software Quality Lab an einer stärkeren Integration von Cucumber mit gängigen Tools Polarion bzw. Jira. Ziel ist, dass Product Owner bzw. Entwicklungsteams einfach Szenarien im Tool zu einer User Story erstellen können und die Wiederverwendung von bestehenden Schritten direkt im Tool unterstützt wird. Somit behält das Team den Überblick über verfügbare und wiederverwendbare Schritte und es entsteht kein Wildwuchs an Szenarien und Schritten, der langfristig zu Wartungsproblemen führen kann.

Tool Integration

Abbildung 2: Überblick Tool-Integration Cucumber, Polarion und Jenkins

Ein weiteres Ziel ist die automatisierte Ausführung der Szenarien in den Tools wie z.B. Polarion zu starten bzw. dessen Ausführungsergebnisse zu präsentieren, wodurch der Product Owner den Erfüllungsgrad der einzelnen Szenarien auf einen Blick erfassen kann. Dadurch ist kein Wechsel in ein anderes Tool mehr erforderlich. Abbildung 2 zeigt die Verzahnung von ALM-Tools (wie z.B. Polarion) mit Cucumber, der Testausführung und schlussendlich die Ergebnisrückführung in das ALM-Tool. Somit ist an einer Stelle das Wissen über den Entwicklungsfortschritt und die Produktqualität gebündelt.

Bei Interesse an unserer Tool-Integration mit Cucumber kontaktieren Sie uns einfach. Für weitere Informationen und praxisnahe Tipps zur Methodik freuen wir uns, wenn wir Sie in einem der nächsten Trainings begrüßen dürfen.

Kontakt für Anfragen

Johannes Bergsmann

johannes.bergsmann@software-quality-lab.com

 +43 5 0657-420
 +43 676 840072 420

Fachlicher Kontakt

Hermann Lacheiner

hermann.lacheiner@software-quality-lab.com

 +43 732 890072 432
 +43 676 840072 432