11.06.2021 -
Story Splitting bedeutet das Splitten in „mundgerechte“ Häppchen von Projekt-Stories. Hierzu muss ein guter Mitarbeiter und Manager bei bspw. Softwareprojekten in der Lage sein – sagt John Yorke. Er veröffentlicht auf seiner Internetseite Yorkesoftware.com immer wieder Artikel zu Themen wie Führung, Story Writing und Management im Allgemeinen. Wer das vertikale sogenannte Sciling, das in-Stücke-schneiden, nicht versteht, mit dem will Yorke gar nicht erst zusammenarbeiten.
Weiterlesen »
11.06.2021 -
Story Splitting bedeutet das Splitten in „mundgerechte“ Häppchen von Projekt-Stories. Hierzu muss ein guter Mitarbeiter und Manager bei bspw. Softwareprojekten in der Lage sein – sagt John Yorke. Er veröffentlicht auf seiner Internetseite Yorkesoftware.com immer wieder Artikel zu Themen wie Führung, Story Writing und Management im Allgemeinen. Wer das vertikale sogenannte Sciling, das in-Stücke-schneiden, nicht versteht, mit dem will Yorke gar nicht erst zusammenarbeiten. Er berichtet in seinen Artikeln, dass immer wieder von ihm verlangt wird, über dieses Thema zu sprechen, sei es im Rahmen von Meetings, Coachings oder auch Veranstaltungen. Yorke gesteht, dass es ihm nicht immer ein Leichtes war, über dieses Thema zu referieren, denn er hat viele Anläufe gebraucht, um es verständlich zu erklären. Im Folgenden fassen wir seine Thesen für Sie zusammen.
Komplex und vielleicht auch kompliziert?
Story Splitting ist also ein umfangreiches und komplexes Thema. Yorke betont, dass das vertikale Splitting in seinen Augen noch wichtiger ist als das horizontale Splitting. Yorke zitiert hier Russell Ackoff, der gesagt hat, dass der Hauptgrund für Scheitern darin liegt, dass das falsche Problem gelöst wird und nicht darin, dass für das richtige Problem die falsche Lösung gefunden wird. Klingt verwirrend? Ist es auch. Was Ackoff damit betonen wollte, ist, dass es immer wichtig ist, auch ein Augenmerk auf das Problem zu haben und sich nicht nur auf die Lösung zu konzentrieren. Yorke bringt auch Ackoffs Analogie des Autos zur Sprache. Demnach benötigt man in jeden Fall einen Motor, um mit einem Auto zu seinem Ziel zu gelangen, aber mit einem Motor allein gelangt man auf keinen Fall zu seinem Ziel. Der Motor, allein betrachtet ist also nutzlos.
Beziehungen zwischen Komponenten
Analogien hin oder her – im Management von Softwareprojekten ist es von extremer Bedeutung, die Interaktion zwischen den verschiedenen Schichten oder Komponenten im Auge zu behalten, denn hierbei handelt es sich oft um den komplexesten Bereich in der Entwicklung überhaupt. Stellen Sie sich vor, sie bauen einen Motor für Ihr Auto und ein Getriebe, aber beides vollkommen unabhängig voneinander. Wie wahrscheinlich ist es, dass die beiden Komponenten nachher einwandfrei zusammenarbeiten? Richtig. Die Wahrscheinlichkeit ist nicht sehr hoch. Im Software-Design verhält es sich laut Yorke genauso mit den verschiedenen Komponenten einer Software. Und doch beobachtet Yorke, dass in der Realität viele Entwickler genauso vorgehen.
Ein System muss ein Ziel haben – denn ohne Ziel kein System
Yorke findet in vielen Teams, die heute Software entwickeln, den Ansatz, zunächst mal den Fokus auf die Datenbanken zu legen und am Ende die anderen Layer zu integrieren. Oder erst einmal ein halbes Jahr am API zu arbeiten und erst dann weiterzumachen. Kaum zu glauben, dass so viele Menschen denken, die Integration sei der einfache Teil bei der Entwicklung. Nachhaltig hält sich der Irrglaube, man könne Monate im Voraus erkennen und bestimmen, welche Bedürfnisse ein User haben wird und welche von vorneherein ausgeschlossen werden können. In seinem Berufsleben begegnet Yorke diesem Fehler kontinuierlich. Wann lernen wir endlich aus den Schmerzen, die fehlendes vertikales Sciling verursacht?
Weniger Workforce, mehr Workflow
Den Fehler, nur auf die einzelnen Komponenten zu blicken, machen viele. Dabei sollte der Fokus auf dem Zusammenspiel dieser Komponenten liegen. Sich auf die Effizienz der Teams zu konzentrieren und die Workflows übergreifend im Auge zu behalten und das Ineinandergreifen zu optimieren wäre oft besser. Es bringt am Ende nicht viel, wenn Einzelteile perfekt sind aber eben nicht optimal miteinander interagieren. Hier benutzt Yorke die Analogie, runde Elemente in eckige Löcher zu stecken.
Aber selbst wenn es nicht ganz so dramatisch ist: Auch ein kleines Problem in einem Interface kann unglückliche Kunden nach sich ziehen. Yorke betont, dass Software allein kein System darstellt, sondern ein Werkzeug ist. Software wird erst dadurch zu einem System, dass sie genutzt wird. Um zu erfahren, ob sie funktioniert und ob sie gut ist, gibt es nur einen Weg: sie muss sich am Kunden beweisen. Am Nutzer. Erst durch ihre Nutzung wird sie zu einem System, aus dem ein Feedback hervorgehen kann. Der einzige Weg, um eine Story zu splitten, ist das Erlangen eines Feedbacks von Nutzern, so dass die Entwickler das Design anpassen können.
Wenn sich aus einer Story kein Userfeedback ableiten lässt, ist die Story nutzlos. Datenbanken, die losgelöst von allem anderen erstellt werden, sind oft eine Zeitverschwendung und können enorme Probleme verursachen, wenn sie schließlich mit den anderen Komponenten des Projekts zusammengebracht werden. Was Yorke schon tausendmal gehört hat: „wir werden das später sicherlich brauchen“, bedeutet in seinen Ohren nur, dass mehr Work in Progress (WiP) kreiert wird, ohne eigentlich Mehrwert zu schaffen. Er schließt seinen Artikel mit einem schönen Zitat von W. Edwards Deming: „Learning is not compulsory… neither is survival“. Lernen ist demnach keine Pflicht. Aber Überleben auch nicht.
Nun, ganz so dramatisch ist es in der Softwareentwicklung glücklicherweise nicht. Im Regelfall überleben ein Softwareprojekt alle. Bis auf ein paar Storys vielleicht.
« Alle Beiträge