Hallo Welt! Darf ich vorstellen – Gareth. Er kann unausstehlich sein. Glauben Sie mir, ich weiß, wovon ich spreche. Nichtsdestotrotz macht er sich immer unentbehrlicher (s. Video).
Wenn Ihre Ideen unsinnig sind, wird er Sie klipp und klar und völlig nüchtern darauf hinweisen. Er wird es Ihnen nicht verschweigen, sondern Klartext mit Ihnen sprechen, wenn Ihre Annahmen verfehlt sind. Er wird stets überprüfen, ob Ihre Unternehmensziele erreicht werden. Sollte das nicht der Fall sein, wird er es Ihnen mitteilen.
Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren
YouTube immer entsperren
Was genau macht Gareth?
Gareth validiert das Warum: den Grund, weshalb die jeweilige Funktionalität überhaupt erstellt wurde. Er sorgt dafür, dass die (Geschäfts-)Ziele erreicht werden und kümmert sich um die Validierung dieser Ziele. Wir alle wissen, dass die Umsetzung eines Features ein anderes beeinflussen kann. Das kann auch Auswirkungen auf den Erfolg der damit verbundenen Ziele haben.
Gareth liebt Unternehmensziele. Er will nicht über Funktionalität sprechen. Er will klare Annahmen wie: Die Leistung der Funktion x wird nach der Umsetzung dieser Veränderungen um 25 % besser; Feature y wird die Nutzung der Funktionalität z über die nächsten 3 Monate um mindestens 50 % verringern. Und so weiter.
Warum wir Gareth wirklich brauchen
Software Craftsmanship und Automatisierung werden allgemein groß geschrieben. Wir sind in der Lage, Software sehr schnell mit aktuellen Technologien zu erstellen und zu implementieren. Allerdings ist es die Post-Deployment-Phase, die uns Sorgen bereitet. Wie können wir sicher sein, dass neue Funktionalität auch tatsächlich die Auswirkungen hat, die das Unternehmen benötigt?
Wir sind der Überzeugung, dass User Stories und Backlogs zu detailliert und komplex sind, um bei der Kommunikation mit Stakeholdern hilfreich zu sein. Wir glauben, dass es sinnvoller ist, über Ziele und Annahmen zu sprechen: Welche Ziele steckt man sich und wie sollen diese überprüft werden?
Wir wissen, dass die Welt sich verändert. Auch unsere Software muss sich verändern. Noch ein Grund, weshalb wir Gareth brauchen: Man muss sich unbedingt darauf verlassen können, dass man seine Ziele auch dann erreicht, wenn man Teile der Software verändert hat. Manchmal macht ein Feature ein anderes überflüssig. Ist das der Fall, wird Gareth es Ihnen mitteilen.
Wie Gareth funktioniert
Wir führen Validierung als zusätzliche Dimension einer User Story ein. Diese nennen wir Experiment. Ein Experiment hat den folgenden Aufbau:
Experiment: Name des Experiments
Baseline: Der ursprüngliche Zustand
Annahme: Welchen Effekt soll die Software erzielen?
Zeit: Welches Zeitintervall und welchen Zeitrahmen beansprucht das Experiment?
Maßnahme: Welche Maßnahme muss Gareth ergreifen, wenn ein Experiment gelingt/misslingt?
Im Folgenden beschreiben wir ein Beispiel:
Die Story:
Als Inhaber einer Hotel-Buchungsseite möchte ich,
dass meine Nutzer an erster Stelle alle vergünstigten Zimmerangebote
angezeigt bekommen,
damit diese zuerst gebucht werden.
Das Experiment könnte nun folgendermaßen aussehen:
Experiment: Ich möchte überprüfen, ob dadurch, dass die günstigeren Zimmer zuerst angezeigt werden, insgesamt mehr Zimmer gebucht werden.
Baseline: Ermittle die aktuelle Zahl der vergünstigten Zimmer, die pro Woche gebucht werden.
Annahme: Im ersten Monat wird die Zahl der Buchungen vergünstigter Zimmer jede Woche um 25 ansteigen.
Zeit: 1 Monat
Erfolgreich: Sende eine E-Mail mit Glückwünschen an das gesamte Team
Nicht erfolgreich: Sende eine E-Mail an den Product Owner.
Baseline: Ermittle die Zahl der vergünstigten Zimmer, die in den letzten 6 Monaten gebucht wurden.
Annahme: Nach 6 Monaten haben ist die Zahl der Buchungen vergünstigter Zimmer um 80 % angestiegen.
Zeit: 6 Monate
Erfolgreich: Versende eine Nachricht, in der daran erinnert wird, Kuchen für die Entwickler zu kaufen.
Maßnahme: Erstelle eine ausführliche Analyse im Backlog.
Gareth wird diese Validierungen so oft durchführen, wie es in den Annahmen beschrieben wird, und die angemessene Maßnahme ergreifen. Für Product Owner ist das eine großartige Möglichkeit zu gewährleisten, dass die richtigen Dinge erstellt und genauso bewahrt werden. Genau das möchten wir auch unseren Stakeholdern versichern können.
Für Teams ist es ebenfalls von großem Vorteil, dass nicht nur Code, sondern auch Unternehmensziele kontinuierlich validiert werden.
Holen Sie sich Gareth zu Hilfe
Haben Sie Interesse? Sie können Gareth gern ausprobieren. Die Software ist Open Source (GNU General Public License v.2.0), damit wir alle etwas davon haben. Möchten Sie sich in irgendeiner Form daran beteiligen? Dann wenden Sie sich an uns. Wir freuen uns auf Ihre Nachrichten!
Gareth finden Sie unter: https://github.com/craftsmenlabs
War dieser Beitrag hilfreich?
Weitere Beiträge
von Niels Talens
18.9.2016 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Niels Talens
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.