Lade Inhalt...

Agile Entwicklung von Web-Anwendungen mit Grails

Seminararbeit 2011 23 Seiten

Informatik - Programmierung

Leseprobe

Inhaltsverzeichnis

1 Einleitung

2 Grundlagen
2.1 Agile Vorgehensmodelle
2.1.1 Das „Manifesto for Agile Software Development“
2.1.2 Scrum
2.1.3 Extreme Programming
2.1.4 Kanban
2.2 Die Java-basierte Sprache Groovy
2.3 Das Web-Application-Framework Grails
2.3.1 Die Entstehung von Grails
2.3.2 Die Konzepte von Grails

3 Grails in der Entwicklung von agilen Web-Anwendungen
3.1 Grails und Scrum
3.2 Grails und Extreme Programming
3.3 Grails und Kanban

4 Schlussbetrachtung

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

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 herausgestellt.1 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.3 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.4 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 Entwicklungsteam „gemäß dem Auftreten neuer Komplexitäten, Schwierigkeiten und Überraschungen“5 seinen Lösungsansatz modifizieren kann.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Überblick über den Scrum-Prozess6

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.7 Das Team ist für die Entwicklung des Produkts verantwortlich und setzt die notwendigen Schritte innerhalb der Sprints eigenverantwortlich um.8 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.9 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, schätzt dafür den Aufwand und legt fest, welche Pakete tatsächlich im Sprint umgesetzt werden können. Die Arbeitspakete werden im Sprint Backlog festgehalten.10 Im Laufe des Sprints wird der Fortschritt des Teams im Burndown Chart visualisiert, in dem der geschätzte verbleibende Restaufwand für die Erreichung der Sprint-Ziele mit der noch zur Verfügung stehenden Zeit in Korrelation gesetzt wird. Das Team trifft sich außerdem zum Daily Scrum, um sich gegenseitig über erledigte und anstehende Aufgaben zu informieren.11 Nach dem Sprint erfolgt dann das Sprint Review Meeting, in dem das Team dem PO seine Arbeitsergebnisse präsentiert. Der PO kann dann entscheiden, ob die Ergebnisse in seinem Sinne als fertig anzusehen sind oder ob in folgenden Sprints noch nachgebessert werden muss.12

2.1.3 Extreme Programming

Extreme Programming (XP) ist ein Prozessmodell und gilt als die Grundlage aller agilen Vorgehensweisen in der Softwareentwicklung.13 Es hat seinen Ursprung im „Chrysler Comprehensive Compensation Systems“-Projekt, das beim Automobilhersteller Chrysler unter Führung von Kent Beck 1996 mit den späteren XP- Methoden umgesetzt wurde.14 XP ist ausgelegt „für kleinere Projekte mit unklaren und sich immer wieder ändernden Anforderungen“.15 Auch im XP ist der Entwicklungsprozess iterativ und inkrementell. Die Entwicklung ist unterteilt in Releases, die wiederum aus Iterationen bestehen. Die Iterationen werden dann in Arbeitspakete von ein bis drei Tagen zerlegt. Ähnlich wie bei Scrum soll bereits nach dem ersten Release ein potenziell auslieferbares Inkrement fertiggestellt sein.16

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Überblick über den XP-Prozess17

XP berücksichtigt immer die Variablen Kosten, Zeit, Qualität und Scope und verfolgt die grundsätzliche Werte Kommunikation, Einfachheit, Feedback und Mut.18

Jede Iteration wird im Planungsspiel vorbereitet. Der Kunde legt seine Wünsche in Form von Stories dar und priorisiert diese. Das Entwicklerteam schätzt hierfür die Aufwände. Übersteigt der geschätzte Aufwand die für die Iteration zur Verfügung stehenden Ressourcen, muss der Kunde seine Stories erneut planen und einige eventuell in eine spätere Iteration verschieben. Dieser Vorgang wird so lange wiederholt, bis Kundenwünsche und Teamressourcen miteinander harmonisieren.19

Grundlegender Bestandteil von XP sind Tests. Zum einen erstellen die Entwickler unit tests für ihre Klassen, zum anderen entwickelt der Kunde für seine Anwendungsfälle functional tests. Die Entwickler sind in XP gezwungen, ihre Tests bereits vor der eigentlichen Implementierung der Funktionalitäten zu schreiben.20 Die Entwickler sollen zudem immer nach einfachen Lösungen suchen und dabei mögliche zukünftige Erweiterungen zu berücksichtigen. Dies geschieht vor dem Hintergrund, dass die Anforderungen dieser zukünftigen Erweiterungen sich im Laufe des Projekts noch verändern können. Der Programmcode wird immer wieder refaktorisiert. Die unit tests sollen dabei mögliche Fehler aufzeigen. Die Dokumentation erfolgt nahezu ausschließlich durch den eigentlichen Programmcode, der entsprechend selbsterklärend sein muss.21 Weiterer zentraler Bestandteil von XP ist das pair programming. Es arbeiten jeweils zwei Entwickler gemeinsam, wobei der eine programmiert und der andere dessen Code laufend auf Fehler und Verbesserungsmöglichkeiten prüft.22 Die Rollen innerhalb des Paares sollen regelmäßig wechseln. Auch werden die Paare immer wieder neu zusammengestellt. So soll gewährleistet werden, „dass sich das Wissen über alle Aspekte des Systems auf alle Entwickler verbreitet“.23 Zudem gehört der entstehende Code immer dem gesamten Team und nie einem einzelnen Entwickler und kann somit jederzeit von jedem Entwickler angepasst und optimiert werden. Das Team vereinbart zudem verbindliche Programmierrichtlinien, um eine einheitliche Code-Basis zu gewährleisten. Um die beschriebene, sehr anspruchsvolle, Art der Teamarbeit gewährleisten zu können, verlangt XP geregelte Arbeitszeiten ohne Überstunden.

In der Praxis werden die XP-Praktiken häufig mit Scrum kombiniert. Beide Modelle beschreiben einen iterativen und inkrementellen Entwicklungsprozess. Während Scrum eher den Ablauf eines Projekts mit Meetings, Rollen und Artefakten beschreibt, definiert XP die Art und Weise, in der das Entwicklerteam arbeitet und die mit dem PO vereinbarten Ziele erreicht.24

2.1.4 Kanban

Kanban wurde ursprünglich bei Toyota entwickelt und bedeutet im Japanischen „Signalkarte“. Diese Karten wurden zur Steuerung von Fertigungsstationen verwendet. Jede Station sollte immer nur so viele Zwischenprodukte herstellen, wie die nachfolgende Station verarbeiten konnte.25 Nach diesem Vorbild wurden die Prinzipien der lean production in die IT-Welt übertragen. Die zentralen Ideen hierbei sind Visualisierung, Pull statt Push, Begrenzung paralleler Arbeit und Kaizen.26

[...]


1 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

2 Beck et. al (2001)

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

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

5 Schwaber (2007), S. 6

6 Entnommen aus Gentsch, Wittwer (2010)

7 Vgl. Schwaber (2007), S. 56

8 Vgl. Schwaber (2007), S. 104

9 Vgl. Schwaber (2007), S. 28

10 Vgl. Schwaber (2007), S. 136 f.

11 Vgl. Jensen (2011), S. 127 f.

12 Vgl. Schwaber (2007), S. 139 f.

13 Vgl. Breitling (2011), S. 50

14 Vgl. C3 Team (1998), S. 25

15 Reißing (2000)

16 Vgl. Reißing (2000)

17 Entnommen aus it-agile (2011)

18 Vgl. Breitling (2011), S. 51

19 Vgl. Reißing (2000) sowie Breitling (2011), S. 52

20 Vgl. Reißing (2000)

21 Vgl. Reißing (2000)

22 Breitling (2011), S. 52

23 Reißing (2000)

24 Vgl. Kniberg (2007), S. 81 ff. sowie Breitling (2011), S. 56

25 Vgl. Roock, Wolf (2010), S. 13

26 ebd.

Details

Seiten
23
Jahr
2011
ISBN (eBook)
9783640983636
ISBN (Buch)
9783640983759
Dateigröße
937 KB
Sprache
Deutsch
Katalognummer
v176956
Institution / Hochschule
FOM Hochschule für Oekonomie & Management gemeinnützige GmbH, Neuss früher Fachhochschule
Note
1,0
Schlagworte
Groovy Grails Scrum Kanban Extreme Programming XP Java Web Softwareentwicklung Agil

Autor

Teilen

Zurück

Titel: Agile Entwicklung von Web-Anwendungen mit Grails