© pink cherry, Photocase.com© Konstantin Chagin, 123RF.com

Vor zehn Jahren formulierten ein paar Entwickler das Agile Manifesto, heute arbeiten viele Software-Entwickler in Unternehmen danach. Auch auf die verteilte Open-Source-Entwicklung lassen sich einige Aspekte agiler Verfahren aus Scrum & Co. anwenden.

Community-Projekte sind dezentral über das Internet organisiert. Die aktiven Teilnehmer kommunizieren über Kanäle wie Mail und IRC oder schlicht über ein Ticket- oder Versionskontrollsystem (VCS). Sie arbeiten am Projekt gewöhnlich in ihrer Freizeit, sodass sie selten über einen längeren Zeitraum konkrete Ergebnisse zu bestimmten Zeiten verbindlich zusagen können. Und bekanntlich bereiten zu starke Formalismen diesen Entwicklern eher Probleme, steht doch bei ihnen der Spaß im Vordergrund.

Agile Vorgehen wie Scrum [1] legen dagegen Wert auf Synchronisationspunkte wie kurze Meetings, transparente Commitments und klare Zeitplanung. Auf den ersten Blick scheinen also beide Ansätze inkompatibel. Es lohnt sich jedoch, den Begriff Agilität etwas differenzierter zu betrachten.

Ein agil arbeitender Entwickler will durch Selbstauszeichnung mit diesem Attribut sicherlich nicht verdeutlichen, er arbeite agil im eigentlichen Sinne des Wortes, also zackig. Das würde wohl jeder von sich behaupten. Agil ist vielmehr ein bunter Blumenstrauß, der sich in drei Kernbereiche untergliedern lässt. Zunächst nennt das Agile Manifesto die Werte Offenheit, Interaktion und Kollaboration, zu denen sich die Entwickler bekennen [2]. Ergänzend dazu lassen sich agile Praktiken wie Continuous Integration oder Refactoring ausmachen.

Werte, Praktiken, Strategie

Zu guter Letzt gibt es agile Vorgehensmodelle oder Rahmenwerke. Eines davon nennt sich Scrum. Die Modelle zeichnen sich besonders durch Iterationen, Transparenz und enges Einbeziehen des Auftraggebers aus.

Werkzeuge spielen auf allen drei Ebenen eine untergeordnete Rolle, da stattdessen Menschen und Prozesse im Mittelpunkt stehen sollen. Agile Entwickler wählen Werkzeuge für einen konkreten Einsatz aus und konfigurieren sie so, dass sie zu den Prozessen und den Anforderungen passen [3].

Agilität lässt sich auch für Community-Projekte adaptieren. Die Werte finden sich fast immer wieder, gerade weil es sich bei vitalen Projekten um eine gemeinsame, kooperative Arbeit handelt. Viele wenden bereits agile Strategien wie beispielsweise Nightly Builds an. Nicht selten halten dabei Modul-Tests, Überprüfungen auf Testabdeckung oder Audits die Qualität hoch.

Andere typische Strategien sind zwar auf die verteilte Entwicklung anwendbar, haben bei Community-Projekten aber weniger Relevanz, zum Beispiel das Pair Programming (PP). Gelegentliche Treffen oder gemeinsame Coding-Nächte bieten keine Alternative zu einem sauber konzipierten PP. Eine elektronisch verteilte Version von PP ist in Community-Projekten daher auch die große Ausnahme. Die Art der Kommunikation unterscheidet sich bei solchen Projekten stark von Entwicklergruppen, die täglich am selben Ort arbeiten.

Scrum und andere Modelle

Agile Strategien lassen sich auch in vielen Vorgehensmodellen anwenden, zum Beispiel beim Spiral- oder Wasserfall-Modell. Damit erhöhen Entwickler die Chance, ihr Projekt erfolgreich zu beenden. Darüber hinaus basiert jedes Vorgehensmodell in der einen oder anderen Form auf Iterationen – interessanterweise sogar das Wasserfall-Modell.

Vor diesem Hintergrund lassen sich “agile” Merkmale an vielen Ansätzen erkennen. Eines der populärsten agilen Vorgehen ist Scrum. Dieses Management-Rahmenwerk trifft keine Aussagen, wie Projektbeteiligte gerade Software erstellen sollen. Im Grunde kann Scrum auch dabei helfen, eine Fußballmannschaft zusammenzustellen oder einen Taubenzüchterverein zu gründen. Anwender reduzieren Scrum oft auf die eigentliche Konstruktion der Software. Dann fehlen aber bei einer Implementierung für erfolgreiche Projekte ebenfalls nötige Phasen wie Vision und Anforderungserhebung sowie Betrieb und Wartung der Software [4].

Owner, Master, Team

Das abstrakte Scrum muss jedes Team individuell für sein Projekt implementieren. Es spricht zunächst den Projektmanager oder Entscheidungsträger an, der sich mit dem Prozess der Entwicklung auseinandersetzt. Dabei setzt es Rollen, Aktivitäten und Artefakte ins Rampenlicht. Scrum gibt einige grundsätzliche Eckpfeiler vor, einige davon finden sich auch in Community-Projekten.

Scrum kennt drei Rollen: Product Owner, Scrum Master und das Team. Der Product Owner legt das gemeinsame Ziel fest. In Community-Projekten ist dies nur durch einen selbst gewählten Kunden-Proxy möglich, der den “Kunden” des Projekts simulieren soll. Meist übernimmt diese Rolle der Projektleiter, wie ihn etwa das Fedora-Projekt nennt. Ein Scrum-Team arbeitet interdisziplinär an der Software, so arbeiten auch in Community-Projekten Grafikdesigner und Lokalisierungsspezialisten Hand in Hand mit anderen Entwicklern.

Der Scrum Master gehört per Definition interessanterweise nicht zum Team. Er überwacht und begleitet den Prozess und greift steuernd ein. Diese Rolle existiert in Community-Projekten nicht. Seine Aufgaben bilden Projekte durch Regularien und Konventionen ab. Nicht selten üben treibende Projekt-Kräfte sie in Personalunion aus. Werkzeuge stehen stärker im Vordergrund und formen den Entwicklungskanal, zum Beispiel durch unterschiedliche Rechte beim Zugriff auf das Versionskontrollsystem.

Agile Werkzeuge

Die in Scrum genutzten Backlogs lassen sich konzeptionell gut auf Community-Projekte übertragen. Häufig sind es Ticketsysteme, die offene und mögliche Aufgaben beinhalten. Es obliegt dann der Entscheidung eines Release-Managers respektive des Projekt-Owner, ob er ein Feature in eine Release aufnimmt indem er Prioritäten wählt oder wenn Freiwillige die neue Eigenschaft schlicht von sich aus implementieren und einreichen.

Den Fortschritt visualisieren auch Community-Projekte häufig in Burndown-Charts. Technisch ist das mit modernen Ticketsystemen kein Problem, etwa mit dem für Open-Source-Projekte kostenlosen Projektracker Jira [5]. Das bekannteste Beispiel für das Sichtbarmachen der Entwicklung ist wohl der Graph der kritischen Fehler vor der Release einer neuen Debian-Version [6].

Oft schreiben Projekte Anforderungen in einer Form fort, die gut zu Scrum-Projekten passt. Zum Beispiel das Jira-Addon Green Hopper, das Entwicklern hilft User Stories zu formulieren. Risiko- oder Hindernislisten (Impediment Backlogs) aus Scrum führen Community-Projekte aber nur selten, da schwer auszumachen ist, welche Hindernisse zu formulieren und gegen wen sie zu artikulieren sind.

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)