Extreme Programming. Eine Übersicht und Bewertung. Reihe A: Discussion Paper ISBN: Rolf Dornberger Thomas Habegger

Größe: px
Ab Seite anzeigen:

Download "Extreme Programming. Eine Übersicht und Bewertung. Reihe A: Discussion Paper 2004-05 ISBN: 3-03724-067-9. Rolf Dornberger Thomas Habegger"

Transkript

1 Reihe A: Discussion Paper ISBN: Extreme Programming Eine Übersicht und Bewertung Rolf Dornberger Thomas Habegger Dezember 2004 Fachhochschule Solothurn Nordwestschweiz und der Autor. Jede Reproduktion, auch von Teilen und unabhängig vom Medium, ist nur mit Genehmigung der Fachhochschule Solothurn Nordwestschweiz und des Autors gestattet.

2

3 Fachhochschule Solothurn Nordwestschweiz Die Fachhochschule Solothurn Nordwestschweiz bildet im Bereich Wirtschaft Betriebsökonominnen und Betriebsökonomen FH mit den Vertiefungsrichtungen Controlling, Human Resource Management, Marketing sowie Informations- und Wissensmanagement aus. Daneben bietet sie ein Vollzeitstudium mit Abschluss Wirtschaftsinformatikerin bzw. Wirtschaftsinformatiker FH an. Ihr ist auch die Höhere Fachschule für Wirtschaftsinformatik mit einem berufsbegleitenden Ausbildungsgang angeschlossen. Im Bereich Technik stehen die Studiengänge Informatik und Telekommunikation, Elektronik und Automation (Wahlmöglichkeiten für die Vertiefung in Richtung Elektronik/ Signalverarbeitung oder Regeltechnik/Automation) sowie Maschinen- und Betriebstechnik (Vertiefungsrichtung Organisationslehre, Wahlpflicht-Richtungen Betriebsmittel- und Anlagenkonstruktion oder Logistik und Betriebsinformatik) zur Auswahl. Der Bereich Soziales bietet den Studiengang Soziale Arbeit mit den möglichen Studienschwerpunkten Beratung, Prävention und soziales Lernen sowie Sozialplanung und Sozialmanagement an. Die FHSO ist renommiert für das breite Weiterbildungsangebot, welches von Fachtagungen über Fachkurse und Berufsprüfungsvorbereitungen bis hin zu Nachdiplomstudiengängen reicht. Erwähnenswert sind die Nachdiplomstudiengänge für Nonprofitorganisationen, für Logistik, für Corporate Design Management, Corporate Communication Management und das Schweizerische Nachdiplomstudium für Personalmanagement. Die FHSO ist unter anderem aktiv in verschiedensten wirtschaftswissenschaftlichen Forschungsgebieten. Die wichtigsten Schwerpunkte der Forschungsaktivitäten sind Unternehmertum, Innovation und strategisches Management, Human Resource Management, Soziale Arbeit, Elektronik und Automation sowie Informations- und Wissensmanagement. Die Ergebnisse werden beispielsweise in der vorliegenden Publikationsreihe und an Forschungsseminaren vorgestellt. Publikationsreihe Die Fachhochschule Solothurn Nordwestschweiz veröffentlicht in dieser Reihe Forschungsarbeiten ihrer Mitarbeitenden. Mit diesen Publikationen sollen die Fachkollegen und die interessierte Öffentlichkeit über die Forschungstätigkeiten und deren Ergebnisse informiert werden. Beachten Sie die Liste der verfügbaren Publikationen und die Bestelladresse am Schluss dieses Hefts. Fachhochschule Solothurn Nordwestschweiz, Reihe A: Discussion Paper iii

4 Management Summary Softwareprojekte nehmen immer größere und komplexere Dimensionen an. Als Folge davon kann sehr oft nur schwerfällig oder mit hohem Kostenaufwand auf veränderte Kundenwünsche und ein dynamisches Geschäftsumfeld reagiert werden. Zudem werden die vier bei Softwareprojekten entscheidenden Variablen Kosten, Zeit, Qualität und Umfang oft in einer für die Kundschaft unbefriedigenden Weise erfüllt. Das Festhalten an klassischen Vorgehensmodellen der Softwareentwicklung ist oftmals der geforderten Flexibilität in heutigen Softwareprojekten nicht mehr dienlich. Die traditionellen Vorgehensweisen möchten alle Anforderungen im Voraus planen, was sehr oft das Scheitern verursacht. Neue, agile Entwicklungsmethoden und, daraus abgeleitet, Extreme Programming (auch XP genannt) sollten in den letzten Jahren die Softwareentwicklung erfolgreicher gestalten. Auf der einen Seite stehen die überaus begeisterten XP- Anwender und -Anwenderinnen, auf der anderen stehen diejenigen, welche XP nur als interessante Ideologie oder als Marketingtrend betrachten, die sich in der Praxis aber als nicht realisierbar erweisen. Oft wird die Meinung vertreten, XP sei nur eine Hervorhebung oder leichte Umgruppierung bereits bestehender Arbeitsmethoden und somit nichts Revolutionäres. Ziel dieses Berichts ist es, Philosophie und Verfahren von Extreme Programming vorzustellen und von den traditionellen Softwareentwicklungsmethoden abzugrenzen. Grundwerte, Prinzipien und Rollenverteilung werden beleuchtet und die drei Kernprozesse von XP (Planung, Programmierung und Design) beschrieben. Die Fragen nach Stärken und Schwächen von XP, nach den benötigten Rahmenbedingungen und nach den Bedingungen, unter denen dieses Entwicklungsvorgehen ungeeignet ist, werden untersucht. Information über den Einsatz und die Verbreitung von XP in der Praxis (Firmen, Projekte, User-Groups, Konferenzen) werden vorgestellt. In diesem Bericht zeigen wir, dass trotz des Attributes extrem XP nicht so radikal ist, wie man meinen könnte. Einzelne Konzepte wie automatisierte Tests oder Refactoring könnten problemlos in eine vorhandene Projektkultur eingebaut werden. XP bedeutet keinen Rückschritt zu den Anfängen der Software-Engineering-Kultur, sondern verwendet die best practice von heute und versucht, den überflüssigen Ballast im Entwicklungsprozess und Projektvorgehen zu vermeiden. Auf den ersten Blick besticht XP durch seine Vorteile. Die Kunden erhalten in regelmäßigen Abständen den aktuellen, getesteten Entwicklungsstand ausgeliefert. Darauf aufbauend dürfen sie zudem das weitere Vorgehen festlegen. Weder führen Anforderungsänderungen zu weiteren Kosten, noch verärgern sie die Entwickler. Die Programmierer ihrerseits müssen sich strikt an Standards halten. Wenn XP die einzelnen Entwickler nicht überfordert, wird einfacher, wartbarer und getesteter Code erzeugt, was dem Wunsch aller Beteiligten entsprechen dürfte. Auf den zweiten Blick wird jedoch recht schnell deutlich, dass XP eine Menge an Zugeständnissen, Erwartungen und Fähigkeiten von den Entwicklern und Kunden abverlangt und dass gewisse Behauptungen von XP erst mit fundierten Daten und Langzeitbeobachtungen erhärtet werden müssen. Basierend auf diesem Bericht lässt sich sagen, dass XP mit seinen Techniken unbedingt ins Portfolio aller Softwareentwickler gehören sollte, damit diese XP oder gewisse Aspekte von XP bei Bedarf einsetzen können. Dazu gehört aber viel Erfahrung in der Softwareentwicklung, um zu erkennen, wann XP hilft und wann nicht. Wie stark sich XP letztendlich durchsetzen wird, lässt sich bis heute nicht ohne weitere empirische Untersuchungen beantworten. Und selbst wenn XP auf die Dauer eine Nischenstellung einnehmen sollte, ermuntert es die an der Softwareentwicklung Beteiligten, ihr bisheriges Handeln zu hinterfragen und möglicherweise Konsequenzen einzuleiten. Es bleibt die Hoffnung, dass die Aufmerksamkeit auf XP auch dazu beiträgt, sein extremes Konzept zu einem universaleren Verfahren weiterzuentwickeln. iv Fachhochschule Solothurn Nordwestschweiz, Reihe A: Discussion Paper

5 Autoren Prof. Dr.-Ing. Rolf Dornberger ist Professor für Wirtschaftsinformatik an der Fachhochschule Solothurn Nordwestschweiz (FHSO), Schweiz. Er engagiert sich in der Lehre und Forschung in den Bereichen Software-Engineering, Programmierung, Web- Technologien, Innovationsmanagement und Wirtschaftsinformatik sowie im gezielten Wissenstransfer zwischen Hochschule, Industrie und Wirtschaft. Zuvor war er mehrere Jahre in der Industrie an verschiedenen Forschungs- und Technologiezentren in leitenden Funktionen tätig. Sein Studium der Luft- und Raumfahrttechnik und seine Promotion über numerische Simulationen absolvierte er in Stuttgart (Deutschland), Barcelona (Spanien) und Grenoble (Frankreich). Thomas Habegger schloss das Studium der Wirtschaftsinformatik an der Fachhochschule Solothurn Nordwestschweiz (FHSO), Schweiz, im Herbst 2004 ab. Während des Studiums vertiefte er sich unter anderem im Rahmen des Seminars Aktuelle Themen der Wirtschaftsinformatik in das Themengebiet Extreme Programming. Fachhochschule Solothurn Nordwestschweiz, Reihe A: Discussion Paper v

6 Inhaltsverzeichnis 1 Einleitung Entstehung und Ursprung von Extreme Programming Klassifikation von Softwareentwicklungsmethoden Softwareentwicklung ohne Methode Methodische Softwareentwicklung Eigenschaften der klassischen Methoden Eigenschaften der agilen Methoden Einordnung von Extreme Programming Theorie und Paradigmen des Extreme Programming Übersicht über Extreme Programming Die vier Variablen eines Projekts in XP Kosten Qualität Zeit Umfang Die vier Werte des XP Kommunikation Einfachheit Feedback Mut Weitere Werte Die XP-Prinzipien Primäre Prinzipien Sekundäre Prinzipien Rollen in einem XP -Projekt Kunde (Customer) Entwickler bzw. Programmierer (Programmer) Coach Terminmanager (Tracker) Projektmanager (Project Manager) Tester Berater (Consultant) Projekteinteilung bei XP...16 vi Fachhochschule Solothurn Nordwestschweiz, Reihe A: Discussion Paper

7 Release Iteration Planung Releases in kurzen Abständen Das Planungsspiel (The Planning Game) Das tägliche Stand-up-Meeting Gemeinsame Sprache und Metaphern Planungsfehler/Keine Überstunden/40-Stunden-Woche Entwicklung Design Einfaches Design Refactoring Metapher im Design Programmieren Programmieren in Paaren (Pair-Programming) Kunde vor Ort (On-Site-Customer) Gemeinsame Codeverantwortung (Collective Codeownership) Programmierstandards Kontinuierliche Integration Dokumentation Testen Unit-Test Akzeptanztest Praxisanwendung und Evaluation von XP Wann ist XP ungeeignet? Übersicht über den Einsatz von Extreme Programming Bekannte XP-Projekte WyCash Daimler Chrysler: C Ford Motor Company: VCAPS Weitere Projekte Firmen XP-User-Groups, XP-Communities und XP -Konferenzen Quantitative Studie XP Visek-Projekt (Technische Universität München) Kernaussagen der Studie Fachhochschule Solothurn Nordwestschweiz, Reihe A: Discussion Paper vii

8 Beschreibung der untersuchten Firmen Beschreibung der untersuchten Projekte Gründe für die Auswahl von XP als Projektvorgehen Am wenigsten genutzte XP -Elemente Kritische Erfolgsfaktoren und Risiken bei XP Pair-Programming-Studie (Universität Utah) Kritische Betrachtung von XP Kostenänderungskurve Rollenverständnis Kunde Entwickler Projektmanager Planung Kleine Releases Planning Game Entwicklung Kunde vor Ort Pair-Programming Gemeinsame Codeverantwortung Refactoring und einfaches Design Dokumentation Verbindlichkeit und Abstimmungen Schlussbetrachtung und Ausblick Schlussbetrachtung Ausblick Anhang Literatur- und Quellenverzeichnis Glossar Liste von Firmen, die XP anwenden Liste von XP-User-Groups Liste von XP-Communities Liste von XP-Konferenzen...44 Bisher erschienen:...45 viii Fachhochschule Solothurn Nordwestschweiz, Reihe A: Discussion Paper

9 Einleitung 1 Einleitung Der vorliegende Bericht behandelt Extreme Programming (XP) in vier Kapiteln. Kapitel 1 (Einleitung) führt an das Thema heran, indem XP im Vergleich zu klassischen und agilen Methoden der Softwareentwicklung eingeordnet wird. Die Entstehung und das Umfeld von XP werden untersucht. Die wichtigsten Themen im Umfeld von XP, wie die Änderungen von Anforderungen innerhalb eines Projekts und die daraus resultierenden Kosten sowie der Einfluss auf das Planungsverhalten, werden erläutert. Kapitel 2 (Theorie und Paradigmen des Extreme Programming) enthält eine Darstellung der Variablen eines Projekts in XP sowie der Werte, Prinzipien und Rollen von XP. Zudem werden die Kernprozesse Planung und Entwicklung in XP vorgestellt. Kapitel 3 (Praxisanwendung und Evaluation von XP) analysiert die notwendigen Rahmenbedingungen, die für einen erfolgreichen Einsatz von XP gegeben sein müssen. Nebst Praxisbeispielen von bekannten Projekten wird die Verbreitung von XP in Firmen, soweit möglich, aufgezeigt. Verschiedene XP -User-Groups und XP-Konferenzen werden vorgestellt. Zwei wissenschaftliche Studien werden erläutert, und verschiedene XP -Verfahren kritisch untersucht. Mit Kapitel 4 (Schlussbetrachtung und Ausblick) kommen wir zur kritischen Würdigung der Ideen und der Praxisrelevanz des Themas XP. Zudem wagen wir einen Blick in die Zukunft und zeigen mögliche Trends auf. 1.1 Entstehung und Ursprung von Extreme Programming Warum wurde Extreme Programming entwickelt? Aufgrund welcher Problematik und in welchem Umfeld entstand seine Ideologie? Dies sind die Fragen des ersten Kapitels. Bei der traditionellen Softwareentwicklung galt die allgemeine Annahme, dass die Kunden einmal und eindeutig erklären, welche Wünsche sie haben und was sie brauchen. Die Software wurde dann mit sämtlichen Funktionen entwickelt, und dies zur vollkommenen Zufriedenheit von Kunde und Entwickler. Bei der traditionellen Softwareentwicklung ging man von einem vorhersagbaren Prozess mit festem, von Anfang bis Ende festgelegtem Ablauf des Projektes aus, wobei alle Phasen detailliert protokolliert wurden. Folgende Probleme traten beim traditionellen Ansatz auf: Da die Kunden oftmals ihre Meinung bezüglich Anforderungen änderten und die Entwickler sich in gewissen Belangen irrten, kam einerseits die Software meist teurer zu stehen als geplant, und die Kunden erhielten nicht das, was sie sich erhofft hatten (vgl. Jansen, Schmitt 2003). Die traditionellen Vorgehensmodelle hatten ihren Ursprung in den Ingenieurwissenschaften. Dabei blieb aber ein wesentlicher Unterschied gegenüber der Informatik unberücksichtigt, was mit folgendem Vergleich verdeutlicht sein soll: Eine einmal konstruierte Rheinbrücke bleibt auch in den kommenden Jahren eine Rheinbrücke. Weder verändert sich der Flusslauf noch wird aus einer Eisenbahnbrücke eine Startbahn für ein Passagierflugzeug. Bei der Softwareentwicklung stellt sich der Sachverhalt ganz anders dar. Gerade in einem stark dynamischen Umfeld sind die einst erhobenen Anforderungen sehr schnell überholt. Das Schlüsselwort lautet hier Flexibilität (zum Teil wird auch der Begriff Agilität verwendet). Dieser Erkenntnis versucht das XP nun gerecht zu werden. Fachhochschule Solothurn Nordwestschweiz, Reihe A: Discussion Paper

10 Einleitung Softwareentwicklungsprojekte wurden immer komplexer, und die Gefahr des Scheiterns nahm zu. Dieses Phänomen wurde Mitte der Sechzigerjahre mit dem Begriff Softwarekrise bezeichnet. Folgende Risiken traten vermehrt in den Vordergrund: Terminverzögerungen: Projekte können nicht termingerecht abgeschlossen werden. Das klassische Projektmanagement ist nicht in der Lage, mit den in der Softwareentwicklung auftretenden technischen, sozialen und ressourcenbedingten Aspekten ein fristgerechtes Fertigstellen der Software zu garantieren. Projektabbruch: Nach mehreren Terminverzögerungen und damit verbundenen Budgetüberschreitungen wird das Projekt abgebrochen. Es zeichnet sich ab, dass die entstehende Software kein akzeptables Kosten-Nutzen-Verhältnis bieten wird. Fehlerrate: Die neue Software soll in Betrieb genommen werden, weist aber eine so hohe Fehlerrate auf, dass sie nicht verwendet werden kann. Die Software wird folglich doch nicht eingesetzt; und das alte System muss soweit möglich noch den Betrieb aufrechterhalten. System wird unrentabel: Fehlerrate oder Änderungskosten der in Betrieb genommenen Software steigen so hoch an, dass das System schneller ausgetauscht werden muss, als ursprünglich angenommen. Geschäftsprozesse falsch verstanden: Bei der Analyse der Benutzeranforderungen und Spezifikation der zu entwickelnden Software wurden die zu unterstützenden Geschäftsprozesse ungenügend abgebildet. Die Software löst das ursprüngliche Problem nicht. Der Kunde ist unzufrieden. Geschäftsprozesse ändern sich: Bei der Analyse der Benutzeranforderungen und Spezifikation der zu entwickelnden Software wurde nicht ausreichend beachtet, dass sich die zu unterstützenden Geschäftsprozesse ändern. Die Software löst nach einer gewissen Zeit das ursprüngliche Problem nicht mehr. Der Kunde wird unzufrieden. Problem ist auch bekannt als moving target. Je nach Dauer der Softwareentwicklung und Änderungsgeschwindigkeit der Geschäftsprozesse kann dies sogar noch vor Fertigstellung der Software auftreten. Falsche Funktionsfülle: Es werden viele Funktionen eingebaut, die dem Kunden keinen rechten Nutzen bringen. Die verlängert die Entwicklungszeit, verteuert damit die Softwareentwicklung, macht die Software wartungsunfreundlicher und wird letztendlich vom Kunden meist nicht gewürdigt. Personalwechsel: Aufgrund eines schlechten Projektmanagements und damit einhergehender Missstimmung im Team werden im Allgemeinen alle guten Programmierer des Projekts nach spätestens zwei Jahren überdrüssig und kündigen. Zu allen diese Risiken versucht XP eine Gegenmaßnahme zu bieten (vgl. Beck 2003: 3). Der Ursprung von XP liegt im Daimler Chrysler-Projekt Chrysler Consolidated Compensation. Ziel dieses Projekts war der Aufbau eines internen Abrechnungssystems. Nachdem bei der Entwicklung des Projekts massive Probleme aufgetreten waren, wurden Kent Beck, Ron Jeffries und Martin Fowler angestellt, um das Projekt wieder unter Kontrolle zu bringen. Sie haben ihre 2 Fachhochschule Solothurn Nordwestschweiz, Hochschule für Wirtschaft, Discussion Paper

11 Einleitung Erfahrungen hierzu später in verschiedenen Büchern veröffentlicht. Die Wurzeln von XP liegen in der Tradition und Kultur von Smalltalk, einer objektorientierten Programmiersprache (vgl. Bögli 2003). Am 31. Dezember 1999 wurde eine Yahoo-Group zum Thema XP gegründet. Im Juni 2000 führte man die erste internationale XP -Konferenz in Sardinien durch. Die Agile Software Development Alliance, welche das Manifest für agile Softwareentwicklung verfasst hat, entstand im Jahre 2001 (vgl. Wasserberg 2003). XP kann als leichtgewichtige, agile Softwareentwicklungsmethode verstanden werden. Dabei wird mit XP nicht der genaue Ablauf eines Projektes geregelt, sondern eine Menge von Aktivitäten festgelegt, über deren Abfolge und Einsatz die Entwickler situativ variabel verfügen können. 1.2 Klassifikation von Softwareentwicklungsmethoden Um XP besser verstehen zu können, betrachten wir im Folgenden zunächst die Klassifikation der Softwareentwicklungsmethoden. Diese unterteilen sich in solche mit und solche ohne Methode. Die Entwicklungsmethoden mit Methode werden wieder unterteilt in klassische und agile Methoden, wie Abbildung 1 zeigt. Softwareentwicklung Softwareentwicklung ohne Methode Methodische Softwareentwicklung Klassische Methoden Agile Methoden Abbildung 1: Klassifikation der Softwareentwicklungsmethoden Die Anforderungen an ein System machen das zentrale Element jeder Softwareentwicklung aus. In ihnen spiegeln sich die Erwartungen der Kunden. Der Erfolg des Projektes lässt sich am besten am Erfüllungsgrad der Anforderungen messen. Wegen der zentralen Bedeutung der Anforderungen hat jedes Vorgehen zur Softwareentwicklung, ob methodisch oder nicht, eine eigene Art, mit Anforderungen umzugehen (vgl. Bögli 2003) Softwareentwicklung ohne Methode Softwareentwicklung ohne Methode wird oft auch als reines Hacking oder Code & Fix bezeichnet und steht und fällt mit der Erfahrung der Entwickler. Dieses Vorgehen wird meist von unerfahrenen Softwareentwicklern eingesetzt. Sie haben das Gefühl, jede neue Benutzeranforderung bzw. jeder Teilanforderung erst einmal in Programmcode umsetzen zu müssen, um schon eine gewisse Substanz an Programmcode zu haben. Der Programmcode wird, um Zeit zu Fachhochschule Solothurn Nordwestschweiz, Reihe A: Discussion Paper

12 Einleitung sparen, allerdings nur ganz beschränkt getestet. Ebenso wird auf das Kommentieren weitgehend verzichtet. Die Überlegungen zur programmtechnischen Umsetzung finden nur im Kopf eines einzelnen Programmierers statt. Die Folge ist, dass das Programm für andere, und meist auch nach kurzer Zeit für den Programmierer selbst, unverständlich und nicht erweiterbar wird. Im Endeffekt ist das Programm nur für einen einzigen, sich nicht ändernden Spezialfall einsetzbar, wenn überhaupt. Dieses Vorgehen wird wegen seiner begrenzten Erfolgsaussichten, gerade in mittleren bis größeren Softwareprojekten, hier nicht näher ausgeführt Methodische Softwareentwicklung Die methodische Softwareentwicklung wird heute in folgende zwei Kategorien aufgeteilt: Auf der einen Seite stehen die klassischen und auf der anderen die agilen Methoden. Der Hauptunterschied besteht in der Planbarkeit der Entwicklung. Im Zentrum der klassischen Methoden liegt das Ziel, den Ablauf der Entwicklung so gut wie möglich planbar zu machen, damit man sich dann möglichst an den Plan halten kann. Die agilen Methoden ermöglichen es andererseits, auf Unvorhergesehenes flexibel zu reagieren. Die Planbarkeit und die Stabilität der Anforderungen beeinflussen deshalb maßgeblich die Wahl der Entwicklungsmethode (vgl. Bögli 2003) Eigenschaften der klassischen Methoden Beispiele für klassische Methoden sind Wasserfallmodell, V-Modell, ergebnisorientiertes Phasenmodell, Wachstumsmodell, Spiralmodell und objektorientiertes Vorgehensmodell. Allen klassischen Methoden ist gemeinsam, dass die Softwareentwicklung in eine Folge von Tätigkeiten aufgeteilt wird, während denen gewisse Ergebnisse erarbeitet werden. Es kann sein, dass die Methoden die Tätigkeiten nur einmal vorsehen oder dass diese iterativ wiederholt werden. Jedenfalls gilt für alle klassischen Methoden, dass sie im Gesamtablauf eine Abfolge von wenigen Phasen beschreiben. Beim Wasserfallmodell sind dies beispielsweise Systemdefinition, Anforderungen, Konzipierung und Realisierung (vgl. Kauflin 2003). Der zeitlich große Abstand zwischen der Anforderungsanalyse sowie der Fertigstellung und Einführung der Software stellt dabei das Hauptproblem dar. Zudem lassen die klassischen Methoden nur noch in beschränktem Maße ein unmittelbares Feedback der Kunden während der Softwareentwicklung zu. Im Allgemeinen werden die Anforderungen detailliert analysiert und präzise dokumentiert. Rechtlich gesehen möchten sich beide Parteien, Auftraggeberschaft und Auftragnehmerschaft, also Kunden und Softwareentwickler, mit dieser möglichst genauen Beschreibung auch vertraglich absichern. Dennoch besteht das allgemein bekannte Problem bei der Softwareentwicklung, dass schließlich zur Unzufriedenheit aller ein System abgeliefert wird, das nur den Anforderungen der Vergangenheit genügt und die aktuellen Bedürfnisse nicht berücksichtigt (vgl. Bögli 2003). Die Metapher für die klassischen Methoden ist die Mondrakete, bei welcher der Kurs bereits vor dem Start feststeht und während der Reise nur noch geringfügig und mit großem Aufwand geändert werden kann. 4 Fachhochschule Solothurn Nordwestschweiz, Hochschule für Wirtschaft, Discussion Paper

13 Einleitung Eigenschaften der agilen Methoden Beispiele für agile Methoden sind Extreme Programming (XP), Scrum, Crystal, Feature Driven Development (FDD), Rational Unified Process (RUP), Dynamic Systems Development Method (DSDM), Adaptive Software Development (ASD), XBreed, Agile Modelling, Pragmatic Programming, Lean Programming, Test Driven Development und Open Source Software Development (vgl. Kauflin 2003 und Fowler 2003). Bei den agilen Methoden wird die Zusammenarbeit mit dem Kunden höher gewichtet als das Aushandeln eines Vertrages. Zugunsten einer höheren Flexibilität wird auf eine bis ins Detail ausgefeilte Anforderungsanalyse verzichtet. XP löst dieses Problem beispielsweise mittels einfacher User-Stories (vgl. Bögli 2003). Manche agilen Methoden, wie z.b. Rational Unified Process (RUP), beschreiben den Gesamtablauf der Softwareentwicklung ähnlich wie klassische Methoden durch eine Abfolge von wenigen Phasen. Im RUP sind dies Inception, Elaboration, Construction und Transition. Andere agile Methoden, wie z.b. Extreme Programming, arbeiten eher mit Werten, Variablen und Prinzipien. Wichtigstes Ziel agiler Entwicklungsmethoden ist es aber, dem Kunden möglichst schnell Nutzen zu erbringen, wobei primär nur die wichtigsten Funktionalitäten erstellt werden. In den weiteren Iterationszyklen kommen dann die zusätzlichen Funktionen ergänzend hinzu. Zur Illustration der Philosophie agiler Methoden sei hier das Manifest für agile Softwareentwicklung angeführt, welches 2001 von der Agile Software Development Alliance entwickelt worden ist (vgl. Westphal 2001): Wir zeigen bessere Wege zur Softwareentwicklung auf, indem wir Software entwickeln und anderen dabei helfen. Wir bevorzugen Menschen und Zusammenarbeit vor Prozessen und Werkzeugen Funktionierende Software vor umfassender Dokumentation Zusammenarbeit mit dem Kunden vor vertraglicher Verhandlung Reaktion auf Veränderung vor Einhaltung eines Plans Das heißt, während die Punkte auf der Rechten wertvoll sind, wertschätzen wir die Punkte auf der Linken mehr Einordnung von Extreme Programming Bei der Klassifizierung der Vorgehensmodelle begegnet man nebst den Begriffen klassische und agile Methoden auch den Begriffen leicht- und schwergewichtige Prozesse. Bei den leichtgewichtigen Prozessen wird alles weggeworfen, was seinen Nutzen für das Projekt verloren hat; bei den schwergewichtigen wird alles nach Plan durchgeführt. XP ist den agilen Methoden und den leichtgewichtigen Vorgehensmodellen zuzurechnen (vgl. Dicke 2002). Abbildung 2 zeigt, wie leicht- und schwergewichtige Entwicklungsmethoden auf einem Spektrum ansteigender Planungsorientierung angesiedelt werden können. Das linke Ende besteht aus dem Extremum eines planlosen, undisziplinierten Hackens. Danach kommen verschiedenste agile Methoden, dann klassische Methoden, die sowohl meilenstein- und risikogesteuert als auch meilenstein- und plangetrieben sein können. Das rechte Ende repräsentiert das streng prozessorientierte Vorgehen über feingranulare Verträge. Der Übergangsbereich zwischen agilen und klassischen Methoden bleibt aber flexibel. In der Abbildung wird klar erkennbar, dass Extreme Programming nicht mit planlosem Ad-hoc-Vorgehen gleichzusetzen ist, wenn es auch am unteren Ende der agilen Methoden steht (vgl. Wasserberg 2003). Fachhochschule Solothurn Nordwestschweiz, Reihe A: Discussion Paper

14 Einleitung Extreme Programming Ad hoc ( Hacken ) meilenstein- und risikogesteuert Feingranulare Verträge (Bsp. V-Modell) meilenstein- und plangetrieben Agile Methoden Klassische Methoden Abbildung 2: Planungsspektrum mit ansteigender Planungsorientierung Um die Flexibilität von Extreme Programming gegenüber sich ändernden Anforderungen zu zeigen, wird oft die Metapher vom Autofahren verwendet. Beim Autofahren ist es notwendig, ständig die Aufmerksamkeit auf Strasse und Umwelt zu richten, um auf unvorhergesehene Ereignisse möglichst adäquat und schnell reagieren zu können. Genauso sollte der Programmierer das Projekt nicht aus den Augen lassen, um möglichst geringe Reaktionszeiten zu erzielen. Kein Autofahrer würde behaupten, eine Fahrt von A nach B komplett im Voraus planen zu können. Auch wenn das Ziel bekannt ist, können unmöglich alle Ereignisse vorausgesehen werden. Die Grundfunktionen beim Autofahren wie Beschleunigen, Bremsen oder Spur Wechseln sind vom Fahrziel unabhängige Faktoren. Ziel ist es, einen Prozess zu finden, der die Anwendung der einzelnen Aktivitäten im richtigen Moment ermöglicht (vgl. Katterl 2004). Der Unterschied von Extreme Programming zu den herkömmlichen agilen Methoden liegt im Begriff extrem. Aber welche Praktiken sind beim Extreme Programming denn eigentlich extrem? Das Attribut extrem rührt daher, dass bewährte Praktiken der Softwareentwicklung ins Extreme geführt werden. Die Ideen von XP sind eigentlich nicht neu; höchstens die konsequente Anwendung und die Kombination sind verstärkte Praktiken von bekannten Ansätzen, wie Tabelle 1 zeigt. (vgl. Beck 2003: xiv). Bewährte Praktiken Code Reviews sind gut Testen ist gut Design ist wichtig Einfachheit ist gut Architektur ist wichtig Kurze Iterationszyklen sind gut ins Extreme geführt Code wird andauernd begutachtet, Pair-Programming Ständiges Testen Ständiges Redesign und Refactoring Alles so einfach wie möglich Ständige Architekturweiterentwicklung Extrem kurz: Minuten bis Stunden Tabelle 1: Verstärkte Praktiken Extreme Programming kann nicht nur bezüglich der Flexibilität auf Anforderungsänderungen positioniert werden, sondern auch bezüglich der daraus resultierenden Kosten für die Änderung. In Abbildung 3 wird der unterschiedliche Kostenverlauf bei Änderungen je nach Entwicklungsmethode sichtbar. Im Gegensatz zur Verwendung von XP steigen bei der Anwendung von 6 Fachhochschule Solothurn Nordwestschweiz, Hochschule für Wirtschaft, Discussion Paper

15 Einleitung klassischen Methoden die Kosten mit fortschreitendem Projektstatus exponential an (vgl. Beck 2003: 21). Die Richtigkeit des Kurvenverlaufs in Abbildung 3 kann nicht ohne weiteres bewiesen werden, da in der Praxis ein Projekt zweimal durchgeführt werden müsste: einmal mit XP und einmal mit einer klassischen Methode, wobei auch die gleichen Fehler zweimal gemacht werden müssten. Dennoch verdeutlicht diese Grafik exemplarisch, dass die Kosten für Änderungen bei XP am Anfang höher sind als bei klassischen Methoden, aber im Laufe des Softwareentwicklungsprojekts nicht mehr groß ansteigen, während klassische Methoden gerade in den späteren Phasen aufgrund des exponentiellen Kostenwachstums quasi keine Änderungen mehr erlauben. Abbildung 3: Änderungskosten Abbildung 4 demonstriert, dass bei XP die Bedeutung der Planung über den gesamten Projektzeitraum weniger groß ist und dass Entscheidungen auf einen späteren Projektzeitpunkt terminiert werden können. Diese Entscheidungen fallen in der Regel dann auch besser aus, da sie aktuelleren Bedürfnissen entsprechen und auf bereits erfolgtem Feedback basieren (vgl. Beck 2003: 21). Abbildung 4: Bedeutung der Planung Nimmt man die Angaben der Kostenkurve aus Abbildung 3 und die Bedeutung der Planung aus Abbildung 4 als gegeben, entstehen in der Anwendung von XP folgende Vorteile (vgl. Beck 2003: 12): Fachhochschule Solothurn Nordwestschweiz, Reihe A: Discussion Paper

16 Theorie und Paradigmen des Extreme Programming Die Richtung eines Projekts kann einfacher dem Projektumfeld angepasst werden. Unklare Punkte können aufgeschoben werden, bis sich das Umfeld geklärt hat. Somit lassen sich unsichere Investitionen reduzieren. Das Projekt kann wachsen und sich dem Marktwachstum anpassen. Das Projekt kann eingestellt werden und der Kunde hat trotzdem ein funktionstüchtiges Softwarepaket, da XP dies nach jedem Release garantiert. Vielleicht sind noch nicht alle Funktionalitäten implementiert, aber was implementiert ist, wollte der Kunde so mit dieser Priorität haben. Eine weitere Voraussetzung für die flexible Reaktion auf Änderungen sind automatisierte Tests. Denn nach jeder Änderung muss der Code schnell wieder getestet werden können, um sicherzustellen, dass das vorhandene System dadurch nicht auch noch versehentlich verändert wurde. Daneben sind ein einfaches, überblickbares Design und eine Menge Übung in dessen Änderung Voraussetzung für ein erfolgreiches Refactoring (vgl. Beck 2003: 24). 2 Theorie und Paradigmen des Extreme Programming 2.1 Übersicht über Extreme Programming Im Folgenden werden die vier Variablen, die Grundwerte sowie die Prinzipien, auf denen XP basiert, vorgestellt Die vier Variablen eines Projekts in XP Die vier Variablen in jedem Projekt sind Kosten Qualität Zeit Umfang Zwischen diesen vier Variablen besteht ein fundamentaler Zusammenhang: Wenn drei Faktoren festliegen, ist der vierte ebenfalls gegeben. Die Konsequenz aus dieser Tatsache ist, dass der Kunde höchstens drei Faktoren nach seinem Wunsch bestimmen kann. Es ist Aufgabe der Entwickler, dem Kunden den Einfluss auf den vierten Faktor zu erläutern (vgl. Armin 2004). Dieser Zusammenhang wird auch Regel genannt. Dies gilt prinzipiell auch für alle Softwareprojekte, egal ob XP eingesetzt wird oder nicht. Kent Beck, einer der XP-Pioniere, vergleicht die vier Variablen mit vier Hebeln einer großen viktorianischen Dampfmaschine. Diese Hebel kontrollieren die Maschine (das Projekt). Jeder Hebel kann arretiert werden. Sind aber die ersten drei Hebel erst einmal arretiert, kann auch der vierte nicht mehr bewegt werden (vgl. Beck 2001: 25). Das Problem ist jedoch, dass die Auswir- 8 Fachhochschule Solothurn Nordwestschweiz, Hochschule für Wirtschaft, Discussion Paper

17 Theorie und Paradigmen des Extreme Programming kungen der Änderungen mit zeitlicher Verzögerung und nichtlinear erfolgen. So ist es z.b. nicht möglich, die Kosten zu verdoppeln, die Zeit dafür zu halbieren und die restlichen Faktoren konstant zu halten. Bildlich kann die Regel auch am Teufelsquadrat nach Sneed veranschaulicht werden, wie Abbildung 5 zeigt (vgl. Heyer 2000). Die vier Variablen im Projekt (Umfang, Kosten, Zeit, Qualität) sind gegeben durch das Quadrat in der Mitte. Ändern sich ein bis drei Variablen im Laufe des Projekts, so bewegen sich die entsprechenden Eckpunkte des Quadrates für diese Variablen (in Pfeilrichtung zunehmend oder entgegen der Pfeilrichtung abnehmend) an eine neue Position. Die restlichen Variablen passen sich dann an, indem sie quasi an eine neue Position gezogen bzw. geschoben werden. Soll beispielsweise in einem Projekt die Qualität der Ergebnisse verbessert, die Zeit im Projekt allerdings verkürzt und sollen die Kosten eingehalten werden, so geht dies nur mit einem verminderten Umfang im Projekt, wie das schraffierte verzerrte Viereck andeutet. Qualität Umfang Zeit Kosten Abbildung 5: Teufelsquadrat nach Sneed Kosten Den stärksten Einfluss auf die Kosten hat das Personal. Je mehr Leute im Projekt beschäftigt werden, desto höher steigen die Kosten an, und zwar nichtlinear, wobei auch noch die Wirkung verzögert eintritt. Die Verzögerung entsteht durch die Einarbeitungszeit von neuen Mitarbeitenden; die nichtlineare Kostensteigerung hängt mit dem Anwachsen des Koordinationsund Kommunikationsaufwandes bei zunehmender Zahl an Teammitgliedern zusammen. Falls dann bei einem in Verzug geratenen Projekt noch weitere Personen hinzugezogen werden müssen, kann die Verzögerung auf den Zeitplan noch größer ausfallen. In diesem Fall empfiehlt es sich, Personen schrittweise einzustellen. Kontraproduktiv ist auch das in gewissen Firmen vorhandene Prestigedenken, ein 150-Personen-Projekt leiten zu müssen. Solche Projekte sind besonders in Softwareprojekten äußerst schwierig zu leiten (vgl. Beck 2003: 17). Kosten können auch durch Hilfsmittel wie größere Bildschirme oder schnellere Rechner, bessere Ausbildung oder arbeitsfreundlichere Umgebung entstehen. Investitionen in die Motivation der Fachhochschule Solothurn Nordwestschweiz, Reihe A: Discussion Paper

18 Theorie und Paradigmen des Extreme Programming Arbeitnehmenden werden beim XP groß geschrieben, und von Überstunden wird dringend abgeraten. Auf die Überstundenthematik wird in Kapitel 40-Stunden-Woche noch näher eingegangen (vgl. Beck 2001: 26) Qualität Bei der Qualität unterscheidet Kent Beck zwischen innerer und äußerer Qualität. Die äußere Qualität ist jene, welche der Kunde in Form von Fehlern, Aussehen von Benutzeroberfläche und Performance des Systems wahrnimmt (vgl. Beck 2001: 27). Die innere Qualität bezeichnet die Güte des Designs und der Tests. Mit geringer innerer Qualität kann zwar kurzfristig Zeit gespart werden, aber längerfristig baut man ein System, dessen Wartung unmöglich wird (vgl. Hofer 2002). Qualität hat einen nicht zu vernachlässigenden Einfluss auf die Motivation der Mitarbeitenden. Die Entwickler können sich besser mit ihrem Arbeitsresultat identifizieren und sind mit ihrer Aufgabe zufriedener, je höher die Qualität ihres Produkts ist. Produkte von minderwertiger Qualität herzustellen, hat eine demoralisierende Wirkung. Durch Sparen bei der Qualität lassen sich meist nur kurzfristige Gewinne erzielen, was sich mit einem Leben auf Pump vergleichen lässt. Kurzfristig ist man vielleicht schneller, aber die Qualitätsmängel fordern später ihren Tribut zurück (vgl. Beck 2003: 18) Zeit Die Hebel Zeit und Umfang sind besser geeignet, verändert werden zu können. Problematisch ist nur, dass man dazu neigt, sich bezüglich des Arbeitspensums zu überschätzen, ohne die zeitlichen Konsequenzen genügend zu berücksichtigen (vgl. Beck 2001: 28). Zusätzliche Zeit kann die Qualität verbessern oder die Möglichkeit schaffen, mehr Funktionalitäten zu implementieren. Falls zu viel Zeit zur Verfügung steht, kann der negative Effekt auftreten, dass wertvolle Nutzerfeedbacks unnötig lange hinausgezögert werden (vgl. Meyer 2004). Zu knappe Zeitberechnung hingegen wirkt sich auf die Qualität meist negativ aus (vgl. Beck 2003: 16). Oft sind die Zwänge, denen die Variable Zeit unterliegt, von außen gegeben. So ließ sich z.b. die Jahr-2000-Umstellung ebenso wenig verschieben wie jährlich wiederkehrende Anpassungen einer Software (z.b. für die Erstellung der Steuererklärung nach neuen Richtlinien) oder ein Projekt, das für eine Messe realisiert werden soll. Die Variable Zeit liegt daher oft nicht im Entscheidungsbereich der Projektmanager, sondern in dem des Kunden (vgl. Beck 2003: 17) Umfang Die Kunden haben oft nicht genaue Vorstellungen bezüglich des Umfangs. Nicht selten wird ihnen erst nach dem ersten Release klar, was sie eigentlich wollten. Die Variable Umfang (Scope) lässt sich meist am leichtesten verändern (vgl. Beck 2003: 19). Eine wichtige Schlussfolgerung ist, die Notwendigkeit des Zusammenhangs dieser vier Variablen allen Beteiligten vor Augen zu führen. Wenn Programmierer, Kunde und Manager transparent 10 Fachhochschule Solothurn Nordwestschweiz, Hochschule für Wirtschaft, Discussion Paper

19 Theorie und Paradigmen des Extreme Programming über Veränderungen und deren Auswirkungen kommunizieren, können sie bewusst entscheiden, welche Variablen sie festlegen wollen. Falls die sich daraus ergebende vierte Variable nicht akzeptabel ist, besteht immer die Möglichkeit, die Ausgangswerte der drei übrigen Variablen zu ändern (vgl. Beck 2003: 15). Kent Beck empfiehlt, dass der Projektmanager den Umfang verwaltet. Denn wenn er den Umfang gezielt kontrolliert, kann den Kunden und übergeordneten Managern die Kontrolle über Kosten, Qualität und Zeit aufgetragen werden (vgl. Beck 2003: 18). Wie reagiert XP auf mögliche Veränderungen bezüglich des Umfangs? Einerseits erreichen Projekte unter XP Feedback häufiger durch die kurzen Iterations- und Release-Zyklen, und andererseits ermöglicht XP genauere Aufwandschätzungen durch die Unterteilung in kleine User-Stories. Bessere Aufwandschätzungen verringern das Risiko, Funktionen weglassen zu müssen. Wichtig ist, dass der Kunde bei jeder Planung den Geschäftsnutzen jeder User-Story bewertet, so dass die wichtigsten Anforderungen zuerst implementiert werden. Deshalb sind bei einer Umfangreduzierung nur gerade die weniger wichtigen Funktionen betroffen (vgl. Beck 2003: 19) Die vier Werte des XP Neben den vier Variablen definiert XP auch vier Werte: Kommunikation, Einfachheit, Feedback und Mut. Diese sind eng miteinander verzahnt (vgl. Beck 2003: 29) Kommunikation Die Ursache für das Scheitern vieler Projekte ist im Bereich zwischenmenschlicher Probleme und insbesondere in einer ungenügenden Kommunikation zu finden. Kommunikationsprobleme sollen möglichst früh durch den Coach identifiziert werden, damit ihre Beseitigung rechtzeitig eingeleitet werden kann. Bei XP werden viele Techniken angewendet, die eine konsequente Kommunikation zur Grundlage haben. Beispiele dazu sind Pair-Programming, Aufwandschätzungen, die täglichen Meetings im Stehen, der Kunde vor Ort, das Planning Game etc., um nur einige zu nennen. XP ohne Beteiligte, die über ausgezeichnete kommunikative Fähigkeiten verfügen, ist ganz und gar unvorstellbar (vgl. Beck 2003: 29) Einfachheit Es wird die einfachste Möglichkeit gewählt, die ausreicht, ein Problem zu lösen. Der Entwickler belastet sich daher nicht mit künftigen Fragestellungen. Nur gerade das, was heute gebraucht wird, wird implementiert, auch auf die Gefahr hin, dass schon morgen die Anforderungen vielleicht wieder ganz anders sind. XP-Entwickler sind überzeugt, dass es besser ist, heute etwas Einfaches zu tun und morgen etwas mehr zu zahlen, wenn man es ändern muss, statt heute etwas Komplizierteres zu entwickeln, das vielleicht niemals verwendet werden kann. Einfachheit und Kommunikation gehören zusammen, denn je einfacher etwas gebaut wird, desto geringer ist der Kommunikationsaufwand, und je mehr kommuniziert wird, desto eher kristallisiert sich heraus, welche Funktionalitäten benötigt werden, um das System möglichst einfach zu halten (vgl. Beck 2003: 29). Fachhochschule Solothurn Nordwestschweiz, Reihe A: Discussion Paper

20 Theorie und Paradigmen des Extreme Programming Feedback Feedback erhält der Entwickler durch den Partner beim Pair-Programming, durch die automatisierten Modultests und am Ende eines Arbeitstages durch die Integrationstests. Der Kunde erhält Feedback durch die häufigen Releases. Zudem wird laufend über den Projektstand und den Projektfortschritt orientiert (vgl. Beck 2003: 31) Mut Mit Mut soll jedes Projektmitglied erkannte Probleme angehen und so den Projekterfolg sichern. Mut verlangt XP darin, dass der Entwickler nur jene Probleme lösen soll, die er momentan wirklich hat, und nicht die, die später vielleicht auftauchen könnten. Mit Mut löst er die heutigen Probleme heute und die morgigen morgen. Mut braucht es ebenfalls, unnötig komplizierten Code zu eliminieren und wieder komplett neu mit der Problemlösung zu beginnen (vgl. Beck 2003: 33) Weitere Werte Zum Teil werden auch sieben Werte für XP genannt, wobei dann Lernen, Respekt und Qualität im Sinn von Qualitätsbewusstsein ergänzend hinzukommen (vgl. Westphal 2004). Respekt gegenüber den anderen Projektmitgliedern und Interesse am Lernen sind unabdingbare Voraussetzungen für alle Beteiligten an XP-Projekten. Qualität ist bereits eine der vier Variablen; und ein angemessenes Qualitätsbewusstsein ist sehr wichtig für alle Beteiligten. Hier wird nun deutlich, dass XP nur mit ganz bestimmten Mitarbeitenden möglich ist Die XP-Prinzipien Da die vier (bzw. sieben) vorgestellten Werte nur den Stil von XP vorgeben, aber zu vage sind, als dass sie sich in dieser Form direkt in die Praxis umsetzen ließen, wurden aus ihnen zunächst einige konkrete Prinzipien abgeleitet. Diese sollen helfen, die vier Werte in die Praxis umzusetzen und zu konkretisieren. Denn was z.b. für die eine Person einfach ist, kann für eine andere kompliziert sein. Die abgeleiteten Prinzipien können in primäre und sekundäre Prinzipien unterteilt werden (vgl. Beck 2003: 37) Primäre Prinzipien Zu den primären Prinzipien gehören (vgl. Beck 2003: 38): Unmittelbares Feedback (rapid feedback) Von entscheidender Bedeutung ist der Zeitraum zwischen einer Aktion und deren Feedback. Gemäß Erkenntnissen aus der Lernpsychologie hängt effektives Lernen von der Zeit zwischen einer Aktion und ihrer Rückmeldung ab. Lernen ist nur möglich, wenn diese Zeit relativ kurz ist. Einfachheit anstreben (assume simplicity) Im Gegensatz zu klassischen Entwicklungsmethoden wird bei der Softwareentwicklung 12 Fachhochschule Solothurn Nordwestschweiz, Hochschule für Wirtschaft, Discussion Paper

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

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

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

- 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

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

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

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

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

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

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

extreme Programming (XP) Hermann Götz Sergij Paholchak Agenda Was ist XP? Grundprinzipien Der Entwicklungsprozess Die Projektplanung Praktiken Vorteile und Nachteile Wann macht XP Sinn für ein Projekt?

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

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

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

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

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

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

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

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

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

Agile Softwareverträge

Agile Softwareverträge Zeitschrift Informatik-Spektrum der deutschen Gesellschaft für Informatik Ursula Sury Agile Softwareverträge AGILE SOFTWAREENTWICKLUNG Komplexität, steter Wandel, Umgang mit vielen Unbekannten das sind

Mehr

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung Unified Process Eine Einführung von Hannes Fischer Fischer Software Elfenstr. 64 70567 Stuttgart Deutschland Copyright 2000 Hannes Fischer Unified Process Wie wird heute gearbeitet? Der Unified Process

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

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

Befragung und empirische Einschätzung der Praxisrelevanz

Befragung und empirische Einschätzung der Praxisrelevanz Befragung und empirische Einschätzung der Praxisrelevanz eines Vorgehensmodells zur Auswahl von CRM-Systemen D I P L O M A R B E I T zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen

Mehr

MSP: Methoden des Software-Entwicklungsprozesses

MSP: Methoden des Software-Entwicklungsprozesses WS 2005/06 Mastermodul CS 5002 MSP: Methoden des Software-Entwicklungsprozesses Teamentwicklung extreme Programming Projekttagebuch Prof. Dr. Klaus Quibeldey-Cirkel Fachhochschule Gießen-Friedberg Forming

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

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

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

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 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

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

Requirements Lifecycle Management (RLM)

Requirements Lifecycle Management (RLM) Whitepaper Requirments Lifecycle Management Requirements Lifecycle Management (RLM) Die Weiterentwicklung der klassischen Anforderungsanalyse 1 Einleitung War noch vor einiger Zeit die klassische Anforderungsanalyse

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

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

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

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

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

Softwaretechnik II. Sommersemester 2014. Software-Qualität. Stefan Berlik

Softwaretechnik II. Sommersemester 2014. Software-Qualität. Stefan Berlik 1 / 43 Softwaretechnik II Sommersemester 2014 Software-Qualität Stefan Berlik Fachgruppe Praktische Informatik Fakultät IV, Department Elektrotechnik und Informatik Universität Siegen 8. Mai 2014 Gliederung

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

Seminar Software Engineering Universität Zürich, Winter 03/04. Agile vs. klassische Methoden der Software-Entwicklung

Seminar Software Engineering Universität Zürich, Winter 03/04. Agile vs. klassische Methoden der Software-Entwicklung Seminar Software Engineering Universität Zürich, Winter 03/04 Agile vs. klassische Methoden der Software-Entwicklung EXTREME PROGRAMMING Manuel Meyer Rosenstrasse 9, 8152 Glattbrugg Matrikelnr. 99-905-739

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

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

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

Ü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

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

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung Kapitel B Vorgehensmodelle Inhaltsverzeichnis 1 B Vorgehensmodell... 3 1.1 Welche Vorgehensmodelle sind

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

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

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

Teststrategie festlegen und Teststufen aufeinander abstimmen

Teststrategie festlegen und Teststufen aufeinander abstimmen Testen Teststrategie festlegen und Teststufen aufeinander abstimmen Bereich Projektplanung und -steuerung Aktivität Projekt planen Ziele Effiziente Testausführung Vermeidung von doppelter Arbeit schnell

Mehr

Agile Software Development

Agile Software Development Dipl. Wirtsch. Ing. Alexander Werth Methoden der Softwareentwicklung 6-1 Agile Manifest Individuen und Interaktion statt Prozessen und Tools. Funktionierende Software statt umfangreicher Dokumentation.

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

Produktphilosophie erstellen

Produktphilosophie erstellen User Experience Produktphilosophie erstellen Bereich Anforderungen Aktivität Ziele Erleichterte Kommunikation zwischen Stakeholdern Designentscheidungen erleichtern/rechtfertigen schnell durchführbar einfach

Mehr

Talk im Schloss. Zusammenbringen was zusammen gehört. Der richtige Softwareentwicklungsprozess für erfolgreiches Usability Engineering 10.12.

Talk im Schloss. Zusammenbringen was zusammen gehört. Der richtige Softwareentwicklungsprozess für erfolgreiches Usability Engineering 10.12. Talk im Schloss Zusammenbringen was zusammen gehört Der richtige Softwareentwicklungsprozess für erfolgreiches Usability Engineering 10.12.2007 F.Riemenschneider +49 177 291 68 32 falko.riemenschneider@itemis.de

Mehr

Referent: Alessandro Arrigo AAM1. Professor: Prof. Dr. Heindl. Furtwangen, 2.7.2009

Referent: Alessandro Arrigo AAM1. Professor: Prof. Dr. Heindl. Furtwangen, 2.7.2009 - Entwicklungsprozess - Referent: Alessandro Arrigo AAM1 Professor: Prof. Dr. Heindl Furtwangen, 2.7.2009 Agenda 1. Vorstellung des Autors 2. Das Buch 3. Inhalt des Kapitels 4. Verwendung in anderer Literatur

Mehr

Produktqualität in agilen Entwicklungsvorgehen. BITKOM Software Summit Frankfurt, 23. September 2014 Dominik Rost, Hartmut Schmitt

Produktqualität in agilen Entwicklungsvorgehen. BITKOM Software Summit Frankfurt, 23. September 2014 Dominik Rost, Hartmut Schmitt Produktqualität in agilen Entwicklungsvorgehen BITKOM Software Summit Frankfurt, 23. September 2014 Dominik Rost, Hartmut Schmitt 1 Motivation 2 Agile Entwicklungsvorgehen Status Quo vorwiegend eingesetzte

Mehr

Inhaltsverzeichnis. Boris Gloger. Scrum. Produkte zuverlässig und schnell entwickeln ISBN: 978-3-446-41913-1

Inhaltsverzeichnis. Boris Gloger. Scrum. Produkte zuverlässig und schnell entwickeln ISBN: 978-3-446-41913-1 sverzeichnis Boris Gloger Scrum Produkte zuverlässig und schnell entwickeln ISBN: 978-3-446-41913-1 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-41913-1 sowie im Buchhandel.

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

Werte und Prinzipien der agilen Softwareentwicklung

Werte und Prinzipien der agilen Softwareentwicklung 1 Was ist Scrum? Scrum ist ein einfaches Projektmanagement-Framework, in das Entwicklungsteams selbstbestimmt erprobte Praktiken einbetten. Der Rahmen sieht einen empirisch, iterativen Prozess vor, bei

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

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

Agiles Vorgehen Do s und Don ts im Umfeld und beim Management

Agiles Vorgehen Do s und Don ts im Umfeld und beim Management Agiles Vorgehen Do s und Don ts im Umfeld und beim Management Vortrag bei der Fachgruppe IT-Projektmanagement 22. Mai 2015, Steinbeis-Transferzentrum IT-Projektmanagement, Stuttgart hoffmann@stz-itpm.de

Mehr

Seminar: Softwareentwicklung in der Wissenschaft. Agile Softwareentwicklung

Seminar: Softwareentwicklung in der Wissenschaft. Agile Softwareentwicklung Seminar: Softwareentwicklung in der Wissenschaft Agile Softwareentwicklung Benjamin Pöpel Fakultät für Mathematik, Informatik und Naturwissenschaften Fachbereich Informatik Betreuer: Christian Hovy 23.

Mehr

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung Block R (Rahmen): SE Aktivitäten 21.10.04 1 Vorlesung Methoden des Software Engineering Block R Rahmen Aktivitäten der Software-Entwicklung Martin Wirsing Einheit R.2, 21.10.2004 Block R (Rahmen): SE Aktivitäten

Mehr

ISO 13485 konforme Entwicklung medizinischer Software mit agilen Vorgehensmodellen

ISO 13485 konforme Entwicklung medizinischer Software mit agilen Vorgehensmodellen ISO 13485 konforme Entwicklung medizinischer Software mit agilen Vorgehensmodellen Bernhard Fischer Fischer Consulting GmbH MedConf 2009 Folie 1 Wie soll Software entwickelt werden? MedConf 2009 Folie

Mehr

Praktische Softwaretechnologie Vorlesung 8

Praktische Softwaretechnologie Vorlesung 8 Praktische Softwaretechnologie Vorlesung 8 Martin Giese Johann Radon Institute for Computational and Applied Mathematics Österr. Akademie der Wissenschaften Linz PSWT 2006 12. Dezember 2006 p.1/32 Die

Mehr

Zielvereinbarung. Team JAMT.

Zielvereinbarung. Team JAMT. Ziele des Projektes. Wer benötigt das Ergebnis des Softwareprojektes? Gruppenprozessleiter, welche keine Expertise auf dem Gebiet der Gruppenprozesserstellung haben Teams, die computergestützte Gruppenarbeit

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

Obligatorisches Lesen Vorgehensmodelle (Phasenmodelle)

Obligatorisches Lesen Vorgehensmodelle (Phasenmodelle) Obligatorisches Lesen Vorgehensmodelle (Phasenmodelle) Zuser Kap. 1-3 oder Ghezzi Chapter 1 oder Pfleeger Chapter 1; Chap 8.1 http://homepages.cs.ncl.ac.uk/brian.randell/nato/ The first International Conference

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

Einleitung. Was ist das Wesen von Scrum? Die Ursprünge dieses Buches

Einleitung. Was ist das Wesen von Scrum? Die Ursprünge dieses Buches Dieses Buch beschreibt das Wesen von Scrum die Dinge, die Sie wissen müssen, wenn Sie Scrum erfolgreich einsetzen wollen, um innovative Produkte und Dienstleistungen bereitzustellen. Was ist das Wesen

Mehr

(Titel des Berichts)

(Titel des Berichts) (Titel des Berichts) Praxissemesterbericht von (Vorname Name) aus (Geburtsort) Matrikelnummer Anschrift Telefon HTW Aalen Hochschule für Technik und Wirtschaft Betreuender Professor Abgabetermin Angaben

Mehr

Umfrage zum Informationsbedarf im Requirements Engineering

Umfrage zum Informationsbedarf im Requirements Engineering Umfrage zum Informationsbedarf im Requirements Engineering Vielen Dank für Ihre Teilnahme an dieser Studie! Im Rahmen eines Forschungsprojektes an der Universität Hamburg und der TU Graz führen wir eine

Mehr

Der Faktor Mensch in IT-Projekten

Der Faktor Mensch in IT-Projekten Der Faktor Mensch in IT-Projekten - Der Faktor Mensch in IT-Projekten Dr. Eberhard Huber Der Faktor Mensch in IT-Projekten - Der Faktor Mensch in IT-Projekten Motivation EinAusflug in die Psychologie und

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

Softwaretechnik Prozessmodelle

Softwaretechnik Prozessmodelle Softwaretechnik Prozessmodelle Karsten Weicker, Nicole Weicker HTWK Leipzig, FHTW Berlin Celine: They enjoy the goal but not the process. But the reality of it is that the true work of improving things

Mehr

Extremes Programmieren

Extremes Programmieren Extremes Programmieren Erschienen im Informatik-Spektrum 23(2), 2000, S. 118-121 als Aktuelles Schlagwort Ralf Reißing Universität Stuttgart Institut für Informatik Abteilung Software Engineering Breitwiesenstr.

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

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

Inhaltsverzeichnis. Boris Gloger. Scrum. Produkte zuverlässig und schnell entwickeln ISBN: 978-3-446-42524-8

Inhaltsverzeichnis. Boris Gloger. Scrum. Produkte zuverlässig und schnell entwickeln ISBN: 978-3-446-42524-8 sverzeichnis Boris Gloger Scrum Produkte zuverlässig und schnell entwickeln ISBN: 978-3-446-42524-8 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-42524-8 sowie im Buchhandel.

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

Evolutionsprozesse. Dr. Thorsten Arendt Marburg, 23. Oktober 2014

Evolutionsprozesse. Dr. Thorsten Arendt Marburg, 23. Oktober 2014 Evolutionsprozesse Dr. Thorsten Arendt Marburg, 23. Oktober 2014 Überblick Betrachtung der bekannten Softwareentwicklungsprozesse bezüglich Software-Evolution Evolutionsprozesse Techniken für Software-Evolution

Mehr

Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler

Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler Modellgetriebene Softwareentwicklung auf Basis von TOPCASED am Beispiel

Mehr

Extreme Programming: Überblick

Extreme Programming: Überblick Extreme Programming: Überblick Stefan Diener / Apr 18, 2007 / Page 1 Prinzipien Rollen Planung Implementierung Praktiken weitere Vorgehensweisen Grenzen Inhalt Stefan Diener / Apr 18, 2007 / Page 2 Prinzipien

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

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

Die Rolle der Anforderungen in agilen Methoden

Die Rolle der Anforderungen in agilen Methoden Seminar Agile vs. klassische Methoden der Software-Entwicklung Die Rolle der Anforderungen in agilen Methoden Seminararbeit von Alex Bögli Salstrasse 45, 8400 Winterthur Matrikel-Nr. 00-703-538 Angefertigt

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

Über dieses Buch. Kapitel 1. 1.1 Einleitung

Über dieses Buch. Kapitel 1. 1.1 Einleitung Kapitel 1 Über dieses Buch 1.1 Einleitung Dieses Buch behandelt das Vorgehensmodell Kanban und seinen Einsatz in Softwareentwicklungsprojekten. Kanban ist ein Vorgehensmodell der schlanken Softwareentwicklung

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

1.2 System- und Softwareentwicklungsprozesse

1.2 System- und Softwareentwicklungsprozesse 1.2 System- und Softwareentwicklungsprozesse Prof. Mario Jeckle Fachhochschule Furtwangen mario@ http://www. Fachhochschule Furtwangen, Sommersemester 2004 Vorgehensmodelle und UML Um Systeme und Software

Mehr

Agile BI Kickstart. Beschreibung des Workshops. Workshopbeschreibung

Agile BI Kickstart. Beschreibung des Workshops. Workshopbeschreibung Bereich: Workshop: Dauer: In-House Workshop Agile BI Kickstart 2 Tage Beschreibung des Workshops Agile Vorgehensweisen werden bei der Entwicklung von BI- und Data Warehouse-Lösungen heutzutage mehr und

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

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

Agiles Testen. Gedankensammlung. 17. November 2013 - Patrick Koglin

Agiles Testen. Gedankensammlung. 17. November 2013 - Patrick Koglin Agiles Testen Gedankensammlung 17. November 2013 - Patrick Koglin Inhalt Reflektion: Agilität notwendig? Wo? Eigenschaften agiler Entwicklung Quality is everyone s responsibility Qualität möglich machen

Mehr

Anhang A: Die Familie der C-Sprachen Anhang B: Grundlagen der C++ und der Java-Programmierung. Vorgehensmodelle der Software-Entwicklung

Anhang A: Die Familie der C-Sprachen Anhang B: Grundlagen der C++ und der Java-Programmierung. Vorgehensmodelle der Software-Entwicklung Einführung in die Software-Entwicklung 7 Software-Entwicklung im Team 1. Von der Idee zur Software 2. Funktionen und Datenstrukturen 3. Organisation des Quellcodes 4. Werte- und Referenzsemantik 5. Entwurf

Mehr