Wieder so‘n Buzzword? Naja, „Geschichtenverantwortlicher“ klingt noch dümmer, oder? Es geht hier um innere Verantwortlichkeiten in einem agilen Softwareentwicklungs-Team zur besseren Qualitäts- und Zielerreichung.
Nun, während der AppSec 2013 sprache ich mit Chris Eng kurz über diese Methode nach seinem Vortrag „Real World Agile SDLC“, hatte ich diese Methode doch in einem der Projekte in denen ich derzeit tätig bin, vorgeschlagen und wir hatten mit einem Piloten ganz nette Erfahrungen gemacht.
Worum geht es bei „storybased Ownership“?
Wenn es in einer Firma Abteilungs- und Projektleiter gibt, gibt es auch immer die Frage nach Verantwortlichkeiten. In der reinen agilen Lehre (bspw. SCRUM) gibt es diese Rollen nicht mehr, aber IRL gibt es sie eben doch. Um diesen Wunsch nach Information und Verantwortlichkeit gerecht zu werden, bestimmt das agile Entwicklungsteam bei der Sprintplanung eben einen, der „den Hut für eine [größere] Story auf hat“, d.h. es ist jemand da, den man fragen kann, wenn man zu genau diesem Thema (der Story) was wissen muss. Aufgaben- oder Defekte im Fehlerreportingsystem haben ja auch immer einen Verantwortlichen. Bei sog. „Stories“, die mehrere Unteraufgaben haben oder auch „Epics“, die über mehrere Iterationen gehen, ggf. mit unterschiedlichen Entwicklern an den jeweiligen Teilaufgaben machen die Übersicht für Außenstehende nicht einfacher. Natürlich kann man alles an den SCRUM-Master übertragen, aber das agile Manifesto stellt die Interaktion der handelnden Personen an die erste Stelle, also die direkte Kommunikation ist m.E. besser als die durch Rollen und Prozesse festgelegte.
Sorgt der SCRUM-Master für die Einhaltung der agilen Vorgehensweise, so unterstützt „storybased Ownership“, da der Verantwortliche selbst ein Interesse hat die „Definition of Done“ (und damit die Abnahmekriterien) zu erfüllen, den Build nicht durch die Tests aus dieser Story rot werden zu lassen, etc.
Der „Storyowner“ ist also der Verantwortliche, der für die Erfüllung der „Definition of Done“ sorgt und somit dazu beiträgt das sein Teilergebnis nicht im „toll ein anderer macht‘s“-Wirrwarr von agilen Teams untergeht. Gleichzeitig wird der SCRUM-Master entlastet.
So macht man nicht nur Projekt-, Bereichs-, Produkt- und andere Leiter oder -Manager glücklich, sondern auch das Team hat etwas davon, da man als „springender Tester“ oder bei großen Epics über mehrere Iterationen und gerade aus dem Urlaub kommend bspw. auch immer weiß wen man bei Unklarheiten fragen kann ohne die anderen zu stören.
Der Storyowner ist nicht allwissend, aber er weiß am Ende wie das Ganze von wem zusammengesetzt worden ist.
