Menu

Mitarbeiter im Interview: Wie arbeitet die Entwicklung bei Plunet?

Liebe Leser,

Heute folgt der zweite Teil unserer Interview-Serie „Plunet stellt sich vor“. Im Rahmen dieser Reihe stellen wir Ihnen einige unserer Kolleginnen und Kollegen vor und geben Ihnen einen Einblick in deren Aufgaben und Tätigkeiten bei Plunet. Heute begrüßen wir Andreas, einen unserer Softwareentwickler aus unserem Würzburger Büro. Andreas wird uns in die agile Entwicklungsmethode Scrum einführen, erläutern was es mit Grooming auf sich hat und uns exklusive Einblicke in die Entwicklungsarbeit von Plunet BusinessManager geben.

Viel Spaß beim Lesen und „Hallo Andreas!“

Plunet Translation Management systems_andi

Stell Dich doch einfach mal vor. Wer bist Du?

Ich bin Andreas und arbeite seit 2009 bei Plunet als Softwareentwickler in unserem Würzburger Büro. Darüber hinaus bin ich der Administrator für JIRA und der Scrum-Master bei uns. Hierfür koordiniere und moderiere ich die unterschiedlichen Scrum-Meetings, wie beispielsweise die Daily Scrums oder das Poker Planning. Hinzu kommen noch weitere kleinere Aufgaben.

Was ist Scrum genau? Kannst du es kurz erklären?

Scrum ist eine agile Entwicklungsmethode. Das heißt, es gibt kurze Release-Zyklen, sogenannte Sprints, die einen definierten Zeitraum dauern und in denen eine bestimmte Anzahl an Vorgängen umgesetzt wird. Bei uns sind es aktuell zwei Wochen. Danach folgt die Rekapitulation. In dieser stellt man die Vorgänge vor. Darauf folgt die Planung des nächsten Zyklus gemeinsam mit dem sogenannten Product Owner. Im Rahmen dessen gibt es eine Reihe unterschiedlicher Meetings, die Scrum maßgeblich ausmachen. Die wichtigsten sind unter anderem das Grooming vor jedem Sprint, das Poker Planning und die Daily Scrums.

Wie laufen diese Meeting ab?

Beim Grooming werden die Vorschläge vom Product Owner vorgetragen, welche Features beziehungsweise Vorgänge er gerne im nächsten Sprint hätte. Der Product Owner vertritt in der Regel den Kunden. Anschließend werden die Vorschläge bewertet, ob sie hinreichend beschrieben sind. Wenn alle Informationen vorliegen, wird das entsprechende Feature zum Poker Planning aufgenommen.

Im Poker Planning wird die Komplexität jedes Vorgangs von jedem Teilnehmer geschätzt. Die Schätzung erfolgt mittels Spielkarten auf denen Zahlenwerte der sogenannten Fibonacci-Reihe abgedruckt sind. Jeder Teilnehmer hält nun für jeden Vorgang eine Karte hoch. Je höher der hochgehaltene Zahlenwert, desto komplexer wird der jeweilige Vorgang eingeschätzt. Sobald im Team Einigkeit über die Komplexität jedes Vorgangs herrscht, ist das Meeting beendet. Auf dieser Grundlage werden dann die zeitlichen Aufwände der Vorgänge und der nächste Sprint geplant.

Und dann gibt es noch die Daily Scrums…

Genau. Die Daily Scrums sind nichts anderes als tägliche Stand-up Meetings. Sie dauern in der Regel nicht länger als 15 Minuten und dienen dazu, sich abzustimmen und sich gegenseitig über den Entwicklungsfortschritt zu informieren. Zudem folgen sie einem bestimmten Ablauf: Die Meetings finden im Stehen statt und ein Ball wird gegen den Uhrzeigersinn herumgereicht. Sprechen darf nur derjenige, der den Ball in der Hand hat.

Das klingt ein bisschen nach Waldorfschule.

Das kann schon sein. Jedoch hat diese Meeting-Art entscheidende Vorteile: Zum einen hat das Entwicklerteam die Möglichkeit, seinen bisherigen Fortschritt regelmäßig zu reflektieren. Zum anderen können bei Blockaden direkt Synergien mit Kollegen für Lösungsansätze geschaffen werden. Darüber hinaus sollen laut Scrum-Lehre durch den ungewohnten Ablauf sowie den Ort- und Positionswechsel andere Gehirnströme angeregt werden, was dazu führen soll, dass man anschließend frischer und konzentrierter weiterarbeiten kann.

Gibt es noch weitere Vorteile?

Durch Scrum hat man sehr kurze und überschaubare Releases, wodurch das Bug-Monitoring sehr gut funktioniert. Das heißt, es werden keine Prototypen vorgestellt und zum Abgleich gegeben, sondern fertige Teil-Features, die in einer kurzen Entwicklungszeit entstandenen sind. Diese können zwar auch noch Fehler beinhalten, aber es ist kein komplexes Modul, an dem ein halbes Jahr gearbeitet wurde und die Fehlerbehebung in die Unsummen gehen würden.

Warum hat Plunet Scrum eingeführt?

Es war der Wunsch der Entwicklung. Denn wir waren unzufrieden mit unserer damaligen Methodik. Früher hat jeder Entwickler einen Vorgang genommen und bearbeitet. Dank Scrum und dem sogenannten Product Backlog gibt es nun eine globale Abstimmung mit einer klar strukturierte Priorisierung aller aktuellen und künftigen Features. Das bedeutet, dass das Entwicklerteam zu jedem Zeitpunkt genau weiß, was parallel bearbeitet wird und was kommen soll. Also der Wissenstransfer ist mittlerweile ein anderer.

Was ist das Product Backlog genau?

Das Product Backlog ist die gesamte Liste, aller Produktanforderungen, die dynamisch weiterentwickelt wird. Hier werden die Anforderungen von “sehr wichtig“ bis “sehr unwichtig“ priorisiert. Der obere Teil von dieser Liste kommt in die Sprints. Und nach jedem Sprint wird das Product Backlog wieder neu sortiert. Das heißt abhängig von der Komplexität, werden die nächsten zehn bis 20 Vorgänge der Liste in den nächsten Sprint aufgenommen. Bei uns sind es sogar 30 bis 60 Vorgänge pro Zyklus, da wir in der Regel drei parallele Sprints umsetzen.

Wie wird festgelegt, welche Vorgänge Priorität haben?

Wir haben dafür ein Punktesystem mit folgenden Kriterien: Ist das Feature wichtig für unsere interne Roadmap? Wie zeitkritisch ist die Anpassung für einen spezifischen Kunden? Wie viele Kunden wollen das Feature? Wenn viele Kunden ein Feature angefragt haben, dann steigt natürlich die Wichtigkeit. Brauchen wir das Feature dringend für unsere Datenintegrität? Also die Priorisierung wird durch externe und interne Faktoren bestimmt.

Schafft Ihr es immer, jeden Kunden im Sprint zu berücksichtigen?

Durch die Einführung von Scrum ist insgesamt die Liefertreue gestiegen. Wir können nun pünktlich und verlässlicher an unsere Kunden liefern. Jedoch ist es nicht immer ganz leicht, die Wünsche aller Kunden sofort zu berücksichtigen. Zum Beispiel, wenn Neukunden zwingend verschiedene Features benötigen, um live gehen zu können, hat das beispielsweise Priorität. Dadurch ist es manchmal schwierig, die Vorgänge zeitnah für jeden Kunden umzusetzen. Dennoch versuchen wir es natürlich.

Gibt es eine feste Anzahl an Vorgängen die pro Sprint umgesetzt werden?

Nein, eine feste Anzahl an Vorgängen gibt es nicht. Vielmehr bestimmt die Komplexität der unterschiedlichen Vorgänge deren Anzahl pro Sprint.

Wie stellt ihr die optimale Anzahl an Vorgängen pro Sprint sicher?

Wir bauen auf Erfahrungswerte. Hierfür haben wir ein eigenes System entwickelt, wodurch wir die optimale Anzahl ziemlich exakt bestimmen können. Es ist im Grunde das Delta aus der geschätzten Anzahl an Entwicklungsstunden und der Ressourcen-Verfügbarkeit in Stunden. Wenn diese Werte übereinstimmen, ist der Sprint voll.

Wie lange dauert ein Sprint in der Regel?

Das ist unterschiedlich. Wir haben am Anfang Vier-Wochen-Sprints gehabt. Das war ziemlich hoch. Mittlerweile machen wir zweiwöchige Sprints, wodurch sich der Aufwand halbiert hat.

Warum wurde der Zyklus von vier auf zwei Wochen verkürzt?

Das hatte mehrere Gründe. Zum einen waren die Meetings sehr umfangreich und deshalb langwierig. Ein Poker-Planning für vier Wochen kann schon mal zäh sein, wenn man drei Stunden im Meeting sitzt und diverse Vorgänge schätzen muss. Irgendwann leidet die Konzentration und man hebt nur noch dieselbe Karte. Deshalb haben wir die Poker-Plannings verkleinert und die Sprints verkürzt. Zum anderen ist man bei kürzeren Sprints wesentlich flexibler in der Planung und kann auf veränderte Anforderungen besser reagieren.

Ich danke Dir für das Gespräch.

Teilen

 

Ihre Kontaktdaten

!
!
!
!
!
!
!
!