Als experimentierfreudiger Entwickler finde ich den Gedanken der hinter Hypothesis-Driven Development steckt sehr interessant. Mit dieser Methode versucht man Probleme experimentell und iterativ zu Lösen oder auch dadurch neue Lösungen zu schaffen. Die Akzeptanz steigert sich im Laufe des Entstehungsprozesses. Das spiegelt auch die Realität wieder, da man Nutzerverhalten nie wirklich voraussagen kann. Es ist einfach viel zu komplex und dynamisch.
Dadurch wird klar, dass Feedback ein wichtiger Teil dieser Methode ist.
Die Bezeichnung Hypothesis-Driven Development beschreibt dabei auch gut die Herangehensweise. Ideen werden zusammengeführt und dazu Hypothesen aufgestellt. Dadurch werden auch Priorisierung oder Testbarkeit der Features vereinfacht. Da am Anfang die Hypothese festgelegt wird kann das erwartete Ergebnis einfach gegengeprüft werden.
Jedes Experiment, dass angegangen wird sollte auf so einer Hypothese aufsetzten. Dabei kann man ein einfaches Muster anwenden. Ich/wir glaube(n), dass Kunde/Benutzer/Firma,… möchte, dass Service, Produkt, Lösung, Feauture … weil ….
Wichtig ist dabei auch einen erwarteten Mehrwert festzulegen, z.B. ein Rückgang falscher Buchungen um 10% im System. Anhand dessen kann man im Nachgang den Erfolg validieren. Das ist wichtig um sicherzugehen keine unnötigen Funktionalitäten bereitzustellen, sondern wirklich die Anforderungen/Wünsche des Anwenders zu erfüllen.
Diese Methode arbeitet bietet auch Mehrwert für Ansätze wie Test Driven Development, da die Hypothese gut in einen Test umgeschrieben werden kann wogegen der Code geprüft werden kann. Der Gedanke des Kontinuität und iterativen schnellen Deploymentzyklen ist einer der Gedanken der DevOps-Philoisophie.
Sei der Erste der einen Kommentar abgibt