Seite I

Inhaltsverzeichnis

1  Einleitung  1

2  Grundlagen  1

2.1  Agile Vorgehensmodelle  1

2.1.1  Das „Manifesto for Agile Software Development“  2

2.1.2  Scrum  2

2.1.3  Extreme Programming  4

2.1.4  Kanban  6

2.2  Die Java-basierte Sprache Groovy  8

2.3  Das Web-Application-Framework Grails  9

2.3.1  Die Entstehung von Grails  10

2.3.2  Die Konzepte von Grails  11

3  Grails in der Entwicklung von agilen Web-Anwendungen  13

3.1  Grails und Scrum  13

3.2  Grails und Extreme Programming  14

3.3  Grails und Kanban.  15

4  Schlussbetrachtung  15

Seite II

Abkürzungsverzeichnis

Abbildungsverzeichnis

Abbildung 1: Überblick über den Scrum-Prozess ............................................................. 3 Abbildung 2: Überblick über den XP-Prozess .................................................................. 5 Abbildung 3: Beispiel für ein Kanban Board .................................................................... 7 Abbildung 4: Der Grails Stack ........................................................................................ 10

Tabellenverzeichnis

Tabelle 1: Vergleich von Java- und Groovy-Syntax („Hallo Welt!“, Bereiche und

Closures, Properties) ......................................................................................................... 8

Seite 1

1 Einleitung

Agile Methoden haben bei der Organisation von Projekten in den vergangenen Jahren weiter an Bedeutung gewonnen. Gerade in der Softwareentwicklung erfreuen sie sich großer Beliebtheit und so steigt die Zahl der Projekte, in denen Scrum, Extreme Programming, Kanban oder ähnliche Vorgehensmodelle zum Einsatz kommen. Kunden und Dienstleister versprechen sich hierdurch bessere Produkte und kürzere Entwicklungszyklen. Es soll möglichst schnell ein potenziell auslieferbares Produkt entstehen, das dann nach und nach verbessert und angepasst werden kann. Den Softwareentwicklern kommt in diesem Zuge ein hohes Maß an zusätzlicher Freiheit und Verantwortung zu. Sie treffen sich regelmäßig mit dem Kunden zu Rückschau und Planung, arbeiten mit diversen Backlogs und kommen zum täglichen Stand-Up-Meeting zusammen. Doch außerhalb dieser vorgegeben Methoden kann die Agilität rasch verfliegen, da weiterhin mit unflexiblen Werkzeugen und Frameworks gearbeitet werden muss. Gerade bei der Entwicklung von Web-Anwendungen im Java-Umfeld sind meist erhebliche Vorarbeiten und Konfigurationen notwendig, bevor überhaupt mit der eigentlichen Entwicklung begonnen werden kann. Mit der Sprache Groovy und dem darauf aufsetzenden Web-Application-Framework Grails soll die Entwicklung in der Java-Welt deutlich agiler werden. Ob dies zutrifft und wie dies funktionieren kann, soll diese Arbeit darlegen. Dazu sollen zunächst die Eigenschaften einiger agile Vorgehensmodelle sowie Groovy und Grails vorgestellt werden. Es folgt eine Analyse, wie Grails die Entwicklung in agilen Projekten unterstützen kann sowie ein Blick auf mögliche Grenzen des Einsatzes.

2 Grundlagen

2.1 Agile Vorgehensmodelle

Gerade in der Softwareentwicklung haben sich agile Vorgehensmodelle in den vergangenen Jahren erfolgreich etabliert. Die enge Zusammenarbeit mit dem Kunden, das eigenverantwortliche Arbeiten des Entwicklungsteams und die schnelle Fertigstellung von Teilprodukten werden hierbei als wesentliche Erfolgsfaktoren

Seite 2

herausgestellt. ¹ Grundlage für alle dadurch entstandenen Frameworks und deren Anwendung in der Softwareentwicklung ist das „Manifesto for Agile Software Development“. Allen Ansätzen gemein ist zudem die Philosophie der kontinuierlichen Verbesserung, bekannt unter dem Schlagwort Kaizen. Zu den verbreitetsten Modellen, die auch miteinander kombiniert werden können, gehören Scrum, Extreme Programming und seit einiger Zeit auch Kanban. Diese sollen im Folgenden kurz vorgestellt werden.

2.1.1 Das „Manifesto for Agile Software Development“

Grundlage für die Anwendung agiler Modelle in der Softwareentwicklung sind die im „Manifesto for Agile Software Development“ beschriebenen Grundsätze:

„Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation Responding to change over following a plan.“ 2

Zu den Unterzeichnern des Manifests gehören unter anderem die Entwickler von Extreme Programming Kent Beck, Ward Cunningham und Ron Jeffries sowie die Scrum-Erfinder Ken Schwaber, Jeff Sutherland und Mike Beedle.

2.1.2 Scrum

Der bekannteste Vertreter unter den agilen Vorgehensmodellen ist wohl Scrum. Vor allem in komplexen Softwareentwicklungsprojekten kommt Scrum zum Einsatz. Es basiert auf den Annahmen zur empirischen Prozesssteuerung mit den drei Handlungsfeldern Sichtbarkeit, Inspektion und Anpassung. ³ Der Scrum-Prozess ist iterativ und inkrementell und erfolgt in festen Timeboxen, die Sprints genannt werden. Nach jedem Sprint steht ein potentiell auslieferbares Inkrement bereit. ⁴ Zu Beginn des Projekts erfolgt keine Detailplanung. Diese wird erst im Laufe des Projekts zu jedem Sprint festgelegt wodurch zeitnahe Anpassungen am Projekt möglich werden und das

¹ Laut einer Projektmanagement-Studie von 2009 werden agile Projekte mit 67% deutlich häufiger

erfolgreich abgeschlossen als klassische mit 40%, vgl. Vigenschow, Toth, Wittwer (2009), S. 13

² Beck et. al (2001)

³ Vgl. Schwaber (2007), S. 2 ff.

⁴ Vgl. Schwaber, Sutherland (2010), S. 10

Seite 3

Entwicklungsteam „gemäß dem Auftreten neuer Komplexitäten, Schwierigkeiten und Überraschungen“ ⁵ seinen Lösungsansatz modifizieren kann.

In Scrum existiert eine klare Verteilung von Verantwortlichkeiten auf drei Rollen. Der Product Owner (PO) vertritt die Kundenseite und ist für die Nutzenmaximierung des Projekts verantwortlich. Er verwaltet und priorisiert das Product Backlog, in dem alle für das Projekt notwendigen User Stories enthalten sind, und gestaltet den Entwicklungsprozess aktiv mit. ⁷ Das Team ist für die Entwicklung des Produkts verantwortlich und setzt die notwendigen Schritte innerhalb der Sprints eigenverantwortlich um. ⁸ Der Scrum Master (SM) ist verantwortlich für die Vermittlung des Scrum-Prozesses und dessen Einhaltung. Anders als ein klassischer Projektmanager ist er nicht weisungsbefugt und auch nicht für den Projekterfolg verantwortlich. ⁹ Er stellt die Kommunikation zwischen PO und Team sicher und beseitigt Hindernisse im Entwicklungsprozess, die im Impediment Backlog festgehalten wurden.

Vor jedem Sprint treffen sich PO und Team unter Moderation des SM zum Sprint Planning. In diesem legt der PO fest, welche Elemente des Product Backlogs umgesetzt werden sollen und priorisiert diese. Das Team zerteilt die User Stories in Arbeitspakete,

⁵ Schwaber (2007), S. 6

⁶ Entnommen aus Gentsch, Wittwer (2010)

⁷ Vgl. Schwaber (2007), S. 56

⁸ Vgl. Schwaber (2007), S. 104

⁹ Vgl. Schwaber (2007), S. 28