Software-Projekte sind in den Regel nicht bis ins kleinste Detail planbar und ständigen Änderungen unterworfen – in Entwicklungsprojekten für mobile Anwendungen sieht das nicht anders aus. Um diesen Anforderungen zu begegnen, sind für viele Teams agile Vorgehensmodelle wie Scrum die Lösung – doch ist der Einsatz in diesen Fällen sinnvoll?
Spielen wir die Situation einmal durch.
Die Rahmenbedingungen
Wir gehen von folgenden Szenarien aus, die durchaus typisch für Mobile-Projekte sind: Das relativ kleine Team besteht aus zwei bis drei Entwicklern. Die Kernarbeit wird je von einem Android- und einem iOS-Experten erledigt. Gemeinsam und mit Unterstützung durch einen weiteren Entwickler werden Querschnittthemen wie Backendanbindung, Systemarchitektur und Design entworfen und umgesetzt.
Das Projekt hat eine relativ kurze Laufzeit von drei bis vier Monaten. Sobald die Entwickler eingespielt sind und ihren Arbeitsmodus gefunden haben, ist das Projekt auch schon fast wieder vorbei.
Da die Mindestgröße für ein Scrum-Team damit regelmäßig unterschritten wird und aufgrund der kurzen Dauer kaum Sprints möglich sind, scheint Scrum auf den ersten Blick also nicht die passende Methode für diese Art von Projekten zu sein. Man könnte jetzt annehmen, dass die beste Möglichkeit, solch kleine Projekte zu managen, das Wasserfall-Modell ist.
Doch das Fazit ist falsch.
Scrum sinnvoll nutzen
Ich setze auch bei kleineren Projekten auf Scrum, bzw. auf den Einsatz einzelner Artefakte, die mir, dem Team und dem Kunden helfen, das Projekt erfolgreich abzuschließen.
Auch wenn die Entwickler autark auf jeweils ihrer Plattform entwickeln, müssen sie sich sowohl fachlich als auch technisch intensiv abstimmen. Da die Entwicklung für die Plattformen parallel läuft und eine gleiche Priorisierung angesetzt wird, kann auch ein gemeinsames Backlog verwendet werden. Beim Planning Poker bewertet der Entwickler jeweils die Umsetzung für seine Plattform. Da die technische Umsetzung von Aufgaben in der Komplexität bei jeder Plattform meist gleich ist, können eventuelle Missverständnisse trotzdem zum Vorschein gebracht werden. Die Sprint-Länge wird möglichst kurz gewählt, die Meetings werden entsprechend gekürzt. Die Sprint-Ergebnisse können als Inkremente direkt dem Kunden über Betatesting-Plattformen bereitgestellt werden.
Eine Anpassung der Scrum-nach-Lehrbuch-Artefakte setze ich bei Projekten mit technisch komplexen Rahmenbedingungen ein. In diesem Fall wird ein Backlog pro Plattform gepflegt, in dem die Priorisierung so angepasst wird, dass die Umsetzung zum Beispiel einer Peripherie-Anbindung mit kundenspezifischen Protokollen zunächst auf einer Plattform realisiert wird. Die Erfahrungen fließen als Synergie-Effekte in die Entwicklung für andere Plattformen mit ein.
Dass die Vorstellung des Kunden vom fertigen Ergebnis niemals vor dem Projekt vollständig und final definiert ist und Änderungswünsche immer diskutiert und umgesetzt werden müssen, ist kein Nachteil: Das Team ist agil und kann auf Änderungswünsche eingehen – auch wenn nur einzelne Scrum-Elemente eingesetzt werden. So erhält der Kunde bei Abschluss genau die App, die er haben möchte und nicht die, die wir anhand von Vorstellungen zu Projektstart entwickelt hätten.
Fazit
Scrum und Mobile – kann das gutgehen? Na klar! Wichtig ist, das Modell nicht einfach nur einzusetzen, weil es eingesetzt werden soll. Schauen Sie genau hin: Sind die entsprechenden Rahmenbedingungen gegeben, um den gesamten Scrum-Prozess zu durchlaufen? Oder wäre es besser, nur einzelne Artefakte zu nutzen? Seien Sie kritisch, dann steht einem erfolgreichen Mobile-Projekt nichts im Wege. Vielleicht haben Sie ja schon eine Idee für eine App und wollen für die Entwicklung Scrum einsetzen? Oder stehen Sie noch ganz am Anfang? Melden Sie sich bei uns – wir freuen uns darauf, Sie zu unterstützen.
Kommentare