Artikel

Tandem Development

Beitrag von Daniel Rosga
4. September 2014

// Agilität

In der vergangenen Woche las ich ein Interview mit Naoki Yoshida, Producer & Director des Titels Final Fantasy XIV bei Square Enix CO., Ltd. Dort stieß ich auf eine interessante Aussage im Zusammenhang mit der Entwicklung des Titels.

»The whole “running the current patch while working on the expansion” workflow and management structure definitely is based on our experience from tandem development […]«

Ich hatte zuvor noch nie von dieser Methode gehört – sie schien mir jedoch vielversprechend, da ich den Verlauf seines Projektes, aufgrund von persönlichem Interesse, aufmerksam verfolge und daher wusste, dass es eine nicht zu verachtende Herausforderung gewesen sein musste, eine Methode zu finden und zu etablieren, die ein stabiles Framework bot sowie gleichzeitig dem enormen Druck von Stakeholdern und Community standhalten konnte.

Ich setzte mich also vor den Rechner und begann mit der Recherche. Entgegen meiner Erwartungen ein schwieriges Unterfangen, da sich die Quellen stark in Grenzen hielten. Keine Wikipedia-Artikel? Kaum Fachliteratur? War ich etwa zufällig auf eine verschollene (möglicherweise einfach nur schlecht dokumentierte) und/oder antiquierte Methode gestoßen? Dies steigerte jedoch nur den Forscherdrang in mir, weshalb ich die Suche fortsetzte und letztendlich noch auf einige brauchbare sowie vertrauenswürdige Texte stieß. Das Ergebnis möchte ich an dieser Stelle gerne mit Ihnen teilen.

Zunächst sollte man erwähnen, dass die Tandem-Methode in ihren Grundsätzen auf XP basiert, sich jedoch in einigen Punkten, die sich als die Schwachpunkte von XP identifizieren lassen, unterscheidet. Extreme Programming ist als Methode dafür bekannt, dass sie stark code-lastig ist – dass die Entwicklung des Produktes höchste Priorität hat. Andere Facetten wie Dokumentation, Kommunikation und Know-how-Transfer fallen dabei unter den Tisch oder werden bestenfalls vernachlässigt. Des Weiteren ist das Risiko, dass Experten aufgrund einer durchgehend hohen Arbeitsbelastung temporär bis dauerhaft aufgrund von Krankheit etc. ausfallen, ständig präsent – was wiederum zu Flaschenhälsen in Bezug auf Ressourcen führen kann.

Wie XP ist auch Tandem iterativ – ein perfektes Ergebnis wird man daher auch hierbei, wie meist auch bei anderen iterativen Methoden, mit Ende des ersten Entiwcklungs-Zyklus kaum erzielen. Erst recht nicht, wenn das Team neu und noch nicht miteinander vertraut ist. Die Qualität des Ergebnisses steigert sich jedoch merkbar mit jedem Zyklus. Um dies sicherzustellen wird das Team zunächst in zwei Teams unterteilt. Beide sollten sich dabei sowohl in Größe als auch Skills gleichen, beide bekommen einen Teamleiter und jedes Mitglied aus dem Team A sollte einen direkten Partner, der vom Skill-Level möglichst auf gleicher Stufe steht, in Team B haben. Dies ist zwar der erste, zugleich jedoch auch der wichtigste Schritt bei der Anwendung der Tandem-Methode.

Zwei Rollen werden von beiden Teams versetzt zueinander abgedeckt. Zum einen die Rolle des Maintenance Teams (mnt) zum anderen die des Development Teams (dev). Wie der Name schon vermuten lässt, kümmert sich das Team mit der Maintenance-Rolle u.a. um die Wartung des Codes, Bereitstellung von Dokumentationen und Bugfixing, während das Team mit der Development-Rolle sich allein auf die Bereitstellung des Releases und die Einhaltung gegebener Deadlines konzentriert. Im Zuge dessen darf das Team Dev während der Entwicklungsphasen in keiner Weise und von niemandem gestört oder unterbrochen werden. Zudem hat es Zugriff auf alle benötigten Ressourcen mit höherer Priorität als alle anderen. Selbst wenn ein kritischer Bug von Team Mnt entdeckt werden sollte, der die Unterstützung einer Person aus Team Dev bedarf, so hat die Arbeit von Team Dev stets Vorrang. Nur auf diesem Weg kann für Team Dev eine Umgegbung gewährleistet werden, in der sie ungestört von äußeren Einflüssen auf ihr gesetztes Ziel hinarbeiten können.

Tandem Phasen

Um den Entwicklungs-Zyklus beider Teams greifbarer zu gestalten, möchte ich an dieser Stelle einen exemplarischen Ablauf aus Sicht von Team B anhand der obigen Grafik beschreiben. Blaue Kästchen stehen hierbei für die Maintenance-Rolle, grüne für die Development-Rolle. Diese Rollen sind, wie bereits erwähnt, nicht Team-exklusiv, sondern versetzt.

P1: Phase eins ist die Maintenance- und Planungsphase, in der das Team berät, welche Aufgaben in der folgenden Development-Phase übernommen werden sollen. Nach Ablauf des ersten Zyklus wird diese Phase ebenfalls für die Beseitigung von Problemen und Fehlern aus der vorherigen Development-Phase verwendet.
P2: Diese Phase ist die erste Development-Phase. Das Team stellt ab diesem Zeitpunkt alle Maintenance-Tätigkeiten ein. Diese Aufgaben liegen ab diesem Punkt in der Verantwortung von Team A, welche sich zu diesem Zeitpunkt parallel in ihrer Phase 5 befinden. Diese Phase wird auch Concept Phase genannt. Die Zeit sollte von Team B genutzt werden um Testcases vorzubereiten und die Planung zu finalisieren.
P3: Die zweite Development-Phase ist die Implementierungsphase, in der sämtlicher Fokus von Team B allein auf der Bereitstellung des geplanten Ergebnisses liegt. Dies hat höchste Priorität. Probleme jedweder Art werden in diesem Zeitraum vom Team an den Teamleiter weitergegeben, der wiederum an den Product Manager berichtet.
P4: Finalisierung. In dieser Phase werden keine weiteren Änderungen am Release getätigt. Der Fokus in dieser Phase liegt auf dem Testen. Mit Ende von Phase 4 müssen alle Implementierungsarbeiten abgeschlossen sein.
P5: In dieser Phase unterstützt B Team A in der Wartung des letzten Releases von A und bereitet die Dokumentationen zum eigenen Release vor.

Die Dokumentation muss immer für den Partner im anderen Team geschrieben werden. Auf diesem Weg kann gewährleistet werden, dass das Know-how zumindest auf zwei Personen verteilt ist und zudem die Dokumentation von der Qualität her höher angesiedelt ist, da es einen direkten Empfänger gibt, welcher sie verstehen muss. Es ist kein Geheimnis, dass eine Dokumentation, die man für sich selbst verfasst, in den meisten Fällen ebenso kurz wie kryptisch und für andere wenig nachvollziehbar ausfällt.

So viel als kleiner Einblick in die Tandem-Methode und die zugehörige Team-Dynamik. Ich hoffe, Sie haben durch diesen Beitrag eine Idee davon bekommen, wie diese Methode funktioniert. Persönlich finde ich die Idee einer Tag-Team-Komposition innerhalb eines Entwicklerteams sehr sympathisch, da die zuvor erwähnten Rollen regelmäßige und planbare Auszeiten für die Teams bieten, in denen sie sich auch mal mit einfacheren Aufgaben beschäftigen oder Urlaub planen können. Dadurch ist das Risiko, Mitarbeiter zu „verbrennen“ deutlich geringer als bei vergleichbaren Methoden – was heutzutage ein ernstzunehmendes Problem darstellt. Ich denke jedoch, dass die Einführung der Tandem-Methode in ein bestehendes Framework eines Unternehmens keine gering zu schätzende Herausforderung darstellt und es relativ schwierig sein dürfte, kontraproduktivem Konkurrenzverhalten unter den Teams vorbeugend entgegen zu wirken. Jedoch habe ich persönlich durch die Beschäftigung mit dieser Methode eine bessere Vorstellung davon bekommen, wie es möglich sein kann, parallel an Patch- und Produktentwicklung zu arbeiten.

| Keine Kommentare