In diesem Artikel erkläre ich, was Continuous Exploration innerhalb des SAFe DevOps Health Radars ist und warum es entscheidend dafür ist, das Richtige auf die richtige Weise zu bauen. Bitte beachten Sie, dass alles hier Besprochene unter der Lizenz von Scaled Agile steht und dass das Scaled Agile Framework als Toolbox zu verstehen ist. Nehmen Sie daraus, was zu Ihren Bedürfnissen passt und Ihre Probleme löst.
Was ist Continuous Exploration?#
Continuous Exploration ist die erste Dimension in der SAFe DevOps Pipeline. Hier kommen all die guten Ideen von Kundenseite und aus dem Business herein. Wir transformieren diese Ideen in Epics mit einer klaren Hypothese, führen Markt- und Kundenforschung durch, um die echten Probleme zu verstehen, definieren eine minimale Architektur, die die Hypothese beweist, und erstellen schliesslich eine Vision, eine Roadmap und ein klares Set an Features, die die Kundenbedürfnisse adressieren.
Das Ziel ist einfach: Wir brauchen eine echte Abstimmung zwischen allen Stakeholdern darüber, welche Hypothesen validiert und was tatsächlich gebaut werden soll.
Warum Continuous Exploration wichtig ist#
Eines der grössten Probleme, mit denen Organisationen konfrontiert sind, ist der Wunsch, zu viel zu bauen. Teams identifizieren oft nicht, welche Dinge echten Wert haben und was wirklich gebaut werden sollte. Das führt dazu, dass das gesamte System mit Arbeit überladen wird, die keinen signifikanten Wert liefert.
Continuous Exploration löst dieses Problem, indem ein klarer Prozess definiert wird: wie Ideen in Epics transformiert werden, wie Kundenbedürfnisse identifiziert werden, wie eine minimale Architektur definiert wird und wie diese Ideen in Features aufgeteilt werden, die bereit für die Entwicklung sind. Das Ergebnis ist, dass wir in der Lage sind, das Richtige richtig zu bauen.
Die vier Aktivitäten von Continuous Exploration#
Continuous Exploration besteht aus vier Aktivitäten: Hypothesize, Collaborate and Research, Architect und Synthesize.
Hypothesize#
Alles beginnt mit Ideen von Kunden und dem Business. In der Hypothesize-Aktivität nehmen wir diese Ideen und erstellen Epics mit einer klaren Hypothese dahinter. Diese Hypothese definiert, was wir glauben, dass Wert liefern wird, und was wir beweisen wollen.
Collaborate and Research#
Mit unseren definierten Epics und deren Hypothesen gehen wir in die Marktforschung und Kundenforschung über. Wir interviewen Kunden, identifizieren ihre echten Bedürfnisse und versuchen, das tatsächliche Problem zu verstehen, das gelöst werden soll. Dieser Schritt stellt sicher, dass wir nicht einfach das bauen, was jemand angefragt hat, sondern das echte zugrundeliegende Problem lösen.
Architect#
Sobald wir die echten Kundenbedürfnisse verstehen, definieren wir die minimale Architektur, die benötigt wird, um die Hypothese zu beweisen. Es geht hier nicht darum, die vollständige finale Architektur zu bauen. Es geht darum, den einfachsten architekturellen Ansatz zu identifizieren, der es uns ermöglicht, unsere Hypothese zu validieren.
Synthesize#
An diesem Punkt haben wir die echten Kundenbedürfnisse identifiziert, haben eine klare Hypothese und haben eine minimale Architektur definiert, um sie zu beweisen. In der Synthesize-Aktivität erstellen wir eine Vision, eine Roadmap und ein klares Set an Features, die in unser priorisiertes Program Backlog kommen. Dies ist der Output von Continuous Exploration und der Input für Continuous Integration.
Wie schnell ist dieser Prozess?#
Eine der Fragen, die mir am häufigsten gestellt wird, ist: Wie lange dauert Continuous Exploration? Die Antwort ist einfach: Es kommt darauf an.
Manche Items können Continuous Exploration innerhalb von Stunden durchlaufen. Andere brauchen Tage, und einige werden Wochen dauern. Was falsch wäre: wenn Continuous Exploration Monate oder sogar Jahre dauert. Das wäre ein Problem.
Es ist auch wichtig zu verstehen, dass Continuous Exploration kein Drei-Monats-Zyklus ist, nur weil es PI Planning gibt. Wir machen nicht drei Monate Continuous Exploration, haben dann alles im PI Planning und starten dann einen weiteren Drei-Monats-Zyklus. Es ist ein kontinuierlicher Prozess.
Konkrete Beispiele#
Eine einfache Kundenanfrage#
Ein Kunde gibt Feedback, dass das Ändern eines kleinen Filters in der Anwendung, um die Reihenfolge umzukehren, massiven Wert für ihn hätte. Diese Anfrage geht sehr schnell durch Hypothesize (die Hypothese ist einfach), durch Collaborate and Research (wir überprüfen schnell das Kundenbedürfnis), durch Architect (die minimale Architektur ist simpel) und in Synthesize, wo sie auf dem Backlog landet. Dieser gesamte Prozess dauert vielleicht nur Stunden.
Ein Bug#
Ein Bug kommt herein und wir gehen in Hypothesize. Hier ist es sehr wichtig, den Bug zu analysieren. Ein kleiner Bug wird sich schnell bewegen, aber ein grosser Bug, der die komplette Geschäftslogik verändert, erfordert eine sorgfältige Analyse. In Collaborate and Research müssen wir feststellen, ob dieser Bug mit einem fehlenden Kundenbedürfnis oder einem nicht adressierten Problem zusammenhängt. Wir könnten entdecken, dass es sich nicht wirklich um einen Bug handelt, sondern ein neues Feature erforderlich ist. In Architect analysieren wir die Auswirkungen der Bugbehebung und ob wir die Architektur ändern müssen. In Synthesize erstellen wir schliesslich entweder einen Bugfix oder ein neues Feature für das Backlog.
Ein grosses Epic#
Stellen wir uns vor, wir stellen die Hypothese auf, dass ein neues Produkt auf unserer Website die Anzahl der Käufer um 10% steigern würde. Das ist ein grosses Epic mit einer bedeutenden Hypothese, und wir müssen das Minimum Viable Product definieren, um sie zu beweisen. In Collaborate and Research untersuchen wir Marktbedürfnisse, befragen Kunden und erstellen vielleicht Papierprototypen, um die Hypothese zu validieren. Wir analysieren den einfachsten Weg, sie zu beweisen. In Architect bestimmen wir die minimale Architektur, die benötigt wird. In Synthesize müssen wir möglicherweise die Vision und die Roadmap anpassen und erstellen neue Features für das Backlog. Dieser Prozess könnte Wochen dauern.
Der Output von Continuous Exploration#
Nach Continuous Exploration haben wir:
- Eine klare Vision, oder eine angepasste bzw. unveränderte Vision
- Ein klares Set an Features in unserem priorisierten Program Backlog
- Enabler Features für die architekturelle Runway, die es uns ermöglichen, mehr Geschäftswert zu liefern
- Eine angepasste oder neue Roadmap
Es ist auch erwähnenswert, dass Informationen, die während Continuous Integration, Continuous Deployment oder Release on Demand gesammelt werden, zurück in Continuous Exploration fliessen können. Neue Ideen, Bugs oder Erkenntnisse aus der Produktion speisen den Kreislauf erneut. Das ist die inkrementelle, kontinuierliche Natur der gesamten DevOps Pipeline.
Continuous Exploration dreht sich darum, Alignment zwischen den Stakeholdern zu erreichen, damit wir identifizieren, welche Hypothese uns den grössten Wert bringt. So können wir bestimmen, was wir bauen müssen, und sicherstellen, dass wir das Richtige richtig bauen.