Scrum bei T-Online International (TOI)

Seit Frühjahr 2006 wird im Bereich „Versandserver“ (VSS, zentrale Logistikapplikation von T-Online International) ein modifizierter Scrum-Prozess für die Weiterentwicklung genutzt.

Scrum "klassisch":

scrumflow.jpg

Dieses Vorgehen konsequent durchhalten zu wollen, setzt allerdings eine weitgehende Kontrolle über den Build- und Deployment-Prozess voraus; insonderheit geht man davon aus, dass es keine engeren Interdependenzen zu anderen, parallelen Projekten (welche vielleicht auch noch anderen, „schwergewichtigeren“ Prozessen folgen) gibt.

Dies ist bei T-Online definitiv nicht gegeben, da der VSS letztlich die letzte Instanz einer Kette von Systemen (und Geschäftsprozessen) ist, in denen eine Vielzahl von Versandvorgängen - Briefe, Emails, Faxe, SMS, Hardware-Pakete… - angestoßen werden (typischerweise ca. 20 Millionen Vorgänge/Jahr!) Hieraus ergeben sich zwangsläufig eine Reihe von Abhängigkeiten zu anderen Systemen, da sich auch bei TOI die Geschäftsprozesse parallel zu den Produkten beständig weiterentwickeln; dies bedeutet, dass die vernetzten Systeme, die diese Prozesse abbilden, sich weitgehend synchronisiert weiterentwickeln müssen.

scrum@TOI

Im Rahmen des VSS hat es daher eine Reihe von Anpassungen gegenüber dem klassischen Scrum-Prozess gegeben:

  • Der 30-Tage-Zyklus für den einzelnen Sprint lässt sich nicht durchhalten!
    Die Länge des Sprint orientiert sich tatsächlich an den synchronisierten Deployment-Zyklen - derzeit (Oktober 2006) ist monatlich ein „Major Deployment“ vorgesehen!
  • Ob tatsächlich zum Ende des Sprint ausgeliefert wird, hängt stets davon ab, ob tatsächlich alle Systeme, die zu dem jeweils geänderten Geschäftsprozess beitragen, auch liefern können :-/
  • Größere Änderungen an elementaren Geschäftsprozessen werden typischerweise einem Verbundtest aller Systeme unterzogen - was allerdings eine mehrwöchige Verzögerung der Auslieferung bedeutet :-/
    (Dies hat vor allem Auswirkungen auf das Konfigurationsmanagement, da infolgedessen oftmals verschiedene Code-Branches parallel entwickelt und später wieder zusammengemergt werden müssen…)
  • Die Organisation schreibt einen recht schwergewichtigen Prozess für das Anforderungsmanagement vor, der neue Features erst einmal in formale „System Modification Requests“ (SMR)bzw. „Change Requests“ (CR) münden lässt; da diese recht feingranular sein können, überdies die Begehrlichkeiten der div. Fachbereiche vielfältig sind, ist eine konsequente Priorisierung des gesamten Backlogs kaum realisierbar!
    Größere Projekte werden zwar mittlerweile in einem „Prio-Board“ durch die Fachbereiche priorisiert, aber oftmals erfolgt die Priorisierung „im kleinen“ doch durch die Projektleitung…
  • Da im Rahmen der Systementwicklung sowohl Weiterentwicklung, als auch Wartung erfolgt, ist die vollständige Isolierung des Entwickler-Teams während des Sprints, wie auch die Unveränderbarkeit des Sprint Backlog nicht durchzuhalten!
    Aktuell auftretende Produktionsprobleme müssen stets - oftmals unter Hintanstellen der Aufgaben in der Weiterentwicklung - vorrangig & zeitnah (via sog. „Hotfixes“) erledigt werden.
    In der Praxis ist dies allerdings kein großes Problem, da das typische „Moving Target“ Syndrom eigentlich durch den recht formalen Prozess des Anforderungsmanagements kontrolliert wird…

Nichtsdestotrotz bleibt ein leichtgewichtiger Prozess übrig, der sich aus Sicht eines beteiligten Team-Mitglieds auch durchaus „agil“ anfühlt. Ein recht überraschender Seiteneffekt war die Tatsache, dass dieses Vorgehen nicht unwesentlich dazu beigetragen hat, die Qualitätsanforderungen des an sich recht schwergewichtigen hausinternen „S3“-Prozesses von TOI zu erfüllen.

Der VSS hat nicht nur (auch über ein größeres Redesign hinweg) seinen Ruf als stabiles, aber auch flexibles System verteidigt, sondern seine Weiterentwicklung gilt auch anerkanntermaßen als weitgehend „S3-konform“ (was viele andere Projekte im Hause nur schwerlich von sich behaupten können). Dies hat wohl auch dazu beigetragen, dass unser Vorgehensmodell auf durchaus (zumindest meinerseit - ChristianMann) unerwartet hohe Akzeptanz im höheren Management gestoßen ist - was nicht heißt, dass unser Beispiel in größerem Maße Schule gemacht hätte…

Wichtige Elemente

Daily Scrum

Das tägliche Standup-Meeting findet stets von 9.45 - 10.00 Uhr statt. Seine hauptsächliche Aufgabe ist es, Informationen zum aktuellen Projektstand möglichst breit zu verteilen, sowie auch den Kollegen aus der Wartung die Gelegenheit zu geben, aktuelle Probleme auf den Tisch zu bringen.

Typischerweise schließen sich an den Daily Scrum div. spontane „Popup-Meetings“ an, in denen aktuelle Probleme kurz durchdiskutiert & Lösungsansätze angerissen werden.

scrum1.jpg

Der Projektleiter (rechts) und sein Projekt-Koordinator beim „Daily Scrum“; im Hintergrund (vlnr.) auf Metaplan-Wänden

  • Tagesaufgaben der Mitarbeiter
  • Sprint Backlog
  • Project Backlog

(Stand: Februar 2006)

scrum3.jpg

Ein Teil des Teams…
(zwischen 7 und 10 Personen, zzgl. Projektleitung)

Informationsradiatoren

Faktisch wird ein guter Teil der Projektorganisation über Metaplan-Wände erledigt (wobei aber nicht verschwiegen werden soll, dass deren Inhalt in regelmäßigen Abständen in die klassischen Gantt-Charts, bzw. M$-Project wandern muss, um der schwergewichtigen Form genüge zu tun… aber das betrifft nur unseren bemitleidenswerten Projekt-Koordinator - Sacrifice One Person)

Die verschiedenen „Backlogs“ werden auf jeweils eigenen Metaplan-Wänden repräsentiert, wobei die einzelnen Karten zudem über ihren Farben kategorisieren werden:

  • Blau = Produktionsprobleme/-themen
  • Grün = Neue Features
  • Gelb = Anforderungen in einem frühen Stadium
  • Weiß = Sonstige Aufgaben
  • Rot = „Ongoing Tasks“, Querschnittsaufgaben ohne direkten Feature- oder Problembezug (nur für Tagesaufgaben!)

Die farbigen Klebepunkte auf den Karten dienen dem Tracking der tatsächlichen Aufwände; sie werden im Daily Scrum gemäß den Angaben der Team-Mitglieder verteilt (Granulation: 1/4, 1/2, 3/4 oder ganzer Tag, durch die Farbe des Klebepunktes bestimmt).

Project Backlog

project-backlog.jpg

Unser Project Backlog umfasst im wesentlichen Vorgänge, die aktuell „auf dem Radar“ sind. Dabei gibt es eine spezielle „Watchlist“ (unten), die an sich bereits behandelte Themen berücksichtigt, bei denen mit weiterem Handlungsbedarf gerechnet wird; oftmals handelt es sich dabei um Produktionsprobleme, bei denen man sich nicht sicher ist, ob die tatsächliche Ursache erfolgreich behoben wurde.

Sprint Backlog

sprint-backlog.jpg

Der Sprint Backlog wird (entgegen der „reinen Lehre“) nicht als unveränderbar behandelt, sondern kann sich durchaus auch im jeweils aktuellen Monat noch ändern - wobei allerdings darauf geachtet wird, dass dies nicht Features betrifft, die bereits in Bearbeitung sind!

Ausschlaggebend ist hier

  • ob das Feature gegenüber dem Fachbereich & den anderen Systemen für das entsprechende Deployment zugesagt wurde, und
  • ob alle anderen beteiligten Systeme ihre Zusagen ebenfalls halten können!

Es kommt durchaus vor, dass sich das zugrundeliegende Prozessdesign als problematisch herausstellt, weshalb das Feature dann verschoben werden muss… :-/

"Tagesaufgaben"

tagesaufgaben.jpg

Ursprünglich war es durchaus intendiert, die Granulation der letztlich aktuell einzelnen Team-Mitgliedern zugeordneten Aufgaben im Sinne von XP-Taskkarten möglichst nahe an einem Aufwandstag zu halten. Einige Aufgaben-Karten erfüllen dies auch durchaus.

Allerdings sind die einzelnen Features typischerweise umfangreich genug, dass sie sinnvollerweise mit einem eigenen Design-Dokument hinterlegt werden. In diesen Design-Dokumenten werden die Aufgaben hinreichend feingranular beschrieben, so dass sich die Umsetzung in der Regel durchaus annähernd tagesgenau planen lässt. Die Notwendigkeit, dies wiederum in eigenen Taskkarten niederzulegen, die dann konket zugeordnet & abgehakt werden, hat sich bisher nicht ergeben…

Konfigurationsmanagement

konfigmgmt.jpg

Auch das Konfigurationsmanagement wird über eine Metaplan-Wand „orchestriert“: die abgearbeiteten Aufgaben-Karten werdender jeweiligen Releasenote, unter der der entsprechende Code abgelegt wird, zugeordnet, um die Übersicht über die in das nächste Deployment einfließenden Features zu behalten.

Der VSS ist im Kern eine batch-orientierte Datenbankanwendung, deren Kern in PL/SQL implementiert ist, die aber durch div. „Satellitenanwendungen“ unterstützt wird, die typischerweise als eigene Teilprojekte in Java entwickelt werden. Von daher sind bereits im VSS selbst bis zu (derzeit) 9 parallele Entwicklungsstränge qua jeweils eigene Releasenotes zu koordinieren!

Christian Mann 2010/10/24 15:50

 
scrum_toi.txt · Zuletzt geändert: 2010/10/24 16:01 von Christian Mann
 
Falls nicht anders bezeichnet, ist der Inhalt dieses Wikis unter der folgenden Lizenz veröffentlicht:GNU Free Documentation License 1.2
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki