Blog

Agiles Projektmanagement in der App Entwicklung

Allgemein, Allgemein 12. Juli 2013 By

Als Startup stellt man sich täglich neuen Herausforderungen und versucht stets flexibel zu bleiben. Klassisches Projektmanagement wie Wasserfall und Co stören diesen Prozess und blockieren die Dynamik eines jeden Projektes. Parallele Projektkoordination, Multitasking, Planänderungen, Kundenwünsche, Ressourcenknappheit und die Kalkulationen sind das Daily Business eines digitalen Dienstleisters. Schlussfolgernd suchten wir Anfang des Jahres nach einer Alternative und fanden sie in Scrum, einem agilen Prozess. Scrum, zu deutsch Gedränge, verspricht Transparenz und Flexibilität durch gesteigerte Kommunikation, iterativ-inkrementellen Vorgehensweise und klar definierte Rollen und Regeln.

Die Rollen bei Scrum

Wie auch im klassischen Projektmanagement besteht ein Team aus mehreren Mitgliedern mit unterschiedlichen Aufgaben. Im Scrum Prozess wird hierbei zwischen den Scrum Team und Außenstehenden wie dem Kunden differenziert.

Scrum Team

Entwicklungsteam

Das Team ist der Lieferant und steuert die Entwicklung einer Applikation. Es besteht aus 3-7 Personen und arbeitet kontinuierlich an dem s.g. Product Backlog (sprich den Anforderungen des Kunden) und liefert nach jedem Sprintzyklus (1-2 Wochen) ein voll funktionsfähiges Stück der App. In unserem Fall kann das ein Feature wie beispielsweise der Login oder die Benutzerregistrierung sein.
Bei den meisten Projekten arbeitet plazz mit einem Feature Team. Im Gegensatz zu den ebenso möglichen Komponententeams, die in Abhängigkeiten zu anderen Teams stehen, sind hier alle nötigen Ressourcen und Fähigkeiten in einer Gruppe vorhanden (Konzept, Design, Backend- und Frontendprogrammierung). Dies steigert die Performanz des Teams durch verkürzte Kommunikationswege und komponentenübergreifende Lösungsansätze.

Product Owner (PO)

Jedes Projekt braucht einen Manager – den Planer und Visionär des Produktes. Er trägt die Verantwortung der fristgerechten Lieferung und Priorisierung einzelner Stories und den Aufgaben im Backlog. Weiterhin definiert er die Stories und steht für Rückfragen zur Verfügung.
In unserem Fall findet hier die Übertragung zwischen Kunde und Dienstleister statt. Der PO klärt die Anforderungen, schreibt anschließend Stories und nimmt das Kundenfeedback entgegen. Die Stories sind verbale Formulierungen aus Usersicht wie beispielsweise: "Als User möchte ich einen Account anlegen, um die App zu nutzen.“ Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen>.

Scrum Master

Der Scrum Master unterstützt sein Team. Er organisiert und moderiert die Meetings des Prozesses. Außerdem achtet man auf die Regeleinhaltung wie zeitliche Begrenzung der Meetings (Timeboxing) oder das Beseitigen vorhandener Hindernisse im Backlog, den Impediments.
Im Fall von plazz ist das der Kontakt mit Webhostern oder auch die Anschaffung von Testgeräten und Equipment.

Teamumgebung

Ausserhalb des Scrum Prozesses gibt es weitere Rollen. Dazu zählen der Kunde, welcher das Produkt finanziert, das Management, welches den Rahmen der Entwicklung koordiniert und der Anwender, welcher in die Projektentwicklung einbezogen wird und eine der wichtigsten Informationsquellen für das Entwicklungsteam darstellt.

Der Scrum Flow

Nachdem die Rollen in Scrum aufgezeigt wurden, widmen wir uns dem eigentlichen Prozess, dem Workflow mit Scrum.

flow

Product Backlog

Wie bereits erwähnt, steht am Anfang eines Projektes der Product Backlog. Diese priorisierte Anforderungsliste wird aus der Kundenanfrage generiert und beinhaltet einen Schätzwert des Teams.  Die sich hieraus ergebenden Storypoints sind keine Manntage sondern eine gefühlte Größe im Bezug auf Aufwand und Komplexität eines Features wie beispielsweise dem Login. In einem iterativen Prozess werden die Stories stetig aktualisiert und neu bewertet.

Sprint

Der Sprint stellt einen Zyklus von 1-2 Wochen Entwicklungsarbeit da. Hier werden die Stories aus dem Produkt Backlog in den Sprint Backlog übertragen und abgearbeitet. Die Zuteilung der User Stories erfolgt im Sprint Planing. Läuft der Prozess einmal, gibt es jeden Tag ein kurzes Abstimmungsmeeting des gesamten Teams. Dieses Daily Scrum dauert maximal 15 Minuten und jeder Mitarbeiter muss folgendes erläutern:

–       Was habe ich gestern getan?
–       Was mache ich heute?
–       Was behindert mich bei der Aufgabe?

Das Daily dient somit der frühzeitigen Problemerkennung, der Ressourcen- und Teameinschätzung sowie der Einplanung möglichen Kundenwünsche. Mit jedem Sprint erhält der Kunde also ein lauffähiges System, welches sich dem Endprodukt annähert.

Am Ende jedes Sprints steht das Sprint Review. Hier präsentiert das Team dem Product Owner und Kunden das Ergebnis seiner Arbeit live am System und sammelt erstes Feedback ein. Um den Scrum Prozess kontinuierlich zu verbessern folgt anschließend eine Retrospektive. Sie dient dazu, Erfahrungen aus dem Sprint zu reflektieren und Verbesserungsmöglichkeiten aufzuzeigen.

Was sind also die Vorteile für den Kunden?

–       Entgegen dem Wasserfall Modell können jederzeit Modifikationen eingebracht werden.
–       Der Entwicklungsstand ist transparent und jedes Feature kann in Aufwand / Nutzen gesetzt werden.
–       Die Entwicklung verläuft aus Anwendersicht und das beginnt schon bei dem erstellen von Stories.

Wo liegen die Gefahren?

–       Fixpreise sind nur schwer umsetzbar, da eine Kalkulation nur den Rahmen abstecken kann.
–       Feste Deadlines bei wachsenden Anforderungen
–       Eine Dokumentation im klassischen Sinne hat niedrigere Priorität.
–       Bei Scrum gibt es einen erhöhten Kommunikations- und Abstimmungsfaktor

Erstes Fazit

Der erste Schritt ist gemacht und die ersten Projekte laufen im Scrum Prozess. Dennoch muss man Kunden sensibilisieren und gerade bei kleinen Projekten hinterfragen ob und wie das Projekt in Scrum integriert werden kann. Weiterhin fällt auf, dass die Kommunikation bei Großprojekten viel Zeit in Anspruch nimmt und man dazu neigt die Übersicht zu verlieren. Grundsätzlich erleichtert Scrum jedoch die Entwicklung enorm und steigert die Produktivität des Teams.

Lesenswert dazu:

http://borisgloger.com/scrum
http://www.it-agile.de/scrum.html
http://ralfrottmann.net/there-is-no-agile-fixed-price

 


Stefan Heinz

Als Art Director ist Stefan Leiter im Bereich Design und Konzeption. Mit Wurzeln in der Welt von Werbeagenturen und dem generalistischen Studium in Online Medien an der Hochschule Furtwangen University hat er sich auf UI und UX sowie Beratung und Kommunikation vertieft.


Switch to Flat 3. Juli 2013 Silberner Löwe für … 25. Juli 2013