A G I L E S O F T WA R E E N T W I C K L U N G

Größe: px
Ab Seite anzeigen:

Download "A G I L E S O F T WA R E E N T W I C K L U N G"

Transkript

1 Collin Rogowski A G I L E S O F T WA R E E N T W I C K L U N G Veranstaltung im SS 2009, Duale Hochschule Baden-Württemberg, Karlsruhe - Skript - 1

2 Software Engineering 6 Software Entwicklung als eigenständige Disziplin 6 Das Wasserfallmodell 7 Big Design Up Front 8 Das Wasserfallmodell in der Praxis 9 Agile Software Entwicklung 12 Die Wurzeln der agilen Software Entwicklung 12 Agile Manifesto 13 Individuals and interactions over processes and tools 13 Working software over comprehensive documentation 15 Customer collaboration over contract negotiation 15 Responding to change over following a plan 16 (Unbequeme) Wahrheiten 17 Extreme Programming 17 Entstehung 17 Aufbau 17 Werte 18 Prinzipien 18 Praktiken 19 User Stories 19 Rhythmus 20 Planen 20 Planungsdreieck 21 Planen (Fortsetzung) 22 Pair Programming 23 2

3 Continuous Integration 23 Test-First 24 Root-Cause Analysis 25 Gemeinsamer Code 25 Abhängigkeiten von Praktiken 26 CI & TDD 26 Rhythmus & gemeinsamer Code 26 gemeinsamer Code & Pair Programming 26 gemeinsamer Code & TDD 26 Pull versus Push 26 Push 27 Pull 27 Scrum 28 Herkunft 28 Aufbau 28 Sprint 28 Rollen 28 Product Owner 28 Scrum Master 29 Team 30 Artefakte 30 Product Backlog 30 Releaseplan 31 Sprint Backlog 32 Burndown Chart 32 3

4 Meetings 33 Daily Scrum 33 Sprint Planung 34 Sprint Review 34 Sprint Retrospektive 35 Scrum auf einen Blick 35 User Stories 36 Was sind User Stories? 36 Warum User Stories? 37 Ambiguität 38 Sprache 38 Kriterien für User Stories 38 Unabhängig 39 Verhandelbar 39 Wertschöpfend 39 Schätzbar 39 Klein 40 Testbar 40 Erzeugen von User Stories 40 Rollen 41 Brainstorming 41 Organisation 41 Konsolidierung 42 Definition 42 Workshop zur User Story Generierung 42 4

5 Bibliographie 44 5

6 Software Engineering Software Engineering - zu deutsch Softwaretechnik - ist derjenige Teil der Informatik, welcher sich mit Modellen zur Erstellung von Software befasst. Die IEEE definiert Software Engineering als [IEEE, 2004] (1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (I). Eine umfassende Beschreibung dieses Feldes findet sich im Software Engineering Body of Knowledge (SWEBOK) [Abran, 2004]. Dieser identifiziert 10 Bereiche, mit denen sich Software Engineering im wesentlichen befasst: 1. Software requirements 2. Software design 3. Software construction 4. Software testing 5. Software maintenance 6. Software configuration management 7. Software engineering management 8. Software engineering process 9. Software tools and methods 10. Software quality Diese Veranstaltung thematisiert hauptsächlich Themen aus den Bereichen 7. und 8., also den Vorgehensmodellen zur Software Entwicklung und der Organisation dieser in Projekten. Für den Einfluss agiler Entwicklung auf das Programmieren an sich, also Codeerstellung, Software Design, etc., sei auf [Martin, 2009], [McConnell, 2004], [Fowler, 1999] und [Gamma, 1996] verwiesen. Software Entwicklung als eigenständige Disziplin Warum kann man nicht einfach Modelle anderer Bereiche wie etwa des Ingenieurwesens oder der Architektur auf die Software Entwicklung übertragen? Schließlich gibt es auch dort Entwicklung und es existieren bereits vielfältige Vorgehensmodelle, best practices und (teilweise) Jahrhunderte an Erfahrungen. Über genaue Antworten auf diese Frage wird viel gestritten, es gibt aber ein paar deutliche Anhaltspunkte dafür, dass Software Entwicklung sich zum Teil deutlich von anderen Disziplinen unterscheidet. Software hat in der Regel einen sehr hohen Komplexitätsgrad, was sich durch eine hohe Anzahl interagierender Teilsysteme und/oder durch einen hohen Verknüpfungsgrad dieser bemerkbar macht. Je größer die Komplexität eines Systems, desto schwieriger seine Handhabung. Software befindet sich oft an der Grenze des Handhabbaren. 6

7 Software wird auch immer wieder neu entwickelt. Keine Software ist identisch mit einer anderen Software (sonst könnte man sie ja einfach binär kopieren). Wir reden also zu Recht von Software Entwicklung und nicht etwa von Software Fertigung. Gemeinsam mit dem vorherigen Punkt (Komplexität) bedeutet diese Erkenntnis, dass zwei verschiedene Software Programme, auch wenn sie sich nur in einem Detail unterscheiden, sehr unterschiedlich aufgebaut sein können. Denn wenn dieses eine Detail mit viele anderen Komponenten in Wechselwirkung steht, hat seine Änderung mitunter große Auswirkungen. Ein Beispiel: Microsoft Office für den Mac ist mittlerweile eine komplett eigene Codebasis und wird von einem eigenen Team entwickelt. Dabei gab es ursprünglich nur die Anforderung, das Produkt Office auf einem anderen Betriebssystem verfügbar zu machen. Software Entwicklung findet oft in einem extrem instabilen Umfeld statt. Die technologischen Fortschritte sind so rasant, dass regelmäßig Paradigmenwechsel stattfinden, wie z.b. die Etablierung von virtuellen Maschinen oder die Wiederkehr von Service Oriented Architectures (SOAs). Dies erfordert auf der einen Seite eine konstante Beschäftigung mit der Technik selbst, aber auch eine aktive Beobachtung des Marktes, da sich die rasanten Fortschritte auch dort widerspiegeln. Ein Beispiel hier: der rasante Aufstieg der Smartphones allgemein durch den unerwarteten Markteintritt von Apple (iphone). Last but not least ist die Entwicklung von Software im Spannungsfeld zwischen Kreativität auf der einen Seite und der Verwendung von best practises und analytischem und strukturiertem Vorgehen auf der anderen Seite angesiedelt. Details hierzu finden sich u.a. in [Rosenberg, 2007] und [Graham, 2004]. Begreift man Software Entwicklung als eigenständige Disziplin, so ist es notwendig, sich dedizierte Vorgehensmodelle für die Entwicklung von Software zu überlegen. Eines der ersten war das so genannte Wasserfallmodell. Das Wasserfallmodell Das Wasserfallmodell ist eines der bekanntesten und verbreitetsten Vorgehensmodelle zur systematischen Entwicklung von Software. Mittlerweile wird es i.d.r. nicht mehr direkt angewandt, sondern in Form weiter ausformulierter Prozesse; oft auf die Bedürfnisse des jeweiligen Unternehmens zugeschnitten. Das Wasserfallmodell ist in diesen Fällen aber oft noch sichtbarer Ursprung. Insbesondere die Hauptcharakteristika finden sich oft 1:1 wieder. 7

8 Das Wasserfallmodell [Winston, 1987] (erschienen 1970) Das Wasserfallmodell ist streng sequentielles, dokumentengetriebenes Vorgehensmodell zur Software Entwicklung [Winston, 1987]. Das Modell sieht sieben Stufen vor, welche für die erfolgreiche Entwicklung von Software durchlaufen werden müssen. Dabei dient der Output von Stufe n als Input für Stufe n+1. Die Entwicklung beginnt mit der Analyse der Anforderung, der einzige Schritt, wo der Kunde der zu entwickelnden Software direkt beteiligt ist. Das Ergebnis dieser Analyse-Phase ist ein Dokument, welches die Wünsche des Kunden an die Software fixiert. Dieses Dokument dient dann als Grundlage für die Design-Phase, in welcher der technische Aufbau der Software (System-Architektur, Klassendiagramme, etc.) festgelegt wird. Diese Dokumente werden dann in der Implementierungsphase verwendet, um die eigentliche Software zu erstellen. Die Integration dieser Software in ihre Umgebung (Interaktion mit andere Software Komponenten, Integration in den Betrieb, etc.) wird in der Integrationsphase vorgenommen. In der darauf folgenden Phase wird die Software getestet und sichergestellt, dass die Qualitätsanforderungen eingehalten werden. Ist dies erfolgt, kann die Software ausgerollt (installiert) werden, um dann in die Lebenszyklus Wartung überzugehen. Big Design Up Front Das Wasserfallmodell folgt dem Paradigma Big Design Up Front (BDUF), welches der Philosophie folgt, dass, je später ein Fehler in der Erstellung eines System gefunden wird, es umso teurer ist, ihn zu beseitigen. Hier sieht man auch klar die Wurzeln des Wasserfallmodells, die Fertigungsindustrie der 1970er Jahre. Bei der Produktfertigung ist BDUF sicherlich gegeben, denn ein Fehler im Design einer Maschine, der sich erst durch eine fehlerhafte Charge des mit der Maschine zu 8

9 erstellenden Produktes bemerkbar macht, ist in der Regel nur mit viel Aufwand (Geld und Zeit) zu beheben. Auch in der Software Entwicklung ist BDUF als Paradigma weit verbreitet, denn es gibt viele Beispiele, wo ein kleiner Fehler zu Beginn eines Projektes sehr große Auswirkungen gegen Ende des Projektes hat. Ein Beispiel: Es soll eine Desktop-Applikation für Windows entwickelt werden. Die Entwickler entscheiden sich als technische Grundlage für das Microsoft.NET-Framework. Die Software wird implementiert und kommt in den Test. Dort wird festgestellt, dass bei der Anforderungsanalyse die Anforderung muss ohne Administrationsrechte installierbar sein vergessen wurde. Das.NET-Framework kann aber nur mit Administrationsrechten installiert werden; die Wahl der gesamten technischen Grundlage war im Nachhinein falsch und das Projekt muss aufgegeben werden. Das Wasserfallmodell in der Praxis Die in der Literatur vielzitierten Berichte der Standish-Group [Standish Group, 2004] zeigen, dass nur ein kleiner Teil aller IT-Projekte wie geplant durchgeführt werden kann. Failed 18% Succeeded 29% Challenged 53% Ergebnisse des Standish CHAOS Report 2004 [Standish Group, 2004] Die Grafik listet die Ergebnisse von durchgeführten IT-Projekten auf. Succeeded bedeutet eine Fertigstellung innerhalb der veranschlagten Zeit und mit den veranschlagten Ressourcen. Challenged bedeutet, dass prinzipiell zwar das Projektziel erreicht, dafür aber mehr Zeit oder mehr Ressourcen als geplant benötigt wurden. Failed bedeutet, dass das Projektziel verfehlt wurde. Interessant ist auch die Entwicklung der Zeit- und Ressourcenüberschreitungen über die letzten Jahre: 9

10 200% 150% 100% 50% 0% Mehrkosten Verzögerung Überschreitung der durchschnittlichen, geplanten Projektparameter in %. [Standish Group, 2004] Man erkennt deutlich eine Verbesserung über die Jahre hinweg, muss aber dennoch bemerken, dass die durchschnittliche Projektlaufzeit um ca. 100% überschritten wird. Dies deckt sich durchaus mit der eigenen Alltagserfahrung: man denke nur an Projekte wie Windows Vista (erstes angekündigtes Releasedatum im Juli 2001 war Ende 2003; Vista erschien im Januar 2007 nach sieben Jahren Entwicklung) oder Duke Nukem Forever. Was könnten Gründe für solche Performancedaten sein? Ein mögliche Ursache wurde schon kurz angeschnitten: Software Entwicklung ist Entwicklung und nicht Fertigung. Sie entspricht der Entwicklung neuer Produkte und nicht der Fertigung bereits existierender. Software Entwicklung benötigt weiterhin ein gehöriges Maß an Kreativität. Die Grundlage, um in einem Team der Kreativität freien Raum zu lassen, ist eine funktionierende Kommunikation. Team bezieht sich hierbei nicht nur auf die Software Entwickler, sondern auf alle an der Entstehung des Produktes beteiligten Personen (Business Analysten, Produktmanager, Software Entwickler, Tester, etc.). Hinzu kommt, dass das Design von (Software) Produkten schwer ist, dass Priorisierung von Features schwer ist und dass Kommunikation schwer ist [Cockburn, 2002]. Schwer bedeutet in diesem Zusammenhang, dass es kein Erfolgsrezept gibt, an welchem man sich entlang hangeln kann. Dies sei an einem Beispiel illustriert. 10

11 Login-Dialog für das Browser-Betriebssystem eyeos. Nehmen wir an, es soll ein Nutzerkonzept für den Login-Dialog erstellt werden, so dass die Entwicklung mit der Umsetzung dieses Konzeptes beginnen kann (bzw. das Design-Team mit dem Software-Design). Auf den ersten Blick sollte die Grafik eigentlich fast schon genügen. Es gibt nur drei Elemente, von denen nur eines eine Aktion ausführt und die Art der Aktion ist selbsterklärend (wir gehen der Einfachheit halber davon aus, dass alle Beteiligten wissen, wie ein Login ins System funktionieren soll). Das genaue visuelle Design ist durch die Grafik auch schon festgelegt. Leider ist dies aber nur auf den ersten Blick so. Was soll passieren wenn der Nutzer sein Login und Passwort eingegeben hat und dann nicht auf den Button klickt, sondern die Return-Taste verwendet? Es soll sicherlich der Login Vorgang ausgelöst werden, das ist aber nirgendwo spezifiziert. Was ist mit der Enter-Taste (unten rechts am Ziffernblock)? 1 Dieses Beispiel ist nicht sehr weit hergeholt, denn wenn ein GUI gefordert ist, welches (graphisch) von den Standards abweicht, so kommt man oft in die Verlegenheit, die benötigten GUI-Widgets selbst programmieren zu müssen. Dies führt dann dazu, dass man solche Kleinigkeiten (wie Return & Enter) mit berücksichtigen muss. Auch funktional ist es nicht so einfach, wie es auf den ersten Blick aussieht. Was soll z.b. passieren wenn der Benutzer bereits eingeloggt ist(auf einem anderen Rechner, oder auf demselben Rechner mit einem anderen Account)? Möchte man alle diese Punkte (plus diejenigen, die ich noch vergessen habe) in die Nutzerspezifikation aufnehmen, wird schon ein sehr umfangreiches Dokument entstehen. In der Regel beschränkt sich die zu entwickelnde Software aber nicht auf so einfache Dialoge wie den diskutierten. Oft enthält kommerzielle Software Dutzende von Dialogen des folgenden Komplexitätsgrades: 1 Zumindest bei Verwendung der Win32-API haben Return und Enter unterschiedliche Keycodes, müssen also getrennt behandelt werden. 11

12 Einstellungs-Dialog vom Firefox 3 Für solche Applikationen ein vollumfängliches Nutzerkonzept mit der oben dargelegten Granularität zu schreiben, ist nahezu unmöglich. Wie kann ich aber Software entwickeln, ohne vorher genau zu spezifizieren, was ich eigentlich entwickeln will? Agile Software Entwicklung Die Wurzeln der agilen Software Entwicklung Der Ursprung der Methoden agiler Software Entwicklung ist auf die japanische Automobilindustrie der 1980er Jahre zurückzuführen. Insbesondere das Unternehmen Toyota beschäftigte sich zu dieser Zeit mit neuen Methoden zur Produktentwicklung. Das sogenannte Lean Management basiert auf der Vermeidung der drei mu : muda = Verschwendung, muri = Überlastung und mura = Unausgeglichenheit. Verschwendung ist hier definiert als jede menschliche Aktivität, die Ressourcen verbraucht, aber keinen Wert erzeugt 2 2 [Hopp, 2000], Seite

13 Das Gegenteil zur Verschwendung ist demnach die Wertschöpfung oder werterzeugende Aktivität. Die agile Software Entwicklung hat sich zum Ziel gesetzt, diese Philosophie zu übernehmen und auf Software Entwicklungsprozesse zu adaptieren. Agile Manifesto Das Agile Manifesto - agilemanifesto.org - versucht die Quintessenz agiler Software Entwicklung zu erfassen und in 4 Werten und 12 Prinzipien festzuhalten. Die vier Werte sind Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan Wichtig ist die im Agile Manifesto den Werten folgende Klarstellung, dass das over nicht im Sinne von anstatt, sondern als Ausdruck einer Priorisierung verstanden werden soll. So sind z.b. Prozesse und Werkzeuge auch wichtig, aber eben nicht so wichtig wie Individuen und Interaktionen. Diese Werte beschreiben den Raum agiler Software Entwicklung in welchem sich dann konkrete Vorgehensmodelle - wie etwa Scrum, extreme Programming oder Crystal - wiederfinden. Individuals and interactions over processes and tools Software wird von Menschen gebaut. Menschen sind einzigartig. Auf den ersten Blick wirken diese beiden Aussagen banal. Sie sind es aber nicht, wenn man sich die Versuche zur Standardisierung von Software Entwicklung anschaut. Denn, wenn man versucht, einen Software Entwicklungsprozess zu definieren, versucht man (i.d.r.) vom Individuum so zu abstrahieren, dass der Prozess von beliebigen Personen durchgeführt werden kann. Die agile Software Entwicklung spricht dem Individuum hier mehr Raum zu, in dem konstatiert wird, dass Individualität wichtiger ist als Prozesskonformität. Dass das gerade im Bereich der Software Entwicklung wichtig ist, folgt u.a. aus der Erkenntnis, dass Software Entwicklung eine Tätigkeit zur Erfindung neuer Produkte ist und diese Tätigkeit unter anderem eine Menge an Kreativität erfordert (s.o.). Um den starken Einfluss der Individualität deutlich zu machen, soll hier ein Aspekt von Individualität - nämlich individuelle Leistungsfähigkeit - diskutiert werden. 13

14 2,5 1 Entwickler Best Median Worst Performance Leistungsfähigkeit von Software Entwicklern. Quelle: [DeMarco, 1999] Die Grafik stellt auf der X-Achse die individuelle Leistungsfähigkeit von Software Entwicklern auf einer Skala von 1 bis 10 dar. Auf der Y-Achse ist die Anzahl der Software Entwickler abgetragen, die diese Leistungsfähigkeit besitzt [DeMarco, 1999]. Aus dieser Statistik kann man (mindestens) drei interessante Aussagen ableiten: I. Die besten Software Entwickler sind um den Faktor 10 produktiver als die schlechtesten Software Entwickler. II. Die besten Software Entwickler sind um den Faktor 2,5 produktiver als durchschnittliche Software Entwickler. III. Die Gruppe der Software Entwickler über dem Median ist im Durchschnitt um den Faktor 2 produktiver als die Gruppe der Software Entwickler unter dem Median. Ein Beispiel, wo dieser Aspekt in klassischen (a.k.a. nicht agilen) Software Entwicklungsmodellen oft nicht berücksichtigt wird, sind Arbeitspaketschätzungen. Bei einem großen Wasserfallprojekt steht in der Planungsphase häufig noch nicht fest, welche Personen später das Entwicklungsteam bilden werden. Trotzdem werden die Arbeitspakte im Vorfeld geschätzt, z.b. durch Architekten oder Lead Engineers. Das führt genau dann zu Problemen, wenn diese bei den Schätzungen von ihrer eigenen Leistungsfähigkeit ausgehen, diese dann aber beim umsetzenden Team nicht vorhanden ist. Mit Interaktionen über Werkzeugen ist gemeint, dass Werkzeuge zwischenmenschliche Beziehungen, bzw. Kommunikation nur ergänzen, aber nicht ersetzen können. Ein Beispiel aus der Praxis: Bugzilla ist ein sehr mächtiges Werkzeug um Defekte in der zu entwickelnden Software zu 14

15 tracken und zu organisieren. Ersetzt er aber die zwischenmenschliche Kommunikation, führt er eher zu sinkender Produktivität und Unmut im Team. 3 Working software over comprehensive documentation Warum ist lauffähige Software wichtiger als Dokumentation? Die abstrakte Antwort ist ganz einfach: Weil Software wertschöpfend ist und Dokumentation nicht. 4 Wichtig ist, dass sich hier Dokumentation nicht auf die Dokumentation der Software - für den User oder für andere Entwickler - bezieht, sondern auf die Dokumentation, die in klassischen Software Entwicklungsmodellen vor der eigentlichen Entwicklung entsteht., also etwa das Nutzerkonzept und die technische Spezifikation. Beide haben auch in der agilen Software Entwicklung durchaus ihren Nutzen, sind aber eben nicht so wichtig wie lauffähige Software. Ein konkretes Beispiel: Es soll eine Software zur Verwaltung von Kundendaten (Anlegen, Ändern, Suchen, Löschen) entwickelt werden. Man kann nun entweder im ersten Monat das (vollständige) Nutzerkonzept erstellen, oder - nach einer kurzen, gemeinsamen Ausarbeitung der zentralen Anforderungen - mit der Implementierung beginnen und am Ende das Monats das Modul zum Anlegen von Kundendaten als lauffähige Software deployt haben. Die agile Software Entwicklung bevorzugt eindeutig die zweite Option, denn nur diese hat einen Wert am Ende des ersten Monats erzeugt: es kann mit der Eingabe von Kundendaten begonnen werden. Das Ergebnis der ersten Option ist aber ausserhalb des Projekts nicht von Relevanz. Lauffähige Software ist einer der wichtigsten, aber auch der kniffeligsten Aspekte von agiler Software Entwicklung. Denn wann genau ist denn eine Software lauffähig, beziehungsweise fertig ( done )? Dies muss von Projekt zu Projekt neu festgelegt werden und erfordert auf der einen Seite viel Wissen aus der Fachdomäne und auf der anderen Seite viel Wissen über technische Aspekte wie Wartbarkeit, Skalierbarkeit und Performanz von Software. Zwei Beispiele sollen dies illustrieren: Ein Computerspiel ist fertig, wenn die Funktionalität umgesetzt wurde, es bugfrei ist, es auf der geforderten Minimal-Hardware performant genug funktioniert, die Server n Kunden auf einmal aushalten (und schnell erweitert werden können), etc. Die Wartbarkeit ist hier u.u. nicht so wichtig (vielleicht ist weder eine Erweiterung noch ein Nachfolger geplant). Eine Software zur Steuerung einer Maschine, welche Medikamente herstellt, ist fertig, wenn die Funktionalität umgesetzt wurde, sie bugfrei ist, die Dokumente für die FDA 5 vorliegen, der Source- Code auf 30 Jahre hin archiviert wurde, die Software so dokumentiert ist, dass ein völlig neues Team in 10 Jahren in der Lage ist einen Bug zu fixen, usw. Skalierung ist hier hingegen kein Thema. Customer collaboration over contract negotiation Die Basis für die meisten Software Produkte ist eine Zusammenarbeit zwischen dem Auftraggeber - ob externer Kunde oder Produktmanager - und dem Entwicklungsteam. Der Auftraggeber kennt die Anforderungen an die Software, die Business Domäne und das Umfeld (oder den Markt), in dem die Software eingesetzt werden. Das Entwicklungsteam bringt das notwendige 3 Ein konkretes Beispiel ist eine Assignment-Eskalation, bei der ein Bug ständig zwischen zwei Teams hin- und hergeschoben wird, da sich niemand wirklich zuständig fühlt. Ein einfaches Telefonat zweier Entwickler löst dieses Problem i.d.r. innerhalb von Minuten. 4 Ansonsten sollte man nicht primär Software Entwickler beschäftigen, sondern Autoren. 5 Food & Drug Association in den USA 15

16 technische Know-How mit, um die Vorstellungen des Auftraggebers in die Tat umzusetzen. Beide sind nur gemeinsam in der Lage, wertschöpfend tätig zu sein. Diese Zusammenarbeit funktioniert nur dann optimal, wenn beide versuchen, dasselbe Ziel zu erreichen. Dieses Ziel kann nur dann in optimaler Art und Weise erreicht werden, wenn auf dem Weg auftretende Hindernisse schnell und unkompliziert aus dem Weg geräumt werden können. Besteht eine harmonierende, wohlwollende Kommunikationsbeziehung zwischen Auftraggeber und Entwicklungsteam, ist dies in der Regel leicht möglich. Ist dies aber nicht der Fall, arten einfache Differenzen schnell aus: das Vergessen der Enter- Taste beim Login-Dialog führt dann leicht zu einer zeitraubenden, hässlichen Grundlagendiskussion über den notwendigen Detailgrad bei Nutzerkonzepten. Fühlt sich dann noch die eine Seite übervorteilt, wird oft sogar der gesunde Menschenverstand ausgeschaltet: Das steht da nicht, also mache ich das auch nicht. Verträge können eine gute Grundlage für eine (Kommunikations-)Beziehung sein, insbesondere dann, wenn die beiden Parteien das erste Mal zusammenarbeiten. Sie sind aber auch i.d.r. nur mit extremem Aufwand anzupassen und bieten damit nicht die genügende Flexibilität, um als primäres Kommunikationsmittel eingesetzt zu werden. Responding to change over following a plan Das größte Risiko für die meisten Projekte ist, das falsche Produkt zu entwickeln. [Pichler, 2008] In der IT Industrie gibt es nahezu täglich große Änderungen 6. Google bringt ohne vorherige Ankündigung einen neuen Browser auf den Markt. Apple betritt mit dem iphone völlig überraschend den Mobilfunksektor. Python 3.0 ist nicht mehr abwärtskompatibel zu vorherigen Versionen. Solche Änderungen können großen Einfluss auf laufende Software Entwicklungsprojekte haben. Eine Web-Applikation, die nicht mit Google Chrome funktioniert, kann nicht wie geplant gelauncht werden. Java ME als technologische Basis für die eigene Mobile Applikation steht plötzlich in Frage. Für eine Portierung der gesamten Codebasis auf Python 3.0 muss Geld und Zeit gefunden werden. Auch Veränderung innerhalb der eigenen Firma oder sogar innerhalb des eigenen Projektes sind oft nicht vorhersehbar. Die Übernahme eines Konkurrenten führt z.b. in der Regel dazu, dass laufende Projekte gründlich ob der Validität ihrer Ziele überprüft werden müssen. Auch Mitarbeiterwechsel - z.b. durch Kündigung - können sehr großen Einfluss auf die Laufzeit von Projekten haben (insbesondere wenn man die individuelle Leistungsfähigkeit verschiedener Software Entwickler berücksichtigt; s.o.). Während in klassischen Software Entwicklungsmodellen diese Punkte unter dem Stichwort Risiko Management laufen und man versuchen würde sie im Vorfeld (vor dem Start der Entwicklungsphase) zu identifizieren und zu bewerten, geht die agile Software Entwicklung hier einen anderen Weg. Agile Entwicklungsmodelle müssen in der Lage sein, mit beliebigen Änderungen umzugehen, also insbesondere mit solchen, die man im Vorfeld nicht antizipiert hat. Auch hier gilt natürlich, dass es schon von Wert ist, einen Plan zu haben. Dieser sollte aber nicht so starr sein, dass die einzige mögliche Reaktion auf eine Änderung eine vollständige Neuplanung ist. 6 Optimisten nennen das Fortschritt. 16

17 (Unbequeme) Wahrheiten Die vier Werte des Agile Manifesto enthalten zum Teil Aussagen, die für klassische Modelle schwer zu akzeptieren sind: I. Software Entwickler sind Individuen und damit nicht beliebig austauschbar. II. Man kommt nur gemeinsam zum Ziel. Es ist nicht zielführend, 7 sich damit zu beschäftigen, im Falle eines Scheiterns nicht Schuld gewesen zu sein. III. Unvorhergesehenes wird passieren und auf das Projekt Einfluss nehmen. Während die klassische Software Entwicklung eher versucht, diese Punkte zu eliminieren oder zu beherrschen, geht die agile Entwicklung einen anderen Weg. Sie fordert diese Punkte als gegeben zu akzeptieren und das eigene Vorgehen darauf anzupassen. Dies kommt sehr schön im Motto von extreme Programming zum Ausdruck: Embrace Change! Extreme Programming Extreme Programming (XP) ist eine konkretes Vorgehensmodell, um agile Software zu entwickeln. D.h., es bewegt sich im Rahmen des, durch die im vorherigen Abschnitt vorgestellten Werte definierten, Bereiches für agile Entwicklungsmodelle. Entstehung XP wurde 1996 von Kent Beck im Rahmen eines Projektes bei Chrysler entwickelt 8. Beck bekam die Aufgabe, ein von immerzu neuen Releaseverschiebungen geplagtes Projekt zu retten. Er tat dies, in dem er mit dem selben Team das Projekt vollständig neu aufsetzte und gleichzeitig drei Praktiken einführte, die später zu wesentlichen Bestandteilen des XP-Modells werden sollten: I. kurze 9 Entwicklungszyklen (Iterationen) II. III. Planung mittels so genannter User Stories Lieferung von fertiger Software am Ende jeder Iteration Aufbau XP basiert auf einem dreistufigen System von Werten, Prinzipien und Praktiken. Werte geben Orientierungspunkte vor und versuchen zu beschreiben, gegenüber welchen abstrakten Zielen sich XP verpflichtet fühlt. Praktiken sind konkrete Handlungsweisen, deren Anwendung hilft, sich den Werten entsprechend zu verhalten. Prinzipien stellen das Bindeglied zwischen den abstrakten Werten und den konkreten Praktiken dar. Sie helfen, neue Praktiken zu erstellen, die im Einklang mit den Werten stehen und können auch als Hilfe zum Verständnis einzelner Praktiken dienen, indem sie die Verbindung zwischen dieser Praktik und einem oder mehreren Werten aufzeigen. 7 im wahrsten Sinne des Wortes 8 Wenn nicht anders angegeben, bezieht sich der gesamte Abschnitt über XP auf [Beck, 2004]. 9 bei Chrysler 3 Wochen 17

18 In diesem Text wird ein Fokus auf einzelne Praktiken gelegt. Die Werte werden kurz diskutiert. Für eine Diskussion der Prinzipien sei auf [Beck, 2004] verwiesen. Werte In XP werden fünf Werte identifiziert, welche die Arbeit mit XP charakterisieren. Kommunikation Rückkopplung Einfachheit Mut Respekt Kommunikation und Einfachheit lassen sich direkt in Beziehung setzen zu Individuals and interactions... und Working software... aus dem Agile Manifesto. Rückkopplung 10 ist die Forderung nach dem Umgang mit Veränderung entsprechend dem Responding to change... aus dem Agile Manifesto. Mut 11 meint hier die Eigenschaft, Missstände nicht einfach zu akzeptieren, nicht zu resignieren, sondern Herausforderungen zu akzeptieren. Respekt bezieht sich auf den Umgang mit anderen Menschen, mit Kollegen, Vorgesetzten und Kunden. Es wird Respekt für ihre Überzeugungen, Meinungen und Arbeitsweisen gefordert. Prinzipien Menschlichkeit Wirtschaflichkeit Win/Win Selbstähnlichkeit Verbesserung Vielfältigkeit Reflektion Flow Gelegenheit Redundanz Defekt Qualität kleine Schritte akzeptierte Verantwortung ( Flow bezieht hierbei auf das Konzept aus [Csikszentmihalyi, 1991].) 10 Im englischen Feedback 11 im englischen Courage 18

19 Praktiken physische Nähe Puffer Team verkleinern ein Team 10 Minuten Build Root-Cause Analysis ständige Transparenz Continuous Integration gemeinsamer Code effektives Arbeiten Test-First nur Code & Tests Pair Programming inkrementelles Design keine Branches User Stories Kundeneinbindung tägliches Deployment wöchentlicher Rhythmus inkrementelles Deployment inkrementelle Verträge Quartals Planungen konstante Teams Pay-Per-Use Diese Praktiken stellen konkrete Handlungsweisen dar, welche in der Praxis erprobt sind und welche dazu führen, dass ein Vorgehensmodell etabliert wird, was sich innerhalb des XP- Werterahmens bewegt. Im Folgenden werden einige der wichtigsten Praktiken vorgestellt. Sie bilden die Grundlage eines nach dem XP-Modell agierenden Software Entwicklungsteams. User Stories User Stories sind in XP die Einheit der Planung. Eine User Story beschreibt einen konkreten Aspekt des zu entwickelnden Produktes. Beispiel Als Mail Benutzer möchte ich Filterregeln anlegen können, so dass meine Inbox übersichtlich bleibt. User Stories sind i.d.r. dreiteilig aufgebaut. Sie enthalten: I. Die Rolle des Sprechers (hier Mail Benutzer ) II. III. Die Aktivität, die ausgeführt werden können soll (hier Filterregeln anlegen ) Das Ziel, welches damit erreicht werden soll (hier aufgeräumte Inbox ) User Stories grenzen sich damit ab von Usecases, denn sie beschreiben immer nur einen konkreten Handlungspfad und versuchen nicht, einen ganzen Raum von Handlungsmöglichkeiten zu beschreiben. Wichtig ist hier auch das Spannungsfeld zwischen Aktivität und Ziel. Dieses ist während der Planungsphase (s.u.) ein guter Ansatzpunkt für Diskussionen, denn oft verknüpfen die Empfänger einer User Story (z.b. die Entwickler, welche die Story umsetzen sollen) mit der Tätigkeit ein ganz anderes Ziel (oder umgekehrt). Die resultierende Diskussion dient dann zum einen der Klärung von Missverständnissen, zum anderen aber auch der Identifikation von Synergieeffekten, z.b. wenn die Entwickler eine Möglichkeit sehen, zwei Ziele (aus zwei User Stories) mit ein und derselben Implementierung zu lösen. User Stories kann man in unterschiedlichen Granularitätsstufen formulieren. Die oben angegebene User Story ist eher grobgranular: um z.b. ihren Implementierungsaufwand abzuschätzen ist es notwendig, sie in viele kleine Arbeitspakte (bei XP Tasks genannt) zu zerlegen. Formuliert man 19

20 User Stories sehr feingranular, entfällt im Idealfall der Zwischenschritt über Arbeitspakete ganz. Die Stories können dann direkt in Code umgesetzt werden. In XP gibt es eine Abneigung dagegen, User Stories elektronisch festzuhalten. Der bevorzugte Weg sind Karteikarten (DIN A7). Diese bieten mehrere Vorteile gegenüber einer elektronischen Erfassung: Sie erzwingen Einfachheit, da sie nur begrenzten Raum für die Formulierung bieten. Sie erzeugen unmittelbare Transparenz über das Projekt für alle Beteiligten (und Interessierten), in dem man die gerade aktiven User Stories an eine Pinnwand in unmittelbarer Nähe des Teams heftet. Man kann mit ihnen physisch planen (etwa auf einem Tisch), durch zeitliche Anordnung Anordnung nach Abhängigkeiten thematische Anordnung mischen... Rhythmus XP versucht einen Rhythmus 12 in der Software Entwicklung zu etablieren. Dies dient vielfältigen Zielen. Zum Einen hilft ein Rhythmus, Flow zu erzeugen [Csikszentmihalyi, 1991], zum anderen dient er direkt der Einfachheit und Transparenz. Die beiden wesentlichen Taktgeber für den Rhythmus in XP sind wöchentliche Iterationen und Quartalszyklen. In wöchentlichen Iterationen wird die Weiterentwicklung der Software geplant und umgesetzt, jede Woche kulminierend in einem Release des Produktes. Quartalszyklen werden verwendet, um die (High-Level-) Planung mit der Realität abzugleichen, Themenschwerpunkte zu ändern und den eigenen Prozess auf den Prüfstand zu stellen. Beide laufen nach demselben Muster ab: zuerst erfolgt in einem Review eine Evaluierung des Erreichten im Falle der Iterationen eine Abnahme der fertiggestellten Software, im Falle der Quartalszyklen ein eher klassisches Projekt- und Teamreview und im Anschluss eine Planung des Zukünftigen. Planen Planungen in XP folgen immer demselben Muster, unabhängig davon, ob sie im Rahmen einer Iterations- oder Quartalsplanung stattfinden; es ändert sich nur die Granularität der jeweiligen Planartefakte: 12 im englischen oft Beat 20

SOFTWARETECHNIK & ENTWICKLUNGSWERKZEUGE

SOFTWARETECHNIK & ENTWICKLUNGSWERKZEUGE Collin Rogowski SOFTWARETECHNIK & ENTWICKLUNGSWERKZEUGE Veranstaltung im WS 2009/10, Duale Hochschule Baden-Württemberg, Karlsruhe - Skript - 1 Software Engineering 6 Software Entwicklung als eigenständige

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

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

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

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

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

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

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

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

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

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

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

SCRUM. Software Development Process

SCRUM. Software Development Process SCRUM Software Development Process WPW 07.08.2012 SCRUM Poster www.scrum-poster.de Was ist Scrum? Extrem Schlanker Prozess 3 Rollen 4 Artefakte Wenige Regeln Die Rollen Product Owner Der Product Owner

Mehr

Einführung in Scrum. Agiles Projektmanagement. Martin Krüger 27.04.2011 Entwicklung von Workflowanwendungen

Einführung in Scrum. Agiles Projektmanagement. Martin Krüger 27.04.2011 Entwicklung von Workflowanwendungen Einführung in Scrum Agiles Projektmanagement Martin Krüger 27.04.2011 Entwicklung von Workflowanwendungen Warum Agiles Projektmanagement? Scrum Empfehlungen Das Seminar Planbarkeit Warum Agiles Projektmanagement?

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

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

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

Agiles Schätzen. Quelle: Kap. 7 aus Wie schätzt man in agilen Projekten oder wieso Scrum-Projekte erfolgreicher sind [Boris Gloger 2014]

Agiles Schätzen. Quelle: Kap. 7 aus Wie schätzt man in agilen Projekten oder wieso Scrum-Projekte erfolgreicher sind [Boris Gloger 2014] Agiles Schätzen Quelle: Kap. 7 aus Wie schätzt man in agilen Projekten oder wieso Scrum-Projekte erfolgreicher sind [Boris Gloger 2014] Schätzen der Größe Wir bestimmen die Größe, nicht den Aufwand. Auf

Mehr

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Agile Methoden als Diagnose-Tool für den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Über mich Berufliche Erfahrung 3 Jahre Projektabwicklung 2 Jahre

Mehr

Software-Dokumentation im agilen Umfeld. Marion Bröer, parson communication

Software-Dokumentation im agilen Umfeld. Marion Bröer, parson communication Software-Dokumentation im agilen Umfeld Marion Bröer, parson communication parson communication Software- und Prozessdokumentation Wissensmanagement Wikis und XML-basierte Dokumentation Schulungen und

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

Agilo [1] ist ein auf Trac [2] basierendes Scrum [3] Tool. Im Folgenden soll eine kurze Überischt gegeben werden, wie Agilo benutzt wird.

Agilo [1] ist ein auf Trac [2] basierendes Scrum [3] Tool. Im Folgenden soll eine kurze Überischt gegeben werden, wie Agilo benutzt wird. AGILO HOWTO Agilo [1] ist ein auf Trac [2] basierendes Scrum [3] Tool. Im Folgenden soll eine kurze Überischt gegeben werden, wie Agilo benutzt wird. ROLLEN IM TEAM In Scrum hat jedes Teammitglied eine

Mehr

Scrum Team Diagnose. Gibt es sonst noch etwas, was du zur Rolle des Product Owners sagen möchtest?

Scrum Team Diagnose. Gibt es sonst noch etwas, was du zur Rolle des Product Owners sagen möchtest? Scrum Rollen Product Owner (PO) Der PO ist klar definiert Der PO übersetzt Anforderungen in klare Backlog Items Der PO ist ermächtigt, Backlog Items zu priorisieren Der PO verfügt über das Fachwissen,

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

Wahlpflichtmodul Projekt I Softwareprojekt I

Wahlpflichtmodul Projekt I Softwareprojekt I Wahlpflichtmodul Projekt I Softwareprojekt I Dipl. Inf. Andrea Meyer SCRUM in Detail Dipl. Inf. Andrea Meyer WIEDERHOLUNG 4 Prinzipien von SCRUM Zerlegung Transparenz Anpassung Überprüfung WIEDERHOLUNG

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

Checkliste für Scrum-Meetings

Checkliste für Scrum-Meetings Checkliste für Scrum-Meetings Gesamtdarstellung 2 Produktvision teilen 3 Estimating 4 Planning 1 - Das WAS 5 Planning 2 - Das WIE 6 Daily Scrum 7 Das Review 8 Die Retrospektive 9 Artefakte 10 GOagile!

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

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

Ü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

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

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

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

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

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

Agile Management Einführung in agiles Management

Agile Management Einführung in agiles Management Agile Management Einführung in agiles Management Agile Management Agile Management-Methoden Einführung Agile Management PQRST e.u. - Ing. Erich Freitag Version 25.06.2013 Lernziele Den Unterschied zwischen

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

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

Requirements Engineering für die agile Softwareentwicklung

Requirements Engineering für die agile Softwareentwicklung Johannes Bergsmann Requirements Engineering für die agile Softwareentwicklung Methoden, Techniken und Strategien Unter Mitwirkung von Markus Unterauer dpunkt.verlag Inhaltsverzeichnis 1 Einleitung 1 1.1

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

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

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

Wie funktioniert agile Software-

Wie funktioniert agile Software- Wie funktioniert agile Software- Entwicklung mit SCRUM Zürich, 8. Mai 008 Jean-Pierre König, namics ag Software Engineer Bern, Frankfurt, Hamburg, München, St. Gallen, Zug, Zürich www.namics.com Agenda»

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

Agiles Testmanagment. Hugo Beerli bbv Software Services AG. Luzern, September 2011. www.bbv.ch

Agiles Testmanagment. Hugo Beerli bbv Software Services AG. Luzern, September 2011. www.bbv.ch Agiles Testmanagment Hugo Beerli bbv Software Services AG Luzern, September 2011 Product Backlog (Agenda) 1) Warum System Tests 2) Agile Arbeitsmethode Stand up Meeting 3) Vorteile der agilen Methode 4)

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

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

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

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

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

Scrum. Eine Einführung

Scrum. Eine Einführung Scrum Eine Einführung Scrum-Charakteristika einfache Regeln wenige Rollen Pragmatismus statt Dogmatik iteratives Vorgehen Scrum auf einer Seite erklärt 3 Rollen für direkt am Prozeß beteiligte 1) Product

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

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

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

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

Are you Agile. SAQ Zug um Zug, 27. November 2008. Agilität: Was bringen Sie mit? Was wissen Sie schon? Was wollen Sie heute Abend mitnehmen?

Are you Agile. SAQ Zug um Zug, 27. November 2008. Agilität: Was bringen Sie mit? Was wissen Sie schon? Was wollen Sie heute Abend mitnehmen? ? SAQ Zug um Zug, Agilität: Was bringen Sie mit? Was wissen Sie schon? Was wollen Sie heute Abend mitnehmen? Folie 1 hat sich als Projektleiter während acht Jahren dafür eingesetzt, Ende Iteration lauffähige

Mehr

SCRUM. Legalisierung der Hackerei? GI Regionalgruppe Dortmund 07.12.2009 Dipl.-Inform. (FH) Dirk Prüter. Dirk.Prueter@gmx.de

SCRUM. Legalisierung der Hackerei? GI Regionalgruppe Dortmund 07.12.2009 Dipl.-Inform. (FH) Dirk Prüter. Dirk.Prueter@gmx.de SCRUM Legalisierung der Hackerei? GI Regionalgruppe Dortmund 07.12.2009 Dipl.-Inform. (FH) Dirk Prüter Dirk.Prueter@gmx.de Überblick Was ist SCRUM Wie funktioniert SCRUM Warum lohnt es sich, SCRUM anzuwenden

Mehr

Grob- und Detailplanung bei der Implementierung nutzen

Grob- und Detailplanung bei der Implementierung nutzen Softwarearchitektur Grob- und Detailplanung bei der Implementierung nutzen Bereich Realisierung Aktivität Softwareinkrement realisieren Ziele Vermitteln einer Orientierungshilfe für alle Entwickler Etablierung

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

Der Business Analyst in der Rolle des agilen Product Owners

Der Business Analyst in der Rolle des agilen Product Owners Der Business Analyst in der Rolle des agilen Owners HOOD GmbH Susanne Mühlbauer Büro München Keltenring 7 82041 Oberhaching Germany Tel: 0049 89 4512 53 0 www.hood-group.com -1- Inhalte Agile Software

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

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

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

Sabotage in Scrum. dem Prozess erfolglos ins Knie schiessen. Andreas Leidig (andrena objects ag) Vortrag bei den XP Days 2007

Sabotage in Scrum. dem Prozess erfolglos ins Knie schiessen. Andreas Leidig (andrena objects ag) Vortrag bei den XP Days 2007 Sabotage in Scrum dem Prozess erfolglos ins Knie schiessen Andreas Leidig (andrena objects ag) Vortrag bei den XP Days 2007 1 Überblick Sabotage? Wer kann sabotieren? Was kann sabotiert werden? Wieviel

Mehr

Praxisbericht und Demo-Projektabwicklung mit der ATLASSIAN Toolchain und Continuous Integration. Markus Stollenwerk, Noser Engineering AG

Praxisbericht und Demo-Projektabwicklung mit der ATLASSIAN Toolchain und Continuous Integration. Markus Stollenwerk, Noser Engineering AG Praxisbericht und Demo-Projektabwicklung mit der ATLASSIAN Toolchain und Continuous Integration Markus Stollenwerk, Noser Engineering AG Agile Softwareentwicklung Crash-Kurs Markus Stollenwerk, 27.9.2013

Mehr

RE-Metriken in SCRUM. Michael Mainik

RE-Metriken in SCRUM. Michael Mainik RE-Metriken in SCRUM Michael Mainik Inhalt Agile Methoden Was ist SCRUM? Eine kurze Wiederholung Metriken Burn Down Graph Richtig schätzen Running Tested Features WBS/ Earned Business Value Business Value

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

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

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

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

Susanne Muehlbauer 29. November 2011

Susanne Muehlbauer 29. November 2011 Machen Sie noch Modellierung Anforderungsmanagement oder sind Sie schon READY for SCRUM? Susanne Muehlbauer 29. Wer ist HOOD unser Geschäftsfeld Der Einsatz von Requirements Engineering und kontinuierliche

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

VORLESUNG NEUERE KONZEPTE P-MANAGEMENT THEMA: PROJEKTMANAGEMENT IN AGILEN PROJEKTEN. Oliver Kühn

VORLESUNG NEUERE KONZEPTE P-MANAGEMENT THEMA: PROJEKTMANAGEMENT IN AGILEN PROJEKTEN. Oliver Kühn VORLESUNG NEUERE KONZEPTE P-MANAGEMENT THEMA: PROJEKTMANAGEMENT IN AGILEN PROJEKTEN Oliver Kühn Agenda 2 Projektmanagement in agilen Projekten Agiles Projektmanagment Scrum-Methode Konventionelle Projektorganisation

Mehr

Iterativ. Inkrementell

Iterativ. Inkrementell Iterativ Inkrementell Build Release Test Qualität Architektur & Documentation Distributed Version Control Continuous Integration TDD Design Agile Architektur Dependency Feature Branches Mocks

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

Agile Methoden vs. Testen

Agile Methoden vs. Testen Agile Methoden vs. Testen cc gmbh Bernhard Moritz CC GmbH TAV 27, AK Testmanagement, 6.6.2008 Bernhard Moritz Flachstraße 13 65197 Wiesbaden Telefon 0611 94204-0 Telefax 0611 94204-44 Bernhard.Moritz@cc-gmbh.de

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

Projektmanagement durch Scrum-Proxies

Projektmanagement durch Scrum-Proxies Cologne Intelligence GmbH Projektmanagement durch Scrum-Proxies Integration von Vorgehensmodellen und Projektmanagement 17. Workshop der Fachgruppe WI-VM der Gesellschaft für Informatik e.v. Stuttgart,

Mehr

AGILES QUALITÄTSMANAGEMENT

AGILES QUALITÄTSMANAGEMENT AGILES QUALITÄTSMANAGEMENT Manfred Rätzmann Head of Department Quality Assurance Deutsche Post E-Post Development GmbH Manfred.Raetzmann@epost-dev.de http://www.epost.de/ Klassische Ziele des Qualitätsmanagements:

Mehr

Bekannte Tools in einem agilen Ansatz. Frank Schwichtenberg SourceTalkTage 2013 Göttingen, 2.10.2013

Bekannte Tools in einem agilen Ansatz. Frank Schwichtenberg SourceTalkTage 2013 Göttingen, 2.10.2013 Bekannte Tools in einem agilen Ansatz Frank Schwichtenberg SourceTalkTage 2013 Göttingen, 2.10.2013 Vorher Lange Planungszeiten und Releasezyklen Manche Features brauchten lange und wurden nicht gebraucht

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

Einführung in das Scrum Framework & welche 10 Praktiken helfen, Scrum wirklich gut zu machen

Einführung in das Scrum Framework & welche 10 Praktiken helfen, Scrum wirklich gut zu machen Einführung in das Scrum Framework & welche 10 Praktiken helfen, Scrum wirklich gut zu machen Wer bin ich Kurse und Vorträge mit Jeff Sutherland und Ken Schwaber Verschiedene Kurse der Scrum.org Professional

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

Dysfunctional Team Game

Dysfunctional Team Game Dysfunctional Team Game Eine Einführung Zusammenfassung Autor: Berthold Barth communicode AG Agile Coach & Scrum Master Brand Manager Geek Dad Skype: bertholdbarth mail@berthold-barth.de http://www.berthold-barth.de

Mehr

Permanente Integration Einstellung und Prozess versus Werkzeuge

Permanente Integration Einstellung und Prozess versus Werkzeuge Consulting Guild AG Methodenberatung für Projekte im 21. Jahrhundert Permanente Integration Einstellung und Prozess versus Werkzeuge Inhalt: Einleitung 1 Worum geht's hier überhaupt? 2 Überblick 2 Permanente

Mehr

Projektmanagement. Vorlesung von Thomas Patzelt 8. Vorlesung

Projektmanagement. Vorlesung von Thomas Patzelt 8. Vorlesung Projektmanagement Vorlesung von Thomas Patzelt 8. Vorlesung 1 Möglicher Zeitplan, Variante 3 26.03. Vorlesung 1, Übung Gr.2 28.05. Keine Vorlesung, Pfingstmontag 02.04. Keine Vorlesung, Hochschultag 04.06.

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

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

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 nach Scrum mit Projektron BCS - Erfahrungsaustausch -

Agiles Projektmanagement nach Scrum mit Projektron BCS - Erfahrungsaustausch - Agiles Projektmanagement nach Scrum mit Projektron BCS - Erfahrungsaustausch - Prof. Dr. Roland Petrasch, Beuth Hochschule für Technik prof.beuth-hochschule.de/petrasch Stefan Lützkendorf Projektron GmbH

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

FALLSTRICKE IM AGILEN ANFORDERUNGSMANAGEMENT ODER WIE BEKOMME ICH MIT USER STORIES VON DEN GEEKS WAS ICH WILL?

FALLSTRICKE IM AGILEN ANFORDERUNGSMANAGEMENT ODER WIE BEKOMME ICH MIT USER STORIES VON DEN GEEKS WAS ICH WILL? FALLSTRICKE IM AGILEN ANFORDERUNGSMANAGEMENT ODER WIE BEKOMME ICH MIT USER STORIES VON DEN GEEKS WAS ICH WILL? Steffen Thols - REConf 2012 07.03.2012 2 ÜBER MICH Name : Steffen Thols Berufserfahrung: Einige

Mehr

Scrum - Von Schweinchen und Hühnchen

Scrum - Von Schweinchen und Hühnchen 4. November 2009 - Actinet IT-Services 1986 erster Computer 1990 Erstes Programm (Kleinster Gemeinsamer Teiler - Basic) 2000 Informatik Studium + Firmengründung 2007 Umorientierung - Software Development

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

IT-Projektmanagement bei basecom. Manuel Wortmann, Patrick Rolefs

IT-Projektmanagement bei basecom. Manuel Wortmann, Patrick Rolefs IT-Projektmanagement bei basecom Manuel Wortmann, Patrick Rolefs Vorstellrunde Mein Name ist, ich bin Jahre alt und mache meine Ausbildung bei. Übersicht wir sprechen internet Wasserfall - schön linear

Mehr

RELEASE AUF KNOPFDRUCK: MIT CONTINUOUS DELIVERY KOMMEN SIE SCHNELLER ANS ZIEL.

RELEASE AUF KNOPFDRUCK: MIT CONTINUOUS DELIVERY KOMMEN SIE SCHNELLER ANS ZIEL. RELEASE AUF KNOPFDRUCK: MIT CONTINUOUS DELIVERY KOMMEN SIE SCHNELLER ANS ZIEL. Die Erwartungen Ihrer Businesskunden an ihre IT steigen. Mehr denn je kommt es darauf an, die Software optimal am Kunden auszurichten

Mehr