Change, Sprint, Timeboxing

Agile Projekte fassen häufig die während der Entwicklung anfallenden Aufgaben, etwa neue Funktionalitäten programmieren und Fehler beheben, unter dem Begriff Changes zusammen. Das Scrum-Team setzt sich einen immer gleich lang bleibenden Zeitrahmen für diese Aufgaben und nennt das einen Sprint.

Den Ansatz, immer wieder eine gleiche Periode bis zu einer abschließenden Release festzulegen - typischerweise zwei bis vier Wochen -, bezeichnen Projektmanager auch als Timeboxing. Durch die Transparenz und Planungssicherheit treten bei Sprints Defekte und Probleme schneller hervor. Das trifft besonders deutlich auf verteilte Teams zu.

Trotz gewisser Anleihen ist der Ansatz der Community-Projekte nicht deckungsgleich mit dem Scrum-Ansatz, da die Taktung eine andere ist: So streben Fedora, Ubuntu oder KDE etwa alle sechs Monate Releases an. Wegen der speziellen Rahmenbedingungen eines Community-Projekts sind wiederkehrende Sprints hier eher unüblich. Ressourcen und somit auch Implementierungen, geschweige denn ganze Release-Inhalte lassen sich selten planen, von langfristigen Roadmaps ganz zu schweigen.

Hier zeigt sich ein Unterschied zu kommerziellen Projekten. Konkrete Inhalte zeitlich zu planen und in wiederkehrender, fest vorgegebener Taktung bereitzustellen ist ein Luxus, den sich nur wenige Community-Projekte leisten können. Aus ähnlichem Grund sind tägliche Synchronisations-Runden, Daily Scrums genannt, kaum übertragbar (siehe Abbildung 1). Der Austausch geschieht hier primär über den eigentlichen Code und formlos via Mail, Chat oder Bugtracker (siehe auch Kasten "Pro und Kontra").

Abbildung 1: Anders als Entwicklungsteams an einem Ort arbeiten viele Open-Source-Projekte verteilt und können keine Besprechungen abhalten. An deren Stelle treten dann Mail, Chat oder Bugtracker.

Ganz anders sieht es mit Extreme Programming (XP) aus [7]. Es bietet sowohl Vorschläge, um ein Projekt grundsätzlich zu organisieren, als auch entwicklungsnahe Prinzipien und Praktiken. Refactoring, permanente Integration, Coding-Standards oder einfaches Design sind auch isoliert nutzbar.

XP hat übrigens nichts mit spontanem Coding zu tun, sondern ist, genauso wie Scrum, mit Disziplin verbunden. Der namengebende Begriff zielt darauf ab, dass für den Projekterfolg notwendige Aspekte, etwa kleine iterative Schritte, extrem angewendet werden sollen. Das gelingt auch in Community-Projekten.

Menschen vor Technik

Wo Software entwickelt wird, sollten Menschen im Vordergrund stehen [8]. Dann bringen agile Strategien in einigen Situationen einen Mehrwert. Viele Community-Projekte tun dies bereits seit Langem implizit, sie mit Scrum zu organisieren ist grundsätzlich möglich. Rahmenparameter wie das Fehlen der örtlichen Nähe liefern jedoch Argumente, die zwar gegen Scrum, aber für eine pragmatische Herangehensweise mit einer situativen Orchestrierung auch agiler Strategien sprechen.

Community-Projekte setzen fast immer eine umfassende technische Infrastruktur ein, die bereits agile Strategien unterstützt und implementiert. Zentrum der leichtgewichtigen Werkzeugkette sind oft Versionsverwaltung, Mailinglisten und Build-Server. Und damit haben Linux-Entwickler bekanntlich schon sehr erfolgreich Software entwickelt. (mg)