Performance Testing in agilen Projekten

Größe: px
Ab Seite anzeigen:

Download "Performance Testing in agilen Projekten"

Transkript

1 Performance Testing in agilen Projekten Daniel Swars Universität Paderborn Zusammenfassung Die agile Softwareentwicklung gewinnt in der Praxis immer mehr Bedeutung. Doch leider macht es die Flexibilität in diesen agilen Projekten fast unmöglich während der Softwareentwicklung nutzbare Performance-Tests durchzuführen. Durch die Möglichkeit, dass sich Anforderungen stetig ändern können, werden schon erlangte Testdaten nutzlos. Trotzdem ist Performance-Testing notwendig, wenn Performance-Kritische Anforderungen bestehen. Diese Ausarbeitung beinhaltet Methoden, Tipps und Erfahrungsberichte für die Integration und Durchführung von Performance-Testing in agilen Projekten. Key words: Performance, Testing, Agil, PREM 1 Einleitung Performance ist für viele Softwareprojekte ein wichtiges Softwarequalitätsmerkmal. Es gibt viele Ansätze und Methoden, um die benötigten Performancekriterien schon früh während des Softwareentwicklungsprozesses zu erreichen. Trotzdem werden in vielen Softwareprojekten Performancetests erst am Ende, in einem extra dafür vorgesehenen Zeitraum, durchgeführt. Beides ist bei der agilen Softwareentwicklung nicht ohne weiteres möglich, da dort die Software in einem iterativen Prozess entwickelt wird. Diese Ausarbeitung beschreibt das vorliegende Problem und mögliche Vorgehensweisen, um in agilen Projekten Performance-Tests durchzuführen. Zusätzlich wird eine Technik vorgestellt, die die Definition von Performance-Anforderungen in agilen Projekten ermöglicht bzw. erleichtert. Zuerst werden in Abschnitt 2 die benötigten Grundlagen erklärt. Dann wird in Abschnitt 3 eine Vorgehensweise beschrieben, wie Performance-Testing in agilen Projekten integriert werden kann. Abschnitt 3.1 beschreibt eine von Scott Barber empfohlene Vorgehensweise [Bar09], bei der sich ein zusätzlicher Performance- Spezialist um die Integration und Durchführung von Performance-Testing kümmert. Danach wird in Abschnitt 3.2 ein anderer Ansatz beschrieben, den Jamie Dobson in seinem Erfahrungsbericht [Dob07] beschreibt. In dem darauf folgenden Abschnitt wird eine Technik zum Definieren von Performance-Anforderung in einem iterativen Prozess beschrieben. Zuletzt wird in Abschnitt 5 in einem abschließenden Fazit ein Vergleich der vorliegenden Vorgehensweisen und Techniken geführt.

2 2 Daniel Swars 2 Grundlagen In diesem Abschnitt werden die benötigten Grundlagen erklärt. In Unterabschnitt 2.1 wird die Agile Softwareentwicklung näher erläutert, bzw. anhand des Software-Entwicklungsprozess Scrum verdeutlicht. Und Unterabschnitt 2.2 beschreibt was Performance-Testing ist, und es werden häufig genutzte Performance- Testing Techniken beschrieben. 2.1 Agile Softwareentwicklung Die Agile Softwareentwicklung ist eine immer häufiger genutzte Alternative zum klassischen Softwareentwicklungsprozess. Ziel der agilen Softwareentwicklung ist ein flexibler bzw. agiler Software-Entwicklungsprozess, bei dem die Funktionalität der Software, die Kommunikation im Entwicklungsteam, sowie die Kommunikation mit den Kunden im Vordergrund steht. Dabei wird versucht mit möglichst geringen bürokratischem Aufwand und möglichst wenig Regeln auszukommen. Die Grundwerte der agilen Softwareentwicklung beschreibt das Agile Manifest [Agi]: Individuum und Interaktion sind wichtiger als Prozesse und Tools Eine funktionierende Software hat einen höheren Stellenwert als eine umfassende Dokumentation Eine ständige und stetige Zusammenarbeit mit den Kunden ist wichtiger als ein Vertrag Der Mut und die Möglichkeit zur Änderung steht über der Befolgung eines festgelegten Planes Im Gegensatz zur traditionellen Herangehensweise der Softwareentwicklung wird bei der agilen Softwareentwicklung die Software in mehreren Iterationen entwickelt. Jede Iteration kann man dabei als eigenes, kleines Softwareprojekt sehen. Einige Beispiele für fest definierte agile Softwareprozesse sind Extreme Programming (XP) [Bec99] und Scrum [SB01]. Scrum: Scrum ist ein von Ken Schwaber, Jeff Sutherland und Mike Beedle erfundener Software-Entwicklungsprozess, der immer öfter für die Softwareentwicklung genutzt wird. Bei Scrum steht das Entwicklungsteam im Vordergrund; sie organisieren ihre Arbeit weitestgehend selbst und wählen ebenfalls selbst ihre Softwareentwicklungs-Werkzeuge und Methoden. Abbildung 1 zeigt den Ablauf eines Software-Entwicklungsprozesses mit Scrum. Am Anfang des Entwicklungsprozess wird eine priorisierte Liste aller Funktionen, Features und Technologien zusammengestellt, die das Endprodukt haben sollte. Diese Liste nennt man Product Backlog und wird üblicherweise vom Kunden und vom Entwickler gefüllt. Welche Prioritäten die Punkte auf der Liste haben, und damit die Reihenfolge in welcher die Features der Software implementiert werden, bestimmt der Product Owner. Dabei können neue Punkte jederzeit auf die Liste mit aufgenommen werden und vorhandene Punkte neue Prioritäten

3 Performance Testing in agilen Projekten 3 24 h 30 days Product Backlog Sprint Backlog Sprint Working increment of the software Abbildung 1. Scrum Prozess [Wik09] bekommen. Das Product Backlog ist also niemals fertiggestellt. Der Product Owner hat eine tragende Rolle in Scrum und sollte in ständiger Kommunikation mit allen Beteiligten sein, damit er die Features zweckmäßig priorisieren kann. Die komplette Softwareentwicklung wird üblicherweise von einem kleinen, selbständigen Team (Scrum-Team) durchgeführt. Dieses Team sucht sich so viele Features vom Product Backlog wie es in einen Produkt Inkrement (Sprint) umsetzen kann. Diese Featuresliste nennt man Sprint Backlog. Ein Sprint ist üblicherweise dreißig Tage lang und kann als kleines eigenständige Softwareprojekt gesehen werden, deren Ziel ein Working Increment des Softwareprodukt ist. Design-Entscheidungen werden dabei größtenteils zweckmäßig für und in dem jeweiligen Sprint getroffen und nicht im Vorfeld für das komplette Softwareprojekt. So entsteht üblicherweise der Großteil der Softwarearchitektur im Laufe mehrerer Iterationen und nicht während der ersten Sprints oder im Vorfeld. Am Ende eines jeden Sprints soll eine funktionsfähige Version des Softwareprodukts entstanden sein, die die Features des Sprint Backlog enthalten. Es kann auch mehr als ein Scrum-Team parallel an dem selben Produkt-Inkrement arbeiten. Dabei arbeiten sie aber immer von den selben Product Backlog. Die Teams organisieren sich selbst und arbeiten komplett selbständig. Dabei sind sie nur von der Product Backlog und von den üblichen Betrieb-Standards und Konventionen abhängig. Täglich trifft sich das Scrum-Team für ein kurzes Status-Meeting (Daily-Scrum). Bei diesem Meeting kann man sehr gut das Vorankommen des Teams beobachten und mögliche Probleme besprechen, um schnelle Lösungen zu finden. Während eines Sprints steht ein Scrum-Master dem Team zur Seite. Er erhält dabei die Transparenz über die Entwicklung aufrecht und hat damit die Aufgabe, den Überblick über die gesamte Entwicklung zu behalten. Seine Aufgabe ist es dabei nicht, die Kommunikation zwischen Produkt-Owner und den Scrum-Team zu Organisieren, da diese direkt miteinander kommunizieren sollen. Er hat dafür zu sorgen, dass das Scrum-Team seine Ziele erreichen kann und das dafür alle benötigten Ressourcen zur Verfügung stehen. Seine Aufgabe ist die ordnungs-

4 4 Daniel Swars gemäße und zweckmäßige Durchführung von Scrum zu organisieren. Nach jedem Sprint trifft sich das Scrum-Team, zusammen mit dem Kunden, zu einem kurzen Sprint-Review-Meeting um das enstandene Produkt Inkrement zu inspizieren. Dies ist oft ein Zeitpunkt, bei dem das Product Backlog erweitert wird und der Product Owner die Prioritäten auf dieser anpasst. Zuletzt trifft sich das Scrum-Team mit den Product-Owner und den Scrum-Master zu einer Retrospektive. Dort werden nochmal die aufgetretenen Probleme während des letzten Sprints angesprochen und Verbesserungsvorschläge gemacht, damit der nächste Sprint besser abläuft. Weitere Details zu Scrum findet man, unter anderem, in dem Buch Agile Software Development with Scrum [SB01] von Ken Schwaber und Mike Beedle. Die Integration von Performance-Testing in Scrum ist nicht einfach, da es keine genaue Definitionen gibt wie man nicht funktionale Anforderungen in Scrum umsetzen soll. Performance-Testing während des gesamten Entwicklungsprozess ist schwierig, da immer wieder neue, vorher nicht bekannte Funktionen oder Anforderungen hinzukommen können, die die schon erlangten Testergebnisse nutzlos machen. Daher werden im folgenden Abschnitt einige Methoden und Tipps für die erfolgreiche Integration von Performance-Testing in agilen Projekten vorgestellt. 2.2 Performance-Testing Beim Performance-Testing testet man ob die Software die gegebenen Performancekriterien einhält. Bei den Performancekriterien unterscheidet man Grundsätzlich zwischen der Laufzeit und dem Speicherverbrauch. Beim testen der Laufzeit wird geprüft welche Antwortzeiten das System oder einzelne Komponenten haben und ob die gegebenen Anforderungen eingehalten werden. Wenn diese Zeit-Anforderungen nicht eingehalten werden, dient Performance-Testing dazu herauszufinden warum dies der Fall ist. Im Laufe eines agilen Projekts werden üblicherweise folgende Testmethoden angewandt: Unit-Test: Unit-Tests dienen zum testen von einzelnen Klassen oder Methoden. Die Testdaten werden in der Regel zufällig generiert. Unit-Tests sind oft ein fester Bestandteil der agilen Softwareentwicklung und werden so oft wie möglich durchgeführt. Man kann mit Unit-Tests auch einzelne Komponenten auf ihre Performance prüfen, indem man die Unit-Tests um eine Zeitschranke erweitert. Ein sehr populäres Tool für Unit-Tests ist JUnit [Lou05] für Java. Lasttest: Ein Lasttest setzt das System unter starke Last. Dies können, zum Beispiel, viele Anfragen auf eine Internetseite sein. Bei einen Lasttest werden oft Probleme bekannt, die bei einem einfachen Unit-Test nicht auftreten. Lasttests dienen dazu, die Grenzen der Software zu finden. Stress-Test: Beim Stress-Test wird das System an seine Grenzen gebracht. Es wird z.b. geprüft ob Daten bei einen Absturz verloren gehen. Akzeptanztest: Ein Akzeptanztest ist ein Test der Software durch den Kunden. Er ist gerade für Performance-Anforderungen wichtig, da dieser Test

5 Performance Testing in agilen Projekten 5 hilft die vom Kunden gewünschten, aber noch nicht erreichten Performance- Anforderungen, zu finden. 3 Integration von Performance-Testing in agilen Projekten Performance-Testing in einem Software Entwicklungsprozess zu integrieren ist oft sehr schwer. Will man Performance-Testing während des kompletten Entwicklungsprozesses durchführen, kann es sein, dass durch eine geänderte Anforderung die schon vorhandenen Test-Ergebnisse unbrauchbar sind. Damit wäre sehr viel Arbeit umsonst gewesen. Performance-Testing in einem festgelegten Zeitraum am Ende des Softwareentwicklungsprozesses durchzuführen ist auch sehr schwierig, da man dafür erstmal definieren muss wann dieser Zeitraum sein soll. Zudem wäre diese Herangehensweise eigentlich keine agile Softwareentwicklung mehr, es sei denn, man macht es in jeder Iteration, welches uns wieder zu dem Problem der ersten Herangehensweise führen würde. Deshalb entscheiden sich viele agile Teams dafür, dass es zu schwierig und zu risikoreich ist, Performance-Testing zu Integrieren. Dabei ist Performance-Testing an sich ein iterativer Prozess und kann bei einer erfolgreichen Integration einen enormen Gewinn für das Software-Projekt bringen. In diesen Abschnitt werden Tipps, Techniken und Beispiele vorgestellt, wie man Performance-Testing in einem agilen Projekt integrieren kann. Der erste Unterabschnitt beschreibt neun Aktivitäten, die Scott Barber als zentrale Punkte für die Integration von Performance-Testing in agilen Projekten sieht. In den darauf folgenden Abschnitt wird eine Vorgehensweise erläutert, die Jamie Dobson in seinem Erfahrungsbericht [Dob07] beschreibt. 3.1 Neun Zentrale Punkte zur Integration von Performance-Testing in agilen Projekten Nach Scott Barber ist der Schlüssel für eine erfolgreiche Integration von Performance- Testing in agilen Projekten die Einhaltung folgender Punkte: Teamweite Kollaboration Effektive Kommunikation Der Wille mit jeder weiteren Aufgabe die Software zu verbessern Die Fähigkeit des Teams den Fokus flexibel ändern zu können Die folgenden neun Aktivitäten sollen unter Berücksichtigung der oben genannten Punkte eine Integration ermöglichen und von einem speziellen Performance- Testing Spezialisten beaufsichtigt werden. Die Abbildung 2 zeigt den Zyklus, wie diese neun Aktivitäten in Laufe eines Softwareentwicklungsprozesses abgearbeitet werden.

6 6 Daniel Swars Abbildung 2. Performance-Testing Zyklus [Bar09] 1. Verstehe die Projekt-Vision und dessen Kontext Zuallererst ist es wichtig die Projekt-Vision und dessen Kontext zu verstehen. Was soll überhaupt entwickelt werden, und wofür? Nur wenn dies wirklich verstanden ist, kann Performance-Testing richtig in das Projekt integriert werden. Dabei ist es ebenfalls wichtig die Details zu kennen, da jedes Detail einen Einfluss auf die Integration haben kann. 2. Erkenne Gründe für das Performance-Testing Es ist wichtig sich früh im Entwicklungsprozess nochmal mit den Gründen für Performance-Testing zu beschäftigen. Wenn sich das Team dieser Gründe nicht im Klaren ist, kann es leicht passieren, dass die Integration nicht funktioniert. Das Wissen über diese Gründe kann leicht die Prioritäten im Software- Entwicklungsprozess ändern und diesen verbessern. 3. Erkenne den Gewinn, den Performance-Testing dem Projekt bringt: Sobald das System verstanden wurde und die Gründe für Performance-Testing klar geworden sind, sollte der potenzielle Gewinn, den Performance-Testing für das Projekt bringt, klar sein. Dies ist nicht nur das Feststellen der Laufzeit von fast fertiggestellten Komponenten, sondern umfasst auch andere Punkte. Diese könnten z.b. folgende sein: Performance-Testing hilft den Entwicklern bessere Unit-Tests zu erstellen

7 Performance Testing in agilen Projekten 7 Performance-Testing hilft festzustellen ob die vorhandene Hardware ausreicht Durch Performance-Testing erlangt man Trendanalysen zum Ressourcenverbrauch 4. Erstelle und aktualisiere Test-Tools und die Testumgebung Brauchbare Tools für sinnvolle Lasttests sind oft schwer zu finden. Dies hat zur Folge, dass eine der schwierigsten Aufgaben das Entwickeln von Test-Tools und das Sammeln von sinnvollen Testdaten ist. Die Testumgebung und die Tools sollten im Laufe des Entwicklungsprozesses immer weiterentwickelt und konfiguriert werden. Dies ist bei agilen Projekten oft zwingend notwendig, da sich die Software in einem stetigen Wandel befindet. 5. Erkenne und koordiniere nützliche Aufgaben und Tests Irgendwann ist es Zeit die ersten Performancetests oder performanceabhängige, strategische Aufgaben auszuführen. Zu diesem Zeitpunkt ist es ebenfalls wichtig sich nochmal mit diesen Aufgaben auseinander zusetzen und sie zu priorisieren. Danach kann man am besten Entscheiden, welche Aufgabe als erstes durchgeführt werden soll. Diese Priorisierung sollte mit dem ganzen Team geschehen, da nur so die wichtigsten Aufgaben herausgefunden werden können. 6. Aufgaben ausführen Zu den auszuführenden Aufgaben gehört nicht nur das Durchführen von Tests. Genauso gut kann die wichtigste Aufgabe erstmal sein, eine neue Grafikkarte zu besorgen, um zu prüfen ob die Anwendung dann besser läuft. 7. Analysiere die Ergebnisse und kommuniziere diese Ein großer Unterschied zwischen agilen Projekten, zu anderen Projekten, ist die kontinuierliche Vermittlung von Ergebnissen und Daten im Team. So ist es wichtig, zwischendurch Reports, Trend-Analysen oder ähnliches zu Testergebnissen zu erstellen und diese dem Team mitzuteilen. Dies hält das Team auf dem Laufenden und motiviert es die performanceabhängigen Aufgaben weiter durchzuführen. Sobald dies geschehen ist beginne wieder mit Punkt Erneuere die Werte und Kriterien Täglich und nach jedem Abschluss einer Aufgabe sollte geprüft werden ob die Kriterien, der noch zu erledigen Aufgaben, immer noch die selben sind und gegebenenfalls angepasst werden müssen. Es könnte auch sein, dass sich einige Performancekriterien komplett geändert haben. Dafür werden die Punkte 1-3 nochmal überdacht. Dies sollte mit dem kompletten Team diskutiert werden. 9. Repriorisiere die Aufgaben In den regelmäßigen Meetings, die man mit dem Team im Laufe des agilen

8 8 Daniel Swars Projekts hält, sollten die noch offenen Performance-Testing-Aufgaben neu priorisiert werden. Es sollte dafür gesorgt werden, dass genug Zeit dafür reserviert ist, damit das Team gute Performance-Testing abhängige Entscheidungen treffen kann. Zusätzliche Punkte: Zusätzlich zu den oben genannten Aktivitäten sollten noch folgende Punkte beachtet werden: Vergesse nicht mit dem Team zu kommunizieren Egal wie lang die Zeit zwischen Performance-Builds liegt, Performance-Testing hängt immer hinter der Entwicklung hinterher. Zuviele Performance-Testing- Aufgaben dauern einfach zu lange um sie durchzuführen. Das sollte immer bedacht werden, wenn die Performance-Testing abhängigen Aufgaben priorisiert werden. Nutze schon existierende Unit-Tests für Performance-Testing auf Komponentenebene. Sie sind einfach zu nutzen und helfen den Entwicklern immer auf dem Laufenden zu sein. Performance-Testing ist einer der größten Auslöser für große Architektur-, Design- und Hardwareänderungen. Führe dem Team deshalb so oft wie es geht am Tag die Performance-Testing Reports vor, damit Performance- Probleme schnell dem Team bekannt werden und sie darauf reagieren können. Die Reports müssen vom Team gelesen und verstanden werden. Teste früh und oft. Release früh und oft. Die von Scott Barber beschriebenen Aktivitäten sind sehr allgemein gehalten und bieten mit Sicherheit eine gute Grundlage für das erfolgreiche durchführen von Performance-Testing in agilen Projekten. Ein großer Schwachpunkt dieser Vorgehensweise ist der benötigte Performance-Testing Spezialist. In Scrum und anderen agilen Entwicklungsprozessen ist vorgesehen, dass jeder Entwickler die gleichen Aufgaben übernehmen kann, und das somit keine Spezialisten existieren. Der von Scott Barber vorgeschlagene Ansatz würde somit ein wenig die Agilität der agilen Softwareentwicklung zunichte machen. So würde bei einem Krankheitsfall des Performance Spezialisten das komplette Performance-Testing mehr oder weniger stillstehen, da kein anderer Entwickler ohne große Einarbeitungsphase diese Aufgaben komplett übernehmen könnte. 3.2 Agiles Performance-Testing Jamie Dobson stellt in seinem Erfahrungsbericht Performance-Testing on an Agile Project [Dob07] einen konkreten Ansatz für agiles Performance-Testing vor. In diesem Artikel beschreibt der Autor,wie er Performance-Testing im Projekt Daedalus integriert hat. Deadalus ist eine Schnittstelle mit der Aufgabe die Client-Anwendungen von einer Reihe von Buchungs- und Planungs- Anwendungen zu entkoppeln. Nach Jamie Dobson umfasst agiles Performance-Testing zwingend die folgenden Punkte:

9 Performance Testing in agilen Projekten 9 Selbständige Entwicklungsteams Spezialisten für Performance-Testing Automatische Performance-Tests Eine Sammlung von Entwicklungstechniken für Performance-Testing bzw. Optimierung Nicht funktionale Anforderungen sollen iterativ in Team-Zusammenarbeit mit Hilfe der Nutzer-Erfahrungen bestimmt werden Der Softwareentwicklungsprozess muss dabei einen starken Fokus auf Softwarequalitäten besitzen. Neben dem Entwicklungsteam gab es ein separates Performance-Testing Team, welches sich nicht nur um die Performance-Tests von Daedalus gekümmert hat, sondern auch noch in anderen Projekten integriert war. Während der Softwareentwicklung wurden drei verschiedene Arten von Performance-Testing durchgeführt: Beta- bzw. Kunden-Testing, Deployment-Testing, und Developer-Testing. Beta Testing: Da es Ziel des Softwareprojekts war eine Schnittstelle zu Entwickeln, brachte es enorme Vorteile eine testbare Version so schnell herauszugeben wie möglich. Damit war es möglich von den Performance-Tests der anderen Entwicklungsteams zu profitieren, die eine Software entwickeln, die mit Deadalus arbeitet. Diese Teams haben ebenfalls Performance-Tests Strategien bei der sie eine vorhandene, lauffähige Version der Deadalus-Schnittstelle durchaus nutzen würden. So würden die anderen Entwicklungsteams mit ihren Performance- Tests gleichzeitig Deadalus testen. Diese Performance-Tests bringen einen enormen Gewinn in das Softwareprojekt, da diese die Schnittstelle mit echten Nutzer-Daten testen. Nur Agile Softwareentwicklung garantiert ein zu jeder Zeit lauffähiges System und damit ein sehr schnelles Feedback bei dieser Entwicklung. Deployment-Testing: Beim Deployment-Testing wird die Anwendung auf eine Testumgebung übertragen, die ein Abbild des Zielsystems sein soll. Deployment- Tests sind sehr ineffizient, da die Übertragung der Software auf das Zielsystem immer sehr viel Zeit in Anspruch nimmt und damit den eigentlich Entwicklungsprozess bremst. Obwohl Deployment-Tests dieses Problem mit sich bringen, sind sie essentiell wichtig, da diese die Software in ihrer wirklichen Umgebung testet. Da die benötigten Ressourcen für diese Tests oft sehr teuer und rar sind, ist es in der Regel nicht möglich einen ständigen Zugriff auf diese zu reservieren. Dies macht echtes agiles Performance-Testing schwierig. Der Trick hierbei ist, so kurze Iterationen zu machen, wie es das Projekt zulässt. Dazu wurden zwei Wochen lange Iterationen eingeführt, in einem sechs Wochen dauernden Release-Zyklus. Der sechs Wochen lange Release-Zyklus basierte auf dem Konzept des Scrum-Sprints. In den ersten beiden Iterationen wurde komplett auf Deployment-Testing verzichtet und nur die anderen beiden, oben genannten Testing-Arten angewandt. Am Anfang der letzten Iteration, also in der Woche fünf, wurde ein Deployment fürs Test-Team erstellt und das Test-Team kümmerte sich ums Performance-Testing. Während der fünften Woche konnten durch das

10 10 Daniel Swars Performance-Testing bekannt gewordene Probleme behoben werden. In der sechsten Woche bekam das Performance-Testing Team dann ein neues, überarbeitetes Deployment. Wärhend der kompletten letzten Iteration stand ein Entwickler voll und ganz für den Support der Performance-Tester zur Verfügung. Ein wichtiger Aspekt um dies umzusetzen, ist das komplette Team von dieser agilen Arbeitsweise zu überzeugen. Performance-Tester haben z.b. oft Angst vor möglichen Anforderungsänderungen, die jederzeitig in einem Agilen Projekt auftreten können und damit die bisher erlangten Testergebnisse möglicherweise unbrauchbar machen. Dies ist immer ein sehr wichtiger Punkt für die Performance-Tester. In Daedalus waren die Anforderungen zwar sehr ungenau spezifiziert, aber sehr gut bekannt und damit waren spätere Performanceabhängige Überraschungen sehr unwahrscheinlich. In einem solchen Projekt ist es nicht ganz so schwierig das Team zu überzeugen. Umso ungewisser die Anforderungen der Software sind, umso schwieriger wird es die Performance-Tester zu überzeugen, da es sehr wahrscheinlich ist, dass Performance-Testing Ergebnisse irgendwann obsolet werden. Dies kann z.b. passieren wenn grundlegende Änderungen in der Architektur vorgenommen werden. Ein weiteres Gegenargument der Performance-Tester war der recht komplizierte und aufwendige Vorgang, der für den Deployment-Vorgang nötig war. Dies konnte aber leicht mit Hilfe von Build-Tools gelöst werden. Zum Schluss konnten die Performance-Tester überzeugt werden, dass ein iterativer Prozess die bessere Alternative ist. Nicht zuletzt, weil bei einem iterativen Prozess eine sehr anstrengende und lange Testphase am Ende des Entwicklungsprozesses erspart bleibt. Developer Testing: Zusätzlich zum Beta-Testing und Deployment-Testing wurde noch Developer Testing von den Entwicklern zum Performance-Testing eingesetzt. Zwar ist es nicht möglich mit Developer-Testing das Deployment- Testing zu ersetzen, aber es ist möglich die Arbeit des Performance-Testing Team stark zu reduzieren. Dabei wurden folgende Methoden eingesetzt: Lokaler Lasttest: Um alle Performance bezogenen Effekte einer neuen oder geänderten Komponente in Erfahrung zu bringen, reicht es oft nicht aus, einfache Unit-Tests durchzuführen. Deshalb galt eine Komponente erst als fertiggestellt, wenn sie einen Lasttest bestanden hat. Dabei wurde der Lasttest nur lokal für die jeweilige Komponente durchgeführt. Nur so werden Probleme bekannt, die bei Belastung erst entstehen. Lokaler Lasttest auf dem Deployment: Sobald ein Bug vom Performance- Testing Team gefunden wurde, bemühte sich das Entwicklungsteam diesen Fehler lokal zu reproduzieren und zu fixen. Da sich die Deployment- Umgebung von der Entwicklungsumgebung unterschied, musste das Deployment nach den Verbesserungen auch nochmal einen lokalen Lasttest bestehen. Agile Performance Optimierung: Agile Performance Optimierung ist sehr simpel. Im Prinzip erweitert man die vorhandenen Unit-Tests nur um eine Laufzeit-Begrenzung, in der der Unit-Test ablaufen soll und arbeitet dann folgende Schritte ab:

11 Performance Testing in agilen Projekten Bottlenecks der Anwendung finden 2. Finde die durchschnittliche Laufzeit heraus 3. Erstelle einen Test mit der gewünschten Laufzeit 4. Optimiere die Methode 5. Wiederhole bis du fertig bist Diese Testmethode ist sehr einfach zu integrieren, da die Unit-Tests in der Regel sowieso schon existieren. Nur sollte man die Testergebnisse sehr kritisch betrachten, da die Testergebnisse auf jedem System unterschiedlich sein können. Es kann sogar vorkommen, dass die Tests je nach Zeit auf dem gleichen System zu unterschiedlichen Ergebnissen führen, da z.b. mehr Prozesse im Hintergrund laufen. Zudem nutzen Unit-Tests normalerweise keine Nutzer-Daten sondern generieren zufällige Testfälle. Dies kann dazu führen, dass man das System auf unrealistischen Testdaten optimiert. Generell ist diese Methode hilfreich um einzelne Funktionen zu optimieren, doch sollte sie mit Vorsicht durchgeführt werden. Zusammenfassend kann man sagen, dass man diese Techniken leicht zum finden und beheben von Performance-Bugs nutzen kann. Developer-Testing unterstützt das Deployment-Testing und ist notwendig für eine funktionierende Performance-Testing Strategie. 3.3 Zusammenfassung: Wie dieses Beispiel zeigt, ist es rein theoretisch einfach Performance-Testing in einem agilen Projekt zu integrieren. Hauptproblem ist hierbei das Team zu motivieren und die angedachten Methoden und Praktiken durchzusetzen. Der Autor hält es aber für unwahrscheinlich, dass echtes Agiles Performance-Testing funktionieren könnte, bei dem das Performance-Testing von dem Entwicklungsteam durchgeführt wird und es kein separates Performance-Testing Team gibt. Das Hauptproblem sieht er bei dem benötigten Erfahrungen, die ein normaler Entwickler normalerweise in den benötigten Maß nicht hat. So existiert hier ebenfalls, wie auch in der von Scott Barber beschriebenen Vorgehensweise 3.1 eine separate Instanz fürs Performance-Testing. Im Gegensatz zu den Tipps von Scott Barber wurden hier konkrete Vorgehensweisen zum testen erläutert. Doch findet man zwischen der von Scott Barber beschriebenen Vorgehensweise und dem Erfahrungsbericht von Jamie Dobson viele Gemeinsamkeiten. Beide verdeutlichen immer wieder wie wichtig es ist das komplette Team zu integrieren und das die Performance-Tester mit dem Entwicklungsteam in ständiger Kommunikation zueinander sein müssen. Zusätzlich wird von beiden erwähnt wie wichtig es ist das Team zu motivieren und automatische Tests zu haben. Manuelle Tests sind zu Aufwändig und sollten nur durchgeführt werden, wenn unbedingt nötig. Es existiert noch immer das Problem, welches Auftritt wenn die Performance- Anforderungen sehr unklar sind. Dies macht es fast unmöglich richtiges agiles Performance-Testing durchzuführen, da durch sich ändere Performance-Anforderungen schon vorhandene Performance-Testing Ergebnisse nutzlos werden. In der von

12 12 Daniel Swars Jamie Dobson Vorgehensweise wird betont, dass das bei seinem Projekt kein Problem war, da die Performance-Anforderungen von Anfang an sehr gut bekannt waren. Der nächste Abschnitt beschreibt eine Technik, wie sich Performance- Anforderungen auch in einem agilen Projekt beschreiben lassen, bei dem die Anforderungen noch nicht so klar definiert sind. 4 Spezifizieren von Performance-Anforderungen Performance-Anforderungen zu definieren ist in agilen Projekten oft schwierig, da viele Anforderungen anfangs sehr unklar sind. Ho et. al. stellen in [HJWM06] das Performance requirements evolution model vor, mit den man Performance- Anforderungen inkrementell, mit wachsendem Detaillevel im Laufe des Projekts, definieren kann. Die grundsätzliche Idee ist, die Anforderungen erstmal sehr grob zu definieren und dann im laufe des Projekts immer mehr Details hinzuzufügen. Performance requirements evolution model (PREM) PREM ist ein evolutionäres Modell zur Definition von Performance-Anforderungen. Das Modell definiert Richtlinien für verschiedene Detaillevel. In jedem Detaillevel werden die benötigten Performance Charakteristiken und die Art der Validierung definiert. Erfolgreich genutzt wurde es erstmals von Ho et. al. in einen IBM-Projekt [HJWM06]. Das folgende Beispiel zeigt, wie wichtig detailliert beschriebene Performance- Anforderungen sein können. Eine Performance-Anforderung könnte einfach definiert sein als: Der Autorisierung-Prozess sollte nicht länger als 0.2 Sekunden dauern. Eine simple Methode dieses zu prüfen wäre den Autorisierung-Prozess einige Male durchlaufen zu lassen und zu prüfen ob die durchschnittliche Dauer unter 0.2 Sekunden liegt. Wenn aber das System irgendwann in Betrieb ist und mehrere Autorisierung-Prozesse gleichzeitig durchgeführt werden, kann es leicht passieren, dass die Dauer bei jedem Nutzer länger als 0.2 Sekunden dauert, obwohl das System den oben beschriebenen Test bestanden hat. Dieses Beispiel zeigt, dass es leicht zu falschen Interpretationen von Performance- Anforderungen kommen kann, wenn diese wage definiert sind. In agilen Projekten ist dies ein häufiges Problem, da dort die Anforderungen zuerst informell dokumentiert sind. Das PREM klassifiziert Performance-Anforderungen in vier Level. Die Abbildung 3 zeigt das PREM graphisch. Level 0: In Level 0 werden die Performance-Anforderungen umgangssprachlich als qualitative Anforderungen definiert. In diesem Level werden die Anforderungen so definiert, wie der Kunde sie wahrnimmt. Durch die Informalität lassen sich diese Anforderungen leicht beschreiben. Sie haben eine starke Ähnlichkeit zu den Funktions-Storys, die in Extreme Programming definiert werden. Eine Level 0 Performance-Anforderung ist der Startpunkt von dem aus der Kunde und der Entwickler präzisere Anforderungen definieren. Ein

13 Performance Testing in agilen Projekten 13 Abbildung 3. PREM [HJWM06] Beispiel für eine Level 0 Performance-Anforderung ist: Der Autorisierung- Prozess sollte beendet sein, bevor der Benutzer die Geduld verliert.. Level 1: Für ein erfolgreiches Performance-Testing in agilen Projekten ist Automatisierung von Tests notwendig. Das manuelle Durchführen von Tests ist sehr zeitraubend und sollte, soweit es geht, vermieden werden. Damit ein Performancetest automatisiert werden kann ist es notwendig quantifizierbare Anforderungen zu definieren. Diese Anforderungen könnten z.b. von den Kunden definiert werden. Level 0 Performance-Anforderungen werden zu Level 1 Performance-Anforderungen durch das Hinzufügen von quantifizierbaren Bedingungen. Einige typische quantifizierbare Anforderungen sind z.b. der Durchsatz (Queries/Sekunde, Frames/Sekunde, Transaktionen/Sekunde etc.) oder die Responsetime. Ein Beispiel für eine Level 1 Performance-Anforderung ist: Der Autorisierung- Prozess sollte innerhalb von 0.2 Sekunden abgeschlossen sein. Der quantifizierbare Wert 0.2 könnte dabei in einer Diskussion zwischen Kunde und Entwickler entstanden sein. Durch die Quantifizierung der Performance- Anforderung ist es nun möglich einen automatischen Test zu schreiben, der diese Anforderung auf einem passenden Testsystem überprüft. Level 1 Performance-Anforderung sollten für Single-User-Systeme genügen. Level 2: Für Multi-User-Systeme, wie z.b. Webseiten, reichen Level 1 Anforderungen nicht aus, da sie nicht zeigen wie verschiedene Prozesse aufeinander Einfluss nehmen und wie die Funktionen auf den Zielsystem bei einer normalen Arbeitslast reagiert. Diese Anforderungen werden System-Ausführungs- Anforderungen (SAA) genannt. SAA definieren welche Prozesse sich auf dem System befinden und wie oft sie im Durchschnitt ausgeführt werden. Der Entwickler definiert mit Hilfe seiner Erfahrung die SAA als quantitative Anforderungen. Eine Level 1 Anforderung wird zu einer Level 2 Anforderung wenn SAA hinzugefügt werden. Ein Beispiel für eine Level 2 Anforderung ist: Im Durchschnitt erreichen zwanzig Anfragen pro Minute das System. Davon sind 10% Autorisierungsanfragen. Der Autorisierungs-Prozess soll innerhalb von 0.2 Sekunden abgeschlossen sein.. Level 3: Für Echtzeit-Systeme oder andere Performance-Kritische Systeme sollten die Zeitanforderungen strikter oder im Worst-Case definiert werden. Level 3 Anforderungen definieren die Performance-Anforderungen im Worst- Case. Ein Beispiel für eine Level 3 Anforderung ist: Während der Hauptbelastungszeit erreichen 100 Anfragen pro Minute das System. Davon sind

14 14 Daniel Swars 10% Autorisierungsanfragen. Die anderen Anfragen beziehen sich zu 90% auf den Warenkorb. Der Autorisierungs-Prozess muss innerhalb von 0.2 Sekunden abgeschlossen sein.. Diese Anforderungen können durch Beobachtungen von der Nutzung vorangehender Systeme in Erfahrung gebracht werden. Solange das System keine Performancekritischen Anforderungen hat, werden Level 3 Anforderungen normalerweise nicht benötigt. Mit PREM ist es möglich Performance-Anforderungen schon sehr früh zu definieren. Während der Entwicklung können die Performance-Anforderungen und Test-Cases weiter spezifiziert werden. Zusätzlich erinnert PREM den Entwickler immer wieder daran weitere Performance-Faktoren zu finden. Der grundsätzliche Unterschied zu einer funktionalen Anforderung und einer Performance- Anforderung ist, dass eine Performance-Anforderung nie wirklich fertig implementiert ist. Man kann eine Performance-Anforderung nicht einfach aus einer Anforderungsliste nehmen, diese dann implementieren und von der Liste streichen. Typischerweise werden daher während einer Iteration funktionale Anforderung ausgewählt und Implementiert. Wenn eine funktionale Anforderung ausgewählt wird, die Performance-Kritisch ist, sollten Performance-Anforderungen definiert werden. Diese Performance-Anforderungen werden nach den PREM weiter spezifiziert, sobald weitere Performancedetails im Laufe des Entwicklungsprozesses bekannt werden. Viele Teams sind vielleicht dazu verleitet Performance-Anforderungen direkt auf höheren Level zu definieren. Dies ist aber keine gute Strategie. Zum einen kann es sehr lange dauern die benötigten Daten für die höheren Detaillevel zu erhalten. Zum anderen enthält jedes Level eine andere Sicht auf die Performance. Oft kann es sogar sein, dass Performance-Anforderungen auf niedrigen Level vollkommen ausreichen. Für kleinere, kaum genutzte Funktionen, die nur einen ganz kleinen Teil auf die Performance des gesamten Systems haben, reicht oft schon eine Level 1 Beschreibung, obwohl es sich um ein Multi-User-System handelt. Die hier vorgestellte Technik lässt sich gut mit den in 3.1 und 3.2 beschriebenen Vorgehensweisen kombinieren. Damit ist es gut möglich auch Performance- Testing mit sehr ungenau spezifizierten Performance-Anforderungen durchzuführen. Die Performance-Anforderungen werden nur dann weiter spezifiziert wenn genug Informationen über die Anforderung bekannt ist. Das führt dazu, dass eine Änderung der grundsätzlichen Performance-Anforderungen sehr unwahrscheinlich ist und ein großes Problem des agilen Performance-Testing nicht mehr vorhanden ist. 5 Fazit Zusammenfassend kann man sagen, dass eine erfolgreiche Integration und Durchführung von Performance-Testing in agilen Projekten nicht wirklich kompliziert ist. Man muss nur grundsätzlich dafür sorgen, dass das Team motiviert ist, die Kommunikation aller Mitglieder richtig funktioniert und das die gesetzten Ziele auch vom ganzen Team erreicht werden wollen. Scott Barber und Jamie Dobson beschreiben Vorgehensweisen, die eine Erfolgreiche Integration erlauben.

15 Performance Testing in agilen Projekten 15 Während die von Scott Barber beschriebenen Handlungen sehr allgemein gehalten sind, und daher wohl fast immer durchführbar sind, beschreibt Jamie Dobson seine Lösung für eine sehr spezielle Software. Trotzdem kann man viele Methoden, die Jamie Dobson in Deadalus genutzt hat auch in andere Projekte überführen. In Kombination mit dem in Abschnitt 4 beschriebenen PREM lassen sich viele Probleme lösen, die im Laufe eines agilen Projekts im Bereich Perfomance-Testing auftreten können. Offen bleibt noch die Frage, inwiefern es möglich ist Performance-Testing ausschließlich vom Entwicklerteam durchführen zu lassen und damit ein agileren Softwareprozess zu erlauben, als die in Abschnitt 3.1 und 3.2 beschriebenen Vorgehensweisen. Jamie Dobson und Scott Barber halten beide einen oder mehrere Performance-Testing Spezialisten für unbedingt notwendig. Literatur [AG03] [Agi] [Bar09] [Bec99] Ambu, Walter und Fabrizio Gianneschi: Extreme Programming at Work. In: Marchesi, Michele und Giancarlo Succi (Herausgeber): XP, Band 2675 der Reihe Lecture Notes in Computer Science, Seiten Springer, Manifesto for Agile Software Development. Barber, Scott: An Explanation of Performance Testing on an Agile Team, May of_performance_testing_on_an_agile_team-part-1.asp und msdn.microsoft.com/en-us/library/bb aspx. Beck, Kent: Embracing Change with Extreme Programming. Computer, 32:70 77, Oktober [Dob07] Dobson, Jamie: Performance Testing on an Agile Project. In: AGILE, Seiten IEEE Computer Society, [Ghe05] Gheorghiu, Grig: Performance vs. load vs. stress testing, February performance-vs-load-vs-stress-testing.html. [HJWM06] Ho, Chih-Wei, Michael J. Johnson, Laurie Williams und E. Michael Maximilien: On Agile Performance Requirements Specification and Testing. In: AGILE, Seiten IEEE Computer Society, [Lou05] [Pul06] [SB01] [SM07] Louridas, Panagiotis: JUnit: Unit Testing and Coding in Tandem. IEEE Software, 22(4):12 15, Puleio, Michael: How Not to Do Agile Testing. In: AGILE 06: Proceedings of the conference on AGILE 2006, Seiten , Washington, DC, USA, IEEE Computer Society. Schwaber, Ken und Mike Beedle: Agile Software Development with Scrum. Alan R. Apt, First Auflage, Shu, Xueling und Frank Maurer: A Tool for Automated Performance Testing of Java3D Applications in Agile Environments. In: ICSEA, Seite 35. IEEE Computer Society, [Wik09] Wikipedia: Scrum, May 2009.

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

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

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

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

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

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

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

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

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

Mehr

Agile 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

Agiles Testmanagement am Beispiel Scrum

Agiles Testmanagement am Beispiel Scrum Agiles Testmanagement am Beispiel Scrum SEQIS Software Testing Know-How Weitere Termine 16. September Testmanagement mit externen Partnern 21.Oktober Software unter Druck: Erfolgsfaktoren bei Last- und

Mehr

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

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

Mehr

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

Agilität: Scrum. Eine Kurzübersicht zum schnellen Einstieg. AG Scrum Kurzübersicht

Agilität: Scrum. Eine Kurzübersicht zum schnellen Einstieg. AG Scrum Kurzübersicht Agilität: Scrum Eine zum schnellen Einstieg Sie finden diese und weitere Präsentationen unter (-> Klick): http://www.peterjohannconsulting.de/index.php?menuid=downloads Für (agile) Entwickler und (traditionelle)

Mehr

SCRUM. Scrum in der Software Entwicklung. von Ernst Fastl

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

Mehr

Agile Softwareentwicklung mit Scrum

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

Mehr

Agiles Projektmanagement mit Scrum

Agiles Projektmanagement mit Scrum Agiles Projektmanagement mit Scrum Josef Scherer CSM, CSP Lösungsfokussierter Berater josef.scherer@gmail.com 2009, Josef Scherer Scherer IT Consulting Freiberuflicher Scrum Coach Lösungsfokussierter Berater

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

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

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

Softwareentwicklung und Application Lifecycle Management als Geschäftsprozess

Softwareentwicklung und Application Lifecycle Management als Geschäftsprozess Softwareentwicklung und Application Lifecycle Management als Geschäftsprozess Von David Chappell Gefördert durch die Microsoft Corporation 2010 Chappell & Associates David Chappell: Softwareentwicklung

Mehr

2 Agile und klassische Vorgehensmodelle

2 Agile und klassische Vorgehensmodelle 9 2 Agile und klassische Vorgehensmodelle Dieses Kapitel gibt eine knappe Charakteristik des agilen Projektmanagementframeworks Scrum und der inzwischen auch populären, aus dem Lean Product Development

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

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

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

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

- 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

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

Leichtgewichtige Traceability im agilen Entwicklungsprozess am Beispiel von Scrum

Leichtgewichtige Traceability im agilen Entwicklungsprozess am Beispiel von Scrum Leichtgewichtige Traceability im agilen Entwicklungsprozess am Beispiel von Scrum Traceability Workshop SE 2013 Aachen 26. Feb. 2013 Elke Bouillon 1, Baris Güldali 2, Andrea Herrmann 3, Thorsten Keuler

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

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

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

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

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

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

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

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

Seminar Softwareentwicklung in der Wissenschaft

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

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

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

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

Schneller zu Ergebnissen unser erstes Agile Project

Schneller zu Ergebnissen unser erstes Agile Project Schneller zu Ergebnissen unser erstes Agile Project Thomas Schmidt Juni 2014 Agenda Das Project Projektstruktur und der Projektplan Theorie vs Realität Releases und Sprints Executable Code Angst vor dem

Mehr

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 Software Testing Automatisiert Manuell 100% 70% 1 Überwiegender Teil der Testing Tools fokusiert auf automatisiertes Testen Microsoft

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

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 Entwicklung àla The Eclipse Way. Dipl.-Inform. Martin Lippert Senior IT-Berater martin.lippert@akquinet.de

Agile Entwicklung àla The Eclipse Way. Dipl.-Inform. Martin Lippert Senior IT-Berater martin.lippert@akquinet.de Agile Entwicklung àla The Eclipse Way Dipl.-Inform. Martin Lippert Senior IT-Berater martin.lippert@akquinet.de Über mich Martin Lippert Senior-IT-Berater bei Akquinet Agile GmbH martin.lippert@akquinet.de

Mehr

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

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

Mehr

Scrum 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

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

Stefan Toth. Befehl von unten: Softwarearchitektur für dynamische Projekte

Stefan Toth. Befehl von unten: Softwarearchitektur für dynamische Projekte Stefan Toth Befehl von unten: Softwarearchitektur für dynamische Projekte [ ] Ob man diese Entwickler schließlich Architekten nennt oder nicht, bleibt dem Projekt überlassen und sollte für die tatsächliche

Mehr

Selbstorganisiert ein Ziel erreichen Analyse, Architektur und Design in agilen Software-Projekten

Selbstorganisiert ein Ziel erreichen Analyse, Architektur und Design in agilen Software-Projekten Selbstorganisiert ein Ziel erreichen Analyse, Architektur und Design in agilen Software-Projekten 1 Qualifikation Über den Vortragenden Freiberuflicher SW-Entwickler und Berater seit 2006 Certified Scrum

Mehr

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

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

Mehr

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

Seminarausarbeitung AW1

Seminarausarbeitung AW1 Hochschule für Angewandte Wissenschaften Hamburg Hamburg University of Applied Sciences Seminarausarbeitung AW1 Sven Klaholz - Collaboration in distributed Scrum - Fakultät Technik und Informatik Department

Mehr

Agiles Projektmanagement mit Scrum. Name: Eric Dreyer

Agiles Projektmanagement mit Scrum. Name: Eric Dreyer Definition 2 Was ist Scrum? Scrum ist ein schlanker, agiler Prozess für Projektmanagement u. a. in der Softwareentwicklung. Woraus besteht Scrum? Einfache Regeln Wenige Rollen Mehrere Meetings Einige Artefakte

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

Swp08-6 Verantwortliche: Yundensuren, Baigalmaa. Testkonzept

Swp08-6 Verantwortliche: Yundensuren, Baigalmaa. Testkonzept Testkonzept 1.Einführung Um die Zuverläsigkeit und die Qualität der Software und des gesamten Systems zu verbessern, sind Tests durchzuführen. Die Testreihe läst sich in drei Stufen einteilen, nülich Komponententest,

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

Scrum E I N F Ü H R U N G

Scrum E I N F Ü H R U N G Scrum EINFÜHRUNG Was ist Scrum? Agiles Vorgehensmodell Grundüberzeugungen Erste Tendenzen Mitte der 80er Jahre Grundidee: Entwickeln in Inkrementen Parallelen zur Lean Production Agiles Manifest Jeff Sutherland

Mehr

Herkömmliche Softwareentwicklungsmodelle vs. Agile Methoden

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

Mehr

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

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

Mehr

extreme Programming (XP)

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

Mehr

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

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

Mehr

Hilfe, mein SCRUM-Team ist nicht agil!

Hilfe, mein SCRUM-Team ist nicht agil! Hilfe, mein SCRUM-Team ist nicht agil! Einleitung: Laut unserer Erfahrung gibt es doch diverse unagile SCRUM-Teams in freier Wildbahn. Denn SCRUM ist zwar eine tolle Sache, macht aber nicht zwangsläufig

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

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

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

Mehr

Agile Embedded Projekte mit Scrum & Kanban. Embedded Computing Conference 2012 Urs Böhm

Agile Embedded Projekte mit Scrum & Kanban. Embedded Computing Conference 2012 Urs Böhm Agile Embedded Projekte mit Scrum & Kanban Embedded Computing Conference 2012 Urs Böhm Der Ingenieur Urs Böhm Dipl.-Ingenieur Elektrotechnik Projektingenieur VDI Certified ScrumMaster urs.boehm@noser.com

Mehr

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

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

Mehr

Software Engineering und Projektmanagement Fragenausarbeitung der Prüfung vom 26.04.2007

Software Engineering und Projektmanagement Fragenausarbeitung der Prüfung vom 26.04.2007 Software Engineering und Projektmanagement Fragenausarbeitung der Prüfung vom 26.04.2007 Christoph Redl Quelle der Fragen: http://www.informatik-forum.at/showthread.php?t=54097 1 SCRUM Prinzip + Vorteile

Mehr

1 Einleitung. Software Engineering. Vorgehensweisen

1 Einleitung. Software Engineering. Vorgehensweisen 1 Noch ein Buch über Software Engineering? Warum nicht! Wir folgen einem Prinzip, das zur Lösungsfindung in den verschiedensten Domänen Einzug gehalten hat: die Betrachtung aus verschiedenen Blickwinkeln.

Mehr

Agile Softwareentwicklung. Yelve Yakut

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

Mehr

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

Agiles Anforderungsmanagement mit SCRUM im regulierten Umfeld

Agiles Anforderungsmanagement mit SCRUM im regulierten Umfeld Agiles Anforderungsmanagement mit SCRUM im regulierten Umfeld Bernhard Fischer Fischer Consulting GmbH MedConf 2011 Luzern Folie 1 Wozu brauchen wir Requirements? MedConf 2011 Luzern Folie 2 Der Anforderungszoo

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

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

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

Referat Extreme Programming. Von Irina Gimpeliovskaja und Susanne Richter

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

Mehr

AGILE 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

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

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

Mehr

Scrum. Max Jäger. Frankfurt, den 07. Juli 2012

Scrum. Max Jäger. Frankfurt, den 07. Juli 2012 Max Jäger Frankfurt, den 07. Juli 2012 I Inhalt Inhalt Abkürzungen Abbildungen III IV 1 Scrum 1 1.1 Einführung............................. 1 1.2 Überblick über Scrum....................... 1 1.3 Rollen................................

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

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

WBS. Sprint. Projektmanagement und Agile Methoden Widerspruch oder Ergänzung? Ing. Markus Huber, MBA

WBS. Sprint. Projektmanagement und Agile Methoden Widerspruch oder Ergänzung? Ing. Markus Huber, MBA PM WBS Sprint Projektmanagement und Agile Methoden Widerspruch oder Ergänzung? Ing. Markus Huber, MBA Über den Vortragenden IT-Leiter der Austrian Gaming Industries (Novomatic Group of Companies) MBA in

Mehr

Testmanagement in IT-Projekten

Testmanagement in IT-Projekten Teil 1: Projektmagazin 05/20009 Teil 2: Projektmagazin 06/2009 1 Test: Prozess, bei dem ein Programm oder ein Software-System ausgeführt wird, um Fehler zu finden Teil 1: Projektmagazin 05/20009 Teil 2:

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

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

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

Mehr

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

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

Projektmanager, Scrummaster, SW-Entwickler. Webbasierte Software. Teilweise Medizinprodukt Scrum seit 2006

Projektmanager, Scrummaster, SW-Entwickler. Webbasierte Software. Teilweise Medizinprodukt Scrum seit 2006 Überleben mit Scrum Andrea Schulz Hintergrund Projektmanager, Scrummaster, SW-Entwickler Siemens Healthcare Webbasierte Software Produkte (Releases als Projekte) Teilweise Medizinprodukt Scrum seit 2006

Mehr

Abweichungsmanagement. Probleme hat doch jeder

Abweichungsmanagement. Probleme hat doch jeder 1 Abweichungsmanagement Probleme hat doch jeder SEQIS Software Testing Know-how Veranstaltungen 2011 24.03.2011 16.06.2011 22.09.2011 24.10.2011 Nicht zuviel und nicht zuwenig: Testdokumentation Theorie

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

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

Projektorganisation und Vorgehen in agilen Projekten. Noser Technologieimpulse München 2013 - Matthias Neubacher

Projektorganisation und Vorgehen in agilen Projekten. Noser Technologieimpulse München 2013 - Matthias Neubacher Projektorganisation und Vorgehen in agilen Projekten Noser Technologieimpulse München 2013 - Matthias Neubacher Ein wenig Theorie Agile Methoden Warum? hohe Anpassbarkeit schnellere Ergebnisse günstigere

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

Agile Testing. Der agile Weg zur Qualität. von Siegfried Tanczos, Martin Klonk, Richard Seidl, Helmut Pichler, Manfred Baumgartner. 1.

Agile Testing. Der agile Weg zur Qualität. von Siegfried Tanczos, Martin Klonk, Richard Seidl, Helmut Pichler, Manfred Baumgartner. 1. Agile Testing Der agile Weg zur Qualität von Siegfried Tanczos, Martin Klonk, Richard Seidl, Helmut Pichler, Manfred Baumgartner 1. Auflage Hanser München 2013 Verlag C.H. Beck im Internet: www.beck.de

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

Scrum. Golo Roden. www.goloroden.de www.des-eisbaeren-blog.de

Scrum. Golo Roden. www.goloroden.de www.des-eisbaeren-blog.de Scrum 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 MCP und CCD > Autor, Sprecher

Mehr

Zwei ungleiche Geschwister

Zwei ungleiche Geschwister Zwei ungleiche Geschwister Wie stehen agile Praktiken und ISTQB Lehrmeinung zueinander Martin Klonk ANECON Software Design und Beratung G.m.b.H. Alser Str. 4/Hof 1 A-1090 Wien Tel.: +43 1 409 58 90 www.anecon.com

Mehr