Seminararbeit. Thema: Komponentenbasierte Softwareentwicklung und Hypermedia

Transkript

1 Seminararbeit Thema: Agile Programmierung Komponentenbasierte Softwareentwicklung und Hypermedia An der Fachhochschule Dortmund im Fachbereich Informatik erstellte Seminararbeit im Studiengang Wirtschaftsinformatik von Michael Pols Betreuer: Prof. Dr. Thiesing

2 Inhaltsverzeichnis I Inhaltsverzeichnis Abkürzungsverzeichnis...II Abbildungsverzeichnis... III 1. Einleitung Zielsetzung der Arbeit Vorgehensweise und Gliederung Die Notwendigkeit agiler Entwicklungsmethoden Das Agile Manifest Die Prinzipien des Agilen Manifests Agile Prozesse der Softwareentwicklung Agile Programmierung Agile Methoden Kennzeichen agiler Methoden Überblick agiler Methoden XP genauer betrachtet Abschluss Zusammenfassung Fazit Ausblick...16 Literaturverzeichnis...17

3 Abkürzungsverzeichnis II Abkürzungsverzeichnis AM...Agile Modeling ARTE...Agile Real-Time Embedded Systems ASD...Adaptive Software Development DSDM...Dynamic Systems Development Method FDD...Feature-Driven Development ISD...Internet-Speed Development LD...Lean Development PP...Pragmatic Programming RAD...Rapid Application Development RUP...Rational Unified Process XP...Extreme Programming

4 Abbildungsverzeichnis 1 Abbildungsverzeichnis Abb.1 Das Agile Manifest...3 Abb.2 Prinzipien des Agilen Manifests...4 Abb.3 Prozesse der Softwareentwicklung...6 Abb.4 Rollen in XP...12 Abb.5 Praktiken in XP...13 Abb.6 Prozess von XP...15

5 1 Einleitung 1 1 Einleitung A gile Entwicklung ist derzeit eines der Schlagworte, das innerhalb der Entwicklergemeinde sehr kontrovers diskutiert wird. Basierend auf leichtgewichtigen Prozessen und Methoden, stellt sie den wirtschaftlichen Nutzen eines Auftraggebers in den Fokus der Betrachtung. Denn die zunehmende Bedeutung von E-Commerce und die Globalisierung von Märkten und Unternehmen, haben das Umfeld der Softwareentwicklung dramatisch geändert. Das Aufkommen neuer Technologien, Märkte und Konkurrenten verlangt im hohen Maße die Möglichkeit nach Änderbarkeit und Flexibilität, sowohl auf Seiten des Kunden, als auch auf Seiten des Entwicklers. Dieses Umdenken bedeutet aber keine Abkehr von unserem bisherigem Verständnisses der Softwaretechnik. Auch agile Prozesse müssen gewissen Prinzipien, Methoden und Konzepten genügen. Diese Seminararbeit ist Teil der im Sommersemester 2004 an der Fachhochschule Dortmund, unter der Betreuung von Prof. Dr. Thiesing, stattgefunden Vortragsreihe zum Thema Komponentenbasierte Softwareentwicklung und Hypermedia. 1.1 Zielsetzung der Arbeit Die vorliegende Seminararbeit möchte einen groben Einblick in agile Verfahren liefern. Dem Leser sollen dabei Philosophie und Prinzipien agiler Vorgehensweisen nähergebracht werden. Das Verständnis dieser Denkweisen zu fördern ist Kernelement dieser Arbeit. 1.2 Vorgehensweise und Gliederung Die Ausarbeitung des Themas beschäftig sich zunächst mit der Notwendigkeit neuer Entwicklungsmethoden, den philosophischen Grundlagen agiler Verfahren, agilen Prozessen in der Softwareentwicklung und konkreten Methoden im Überblick. Die Themen werden dabei in genau dieser Reihenfolge behandelt. Abschließend werden noch Einsatzmöglichkeiten und Beschränkungen agiler Methoden aufgezeigt.

6 2 Die Notwendigkeit agiler Entwicklungsmethoden 2 2 Die Notwendigkeit agiler Entwicklungsmethoden Wir müssen unsere Softwareentwicklung wertvoller machen. Aber vor allem müssen wir Spielraum für Geschäftsentscheidungen schaffen. Kent Beck U m die Notwendigkeit agiler Methoden zu verstehen, müssen wir kurz die Geschichte bemühen. Im Jahr 1968 wurde während einer NATO-Konferenz in Garmisch- Partenkirchen zum erstenmal der Begriff Softwaretechnik definiert. Seither verstehen wir unter Softwaretechnik die zielorientierte Bereitstellung und systematische Verwendung von Prinzipien, Methoden, Konzepten, Notationen und Werkzeugen für die arbeitsteilige, ingenieurmäßige Entwicklung und Anwendung von Softwaresystemen 1. Im Laufe der letzten 25 Jahre sind aus diesem Verständnis heraus eine Unmenge von Vorgehensweisen, Verfahren und Methoden entstanden, die Planung bis ins Detail zulassen. Die daraus resultierende Kultur der Softwareentwicklung zielt vor allem darauf ab Anforderungen möglichst widerspruchsfrei und vollständig zu spezifizieren, da man aus Erfahrung weiß das Änderungen oder die Behebung von Fehlern in späten Phasen eines Projektes zu hohen Kosten und Terminüberschreitungen führt. Da die Anforderungen zu Beginn eines Projektes aber meist unklar oder ungenau sind, ist der Ärger vorprogrammiert. Wenn man einige Projektrisiken genauer betrachtet, so muss man feststellen das ein großer Anteil von ihnen in unzureichender Kommunikation mit dem Kunden begründet ist. Wenn dieser nicht in der Lage ist seine Wünsche präzise, im Sinne des zum Einsatz kommenden Vorgehensmodells, zu formulieren, dann fühlen sich Entwickler vielleicht dazu genötigt ihre eigene Interpretation der Kundenwünsche einfließen zu lassen. Ohne Absprache mit dem Kunden wird dann ein Produkt entwickelt welches eine falsche Funktionalität besitzt. Schlimmstenfalls löst die entwickelte Software gar nicht mehr das ursprüngliche Problem. Häufig werden solche Mängel aber erst sehr spät entdeckt, da erst nach Fertigstellung der Software an den Kunden ausgeliefert wird. Ein weiteres Risiko ist die immer schnellere Entwicklung von Technologien und Märkten. Innerhalb eines Entwicklungszeitraumes, der gegebenenfalls Jahre dauern kann, können sich die Geschäftprozesse des Kunden ändern. Seine Wünsche an die von ihm beauftragte Software ändern sich dementsprechend. Also müssen seine Änderungswünsche einem Changemanagement übergeben werden und je nach verwendeter Vorgehensweise wird der gesamte Entwicklungsprozess weitestgehend von vorne begonnen. Das Grundproblem ist anscheinend Kommunikationsschwäche und Mangel an Flexibilität der traditionellen Verfahren. Sie selbst sind der Mittelpunkt des Entwicklungsprozesses und nicht selten wird der Erfolg eines Projektes an der genauen Einhaltung von Vorgehensmodellen gemessen. An dieser Stelle brechen agile Entwicklungsverfahren mit traditionellen Vorgehensmodellen und rücken den Softwareentwicklungsprozess in ein neues Wertesystem. 1 vgl. [Balzert, 1998] Seite 36

7 2 Die Notwendigkeit agiler Entwicklungsmethoden Das agile Manifest Wenn über das Grundsätzliche keine Einigkeit besteht, ist es sinnlos Pläne zu machen Konfuzius B emühungen und Versuche Softwaresysteme schneller und wirtschaftlicher zu entwickeln wurden bereits Anfang der neunziger Jahre unternommen. Erst mit Aufkommen der sogenannten leichtgewichtigen Methoden Ende der neunziger Jahre und Anfang des Jahrtausends kam man diesem Ziel näher. Bis zum Jahr 2001 gab es bereits sechs ausgereifte Verfahren. Um Ausuferungen zu vermeiden und die Verbreitung leichtgewichtiger Prozesse zu gewährleisten, trafen sich im Februar 2001 siebzehn Vertreter der wichtigsten bis dahin bekannten Verfahren in Snowbird, Utah. Das Ergebnis der dort stattgefundenen Diskussionen ist im sogenannten Agilen Manifest [Abb. 1] festgehalten worden. Das Agile Manifest 2 Wir entdecken bessere Wege zur Entwicklung von Software, indem wir selbst Software entwickeln und andere in diesem Bestreben unterstützen. Durch diese Tätigkeiten haben wir gelernt, dass uns Menschen und Zusammenarbeit mehr bedeuten als Prozesse und Werkzeuge;... lauffähige Software mehr bedeutet als umfangreiche Dokumentation;... Zusammenarbeit mit dem Auftraggeber mehr bedeutet als Vertragsverhandlungen... Reaktion auf Änderungen mehr bedeutet, als die starre Einhaltung eines Planes. Obwohl wir auch die Dinge auf der rechten Seite als wichtig erachten, schätzen wir im Zweifelsfall die Dinge auf der linken höher ein. Abb. 1: Das agile Manifest Auffallend und bedeutsam sind mehrere Dinge in diesem Zusammenhang. Zum einen stellen sich die Verfasser als aktive Teilnehmer im Entwicklungsprozess vor, also sind die gemachten Aussagen und Beobachtungen aus der Praxis entstanden und somit nicht nur von akademischen Nutzen. Der zweite wesentliche Punkt ist, dass nunmehr der Kunde, der für ihn geschaffene wirtschaftliche Nutzen (die Software) und Flexibilität im Vordergrund der Entwicklung stehen. Jeder Mensch könnte diesen einfachen Aussagen zustimmen und tatsächlich erhebt sich die Frage warum die Entwicklung einen anderen Weg genommen hat. Zudem sind die getroffenen Aussagen in keiner Weise dogmatisch formuliert und lassen Interpretationsspielräume zu, ohne die Kernaussagen zu unterminieren. Dennoch, hier ist, in Hinblick auf die in der Kapiteleinleitung genannten Projektrisiken, ein radikaler Wertewandel vollzogen worden. 2

8 2 Die Notwendigkeit agiler Entwicklungsmethoden 4 Das Agile Manifest bildet also die Philosophie denen agile Methoden folgen sollen. Philosophien prägen aber nur die Einstellung zu den Dingen der Betrachtung, eine Direktive zur Umsetzung bieten sie nicht. Daher war es notwendig dem Manifest noch einige Prinzipien ergänzend hinzuzufügen, um einen Einsatz in der Praxis zu ermöglichen. 2.2 Die Prinzipien des agilen Manifests Um dem Agilen Manifest auch den Einzug in die Praxis zu ermöglichen, wurden zusätzlich zwölf Prinzipien [Abb. 2] formuliert. Prinzipien sind Grundsätze, die man seinen Handlungen zugrunde legt 3. Wie nachher ersichtlich sein wird, finden sich diese Prinzipien auch mehr oder weniger stark in den konkreten Implementierungen agiler Methoden wieder. Die Prinzipien des agilen Manifests 4 1. Unsere höchste Priorität ist es, den Kunden durch frühzeitige und kontinuierliche Auslieferung nützlicher Software zufrieden zu stellen. 2. Begrüße sich ändernde Anforderungen, selbst spät in der Entwicklung. Agile Prozesse machen Änderungen als Wettbewerbsvorteil des Kunden nutzbar. 3. Liefere lauffähige Software häufig aus, alle paar Wochen bis alle paar Monate, unter Bevorzugung kürzerer Abstände. 4. Geschäftsleute und Entwickler müssen während des ganzen Projekts täglich zusammenarbeiten. 5. Baue Projekte um motivierte Individuen herum auf. Stell ihnen die benötigte Umgebung und Unterstützung zur Verfügung und vertraue auf sie. 6. Die effizienteste und effektivste Methode der Übermittlung von Informationen an und innerhalb eines Entwicklungsteams ist das persönliche Gespräch. 7. Lauffähige Software ist das wichtigste Maß für den Projektfortschritt. 8. Agile Prozesse fördern die dauerhafte Entwicklung. Sponsoren, Entwickler und Nutzer sollten ein konstantes Tempo unbegrenzt einhalten können. 9. Beständiges Achten auf ausgezeichnete technische Fertigkeiten und gutes Entwerfen steigert die Agilität. 10. Schlichtheit ist wesentlich. 11. Die besten Architekturen, Anforderungen und Entwürfe stammen von selbstorganisierenden Teams. 12. In regelmäßigen Abständen denkt das Team darüber nach, wie es effektiver werden kann, und passt sein Verhalten dementsprechend an. Abb. 2: Prinzipien des agilen Manifests 3 siehe [Balzert, 1998] Seite

9 2 Die Notwendigkeit agiler Entwicklungsmethoden 5 Zusammenfassend soll festgehalten werden das Agiles Manifest und die begleitenden Prinzipien die Grundlage aller konkreten Implementierungen wie XP, Scrum usw. bilden. Um den Begriff Agilität nicht noch weiter überzustrapazieren, merke man sich die folgenden Stichpunkte, die das Wesen von Agilität gut transportieren. mitdenken, statt Dienst nach Vorschrift eher Angemessenheit als Extremismus eher ergebnisorientiert als prozessorientiert eher miteinander reden als, gegeneinander schreiben eher Vertrauen als Kontrolle eher best-practices als starre Vorgaben effektiv arbeiten = die richtigen Dinge machen 5 effizient arbeiten = die Dinge richtig machen 6 offen für Änderungen sein Die Kritiker agiler Methoden sehen in diesen offenen Ansatz eine Form der Planlosigkeit und fürchten den Einzug chaotischer Verhältnisse. Dem kann man nur entgegnen, das agile Methoden ebenfalls strikte Vorgaben besitzen. XP, zum Beispiel, setzt sich aus genau definierten Rollen, Verantwortlichkeiten und Praktiken zusammen. Wenn diese nicht korrekt implementiert sind, ist es auch kein XP. Tatsache ist das agile Methoden ebenfalls Ergebnisse und Dokumente liefern, sie unterscheiden sich nur womöglich in Umfang, Anzahl und Formalismus von den Resultaten traditioneller Verfahren. 5 siehe [Starke, 2002] Seite 16 6 siehe [Starke, 2002] Seite 16

10 Agile Prozesse der Softwareentwicklung 6 3 Agile Prozesse der Softwareentwicklung Was man von der Musik lernen kann, ist dies: Der Einsatz muss prompt und gleichmäßig sein, das Weiterspiel in Harmonie und Takt zusammenklingen bis zum Finale. Konfuzius D ie agilen Methoden beinhalten allgemein betrachtet sechs elementare Prozesse oder Prozessebenen [Abb. 3]. Dem Wesen nach sind diese Prozesse unteilbar und interdependent. Das bedeutet vor allen Dingen, dass jeder einzelne Prozess agilen Ansprüchen genügen muss. Wenn also ein Prozess nicht konform zu den Prinzipien des Agilen Manifests implementiert wird, dann kann man auch nicht mehr von agiler Vorgehensweise sprechen. Den Grad der Anpassungsfähigkeit muss also jedes Unternehmen für sich bestimmen. Abb. 3: Prozesse der Softwareentwicklung Im Rahmen dieser Seminararbeit wird nur der Prozess der Programmierung näher erläutert. 3.1 Agile Programmierung Die Tätigkeit des Programmierens ist natürlich integraler Bestandteil des Softwareentwicklungsprozesses. Sie ist die direkte und kreative Umsetzung vorgelagerter Prozesse, wie Architekturentwurf und Systemanalyse, welche wiederum von ihr beeinflusst werden. Leider gibt es den Bergriff Agile Programmierung gar nicht. Die meisten Quellen verstehen unter diesem Begriff die Verwendung von XP, das aber nur eine von vielen agilen Methoden ist. Andere verwechseln Programmierung mit Architektur und Entwurf. In Kapitel 2 wurde der Begriff der Agilität zugegebenermaßen überstrapaziert, aber wenn man sich noch einmal die Begrifflichkeit vor Augen führt, kommt man schnell zu der Erkenntnis, dass es

11 Agile Prozesse der Softwareentwicklung 7 Programmiertechniken und Werkzeuge geben muss, die insbesondere Kommunikation und Änderungsmöglichkeiten unterstützen. An dieser Stelle soll der Begriff Agile Programmierung zwar nicht definiert werden, es soll aber gezeigt werden welche Techniken diesen Ansatz gut unterstützen. Testgetriebene Entwicklung Dieser Ansatz bietet mehrere Vorteile. Vereinfacht ausgedrückt bedeutet testgetriebene Entwicklung nichts anderes, als das grundsätzlich immer ein Test entwickelt wird. Dies geschieht vor der eigentlichen Implementierung. Unterstützung bieten die verschiedenen Testframeworks, wie zum Beispiel das bereits in dieser Veranstaltungsreihe vorgestellte JUnit. Durch das kontinuierliche testen erreicht man ein hohes Niveau an Qualität. Aus psychologischer Sicht wird durch dieses Verfahren auch der Projekteinstieg erleichtert. Da in jedem Fall zuerst der Test entwickelt werden muss, hat man schon etwas zu tun, obwohl man vielleicht noch gar nicht weiß wie man das zu testende Feature genau implementieren möchte. Zudem fördert testgetriebene Entwicklung, durch unmittelbares Feedback, das Vertrauen in die eigenen Fähigkeiten. Natürlich nur, wenn man seine Fehler erkennt und aus ihnen lernen kann. Best-Practices Die persönlichen Erfahrungen und Kenntnisse, gute und schlechte, der Projektbeteiligten fließen in das Projekt ein und kommen somit allen zugute. Zu den Kenntnissen gehören zum Beispiel Wissen um Design-Pattern und deren Implikation was die programmiertechnische Umsetzung betrifft, als auch Wissen um Algorithmen und Datenstrukturen. Code Konventionen Eine einheitliche Formatierung fördert die Lesbarkeit von Quelltext und vermeidet damit schon das Aufkommen einiger syntaktischer und logischer Fehler, was wiederum zu besserer Qualität führt. Refactoring Unter Refactoring versteht man Änderungen am Quellcode, die dessen nichtfunktionale Qualität verbessern, aber keine Veränderungen am Verhalten zeigen 7. Zum Beispiel können Codewiederholungen in Methoden ausgelagert werden, Konstanten gehören meist in Interfaces und rekursive Aufrufe können in iterative umgewandelt werden. Die Liste möglicher Strategien ist lang und füllt ganze Bücher, die in einem Projekt an exponierter Stelle auch bereitgestellt werden sollten. Design-by-Contract Die Überprüfung von Vor- und Nachbedingungen von Methoden und Funktionen innerhalb des Codes. Dieses Vorgehen führt unabhängig von den verwendeten Testverfahren zu besserer Qualität. Für die Programmiersprache Java sind seit dem JDK 1.4 die sogenannten assert-befehle integriert worden, die genau dieses erledigen. Fortlaufende Integration 7 vgl. [Beck, 2000] Seite178

12 Agile Prozesse der Softwareentwicklung 8 Da die meisten Programmieraufgaben meist in kleinen Zwischenstufen unterteilt sind, ist der Programmierer dazu aufgefordert seine demnach schnell erzielten Resultate in des Gesamtsystem zu integrieren. Das sollte nach Möglichkeit zumindest einmal täglich der Fall sein. Damit erreicht man eine schnelle Verbreitung des fertigen Codes an alle Projektbeteiligten und ist damit in der Lage Systemtests durchführen zu können. Dazu gehören Performance- oder Lasttests die das Laufzeitverhalten des Systems überprüfen und mittels Metriken mess- und vergleichbar machen, aber auch Akzeptanztests des Auftraggebers. Ergebnisorientierung Die Programmierer sind bei agilen Methoden immer beschäftigt. Jeder besitzt, meist sehr genaue, Vorgaben was zu tun ist. Also wird keine Zeit für die Implementierung von Tools und Zusätzen verschwendet, da man im Hinterkopf immer den wirtschaftliche Kundennutzen behalten muss. Außerdem bedeutet Ergebnisorientierung, dass man eine Sache erst zu Ende bringt, bevor man eine andere beginnt. Will man einen Fehler beheben, dann wird der Fehler behoben. Möchte man ein Feature implementieren, dann wird es implementiert. Vermeidung von Redundanz Hierunter ist die Vermeidung von Codewiederholungen und unnötige Kommentierung gemeint. Programmfragmente sollten in ihrer Semantik weitestgehend ohne Kommentare auskommen. Das betrifft vor allem die Wahl der Variablen- und Methodennamen. Codewiederholungen sind durch geeignete Refactorings zu beheben. Aufbau von Kompetenz Damit sind zum einen Training und Besuch von Fachseminaren zu verstehen, aber auch die Verbreitung von Wissen innerhalb des Projektteams, sei es im Rahmen von Vorträgen oder durch die Arbeit selbst. Code Konventionen, Refactoring und best-practices des Projektteams werden durch die Praxis doch wohl schneller verbreitet, als durch ein umfassendes Regelwerk (das natürlich trotzdem gelesen werden sollte, so es existiert). Die in XP geforderte Programmierung in Paaren ist hinsichtlich des Aufbaus von teamweiten Projektwissens eine der effektivsten Ausprägungen für den Aufbau von Kompetenz. Code Reviews Der entwickelte Code wird in regelmäßigen Abständen von allen Programmierern, auf Qualität, Konventionen und Änderungsmöglichkeiten hin, betrachtet, analysiert und bewertet. Dazu sind nicht unbedingt Meetings notwendig, da der Code durch die fortlaufende Integration sowieso allen Programmieren zur Verfügung steht. Wichtig ist nur das die Programmierer somit ständig die Qualität ihrer Tätigkeit im Auge behalten und gegebenenfalls Verbesserungen anregen können. Offen-Geschlossen-Prinzip Offen für Erweiterungen und geschlossen für Änderungen. Dieses Prinzip heißt nichts anderes als das fertiggestellter Code nicht mehr angetastet werden sollte. Unter fertiggestellten Code versteht man Code der bereits integriert wurde und auch schon den Prozess des Refactorings durchlaufen hat. Da die gesamte Architektur hinsichtlich kontinuierlicher Änderungen entworfen sein sollte, werden Änderungen als Erweiterungen implementiert. Get it right the last time

13 Agile Prozesse der Softwareentwicklung 9 Es ist nicht mehr wichtig alles von Anfang an perfekt zu machen. Tatsächlich muss aber das Endprodukt der programmiertechnischen Arbeit so funktionieren wie es spezifiziert wurde. 4 Agile Methoden Wer fest und ausdauernd, schlicht und bescheiden ist, kommt dem Guten nahe. Konfuzius 4.1 Kennzeichen agiler Methoden $Rgile Methoden sind im Wesen geprägt von vier Eigenschaften. Allen ist gemein das sie kooperativ, adaptiv, inkrementell-iterativ und schlicht sind. Damit bilden sie die direkte Umsetzung der in Kapitel 2 betrachteten Philosophie und Prinzipien. 4.2 Überblick agiler Methoden Im Laufe der letzten Jahre haben sich ein Dutzend agiler Methoden entwickelt. Zum höchsten Grad an Bekanntheit hat es XP gebracht. XP gilt innerhalb der Entwicklergemeinde als leichtgewichtigster und agilster Vertreter dieser Methoden. Die fast spielerische Herangehensweise an den Entwicklungsprozess, lässt jedoch Befürworter traditioneller Vorgehensmodelle die Nase rümpfen. Nichtsdestotrotz sind nicht wenige Softwareprojekte erfolgreich mit XP durchgeführt worden. Im folgenden wird ein kurzer Überblick einzelner Vertreter der agilen Methodenfamilie gegeben. AM AM ist eine Methode die ihren Schwerpunkt im Entwurf und der Modellierung von Architekturen hat. Da bei dieser Methode das Modellieren sogenannter Artefakte im Vordergrund steht, muss AM auch durch andere leichtgewichtige Prozesse, wie XP oder RUP, unterstützt werden. ASD ASD ist eher als Entwicklungsphilosophie, denn als konkrete Methode zu betrachten. Historisch basiert sie auf der bereits 1994 entwickelten RAD-Methode. Kernaussage ist, Wandel als Grundlage von Handlungen zu verinnerlichen. Spekulieren, Kollaborieren und Lernen bilden den Entwicklungszyklus von ASD. ASD beansprucht für sich auch die Möglichkeit der verteilten Entwicklung. ARTE ARTE ist ein technischer Ansatz für die Entwicklung eingebetteter Echtzeitsysteme. Diese Methode bietet erste Ansätze für die gemeinsame Entwicklung von Hard- und Softwarekomponenten und ist besonders gekennzeichnet durch die Verwendung vieler Diagrammformen, die das System aus verschiedenen Perspektiven des Entwicklungsprozesses betrachten. Crystal Methodology Den Namen bezieht die Crystal-Methode aus der Tatsache, dass die Kritikalität, also der mögliche Schaden den das System anrichten kann, anhand einer Farbskala bestimmt wird, die man auch für Kristalle verwendet. Nicht kritische System bezeichnet man als Crystal Clear. Kritische Systeme

14 Agile Methoden 10 sind als Crystal Red klassifiziert. Neben der Kritikalität werden auch Kosten und Teamgröße über diese Skala bestimmt. DSDM Dieses Verfahren ist der einzige kommerzielle Vertreter agiler Methoden. Es besitzt eine ISO Zertifikation. DSDM setzt Grenzen für Zeit und Ressourcen fest, um dann die Funktionalität an diese Grenzen anzupassen. Diese Methode schränkt agile Prinzipien, wie Selbstorganisation stark ein. FDD FDD ist die am stärksten prozessorientierte Methode. Sie besteht auf die genaue Einhaltung der vorgeschriebenen Praktiken. Lediglich in der Ausführung besteht Flexibilität, die jedoch ebenfalls durch genau definierte Zeitfenster eingeschränkt ist. Interessant an FDD zu bemerken ist, dass diese Methode von sich behauptet für kritische Systeme geeignet zu sein und weitestgehend ohne direkte Kooperation mit dem Auftraggeber auskommen soll. Belege für diese Behauptungen sind nicht zu finden. ISD ISD kennzeichnet sich vor allem durch die Geschwindigkeit der Verbreitung. Von diesem Ansatz wird behauptet, das er die Vorgehensweise wie Microsoft und Netscape Software entwickeln gut wiederspiegelt. LD LD ist eine Methode die sich stark an den Prinzipien des Automobilbaus in Japan orientiert. Dieser Fabrikansatz bietet zudem Ansätze zur Analyse von Wertschöpfungsketten. PP PP ist eher eine Ansammlung von 70 best-practices der Programmierung. Diese Methode erfordert ähnlich wie AM die Unterstützung anderer leichtgewichtiger Prozesse. RUP RUP ist eigentlich kein leichtgewichtiger Prozess im eigentlichen Sinne, jedoch existieren Anpassungsmöglichkeiten um RUP auch als agile Methode zu benutzen. Dieser stark werkzeugorientierte Ansatz macht starken Gebrauch von der Modellierungssprache UML. Scrum Scrum als Methode stellt die Überwachung und Regelung von Prozessen und Projektvariablen (Zeit, Qualität, Anforderungen,...) in den Vordergrund. Damit ist Scrum eher managementorientiert. Neue Anforderungen werden in einem sogenannten Backlog zwischengespeichert. Die Umsetzung der Anforderungen wird über Prioritäten gesteuert.

15 Agile Methoden 11 XP Die prominenteste Methode in diesem Zusammenhang stellt wahrscheinlich auch die radikalste Umsetzung agiler Prinzipien dar. Grundsätzlich steht der entwickelte Code im Fokus der Betrachtung. Der Code wird auch als Kommunikationsmittel eingesetzt. Sämtliche in Kapitel 3 gemachten Aussagen über Programmiertechniken kommen hier zum Einsatz. Zuhören, Programmieren, Testen und Lernen bilden die Haupttätigkeiten von XP. Die Programmiertechniken die XP einsetzt werden auch für andere Methoden empfohlen. In dem nächsten Unterkapitel wird, hinsichtlich der Umsetzung agiler Prinzipien, noch einmal genauer auf eine ausgewählte Methode eingegangen, nämlich XP.

16 Agile Methoden XP genauer betrachtet Jeder Softwareentwicklungsprozess muss notwendigerweise bestimmte Verantwortungsbereiche und Rollen der Projektbeteiligten festlegen. XP bildet hier keine Ausnahme und ist dabei geradezu restriktiv. Grundsätzlich können für alle Entwicklungsprozesse fünf Verantwortungsbereiche identifiziert werden [Abb. 4]. Die Position der einzelnen Rollen 8 gibt dabei die relative Nähe zu den anderen Verantwortungsbereichen wieder. Der Bereich des Entwicklungsteams ist in das Zentrum gerückt, da hier die eigentliche Schaffung von wirtschaftlichen Mehrwert für den Auftraggeber entsteht. Damit korrespondiert die Betrachtung schon mit den Prinzipien des Agilen Manifests: Baue Projekte um motivierte Individuen herum auf. Stell ihnen die benötigte Umgebung und Unterstützung zur Verfügung und vertraue auf sie. Die besten Architekturen, Anforderungen und Entwürfe stammen von selbstorganisierenden Teams. Abb. 4: Rollen in XP Nimmt man nun noch die verschiedenen Rollen genauer unter die Lupe, so fällt auf, dass der Kunde zum Beispiel nicht zwangsläufig kompletter Bestandteil des Entwicklungsteams sein muss, jedoch im direkten Umfeld des Entwicklungsteams zu suchen ist. Schließlich ist er ja auch der 8 Big Boss : Er ist der entgültige Entscheidungsträger. Coach : Er betreut das Team und achtet darauf das XP-Techniken eingehalten werden. Tracker (optional) : Er überwacht die Wirtschaftlichkeit und Terminschätzungen des Teams. Expert (optional) : Stellt Fachkompetenz zur Verfügung die nicht vom Team abgedeckt wird. Programmer : Entwickelt Unittests und implementiert Kundenanforderungen. Tester : Entwickelt mit dem Kunden Akzeptanztests und führt sie aus. Customer : Er gibt Anforderungen in Form von Stories und entwickelt Akzeptanztests.

17 Agile Methoden 13 einzige der dem Team genau sagen kann was er benötigt. Damit ist ein weiteres Prinzip des Manifests integriert: Geschäftsleute und Entwickler müssen während des ganzen Projekts täglich zusammenarbeiten. In XP ist der Kunde für die Entwicklung von Akzeptanztests verantwortlich und wird von dem Entwicklungsteam in diesem Bestreben in der Rolle des Testers unterstützt. Damit findet sich auch ein Punkt der in Kapitel 3 als Bestandteil agiler Programmierung vorgestellt wurde in dieser Grafik ebenfalls wieder: Testgetriebene Entwicklung Die nächste Grafik [Abb. 5] die betrachtet werden soll, zeigt die für XP notwendigen Praktiken. Wesentliche Prinzipien des Agilen Manifests und agile Programmiertechniken die hier ihre Umsetzung finden sind bereits aus der Namensgebung herauszulesen. Abb. 5: Praktiken in XP Die Praktiken plannig game, simple design und metaphor zielen im Grunde nur auf folgenden Punkt der agilen Prinzipien ab: Schlichtheit ist wesentlich.

18 Agile Methoden 14 Kurze Releasezyklen und kontinuierliche Integration decken als notwendige Praktiken gleich mehrere Prinzipien ab: Unsere höchste Priorität ist es, den Kunden durch frühzeitige und kontinuierliche Auslieferung nützlicher Software zufrieden zu stellen. Liefere lauffähige Software häufig aus, alle paar Wochen bis alle paar Monate, unter Bevorzugung kürzerer Abstände. Lauffähige Software ist das wichtigste Maß für den Projektfortschritt. Die Praktiken aus dem Implementierungsbereich spiegeln die in Kapitel 3 gemachten Annahmen über agile Programmiertechniken wieder und implementieren diese in idealer Weise. Das Programmieren in Paaren verinnerlicht dabei sogar ein bis hier noch nicht erwähntes aber dennoch wichtiges Prinzip des Manifests wieder und wird deshalb auch an erster Stelle erwähnt: Die effizienteste und effektivste Methode der Übermittlung von Informationen an und innerhalb eines Entwicklungsteams ist das persönliche Gespräch. Code Konventionen Testgetriebene Entwicklung Refactoring Fortlaufende Integration Ergebnisorientierung Aufbau von Kompetenz Die vierzig Stundenwoche und die just rules Praktik dienen in diesem Zusammenhang der langfristigen Motivation des Teams. Die letzte Grafik die betrachtet werden soll um XP hinsichtlich der Umsetzung agiler Prinzipien zu untersuchen, zeigt den eigentlichen Entwicklungsprozess von XP [Abb. 6]. Dazu muss die folgende vereinfachte Zusammenfassung des Prozesses genügen um ein allgemeines Verständnis von XP zu transportieren. Wie in der Rollenverteilung weiter oben kurz beschrieben schreibt der Kunde seine Anforderungen im Rahmen eines Planungsspiels als sogenannte Stories nieder. Dabei formuliert er seine Wünsche in Form von Metaphern. Das Team beurteilt den zeitlichen Aufwand für die einzelnen Stories. Sind die Anforderungen einer Story dabei zu umfangreich um in einem Iterationszyklus von ca. 4 Wochen implementiert zu werden, dann muss diese Story weiter unterteilt werden. Damit werden auch erreichbare Ziele gesteckt. So gesehen kommt es in XP- Projekten nie zu Verzögerungen. Sind die Anforderungen einer Iteration vollständig, macht sich das Team an die Arbeit. Dabei kommen zu jedem Zeitpunkt die oben genannten Praktiken zum Einsatz.

19 Agile Methoden 15 Abbildung 6: Prozess von XP Allein die grafische Darstellung zeigt in einfacher Art und Weise den iterativen und inkrementellen Charakter agiler Methoden. Inkrementell bedeutet das jede Iteration auch zu Ergebnissen führt, nämlich den Releases. Iterativ heißt, das der gesamte Prozess mehrfach durchlaufen wird bis irgendwann ein Final Release als Projektergebnis geliefert werden kann. Dabei liefert jede Iteration ein Feedback des Kunden, welches wieder in die nächste Iteration einfließt. Der iterative Prozess von XP liefert damit auch den Zugang zu den letzten Prinzipien des Agilen Manifests: Agile Prozesse fördern die dauerhafte Entwicklung. Sponsoren, Entwickler und Nutzer sollten ein konstantes Tempo unbegrenzt einhalten können. Beständiges Achten auf ausgezeichnete technische Fertigkeiten und gutes Entwerfen steigert die Agilität. In regelmäßigen Abständen denkt das Team darüber nach, wie es effektiver werden kann, und passt sein Verhalten dementsprechend an. Damit implementiert XP sämtliche Prinzipien die wir agilen Verfahren zu Grunde legen. Auch sämtliche Programmiertechniken die agile Ansätze fördern finden Einzug in XP. Dadurch wird XP sogar noch ein weiteres Stück extremer.

20 Abschluss 16 5 Abschluss Vollkommen ist die Tugend der goldenen Mitte. Schon lange ist sie selten geworden. Konfuzius 5.1 Zusammenfassung In dieser Ausarbeitung wurden die wesentlichen Kernelemente agiler Vorgehensweisen aufgezeigt. Der Leser sollte an dieser Stelle allgemeine Kenntnisse über agile Methoden besitzen, das ihm ermöglichen soll Vor- und Nachteile dieser Denkweise zu beurteilen. 5.2 Fazit Agile Methoden erlauben einen flexiblen Ansatz in der Softwareentwicklung. Kommunikationsbereitschaft und wirtschaftlicher Mehrwert in Form von lauffähiger Software stehen im Brennpunkt der Betrachtung. Diese Selbstverständlichkeit ist in traditionellen Verfahren oft schwer umsetzbar. Die genauen Ausprägungen einzelner Methoden sind dennoch sehr restriktiv. Damit wird Planlosigkeit verhindert. Kommerzielle Methoden, wie DSDM, bieten dazu Ansätze für stark von Normen geprägte Entwicklungen und die Durchführung größerer Projekte. Allgemein kann man aber sagen, dass agile Methoden eher in kleineren Projekten zum Einsatz kommen. Unterstützung für verteilte Entwicklung ist nur schwer zu implementieren. Die Entwicklung von wiederverwendbaren Artefakten und Komponenten ist natürlich möglich, allerdings nur, wenn der Auftraggeber sich davon einen wirtschaftlichen Nutzen verspricht. Ab einem gewissen Projektumfang oder hochgradiger Komplexität ist agiles Vorgehen nicht mehr wirklich durchführbar, da der Koordinierungsaufwand für Kommunikation und Fachkompetenz größer sein wird als der Nutzen, den man sich durch Flexibilität verspricht. Wir wollen festhalten, dass agile Verfahren also eher in kleineren Projekten zum Einsatz kommen, in denen zeitnah auf sich ändernde Anforderungen reagiert werden muss. Idealerweise trifft dies besonders auf die im Rahmen dieser Veranstaltung vorgestellten Webservices zu. 5.3 Ausblick Die Evolution agiler Verfahren hat gerade erst begonnen. Für einen breiten Einsatz fehlen in den Unternehmen aber meist die Organisationsformen, die Agilität zu ihrer Maxime erheben. Daher wird es noch einige Zeit benötigen bis Unternehmen die Vorteile agiler Verfahren verinnerlicht und begriffen haben. Da diese leichtgewichtigen Prozesse sehr stark marktorientiert sind, wird es in Zukunft interessant sein zu beobachten, welche Unternehmen sich in ihrer Strategie langfristig am Markt positionieren können. Mit ersten Ansätzen für die Entwicklung von sicherheitskritischen Systemen, scheint auch hier eine Bastion traditioneller Vorgehensmodelle zu fallen. Die Chancen für die Zukunft stehen also gut für agile Herangehensweisen.