Als man Software-Entwickler noch Programmierer nannte, wurden Projekte entweder gar nicht geplant und nach Art des bewährten Projekt-Managements, wie man es auch beim Bau von Brücken und Wolkenkratzern nutzt. Nun aber macht seit einiger Zeit eine Methode die Runde, die einfach „Scrum“ heißt und die sogenannte „agile“ Software-Entwicklung ermöglicht. Warum diese Art Projekt-Management nach einem Begriff aus dem Rugby benannt wurde, erklärt sich erst, wenn man weiß, wie Scrum funktioniert.

Im Grunde ist der Begriff „agile Software-Entwicklung“ der wichtigere. Die Idee dahinter ist, so schnell wie möglich zu ausführbaren Programmen zu kommen, also die Entwurfsphase so kurz wie möglich zu halten. Das geht überhaupt nur, weil beim Bau von Anwendungen (und übrigens auch Websites) so gut wie gar nicht mehr programmiert wird. Alle aktuellen Systeme, mit den Anwendungen, Apps und Websites realisiert werden, arbeiten nach dem Prinzip der Frameworks.

Ein solches Framework kann man sich als eine Art Lego-Kiste vorstellen, in der Hunderte verschiedenfarbiger Steine und Elemente mit unterschiedlichen Funktionen liegen, die nur eines gemeinsam haben: die Schnittstellen, mit denen man sie zusammenfügt. Programmiert werden nur noch diese Elemente, und selbst die entstehen viel öfter durch das Klonen vorhandener Bausteine und deren Anpassung.

Form und Funktion scharf getrennt

Außerdem sind heutzutage bei der Software-Entwicklung jeder Art Form und Funktion scharf voneinander getrennt. User-Interface (UI) und die sogenannte „User-Experience“ (UX) können völlig unabhängig von der darunterliegenden Funktionsebene entworfen werden – sofern man sich innerhalb eines Systems mit definierten Schnittstellen (APIs) bewegt. Umgekehrt können sich Programmierer die tollsten Funktionen ausdenken und mit Hilfe eines Frameworks realisieren, ohne sich auch die geringsten Gedanken über das zu machen, was der User später davon zu sehen bekommt und wie genau er diese nutzt.

Historisch entwickelt hat sich die agile Software-Entwicklung einerseits aus dem Fortschritt bei den Programmiersprachen – insbesondere bei C++ – sowie den Rahmenbedingungen, die Apple und Google für den Bau von Apps für iOS und Android vorgegeben haben. Das Besondere beim „Programmieren“ für Online-Anwendungen: Es findet außerhalb der Frameworks für diese Systeme schlicht und einfach nicht mehr statt. Niemand muss sich also seine Lego-Steine selbst aus Kunststoff kneten.

So bringt die agile Software-Entwicklung mehr Transparenz in die Entwicklung und führt dazu, dass Anpassungen und Veränderungen in kürzester Zeit umgesetzt werden können. Das hat übrigens vor allem die Möglichkeiten der Kooperation zwischen Auftraggebern und entwickelnden Dienstleistern erheblich verbessert, verkürzt den Prozess und führt zu sinkenden Kosten.

Mehr Transparenz, höhere Geschwindigkeit, geringere Kosten

Scrum ist ursprünglich eine Sonderform des Lean Development, bei der kleine, autonome Teams gleichberechtigter Mitglieder eigenständig Lösungen entwickeln. Sie werden von außen nicht gesteuert, sondern bekommen nur das Ziel zugeteilt; die Strategie und Taktik entwickelt ein solches Team selbst. Zuerst eingesetzt wurde die Scrum-Methodik ab etwa 1995 im japanischen Automobilbau, wo es bis heute beinahe die Rolle einer Philosophie einnimmt. Weil die Teams autark arbeiten und ihre Taktik von Fall zu Fall anpassen, kam in Japan der Begriff „Scrum“ auf.

Das deutsche Wort für diesen Rugby-Begriff lautet „Gedränge„. Dabei handelt es sich um eine Standardsituation, die immer dann angeordnet wird, wenn das Spiel nach einer Unterbrechung neu gestartet werden muss. Je acht Spieler jeden Teams bilden die beiden Hälften des Gedränges, in dessen Mittelgasse das Ei gerollt wird. Die Spieler versuchen nun, den Ball mit den Füßen von innen nach außen auf ihre Seite zu befördern, um so zu Ballbesitz zu kommen. Dabei bestimmen die Teilnehmer des Gedränges durch Kommunikation untereinander die Taktik. Also: Kein Trainer oder Kapitän gibt die Methode vor; was auch sinnlos wäre, weil die Gegner dasselbe Ziel haben.

Project-Owner, Entwicklungsteam, Scrum-Master

In der Praxis wird also bei einem Unternehmen, das den Auftrag zur Entwicklung einer Software bekommen hat, ein Team gebildet. Und zwar unter Anwendung von Kriterien wie Ressourcenbedarf, Knowhow-Profilen, Erfahrungsschatz und Kommunikationsfähigkeit, die jeweils nach dem gewünschten Endergebnis bewertet werden. Anders als beim Rugby-Gedränge gibt es beim Scrum drei Parteien: den Product-Owner, das Entwicklungsteam und den Scrum-Master.

Die Rolle des Product-Owners ähnelt der des altmodischen Projektmanager, er definiert die Eigenschaften des zukünftigen Produkts und ist für die erfolgreiche Realisierung verantwortlich. Mitglied des Entwicklungsteams ist er aber nicht. Auch der Scrum-Master ist nicht Teil der Mannschaft, sondern eine Art Mädchen für alles. In dieser Rolle sorgt für die Einhaltung der Scrum-Regeln und vor allem dafür, dass dem Team alles für die erfolgreiche Arbeit geboten wird. Das reicht vom Bereitstellen der nötigen Technik bis zum Erzeugen einer Wohlfühlatmosphäre und der Moderation von Konflikten im Team.

Das wahrhaft Besondere an Scrum aber ist, dass nicht kontinuierlich Schritt für Schritt gearbeitet wird, sondern in Zyklen. Denn:

Der Ansatz von Scrum ist empirisch, inkrementell und iterativ. Er beruht auf der Erfahrung, dass viele Entwicklungsprojekte zu komplex sind, um in einen vollumfänglichen Plan gefasst werden zu können. Ein wesentlicher Teil der Anforderungen und der Lösungsansätze ist zu Beginn unklar. Diese Unklarheit lässt sich beseitigen, indem Zwischenergebnisse geschaffen werden. Anhand dieser Zwischenergebnisse lassen sich die fehlenden Anforderungen und Lösungstechniken effizienter finden als durch eine abstrakte Klärungsphase. [Quelle: Wikipedia]

Nicht lange reden, machen!

Salopp ausgedrückt geht man mit Scrum nach dem Motto „Nicht lange reden, machen!“ vor. In sogenannten „Sprints“ wird ein Zwischenergebnis erzeugt und bewertet. Die Analyse ergibt dann ganz konkret, was nicht in Ordnung ist und was noch fehlt. Im folgenden Sprint werden dann Fehler ausgemerzt und Fehlendes integriert.

Geradezu idealtypisch funktioniert da bei der Entwicklung von Websites mit einem Content-Management-System wie Typo3 sowie einem darauf zugeschnittenen Framework. Einem Auftraggeber kann innerhalb weniger Tage ein teilweise funktionsfähiger Prototyp präsentiert werden, also eine Website, die schon ungefähr so aussieht wie gewünscht und bereits die meisten (Standard)funktionen enthält. Ein solcher Prototyp wird mit dem Auftraggeber diskutiert, woraus sich die Arbeiten für den nächsten Sprint ergeben.

Scrum ist ein Buzzword, das Otto Normalanwender in der Regel nicht erreicht. Auch wenn es einen gewaltigen Theorieüberbau gibt, ist diese Methode doch im Kern pragmatisch und absolut alltagstauglich. Vermutlich werden aktuell 99 Prozent aller Apps für mobile Endgeräte in Scrum-Verfahren entwickelt. Das gute, alte Projektmanagement früherer Tage kommt dagegen fast nur noch bei der Entwicklung komplexer Systeme jenseits von Anwendungsprogrammen zum Einsatz. Beides wird auch wohl auf nicht absehbare Zeit so bleiben.

[Bildnachweis – Titelbild: PierreSelim via Wikimedia unter der Lizenz CC BY-SA 3.0; Agile Softwareentwicklung via scnsoft.de;]