Techniken der Agilen Software-Entwicklung in Web-Projekten

Größe: px
Ab Seite anzeigen:

Download "Techniken der Agilen Software-Entwicklung in Web-Projekten"

Transkript

1 Diplomarbeit Techniken der Agilen Software-Entwicklung in Web-Projekten Bert Schulzki Gutachter: Prof. Dr. Klaus Bothe Berlin, 26. November 2003 Humboldt Universität zu Berlin Institut für Informatik Lehr- und Forschungsgebiet Softwaretechnik

2

3 III Erklärung Erklärung Hiermit versichere ich, dass ich die vorliegende Diplomarbeit selbstständig und nur unter Zuhilfenahme der angegebenen Quellen erstellt habe. Ich bin damit einverstanden, dass ein Exemplar dieser Arbeit in der Bibliothek des Instituts für Informatik der Humboldt-Universität zu Berlin ausgestellt wird. Berlin, 26. November 2003 Bert Schulzki

4 Danksagung IV Für ihre Unterstützung möchte ich mich bei folgenden Personen bedanken: Tom Kedor, Technischer Direktor der Aperto AG, der mir die einmalige Chance eröffnete, in kommerziellen Projekten neue Prozesse zu testen und damit die organisatorische Basis für diese Arbeit schuf, sowie Frank Westphal, dem ich nicht nur viele gute Anmerkungen verdanke, sondern der mich auf der XP2003 in Genua auch mit vielen der Autoren bekannt machte, die ich in dieser Arbeit so häufig zitiere.

5 V Inhaltsverzeichnis Inhaltsverzeichnis Vorwort 1. Einführung Probleme traditioneller Prozesse Die Entstehung der Agilen Software-Entwicklung Überblick über wichtige Agile Prozesse Prozesse in Web-Projekten Besonderheiten von Web-Projekten 8 2. Extreme Programming Geschichte Rollen Techniken Prozess Kosten von Änderungen Referenzprojekte XP und Zertifizierung XP und RUP Agile Projekte bei der Aperto AG Über die Aperto AG Die Projekte ZIF und Allbecon Projektvorbereitung Projektverlauf Eingesetzte Agile Techniken Agile Techniken des Projektmanagements Kleine Teams Standup meetings Jam sessions Planning game Colocation Short releases Kunde vor Ort Nachhaltiges Tempo Information radiator 44 VII

6 Inhaltsverzeichnis VI 5. Agile Techniken des Designs CRC-Karten Refactoring Simple design Metapher Testgetriebenes Design Agile Techniken der Implementierung Pair programming Collective ownership Continuous integration Unit tests Agile Techniken der Qualitätssicherung Programmierstandards Integrationstests Akzeptanztests Spike solutions Retrospektiven Ergebnis Anwendung Beherrschung Nützlichkeit Etablierung Fazit und Ausblick Anhang Rohwerttabellen Abbildungen Quellen Abkürzungen 93

7 VII Vorwort Today the era of fat process is over. As Jim Highsmith has said Thin is in. To optimize for speed and responsiveness, we need to put process on a diet. We need to shed paperwork and bureaucratic burden, eliminate endless code inspections, and invest in our people so they can steer themselves sensibly through the chaotic maze that is a modern-day IT project. This is the genesis of the Agile approaches to software development. Tom DeMarco, 2002 Vorwort Diese Arbeit beschreibt die Umsetzung konkreter Web-Projekte unter dem Einsatz Agiler Techniken. Sie untersucht die Annahme, ob Agile Prozesse für den Einsatz in Web-Projekten mit ihren spezifischen Besonderheiten geeignet sind und leistet damit einen Beitrag für die Diskussion darüber, in welchen Domänen Agile Prozesse besser oder schlechter geeignet sind als traditionelle, schwergewichtige Prozesse. Für diese Arbeit ermöglichte die Aperto AG die Durchführung zweier Pilot-Projekte für die Realisierung der Internet-Auftritte vom ZIF, einer Initiative des Auswärtigen Amtes und der Allbecon AG, eines internationalen Personal-Dienstleisters. Für beide Projekte mit dem Einsatz von bis zu acht Mitarbeitern in einem Zeitraum von drei Monaten wurde Extreme Programming als Prozess ausgewählt, da es der derzeit am besten dokumentierte Agile Prozess ist. Dazu habe ich als Entwickler und Coach die Einführung der XP-Techniken begleitet, um anschließend eine empirische Befragung über den Einsatz und die Akzeptanz Agiler Techniken unter den Entwicklern durchzuführen. Die Arbeit führt im ersten Kapitel in die Entwicklung der Agilen Prozesse und die Besonderheiten von Web-Projekten ein. Anschließend wird im Kapitel zwei der hauptsächlich verwendete Agile Prozess Extreme Programming genauer vorgestellt, bevor im dritten Kapitel die konkrete Durchführung des Projektes bei der Aperto AG beschrieben wird. Der Schwerpunkt dieser Arbeit folgt in den Kapiteln vier bis acht, in denen die Ergebnisse der empirischen Befragung der Entwickler dargestellt werden. Dabei habe ich versucht, folgende Items zu jeder eingesetzten Technik zu erfassen: Anwendung: Hat der Mitarbeiter die Technik im Projekt angewendet? Nützlichkeit: Empfand der Mitarbeiter die Technik als nützlich für das Projekt? Beherrschung: Ist der Mitarbeiter der Ansicht, die Technik zu beherrschen? Etablierung: Will der Mitarbeiter die Technik zukünftig wieder einsetzen? Jeder Abschnitt über eine Technik besteht aus zwei Teilen: einem literaturwissenschaftlichen Überblick (Grundlagen) und einer Diskussion der Ergebnisse aus dem Einsatz der Technik im Projekt (Erfahrungen).

8 Vorwort VIII Bei der Bezeichnung der eingesetzten Techniken werden sowohl deutsche als auch englische Begriffe verwendet. Für einige der englischen Begriffe gibt es schlichtweg keine geeignete Übersetzung (z.b. Jam sessions), für andere ist die deutsche Übersetzung künstlich und unnatürlich (Refaktorisierung anstatt Refactoring). Ich habe darum versucht, die Begriffe in der Sprache zu bezeichnen, wie sie in der Praxis (auf Konferenzen, Schulungen und Projekten) im deutschen Sprachraum auch tatsächlich benutzt werden. Im achten Kapitel werden die Ergebnisse der einzelnen Techniken zueinander in Beziehung gesetzt, bevor ich im neunten Kapitel ein Fazit ziehe. Obwohl nicht alle Techniken positiv bewertet wurden, konnte die Annahme, dass Agile Prozesse für die Durchführung von Web-Projekten geeignet sind, bestätigt werden. Die Arbeit konzentriert sich auf die Durchführung der Projekte und die anschließende Befragung der Entwickler zu den einzelnen Techniken. Was diese Arbeit nicht leisten kann, ist ein Urteil über die Leistungsfähigkeit des überwiegend eingesetzten Prozesses Extreme Programming insgesamt oder einen Vergleich zu anderen Prozessen über die Tatsache hinaus, dass die Projekte erfolgreich abgeschlossen wurden. Die Angebote des ZIF und der Allbecon AG sind heute online und bedienen täglich Hunderte Besucher und Bewerber. Die Erfahrungen aus den durchgeführten Projekten zeigen die Nützlichkeit verschiedener Techniken der Agilen Software-Entwicklung und ihre Auswirkungen auf die Arbeitsweise bei der Aperto AG. Der technische Direktor Tom Kedor schreibt dazu: Die in den letzten drei Monaten von Herrn Schulzki eingeführten Techniken aus dem Umfeld des Extreme Programming wurden von den Entwicklern durchweg positiv begrüßt. Insbesondere die konsequente Anwendung eines testgetriebenen Entwicklungs-Ansatzes und die gemeinsame Problemlösung in Form des Pair Programming haben in den beiden Pilot-Projekten zu einer spürbaren Verbesserung der Software-Qualität zum Wohle unserer Kunden geführt. Diese positiven Erfahrungen bildeten die Grundlage für die Entscheidung, einen Großteil der neu eingeführten Techniken als Entwicklungs-Standard in der Technischen Abteilung der Aperto AG zu definieren.

9 1 Probleme traditioneller Prozesse 1. Einführung 1.1 Probleme traditioneller Prozesse Ende der sechziger Jahre manifestierten sich die immer komplexeren Probleme der Software-Entwicklung in der sogenannten Software-Krise. Zu deren Bewältigung wurde 1968 auf einer historischen NATO-Konferenz in Garmisch-Partenkirchen beschlossen, die Entwicklung von Software als eigenständige Ingenieursdisziplin zu etablieren. 1 Zu den wichtigsten Fortschritten auf dem Weg der Software-Entwicklung hin zu einer Ingenieursdisziplin zählen, neben der Entwicklung neuer Methoden, die Einführung von Entwicklungsprozessen, die unabhängig von den eigentlichen Produkten (der Software) betrachtet und verbessert werden können. Ein sogenanntes Prozessmodell legt das methodische Vorgehen für die Entwicklung eines Softwareproduktes fest 2. Neben dem eher akademischen Wasserfall-Modell finden in der Industrie heute überwiegend das V-Modell 3, das Spiralmodell 4 oder der Rational Unified Process 5 Verwendung. Alle vier Jahre veröffentlicht die Standish Group umfangreiche Untersuchungen über Projekte in der IT-Branche. Im sogenannten CHAOS-Report liegt mit den Daten von 365 Unternehmen und 8000 Software-Projekten aus den USA eine der derzeit umfangreichsten Analysen zur Situation der Software-Entwicklung vor. 6 Abb. 1: Erfolg von Software-Projekten in den USA 1 vgl. [URL_NATO] 2 vgl. [BALZERT98] Seite 29 3 vgl. [DROESCHEL99] 4 vgl. [BOEHM88] 5 vgl. [JACOBSON99] oder [URL_RUP] 6 vgl. [URL_STANDISH]

10 1. Einführung 2 Der Report belegt unter anderem, dass sich die Anzahl der erfolgreich abgeschlossenen Software-Projekte (trotz moderner und umfassender Vorgehensmodelle) in den letzten Jahren insgesamt nicht wesentlich erhöht hat. Als gefährdet werden dabei alle diejenigen Projekte gewertet, die Zeit und/oder Budget deutlich überschritten haben. Trotz der Stagnation bei der Anzahl der Projekterfolge insgesamt, verdoppelte sich die Erfolgsrate in mittleren und großen Unternehmen. Die modernen Prozesse und deren umfangreiches Projektmanagement sind hier offenbar sehr wirkungsvoll. Für kleinere Unternehmen blieb dieser Wert dagegen nahezu unverändert. Dafür stiegen die Projektkosten sogar um 50 %. Der insgesamt nahezu konstante Verlauf der Kurve lässt sich mit der zunehmenden Anzahl kleinerer Projekte erklären. Mittlerweile werden bereits etwa 80 von 100 Software-Projekten mit weniger als 50 Mitarbeitern durchgeführt, bei steigender Tendenz. 1 Wenn die modernen Prozesse nicht zur Verbesserung der Erfolge in kleinen Unternehmen (und kleinen Software-Projekten) beigetragen haben, stellt sich die Frage, ob diese Prozesse, die in großen Unternehmen beachtlich zur Reduzierung von Kosten beigetragen haben, überhaupt für kleine Projekte und damit für die überwiegende Mehrheit aller Software-Projekte, geeignet sind. Die ISO und CMM zertifizierten Unternehmen bis vor wenigen Jahren danach, ob sie diese Prozesse einhielten. 2 Doch die Liste derjenigen Unternehmen, die Anfang der neunziger Jahre die höchsten Level des CMM erreichten, liest sich heute wie ein who s who of downsizing 3. Über die Konzentration auf die Prozesse wurden die Ergebnisse vergessen. Nicht selten analysieren, spezifizieren und designen hunderte Mitarbeiter jahrelang (ISOund CMM-konform), ohne eine einzige Zeile Code zu schreiben, um das Projekt schließlich zu verwerfen. 4 Abstrahiert man den Prozessbegriff von der Informatik zu allgemeinen Naturwissenschaften, so gibt es zwei Hauptansätze für die Kontrolle von Prozessen: 5 Das definierte Prozesssteuerungsmodell setzt voraus, dass jedes Element genau verstanden ist. Ein gleicher Satz von Eingaben generiert stets die gleichen Ausgaben. Das empirische Prozesssteuerungsmodell geht vom Unvorhersehbaren aus. Es erfordert ständige (Echtzeit-)Kontrolle aller Parameter und (falls erforderlich) deren Anpassung. Die traditionellen Ansätze der Informatik gehen von definierten Prozesssteuerungsmodellen aus. Aus der praktischen Erfahrung heraus stellen sich jedoch kritische Fragen, beispielsweise, ob diese Ansätze nicht die kreativen Aspekte der Software-Entwicklung vernachlässigen. Würden zwei Designer dasselbe Problem wirklich gleich modellieren? Arbeitet ein Entwickler jede Woche gleich effektiv? Oder erfordert Entwicklung von Software den Einsatz von empirischen Prozesssteuerungsmodellen? 1 vgl. [HIGHSMITH02] Seite Erst mit der ISO 9001:2000 erlangte die Ergebnisqualität wieder eine größere Bedeutung. 3 Tom DeMarco in [HIGHSMITH02] Seite XV 4 vgl. z.b. [COLDEWEY01] Seite 3, [SCHWABER01] Seite 24 oder [HIGHSMITH02] Seite vgl. [SCHWABER01] Seite 25

11 3 Die Entstehung der Agilen Software-Entwicklung 1.2 Die Entstehung der Agilen Software-Entwicklung Geschichte Traditionelle Prozesse werden wegen ihres intensiven Einsatzes von Dokumenten und Artefakten auch als schwergewichtige Prozesse bezeichnet. Der Aufwand für deren Erstellung wurde durch die Annahme gerechtfertigt, dass die Korrektur eines Fehlers exponentiell teurer würde, je später man ihn entdeckte. Um so größer der Aufwand in den frühen Phasen des Projektes, um so weniger Fehler müssten später im Projekt korrigiert werden. Ende der neunziger Jahre wurde eine Anzahl von Berichten publiziert, in denen erfolgreiche Projekte die Anwendung etablierter Prozesse bewusst vermieden und auf die Erstellung zahlreicher Dokumente verzichteten. Die Projektmanager und Berater, die diese Projekte durchführten, hatten teilweise noch wenige Jahre zuvor selbst Bücher oder Software über schwergewichtige Prozesse veröffentlicht. 1 Sie verzichteten bei diesen Projekten durchaus nicht auf Prozesse, nur waren ihre Ansätze teilweise radikal anders als die etablierten Standards. Die Entscheidung, anstelle des etablierten Prozesses solche unbekannten Ansätze einzusetzen, erforderte ein gewisses Maß an Risikobereitschaft und Mut. Viele der betroffenen Unternehmen brachten diesen oft erst in einem letzten, verzweifelten Versuch auf, als die kritischen Projekte bereits gescheitert waren. 2 Vermehrt konnten derartige Projekte dann mit einem Bruchteil der ursprünglichen Mitarbeiter und des ursprünglichen Budgets bereits innerhalb weniger Monate erfolgreich erste Ergebnisse liefern. Aus diesen Erfahrungen heraus entstanden erste Bücher über die tatsächlich verwendeten Prozesse und Methoden. Bislang war es üblich, dass Prozesse durch Wissenschaftler theoretisch erdacht wurden, um anschließend in der Praxis angewendet zu werden. Erstmalig in der Geschichte der Software-Technik wurden Prozesse beschrieben, nachdem sie (vielfach und erfolgreich) in der Praxis eingesetzt worden waren. Zunächst als leichte Prozesse bezeichnet, wurde schnell deutlich, dass ihre Gemeinsamkeit nicht in dem reduzierten Einsatz von Dokumentation bestand, sondern vielmehr in den Werten. Und so trafen sich im Februar 2001 in Utah 17 Vertreter dieser Werte zu einer historischen Konferenz. Nach tagelanger Diskussion einigten sie sich auf die Formulierung eines Manifestes 3, das den kleinsten Nenner ihrer Gemeinsamkeiten zusammenfasst. Sie gründeten eine Interessengemeinschaft 4 zur Verbreitung dieser gemeinsamen Werte, der sich bis heute Hunderte 5 Entwickler, Akademiker und Manager angeschlossen haben. 1 So arbeitete Ken Schwaber an Prozess-Management-Software (vgl. [SCHWABER01] Seite 17f) oder Jim Highsmith unterrichtete diese Thematik (vgl. [HIGHSMITH02] Seite 220) 2 z.b. Chrysler C3 (vgl. [ANDERSON98] Seite 24ff), Singapoore (vgl. [HIGHSMITH02] Seite 270ff) oder Benefits company (vgl. [SCHWABER01] Seite 133ff) 3 vgl. [URL_MANIFESTO] 4 vgl. [URL_ALLIANCE], der unter anderem auch Grady Booch angehört 5 Stand vom : 1381 Unterzeichner

12 1. Einführung Das Agile Manifest Im Text des Manifestes werden im wesentlichen Werte genannt, die in Umfang und Bedeutung die Unterschiede zu traditionellen Prozessen verdeutlichen. Die Darstellung erfolgt dabei in der Form Wert a ist wichtiger als Wert b. Damit soll vermittelt werden, dass Werte auf der rechten Seite durchaus nicht zu vernachlässigen sind, jedoch die Werte auf der linken Seite von den Unterzeichnern des Agilen Manifestes als wichtiger bewertet werden. Die vier Werte lauten in der Zusammenfassung: Einzelpersonen und Interaktion sind wichtiger als Prozesse und Werkzeuge. Es ist denkbar, Projekte erfolgreich abzuschließen, ohne jegliche Prozesse oder Werkzeuge einzusetzen. Es ist jedoch unmöglich, ein Projekt ohne Einzelpersonen und deren Interaktion zu realisieren. Zudem macht auch der beste Prozess aus einem Team von Anfängern keine leistungsfähigen Entwickler, wohingegen erfahrene Teams oft von sich aus zur Selbstorganisation neigen. Prozesse und Werkzeuge unterstützen dabei. Funktionierende Software ist wichtiger als umfangreiche Dokumentation. Ein Projekt kann durchaus ohne jegliche Dokumentation erfolgreich sein, wenn das System nur läuft. Aber ohne ein solches laufendes System hilft keine Dokumentation der Welt es einzusetzen. Das bedeutet nicht, dass Entwickler in Agilen Prozessen vollständig auf Dokumentation verzichten sollen, sondern dass jegliche unnötige Dokumentation vermieden und wo immer es geht durch Kommunikation ersetzt wird. Dokumentation soll nicht zum Selbstzweck erfolgen, sondern nur, wenn es nötig ist und keine Alternative besteht. Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen. Die heute üblichen Verträge zwischen Kunden und Auftragnehmern lassen mitunter den Verdacht aufkommen, als bereiteten sich beide Seiten auf eine unvermeidliche Gerichtsverhandlung vor. Ihr Fokus liegt oft in einer Absicherung im Falle des Scheiterns des Projektes statt in der erfolgreichen Zusammenarbeit an einem gemeinsamen Ziel. Alle Agilen Prozesse zeichnen sich daher durch eine enge Einbeziehung des Kunden aus, der so immer wieder die Möglichkeit hat, das Projekt zu beeinflussen. Die Fähigkeit, auf Änderungen zu reagieren, ist wichtiger als das Verfolgen eines Plans. Zu Beginn des Projektes ist das Wissen über das System am geringsten, und während des Projektes können immer unvorhersehbare Ereignisse eintreffen, die ursprüngliche Schwerpunkte verschieben. Ein akribisch eingehaltener Plan kann vollständig und termingerecht erfüllt sein und doch am Ende nicht das leisten, was der Kunde gewünscht hat. 1 Agile Prozesse akzeptieren Änderungen als unvermeidlich und willkommen, 2 nur für den Zeitraum der aktuellen Iteration 3 gelten Anforderungen als verbindlich. 1 vgl. [HIGHSMITH00] 2 Der Untertitel von [BECK00] lautet (doppeldeutig) im Original: Embrace change 3 Agile Prozesse verwenden kurze Iterationen von wenigen Wochen

13 5 Überblick über wichtige Agile Prozesse 1.3 Überblick über wichtige Agile Prozesse Adaptive Software Development (ASD) Adaptive Software Development entstand aus den Erfahrungen von Jim Highsmith und hat seine Wurzeln im Rapid Application Development (RAD). Seit 1992 wurde es erfolgreich in mehr als 100 Projekten eingesetzt und schließlich im Jahr 2000 in Buchform veröffentlicht. In einem iterativen Prozess, dem sogenannten ASD Life Cycle, werden nach anfänglicher Initialisierungsphase Zyklen von Adaptive cycle planning, Concurrent feature development und Quality review durchgeführt. Anwender und Kunden weisen die zu realisierenden Anforderungen für die Iteration von zwei bis acht Wochen Länge zu Scrum Scrum, dessen Name aus dem Rugby entlehnt ist, wurde seit Anfang der neunziger Jahre von Ken Schwaber und Jeff Sutherland in zahlreichen Projekten eingesetzt und schließlich im Jahr 2001 in Buchform veröffentlicht. Bei Scrum werden die Anforderungen in einem sogenannten Backlog vom Kunden für eine 30-tägige Iteration (den sogenannten Sprint) ausgewählt. Die Kontrolle über den Prozess erfolgt mit kurzen täglichen Meetings und einer Demonstration nach dem Sprint. Scrum ist dabei eher ein Projekt-Management-Framework und kann mit verschiedenen Techniken kombiniert werden Lean Development (LD) Der Name entstammt der Lean production, die in den achtziger Jahren vor allem in der Auto-Industrie sehr populär war. Robert N. Charette übertrug diese Erfahrungen in die Entwicklung von Software und leitet daraus zwölf einfache Prinzipien ab, die den typischen, Agilen Werten entsprechen. LD beruht im wesentlichen auf Risiko Management und Templating-Techniken Feature Driven Development (FDD) FDD entstand aus den Projekt-Erfahrungen von Jeff De Luca und Peter Coad Mitte der neunziger Jahre und wurde erfolgreich vor allem in sehr großen Projekten verwendet. Nach einer kurzen Initialisierungsphase werden iterativ ausgewählte Anforderungen geplant und umgesetzt Dynamic System Development Method (DSDM) DSDM ist einer der umfangreicheren Agilen Prozesse und wurde in speziellen Versionen erfolgreich in Europa und den USA eingesetzt. Er wird als einziger Agiler Prozess von einem Konsortium gepflegt. Ihm gehören Mitglieder an wie Hewlett Packard, British Airways oder Oracle. DSDM muss kostenpflichtig lizenziert werden und ist als Agiler Prozess für die ISO-9000-Zertifizierung zugelassen. 4 1 vgl. [HIGHSMITH00] 2 vgl. [SCHWABER01] oder [URL_SCRUM] 3 vgl. [URL_FDD] 4 vgl. [URL_DSDM] oder [COLDEWEY02]

14 1. Einführung Extreme Programming (XP) Extreme Programming ist einer der bekanntesten Agilen Prozesse. Es beruht auf einem einfachen System von Techniken und wurde Mitte der neunziger Jahre von Kent Beck, Ward Cunningham und Ron Jeffries entwickelt sowie erfolgreich eingesetzt wurde es in Buchform veröffentlicht 1 und hat eine enorme Popularität erreicht. 2 Die maßgeblich auf Kent Beck und XP zurückzuführende wachsende Verbreitung Agiler Prozesse in der Industrie führt heute dazu, dass der ausschließliche Einsatz herkömmlicher (schwerer) Prozesse stärker hinterfragt wird und der Projekterfolg wieder stärker in den Mittelpunkt rückt. Da die meisten in diesem Projekt verwendeten Techniken aus dem XP stammen, wird dieser Prozess ausführlich im Kapitel 2 beschrieben Crystal Methodologies Bei der Crystal-Methoden-Familie handelt es sich genaugenommen nicht um einen Prozess, sondern um ein Framework. Alistair Cockburn befragte in den neunziger Jahren Mitarbeiter in erfolgreichen Projekten, welche Methoden und Techniken sie eingesetzt hätten. Aus diesen Erfahrungen leitete er dann die Erkenntnis ab, dass unterschiedliche Projekte unterschiedliche Prozesse benötigen. Als wesentlichen Beitrag ermöglichen die Crystal- Methoden eine Klassifizierung von Projekten. Alistair Cockburn entwarf dazu eine Matrix, in der Projekte nach mehreren Kriterien wie z.b. Größe geordnet waren. Abb. 2: Die Crystal-Methoden-Familie Zu den Erkenntnissen der Crystal-Familie gehört: Je geringer die Größe des Teams ist, um so weniger Dokumente müssen verwendet werden. Je kritischer die Anwendung dagegen ist, um so formaler müssen diese Dokumente sein. 3 1 vgl. [BECK00] 2 vgl. [COLDEWEY01B] 3 vgl. [COCKBURN02] oder [URL_CRYSTAL]

15 7 Prozesse in Web-Projekten 1.4 Prozesse in Web-Projekten Für die spezifischen Bedingungen von Web-Projekten eignen sich nicht alle Prozesse gleichermaßen. In den letzten Jahren hat sich in der Industrie vermehrt gezeigt, dass die Realität von Web-Projekten stark durch Aspekte wie kleine Teams, unklare und wechselnde Anforderungen sowie recht kurze Projektlaufzeiten geprägt wird. Die Flexibilität, Anforderungen in einem gewissen Maß auch während des Projektes an die Marktgegebenheiten anpassen zu können, wird durch den Markt gefordert. Diese Flexibilität steht mit ihrem Grundprinzip der Veränderbarkeit in gewissem Gegensatz zu den Formalismen und Vorabspezifikationen, auf die schwere Prozesse aufbauen. Dieser Konflikt führte und führt im Umfeld der Web-Projekte oft zu einer gänzlichen Abwendung von den althergebrachten Prozessen hin zu einer pragmatischen Can do -Mentalität, die alles als veränderbar annimmt und Prozesse per se als zu engen Rahmen für die Erstellung von Software im Internet ansieht. 1 Die Ergebnisse der CHAOS-Studie haben erwiesen, dass der Einsatz schwerer Prozesse unter diesen Rahmenbedingungen kein Garant für erfolgreiche Produkte ist. Im Gegenteil, die Gemeinsamkeiten erfolgreicher Projekte deuten klar in die Richtung, etablierte Prozesse auf ein sinnvolles Minimum zu verschlanken und den Rahmenbedingungen von Web-Projekten anzupassen. Ähnlich wie das Tailoring des RUP, nur eben radikaler in der Reduktion der Artefakte. Hier bietet sich der Einsatz Agiler Prozesse besonders an, zumal einige speziell für derartige Projekte, basierend auf Erfahrungen aus diesem Projektumfeld, entwickelt wurden, wie z.b. Crystal Orange Web aus der Crystal-Methoden-Familie. Dieser Prozess unterscheidet sich vom normalen Crystal Orange dadurch, dass er den Fokus nicht auf ein einzelnes Projekt legt, sondern auf einen kontinuierlichen Strom von Initiativen. Jede dieser Initiativen erfordert Programmierung und die anschließende Überführung der entstandenen Ergebnisse in eine gemeinsame Code-Basis zur Nutzung in anderen Projekten. 2 Dieser Ansatz trägt unter anderem der Tatsache Rechnung, dass Mitarbeiter nicht zu 100 % auf ein Projekt gebucht werden können, weil sie in mehreren Projekten gleichzeitig beschäftigt sind. In der Gegenwart bestimmen jedoch klassische Phasenmodelle den Ablauf von Web-Projekten. Dabei ist es sogar üblich, dass einzelne Phasen differenziert verkauft und abgerechnet werden. So wird oft ein Ergebnis einer Konzeptionsphase, z.b. ein sogenanntes Feinkonzept, in Auftrag gegeben, in dem die Anforderungen an das endgültige System erarbeitet werden. Diese Besonderheit von Web-Projekten ist darauf zurückzuführen, dass die Kunden in diesen Projekten meist nur sehr unklare Vorstellungen von den Möglichkeiten des Mediums Internet besitzen und unter anderem deswegen die Beratungsleistung des Dienstleisters in Anspruch nehmen. 1 vgl. [URL_ISD] Seite 55 2 vgl. [COCKBURN02] Seite 206

16 1. Einführung Besonderheiten von Web-Projekten Web-Projekte weisen eine Reihe von Unterschieden zu anderen Software-Projekten auf. Im Ergebnis dieser Projekte entstehen nicht nur Programme, sondern auch Videos, Musik, Graphiken usw. Web-Projekte gehören damit zu Multimedia-Projekten, wie z.b. auch Computerspiele. 1 Die Besonderheiten von Web-Projekten sind für diese Arbeit besonders relevant, deswegen werden sie im Folgenden detailliert erläutert Festpreisprojekte Der häufigste Typ von Projekten allgemein sind sogenannte Festpreisprojekte, bei denen die vier Variablen Kosten, Zeit, Qualität und Umfang von beiden Seiten festgelegt werden. Das resultiert vor allem aus dem Selbstverständnis der meisten Anbieter als Dienstleister. Die Kunden haben die Auswahl zwischen vielen Anbietern und schreiben daher für die Durchführung solcher Projekte fast immer einen sogenannten Pitch aus. Der Dienstleister mit der ansprechendsten Präsentation und dem besten Preis-/Leistungsverhältnis gewinnt meistens den Pitch. Die Anbieter können es sich dabei in der Regel nicht leisten, ein Team anzubieten, das für im Monat für den erforderlichen Zeitraum gemietet werden kann, solange sich die Kunden bei anderen Anbietern (scheinbar) sicher sein können, das gesamte Projekt für geliefert zu bekommen. Gerade bei größeren Kunden erfolgen Bezahlung und die vorausgehenden Verhandlungen oft durch eine eigene Abteilung, den Einkauf. Dieser ist darauf spezialisiert, Preise durch Vergleiche von Anbietern planbar zu machen und den günstigsten Anbieter auszuwählen. Für diesen Zweck verlangt ein solcher Einkauf im Allgemeinen absolute Summen. Nach der Philosophie von XP können solche Projekte nur selten erfolgreich sein. Sie erfordert, dass zumindest eine dieser vier obengenannten Variablen justierbar bleibt. 2 Kent Beck empfiehlt daher, solche Projekte stets umzuwandeln und entweder den Umfang oder die Qualität flexibel zu gestalten. 3 Und genau hier liegt eines der größten Probleme von XP, denn sowohl Kunden als auch Management müssen überzeugt werden, von ihren jahrelang gewohnten und einfach auch üblichen Vertragsmodellen abzuweichen, inklusive der ebenso üblichen Überschreitungen von Budget oder Zeitplan. Obwohl durchaus auch Festpreisprojekte erfolgreich mit XP durchgeführt wurden 4, so ist diese Konstellation zumindest problematisch. Das gilt aber nicht nur für Agile Prozesse, sondern prinzipiell für die IT-Branche, wo ein generelles Umdenken erforderlich ist. 5 1 vgl. [WALLACE02] Seite V 2 vgl. [BECK00] Seite 15ff 3 vgl. [BECK00] Seite vgl. [LIPPERT02] Seite 155f 5 vgl. [BLEUL01] Seite 185

17 9 Besonderheiten von Web-Projekten Projektlaufzeiten Die Laufzeit von Web-Projekten ist in der Regel um einiges kürzer als die von anderen Software-Projekten. Sie dauern im Allgemeinen nur wenige Monate, nur in seltenen Fällen länger als ein Jahr. Das wirkt sich selbstverständlich auf die Dauer der Iterationen aus. Würde man etwa eine Iterationsdauer von vier Wochen für ein Projekt mit zwei Monaten Gesamtlaufzeit festlegen, gäbe es gerade zwei Iterationen. Die kurzen Projektlaufzeiten eröffnen aber auch eine Chance, nämlich die Möglichkeit, ständig die neuesten und aktuellsten Technologien auszuprobieren. Sie versprechen für gewöhnlich eine schnellere und effizientere Projektdurchführung. Der Einsatz solcher Technologien erfordert jedoch Mitarbeiter, die mit solchen, oft noch wenig verbreiteten Technologien vertraut sind. Oftmals sind die Projekte zu einem definierten Zeitpunkt nicht vollständig abgeschlossen. Die Dienstleister betreuen den Internet-Auftritt oft noch viele Monate oder Jahre. Diese Betreuung erfordert aber in der Ressourcenplanung die Verfügbarkeit von Mitarbeitern. Für das aktuelle Projekt können viele Mitarbeiter deswegen nicht zu vollem Anteil gebucht werden, da sie einen Teil ihrer Zeit mit der Betreuung laufender Projekte verbringen. Die Berücksichtigung dieses Umstands muss von den eingesetzten Prozessen unterstützt werden Unscharfe Anforderungen Während der Kunde in herkömmlichen Software-Projekten in der Regel über das nötige Spezialwissen der Domäne verfügt, sieht er sich bei Web-Projekten häufig mit großen Schwierigkeiten konfrontiert, dieses Wissen auf das neue Medium anzuwenden. 1 Er wendet sich unter anderem deswegen an einen Dienstleister, damit dieser ihm bei der Präsentation in dem Medium Internet behilflich ist. Viele daraus resultierenden Anforderungen kommen also letztendlich vom Dienstleister selbst, der meist für diesen Zweck eine spezielle Abteilung (Konzeption) besitzt. Erst in einem relativ späten Stadium des Projektes wird für den Kunden sichtbar, ob die Konzeption die richtigen Anforderungen (Requirements) erarbeitet hat Interdisziplinäre Teams Die Vielzahl der unterschiedlichen Anforderungen von Web-Projekten erfordert überdurchschnittliche Teamzusammenstellungen. Dazu gehören z.b. Konzepter, Grafikdesigner oder Content-Redakteure. Selbst die Entwickler unterscheiden sich oft z.b. in Backend-, Frontend- oder Flash-Entwickler. Darüber hinaus werden häufig Usability-Experten für die Optimierung der Oberflächen herangezogen. 1 vgl. [WALLACE02] Seite 112

18 1. Einführung Heterogene Architekturen Während für die meisten Anwendungen die Zielarchitektur relativ homogen ist, ist sie für Web-Projekte in der Regel sehr vielfältig. Je nach Anforderung muss das System für Nutzer der verschiedensten Betriebssysteme, mit verschiedenen Browsern, verschiedenen Plugins, individuellen Einstellungen, unterschiedlichen Auflösungen, ja sogar unterschiedlichen Farben angeboten werden. Neben der Berücksichtung der unterschiedlichen Client-Systeme stellt der Kunde auch oft Anforderungen an die Server-Infrastruktur. Schließlich muss sich die Anwendung in dessen Systemumgebung integrieren Subjektive Tests In Web-Projekten lassen sich nicht alle Tests automatisieren. Typische Probleme im Umfeld des automatisierten Tests von Web-Projekten ergeben sich aus der stark visuell geprägten Wahrnehmung von Fehlern. Beispielsweise lässt sich zwar automatisiert feststellen, ob ein Button vorhanden ist, aber wird er rechtsbündig dargestellt oder zentriert? Und ist das Ergebnis auf allen Browsern identisch? Und wenn ein Bild an der erwarteten Stelle einer Webseite mit der erforderlichen Größe ist, so wäre es doch ein schwerwiegender Fehler, wenn es das falsche Bild wäre. Web-Projekte erfordern immer auch Testen durch Testpersonen, und die erforderliche Zeit zum Testen muss vor jedem Release mit eingeplant werden.

19 11 Geschichte 2. Extreme Programming Extreme Programming (XP) ist ein leichtgewichtiges Prozessmodell für Software-Entwicklung in kleinen und mittelgroßen Teams. Es besteht aus einem System von Techniken, die im Zusammenspiel eine flexiblere und risikoärmere Erstellung von Software ermöglichen sollen. Da der überwiegende Teil der während des Projektes eingesetzten Agilen Techniken dem Extreme Programming entstammt, soll dieser Prozess im folgenden näher erläutert werden. 2.1 Geschichte Extreme Programming entstand Mitte der neunziger Jahre, obwohl die darin verwendeten Techniken teilweise viel älter sind. Als erste Arbeit zu diesem Thema gilt ein Beitrag von Ward Cunningham auf der PLoP95. 1 Die Namensgebung erfolgte durch Kent Beck 2, der das Verfahren zum ersten Mal 1996 in einem Team von Programmierern für eine Gehaltsabrechnungs-Software von Chrysler einsetzte. Beck war zuvor durch die Veröffentlichung von einigen Büchern zum Thema Smalltalk 3 bekannt geworden und vor allem durch die Erfindung der CRC-Karten. Einen wesentlichen Beitrag leistete auch Martin Fowler, der die Technik des Refactoring 4 systematisierte. Er war als Berater zu diesem Projekt hinzugezogen worden. Fowler veröffentlichte zuvor bereits einige Bücher zum Thema Objektorientierte Programmierung (OOP), von denen vor allem UML destilled 5 und Analysis patterns 6 zu den Klassikern der OO-Literatur zählen. Inzwischen findet XP eine immer größere Verbreitung und ist besonders in den Kreisen der OO-Entwickler auf großes Interesse gestoßen. So entstand z.b. durch die Zusammenarbeit von Kent Beck und Erich Gamma 7 ein weiteres, oft referenziertes Projekt: JUnit 8, ein JAVA Framework für die automatische Durchführung von Unit tests. XP ist nicht unumstritten. Während vor allem von akademischer Seite aus immer wieder Bedenken an den mitunter sehr radikalen Konzepten von XP vorgebracht werden, gibt es eine stetig wachsende Anzahl an Erfolgsmeldungen aus der Praxis, die von Kritikern teilweise bereits als Hype bezeichnet werden 9. Die Wahrheit liegt vermutlich irgendwo in der Mitte, und so bemüht man sich momentan um eine sachliche Diskussion darüber, in welchen Domänen die Prinzipien von XP gelten. 1 vgl. [URL_EPISODES] 2 In einem gleichnamigen Buch erschienen 1999 (vgl. [BECK00]) 3 vgl. z.b. [BECK97] oder [BECK98] 4 In einem gleichnamigen Buch erschienen 1999 (vgl. [FOWLER00]) 5 vgl. [FOWLER00B] 6 vgl. [FOWLER99] 7 Erich Gamma machte sich durch die Einführung von Entwurfsmustern in die OO Software-Entwicklung verdient (vgl. [GAMMA96]) 8 vgl. [URL_JUNIT] 9 vgl. [COLDEWEY01B], [WEGENER99] oder [KÖNIG02]

20 2. Extreme Programming Rollen Der XP-Prozess kennt eine geringe Anzahl von Rollen. Einige der Rollen können von der gleichen Person übernommen werden oder, wie im Falle des Terminmanagers, zwischen verschiedenen Personen wechseln. 1 Der Programmierer (programmer) ist für die Entwicklung des Codes und dessen Integration zuständig. Außerdem schreibt er die automatisierten Unit tests, schätzt Aufwände und übernimmt das Design. Der Kunde (customer) ist selber Teil des XP-Teams, er schreibt zusammen mit den Programmierern die Anforderungen (in Form von Story-Karten) auf und definiert dafür Akzeptanztests. Diese Akzeptanztests entscheiden darüber, wann eine Anforderung als erfüllt gilt. Er trifft außerdem die Entscheidung, welche der Anforderungen für ihn den größten Wert darstellt. Dadurch, dass der Kunde selbst Mitglied des XP-Teams ist, können Rückfragen sehr effektiv beantwortet werden. Der Terminmanager (tracker) überwacht den Projektfortschritt und andere relevante Metriken. Er hält sich darüber auf dem Laufenden, wie weit das Team in der aktuellen Iteration ist und achtet auf Alarmsignale, wenn Termine nicht eingehalten werden können. Er vergleicht die Aufwandschätzungen der Programmierer mit den tatsächlich angefallenen Aufwänden und konfrontiert die Programmierer mit den Abweichungen, um die Schätzgenauigkeit perspektivisch zu erhöhen. Eine wichtige Metrik zur Demonstration des Projektfortschritts ist die Anzahl erfolgreicher Akzeptanztests, die jeweils den Abschluss einer Funktionalität bedeuten. Andere wichtige Metriken können jedoch auch die Anzahl der Unit tests, die Anzahl der Integrationen oder eben jede andere Statistik sein, die dem Team zu einem bestimmten Zeitpunkt im Projekt hilft. 2 Die Aufgabe des Trainers (coach) besteht in der Einführung der XP-Techniken. Er versucht darauf zu achten, dass diese Techniken auch wirklich angewendet werden. Ein guter Coach trifft jedoch keine Entscheidung für das Team, sondern ist nur beratend tätig. Der Coach hilft dem Team, den XP-Prozess fortwährend zu verbessern. In vielen Projekten werden externe XP-Coaches hinzugezogen, da für die Ausübung dieser Rolle umfangreiche Erfahrungen erforderlich sind. Im ursprünglichen XP-Buch 3 gibt es darüber hinaus einige weitere Rollen, die aber in der Praxis für den Prozess nicht von der gleichen Bedeutung sind: Berater, als externer XP-Spezialist, Big Boss, stellvertretend für das Management und Tester, für die Durchführung der Akzeptanztests in Zusammenarbeit mit dem Kunden. 1 vgl. [BECK00] Seite vgl. [BECK01] Seite 112ff 3 Die deutsche Übersetzung [BECK00] erschien 2000, das Original ist von 1999.

Empirische Evidenz von agilen Methoden. Seminar in Software Engineering Wintersemester 03/04

Empirische Evidenz von agilen Methoden. Seminar in Software Engineering Wintersemester 03/04 Empirische Evidenz von agilen Methoden Seminar in Software Engineering Wintersemester 03/04 Agenda Einleitung Bedeutung von agil Kurzübesicht agiler Methoden Überprüfung des (agilen) Erfolges Ausgewählte

Mehr

extreme Programming Eine Einführung mit Empfehlungen und Erfahrungen aus der Praxis dpunkt.verlag Henning Wolf Stefan Roock Martin Lippert

extreme Programming Eine Einführung mit Empfehlungen und Erfahrungen aus der Praxis dpunkt.verlag Henning Wolf Stefan Roock Martin Lippert Henning Wolf Stefan Roock Martin Lippert extreme Programming Eine Einführung mit Empfehlungen und Erfahrungen aus der Praxis 2., überarbeitete und erweiterte Auflage dpunkt.verlag 1 Einleitung 1 1.1 Die

Mehr

3. Vorgehensmodelle Software Engineering. Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006

3. Vorgehensmodelle Software Engineering. Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006 3. Vorgehensmodelle Software Engineering Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006 Agenda Agenda Übersicht V-Modell Rational Unified Process Extreme Programming Fazit, Literatur, Kontrollfragen

Mehr

Software Engineering. 4. Methodologien. Franz-Josef Elmer, Universität Basel, HS 2014

Software Engineering. 4. Methodologien. Franz-Josef Elmer, Universität Basel, HS 2014 Software Engineering 4. Methodologien Franz-Josef Elmer, Universität Basel, HS 2014 Software Engineering: 4. Methodologien 2 Wie den Entwicklungsprozess organisieren? Dokumentieren Verwalten Instandhalten

Mehr

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing.

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. SOFTWARETECHNIK Kapitel 7 Vorgehensmodelle Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. Armin Zimmermann Inhalt Vorgehensmodelle Sequenzielle Modelle Iterative

Mehr

- Agile Programmierung -

- Agile Programmierung - Fachhochschule Dortmund Fachbereich Informatik SS 2004 Seminar: Komponentenbasierte Softwareentwicklung und Hypermedia Thema: - - Vortrag von Michael Pols Betreut durch: Prof. Dr. Frank Thiesing Übersicht

Mehr

Agile Softwareprozess-Modelle

Agile Softwareprozess-Modelle Agile Softwareprozess-Modelle Steffen Pingel Regionale Fachgruppe IT-Projektmanagement 2003-07-03 Beweglich, Lebhaft, Wendig Was bedeutet Agil? Andere Bezeichnung: Leichtgewichtiger Prozess Manifesto for

Mehr

10 Jahre agile Softwareentwicklung Wie erwachsen sind wir geworden?

10 Jahre agile Softwareentwicklung Wie erwachsen sind wir geworden? 10 Jahre agile Softwareentwicklung Wie erwachsen sind wir geworden? Stefan Roock stefan.roock@akquinet.de Hintergrund 1/2 Senior IT-Berater bei der akquinet AG extreme Programming seit Anfang 1999, dann

Mehr

Software entwickeln mit extreme Programming

Software entwickeln mit extreme Programming Martin Lippert Stefan Roock Henning Wolf Software entwickeln mit extreme Programming Erfahrungen aus der Praxis dpunkt.verlag Inhaltsverzeichnis 1 Einleitung 1 1.1 Die XP-Werte 4 1.2 Die XP-Prinzipien

Mehr

3. Vorgehensmethoden/Prozessmodelle

3. Vorgehensmethoden/Prozessmodelle 3. Vorgehensmethoden/Prozessmodelle Vorgehensmethode/Prozessmodell: Ablauforganisation des Projektes für eine effektive und zielgerichtete Softwareentwicklung Wasserfallmodell Spiralmodell Agiles Vorgehen

Mehr

Extremes Programmieren

Extremes Programmieren Extremes Programmieren Übersicht, Demonstration, Erfahrungen ACM/GI Regionalgruppe Hamburg, 16.3.2001 Frank Westphal unabhängiger Berater westphal@acm.org http://www.frankwestphal.de Tammo Freese OFFIS,

Mehr

Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise

Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise Die Bearbeitungszeit der Klausur beträgt 90 Minuten. Es sind alle

Mehr

Einführung in die SWE

Einführung in die SWE Einführung in die SWE Inhalte der Vorlesung Allgemeine Ziele der Lehrveranstaltung Entwickeln einer kleinen Applikation nach professionellem Vorgehensmodell Erlernen des objektorientierten Herangehens

Mehr

Ganzheitliches IT-Projektmanagement

Ganzheitliches IT-Projektmanagement Ganzheitliches IT-Projektmanagement Kapitel 2 nach dem Buch: Ruf, Walter; Fittkau, Thomas: "Ganzheitliches IT-Projektmanagement" Wissen - Praxis - Anwendungen R. Oldenbourg Verlag München - Wien 2008;

Mehr

Herkömmliche Softwareentwicklungsmodelle vs. Agile Methoden

Herkömmliche Softwareentwicklungsmodelle vs. Agile Methoden vs. Agile Methoden Christoph.Kluck@Student.Reutlingen University.de Medien und Kommunikationsinformatik Agenda Einführung Vorgehensmodelle Herkömmlich agil Resümee Klassische Probleme Nachgereichte Anforderungen

Mehr

Extreme Programming. Universität Karlsruhe (TH) Fakultät für Informatik Lehrstuhl für Programmiersysteme. Forschungsuniversität gegründet 1825

Extreme Programming. Universität Karlsruhe (TH) Fakultät für Informatik Lehrstuhl für Programmiersysteme. Forschungsuniversität gegründet 1825 Universität Karlsruhe (TH) Forschungsuniversität gegründet 1825 Extreme Programming Agiles Manifest Individuen und Interaktion wichtiger als Prozesse und Werkzeuge Laufende Software wichtiger als vollständige

Mehr

Einführung in die Softwaretechnik 9. Softwareprozesse

Einführung in die Softwaretechnik 9. Softwareprozesse 9. Softwareprozesse Klaus Ostermann (Mit Folien von Christian Kästner, Gabriele Taentzer und Wolfgang Hesse) 1 Agenda Wie kommt man vom Kundenwunsch zur fertigen Software? Wie strukturiert man ein Softwareprojekt?

Mehr

Werte 2.0 - Weil ich es mir wert bin. Dipl.-Inf. Bernd Schiffer akquinet it-agile GmbH bernd.schiffer@akquinet.de

Werte 2.0 - Weil ich es mir wert bin. Dipl.-Inf. Bernd Schiffer akquinet it-agile GmbH bernd.schiffer@akquinet.de Werte 2.0 - Weil ich es mir wert bin Dipl.-Inf. Bernd Schiffer akquinet it-agile GmbH bernd.schiffer@akquinet.de Danke, Johannes... 2 Ich sah sie überall... 3 Werte des Extreme Programmings Kommunikation

Mehr

myscrum Scrum in der Praxis Markus Schramm compeople AG Frankfurt

myscrum Scrum in der Praxis Markus Schramm compeople AG Frankfurt myscrum Scrum in der Praxis Markus Schramm compeople AG Frankfurt Überblick Agilität und Scrum Grundlagen der agilen Softwareentwicklung Rahmenbedingungen bei der Einführung eines agilen Projektvorgehens

Mehr

Software-Entwicklung

Software-Entwicklung Software-Entwicklung SEP 96 Geschichte der Programmierung Aufgaben von, Anforderungen an Programme mit der Zeit verändert 1 Programmierung über Lochkarten z.b. für Rechenaufgaben 2 maschinennahe Programmierung

Mehr

Software- Projektmanagement. Dokument V 1.2-2010. Oliver Lietz - Projektmanagement. Projektmodelle im Vergleich. Agil Extreme Programming /

Software- Projektmanagement. Dokument V 1.2-2010. Oliver Lietz - Projektmanagement. Projektmodelle im Vergleich. Agil Extreme Programming / Software- Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.2-2010 Projektmodelle im Vergleich Klassisch Wasserfall -Modell Spezifikation/Pflichtenheft

Mehr

6 Jahre extreme Programming Eine Retrospektive

6 Jahre extreme Programming Eine Retrospektive 6 Jahre extreme Programming Eine Retrospektive Dipl.-Informatiker Martin Lippert Senior IT-Berater martin.lippert@it-agile.de http://www.it-agile.de Hintergrund Senior IT-Berater bei it-agile GmbH extreme

Mehr

Extreme Programming. Frank Gerberding LINEAS Informationstechnik GmbH Theodor-Heuss-Straße 2 D-38122 Braunschweig

Extreme Programming. Frank Gerberding LINEAS Informationstechnik GmbH Theodor-Heuss-Straße 2 D-38122 Braunschweig Extreme Programming Frank Gerberding LINEAS Informationstechnik GmbH Theodor-Heuss-Straße 2 D-38122 Braunschweig Stand: 11.06.2007 LINEAS Gruppe - Zahlen und Fakten LINEAS Gruppe Branche Software- und

Mehr

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was

Mehr

Softwareentwicklungsprozesse. 18. Oktober 2012

Softwareentwicklungsprozesse. 18. Oktober 2012 Softwareentwicklungsprozesse 18. Oktober 2012 Überblick Was soll ein Softwareentwicklungsprozess leisten? Überblick über Softwareentwicklungsprozesse Welche gibt es? Warum gibt es mehrere? Diskussion:

Mehr

Klassische vs. agile Methoden der Softwareentwicklung

Klassische vs. agile Methoden der Softwareentwicklung Klassische vs. agile Methoden der Softwareentwicklung Vorgetragen am 03. November 2004 durch Jonathan Weiss Emel Tan Erstellt für SWT Methoden und Werkzeuge zur Softwareproduktion Agenda I. Einleitung

Mehr

Compact Scrum Guide. Agile Coach / Business Consultant @ Prowareness Contact: o.mann@prowareness.de, 0176-52845680

Compact Scrum Guide. Agile Coach / Business Consultant @ Prowareness Contact: o.mann@prowareness.de, 0176-52845680 Compact Scrum Guide Author: Oliver Mann, Role: Agile Coach / Business Consultant @ Prowareness Contact: o.mann@prowareness.de, 0176-52845680 Compact Scrum Guide Inhalt 1. Was ist Scrum und wofür wird es

Mehr

Projektmanagement. Dokument V 1.2. Oliver Lietz - Projektmanagement. Probleme bei Projekten

Projektmanagement. Dokument V 1.2. Oliver Lietz - Projektmanagement. Probleme bei Projekten Projektmanagement Agile Methoden: Extreme Programming / Scrum Dokument V 1.2 Probleme bei Projekten Viel Arbeit, die an den Zielen vorbeigeht Viel Dokumentation für f r unbenutzte Bestandteile Fehlende

Mehr

Referat Extreme Programming. Von Irina Gimpeliovskaja und Susanne Richter

Referat Extreme Programming. Von Irina Gimpeliovskaja und Susanne Richter Referat Extreme Programming Von Irina Gimpeliovskaja und Susanne Richter 1.) Was ist XP? Überlegte Annäherung an Softwareentwicklung Prozessmodell für objektorientierte Softwareentwicklung erfordert gute

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se

Mehr

Das Who s Who der agilen Methoden Golo Roden

Das Who s Who der agilen Methoden Golo Roden Das Who s Who der agilen Methoden Golo Roden www.goloroden.de www.des-eisbaeren-blog.de Über mich > Wissensvermittler und Technologieberater >.NET, Codequalität und agile Methoden > MVP für C#, zweifacher

Mehr

Softwareentwicklungsprozesse optimieren. wie Sie die Vorteile klassischer und agiler Methoden erfolgreich kombinieren

Softwareentwicklungsprozesse optimieren. wie Sie die Vorteile klassischer und agiler Methoden erfolgreich kombinieren Softwareentwicklungsprozesse optimieren wie Sie die Vorteile klassischer und agiler Methoden erfolgreich kombinieren Dipl.-Inform. Dipl.-Math. Wolfhart Grote Software Ring e. G., Erlangen 25. Oktober 2007

Mehr

Was funktioniert und was nicht? Agile Softwareentwicklung in der Praxis Martin Lippert, martin.lippert@akquinet.de

Was funktioniert und was nicht? Agile Softwareentwicklung in der Praxis Martin Lippert, martin.lippert@akquinet.de Was funktioniert und was nicht? Agile Softwareentwicklung in der Praxis Martin Lippert, martin.lippert@akquinet.de Über mich Martin Lippert Senior IT-Berater bei akquinet it-agile GmbH martin.lippert@akquinet.de

Mehr

Anforderungsermittlung mit Extreme Programming (XP) - Erfahrungen aus der Praxis

Anforderungsermittlung mit Extreme Programming (XP) - Erfahrungen aus der Praxis Anforderungsermittlung mit Extreme Programming (XP) - Erfahrungen aus der Praxis Stefan Roock, roock@jwam.de APCON Workplace Solutions GmbH & Universität Hamburg Vogt-Kölln-Strasse 30 22527 Hamburg Germany

Mehr

XP, Scrum, Crystal, FDD:

XP, Scrum, Crystal, FDD: XP, Scrum, Crystal, FDD: Welche agile Methode passt zu uns? Henning Wolf Christoph Kemp Was ist Agilität? Teil 1: Das agile Manifest We are uncovering better ways of developing software by doing it and

Mehr

Projektmanagement: Prozessmodelle

Projektmanagement: Prozessmodelle Projektmanagement: Prozessmodelle Martin Wirsing Institut für Informatik Ludwig-Maximilians-Universität München WS 2006/07 Ziele Wichtige Prozessparadigmen und Vorgehensmodelle wiederholen und in Zusammenhang

Mehr

Extreme Programming. Referat von Viktoria Schwarzhaupt und Andrea Schuhmann

Extreme Programming. Referat von Viktoria Schwarzhaupt und Andrea Schuhmann Extreme Programming Referat von Viktoria Schwarzhaupt und Andrea Schuhmann 1. Was ist XP - Prozessmodell für die objektorientierte Softwareentwicklung - leichter Softwareentwicklungsprozess Analyse Design

Mehr

Software Engineering (SE) 2) Phasenübergreifende Verfahren

Software Engineering (SE) 2) Phasenübergreifende Verfahren Software Engineering (SE) 2) Phasenübergreifende Verfahren Prof. Dr. Anja Metzner Hochschule Augsburg, Fakultät für Informatik Kontakt: anja.metzner@hs-augsburg.de Studiengang IBac 1 (Stand: 01.10.2014),

Mehr

Software-Lebenszyklus

Software-Lebenszyklus Software-Lebenszyklus Inhalt Vorgehensmodell/Phasenplan Wasserfallmodell WAS-Beschreibung WIE-Beschreibung Weitere Phasenmodelle: Spiral-Modell, V-Modell, RUP Extreme Programming SW-Qualitätssicherung

Mehr

Wasserfall, «Death March», Scrum und agile Methoden. 08. Dezember 2011 Embedded Software Engineering Kongress Urs Böhm

Wasserfall, «Death March», Scrum und agile Methoden. 08. Dezember 2011 Embedded Software Engineering Kongress Urs Böhm Wasserfall, «Death March», Scrum und agile Methoden 08. Dezember 2011 Embedded Software Engineering Kongress Urs Böhm Übersicht Warum Projektmanagement? Gängige SW Entwicklungsprozesse Wasserfall V-Modell

Mehr

Systemen - Testen im Softwarelebenszyklus

Systemen - Testen im Softwarelebenszyklus P r a k t I s c h e Entwicklung und Test Testen von Software-Systemen Systemen - Testen im Softwarelebenszyklus Entwickler erstellen ihr System bzw. ihre Software und testen es/sie zur Entwicklungszeit

Mehr

SCRUM. Scrum in der Software Entwicklung. von Ernst Fastl

SCRUM. Scrum in der Software Entwicklung. von Ernst Fastl SCRUM Scrum in der Software Entwicklung von Ernst Fastl Agenda 1. Die Entstehung von Scrum 2. Überblick über den Prozess 3. Rollen 4. Meetings 5. Artefakte 6. Fragen & Antworten Agenda 1. Die Entstehung

Mehr

Agile Programmierung - Theorie II SCRUM

Agile Programmierung - Theorie II SCRUM Agile Programmierung - Theorie II SCRUM Arne Brenneisen Universität Hamburg Fakultät für Mathematik, Informatik und Naturwissenschaften Seminar Softwareentwicklung in der Wissenschaft Betreuer: Christian

Mehr

Einführung in SCRUM. Helge Baier 21.01.2010

Einführung in SCRUM. Helge Baier 21.01.2010 Einführung in SCRUM Helge Baier 21.01.2010 Helge Baier Master of Computer Science (Software Engineering) über 10 Jahre Erfahrung in der Software Entwicklung Zertifizierung zum Scrum Master (2009) praktische

Mehr

Vorgehen im Softwareentwicklungsprozess

Vorgehen im Softwareentwicklungsprozess Der Softwareentwicklungsprozess Für die Entwicklung von Software, namentlich für große Projekte, ist ein systematisches Vorgehen notwendig. Dieses Vorgehen, der Softwareentwicklungprozess, wird strukturiert

Mehr

Projektmanagement. Projektmanagement

Projektmanagement. Projektmanagement Projektmanagement Dipl.-Ing. Oliver Lietz Was ist ein Projekt? Projektmanagement Eindeutiges Ziel Individuell (einmalig) Begrenzt (Anfang und Ende) Komplex (keine Routineaufgabe) Warum Projektmanagement

Mehr

Kurzübersicht Unified Process und Agile Prozesse

Kurzübersicht Unified Process und Agile Prozesse Kurzübersicht Unified Process und Agile Prozes Rainer Schmidberger schmidrr@informatik.uni-stuttgart.de Copyright 2004, Rainer Schmidberger, Universität Stuttgart, Institut für Softwaretechnologie, Abt.

Mehr

ANECON. Business Process meets Agile Software Development. DI Ernst Lieber Leiter Geschäftsfeld Softwareentwicklung

ANECON. Business Process meets Agile Software Development. DI Ernst Lieber Leiter Geschäftsfeld Softwareentwicklung ANECON Business Process meets Agile Software Development DI Ernst Lieber Leiter Geschäftsfeld Softwareentwicklung ANECON Software Design und Beratung G.m.b.H. Alser Str. 4/Hof 1 A-1090 Wien Tel.: +43 1

Mehr

Lösungen zum Test objektorientierter Software

Lösungen zum Test objektorientierter Software Lösungen zum Test objektorientierter Software Pieter van den Hombergh Fontys Hogeschool voor Techniek en Logistiek Software Engineering 14. März 2013 HOM/FHTeL Lösungen zum Test objektorientierter Software

Mehr

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.1 Wie kommt es zu einem Projektauftrag? Auftraggeber Projekt-Idee / Ziele [Anforderungen/Spezifikation/

Mehr

Professionelles Projektmanagement in der Praxis. Veranstaltung 7 Teil 1 (30.06.2003):

Professionelles Projektmanagement in der Praxis. Veranstaltung 7 Teil 1 (30.06.2003): Professionelles Projekt-Management in der Praxis Veranstaltung 7 Teil 1 (30.06.2003): Prof. Dr. Phuoc Tran-Gia, FB Informatik, Prof. Dr. Margit Meyer, FB Wirtschaftswissenschaften, Dr. Harald Wehnes, AOK

Mehr

Software-Projektmanagement Vorgehensmodelle vor dem Hintergrund globaler Software Projekte

Software-Projektmanagement Vorgehensmodelle vor dem Hintergrund globaler Software Projekte Software-Projektmanagement Vorgehensmodelle vor dem Hintergrund globaler Software Projekte Hochschule Furtwangen Robert-Gerwig-Platz 1 78120 Furtwangen E-Mail : Berkan.Kutlutuerk@hs-furtwangen.de Seite

Mehr

Software Engineering. 2. Methodologien. Franz-Josef Elmer, Universität Basel, HS 2010

Software Engineering. 2. Methodologien. Franz-Josef Elmer, Universität Basel, HS 2010 Software Engineering 2. Methodologien Franz-Josef Elmer, Universität Basel, HS 2010 Software Engineering: 2. Methodologien 2 Wie den Entwicklungsprozess organisieren? Dokumentieren Verwalten Instandhalten

Mehr

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering mit Übungen Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering 2 Organisation Ort: Seminarraum 05.002, Spiegelgasse 5 Ablauf: 15:15 Vorlesung Prüfung: Schriftlich,

Mehr

Agile Softwareentwicklung mit Scrum

Agile Softwareentwicklung mit Scrum Informatik Gregor Liebermann Agile Softwareentwicklung mit Scrum Referent: WiSe 2014 Gregor Liebermann M.Sc. www.hs-augsburg.de Überblick Aufbau der Vorlesung Montags 15:40 18:40 5 CP Aufteilung in Vorlesung

Mehr

Inhaltsverzeichnis. Inhaltsverzeichnis... I. 1 Problemstellung... 1. 2 V-Modell... 1. 2.1 Allgemeines... 1. 2.2 Anwendung des V-Modells...

Inhaltsverzeichnis. Inhaltsverzeichnis... I. 1 Problemstellung... 1. 2 V-Modell... 1. 2.1 Allgemeines... 1. 2.2 Anwendung des V-Modells... Inhaltsverzeichnis Inhaltsverzeichnis... I 1 Problemstellung... 1 2 V-Modell... 1 2.1 Allgemeines... 1 2.2 Anwendung des V-Modells... 3 3 SCRUM-Modell... 4 3.1 Allgemeines... 4 3.2 Anwendung des SCRUM-Modells...

Mehr

Praktische Erfahrungen beim Einsatz des Vorgehensmodells "SCRUM" bei AGFA HealthCare

Praktische Erfahrungen beim Einsatz des Vorgehensmodells SCRUM bei AGFA HealthCare Praktische Erfahrungen beim Einsatz des Vorgehensmodells "SCRUM" bei AGFA HealthCare SCRUM Praktische Erfahrungen beim Einsatz des Vorgehensmodells "SCRUM" eines Entwicklerteams von AGFA HealthCare 2 Praktische

Mehr

Agile Methoden ohne Hype

Agile Methoden ohne Hype Agile Methoden ohne Hype Bastian Helfert Torsten Fink akquinet AG Microsoft/.NET 650T EK akquinet AG 1,5 Mio. EK Outsourcing 400T EK Java 400T EK SAP 100T EK International 140T EK Die präagile Zeit Dominanz

Mehr

Agiles Projektmanagement - auch geeignet für Nicht-IT-Projekte? PMI Prof. Dr.-Ing. Holger Günzel 14.09.2012

Agiles Projektmanagement - auch geeignet für Nicht-IT-Projekte? PMI Prof. Dr.-Ing. Holger Günzel 14.09.2012 Agiles Projektmanagement - auch geeignet für Nicht-IT-Projekte? PMI Prof. Dr.-Ing. Holger Günzel Verglühte die Raumfähre Columbia durch einen unflexiblen Projektmanagementprozess? Rückblick: 2003 verglühte

Mehr

Requirements Management mit RequisitePro. Rational in der IBM Software Group. Der Rational Unified Process als Basis für die Projektarbeit

Requirements Management mit RequisitePro. Rational in der IBM Software Group. Der Rational Unified Process als Basis für die Projektarbeit IBM Software Group IBM Rational mit RequisitePro Hubert Biskup hubert.biskup@de.ibm.com Agenda Rational in der IBM Software Group Der Rational Unified Process als Basis für die Projektarbeit mit Rational

Mehr

Test-Driven Developement Eine Einführung

Test-Driven Developement Eine Einführung Test-Driven Developement Eine Einführung 2007 by Tobias Hagen Im Rahmen der Veranstaltung Aktuelle Themen der Informatik bei Prof. Dr. Friedbert Kaspar Hochschule Furtwangen University Übersicht Einführung...

Mehr

Whitepaper. Automatisierte Akzeptanztests mit FIT. Einleitung. Die Bedeutung von Akzeptanztests

Whitepaper. Automatisierte Akzeptanztests mit FIT. Einleitung. Die Bedeutung von Akzeptanztests Automatisierte Akzeptanztests mit FIT Einleitung Dieses beschreibt, wie man Tests aus Anwender-/Kundensicht mit dem Open-Source-Werkzeug FIT beschreibt und durchführt. Das ist für Kunden, Anwender und

Mehr

3.4 Unified Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process.

3.4 Unified Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process. 1996 Philippe Kruchten: Rational Unified Process Produkt der Firma Seit 2002 Teil des IBM Konzerns Objektorientiertes

Mehr

Wasserfall, «Death March», Scrum und agile Methoden. 30.August 2011 Embedded Computing Conference 2011 Urs Böhm

Wasserfall, «Death March», Scrum und agile Methoden. 30.August 2011 Embedded Computing Conference 2011 Urs Böhm Wasserfall, «Death March», Scrum und agile Methoden 30.August 2011 Embedded Computing Conference 2011 Urs Böhm Übersicht Entwicklungsprozess Warum Projektmanagement? Gängige SW Entwicklungsprozesse Wasserfall

Mehr

Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle. Windhoff Software Services GmbH www.wind-soft.

Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle. Windhoff Software Services GmbH www.wind-soft. Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle Folie 2 Agenda Projektmanagement: Ziele und Methoden Agile Methoden: Scrum Agile Methoden im BI Umfeld PM

Mehr

Wir erledigen alles sofort. Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind.

Wir erledigen alles sofort. Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind. Wir erledigen alles sofort Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind. agilecoach.de Marc Bless Agiler Coach agilecoach.de Frage Wer hat

Mehr

Agile Softwareentwicklung - Ein praktisches Beispiel -

Agile Softwareentwicklung - Ein praktisches Beispiel - Agile Softwareentwicklung - Ein praktisches Beispiel - Dr. Dagmar Monett Díaz Berlin, 03.11.2009 D. Monett: Agile Softwareentwicklung Ein praktisches Beispiel Der Softwareentwicklungsprozess Sichtweisen,

Mehr

Scrum technische Umsetzung und kaufmännische Rahmenbedingungen

Scrum technische Umsetzung und kaufmännische Rahmenbedingungen Scrum technische Umsetzung und kaufmännische 9. Darmstädter Informationsrechtstag 2013 Darmstadt, 15. November 2013 Franziska Bierer 2 andrena ojects ag Gründung 1995 Standorte in Karlsruhe und Frankfurt

Mehr

Agile Softwareentwicklung. Yelve Yakut

Agile Softwareentwicklung. Yelve Yakut Agile Softwareentwicklung Yelve Yakut Index Projekte Vorgehensmodelle Agilität Scrum Feature Driven Development 20.05.08 Agile Softwareentwicklung #2 Projektplanung Von 210 Projekten im Zeitraum von 1997

Mehr

Internet Briefing Agile SW-Entwicklung

Internet Briefing Agile SW-Entwicklung 1 www.namics.com Internet Briefing Agile SW-Entwicklung 6. Februar 2007 Peter Stevens, Principal Consultant Bern, Frankfurt, Hamburg, München, St. Gallen, Zug, Zürich Agenda 2 www.namics.com 3 www.namics.com

Mehr

Agiles Projektmanagement. erklärt in 30 Minuten! IT-Forum Agiles Projektmanagement, NIK 29. Juni 2011. Thomas Hemmer

Agiles Projektmanagement. erklärt in 30 Minuten! IT-Forum Agiles Projektmanagement, NIK 29. Juni 2011. Thomas Hemmer Agiles Projektmanagement erklärt in 30 Minuten! IT-Forum Agiles Projektmanagement, NIK 29. Juni 2011 Thomas Hemmer Chief Technology Officer thomas.hemmer@conplement.de conplement AG, Nürnberg 2 conplement

Mehr

Agile Software-Entwicklung: Überblick

Agile Software-Entwicklung: Überblick Agile Software-Entwicklung: Überblick Stefan Diener / Apr 18, 2007 / Page 1 Inhalt Historie Agiles Manifest Agile Prinzipien Agile Methoden Agile SW-Entwicklungsprozesse Stefan Diener / Apr 18, 2007 /

Mehr

Die praktische Bedeutung der verschiedenen Vorgehensmodelle in der Software-Entwicklung

Die praktische Bedeutung der verschiedenen Vorgehensmodelle in der Software-Entwicklung Vorgehensmodelle Seite 1/6 Die praktische Bedeutung der verschiedenen Vorgehensmodelle in der Software-Entwicklung Große Softwareprojekte erwecken oft den Eindruck, dass diese chaotische verlaufen. Und

Mehr

Agilität selbst erfahren. Agile Softwareentwicklung in der Praxis: Jetzt bewerben für das erste Agile Code Camp 2013!

Agilität selbst erfahren. Agile Softwareentwicklung in der Praxis: Jetzt bewerben für das erste Agile Code Camp 2013! Agilität selbst erfahren. Agile Softwareentwicklung in der Praxis: Jetzt bewerben für das erste Agile Code Camp 2013! Sie wollen alles über agile Softwareentwicklung wissen? Wie können Sie agile Methoden

Mehr

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert The Rational Unified Process Eine Einführung von T. Langer und A. Nitert Übersicht Einleitung Probleme der SW-Entwicklung, Best Practices, Aufgaben Was ist der Rational Unified Process? Struktur des Prozesses

Mehr

Agile Softwareentwicklung mit Scrum

Agile Softwareentwicklung mit Scrum Agile Softwareentwicklung mit Scrum Einführung und Überblick zum agilen Softwareentwicklungsprozess Scrum März 2006 Robert Schmelzer, DI(FH) E-Mail: robert@schmelzer.cc Web: http://www.schmelzer.cc Einführung

Mehr

V-Methode, RUP, Waterfall oder was?

V-Methode, RUP, Waterfall oder was? 5. Bayerischer IT-Rechtstag am 26. Oktober 2006 auf der SYSTEMS 2006 in München Übersicht über die verschiedenen Vorgehensmodelle Dr. Sarre & Schmidt EDV-Sachverständige, München Öffentlich bestellter

Mehr

1 Einleitung. 1.1 Unser Ziel

1 Einleitung. 1.1 Unser Ziel 1 Dieses Buch wendet sich an alle, die sich für agile Softwareentwicklung interessieren. Einleitend möchten wir unser mit diesem Buch verbundenes Ziel, unseren Erfahrungshintergrund, das dem Buch zugrunde

Mehr

Leuchtfeuer. Hinter den Kulissen der Scrum Transformierung der Allianz Deutschland

Leuchtfeuer. Hinter den Kulissen der Scrum Transformierung der Allianz Deutschland Leuchtfeuer Hinter den Kulissen der Scrum Transformierung der Allianz Deutschland Gliederung Über die Allianz Wie führen wir Scrum ein? Wie haben wir begonnen? Techniken und Praktiken Change-Management

Mehr

Agile Softwareentwicklung

Agile Softwareentwicklung Agile Softwareentwicklung Werte, Konzepte und Methoden von Wolf-Gideon Bleek, Henning Wolf 2., aktualisierte und erweiterte Auflage Agile Softwareentwicklung Bleek / Wolf schnell und portofrei erhältlich

Mehr

Software Engineering. Prozessmodelle zur Softwareentwicklung

Software Engineering. Prozessmodelle zur Softwareentwicklung Software Engineering Prozessmodelle zur Softwareentwicklung Die Inhalte der Vorlesung wurden primär auf Basis der jeweils angegebenen Literatur erstellt. Darüber hinaus finden sich ausgewählte Beispiele

Mehr

Kapitel 1 Software-Prozessmodelle

Kapitel 1 Software-Prozessmodelle Kapitel 1 Software-Prozessmodelle Ein Software-Prozessmodell ist ein Modell für die Entwicklung eines Software-Systems. Da Modellbildung immer auch Abstraktion beinhaltet, geht es nicht um die Darstellung

Mehr

Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer

Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer Wasserfall vs. Agile: Eine Erfolgsstory 2 Umsetzung agiler Prinzipien Entwicklungsprozess 2009 30.6% 13.4% 20.6% 35.4% Agil Iterativ

Mehr

3 Projektmanagement. Auch hier lassen sich wieder grob kommerzielle und nicht kommerzielle Projekte unterscheiden.

3 Projektmanagement. Auch hier lassen sich wieder grob kommerzielle und nicht kommerzielle Projekte unterscheiden. 3 Projektmanagement Das Thema Projektmanagement kann man aus sehr unterschiedlichen Perspektiven angehen. Klar strukturiert mit Netzplänen und Controlling- Methoden oder teamorientiert mit Moderationstechniken

Mehr

Agile Entwicklung nach Scrum

Agile Entwicklung nach Scrum comsolit AG Hauptstrasse 78 CH-8280 Kreuzlingen Tel. +41 71 222 17 06 Fax +41 71 222 17 80 info@comsolit.com www.comsolit.com Agile Entwicklung nach Scrum Seite 1 / 6 Scrum V 1.0 1. Wieso Scrum Die Entwicklung

Mehr

Projektplanung für Softwareprojekte: KLIPS 2.0 Prof. Dr. Manfred Thaller WS 2011/12 3.11.2011 Dana Wroblewski

Projektplanung für Softwareprojekte: KLIPS 2.0 Prof. Dr. Manfred Thaller WS 2011/12 3.11.2011 Dana Wroblewski Projektplanung für Softwareprojekte: KLIPS 2.0 Prof. Dr. Manfred Thaller WS 2011/12 3.11.2011 Dana Wroblewski 1. Was heißt Agil 2. Scrum? Grundbegriffe 3. Wer benutzt Scrum 4. Vorteile & Nachteile von

Mehr

Was fehlt Scrum? 31. März 2014 Erich Oswald CTO Ergon Informatik AG

Was fehlt Scrum? 31. März 2014 Erich Oswald CTO Ergon Informatik AG Was fehlt Scrum? 31. März 2014 Erich Oswald CTO Ergon Informatik AG Scrum ist eine Erfolgsstory Aus der Praxis entstanden Nachweislich erfolgreich Gut geeignet für komplexe Probleme Produktentwicklung

Mehr

ZuuL - Entwicklung eines Adventures

ZuuL - Entwicklung eines Adventures ZuuL - Entwicklung eines Adventures im Rahmen der Uni-Tage 2009 Team 120 Universität Hamburg 16./17. November 2009 Team 120 (Universität Hamburg) ZuuL - Entwicklung eines Adventures 16.11.09 1 / 21 Übersicht

Mehr

extreme Programming (XP)

extreme Programming (XP) Softwaretechnik SS2005 Tobias Giese Masterstudiengang Informatik HS-Harz Agenda Allgemeines Vorgehensmodell Kommunikation und Arbeitsphilosophie Entwicklungsphasen / Extreme Rules Planung Entwurf Implementierung

Mehr

Agile Softwareentwicklung mit SCRUM

Agile Softwareentwicklung mit SCRUM Agile Softwareentwicklung mit SCRUM PMI MUC 01. März 2010 Referent: Gerhard Held mehr als 35 Berufsjahre in der Softwareentwicklung im Projektmanagement und verwandten Themen... Gründe für das Scheitern

Mehr

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander?

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander? INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung Rütistrasse 9, Postfach 5401 Baden, Switzerland Phone: +41 56 222 65 32 Internet: www.infogem.ch Robust und Agil gegeneinander oder miteinander?

Mehr

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16 Probeklausur Lenz Belzner January 26, 2015 Lenz Belzner Probeklausur January 26, 2015 1 / 16 Definieren Sie Software Engineering in Abgrenzung zu Individual Programming. Ingenieursdisziplin professionelle

Mehr

Agile Softwareentwicklung. Referat von Kristina Schrickel Praxisprojekt Ruby Leitung : Ralf Berger

Agile Softwareentwicklung. Referat von Kristina Schrickel Praxisprojekt Ruby Leitung : Ralf Berger Agile Softwareentwicklung Referat von Kristina Schrickel Praxisprojekt Ruby Leitung : Ralf Berger Inhalt 1. Klassische Entwicklungstechnik 2. Agile Entwicklungstechnik - Allgemeines 3. Agiles Manifest

Mehr

Scrum. Agile Software Entwicklung mit. Agile Software Entwicklung mit. Scrum. Raffael Schweitzer 18. November 2003

Scrum. Agile Software Entwicklung mit. Agile Software Entwicklung mit. Scrum. Raffael Schweitzer 18. November 2003 Agile Software Entwicklung mit Raffael Schweitzer 18. November 2003 Agenda Einleitung Was ist? Wie funktioniert? Einsatzbereiche Erfolgsfaktoren Fazit Agenda Einleitung Was ist? Wie funktioniert? Einsatzbereiche

Mehr

Agile Softwareentwicklung mit Scrum

Agile Softwareentwicklung mit Scrum Informatik Gregor Liebermann Agile Softwareentwicklung mit Scrum Referent: WiSe 2015 Gregor Liebermann M.Sc. www.hs-augsburg.de Überblick Aufbau der Vorlesung Montags 15:40 18:40 5 CP Aufteilung in Vorlesung

Mehr

Extreme Programming (XP)

Extreme Programming (XP) Einführung in Extreme Programming 1 Extreme Programming (XP), wolf@jwam.de Martin Lippert, lippert@jwam.de Stefan Roock, roock@jwam.de Universität Hamburg & APCON Workplace Solutions GmbH Vogt-Kölln-Strasse

Mehr

PM-Forum Augsburg. Thomas Müller-Zurlinden, PMP 18.05.2012. Kontakt: Info@QinS.de

PM-Forum Augsburg. Thomas Müller-Zurlinden, PMP 18.05.2012. Kontakt: Info@QinS.de PM-Forum Augsburg Thomas Müller-Zurlinden, PMP 18.05.2012 Kontakt: Info@QinS.de Einführung in die Konzepte der Software Product Line Organisation einer globalen SPL Entwicklung SPL und die Herausforderungen

Mehr