Normkonforme Medizinproduktentwicklung

Größe: px
Ab Seite anzeigen:

Download "Normkonforme Medizinproduktentwicklung"

Transkript

1 Agile Methoden in der Medizintechnik mit agilen Prozessen und Artefakten Marc Bless Version Mai 2012, Baden-Baden

2 Inhaltsverzeichnis Vorwort 4 Von der Norm zum Prozess: des Meta-Prozesses 7 Überblick der Prozesse und Artefakte 10 Prozesse, Meetings, Reviews 12 Acceptance Testing 13 Clean Code / SOLID Principles 14 Continuous Integration 16 Early Integration / Early Testing 17 Exploratory and Manual Testing 18 Integration Testing 19 Problem Communication 20 Product Backlog Grooming 21 Quality Management Prozess 23 Release Planning Meeting 24 Risk Analysis and Management 25 Scrum 27 Software Maintenance Process 28 Sprint Planning 29 Sprint Retrospective 31 Sprint Review 32 Team Kick-Off Meeting 34 Test Automation 35 Version 0.1 /

3 Test-Driven Design (TDD) 37 Unit Testing 39 Usability Process 40 Zero Bug Tolerance 41 Dokumente, Artefakte, Pläne 43 Architecture Documentation 44 Definition of Done 45 Definition of Ready 47 Iteration Notes 49 Linkable IDs 50 Product Backlog 51 Release Notes 53 Software Development Plan 54 Software Maintenance Plan 56 Sprint Development Plan = Sprint Backlog 57 Team Charter / Working Agreements 59 Test Documentation 61 User Story 62 Versioning System 64 Historie und Ausblick 66 Version 0.1 /

4 Vorwort Medizintechnik und die Entwicklung entsprechender Medizinprodukte befinden sich in einem regulierten Umfeld. Gesetze, Normen und Richtlinien geben mehr oder weniger harte Rahmenbedingungen vor, in deren Grenzen ein Medizinprodukt umgesetzt werden darf. Lange Entwicklungszeiten für Produktlebenszyklen sind wirtschaftlich heutzutage nicht mehr sinnvoll. Eine kurze Time-to-Market wird immer wichtiger, um den Marktbegleitern einen Schritt voraus zu sein und innovative Produktideen schnell als erster am Markt platzieren zu können. Der Kunde eines Medizinproduktes wird immer mündiger und entscheidet selbst über den Erfolg einzelner Produkte und Dienstleistungen. Dies erfordert bereits bei der Entstehung neuer Produktideen eine gewisse Nähe zum Anwender oder sogar die entwicklungsbegleitende Einbindung echter Anwender. In traditionellen Vorgehensweisen kann der Anwendungserfolg oft erst ganz am Ende des Prozesses ermittelt werden. Ein entsprechendes Reagieren auf Kunden und Anwender sowie deren wertvolles Feedback kann dann erst in einem nächsten Produkt, Projekt oder Release stattfinden und sich auswirken. Der Kunde bewertet ein Produkt nicht nur nach seinen Funktionen und der einfachen Handhabung, sondern auch nach seiner Qualität und Fehlerfreiheit. Dabei spielen oft schon Kleinigkeiten eine große Rolle, die zu einer negativen Bewertung eines Produktes führen können. In sozialen Netzwerken und Produktbewertungsportalen multiplizieren sich diese Effekte mittlerweile soweit, dass wir feststellen müssen: über Sieg oder Niederlage eines Produktes kann heute die breite Masse der Anwender entscheiden, unabhängig von Marketing- und Werbemaßnahmen. Der Einsatz agiler Management- und Entwicklungsmethoden liegt auf der Hand. Schnelle Entwicklungszyklen, Einbindung und Feedback echter Anwender, sowie höchste Qualitätsansprüche können durch agile Methoden nachhaltig realisiert werden. Des weiteren haben agile Methoden in den letzten Jahren ein breites Publikum erreicht und sind in aller Munde. Viele Versprechen, aber auch Missverständnisse kursieren bezüglich agiler Methoden: Scrum ist chaotisch. Jeder macht, was er will. Es wird nichts mehr dokumentiert. Scrum funktioniert nur bei kleinen Web-Projekten. Version 0.1 /

5 Agilität funktioniert nicht bei komplexen Medizintechnik-Projekten. Agile Methoden funktionieren in unserer Organisation nicht. Scrum ist die Lösung all unserer Probleme. Durch Agilität werden wir effizienter. Die IEC beschreibt einen konkreten Software-Life-Cycle-Prozess und muss eins-zueins umgesetzt werden. Wir müssen ein V-Modell einsetzen, um normkonform zu arbeiten. Die Kombination der agilen Welt und des regulierten Umfeldes der Medizinproduktentwicklung bereitet vielen Leuten Kopfzerbrechen und führt zu großer Unsicherheit. In dieser Unsicherheit lauert die Gefahr, agile Methoden in bestehende, normkonforme Prozesse zu pressen, ohne dass sich der Vorteil echter Agilität entfalten kann. Eine vereinfachte, beschränkte oder missverstandene Anwendung agiler Methoden kann dazu führen, dass das Scheitern eines Produktes oder Projektes eben diesen agilen Methoden zugerechnet wird: Agil haben wir schon probiert, das hat ja auch nicht funktioniert. Agil hat bei uns alles nur schlimmer gemacht. Scrum hat uns mit Problemen konfrontiert, die wir vorher gar nicht hatten. Können beide Welten effektiv nebeneinander existieren? Wie viel Agilität passt in die normativen Anforderungen? Welche agilen Praktiken eignen sich für einen regulierten Entwicklungsprozess? Die grundsätzliche Frage lautet: wie kann die Normkonformität agiler Prozesse und Methoden nachgewiesen werden? Dieses Dokument beschreibt den Prozess, mit dessen Hilfe die Anforderungen aus der IEC an den Software-Life-Cycle-Prozess zu konkreten agilen und traditionellen Praktiken transferiert wurden. Diese anwendbaren Praktiken werden im Detail beschrieben und können gesamtheitlich als reines Scrum betrachtet werden mit entsprechenden Erweiterungen, um die normativen Anforderungen an den Software-Life-Cycle abzubilden. Zukünftige Ausgaben dieses Dokumentes werden die Normen 14971, und e- benso einbinden und abgeleitete Praktiken beschreiben. Des weiteren ist die Einbindung von Praktiken geplant, welche einen agilen, FDA-konformen Entwicklungsprozess ermöglichen. Version 0.1 /

6 Das vorliegende Dokument beschreibt eine vollständige, IEC konforme Implementierung von Scrum als Projektmanagementmethode sowie agilen Entwicklungspraktiken aus dem Extreme Programming. Ich freue mich auf Fragen, Feedback und konstruktive Kritik der Leserschaft und bedanke mich vorab für das Interesse an der Thematik. Marc Bless Baden-Baden, Juni 2012 Version 0.1 /

7 Marc Bless Von der Norm zum Prozess: des Meta-Prozesses Um zu einem normkonformen Prozess zu gelangen, bin ich vorgegangen, wie im Folgenden beschrieben. Anforderungen an den Software-Life-Cycle-Prozess Zunächst habe ich die Struktur der IEC vollständig aufgebrochen. Aus den einzelnen Kapiteln, Sektionen und jedem darin enthaltenen Paragraphen habe ich die eigentlichen Anforderungen an einen Software-Life-Cycle-Prozess extrahiert. Abgeleitete Anforderungen: Der Prozess - Teil 1/2 IEC Kapitel & Sektionen Paragraphen Anforderungen Marc Bless Scrum und die IEC Wie soll das gehen? --- ScrumMed 2012, agile coach.de Die Struktur der Norm suggeriert einen sequentiellen Entwicklungsablauf, der einem agilen Ansatz im Wesen widerspricht. Gleichzeitig stecken in dieser Struktur viele redundante Anforderungen, die zu einem sequentiellen Ablauf eher orthogonalen Charakter haben, wie zum Beispiel das gesamte Thema Risikomanagement. agile coach.de Version 0.1 /

8 Aus diesem Grund ordnete ich die Anforderungen neuen Clustern zu, welche einzelne Entwicklungsthematiken inhaltlich abgeschlossen handhabbar machten. Eine für uns grundlegende Aussage der Norm lautet: agile Vorgehensweisen sind (erlaubt und) möglich. ( Jeder beliebige wasserfallartige, iterative oder evolutionäre Prozess kann verwendet werden. ) Dokumente und Prozesse Den Anforderungen in den Clustern wurden konkrete agile und klassische Praktiken und Artefakte zugeordnet. Die Zuordnungen einzelner Praktiken und Artefakte zu einzelnen Anforderungen habe ich so vollständig vorgenommen, dass die Gesamtmenge aller normativen Anforderungen vollständig erfüllt wird. Jede einzelne Zuordnung ist schriftlich begründet, um einen Nachweis der Anforderungserfüllung führen zu können. Das Ergebnis aller Praktiken und Artefakte mitsamt ihrer Begründungen findet sich im Hauptteil dieses Dokuments. Das wichtigste Prinzip für die Zuordnung von Praktiken und Artefakten ist Simplicity (Einfachheit) und bedeutet, die minimale, aber vollständige Befriedigung der normativen Anforderungen zu finden. Praktiken sind dabei im Wesentlichen Prozesse, Reviews, Meetings, Besprechungen und Workshops. Unter Artefakten verstehen wir sämtliche Dokumente, Ergebnisse, funktionierende Software, Pläne und en, welche im Entwicklungsverlauf entstehen und eine Rolle spielen. Nachweis der Normkonformität Der Nachweis der Normkonformität wird aus kopierrechtlichen Gründen nicht in diesem Dokument geführt. Da die Originalquellen und Anforderungen der Normen nicht bei den Zuordnungen der Praktiken und Artefakte beschrieben sind, mag es an manchen Stellen nicht offensichtlich sein, für welche Anforderung und aus welchem Grund eine bestimmte Praktik oder ein Artefakt Normkonformität herstellt. Der interessierte Leser darf sich gerne an den Autoren wenden, um mehr über das Thema Nachweis der Normkonformität zu erfahren. Grundsätzlich können zwei Anwendungsfälle unterschieden werden. Der Abgleich der normativen Anforderungen mit einem bestehenden (agilen oder klassischen) Life-Cycle-Prozess ist ein sehr aufwändiges, aber notwendiges Verfahren, um die Normkonformität des beste- Version 0.1 /

9 henden Prozesses nachzuweisen. Im Gegensatz dazu führt die Ableitung eines neuen, normkonformen Prozesses zu einer vollständigen Scrum-Umsetzung mit minimalem Tailoring. (Scrum steht hierbei nur für eine mögliche agile Referenzimplementierung, es können beliebige andere Vorgehensmodelle oder Prozessframeworks modelliert werden. Der in diesem Dokument vorgestellte Ansatz beschreibt eine vollständige Scrum-Implementierung.) Der Aufwand für diese Ableitung ist ebenfalls nicht unerheblich, wird jedoch durch die Gewissheit über die Normkonformität relativiert. Abgeleitete Anforderungen: Der Prozess - Teil 2/2 Anforderungen Dokumente Artefakte Prozesse Reviews Meetings Simplicity = Einfachheit: Minimale, aber vollständige Befriedigung der normativen Anforderungen Abgleich mit (bestehendem) Life-Cycle-Prozess Nachweis der Normkonformität Marc Bless Scrum und die IEC Wie soll das gehen? --- ScrumMed 2012, Abschließend lässt sich sagen: Scrum und die Norm IEC harmonieren perfekt miteinander, benötigen minimales Tailoring, widersprechen sich nicht und verfolgen ähnliche Zielsetzungen. Version 0.1 /

10 Überblick der Prozesse und Artefakte Das nachfolgende Diagramm zeigt den gesamten Überblick aller Prozesse und Artefakte, welche aus normativen und gewünschten agilen Gründen benötigt werden. Im folgenden Hauptteil dieses Dokumentes werden die einzelnen Praktiken und Artefakte im Detail beschrieben in jeweils eigenen Kapiteln. Die Struktur dieser einzelnen Kapitel ist folgendermaßen aufgebaut: - kurze Erklärung der Praktik oder des Artefaktes für das bessere Verständnis, welche Absicht dahintersteckt und welche Ergebnisse erwartet werden. - Liste der üblicherweise beteiligten Rollen für eine bessere Einschätzung, welche Rollen in einem bestehenden Unternehmenskontext für den Einsatz der Praktik oder des Artefaktes in Frage kommen. Die in diesem Dokument aufgeführten Rollen müssen nicht genau so übernommen werden, sie dienen eher dem Aufzeigen potentieller, sinnvoller Möglichkeiten. Version 0.1 /

11 - Liste von Büchern, Artikeln und Webseiten, welche sich mit der Praktik oder dem Artefakt detailliert auseinandersetzen. - Liste der direkt aus dem Normtext abgeleiteten Anforderungen an den Software-Life-Cycle-Prozess. Hinweis: aus Copyright-Gründen sind diese Listen mit Norminhalten nicht in diesem Dokument enthalten. - Durchzuführende Maßnahmen und Aktivitäten sowie Begründungen, weswegen die beschriebene Praktik oder das Artefakt zur Herstellung der Normkonformität benötigt wird. Version 0.1 /

12 Prozesse, Meetings, Reviews Version 0.1 /

13 Acceptance Testing Process Akzeptanz-Tests sind ein grundlegender Bestandteil von (agilen) Anforderungen. Durch ihre Einhaltung wird sichergestellt, dass (a) die gewünschten Anwenderbedürfnisse befriedigt werden, (b) die umgesetzte Funktionalität durch geprüfte Schnittstellen integriert werden kann und (c) die Anforderung als "fertig" (done) betrachtet werden kann. Product Owner Entwicklungs-Team Lisa Crispin - Agile Testing Mit Hilfe von definierten Akzeptanz-Tests wird sichergestellt, dass das erstellte Software- Produkt die Bedürfnisse der Anwender befriedigt und die Anforderungen korrekt umgesetzt wurden. Mit Hilfe von Akzeptanz-Tests wird sichergestellt, dass eine in Software umgesetzte Anforderung abgekapselt funktioniert und damit für eine Integration in andere Strukturen bereit ist. Durch Akzeptanztests wird sichergestellt, dass die entwickelte Software entsprechende Akzeptanzkriterien befriedigt. Akzeptanztests entsprechen Black-Box-Tests. Version 0.1 /

14 Clean Code / SOLID Principles Process Clean Code ist ein Wertesystem zur Professionalisierung der Software-Entwicklung. In ihm sind viele Good Practices und grundlegende Prinzipien enthalten, welche durch die Erfahrungen in den letzten Jahrzehnten als gültig und korrekt betrachtet werden können. Bekannter sind in erster Linie die fünf SOLID-Prinzipien: Single Responsibility Principle SRP Eine Klasse darf nur aus einem Grund geändert werden. Open Closed Principle OCP Eine Klasse muss offen sein für Erweiterungen, aber geschlossen gegen Modifikationen. Liskov Substitution Principle LSP Eine abgeleitete Klasse verhält sich immer so wie ihre Basisklasse. Interface Segregation Principle ISP Clients werden nicht mit Details versehen, die sie nicht benötigen. Dependency Inversion Principle DIP Klassen hoher Ebenen sollen nicht von Klassen niedriger Ebenen abhängig sein, sondern beide sollen von Interfaces/Abstraktionen abhängen. Interfaces sollen nicht von Details abhängen, sondern Details von Interfaces. Entwicklungs-Team Version 0.1 /

15 Robert C. Martin - Clean Code Durch die korrekte Anwendung objekt-orientierter Prinzipien wie "Separation of Concerns" und "Single Responsibility Principle" entstehen lose gekoppelte Architekturen. Durch die Anwendung objekt-orientierter Prinzipien wird die Aufteilung von Software-Einheiten in weitere Einheiten getrieben. Modernes Software-Engineering wird umgesetzt mit der Anwendung von Clean Code und SOLID-Prinzipien, TDD, Unit Tests, Design Patterns und vielen anderen Methoden, die hier nicht vollständig aufgeführt werden können. Version 0.1 /

16 Continuous Integration Process Kontinuierliche Integration beschreibt den Prozess des regelmäßigen, vollständigen Neubildens und Testens einer Anwendung. Jeder Entwickler checkt seine Änderungen früh und regelmäßig (mindestens täglich) in eine Versionsverwaltung ein. Von dort aus wird das gesamte System neu gebaut und automatisch getestet, damit die Entwickler schnellstmöglich auf vorhandene Fehler im System aufmerksam gemacht werden können. Entwicklungs-Team Konsequent angewandte Continuous Integration ist die Aktivität, durch welche eine frühzeitige Integration aller beteiligten Komponenten inklusive der dazugehörigen Integrationstests sichergestellt wird. Die einzelnen Software-Einheiten werden kontinuierlich integriert. Kontinuierliche Integration bedient sich eines Versionierungssystems, um jederzeit kleine Änderungen am System integrieren zu können. Kontinuierliche Integration benötigt eine funktionierende Test-Automatisierung, um ihren Nutzen entfalten zu können. Version 0.1 /

17 Early Integration / Early Testing Process Frühzeitige Integration und frühzeitiges Testen sind zum Einen Konzepte der kontinuierlichen Integration mit Test-Automation, zum Anderen können sie auch entwicklungsbegleitend manuell durchgeführt werden. Im Extremfall können Anforderungen vor ihrer eigentlichen Umsetzung bereits getestet werden (Test-First Development). Das darunterliegende Prinzip heißt "Schnelles Scheitern" (Fail Fast). Wir möchten so schnell wie möglich wissen, dass unser Vorhaben nicht erfolgreich sein kann. Entwicklungs-Team James Shore - The Art of Agile Development (Kapitel 13.2) Anforderungen können bereits vor ihrer endgültigen Umsetzung getestet und integriert werden. Frühe Integration bedient sich eines Versionierungssystems, um Änderungen am System sofort integrieren zu können. Version 0.1 /

18 Exploratory and Manual Testing Process Neben einer funktionierenden Test-Automation beschäftigen sich agile, entwicklungsbegleitende Tester mit explorativem und manuellem Testen des Systems. Entwicklungs-Team Lisa Crispin - Agile Testing Exploratives Testen entspricht Black-Box-Tests. Die benötigte Test Dokumentation wird mit den Ergebnissen der explorativen und manuellen Tests angereichert. Version 0.1 /

19 Integration Testing Process Integrations-Tests stellen sicher, dass sich die einzelnen Teile eines entwickelten System miteinander verbinden lassen und ein funktionierendes Ganzes entsteht. Entwicklungs-Team Lisa Crispin - Agile Testing Integrations-Tests entsprechen Black-Box-Tests bezüglich der Schnittstellen einzelner Systemkomponenten und White-Box-Tests bezüglich der System-Architektur. Die Software-Integration wird durch Integrationstests verifiziert. Die integrierten Software-Einheiten werden durch Integrationstests verifiziert. Durch Test- Automation kann eine Dokumentation der Testergebnisse erzeugt werden. Integrations- sowie System-Tests können mit Simulationen, Prototypen und Mocks durchgeführt werden. Version 0.1 /

20 Problem Communication Process Ein Problem-Kommunikationsprozeß wird dafür eingesetzt, Stakeholder, Anwender, Kunden und allgemein alle am Produkt interessierten Personen darüber zu informieren, welche Fehler und Probleme sich in dem Produkt befinden und behoben bzw. nicht länger benutzt werden sollten. Product Owner keine Probleme und deren Konsequenzen werden über einen "Problem Communication"-Prozeß an Anwender kommuniziert. Einzubindende Stakeholder werden durch einen "Problem Communication"-Prozeß über die Existenz eines Problems informiert. Version 0.1 /

21 Product Backlog Grooming Process Im Product Backlog Grooming Meeting wird von Product Owner und Team bewertet, welche Änderungen sich am Produkt durch Anforderungen (z.b. Änderungsanträge und User Stories) ergeben. Die Entscheidung darüber, welche Anforderungen umgesetzt werden sollen, liegt einzig und alleine beim Product Owner. Product Owner Entwicklungs-Team Scrum Master Im Product Backlog Grooming Meeting werden bestehende Anforderungen und User Stories im Product Backlog neu bewertet und aktualisiert. Der Product Owner läßt im Product Backlog Grooming Meeting neue und geänderte Anforderungen vom Team bewerten und erteilt deren Freigabe durch Aufnahme und Einsortierung in sein Product Backlog. Im Product Backlog Grooming Meeting werden neue und geänderte Anforderungen auf ihren Einfluß auf bestehende Produkte und Systeme untersucht. Version 0.1 /

22 Im Product Backlog Grooming Meeting durchlaufen neue und geänderte Anforderungen den Risikomanagement-Prozess, um neue Risiko-Maßnahmen abzuleiten. Im Product Backlog Grooming Meeting durchlaufen neue und geänderte Anforderungen den Risikomanagement-Prozess, um sie mit bestehenden Risiko-Maßnahmen abzugleichen. Im Product Backlog Grooming Meeting werden Fehler- und Problem-Berichte bewertet und ihr Einfluß auf die Sicherheit bestehender Produkte und Systeme festgestellt, um notwendige Anforderungsänderungen im Product Backlog abzuleiten. Im Product Backlog Grooming werden notwendige Änderungen am System diskutiert und für die Entwicklung freigegeben. Im Product Backlog Grooming werden Probleme und Fehler von bereits releaster Software besprochen. Im Product Backlog Grooming werden die Funktionalitäten und Performance-Anforderungen an einzusetzende SOUP-Komponenten definiert. Im Product Backlog Grooming werden Änderungen an der Software analysiert, bewertet und ins Product Backlog einsortiert. Damit durchlaufen Änderungen den gleichen Entwicklungsprozeß wie Anforderungen und User Stories. Im Backlog Grooming werden die Anforderungen an Hardware und Software identifiziert, welche durch den Einsatz von SOUP notwendig werden. Im Product Backlog Grooming wird das Product Backlog kontinuierlich überarbeitet und angepasst. Im Product Backlog Grooming werden User Stories erstellt, verfeinert, abgeschätzt, verworfen und in einzelne User Stories aufgesplittet. Version 0.1 /

23 Quality Management Prozess Process Ein zertifiziertes Qualitätsmanagementsystem (z.b. nach ISO 13485) für medizinische Produkte wird dafür genutzt, die Normkonformität für Medizinproduktentwicklungen nachzuweisen und damit deren Marktfreigabe zu erwirken. Qualitätsmanager Scrum Master ISO Ein Qualitäts-Management-Prozess ist definiert und wird eingesetzt. Version 0.1 /

24 Release Planning Meeting Process Im Release Planning wird regelmäßig darüber entschieden, welcher Inhalt/Scope in die Produktentwicklung einfließen soll und welche Zeiträume und Meilensteine sich daraus ergeben. Product Owner Entwicklungs-Team Im Release Planning findet die Vorbewertung und Priorisierung statt für Probleme und Fehler von bereits releaster Software. Das Release Planning unterscheidet nicht, ob ein Release aus neuen Anforderungen besteht oder aus Änderungen an einem bestehenden System. Im Release Planning wird festgelegt, ob ein Release als vollständiges System-Release erstellt wird oder als Patch zu einem bestehenden System-Release. Im Release Planning wird entschieden, welche Maßnahmen und Aktivitäten durchzuführen sind, um eine verläßliche Auslieferung der Software zu gewährleisten. Im Release Planning wird das Product Backlog initial erstellt bzw. in späteren Release Planning Meetings kontinuierlich überarbeitet und angepasst. Version 0.1 /

25 Risk Analysis and Management Process In einem Risiko-Management-Prozeß werden Gefährdungen für Menschen und Umwelt durch Gebrauch eines Medizinproduktes analysiert, bewertet, durch Maßnahmen reduziert und entsprechend kontrolliert. Der Risiko-Management-Prozeß findet während aller Entwicklungsaktivitäten und -phasen statt. Qualitätsmanager Product Owner Entwicklungs-Team Scrum Master ISO Im Sprint Planning Meeting wird sichergestellt, dass alle Maßnahmen aus der Risiko-Analyse einer in diesem Sprint geplanten Anforderung in das Product Backlog als Anforderung einfließen. Im Sprint Planning Meeting wird sichergestellt, dass alle Maßnahmen aus der Risiko-Analyse einer in diesem Sprint geplanten Anforderung in das Product Backlog als Anforderung einfließen. Version 0.1 /

26 Im Sprint Planning Meeting durchlaufen alle Anforderungen eine Risiko-Analyse, um notwendige Maßnahmen abzuleiten. In der Risiko-Analyse während des Sprint Planning Meetings werden alle Anforderungen auf möglichen Mißbrauch untersucht und entsprechende Maßnahmen abgeleitet. Notwendige Änderungen an der Software, die durch System-Tests erkannt werden, durchlaufen während des Sprint Plannings die notwendige Risikoanalyse. Im Sprint Planning Meeting werden Probleme und Fehler auf sicherheitsrelevante Aspekte mit Hilfe der Risikoanalyse untersucht. Die Sicherheitsklassifizierung wird im Sprint Planning für alle umzusetzenden Software-Einheiten überdacht und gegebenenfalls neu vergeben. Im Sprint Planning werden die Architektur und die Software-Einheiten der umzusetzenden Anforderungen definiert. Die identifizierten Software-Einheiten durchlaufen die Risiko-Analyse. Im Sprint Planning wird die Risiko-Analyse der umzusetzenden Architektur und ihrer Software-Einheiten durchgeführt. Im Sprint Planning werden für fehlerhaftes Verhalten der Software mögliche Ursachen in Hardware- und Software-Fehlern analysiert Im Sprint Planning werden User Stories daraufhin untersucht, ob sie zu einer Gefahrensituation beitragen können, die in der Risiko-Analyse enthalten ist. Im Sprint Planning werden die umzusetzenden Anforderungen und deren abgeleitete Software-Einheiten durch die Risiko-Analyse auf mögliche Gefährdungen hin untersucht. Im Sprint Planning werden Workflows und sequentielle Abfolgen von Events in der Software durch die Risiko-Analyse auf Gefahrensituationen untersucht. Im Sprint Planning werden die umzusetzenden Software-Einheiten durch die Risiko-Analyse auf Gefahrensituationen untersucht. Im Sprint Planning wird der zu erstellenden Software-Einheit eine Sicherheitsklassifizierung zugewiesen (A, B, C), welche weitere Details im Entwicklungsprozess bestimmt. Im Sprint Planning werden zu jeder Software-Einheit mit möglichen Gefahrensituationen entsprechende Maßnahmen identifiziert und festgehalten. Im Sprint Planning werden mögliche Ursachen für Fehlverhalten von SOUP durch die Risiko- Analyse identifiziert. Im Sprint Planning werden SOUPs und ihre bekannten Fehler/Abweichungen durch die Risiko-Analyse betrachtet. Risiko-Management wird in erster Linie im Sprint Planning durchgeführt. Risiko-Management wird im Sprint Planning Meeting durchgeführt. Im Sprint Planning wird jeder Anforderung und User Story (auf jeder Ebene) eine Sicherheitsklassifizierung zugeordnet durch die Anwendung der Risiko-Analyse. Version 0.1 /

27 Scrum Process Scrum ist ein Management-Framework für die empirische Prozeßkontrolle. Product Owner Entwicklungs-Team Scrum Master Ken Schwaber - Agiles Projektmanagement mit Scrum Roman Pichler - Scrum Scrum ist ein gültiges Prozeß-Framework für den Software-Life-Cycle. Version 0.1 /

28 Software Maintenance Process Process Der Software Maintenance-Prozess (Software Wartungsprozeß) beschreibt alle Aktivitäten, die für die Änderung von sich im Markt befindlichen Medizinprodukten notwendig sind. Dazu gehört das Einholen und Bewerten von Anwender-Feedback sowie ein installierter Fehlerbehebungsprozeß. Product Owner Entwicklungs-Team https://www.ibm.com/developerworks/mydeveloperworks/blogs/c914709e e f-8982fc416138/entry/march_10_2012_11_27_am8?lang=en Über den Software Maintenance Prozeß erfolgt das Einholen des Feedbacks zu releaster Software innerhalb der eigenen Organisation. Über den Software Maintenance Prozeß erfolgt das Einholen des Feedbacks zu releaster Software von tatsächlichen Anwendern. Version 0.1 /

29 Sprint Planning Process Im Sprint Planning Meeting einigen sich der Product Owner und das Team auf ein Sprint-Ziel und das dafür umzusetzende Sprint Backlog. Im zweiten Teil des Sprint Plannings werden vom Team konkrete Architektur- und Umsetzungsaufgaben identifiziert und geplant. Product Owner Entwicklungs-Team Scrum Master Im Sprint Planning Meeting wird vom Team festgestellt, ob sich Anforderungen im Product Backlog widersprechen. Im Sprint Planning Meeting wird sichergestellt, dass über die Anforderungen ein einheitliches Verständnis bei allen Beteiligten herrscht. Im Sprint Planning Meeting wird sichergestellt, dass zu jeder Anforderung Akzeptanz-Kriterien für die Integration in andere Strukturen erstellt werden. Im Sprint Planning Meeting werden bestehende Anforderungen und User Stories im Product Backlog neu bewertet und aktualisiert. Version 0.1 /

30 Spätestens im Sprint Planning Meeting werden Anforderungen auf ihre korrekte und vollständige Definition geprüft. Im Sprint Planning Meeting werden vom Team alle Tasks identifiziert, welche für die Umsetzung einer Änderung (erneut) durchgeführt werden müssen. Im Sprint Planning erfolgt die Planung der Integrations-Tests sowie der System-Tests. Im Sprint Planning finden die notwendigen Risiko-Analysen sowie die Umsetzungsplanung statt für Probleme und Fehler von bereits releaster Software. Im Sprint Planning werden die Fehler- und Problemberichte analysiert. Im Sprint Planning werden für benötigte SOUP-Komponenten die Funktionalitäten und Performance-Anforderungen festgelegt. Im Sprint Planning werden die umzusetzenden Anforderungen in eine Architektur überführt und diese wiederum in Software-Einheiten runtergebrochen. Im Sprint Planning werden die Architektur und die Schnittstellen der umzusetzenden Software-Einheiten sowie der einzubindenden externen Software-Einheiten festgelegt. Die grundlegenden Software-Strukturen und Architektur-Entscheidungen können im Sprint Planning getroffen werden. Im Sprint Planning werden Software-Einheiten, die eine Risiko-Maßnahme umsetzen, genauso behandelt wie alle anderen Anforderungen und befolgen den definierten Entwicklungsprozeß. Im Sprint Planning Meeting wird das Sprint Backlog bzw. der Sprint Development Plan festgelegt. Im Sprint Planning werden die Iteration Notes (Sprint Notizen) angefangen. Im Sprint Planning Meeting wird in der zweiten Phase (Sprint Planning 2) die Architektur der umzusetzenden Anforderungen besprochen, skizziert und festgehalten. Version 0.1 /

31 Sprint Retrospective Process In der Sprint Retrospektive hat das Team die Möglichkeit, Verbesserungsmaßnahmen für die eigenen Prozesse und Strukturen zu identifizieren und zu beschließen. Product Owner Entwicklungs-Team Scrum Master Norman Kerth - Project Retrospectives Esther Derby, Diana Larsen - Agile Retrospectives Der Team Charter und die Working Agreements können vom Team im Sprint Retrospective Meeting an veränderte Situationen und gegebene Notwendigkeiten angepasst werden. Die Definition-of-Ready kann vom Team im Sprint Retrospective Meeting an veränderte Situationen und gegebene Notwendigkeiten angepasst werden. Die Definition-of-Done kann vom Team im Sprint Retrospective Meeting an veränderte Situationen und gegebene Notwendigkeiten angepasst werden. Der Software Development Plan kann vom Team im Sprint Retrospective Meeting an veränderte Situationen und gegebene Notwendigkeiten angepasst werden. Version 0.1 /

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

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

Mehr

Agile Produktentwicklung in der Medizintechnik

Agile Produktentwicklung in der Medizintechnik Whitepaper für Top-Entscheider Agile Produktentwicklung in der Medizintechnik Agilität in der Produktentwicklung ist in aller Munde und in allen Branchen existieren eine Vielzahl von Firmen, die sich mit

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

Scrum und die IEC 62304

Scrum und die IEC 62304 agilecoach.de Marc Bless Scrum und die IEC 62304 Medizinische Software mit agilen Methoden normkonform entwickeln Leseprobe der Vollständigen Ausgabe Version 1.2 Juli 2013, Baden-Baden Vorwort zur Leseprobe

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

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

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

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

Marc Bless. Scrum. und die IEC 62304. Medizinische Software mit agilen Methoden normkonform entwickeln

Marc Bless. Scrum. und die IEC 62304. Medizinische Software mit agilen Methoden normkonform entwickeln Marc Bless Scrum und die IEC 62304 Medizinische Software mit agilen Methoden normkonform entwickeln Version 1.8 Januar 2014 agilecoach.de Marc Bless Scrum und die IEC 62304 Medizinische Software mit

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

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

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

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

Teststrategie festlegen und Teststufen aufeinander abstimmen

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

Mehr

Agile 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

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

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Andreas Armbrecht Siemens AG Darmstadt, 01. 02. Dezember 2009 Business Unit Rail Automation Systeme der Eisenbahnautomatisierung

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

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

Iterativ. Inkrementell

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

Mehr

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

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

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

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

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

AGILES QUALITÄTSMANAGEMENT

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

Mehr

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

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

AGILER TESTMANAGER EIN OXYMORON?

AGILER TESTMANAGER EIN OXYMORON? AGILR ANAGR IN OXYMORON? Kay.Grebenstein@saxsys.de AGILR ANAGR IN OXYMORON? Benötigen wir mit Scrum noch die Rolle estmanager? 1 AGILR ANAGR IN OXYMORON? Aufgaben SCRUM AUFGABN Strategische bene (Qualitätsmanager)

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

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

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

Mehr

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

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

Scrum. Eine Einführung

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

Mehr

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

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

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

Grob- und Detailplanung bei der Implementierung nutzen

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

Mehr

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

Ü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

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

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

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

Lean, Agile & Scrum. Josef Scherer. Sponsoren. Agilität Scrum Grundlagen Erfahrungsaustausch. 10:30 12:00, ETH Zürich, E6

Lean, Agile & Scrum. Josef Scherer. Sponsoren. Agilität Scrum Grundlagen Erfahrungsaustausch. 10:30 12:00, ETH Zürich, E6 Lean, Agile & Scrum Conference Sponsoren Josef Scherer Scrum für Einsteiger Agilität Scrum Grundlagen Erfahrungsaustausch 10:30 12:00, ETH Zürich, E6 Vorstellung Erfahrung fh mit Scrum? Agile Kultur Agiles

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

Scrum in regulierten Branchen - Dürfen wir das überhaupt? GPM Friedrichshafen, 21.09.2012 Frank Lange Agilefokus.de

Scrum in regulierten Branchen - Dürfen wir das überhaupt? GPM Friedrichshafen, 21.09.2012 Frank Lange Agilefokus.de Scrum in regulierten Branchen - Dürfen wir das überhaupt? GPM Friedrichshafen, 21.09.2012 Frank Lange Agilefokus.de Abstract Verschiedene Studien zeigen regelmäßig jedes Jahr aufs neue, dass ein Großteil

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

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

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

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

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

Mehr

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

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

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

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

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

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

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

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

End-to-End Agility Sind Sie schon agil genug? Mag. Christoph Leithner c.leithner@celix.at

End-to-End Agility Sind Sie schon agil genug? Mag. Christoph Leithner c.leithner@celix.at End-to-End Agility Sind Sie schon agil genug? Mag. Christoph Leithner c.leithner@celix.at www.celix.at September 2015 celix Solutions GmbH Spezialist für Team Collaboration und IT Prozess Management Agile

Mehr

Projektmanagement Vorlesung 14/ 15: Wiederholung ausgewählter Themen zur Klausurvorbereitung. Prof. Adrian Müller, PMP, PSM-1, CSM FH Kaiserslautern

Projektmanagement Vorlesung 14/ 15: Wiederholung ausgewählter Themen zur Klausurvorbereitung. Prof. Adrian Müller, PMP, PSM-1, CSM FH Kaiserslautern Projektmanagement Vorlesung 14/ 15: Wiederholung ausgewählter Themen zur Klausurvorbereitung Prof. Adrian Müller, PMP, PSM-1, CSM FH Kaiserslautern phone: +49 631/3724-5329 http://www.hs-kl.de/~amueller

Mehr

Scriptbasierte Testautomatisierung. für Web-Anwendungen

Scriptbasierte Testautomatisierung. für Web-Anwendungen Scriptbasierte Testautomatisierung für Web-Anwendungen Scriptbasierte Testautomatisierung + Web-Anwendung: Erstes Einsatzgebiet, Ergebnisse aber allgemein übertragbar + Test aus Benutzersicht - Nicht Unit-Test,

Mehr

Machbar? Machbar! 07.10.2010

Machbar? Machbar! 07.10.2010 TANNER AG 2010 TANNER AG Kemptener Straße 99 D-88131 Lindau (B) Telefon +49 8382 272-0 Fax +49 8382 272-900 www.tanner.de info@tanner.de Agile Softwareentwicklung im regulativen Umfeld. Machbar? Machbar!

Mehr

Wahlpflichtmodul Projekt I Softwareprojekt I

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

Mehr

Checkliste für Scrum-Meetings

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

Mehr

Agile BI Kickstart. Beschreibung des Workshops. Workshopbeschreibung

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

Mehr

Susanne Muehlbauer 29. November 2011

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

Mehr

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

Medizinprodukte mit Risikoanalyse nach ISO 14971

Medizinprodukte mit Risikoanalyse nach ISO 14971 Whitepaper Medizinprodukte mit Risikoanalyse nach ISO 14971 www.infoteam.de Medizinprodukte mit Risikoanalyse nach ISO 14971 In unserer zunehmend vernetzten Welt steigt auch die durch Software realisierte

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

READY-STEADY-DONE! Der Product Owner are you READY for agile?!

READY-STEADY-DONE! Der Product Owner are you READY for agile?! READY-STEADY-DONE! Der Product Owner are you READY for agile?! Susanne Mühlbauer HOOD GmbH Büro München Keltenring 7 82041 Oberhaching Germany Tel: 0049 89 4512 53 0 www.hood-group.com -1- Neue Ideen sind

Mehr

Software Engineering (SE) 2) Phasenübergreifende Verfahren

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

Mehr

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

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

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

Mehr

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

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

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

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

Mehr

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

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

- 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

Requirements Engineering für die agile Softwareentwicklung

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

Mehr

Gutes Benehmen Akzeptanztest-getriebene Software-Entwicklung in einem Web-Projekt

Gutes Benehmen Akzeptanztest-getriebene Software-Entwicklung in einem Web-Projekt Gutes Benehmen Akzeptanztest-getriebene Software-Entwicklung in einem Web-Projekt 1 David Tanzer Bakk. Techn. (JKU Linz) Certified Scrum Master Freiberufler seit 2006 http://davidtanzer.net business@davidtanzer.net

Mehr

Projektplan. Software Engineering Projekt. November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1

Projektplan. Software Engineering Projekt. November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1 Projektplan Software Engineering Projekt November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1 Der Projektplan Grundlage der gemeinsamen Arbeit innerhalb des Teams und mit

Mehr

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

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

Mehr

Leuchtfeuer. Hinter den Kulissen der Scrum Transformierung der Allianz Deutschland

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

Mehr

It s all about shipping software!

It s all about shipping software! 1 Shipping Software Raiffeisen Bausparkasse V-ARC, 21.12.2011 Gerhard H. Leonhartsberger It s all about shipping software! Seite 2 2 How fast do you ship quality software? Seite 3 Software Entwicklung

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

Inhaltsverzeichnis. Ralf Wirdemann. Scrum mit User Stories ISBN: 978-3-446-42660-3. Weitere Informationen oder Bestellungen unter

Inhaltsverzeichnis. Ralf Wirdemann. Scrum mit User Stories ISBN: 978-3-446-42660-3. Weitere Informationen oder Bestellungen unter Ralf Wirdemann Scrum mit User Stories ISBN: 978-3-446-42660-3 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-42660-3 sowie im Buchhandel. Carl Hanser Verlag, München 1 Einführung.....................................

Mehr

Die Welt der SW-Qualität Ein Streifzug in 30 Minuten! Johannes Bergsmann Eigentümer

Die Welt der SW-Qualität Ein Streifzug in 30 Minuten! Johannes Bergsmann Eigentümer Die Welt der SW-Qualität Ein Streifzug in 30 Minuten! Johannes Bergsmann Eigentümer Inhalt Top Themen Requirements Testen Testautomatisierung Change-Management Risiko-Management Agile Methoden Traceability

Mehr

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

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

Mehr

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

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

Mehr

Unsere Kunden erzählen keine Geschichten. Ursula Meseberg microtool GmbH Berlin

Unsere Kunden erzählen keine Geschichten. Ursula Meseberg microtool GmbH Berlin Unsere Kunden erzählen keine Geschichten Ursula Meseberg microtool GmbH Berlin Unsere Kunden erzählen keine Geschichten Ein modellbasierter Prozess für die Anforderungsanalyse im Vorfeld agiler Produktentwicklung

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

Scrum und professionelles Requirements Engineering

Scrum und professionelles Requirements Engineering Scrum und professionelles Requirements Engineering Dr. Martin Mandischer (Prokurist, Professional Scrum Trainer) Jens Trompeter (Vorstand, Certified Scrum Professional) Gründung im Jahr 2003 Mehr als 160

Mehr

Agile Software-Entwicklung: Überblick

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

Mehr

Scrum mit User Stories

Scrum mit User Stories Ralf Wirdemann Scrum mit User Stories HANSER Inhaltsverzeichnis 1 Einführung 1 1.1 Warum dieses Buch? 2 1.2 Struktur und Aufbau 3 1.3 Dankeschön 5 1.4 Feedback 5 2 Beispiel: Scrumcoaches.com 7 2.1 Das

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