Kolumne

DevOps Stories: Viele kleine Schritte – Warum kleine Experimente so wichtig sind

Konstantin Diener

© Software & Support Media GmbH

Die Mitglieder des MusicStore-Teams haben sich zu einem Backlog-Grooming-Termin zusammengefunden. Erik, der Product Owner, hat einen Entwurf für ein neues Feature mitgebracht und stellt es den Kollegen vor.
 
 

Erik: „Schaut mal, so habe ich mir Folgendes für den Bereich ‚Was deine Freunde hören‘ gedacht.“

Christian: „Okay, das ist ein ganz schön dickes Brett!“

Lukas: „Dafür müssen wir eine völlig neue Aggregation bauen, die Timeline erweitern und die Services anpassen, in denen heute die Playlists erzeugt werden – wenn die Benutzer Playlists mit den Hits ihrer Freunde bekommen sollen.“

Julia, Christian und Lukas beginnen direkt eine Diskussion am Whiteboard.

Erik: „Bekommen wir das in einem Sprint hin?“

Christian: „Niemals! Was meint ihr? Ich denke das wird mindestens vier Sprints, eher fünf dauern …“

Lukas: „Ja, ich stimme dir zu. Neben diesem Thema haben wir auch noch ein paar Reste aus den letzten Sprints.“

Ruben (Scrum Master): „Also ich höre mindestens zwei Stories heraus: eine für die neue Timeline und eine für die neuen Playlists. Ist eine davon in einem Sprint machbar?“

Christian: „Nein!“

Ruben: „Bekommen wir die Stories irgendwie so zerlegt, dass dabei etwas herauskommt, was in diesem Sprint machbar ist? Können wir irgendeinen ganz schlanken Aspekt des Gesamtthemas umsetzen?“

Julia: „Wenn ich es richtig verstehe, muss die neue Aggregation gebaut werden, damit die Timeline schnell aufgebaut werden kann. Außerdem werden die Animationen in der Timeline einiges an Zeit kosten. Vielleicht könnte man die Timeline einfach live berechnen und die Animationen weglassen. Der Benutzer sieht Änderungen dann nur, wenn er auf Reload drückt.“

Christian: „Julia, das ist doch Murks. So müssen wir die ganze Logik für die Timeline zweimal implementieren. Und Reload drücken finde ich voll 90er!“

Ruben: „Ich finde Julias Vorschlag gar nicht schlecht. So könnten wir in einem Sprint ein erstes Inkrement liefern!“

Christian: „Sorry Ruben, aber daran merkt man, dass du keine Software entwickelst. Ich finde dieses sklavische ‚In einem Sprint liefern’ ziemlich unsinnig. Du nennst so was Cargo Cult. Wir hätten einen Haufen Mehrarbeit. Das, was dabei rauskommt, kann man keinem Kunden zumuten! Nachher nimmt Erik das noch so live. Dafür würde ich mich schämen! Wir wissen doch, was zu tun ist!“

Teams tun sich immer wieder schwer damit, in kleinen Intervallen zu liefern …

Das Gespräch zwischen den Mitgliedern des MusicStore-Teams ist durch einen Blogpost inspiriert. Dieser Blogpost beschreibt eine ähnliche Situation und ein ähnliches Gespräch: Ein neues Feature steht zur Entwicklung an, das nicht komplett in einen Sprint passt. Auch dieses fiktive Team tut sich unglaublich schwer damit, etwas zu definieren, was klein genug für einen Sprint ist.

Warum tun sich Teams mit dieser Aufgabe so schwer und sehen sogar – wie Christian – keinen Sinn darin? Zunächst einmal, vermutet der Autor, liegt es daran, dass wir Menschen ungeduldige Kreaturen sind. Wir mögen kleine Schritte allenfalls, wenn wir das große Ganze (noch) nicht kennen. Ist uns das Zielbild bekannt, wollen wir alle Kräfte darauf fokussieren, genau das umzusetzen. Das Team ist von Eriks Idee angetan und macht sich sofort an die Konzeption der Architektur. Für sie macht das Feature als Ganzes einen runden Eindruck. Warum sollte man es also zerlegen?

Dieser Eindruck verstärkt sich, wenn die Teillösungen als etwas Minderwertiges wahrgenommen werden. Christian ist von Julias Vorschlag, der Einfachheit halber zunächst die Aktualisierung über den Reload Button des Browsers zu implementieren, überhaupt nicht begeistert. Aus einem coolen Feature wird für ihn dadurch etwas Schlechtes. Er will auch verhindern, dass die Kunden eine solche Lösung zu Gesicht bekommen. Offensichtlich hat Erik, der Product Owner, schon das ein oder andere Mal Zwischenlösungen live genommen, auf die das Team nicht stolz war. Christian geht sogar so weit, dass er sich für die von Julia vorgeschlagene Lösung schämen würde.

Lesen Sie auch: DevOps Stories: Cloud bedeutet nicht NoOps

Die Entwickler des Teams fühlen sich vermutlich nicht richtig ernst genommen. Sie haben das Gefühl, dass ihnen Ruben, ihr Scrum Master, nicht zutraut, ein umfangreiches Feature wie dieses „auf einen Streich“ zu implementieren.

Dazu kommt noch die Mehrarbeit, die mit diesem vermeintlich fehlenden Vertrauen verbunden ist. Sie müssen die Abfragen für die Timeline zweimal entwickeln: einmal auf den bestehenden Datenquellen und später dann auf einer Datenquelle, die für diesen Zweck optimiert ist. Setzten sie das Thema in Form von einer oder maximal zwei großen User Stories um, wäre klar, dass die Stories nicht in einem Sprint abgearbeitet werden können. Im Sprint Review würden sie zu dieser Work in Progress auch nichts sagen. Wenn, stünde alles was sie zeigen unter dem Vorbehalt, dass es ja sowieso noch nicht fertig ist. Das Team könnte mehrere Sprints ohne vermeintlich nervige zeitraubende Diskussionen mit dem Product Owner, Kunden oder anderen Stakeholdern in Ruhe vor sich hin entwickeln.

… dabei sind regelmäßige kleine Experimente ein wichtiger Teil der DevOps-Philosophie

Genau in diesem Verhalten liegt die Gefahr. Der Product Owner des Teams hat vermutlich eine Hypothese über das Nutzerverhalten aufgestellt beziehungsweise darüber, wie er es beeinflussen will [1]. Um seine Hypothese zu überprüfen, möchte er mit dem Team das beschriebene Feature umsetzen. Je länger das Team und er brauchen, um Feedback vom Markt zu seiner Hypothese zu bekommen, desto teurer wird es.

Das Buch „The Phoenix Project“ [2] ist eines der Standardwerke zum Thema DevOps. Die Arbeitsweise wird dabei in den „Drei Wegen“ beschrieben. Der dritte Weg beschäftigt sich mit dem Experimentieren als einem wichtigen Aspekt einer DevOps-Kultur:

„Der Dritte Weg dreht sich um das Aufbauen einer Kultur, die zwei Dinge fördert: andauerndes Experimentieren, bei dem man Risiken eingehen und aus Erfolgen und Fehlschlägen lernen muss, und ein Verständnis dafür, dass Wiederholung und Übung die Grundlage des Könnens sind.“

Es ist beabsichtigt, dass der Product Owner und das Entwicklungsteam kontinuierlich Risiken eingehen – dass ihre Hypothese über die Kunden oder den Markt nicht zutrifft. Damit dieses Verfahren funktioniert, versuchen sie aber, jedes einzelne Risiko möglichst klein zu halten und zu überprüfen. Die beste Möglichkeit dafür ist schnelles und direktes Feedback. Aus diesem Grund gibt es in Scrum Sprints fester Dauer, an deren Ende dem Kunden ein Produktinkrement zur Verfügung gestellt werden soll. Das Team müsste sich also fragen, was das kleinstmögliche Häppchen Software ist, mit dem sie sinnvolles Feedback zu Eriks Hypothese einsammeln können. Julias Vorschlag ist in diesem Sinne entstanden. In der digitalen Produktentwicklung gibt es sogar die Faustformel, dass Softwareentwicklung immer die teuerste Methode ist, eine Hypothese zu überprüfen. Das Buch „Lean Experimentation in Action“ [3] gibt eine Fülle von Anregungen für Alternativen.

DevOpsCon Whitepaper 2018

Free: 40+ pages of DevOps expert knowledge

Learn about Containers,Continuous Delivery, DevOps Culture, Cloud Platforms & Security with articles by experts like Kai Tödter (Siemens), Nicki Watt (OpenCredo), Tobias Gesellchen (Europace AG) and many more.

Selbst wenn Eriks Hypothese schon durch solche Instrumente ausreichend validiert ist, lohnt es sich, weiterhin kleine User Stories zu schneiden, die innerhalb eines Sprints umsetzbar sind. Das Team hat zwar sofort eine konkrete Vorstellung, wie es die neuen Aggregationen umsetzen möchte, auf der anderen Seite bietet Softwareentwicklung immer Überraschungen. Ist die Anzeige vielleicht trotzdem zu langsam? Gibt es Synchronisationsprobleme zwischen den verschiedenen Datenquellen? Sind die Operationen sehr speicherintensiv? Müssen die Privatsphäreeinstellungen der Benutzer erweitert werden, damit sich niemand belästigt fühlt? Auch diese Fragen lassen sich nicht vorab beantworten. Deswegen ist es sinnvoll, in möglichst realistischen vertikalen Schnitten (Endbenutzer-Frontend bis Persistenz) zu lernen und Erfahrungen zu sammeln. Im Buch „Fifty Quick Ideas to Improve Your User Stories“ [4] schlagen die Autoren vor, dass sich das Team bei jeder Story entscheidet, ob sie Business Value liefern oder etwas lernen wollen („Learn or Earn“).

Ruben hält das Team an, in kleinen Schritten zu denken – und User Stories, die in einen Sprint passen. Er tut das nicht nur, weil er dieses Mantra in einem Training mal gelernt hat und es jetzt blind anwendet; Christian nennt es Cargo Cult. Er weiß, wie wichtig regelmäßiges Feedback dafür ist, dass die Risiken, die das Team kontinuierlich eingeht oder eingehen soll, im überschaubaren Rahmen bleiben. Dabei handelt es sich sowohl um technische Risiken als auch um Risiken hinsichtlich des Geschäftsmodells von MusicStore.

Lesen Sie auch: DevOps Stories: ChatOps als Konzept der Zusammenarbeit

Dieses Feedback wird vor allem von Christian als Kontrolle wahrgenommen („Ich habe verstanden, was wir bauen sollen. Ich muss es nicht ständig zwischendrin dem Product Owner zeigen und kontrollieren lassen, ob ich es richtig mache.“). Ruben hat aus diesem Grund dem Team noch einmal detailliert die Hintergründe zu den kurzen Zyklen erläutert und sie haben sich auf einen Fahrplan für entsprechende Zwischenlösungen (kleine User Stories) geeinigt. Bei der Zerlegung hat ihnen [5] geholfen, in dem es eine eigene Sektion zu „Splitting Stories“ gibt.

Geschrieben von
Konstantin Diener
Konstantin Diener
Konstantin Diener ist CTO bei cosee. Sein aktueller Interessenschwerpunkt liegt auf selbstorganisierten Teams, agiler Unternehmensführung, Management 3.0 und agiler Produktentwicklung. Daneben entwickelt er noch leidenschaftlich gerne selbst Software. Twitter: @onkelkodi
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: