Extreme Programming Agilität in der Softwareentwicklung

Größe: px
Ab Seite anzeigen:

Download "Extreme Programming Agilität in der Softwareentwicklung"

Transkript

1 Westfälische Wilhelms-Universität Münster Ausarbeitung Extreme Programming Agilität in der Softwareentwicklung im Rahmen des Seminars Software Management Jan Ernsting Themensteller: Prof. Dr. Herbert Kuchen Betreuer: Susanne Gruttmann Institut für Wirtschaftsinformatik Praktische Informatik in der Wirtschaft

2 Inhaltsverzeichnis 1 Motivation zur agilen Softwareentwicklung 1 2 Agilität und Modelle der Softwareentwicklung Agilität Wasserfall-Modell Extreme Programming Ausschnitt der XP-Techniken Programmieren in Paaren Testen Refactoring Einfaches Design Überblick der Abhängigkeiten Rahmenbedingungen für XP Management-Strategien im XP Coaching Planung XP als Evolutionstreiber 21 Literaturverzeichnis 22 i

3 Kapitel 1: Motivation zur agilen Softwareentwicklung 1 Motivation zur agilen Softwareentwicklung Das Verhältnis von Endanwendern und Entwicklern ist oft sehr angespannt. Falsch umgesetzte Anforderungen oder Mängel in Anwendungen sind nur ein Teil der Gründe für die Anspannung der beiden Gruppen. Das traditionelle Entwicklungsmodell weiß damit nur schwerlich umzugehen, da ein Pflichtenheft typischerweise den Umfang eines Systems festlegt und nach der Interpretation des Entwicklers implementiert wird. Zum Ende der Anwendungsentwicklung in diesem Umfeld werden dann häufig noch die Testaktivitäten verkürzt oder unter extremen Zeitdruck ausgeführt, sodass Mängel unter Umständen erst am Arbeitsplatz des Anwenders ersichtlich werden. Statt eine Punktladung zum Ende eines Projektes zu erwarten, sind Feedback- Mechanismen während der Entwicklung sinnvoll, die den Anwender mit einspannen, um Anforderungen optimal umzusetzen, sodass die Akzeptanz des Systems maximiert werden kann und den Anwender bei seiner Arbeit bestmöglich unterstützt. Dadurch kann das Verhältnis der Endanwender und Entwickler entspannt werden und bildet eine Grundlage, um gegenseitiges Misstrauen abzubauen und in wertvolles Vertrauen umzuwandeln, das bspw. langwierige Vertragsgespräche wie ein Relikt vergangener Zeiten wirken lässt. Das Prozessmodell des Extreme Programming (Abk. XP) bildet einen agilen Ansatz zur Softwareentwicklung. Es beinhaltet unter anderem die angesprochenen Feedback-Zyklen, aber auch Praktiken, die auf die Maximierung der Anwendungs- Qualität abzielen. So ist XP geeignet, um komplexere Systeme für Anwender und Kunden zu entwickeln und dabei die Kunden-Anforderungen nach bestem Vermögen umzusetzen. Um im Rahmen dieser Seminararbeit aufzuzeigen, wie Extreme Programming den Entwicklungs-Prozess stärken kann, werden zunächst grundlegende Strategieziele der Softwareentwicklung aufgezeigt. Daraufhin wird Agilität sowohl im Betriebswirtschaftlichen als auch im Speziellen also der Softwareentwicklung vorgestellt und erläutert. Als verbreitetes Modell wird dann das Wasserfall-Modell als Referenz positioniert. Ausgehend von dem zweiten Kapitel wird Extreme Programming in der ersten Version kurz umschrieben, um dann im Detail darauf einzugehen, wie XP-Praktiken dazu beitragen die marginalen Aufwände in der Softwareentwicklung zu stabilisieren. Letztlich werden Schwierigkeiten, in Bezug auf die Abhängigkeiten der Techniken untereinander, skizziert und Extreme Programming spezifische Management- Strategien vorgestellt. 1

4 Kapitel 2: Agilität und Modelle der Softwareentwicklung 2 Agilität und Modelle der Softwareentwicklung Das Software Management stellt einen wesentlichen Erfolgsfaktor bei der Erstellung einer Anwendung dar. Grady unterscheidet drei Management-Strategien, die er als wichtig hervorhebt [Gr92, S. 22]; in Ahnlehnung an Grady hat Balzert die Ziele dieser primären Strategien wie folgt aufgelistet [Ba98, S. 4]: Maximierung der Kundenzufriedenheit, Minimierung des Aufwands und der Zeit der Software-Erstellung, Minimierung von Fehlern. Ein Unternehmen kann sich je nach Umweltsituation entscheiden, ihre Entwicklung stärker nach einer Strategie als nach einer anderen auszurichten. Veranschaulichend kann die Strategieausrichtung einer Entwicklung in einem gleichseitigen Dreieck dargestellt werden. Die einzelnen Strategien bilden zu diesem Zwecke die Ecken. Abbildung 1: Teufelsquadrat [Sn05, S. 38] Das Teufelsquadrat nach Sneed bildet die vier üblichen Projektparameter, Qualität, Quantität, Aufwand und Projektdauer, auf die Ecken eines Quadrates wie in Abbildung 1 ab. Unter dem Begriff der Quantität wird der Umfang eines Systems verstanden. Der Aufwand repräsentiert die Ressourcen, die zum Einsatz kommen. Die Projektdauer und die Qualität bedürfen keiner weiteren Erklärung. Der grau, schattierte Bereich ist in der Flächengröße fixiert und drückt die Produktivität aus, die pro Zeiteinheit von einem Projektmiglied erbracht werden kann. Zwei Parameter können optimiert werden, die jeweils anderen beiden passen sich entsprechend an, sodass die Größe der Produktivitätsfläche unverändert bleibt, nicht jedoch seine Form [Sn05, S. 38f.]. 2

5 Kapitel 2: Agilität und Modelle der Softwareentwicklung 2.1 Agilität In der Betriebswirtschaftslehre ist Agilität als ein Erfolgsfaktor einer Organisation bestimmt. Eine Organisation wird als agil definiert, wenn sie adaptiv, aktiv und flexibel ist sowie mit der Unsicherheit ihrer Umwelt umgehen kann und wandlungsfähig ist. In Zeiten schnelllebiger Märkte und kurzer Produktzyklen ist es wichtig für Unternehmen Chancen und Risiken zu erkennen und sie bewusst wahrzunehmen [DK08, S. 40]. Zur Agilität in der Softwareentwicklung hat die Agile Alliance spezifischer 17 Personen, die agile Software-Praktiken beeinflusst haben ein Manifest verfasst. In dem Manifest werden Werte 1 gegeneinander abgewogen, die einen agilen Entwicklungsprozess prägen und wurden folgendermaßen verfasst [BB01]: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Der einleitende Satz hebt den agilen Prozess als Lernprozess hervor. Durch das Ausführen von agilen Prozessen und dem Leisten von Hilfestellungen wird der Lerneffekt gesteigert. Werden die vorgestellten Gewichtungen und die von Grady identifizierten Management-Strategien gegenüber gestellt, wird ersichtlich, dass ein agiler Prozess sich mindestens zwischen der Maximierung der Kundenzufriedenheit und der Minimierung von Fehlern einordnen lässt. Schließlich setzt Working Software bzw. funktionierende Software voraus, dass ein System eine minimale Anzahl an Fehler enthält. Dies bedeutet nicht, dass eine verständliche Dokumentation des Systems außer Acht gelassen werden kann, ihr jedoch im Zweifelsfall weniger Gewicht beigemessen wird [Ec04, S. 15]. Die Kundenzufriedenheit wird durch die Zusammenarbeit mit dem Kunden und das Reagieren auf Veränderungen maximiert, da eine Unternehmung gemeinsam mit dem Kunden dessen Wünsche und wahrscheinlich ändernde Anforderungen bestmöglich umsetzen kann. 1 Auf Basis der agilen Werte wurden 12 Prinzipien abgeleitet, die in einem agilen Prozess bedacht werden sollten. Sie sind über die Webseite des Manifestes abrufbar. 3

6 Kapitel 2: Agilität und Modelle der Softwareentwicklung Will ein Projekt ein agiles Prozessmodell anwenden, stellt bspw. XP oder Scrum einen Ausgangspunkt für ihr Vorgehen dar [Ec04, S. 13]. Ein agiler Prozess kann in seiner Rohform die Erwartungen und Wünsche eines Teams nicht komplett erfüllen und befriedigen, weil jedes Team durch seine Mitglieder sehr unterschiedlich geprägt ist. Aus diesem Grund bietet die Retrospektive die Möglichkeit ein Prozessmodell an die örtlichen Gegebenheiten anzupassen. Während der Retrospektive, die entweder nach Ende oder Abbruch einer Iteration stattfindet, wird der vorhandene Prozess auf zwei Ebenen hinterfragt [Ec04, S. 13]. Die Erste betrachtet den Stand bzw. den Status des Projektes, wobei auch auf Aspekte eingegangen wird, die den Fortschritt des Projektes behindern oder verlangsamen. Eine Frage, die sich ein Team auf der ersten Ebene stellen kann, wäre die, ob alle notwendigen Refactorings durchgeführt wurden. Auf der Zweiten, der Metaebene, das Prozessmodell kritisch hinterfragt. Bspw. kann ein Team die Überlegung anstellen, die Planung der Iterationen durch das sogenannte Schätzpoker 2 zu unterstützen, um so mehr Struktur in ihre Schätzungen und Planungen einzubringen. An dieser Stelle werden Schwierigkeiten mit größeren Teams ersichtlich, da es aufgrund der Vielzahl an Bedürfnissen der individuellen Entwicklern schwieriger wird, diese zu befriedigen. Würden viele Änderungen als Ergebnis einer Retrospektive am Prozessmodell oder am Prozess vorgenommen, um auf die Wünsche und Vorschläge der vielen Entwickler einzugehen, ist das Risiko groß, dass der Prozess keine inkrementelle Entwicklung durchläuft. Viele oder große Änderungen am Prozess behindern das Nachvollziehen des Erfolgs der Modifikationen. 2.2 Wasserfall-Modell Um die Vor- und Nachteile agiler Prozessmodelle greifbarer zu machen, wird als Referenzmodell das Wasserfall-Modell der Software-Entwicklung vorgestellt und zu Vergleichszwecken herangezogen. In der Praxis hat dieses Modell eine Zeit lang, unter anderem aufgrund seines einfachen und verständlichen Aufbaus, Verwendung gefunden [Ba98, S. 100] und wird auch aktuell eingesetzt. Das Wasserfall-Modell sieht vor, dass ein System in einem Prozess mit bis zu sieben aufeinander folgenden Stufen entwickelt wird, wie es in Abbildung 2 dargestellt ist. Die Anzahl der Stufen ist nicht fixiert ist und variiert je nach Definition des Modells zwischen fünf und sieben. Dabei sind Rückkopplungen zur jeweils vorigen Stufe bzw. Aktivität vorgesehen, um teure Überarbeitungen über mehrere Stufen 2 Im Abschnitt 4.2 wird diese Art der Aufwandsabschätzung erläutert. 4

7 Kapitel 2: Agilität und Modelle der Softwareentwicklung Abbildung 2: Wasserfall-Modell [Ba98, S. 99] hinweg zu vermeiden [Ba98, S. 99]. Damit die Kopplungen zwischen den einzelnen Aktivitäten bzw. Stufen funktionieren können, laufen die einzelnen Aktivitäten sequenziell ab. Am Ende jeder Stufe steht ein fertiges Dokument, bspw. das Pflichtenheft als Ergebnis der Phase Software-Anforderungen; das Prozessmodell ist dokumenten-getrieben. Wird ein System nach dem Wasserfall-Modell entwickelt, so werden in der ersten Stufe sämtliche Systemanforderungen des Benutzers ermittelt und in der zweiten Stufe als Softwareanforderungen formuliert. Nach der Analyse ist in den darauffolgenden Aktivitäten keine Benutzerbeteiligung vorgesehen. Dennoch wirken sich manche Eigenschaften des Modells nachteilig aus. Der Dokumenten-Trieb des Wasserfalls führt unter Umständen dazu, dass die Dokumentation wichtiger wird als das eigentliche System [Ba98, S. 101]. Ändert der Benutzer in einer späteren Phase des Entwicklungsprozesses z. B. während der Codierung seine Anforderungen an das System, ist es schwer diese zu berücksichtigen, da die Anforderungen während der ersten Stufen festgelegt wurden. Durch die Festlegung des System-Umfanges und der Ressourcen werden nach dem Teufelsquadrat (sh. Abb. 1) Schwierigkeiten bei der Einhaltung von Terminen als auch der Qualität des Systems zu erwarten sein. 5

8 3 Extreme Programming Im folgenden Abschnitt werden die Grundzüge und Gedanken hinter Extreme Programming erörtert. Dabei wird die erste Version von XP unterstellt, weil ein Großteil der verfügbaren Literatur von dieser ausgeht. Außerdem bestehen zwischen den beiden Versionen nur geringfügige, für diese Ausarbeitung zu vernachlässigende Unterschiede, da die grundsätzlichen Ideen gleich geblieben sind [WRL05, S. 145]. Es wurden bspw. die Benennungen von Techniken und Prinzipien geändert sowie ein neuer Wert, der Respekt, hinzugefügt. Neben den Programmierern kommt dem Kunden eine wichtige Rolle in XP zu. Er ist im besten Falle zugleich Auftraggeber und Anwender des zu entwickelnden Systems. Sind dies verschiedene Personen, ist von einem zusätzlichen Kommunikationsaufwand auszugehen. Der Auftraggeber gibt die Ziele des Projektes vor, während der Anwender Fachwissen für die Entwickler beisteuert, damit die Anforderungen ohne größere Informationsverluste kommuniziert werden können [WRL05, S. 164]. Da für das Erfassen der Anforderungen sogenannte Story-Cards Verwendung finden, wird unter anderem vorausgesetzt, dass der Kunde gewillt ist das Projekt mit seinem Fachwissen aktiv zu unterstützen. Der Inhalt einer Story-Card ist die Beschreibung dessen was der Kunde vom System erwartet. Formulierungen, wie z. B. Ich möchte die aktuellen Geburtstage meiner Mitarbeiter auf einen Blick erfassen, sind gängig. Damit das System den Ansprüchen des Kunden so gut wie möglich gerecht werden kann, ist es wichtig, dass zwischen den Programmierer und dem Kunden reibungslos kommuniziert werden kann. Außerdem ist er befähigt die Anforderungen an das System jederzeit anzupassen, um z. B. neue Ideen einfließen zu lassen oder veränderte Umweltsituationen zu berücksichtigen. Ein zentrales Konzept von Extreme Programming ist die Orientierung der Entwicklung am Geschäftswert (engl. Business Value), welcher den Nutzen einer Anwendung für den Kunden wiederspiegelt. Positive Auswirkungen auf diesen Wert hat es, wenn die Programmierer die Story-Cards auch User Stories genannt umsetzen, die vom Kunden mit den höchsten Prioritäten versehen wurden. Agile Prozessmodelle wie Scrum und Extreme Programming verfügen über ein weiteres Konzept, das auf der Definition von Werten beruht. Bei XP sind dies in der ersten Version: Einfachheit, Kommunikation, Feedback und Mut, in der zweiten wurde das Wertesystem um Respekt erweitert. Beck hatte Respekt als Wert bereits in der ersten Version vorgestellt. Diesen Wert jedoch als unterhalb der Oberfläche der anderen vier [Werte] versteckt [Be03, S. 34f.] beschrieben und daher ursprünglich nicht explizit angeführt, aber mittlerweile im Zuge der Präzisierungen in der 6

9 zweiten Version des Manifests hinzugenommen. Das Leben der vorgestellten Werte in einem Projekt ist ein elementarer Schlüssel zum erfolgreichen Einsatz von XP. Auf den vier bzw. fünf Werten bauen 15 bzw. 14 Prinzipien auf, aus denen wiederum zwölf Techniken abgeleitet wurden, die in einem XP-Projekt eingesetzt werden sollten. Um den Umfang der Arbeit nicht zu sprengen, werden alle Techniken in Tabelle 1 auf Seite 8 kurz und knapp vorgestellt. In Anlehnung an das Werk von Wolf et. al. wurde die Übersicht angefertigt, wobei die Autoren die zwölf Techniken bereits um die Standup-Meetings und die Retrospektive erweitert haben, die XP in der zweiten Version berücksichtigt [WRL05]. 3.1 Ausschnitt der XP-Techniken Da die eingehende Erläuterung sämtlicher Praktiken in XP den Rahmen sprengen würde, werden im folgenden Abschnitt vier Techniken genauer dargestellt. Aufgrund der wechselseitigen Beziehungen der Techniken, auf die Abschnitt 3.2 eingegeht, werden mitunter Aspekte anderer Techniken beleuchtet. Die ausgewählten Techniken wirken sich maßgeblich auf den langfristigen Erfolg und Fortbestand eines XP-Projektes aus. Aus betriebswirtstschaftlicher Sicht besitzen die Praktiken in der Kombination eine hohe Relevanz, da sie sowohl Einfluss auf die Flexibilität und Qualität des Systems als auch deren Entwicklung nehmen. Denn das Programmieren in Paaren stellt sicher, dass unter anderem Wissen innerhalb des Teams aktiv ausgetauscht wird und der Entwicklungsprozess diszipliniert verfolgt wird. Durch das Testen wird ein Qualitätsniveau dauerhaft aufrecht erhalten und sichert das Team gegen Regressionen bzw. Rückschritte in der Entwicklung ab. Die Technik des Refactorings trägt dazu bei, das System immer ändern oder erweitern zu können. Anfängliche Kostenersparnisse werden mit Hilfe des einfachen Designs erreicht, da bewusst auf einen aufwendigen und zeitintensiven Entwurf des Systems verzichtet werden und durch die Änderbarkeit des Codes durch das Refactoring unterstützt wird. Im Zusammenspiel aller Techniken insbesondere durch die im folgenden, genauer vorgestellten Techniken wird eine Verbesserung der Aufwandskurve erreicht [Fo04]. Genauer gesagt, wird eine Stabilisierung der Kurve erzielt, sodass weitere Änderungen am System mit gleichen Aufwänden erzielt werden können. Abbildung 3 veranschaulicht den Gedanken hinter der Stabilisierung der Aufwände bei steigender Komplexität. Auf der linken Seite ist die in der Lehre vermittelte Aufwandskurve der traditionellen Entwicklung abgebildet, die exponentiell wächst. Dementsprechend einen höheren Aufwand verursacht, je komplexer ein System wird. Rechts 7

10 Name der Technik Planungsspiel Kurze Releasezyklen Metapher Einfaches Design Testen Refactoring Programmieren in Paaren Gemeinsame Verantwortlichkeit Fortlaufende Integration Nachhaltiges Tempo Kunde vor Ort Programmierstandards Retrospektive Standup-Meetings Beschreibung Der Kunde verfasst und priorisiert Anforderungen, Entwickler schätzen vor der Priorisierung einer Anforderung den Aufwand Software früh und häufig liefern Die Metapher beschreibt die primäre Funktion eines Systems Das einfachste Design wählen, das die Anforderungen erfüllt Erst automatisierte Tests schreiben und dann den Produktiv-Code Unschönheiten im Entwurf sofort beheben Zwei Entwickler arbeiten immer zusammen an einer Aufgabe Alle Entwickler arbeiten an und verantworten einen gemeinsamen Code-Bestand Änderungen am Code mehrmals täglich in den Code-Bestand integrieren Die Entwicklung findet mit einer gleichmäßigen Gewschwindigkeit statt Der Kunde und die Entwickler arbeiten am gleichen Ort Alle Entwickler halten sich an kurze, gemeinsame Programmierstandards Regelmäßige Reflektion über die Handlungen des Teams Tägliche Treffen aller Projektbeteiligten, um über den Projektfortschritt zu informieren Tabelle 1: Übersicht der XP-Techniken 8

11 Abbildung 3: Kostenkurve des Wasserfall-Modells und XP davon ist die in XP erwartete Kurve dargelegt, die mit steigender Komplexität gegen einen Wert konvergiert, sodass die marginalen Aufwände trotz steigender Komplexität nicht nennenswert wachsen. Dieser Wert liegt mittel- und langfristig unter dem der traditionellen Kurve [Be03, S. 21ff.] Programmieren in Paaren Programmieren in Paaren (engl. Pair Programming) ist eine Methode der Softwareentwicklung. Dabei arbeiten jeweils zwei Entwickler gemeinsam an einem Computer. Die Person, die über die Kontrolle von Maus und Tastatur verfügt, wird als Fahrer bezeichnet. Während der Fahrer bspw. einen Algorithmus in der Programmiersprache Java verfasst, ruht sich die andere Person jedoch nicht aus. Sie ist als Partner konzentriert bei der Arbeit und beobachtet die Eingaben des Fahrers. Dadurch stellt der Partner sicher, dass z. B. Randbedingungen des Algorithmusses überprüft, die Programmierstandards eingehalten oder Testfälle geschrieben werden. Durch diese implizit vorhandene Kontrollstruktur werden zwei wichtige Aspekte in der Softwareentwicklung gestärkt [WK00, S. 111]. Zum einen wird die Produktivität gesteigert, da es aufgrund der Partnerrolle unwahrscheinlich ist, dass der Fahrer anderen Aktivitäten nachgeht, die dem Ziel der Programmierung nicht zuträglich sind. Dazu zählt bspw. das Prüfen des privaten -Kontos. Durch die Anwesenheit des Partners ist immer eine Person vorhanden, die dafür sorgt, dass die Arbeit Fortschritte macht und Ergebnisse produziert werden. Auf der anderen Seite sichert der Partner die Qualität, indem er den Fahrer unter anderem auf syntaktische oder semantische Fehler hinweist. Zusätzlich haben beide Programmierer sei es der Fahrer oder der Partner ein Interesse an korrektem, fehlerfreiem Quelltext, da dieser aufgrund der gemeinsamen Verantwortlichkeit dem gesamten Team gehört. So gesehen stellt der Partner das schlechte Gewissen des Fahrers in Person dar und sollte auf der Behebung der zuvor beschriebenen Probleme beharren. Dennoch wird als Gegenargument zum Pair Programming mitunter angeführt, 9

12 dass zwei Programmierer als Paar weniger produktiv entwickeln als zwei Programmierer im Alleingang. Das im vorigen Absatz angeführte Argument beschreibt, wie durch die Paarung eine gesteigerte Aufmerksamkeit und damit gesteigerte Produktivität erzielt werden kann. Zusätzlich fehlt die empirische Grundlage, die das Gegenargument bekräftigen. Studien, die in der universitären Lehre unter anderem von Williams und Upchurch [WU01] sowie Braught et. al. [BEW08] durchgeführt wurden, zeigten, dass Studierende vom Programmieren in Paaren sehr profitierten. Dieser Profit wurde sowohl in der Qualität der erstellten Programme als auch in dem Lernerfolg der Beteiligten widergespiegelt. Kurzfristig ist sicherlich mit einer höheren Produktivität bei Einzelprogrammierern auszugehen, jedoch werden Programmierer auf lange Sicht besser mit dem Komplexität eines Software-Systems umgehen können als würden sie einzeln mit der Entwicklung am System beauftragt. Das Gegenargument wird außerdem durch die Tatsache geschwächt, dass viele Programmierer in Notsituationen auf Pair Programming zurückgreifen [JAH01, S. 111]. Der Autor dieser Arbeit hat diese Erfahrung in der Praxis einer Softwareentwicklungsfirma gesammelt. Dabei hat er bspw. bei schwerwiegenden Fehlern die Hilfe von Kollegen hinzugezogen; in anderen Fällen wurde er um Hilfe gebeten. Bei konsequentem Einsatz von Pair Programming tritt eine Kosteneinsparung durch den geringeren Bedarf an leistungsstarken PC ein. Schließlich arbeiten dann jeweils zwei Entwickler an einem Arbeitsplatz zusammen, sodass die Anzahl an Workstations reduziert werden kann. Es sei zusätzlich darauf hingewiesen, dass die Rollen der beiden Programmierer nicht statisch vergeben werden. Das heißt, dass die Programmierer im Laufe ihrer Zusammenarbeit des Öfteren einen Rollentausch vornehmen. Der Tausch findet unter anderem dann statt, wenn der Partner dem Fahrer eine Idee nicht verbal, sondern nur explizit im Quelltext ausdrücken kann oder will. Außerdem kann der Partner einen Wechsel vorschlagen, wenn er das Gefühl hat, dass der Fahrer nicht weiterkommt [JAH01, S. 113]. Dadurch wird bspw. verhindert, dass das Arbeiten zur Routine wird und dadurch die Konzentration sinkt oder ein aussichtsloser Pfad verfolgt wird. Im Zuge dessen wird das Risiko reduziert, das unbeabsichtigt Fehler in die Software einfließen. Des Weiteren werden die Paare in häufigen Abständen neugemischt; denkbar sind halbtägliche Wechsel, wobei dies in den jeweiligen Teams angepasst werden kann. Ein weiterer Punkt ist der Wissensaustausch, der durch häufige Paarwechsel gefördert wird. Wolf, et. al. beschreiben, wie das Programmieren in Paaren die Weitergabe von Wissen innerhalb eines Teams begünstigt [WRL05, S. 99]. Dabei benennen sie das Szenario, bei dem ein erfahrener Programmierer mit einem unerfahrenem 10

13 Programmierer zusammenarbeitet und das Wissen des Erfahrenen mit dem Unerfahrenen durch die direkte Interaktion ausgetauscht wird. Aufgrund dieses Austausches ist der Unerfahrene schneller in der Lage produktiv dem zu entwickelnden System beizutragen. Das zuvor beschriebene Erfahrungsgefälle zwischen den Programmierern ist jedoch nicht der einzige Vorteil in Bezug auf den Wissensaustausch. Beck erläutert einen weiteren Aspekt anhand einer Metapher [Be03, S. 101]. Dabei vergleicht er das Team mit einem Wasserbecken und illustriert wie folgt: Wenn jemand im Team eine wichtige neue Information findet, dann ist das so, als würde man einen Tropfen Farbstoff in ein Wasserbecken geben. Da die Paarungen ständig wechseln, wird die Information rasch im Team verbreitet, ebenso wie sich der Farbstoff rasch im Wasserbecken verteilt. Im Gegensatz zum Farbstoff wird die Information während der Verbreitung jedoch dichter, da in sie noch die Erfahrung und die Erkenntnisse aller Teammitglieder eingehen. Daraus resultiert insgesamt eine Wissensbasis, die im Team ständig erneuert wird und nicht zeitaufwendig in Wissens-Management- Systemen wie z. B. Wikis gepflegt werden muss. Durch Pair Programming und die einhergehende Wissensverbreitung wird außerdem ein wichtiges Projektrisiko minimiert, dessen Eintreten nicht exakt bestimmt werden kann. So führt der Ausfall eines Teammitgliedes in einem XP-Prozess nicht unmittelbar zu größeren Zeitverzögerungen bzw. Stillstand der betroffenen Projekte, da das Wissen auf das Team verteilt wurde. Diese Dezentralisierung von Wissen erhöht den sogenannten Truck-Factor, der besagt, dass der Faktor geringer ausfällt sobald der Fortschritt oder Erfolg des Projektes unmittelbar von einzelnen Teilnehmern abhängt [Bo05]. Bei einem Truck-Factor von 5 müssten folglich 5 Mitglieder des Projektes von einem Truck bzw. einem LKW erfasst werden, um einen Stillstand zu verursachen. Ein hoher Truck-Factor drückt also eine gewisse Unabhängigkeit von den Beteiligten eines Projektes aus, sodass es unwahrscheinlich ist, dass z. B. personelle Änderungen ein Projekt zum Scheitern bringen Testen Das Testen (engl. Testing) stellt eine weitere facettenreiche Technik im Extreme Programming dar. Im Kern handelt es sich um ein Prinzip, das die erwartete Funktionalität vor der Erstellung einer Implementation in einem Test festlegt. Dazu zählen vereinfacht dargestellt bspw. die zu erwartenden Ausgaben auf Eingaben oder die Fehlerbehandlung bei illegalen Eingaben. Durch die Möglichkeit das Verhalten eines Systems in Tests festzuhalten, bietet 11

14 das Testing dem Kunden ein Hilfsmittel um seine Anforderungen an das System in Testfällen auszudrücken. Gleichzeitig können die Entwickler nachvollziehen, ob sie den gewünschten Funktionsumfang korrekt implementiert haben. Hierbei ist es wichtig zwischen den verschiedenen Arten des Testing zu unterscheiden; die zuvor beschriebene Art fällt in die Kategorie der Akzeptanztests [WRL05, S. 70ff.]. Dabei legt der Kunde fest, welche Kriterien eine Anwendung zu erfüllen hat. Ein Kriterienkatalog beinhaltet Punkte wie die korrekte Berechnung von Ausgaben auf entsprechende Eingaben oder bestimmte Benutzbarkeitsmerkmale, z. B. die Erreichbarkeit des Startbildschirmes von jedem Punkt der Anwendung. Zur Unterstützung dieser Aufgabe existieren Tools wie FIT, das dem Kunden ermöglichen das Verhalten von Geschäftsregeln und ähnlichem in einem Wiki oder einer Excel- Tabelle zu pflegen [ov08b]. Ist das Verhalten einer Weboberfläche zu testen, stellt bspw. Canoo WebTest eine Möglichkeit dar [ov08a]. Manche Aspekte der Akzeptanz sind jedoch nicht automatisiert testbar und erfordern manuelle Durchführung; so kann die Lesbarkeit einer Website nur schwerlich automatisch getestet werden. Während der Programmierung eines Software-Systems schaffen die Entwickler mit Hilfe von Komponententests (engl. Unit Tests) eigenes Vertrauen in das von ihnen zu implementierende System. In XP wird der Ansatz der testgetriebenen Entwicklung eingesetzt, der besagt, dass bevor jeglicher Produktiv-Code geschrieben wird, ein Test die Existenz dieses Codes rechtfertigen muss. Die zweite Version von XP nennt Beck nicht mehr Testing, sondern Test-First Programming, um die Wichtigkeit des Testgetriebenen zu betonen. Die testgetriebene Entwicklung einer Funktionalität erfolgt in einem sich stetig wiederholenden 3-Phasen-Modell [We05, S. 51ff.]. In der ersten Phase wird der Test hinzugefügt und es wird genau so viel Produktiv-Code erstellt, bis der Test laufen kann und fehlschlägt. Dies bedeutet konkret, dass der Compiler zufrieden gestellt wird, sofern dieser aufgrund von Kompilier-Fehlern die Ausführung des Tests ausschlägt. Daraufhin implementiert man den Code, der den Test erfüllt, der üblicherweise in einem xunit-testfall erfasst wurde; JUnit ist eine Ausprägung für das Testen von Komponenten in Java [ov08c]. Da in diesem Schritt gemogelt werden darf, bspw. durch das harte Kodieren von Rückgabewerten, wird im dritten Schritt mit der Technik des Refactoring der Code vereinfacht, um Duplikationen und andere Gerüche 3 aus dem Quelltext zu entfernen. Da Testing das Schreiben der Testfälle vor dem Verfassen des eigentlichen Programmquelltextes vorsieht, werden die Ideen der Programmierer in den Tests wider- 3 Fowler verwendet diesen Begriff um Potenzial für Refactorings zu erkennen [FBB99, S. 75ff.]. 12

15 gespiegelt und formen auf diese Art und Weise die Schnittstellen des zukünftigen Systems. Die Formung der Schnittstellen durch die Tests prägen das Design der zukünftigen Anwendung maßgeblich, weshalb die testgetriebene Entwicklung auch als Designstrategie bezeichnet wird [We05, S. 91]. Insgesamt spannt die Menge der Komponententests Testsuite genannt sowie die Akzeptanztests eine Art Sicherheitsnetz für die Entwickler. Sollte eine ihrer Änderungen in dieses Netz fallen, werden sie automatisch darauf aufmerksam gemacht; im Gegensatz zur traditionellen Entwicklung bei der viele Fehler im Programm nicht automatisch entdeckt werden können, sondern erst in der Testphase, und aufgrund der Komplexität in der Programmierung übersehen werden. Durch die Testfälle wird automatisch beim Ausführen der kompletten Testsuite sichergestellt, dass der bestehende Funktionsumfang des betroffenen Systems nicht ungewollt reduziert wird. Diese Reduzierung beinhaltet z. B. das Einfügen von Fehlern, die für den Benutzer falsches Systemverhalten bedeuten können. Mängel in Programmen der traditionellen Softwareentwicklung, werden womöglich nicht von den Entwicklern bemerkt und letztlich an den Kunden ausgeliefert. Je später die Fehler behoben werden, sind die dafür notwendigen Aktivitäten mit umso höherem Aufwand bzw. Fehlerbehebungskosten anzusetzen [Ba98, S. 22f.]. Jedoch bleiben selbst Anwendungen, die mit Hilfe einer testgetriebenen Entwicklung zu Stande gekommen sind, nicht von Fehlern verschont. Die Wahrscheinlichkeit, dass Fehler während der Programmierung einfließen, ist aber geringer, da die Qualität insgesamt gestiegen ist [We05, S. 4f.]. Weitere Testtypen werden je nach Anwendungssituation relevant. Ein Profiler kann bspw. eingesetzt werden, um die Performance der Anwendung zu testen oder zu analysieren, sollte das System nicht die gewünschten Antwortzeiten bieten. Dabei werden Schwachstellen herausgestellt, die daraufhin optimiert werden können. Insgesamt sollte es jedoch nicht zu Problemen in puncto Performance kommen, da aufgrund des einfachen Designs weniger Objekte und Objektinteraktionen beteiligt sind [WRL05, S. 85f.] und das System somit performant sein sollte. Im Zusammenhang mit der fortlaufenden Integration wird sichergestellt, dass alle Komponententests fehlerfrei durchlaufen, da dies die Mindestanforderung an zur Integration stehenden Code ist. Dabei können neben den Unit Tests auch automatische Akzeptanztests durchgeführt werden, die jedoch eine Integration nicht abbrechen können, da sie in diesem Kontext lediglich als grober Indikator für den Projektfortschritt zu sehen sind. 13

16 3.1.3 Refactoring Das Refactoring dient dazu den Code und die Tests leicht verständlich zu halten und um Änderungen am Code einfach durchführen zu können [FBB99, S. 54]. Während eines Refactorings wird das zu beobachtende Verhalten des Systems jedoch nicht geändert. Die durch das Testen aufgebaute Testsuite gibt den Entwickler Vertrauen in ihre Refactorings. Vor Beginn der Änderungen wird sichergestellt, dass alle Unit-Tests problemlos durchlaufen, dann werden die Refactorings in inkrementellen Schritten am System durchgeführt. Zwischen den Schritten wird die Testsuite ausgeführt, um die Gewissheit zu erlangen, dass das Systemverhalten nicht modifiziert wurde. Als Ergebnis sind keine Funktionalitätserweiterungen vorgesehen, viel mehr soll das Verständnis vom System gestärkt und die Aufwandskurve des Projektes niedrig gehalten werden [WRL05, S. 88]. Refactorings müssten folglich als wert-neutral in Bezug auf den Geschäftswert betrachtet werden. Jedoch werden sie durch neue Anforderungen mitunter erforderlich, um das System in die Lage zu versetzen, die Funktionalitäten zur Erfüllung einer Story umzusetzen, sodass ein Refactoring eine Wertsteigerung begünstigt. Die Liste an möglichen Refactorings ist lang und enthält einfache Dinge wie das Umbenennen von Methoden, um die Funktion einer Methode besser kommunizieren zu können [FBB99, S. 273f.], oder das Verschieben eines Datenfeldes in eine andere Klasse, um geänderte Verantwortlichkeiten in Klassen zu antizipieren [FBB99, S. 146f.]. Komplexer fällt bspw. das Ändern eines Bedingungsblockes mit mehreren parallelen if-else- oder einem switch-statement aus, die mit dem Wissen über den Typ eines Objektes unterschiedliches Verhalten demonstrieren [FBB99, S. 255ff.]. Mit Polymorphismus wird das gewünschte Verhalten in die entsprechenden Klassen verschoben, sofern die Klassen eine Vererbungsstruktur besitzen, die dieses zulässt. In der Oberklasse wird eine abstrakte Methode definiert, die von den Unterklassen überschrieben wird und die gewünschten Werte zurückgibt, sodass der Bedingungsblock zu Gunsten von Erweiterbarkeit und Lesbarkeit entfällt. Die Notwendigkeit zum Refactoring eines Systems wird durch die sogenannten Gerüche (engl. Smells) markiert [FBB99, S. 75ff.]. Duplizierter Code ist einer von verschiedenen Gerüchen und stellt eine mögliche Fehlerquelle dar. Eine Vereinheitlichung des duplizierten Code-Blockes führt dazu, dass zukünftige Änderungen nur an einer Stelle gepflegt werden müssen und andere Stellen im Code daher nicht vergessen werden können. Als weiterer Geruch reiht sich der lange Methoden-Rumpf ein, der als Relikt 14

17 der prozeduralen Programmierung in der objektorientierten Programmierung keine Daseinsberechtigung besitzt. Durch Einführen neuer Methoden, die passende Teile des alten Rumpfes zusammenfassen, wird die Lesbarkeit des Code erhöht [FBB99, S. 110ff.]. Insgesamt stellt das Refactoring eine Möglichkeit zur Beherrschung der Komplexität eines wachsenden Systems dar. Damit Refactorings optimal umgesetzt werden können, müssen die Entwickler den Quelltext gemeinsam verantworten. Das Refactoring bietet sich als Hilfestellung für die Technik des einfachen Designs an, um den einfachsten Architektur-Ansatz wählen zu können, und wird von der testgetriebenen Entwicklung benötigt Einfaches Design In XP wird nicht wie etwa bei dem Wasserfall-Modell eine komplette Aktivität auf den Entwurf bzw. das Design angesetzt. Vielmehr durchläuft das Design während der Entwicklung einen evolutionären Prozess, in dem die Architektur inkrementell angepasst wird. Im Zuge der Nachbesserungen wurde in der zweiten XP-Version der inkrementelle Entwurf als zusätzliche Technik benannt. Dennoch startet kein XP-Projekt komplett ohne ein Architektur-Konzept, es beschränkt sich lediglich auf das Nötigste. Es wird lediglich kein Design auf Vorrat erstellt, das möglicherweise nützlich sein könnte, die Verwendung also unsicher bzw. unwahrscheinlich ist [WRL05, S. 78]. Aufgrund der Ausrichtung am Geschäftswert wird das einfachste Design gewählt, das die Anforderungen des Kunden erfüllt, sodass die Entwicklung stets wert-maximierend voranschreitet. Des Weiteren birgt die Bevorratung von Architektur bzw. Design ein Risiko, insofern, dass das Bevorratete womöglich nicht von Tests abgedeckt wird und so einen potenziellen Mangel darstellen könnte [WRL05, S. 80]. Damit ein Design einfach bleibt oder wird, hat Beck 4 Regeln aufgestellt, die den Charakter eines einfachen Design prägen und nach ihrem Stellenwert absteigend priorisiert [Be03, S. 109]: 1. Das System (sowohl Code und Tests) sollte den Inhalt des Systems verständlich ausdrücken. 2. Das System sollte keinen duplizierten Code enthalten. 3. Das System soll die minimale Anzahl an Klassen haben 4. Das System soll die minimale Anzahl an Methoden haben. 15

18 Wolf et. al. schreiben, dass durch die testgetriebene Entwicklung, die durch das Testen impliziert wird, diese Regeln geradezu erzwungen werden [WRL05, S. 81]. Ausgehend von der Entwicklung des einfachsten Design, das eben den simpelsten Ansatz darstellt, der gerade funktioniert, kann die Aussage formuliert werden, dass ein XP-Team mit leichtem Gepäck reist [Be03, S. 42]. Diese Umschreibung basiert auf einem Prinzip aus der ersten Version von XP 4 und betont, dass ein Team von jetzt auf gleich, wie Nomaden, auf Veränderungen, wie z. B. modifizierte Umweltsituationen, reagieren kann. Im Vergleich zur traditionellen Entwicklung stellt sich eine Kostenreduktion ein, weil Design-Entscheidungen erst zur realen Fälligkeit getroffen werden und nicht schon vor der Codierung, wenn noch nicht alle Anforderungen des Kunden bekannt sind. Außerdem lassen sich kleine, einfache Designs leichter anpassen als große, sodass der notwendige Aufwand geringer ausfällt. Diese Aufwandsreduzierung wird nicht zuletzt durch die Technik des Refactoring begünstigt. 3.2 Überblick der Abhängigkeiten Abbildung 4 zeigt die Abhängigkeiten der Techniken untereinander. So bedingt das einfache Design das Refactoring, um erfolgreich eingesetzt werden zu können. Beim Pair Programming ermahnt der Partner den Fahrer, wenn dieser vom testgetriebenen Ansatz abkommt und bspw. Geschäftslogik ohne einen Test implementiert. Ohne das Refactoring könnte die testgetriebene Entwicklung nicht angewendet werden, da es die grundlegende Technik für die dritte Phase darstellt. Aufgrund der Abhängigkeiten empfiehlt sich langfristig stets eine vollständige Einführung von XP, da dann sämtliche Vorteile in Kraft treten, wie z. B. die Stabilisierung der Aufwände. Wolf et. al. schlagen zwei Ansätze zur Einführung von XP vor. Zum eine komplette, einmalige Einführung der Praktiken und zum anderen eine schrittweise Unterweisung, bspw. für bestehende Projekte [WRL05, S. 242ff.]. 3.3 Rahmenbedingungen für XP Die Fokussierung von XP liegt unter anderem wegen der vorgestellten Techniken auf lauffähiger Software. Wird davon ausgegangen, dass der Aufwand der zur Entwicklung aufgebracht wird, fix ist, dann muss der Kunde gewillt sein, den Umfang des Systems ggf. zu reduzieren oder Änderungen am Fertigstellungstermin vorzunehmen, wie aus dem Teufelsquadrat (sh. Abb. 1) aufgrund der beiden festgelegten 4 In der zweiten Version wurde das einfache Design auf zwei andere Techniken verteilt. 16

19 Abbildung 4: Techniken stützen sich gegenseitig [Be03, S. 70] Parameter abgeleitet werden kann. Daher ist es schwierig mit XP ein Projekt durchzuführen, das am Ende der Laufzeit die gesetzten Ziele im vollen Umfang erreicht, dafür aber die meisten Ziele mit einer gewissen Qualität umgesetzt hat. Denkbar ist natürlich auch das Gegenteil, dass ein Team vor Ende der Projektlaufzeit sämtliche Ziele erreicht hat und weitere Funktionen implementieren könnte. Insbesondere bei Projekten mit langer Laufzeit (> 1 Jahr) wird es sehr schwierig Aussagen über die Zielerreichung zu treffen. Dies ist aber ein Problem, mit dem auch andere Prozessmodelle zu kämpfen haben, da auf lange Sicht große Planungsunsicherheit herrscht. Eine weitere Rahmenbedingung stellen physische Faktoren dar, wie z. B. getrennte Büroräume oder Einzel-Arbeitsplätze. Sind die Mitglieder eines Teams über mehrere Büroräume oder gar weitere Distanzen verteilt, wird ein Großteil der informellen Kommunikation unterbunden. Das Programmieren in Paaren fördert zumindest die informelle Verständigung innerhalb der Paare und erstreckt sich bei jedem Partnerwechsel weiter. Jedoch können die Entwickler bei einer physischen Trennung nicht von einer paar-übergreifenden, informellen Kommunikation profitieren. Schreibtische können ebenfalls einen physischen Störfaktor bilden, da viele Tische als Einzel-Arbeitsplatz dienen und an den Seiten, bspw. durch Schubfächer oder ähnlichem blockiert werden, oder aufgrund ihrer L-Form nur für eine Person 17

20 eine angenehme Sitzposition ermöglichen. Wolf et. al. empfehlen runde Tische für das Programmieren in Paaren, sodass der Rollentausch ohne großen Aufwand vorgenommen werden kann [WRL05, S. 102]. Dies bedeutet, dass der Fahrer dem Partner die Eingabegeräte nur zuzuschieben braucht, um den Tausch zu vollenden. Eingangs wurde in Abschnitt 2.1 darauf hingewiesen, dass große Teams mit der Einführung und Verwendung von agilen Prozessmodellen Probleme haben werden. Dies gilt auch für Extreme Programming, da bspw. Praktiken wie die gemeinsame Verantwortlichkeit bei größeren Teams aufgrund von nicht wahrgenommener Verantwortlichkeit früher verfallen. Als Maximum werden Teamgrößen von bis zu 12 Entwicklern angegeben; kleinere Teams aber zu favorisieren sind, die bspw. durch Aufspaltung des Projektes in logische Teilprojekte realisiert werden können [WRL05, S. 206f.]. Zu guter Letzt ist es notwendig, dass alle Beteiligten gewillt sind, die Werte, Prinzipien und Techniken anzunehmen, umzusetzen und zu leben. Die Regeln, die XP definiert, müssen diszipliniert eingehalten werden, was angesichts der Spielräume leichter gesagt als getan ist [WRL05, S. 241]. 18

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

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

- 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

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

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

Herkömmliche Softwareentwicklungsmodelle vs. Agile Methoden

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

Mehr

Extreme Programming. 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

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

Festpreisvertrag und agil nützt nicht viel? Stefan Roock, stefan.roock@akquinet.de Henning Wolf, henning.wolf@akquinet.de http://www.it-agile.

Festpreisvertrag und agil nützt nicht viel? Stefan Roock, stefan.roock@akquinet.de Henning Wolf, henning.wolf@akquinet.de http://www.it-agile. Festpreisvertrag und agil nützt nicht viel? Stefan Roock, stefan.roock@akquinet.de Henning Wolf, henning.wolf@akquinet.de http://www.it-agile.de Unser Hintergrund Agile Softwareentwicklung/Schulung/Beratung

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

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

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

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

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

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

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

Mehr

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

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

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

Mehr

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

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

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

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

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

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

Mehr

Agile 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

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

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

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

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

Mehr

Agile Methoden bei der Entwicklung medizinischer Software

Agile Methoden bei der Entwicklung medizinischer Software Agile Methoden bei der Entwicklung medizinischer Software Bernhard Fischer Fischer Consulting GmbH Fischer Consulting GmbH Technologie-Forum 2008 Folie 1 Wie soll Software entwickelt werden? Fischer Consulting

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

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

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

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

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

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

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

Ü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

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

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

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

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

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

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

Mehr

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

Extreme Programming (XP)

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

Mehr

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

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

Inhalt. 3.1 Der inkrementelle Entwurf im Überblick... 13 3.2 Flache Aufwandskurve... 14 3.3 Qualitätskriterien für den inkrementellen Entwurf...

Inhalt. 3.1 Der inkrementelle Entwurf im Überblick... 13 3.2 Flache Aufwandskurve... 14 3.3 Qualitätskriterien für den inkrementellen Entwurf... ix 1 Einleitung 1 Roman Pichler Stefan Roock 1.1 Agile Softwarewicklung und Scrum............................ 1 1.2 Zielgruppe und Zielsetzung.................................. 2 1.3 Überblick über das

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

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

Agile Softwareentwicklung mit Scrum

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

Mehr

Agiler Healthcheck. Dieter Bertsch & Sabine Canditt Agile Center Allianz Deutschland München / Januar 2013

Agiler Healthcheck. Dieter Bertsch & Sabine Canditt Agile Center Allianz Deutschland München / Januar 2013 Agiler Healthcheck Dieter Bertsch & Sabine Canditt Agile Center Allianz Deutschland München / Januar 2013 Inhalt 1 2 3 Motivation Existierende Healthchecks Agiler Healthcheck der Allianz "Der Glaube an

Mehr

Test-Driven Developement Eine Einführung

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

Mehr

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

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

Mehr

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

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

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

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

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

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

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

6 Jahre extreme Programming Eine Retrospektive

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

Mehr

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

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

Vorgehen im Softwareentwicklungsprozess

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

Mehr

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

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

Agile Entwicklungspraktiken mit Scrum

Agile Entwicklungspraktiken mit Scrum Agile Entwicklungspraktiken mit Scrum von Roman Pichler, Stefan Roock 1. Auflage Agile Entwicklungspraktiken mit Scrum Pichler / Roock schnell und portofrei erhältlich bei beck-shop.de DIE FACHBUCHHANDLUNG

Mehr

Herausforderungen bei agiler Entwicklung und agilem Testen

Herausforderungen bei agiler Entwicklung und agilem Testen Herausforderungen bei agiler Entwicklung und agilem Testen Dr. Andreas Birk, Gerald Heller Vivit Deutschland Jahrestreffen, Bad Honnef 14. September 2010 Inhalt Was ist agile Entwicklung? Wie unterstützt

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

Agile Softwareentwicklung mit Scrum

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

Mehr

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

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

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

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

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

Agile Software Development with Scrum

Agile Software Development with Scrum Agile Software Development with Scrum (Schwaber/Beedle, Prentice Hall, 2002) Ein Lesebericht von Robert Hagedorn und Dr. Juho Mäkiö Was ist eigentlich Scrum und wie kann es erfolgreich in der Systementwicklung

Mehr

CONTINUOUS DELIVERY. Entmystifiziert. codecentric AG

CONTINUOUS DELIVERY. Entmystifiziert. codecentric AG CONTINUOUS DELIVERY Entmystifiziert WIE SOFTWARE LIEFERN? 01.07.2014 2 WAS IST CONTINUOUS DELIVERY? Robust Wiederholbar Effektiv 01.07.2014 3 LANDSCHAFTEN Continuous Integration Public / Private Hybrid

Mehr

Taking RM Agile. Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum

Taking RM Agile. Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum Taking RM Agile CLICK TO EDIT MASTER OPTION 1 Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum Click to edit Master subtitle style Christian Christophoridis Requirements Management

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

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

Agile Softwareentwicklung - Ein praktisches Beispiel -

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

Mehr

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

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

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

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

Einführung von Testautomatisierung reflektiert. Erkenntnisse eines Linienmanagers zu Herausforderungen und Fallgruben

Einführung von Testautomatisierung reflektiert. Erkenntnisse eines Linienmanagers zu Herausforderungen und Fallgruben Einführung von Testautomatisierung reflektiert Erkenntnisse eines Linienmanagers zu Herausforderungen und Fallgruben Matt Young Leiter Test Acquiring Inhaltsverzeichnis Einleitung Testautomatisierung PostFinance

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

Dauerhafter Unternehmenserfolg mit Agile Evolution

Dauerhafter Unternehmenserfolg mit Agile Evolution Turning visions into business September 2011 Dauerhafter Unternehmenserfolg mit Agile Evolution Malte Foegen, David Croome, Timo Foegen Scrum-Techniken verbreiten sich zunehmend. Sie führen in vielen Fällen

Mehr

Der Entwicklungsprozess. Oder wie entwickle ich ein eingebettetes System?

Der Entwicklungsprozess. Oder wie entwickle ich ein eingebettetes System? Der Entwicklungsprozess Oder wie entwickle ich ein eingebettetes System? Einleitung Problemstellung erläutern, Eine Entwicklungsprozess ist ein Prozess, der beschreibt, wie man eine Entwicklung anzugehen

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

Leitfaden für die Beschaffungen von agilen IT Projekten

Leitfaden für die Beschaffungen von agilen IT Projekten Leitfaden für die Beschaffungen von agilen IT Projekten 27. August 2014 Fachgruppe Thomas Molitor, Stephan Sutter 1 Agenda 1. Nutzen des Leitfadens 2. Motivation & Kontext 3. Zielgruppen 4. Ihre Herausforderungen

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

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

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

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

Agile Softwareentwicklung

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

Mehr

AGILE SOFTWAREPROJEKTE IN REINFORM WAS BEDEUTET DAS RECHTLICH? RA Daniel Schätzle Berlin, 22. April 2015

AGILE SOFTWAREPROJEKTE IN REINFORM WAS BEDEUTET DAS RECHTLICH? RA Daniel Schätzle Berlin, 22. April 2015 AGILE SOFTWAREPROJEKTE IN REINFORM WAS BEDEUTET DAS RECHTLICH? RA Daniel Schätzle Berlin, 22. April 2015 Agiles Vorgehen 2 Agiles Vorgehen 3 WAS BEDEUTET AGIL Abstimmung über Ziel (nicht konkretes Entwicklungsergebnis)

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

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