Lean Architecture 2012

Größe: px
Ab Seite anzeigen:

Download "Lean Architecture 2012"

Transkript

1 Lean 2012 Architecture Lean Architecture oder auch Schlanke Architektur ist ein Lösungsansatz, der die Aufgabe adressiert, das richtige Maß an Architektur zu finden und die richtigen Elemente in die Architekturplanung einzubeziehen.

2 Inhaltsverzeichnis 1 Abstract Begriffe Architektur Lean Lean Architecture Vorgehensmethoden in der Softwareentwicklung Plangetriebene Methoden am Beispiel Wasserfall Die Vorgehensweise Wasserfallmodell und Architektur Auswirkung auf die Architektur Agile Methoden am Beispiel Scrum Die Vorgehensweise Scrum und Architektur Auswirkung auf die Architektur Artefakte und Regeln Ansätze Angemessenheit der Geschäftsprozesse Refactoring Evolutionäres Design Divide, Conquer and Integrate Inkrementelles Design Rapid Prototyping Tools haben kaum Auswirkung auf Qualität der Architektur Architektur-Dokumentation YAGNI vs. BFUD Minimale Transaktionskosten Fazit Wie kann Lean Architecture erreicht werden Quellen Forschung und Lehre leben vom Gedankenaustausch, dabei helfen klare Vereinbarungen

3 Tabellenverzeichnis Tabelle 1: Die 14 Lean Prinzipien... 7 Tabelle 2: Die 14 Lean Prinzipien im Kontext Architektur Tabelle 3: Artefakte und Regeln je Vorgehensmethode Tabelle 4: Lean Prinzipien in plangetriebenen und agilen Vorgehensmethoden Abbildungsverzeichnis Abbildung 1: Phasenübergänge im Wasserfallmodell Abbildung 2: Wie häufig werden Features eines Systems durchschnittlich genutzt [Standish Group 1994] Abbildung 3: Koevolutionsmodell des Designs nach Maher, Poon und Boulanger von 1996 [BROOKS11, S. 79] Abbildung 4: Kosten der Softwareentwicklung [nach Lui 2008] Abbildung 5: Gegenüberstellung von YAGNI und BUFD (siehe [COPLIEN11]) Abbildung 6: Erweiterung der Vorgehensmodelle hin zu Lean Prinzipien

4 1 Abstract In der Ära der plangetriebenen Methoden befassten sich Softwarearchitekten mit langwierigem Big Front-Up Design. Dessen Ergebnisse neigten dazu, schon bei kleinen Umweltveränderungen oder gar Design-Fehlern auseinanderzufallen. Was verstärkend hinzukommt, ist, dass die Ära der plangetriebenen Methoden noch lange nicht vorbei ist. In der agilen Welt wird Architekturplanung häufig gar nicht in Betracht bezogen. Hier scheint der Fokus einzig auf schnellem Geschäftserfolg zu liegen. Kurzfristig funktioniert dies zumeist, auf lange Sicht wirkt sich die Vernachlässigung der Architektur eines Softwaresystems eher nachteilig aus. Meine These lautet, das, wenn weder Big Front-Up Design noch Vernachlässigung von Architekturplanung funktionieren, ein Lösungsweg in einer Mischung zwischen plangetriebenen und agilen Vorgehensmethoden liegen könnte. Lean Architecture oder auch Schlanke Architektur ist solch ein Lösungsansatz, der die Aufgabe adressiert, das richtige Maß an Architektur zu finden und die richtigen Elemente in die Architekturplanung einzubeziehen. 4

5 2 Begriffe In den folgenden Abschnitten sollen grundlegende Begriffe bekannt gemacht werden. 2.1 Architektur Der Architekturbegriff ist für IT-Systeme nicht eindeutig definiert. Grundsätzlich werden hier unter Architektur die Fundamente und tragenden Säulen eines Software-Systems verstanden. Sie beschreibt die grundlegenden Bestandteile eines Systems und deren Funktion die Beziehungen (Schnittstellen) dieser Bestandteile untereinander die Umwelt des Systems, also z.b. seine Partnersysteme die Beziehungen (Schnittstellen) zwischen System und Umwelt Die Architektur liefert darüber hinaus einen Überblick über die Komplexität eines Systems. Implementierungsdetails des Systems gehören nicht zu dessen Architektur (siehe [Vogel08, S. 8ff]). Architektur liegt nicht auf der Straße, sie wird entweder mühsam aus Anforderungen und Rahmenbedingungen gewonnen oder unter Nutzung von Erfahrungen aus vergangenen Projekten, z.b. unter Einbeziehung von Entwurfsmustern oder Referenzarchitekturen, hergeleitet. Dabei ist der Anspruch, nicht einfach eine Architektur zu entwerfen, sondern vielmehr eine gute und angemessene Architektur, die den Anforderungen und Rahmenbedingungen gerecht wird. Also entwickeln wir eine gute Architektur. Laut James Shore zeichnet sich gute Architektur dadurch aus, leicht verständlich zu sein und die sie beschreibende Software mit vertretbarem Aufwand erstell- und anpassbar zu machen, während die Software ein angemessenes Laufzeitverhalten zeigt (siehe [SHORE06]). Das die leichte Änderbarkeit einer Software eine wichtige Eigenschaft ist, die von ihrer Architektur unterstützt werden muss, zeigt sich daran, dass die Kosten einer Software durchschnittlich zwischen 40 und 90 Prozent während ihrer Wartungsphase entstehen, also wenn die Software bereits produktiv eingesetzt wird (POPPENDIEC07, S. 20). Wodurch unterstützt eine Architektur eine leichte Änderbarkeit der Software, die sie beschreibt? Die Antwort auf diese Frage folgt später. 2.2 Lean Lean bzw. Lean Management ist ein System zur Optimierung von Wertschöpfungsketten aus Sicht von Kunden und Anbietern, wobei überflüssige Tätigkeiten vermieden werden. Ergebnis der Optimierung sind effiziente Prozesse, die flexibel auf Veränderung reagieren können. Lean Management hat seinen Ursprung bei Toyota, bzw. genauer im Toyota Produktionssystem (TPS), das seinen größten Entwicklungsschub während des Ölschocks 1973 hatte, als Toyota praktisch alle Einzelteile und Rohstoffe für seine Produktion importieren musste (siehe LIKER04, S. 15ff). Zu den Zielen von Lean zählen beispielsweise beste Qualität, geringste Kosten, nachhaltig kurze Durchlaufzeiten und größter Kundennutzen. Dabei basiert Lean auf zwei Grundpfeilern: 5

6 Wertschätzung für die am Prozess beteiligten Menschen und der Wille, den Prozess ständig zu verbessern. Ohne kompetente Mitarbeiter, die gern ihrer Tätigkeit nachgehen, ist die Einführung von Lean oder das Ausleben der Prinzipien von Lean nicht denkbar. Um einen Prozess verbessern zu können, muss ich mich damit auseinandersetzen und das tue ich lieber, wenn ich dafür von meinen Kollegen Wertschätzung erhalte und dafür aber auch meinen Kollegen dieselbe Wertschätzung zu teil werden lasse. Dabei darf es keine Rolle spielen, ob ich Manager oder Architekt oder Entwickler bin. Kontinuierliche Prozessverbesserung kann auf vielfältige Art und Weise durchgeführt werden. Bei Lean wird beispielsweise aktives Wissensmanagement betrieben und mit den Mitarbeitern Retrospektiven durchgeführt, deren Ergebnisse wiederum in die Prozessverbesserung einfließen. Bei Problemen wird beispielsweise Root-Cause-Analysis 1 durchgeführt. Prozessverbesserung im Kontext Lean meint hier Kaizen 2, nicht den Kontinuierlichen Verbesserungsprozess (KVP) 3 in deutschen Unternehmen und Behörden. Eine wichtige Grundlage dafür, dass Lean bzw. Lean Management in einer Organisation funktioniert, ist die langfristige, tatkräftige Unterstützung des Lean Ansatzes durch das Management der Organisation. Ähnlich den Prinzipien hinter dem Agilen Manifest gibt es Lean Prinzipien, mit deren Hilfe die Ziele von Lean erreicht werden können. Im Folgenden werden diese 14 Prinzipien kurz beschrieben. Weiterführende Informationen können [LARMAN08, S. 65ff] entnommen werden. Lean Prinzip Workflow visualisieren Einsatz der richtigen Werkzeuge Gleichmäßige Aufgabenverteilung Pull statt Push Interpretation Bilde den durchgeführten Prozess grafisch so einfach wie möglich ab. Stelle ihn so dar, wie er tatsächlich gelebt wird und nicht, wie er eigentlich sein sollte. Das ist eine der Regeln in Kanban (siehe [ANDERSON11, S. 44f]). Die Software-Werkzeuge, die den Prozess und die Mitarbeiter bei ihrer Arbeit unterstützen, sollten auch eingesetzt werden. Erinnert mich an den Joel-Test in [SPOLSKI07]: 9. Do you use the best software money can buy? Ziel dieses Prinzips ist es, ein Arbeitstempo zu finden, das von den Mitarbeitern über einen langen Zeitraum eingehalten werden kann, ohne die Mitarbeiter zu überlasten, aber auch ohne sie zu unterfordern. Korreliert mit dem Prinzip Pull statt Push. Anstatt von Managementseite vorzugeben, wie viel einer Aufgabe bis zu einem Termin fertiggestellt sein muss (Push), werden die am Prozess Beteiligten dazu angehalten, selbst festzulegen, wie viel bis zu diesem Termin geschafft werden kann (Pull). Eine implizite Konsequenz dieses Vorgehens ist eine nachhaltige Geschwindigkeit im Prozess. Zum besseren Verständnis sind an dieser Stelle Ausflüge in die Warteschlangentheorie und zu Kanban empfohlen. Der Einfachheit halber verweise ich auf [Goldratt90] und [ANDERSON11]. In Pull statt Push steckt implizit noch ein weiteres Paradigma: Entscheide so spät wie möglich. Plane und führe Aufgaben genau zur richtigen Zeit 4 1 Mehr Informationen zur Root-Cause-Analysis siehe [BELLINGER04] 2 Siehe [BRUNNER08, S. 11ff] 3 KVP stellt durch seine Schwerfälligkeit eher einen Kontinuierlichen Verbesserungs-Verhinderungsprozess dar. 4 Just in Time 6

7 Lean Prinzip Wertflussoptimierung Entscheidungen mit langfristigem Fokus treffen Probleme zuerst lösen Menschen und Teams weiterentwickeln Entscheider aus dem Team Selbst kümmern Entscheidungen im Konsens treffen Lean weitertragen Kontinuierliche Verbesserung Regeln gemeinsam definieren Tabelle 1: Die 14 Lean Prinzipien Interpretation aus und nicht deutlich vorher, da sich Anforderungen und Rahmenbedingungen bis dahin geändert haben können, deine Arbeit wertlos wird und es dadurch zu Verschwendung von Ressourcen kommt. Hier geht es darum, den Kundenauftrag zum frühesten möglichen Zeitpunkt zu erfüllen, zum einen, um den Kunden zufrieden zu stellen und nicht unwichtiger, zum frühesten möglichen Zeitpunkt Feedback vom Kunden zu erhalten und dieses Feedback in den Wertschöpfungsprozess einfließen zu lassen. Auf den ersten Blick kollidiert dieses Paradigma mit Wertflussoptimierung und Pull statt Push. Es gilt, für Entscheidungen nicht nur das aktuell relevante Problem zu beachten, sondern mindestens die bis jetzt absehbaren künftigen Aufgaben in den Entscheidungsprozess mit einzubeziehen. Kommt es zu Fehlern oder Problemen, soll nach der Ursache gesucht werden. Erst dann darf mit der eigentlichen Aufgabe fortgefahren werden. Ist ein Team der Ansicht, dass eine bestimmte Vorgehensweise den Prozess besser unterstützt als die bisher genutzte Methode, soll das Team dazu bevollmächtigt werden, die Vorgehensweise auszuprobieren und ausreichend Unterstützung bekommen, sein Ziel zu erreichen. Im Idealfall tritt die Prozessverbesserung tatsächlich ein. Ist die Vorgehensweise wider Erwarten nicht zielführend, hat das Team dennoch wichtige Erfahrungen gesammelt. Idealerweise werden Entscheider aus den eigenen Mitarbeitern rekrutiert. Sie kennen das Aufgabenumfeld und sind durch ihre konkrete Erfahrung eher in der Lage, die richtigen Entscheidungen zu treffen. Dieses Prinzip korreliert mit den Prinzipien Entscheider aus dem Team, Probleme zuerst lösen und Menschen und Teams weiterentwickeln. Das Team muss bevollmächtigt sein, sich eigenständig um Probleme und um Prozessverbesserung zu kümmern. Ein bevollmächtigtes Team trifft Entscheidungen im Idealfall im Konsens. Die anschließende Umsetzung dieser Entscheidung kann dann effektiver/schneller erfolgen, da alle Teammitglieder hinter der Entscheidung stehen. Dort wo Lean erfolgreich ist, sollte es an die Umgebung weitergegeben werden. Setzen Partner und Kunden Lean ein? Bringt ihnen Lean Vorteile bei der eigenen Prozessgestaltung? Es reicht uns nicht, zu verstehen, warum Dinge sind wie sie sind. Wir gehen weiter: Müssen die Dinge sein, wie sie sind? Gibt es bessere Lösungen, die die anderen Prinzipien von Lean besser unterstützen? Suche im Fehlerfall den Grund des Fehlers, nicht den Schuldigen. Das Prinzip meint die Festlegung von Regeln mit denen der Prozess eingehalten bzw. die Prozesserfüllung gemessen werden kann. Die am Prozess beteiligten Mitarbeiter stimmen die Regeln ab (siehe Entscheidungen im Konsens treffen). An Lean Interessierte seien auf [LARMAN08, S. 44ff] verwiesen. Hier ist mit dem Lean Thinking House das Modell hinter Lean, Lean Management und Lean Thinking trefflich beschrieben. Wem dies noch nicht reicht, kann sich die empfohlener Literatur in [LARMAN08, S. 90f] zu Gemüte führen. 7

8 Die Prinzipien hinter dem Agilen Manifest weisen mehrere Überschneidungen mit den Prinzipien von Lean auf. Eine Folge davon ist, dass Lean bzw. Lean Management bereits auf die eine oder andere Art und Weise in den verschiedenen Agilen Methoden integriert ist. 2.3 Lean Architecture Wenn ich versuche, ein Problem auf die einfachste mögliche Art und Weise zu lösen, ist die Lösung bezogen auf das konkrete Problem optimal, auf der anderen Seite aber bei sich veränderten Anforderungen schwer anpassbar. Wer einmal die Erfahrung gemacht hat und Anforderungen, die ursprünglich nicht vorgesehen waren, in ein System zu planen oder umzusetzen, weiß, wie aufwändig dies sein kann. Wer diese Erfahrung mehr als einmal gemacht hat, lernt recht schnell, seine Software so zu entwerfen und zu bauen, dass sie für ungeplante Änderungen offen ist. Diese Änderbarkeit kommt allerdings nicht kostenlos ins System. Hooks bieten eine Möglichkeit, einen Softwareentwurf offen für Änderungen zu gestalten. Dabei schätzt der Architekt oder der Entwickler die Wahrscheinlichkeit von Änderungen innerhalb einer Komponente im Voraus ab und sieht dafür Haken vor, also leere Methoden mit vorgegebenen Rückgabewerten und Parametern, in die Funktionalität bei Bedarf integriert werden kann, ohne den Rest des Entwurfs zu verändern. Nun können wir nur schwer vorhersagen, an welchen Punkten eines Entwurfs künftig Änderungen auftreten könnten, also werden Hooks an beliebig vielen Stellen vorgesehen. Der Nachteil dieses Ansatzes ist eine Architektur, die komplexer ist, als die aktuellen Anforderungen verlangen würden. Die Kunst ist, den Mittelweg zwischen Planung bisher nicht vorgesehener Änderungen und starren, unflexiblen Systemen zu finden. In Abschnitt 2.2 wurden die 14 Prinzipien von Lean kurz beschrieben. Wir versuchen, diese Prinzipien in einen Kontext mit Softwarearchitektur zu bringen und so eine Definition für Lean Architecture zu finden. Lean Prinzip Workflow visualisieren Einsatz der richtigen Werkzeuge Gleichmäßige Aufgabenverteilung Lean Prinzip auf Softwarearchitektur angewendet Es existiert eine Reihe von Architekturmanagement- Frameworks im Kontext von Enterprise Architektur, die einen Prozess vorgeben. In Softwareprojekten wird in der Regel nach einem Vorgehensmodell verfahren, das den Prozess vorgibt. Der Architekturentwurf ist häufig in diesen Prozess eingebettet und mit sehr wenigen eigenen Regeln ausgestattet. Welche Werkzeuge stehen zur Unterstützung eines Architekturentwurfs zur Verfügung? Aus meiner Sicht gibt es kein Werkzeug für den Architekturentwurf, dass gegenüber anderen Tools herausragt, also unbedingt eingesetzt werden muss. Wenn Toolunterstützung zur Verfügung steht, sollte sie auch genutzt werden. Wenn allerdings Tools zum Selbstzweck eingesetzt werden, leidet die Architektur in der Regel darunter. Korreliert mit dem Prinzip Pull statt Push. Wenn der sich in Arbeit befindliche Architekturentwurf andere Teammitglieder behindert, weil er bezogen auf ein konkretes Problem noch nicht fertig ist, müssen die Teammitglieder beim 8

9 Lean Prinzip Pull statt Push Wertflussoptimierung Entscheidungen mit langfristigem Fokus treffen Probleme zuerst lösen Menschen und Teams weiterentwickeln Lean Prinzip auf Softwarearchitektur angewendet Entwurf unterstützen. Prinzipiell steckt in jedem Entwickler ein Architekt. Alternativ entsteht bei den Architekten Überlastung und die Qualität des Entwurfs lässt zu wünschen übrig. Ich beschreibe die Architektur nicht vollständig im Voraus, sondern kümmere mich nur um den Teil, der für mein aktuelles Problem erforderlich ist. Sinnvollerweise betrachte ich auch die in der nahen Zukunft geplanten Anforderungen und versuche, sie bei der Lösung meines aktuellen Problems zu berücksichtigen. Warum ist ein vollständiger Entwurf nicht sinnvoller? Unter Umständen ist mein Entwurf veraltet, wenn ich endlich an den kritischen Stellen ankomme. Bereits geleisteter Aufwand wäre verschwendet und das ist bei Lean Management verpönt. Eine Softwareauslieferung an den Kunden erfolgt, sobald sie für ihn nutzbar ist und nicht erst, wenn sie vollständig fertig ist. Der Kunde hat so Gelegenheit, die Software zu nutzen bzw. zu prüfen und mir Feedback zu geben. Als Konsequenz daraus kann ich sein Feedback in die Architektur des Systems einfließen lassen und bei der Weiterentwicklung des Systems berücksichtigen. Im Kontext Architektur ist das Feedback von größerer Relevanz als die frühzeitige Auslieferung der Software an den Kunden. Wichtig ist hier das iterative Vorgehen das Feedback muss regelmäßig kommen, also muss regelmäßig geliefert werden. Dieses Prinzip kommt dem Bedarf nach Architekturplanung sehr entgegen. Es reicht nicht aus, Architekturentscheidungen für das aktuelle Problem zu treffen. Sinnvollerweise werden die Probleme, die in der nahen Zukunft bearbeitet werden sollen, in den Planungsprozess einbezogen (siehe Pull statt Push). Treten Fehler in der Architektur auf, muss der tiefere Grund gesucht werden. Ein im Kontext Lean empfohlenes Mittel ist die Root-Cause-Analyse. Frage bis zu fünf Mal, Warum ein Problem besteht, um dem eigentlichen Problem auf den Grund zu gehen. 1. Warum trägt die Architektur nicht? Weil sie den neuen Anforderungen des Kunden nicht mehr gerecht wird. 2. Warum wird die Architektur den neuen Anforderungen des Kunden nicht mehr gerecht? Weil seine neuen Anforderungen eine Services bedingen und diese mit der aktuellen Architektur nicht abgebildet werden können. 3. Warum kann die Architektur keine Services abbilden? Weil die Architektur bisher auf Client-Server basiert hat und dort keine Services vorgesehen sind. Ach so! Den Architekten wird wie den anderen Teammitgliedern auch, Freiraum eingeräumt, Methoden, Frameworks, Muster 9

10 Lean Prinzip Entscheider aus dem Team Selbst kümmern Entscheidungen im Konsens treffen Lean weitertragen Kontinuierliche Verbesserung Regeln gemeinsam definieren Tabelle 2: Die 14 Lean Prinzipien im Kontext Architektur Lean Prinzip auf Softwarearchitektur angewendet daraufhin zu untersuchen, ob sie für die Architektur eines Systems eine Verbesserung darstellen. Ist die Evaluierung erfolgreich, profitiert das gesamte Team. Idealerweise sind die Architekten die erfahrensten Mitarbeiter der jeweiligen Problemdomäne. Durch ihr tiefes Wissen sind sie in der Lage, konkrete Probleme leichter zu erfassen und zu lösen als domänenfremde Kollegen. Der Ansatz birgt natürlich auch Probleme; je nach Situation kann domänenfremde Erfahrung ebenfalls von Vorteil sein. Genau wie jedes andere Teammitglied gehen Architekten aktiv auf Probleme und Herausforderungen zu. Geschieht dies nicht, besteht die Gefahr, dass die Architektur technische Schulden aufhäuft und unflexibel wird. Konsens in Bezug auf die Architektur erreiche ich als Architekt, wenn ich meine Entwicklerkollegen als Kunden verstehe und die Architektur das Produkt ist, mit dem sie arbeiten wollen / müssen. Ich hole Feedback ein und lasse dieses Feedback, wo es möglich und sinnvoll ist, in die Architektur einfließen. Wenn die Lean Prinzipien im Kontext Softwarearchitektur in meinem Projekt bzw. für mein Produkt funktionieren, können sie auch in Nachbarprojekten funktionieren. Architekten neigen ohnehin dazu, sich mit Kollegen auszutauschen. Ich habe eine Architektur vorliegen und hinterfrage sie immer wieder, um sie zu optimieren bzw. an geänderte Bedingungen anzupassen. Im Kontext Architektur kann dies bedeuten, dass Architekten und Entwickler vereinbaren, welche Artefakte in welcher Detailtiefe von den Architekten zur Verfügung gestellt werden sollen, damit Architektur für die Entwickler greifbar wird. Eine aus meiner Sicht naheliegende Annahme ist, dass aus dem Maß der Anwendbarkeit bzw. Anwendung der Lean Prinzipien auf die mit der Erstellung und Pflege einer Softwarearchitektur verbundenen Tätigkeiten und Regeln ableitbar ist, ob in einem konkreten Projekt eine Lean Architecture vorliegt bzw. realisierbar ist. 10

11 3 Vorgehensmethoden in der Softwareentwicklung Lean Architecture 2012 In der heutigen Welt der Softwareentwicklung können wir grundsätzlich zwei Arten von Vorgehensmethoden 5 beobachten: plangetriebene und agile Methoden. Mischformen beider Methoden sind, abgesehen von der Anwendung von Extreme Programming-Praktiken in plangetriebenen Vorgehensmethoden, eher ungebräuchlich. 6 Plangetriebene Methoden zeichnen sich durch abgeschlossene, aufeinanderfolgende Projektphasen aus, in denen jeweils bestimmte Prozesse eingehalten, Artefakte erstellt und Regeln erfüllt sein müssen, bevor die nächste Phase begonnen werden kann. Zu den klassischen, plangetriebenen Methoden zählen beispielsweise Wasserfallmethode, weiterführende Informationen siehe [ROYCE87] V-Modell XT, siehe [VMODEL10] und Rational Unified Process (RUP), siehe [RUP11] Agile Methoden zeichnen sich durch zeit- oder aufgabengesteuertes, iterativ-inkrementelles Vorgehen aus. In ihrem Mittelpunkt stehen Personen und Kommunikation. Agile Methoden sind unter anderen Scrum, weiterführende Informationen siehe [Pichler08], Crystal, siehe [COCKBURN05], Feature-Driven Development (FDD), siehe [PALMER02] und Extreme Programming, siehe [BECK05] In den folgenden Abschnitten wird der Umgang mit Architektur in plangetriebenen und agilen Vorgehensmethoden am Beispiel von Wasserfallmethode und Scrum beschrieben. 3.1 Plangetriebene Methoden am Beispiel Wasserfall Die Vorgehensweise Mit plangetriebenen Vorgehensmodellen zu erstellende Systeme starten mit einer Analysephase, in der Anforderungen 7 an das System erhoben werden. In der Konzeptionsphase wird beschrieben, was getan werden muss, damit das System diesen Anforderungen gerecht wird, während in der Entwurfsphase festgelegt wird, wie die Anforderungen umzusetzen sind. Wenig überraschend werden Anforderungen in der Implementierungsphase gemäß dem Entwurf, also dem Wie umgesetzt und in der Testphase die korrekte Realisierung des Systems gemäß dem Was aus der Konzeptionsphase geprüft. Ist diese Prüfung erfolgreich, kann das System mit der abschließenden Einführungsphase seinem Bestimmungszweck zugeführt und benutzt werden. 5 Ich verwende die Begriffe Vorgehensmodell und Vorgehensmethode synonym. 6 Wer jetzt über V-Modell XT mit Scrum nachdenkt, betrachte bitte den Fokus beider Methoden? Angenommen, es soll die Leistungsfähigkeit einer Autobahn festgestellt werden, dann liefert V-Modell XT die Anzahl der Autos, die auf der Autobahn geparkt werden kann. Scrum hingegen liefert die Anzahl der Autos, die die Autobahn pro Zeiteinheit passieren können. Die erste Zahl ist mit der zweiten in keiner Weise vergleichbar und so verhält es sich auch mit den beiden Modellen. 7 Es wird in der Regel zwischen funktionalen und nicht-funktionalen Anforderungen sowie Rahmenbedingungen unterschieden (siehe [VOGEL08, Seite 107ff]). 11

12 Analyse Konzeption Entwurf Implementierung Test Einführung Abbildung 1: Phasenübergänge im Wasserfallmodell Im Wasserfallmodell sind Phasenübergänge in beiden Richtungen nur zur zwischen benachbarten Phasen zugelassen (siehe Abbildung 1). Eine neue oder geänderte Anforderung muss zwingend über die Analysephase in das System einfließen und Schritt für Schritt die folgenden Phasen bis zur Einführung durchlaufen. Ein im Betrieb des Systems entdeckter Fehler in einer Anforderung muss schrittweise über alle vorangehenden Phasen an den jeweiligen Vorgänger übergeben werden. Die fehlerhafte Anforderung wird in der Anforderungsanalyse korrigiert und die erforderliche Anpassung über die nachgelagerten Phasen nachgezogen. In jeder Phase des Wasserfallmodells müssen zwingend Artefakte erstellt werden, deren Existenz und Qualität Bedingung 8 für den Start der jeweils nächsten Phase ist, z.b. der Anforderungskatalog in der Analysephase, das Grobkonzept in der Konzeptionsphase, das Feinkonzept in der Entwurfsphase, die Programmierdokumentation in der Implementierungsphase usw. Bei einer neuen oder geänderten Anforderung müssen alle von der Änderung betroffenen Artefakte angepasst werden und die Qualität dieser Artefakte erneut bewertet werden Wasserfallmodell und Architektur Die Software- und Systemarchitektur im Wasserfallmodell wird während der Konzeptions- und Entwurfsphase definiert. Während in der Konzeptionsphase die Grobarchitektur beschrieben werden soll, muss in der Entwurfsphase die Feinarchitektur festgelegt werden. Dabei gilt es, die Architektur so vollständig wie möglich zu beschreiben. Architekturaspekte, die in dieser Phase nicht vorhanden bzw. nicht bereits in allgemeingültigen Dokumenten z.b. für Referenz- oder Unternehmensarchitektur beschrieben sind, stehen für die Implementierungsphase nicht zur Verfügung und können nicht umgesetzt werden. Wird eine solche Lücke während der Implementierung entdeckt, muss der fehlende, falsche oder unvollständige Architekturaspekt ergänzt/korrigiert werden. Die Implementierung des Architekturaspekts darf erst begonnen/fortgesetzt werden, wenn die entsprechende Dokumentation zur Verfügung steht. In plangetriebenen Vorgehensmodellen wird häufig zwischen fachlicher und technischer Architektur unterschieden und diese beiden Architektursichten in getrennten Dokumenten festgeschrieben. Die technische Architektur ist dabei in der Regel von der fachlichen Architektur abhängig. Im Idealfall 8 Der Abschluss einer Phase kann z.b. durch Passieren sogenannter Quality Gates geprüft und dokumentiert werden (siehe [AARON09]). 12

13 steht die fachliche Architektur bereits fest, wenn mit der Beschreibung der technischen Architektur begonnen wird. Die im vorangegangenen Abschnitt beschriebene Prüfung von Artefakten gilt auch für Architekturartefakte. Big Picture, Grob- und Feinarchitektur aus fachlicher und technischer Sicht müssen in ausreichender Qualität vorhanden sein, bevor die Implementierungsphase begonnen werden darf Auswirkung auf die Architektur Die Software- und Systemarchitektur in mit plangetriebenen Methoden durchgeführten Projekten kann monolithische Strukturen aufweisen und auf Grund der Mächtigkeit der Methode schwer änderbar sein. 9 Eine Ursache hierfür ist die Annahme, dass die Anforderungen, die mit der Softwareund Systemarchitektur erfüllt werden sollen, vollständig beschrieben sind. Entsprechend wird Änderungen oder Änderbarkeit der Software auf Architekturebene wenig bis kein Raum gewährt. Kommt es trotzdem zu Änderungen, sind häufig hohe Kosten bei Planung und Durchführung von Änderungen die Folge. Eine weitere Ursache für die Schwerfälligkeit gegenüber Änderungen ist in der umfangreichen Konzeption und Dokumentation der Architektur zu finden. Um dem Prozess der plangesteuerten Methode gerecht zu werden, ist eine hohe Anzahl von architekturrelevanten Artefakten zu erstellen. Diese Artefakte gehören teilweise nur indirekt zur Architektur, sind aber für deren Beschreibung im Rahmen der Methode zwingend erforderlich. Werden diese Architektur-Artefakte nicht in ausreichender Qualität zur Verfügung gestellt, werden Quality Gates der plangetriebenen Methode nicht erfüllt und das Softwareprojekt darf nicht fortgeführt werden. Zu diesen Architekturartefakten können folgende Dokumente gezählt werden. Big Picture bzw. Architekturüberblick Grobkonzept oder Grobarchitektur Feinkonzept oder Detailarchitektur Schnittstellenverträge und -beschreibungen Serviceverträge und -beschreibungen Sicherheitskonzept Formal müssen unabhängig vom Zeitpunkt eines Änderungsbedarfs alle diese Dokumente angepasst werden, bevor die Änderung durchgeführt werden darf. In der Realität werden die Anpassung der Dokumente und die Änderung am System oft parallel vorgenommen, da aus den Dokumenten heraus teilweise schwer ersichtlich ist, welche Änderung am System durchgeführt werden müssen, damit der Änderungsbedarf erfüllt werden kann. Damit wird zum einen die plangetriebene Methode konterkariert und eher ein iteratives Vorgehen wie in Abschnitt 4.3 beschrieben durchgeführt, zum anderen gezeigt, dass die gewählte plangetriebene Vorgehensmethode in ihrer Reinform schwer anwendbar ist. Wenn sich ein Vorgehensmodell nicht für Änderungen eignet, warum sollte es dann überhaupt für die Durchführung eines Softwareprojekts angewendet werden? Sind die Agilen Methoden nicht 9 Die Einschränkung ist keine seltene Ausnahme, gilt aber nicht für jeden Architekturentwurf. Es sind durchaus Systeme denkbar, bei denen monolithische Architekturen nicht als Nachteil betrachtet werden. 13

14 ohnehin die bessere Wahl für die Softwareentwicklung? Ja und Nein. Es kommt darauf an, welchen Fokus die Software, die entwickelt werden soll, hat. Besteht die Gefahr, dass durch Fehler im System Leben auf dem Spiel steht oder große Summen Geldes verloren gehen können, gleichzeitig aber die Änderungswahrscheinlichkeit von Anforderungen an das System gering ist oder diese Änderungen nicht zeit-, finanz- und lebenskritisch sind, ist eine plangetriebene Vorgehensmethode durchaus die bessere Wahl. Besteht die Gefahr, dass durch die Schwerfälligkeit einer plangetriebenen Methode Änderungen am System nicht rechtzeitig durchgeführt werden können und dadurch Leben oder große Geldbeträge auf dem Spiel stehen, tendiere ich eher zur Anwendung von Agilen Methoden. Die Steuerungssoftware eines Satelliten oder eines Raumschiffes beispielsweise wird eher mit Hilfe einer klassischen, plangetriebenen Vorgehensmethode erstellt werden. In [Boehm04, S. 54ff] sind fünf kritische Faktoren beschrieben, an Hand derer abgewogen werden kann, ob für eine konkrete Aufgabenstellung plangetriebene oder agile Methoden angewendet werden sollen. Die Architektur spielt bei der Abwägung eine eher untergeordnete Rolle, da die Architektur der gewählten Methodik folgt. 3.2 Agile Methoden am Beispiel Scrum Die Vorgehensweise Scrum ist eine agile Vorgehensmethode, die unter anderem für die Durchführung von Softwareprojekten genutzt werden kann. Scrum legt dabei Wert auf die Menschen im Umfeld des Projekts und die Kommunikation dieser Personen untereinander. Scrum kennt im Gegensatz zu plangetriebenen Methoden nur sehr wenige Regeln und Artefakte, was die Methode zu einem Prozessleichtgewicht macht. Die Vorgehensweise ist iterativ-inkrementell, d.h. innerhalb eines vorgegebenen Zeitfensters von zwei bis sechs Wochen soll ein vereinbarter Funktionsumfang zur Verfügung gestellt werden und in diesem Zeitfenster alle für die Erstellung der vereinbarten Funktionalität erforderlichen Tätigkeiten durchgeführt werden. Scrum kennt nur drei Projektrollen: Scrum Master, Product Owner und Scrum Team. Scrum kennt weder Projektleiter, noch Risiko- oder Release Manager, allerdings auch keinen Architekten. Scrum zeichnet sich wie alle Agilen Methoden dadurch aus, leichter auf geänderte Anforderungen oder Umweltbedingungen reagieren zu können als dies mit plangetriebenen Vorgehensmodellen möglich ist. Dadurch, dass ein System oder eine Software nicht erst komplett geplant und nach diesem Plan umgesetzt wird, sondern in kleinen Schritten vorgegangen wird und nach jedem Schritt geprüft wird, ob sich die Entwicklung noch in die richtige Richtung bewegt, fällt es leichter, den Abgrund oder den reißenden Fluss zu erkennen, der sich plötzlich vor dem System auftut. 10 Die Prüfung, ob sich das Projekt noch in die richtige Richtung bewegt, wird durch den Product Owner im Sprint Review Meeting im Idealfall im Beisein von Kunden vorgenommen. Das Scrum Team präsentiert die für den Sprint vereinbarte Funktionalität; der Product Owner bewertet live, ob die Funktionalität der Vereinbarung entspricht. Vielleicht entscheidet der Product Owner, dass eine Funktionalität zwar umgesetzt wurde, er aber eine Ergänzung wünscht, die gleich im nächsten Sprint 10 In klassischen Vorgehensmodellen werden diese plötzlich auftretenden Abgründe und Flüsse in der Regel erkannt, wenn sich das Projekt im freien Fall oder im Wasser befindet. 14

15 geliefert werden soll oder dass jetzt, wo eine bestimmte Funktionalität bereit gestellt wurde, eine ähnliche Funktionalität, die auf der eben gelieferten aufsetzt, angefordert werden kann Scrum und Architektur Oberflächlich betrachtet wird in Scrum-Projekten kein Augenmerk auf Architektur gelegt. So gibt es keine Regel, die festlegt, wann und in welchem Umfang Architektur geplant oder berücksichtigt werden muss. Die Verantwortung für die Architektur liegt beim Scrum Team. Während der Vorbereitung auf ein Scrum-Projekt, in der Regel im Sprint 0 (die allererste Iteration) sollen grundlegende Architekturentscheidungen getroffen werden bei der Planung jedes weiteren Sprints im Sprint Planning Meeting muss für jede User Story geprüft werden, inwiefern ihre Realisierung Auswirkungen auf die bereits bestehende Architektur hat oder inwiefern die Architektur des Systems angepasst werden muss, um die User Story sinnvoll umsetzen zu können. Muss und soll wurde hier bewusst gewählt; die Realität sieht leider etwas anders aus. User Stories, die Anforderungen in Scrum, müssen den Geschäftswert einer Software bzw. eines Systems für den Kunden erhöhen. Als Sachbearbeiter benötige ich eine Übersicht über meine offenen Aufgaben, um ihre zeitgerechte Erledigung gewährleisten zu können. Aktivitäten, die den Geschäftswert einer Software nicht direkt erhöhen, werden je nach Projekt nicht ausgeführt oder vor dem Kunden versteckt. Die Umstellung des Komponentenschnitts einer Software erhöht den Geschäftswert nicht und wird deswegen entweder nicht durchgeführt, was z.b. die Änderbarkeit der Software in der Zukunft behindern kann, oder heimlich ausgeführt. Der Kunde wundert sich vielleicht, dass eine User Story während der Umsetzung aufwändiger ist, als sie ihm erscheint. Da der Kunde seine Funktionalität letztlich wie gewünscht geliefert bekommt, spielt der Aufwand für ihn nur eine untergeordnete Rolle. Eine User Story wie die folgende würde heute beim Agilen Kunden einen Sturm der Empörung hervorrufen. Als Systemeigentümer möchte ich eine leicht wartbare Software, um mit vertretbarem Aufwand auf Änderungen reagieren zu können. In dieser User Story ist für den Kunden auf den ersten Blick kein Geschäftswert erkennbar, sollte man denken. Vielleicht ist es in der Agilen Welt an der Zeit, den Kunden den Geschäftswert leicht wartbarer Software zu erklären, in der neue oder geänderte Anforderungen untergebracht werden können, ohne die Software komplett umbauen zu müssen oder neu zu schreiben. Der Aufwand einer Änderung ist ein Geschäftswert, der minimiert werden kann. Im Gegensatz zu plangetriebenen Vorgehensmethoden wird bei Scrum-Projekten kein expliziter Wert auf Architekturdokumentation gelegt. Scrum selbst kennt keine Regel die die Dokumentation einer Software oder gar der Architektur festschreibt. Zur Einhaltung entsprechender Regeln müssen eher 11 In klassischen Vorgehensmodellen sieht der Kunde in der Regel erst nach Fertigstellung der Software, wie und ob seine Anforderungen erfüllt wurden. Frühes Kundenfeedback wie bei den agilen Methoden ist in plangesteuerten Modellen eher unüblich. 15

16 das Agile Manifest 12 oder parallel zu Scrum betriebene Agile Methoden wie Extreme Programming 13 herhalten Auswirkung auf die Architektur In meiner Wahrnehmung fällt das Los der Architektur in Agilen Projekten in zwei Kategorien: Berücksichtigung und Vernachlässigung. Ein Teil der Agilen Projekte neigt in der Realität dazu, Architekturaspekte zu vernachlässigen oder deren Berücksichtigung vor den Kunden zu verstecken (siehe Abschnitt 3.2.2). Eine Folge dieses Verhaltens sind Systeme, deren Änderbarkeit mit steigender Lebensdauer immer stärker abnimmt. Je stärker das System geändert wurde, desto länger dauert es, eine Änderung vorzunehmen. Zwingend notwendige Refactorings (siehe Abschnitt 4.2) werden nicht durchgeführt, weil sie den Geschäftswert der Software nicht erhöhen. Werden neben der Architektur auch noch automatische Tests außer Acht gelassen, steigt unter Umständen auch die Fehlerhäufigkeit und die Fehleranfälligkeit im System. Der Endzustand eines solchen Verhaltens ist ein nicht wartbares System, dessen Schicksal eine Neuentwicklung ist. Im schlechtesten möglichen Fall werden bei dieser Neuentwicklung dieselben Fehler wiederholt. In der idealen Scrum-Welt, die glücklicherweise häufig genug auch die reale Welt streift, werden Architekturaspekte entsprechend aktueller Anforderungen sehr wohl berücksichtigt. Was diesen Projekten jedoch fehlt ist der ganzheitliche Architekturansatz. Anstatt Architektur vorausschauend zu planen, wird sie aufgabenbezogen berücksichtigt. Eine Folge ist, dass metaphorisch zehnmal ein Schritt gemacht wird statt einmal fünf, um zum selben Ergebnis im Kontext der Architektur zu kommen. Mit vorausschauender Planung meine ich nicht den Architekturansatz der plangetriebenen Vorgehensmethoden, sondern Architekturplanung für die nächsten drei bis fünf Iterationen. Diese Vorgehensweise widerspricht in gewissem Maß den Prinzipien von Scrum. Scrum hat allerdings nicht den Anspruch allgemeingültig zu sein; Anpassungen am Prozess sind sehr wohl zulässig, sofern sie notwendig sind. 14 Eine wichtige Voraussetzung für die vorausschauende Architekturplanung in Scrum ist ein gut gepflegte Product Backlog und ein Product Owner, der genug Weitblick für die nächsten Iterationen im Projekt hat. Architektur muss in Scrum dokumentiert werden, allerdings wird in einem agilen Projekt niemand auf die Idee kommen, die Systemarchitektur vollständig nach zu dokumentieren. Dies würde bedeuten, einen wichtigen Vorteil agiler Methoden, Reaktionsfähigkeit auf Änderungen, zu verspielen, denn in dem Moment, wo eine umfangreiche Dokumentation vorhanden ist, muss sie auch (aufwändig) gepflegt werden. Wichtig aus meiner Sicht ist, in Architekturentscheidungen festzuhalten, warum die Architektur an einer bestimmten Stelle das Entwurfsmuster X enthält und warum man sich gegen Alternative Y entschieden hat. Verfügt das System dazu noch über ein Big Picture, das den aktuellen Zustand der 12 Siehe 13 Siehe [BECK04] 14 Eine Anwendung, bei dem in Scrum vorausschauend geplant wird, sind Projekte mit mehreren Teams, wenn zwischen den Teams Abhängigkeiten entstehen, z.b. ein Team eine Zulieferung für ein anderes Team macht und dieses andere Team mit einer Aufgabe erst dann beginnen kann, wenn diese Zulieferung erfolgt ist (siehe [LARMAN09, S. 289ff]). 16

17 Systemarchitektur widerspiegelt, steht dem System aus Architektursicht eine lange Lebensdauer bevor. 3.3 Artefakte und Regeln Alle Vorgehensmodelle, egal ob RUP, Scrum, Kanban oder V-Modell XT, haben eine Gemeinsamkeit: Um das jeweilige Vorgehensmodell zu erfüllen, müssen Regeln eingehalten und Artefakte gepflegt werden. Je nach Anzahl der zu erfüllenden Regeln bzw. erforderlichen Artefakte wird zwischen schwer- und leichtgewichtigen Modellen unterschieden. Die nachfolgende Tabelle stellt beispielhaft einige Vorgehensmodelle gegenüber. Vorgehensmodell Regeln und Artefakte Rational Unified Process (RUP) ca. 120 V-Modell XT 70 bis 100, je nach Konsequenz der Regelauslegung Scrum 13 Extreme Programming (XP) 13 Kanban 4 Hacking 0 Tabelle 3: Artefakte und Regeln je Vorgehensmethode Je mehr Regeln eingehalten und Artefakte erstellt/gepflegt werden müssen, desto aufwändiger ist es, Änderungen durchzuführen und dabei den Prozess einzuhalten. Die Komplexität der Artefakte und die Beziehungen der Artefakte untereinander z.b. über Querverweise oder Versionen von Artefakten, erhöhen den Aufwand von Änderungen noch mehr. Die Leichtgewichtigkeit von agilen Methoden wie Scrum oder XP suggeriert weniger Aufwand bei der Durchführung von Änderungen. Scrum kennt vier durch die Methode vorgegebene Artefakte: Product Backlog, Sprint Backlog, Taskboard und Burndown Chart. Besteht das Projekt aus mehreren Teams, gibt es pro Team ein Sprint Backlog, Taskboard und Burndown Chart. Das Product Backlog verwenden alle Teams, die am Produkt arbeiten, gemeinsam. In Abschnitt 2.2 ist eine Übersicht der 14 Lean Prinzipien aufgeführt. Im Folgenden versuche ich, diese Lean Prinzipien auf plangetriebene und agile Vorgehensmethoden anzuwenden. Meine Annahme ist, dass die vielen Artefakte und Regeln der plangetriebenen Vorgehensmethoden im Gegensatz zu agilen Methoden die Anwendbarkeit der Lean Prinzipien erschweren, wenn nicht sogar verhindern. Wird ein Prinzip von einer der Methoden weder unterstützt noch behindert, ist die entsprechende Zelle grau markiert. Unterstützt eine Methode ein Lean Prinzip, ist der Hintergrund der Zelle grün, behindert sie ein Prinzip, ist sie rot hinterlegt. Lean Prinzip Plangetriebene Methode Agile Methode Workflow visualisieren Anwendung möglich. Anwendung möglich. Einsatz der richtigen Anwendung möglich. Anwendung möglich. Werkzeuge Gleichmäßige Aufgabenverteilung Plangetriebene Methoden legen konkret fest, welche Aufgaben in welchem Zeitraum Anwendung je nach Methode möglich. erledigt werden müssen. Pull statt Push Siehe vorheriger Punkt. Anwendung möglich. 17

18 Lean Prinzip Plangetriebene Methode Agile Methode Wertflussoptimierung Eine Prozessoptimierung bedingt Anwendung möglich. Plananpassungen. Dies ist in plangetriebenen Methoden unerwünscht. Plangetriebene Methoden neigen dazu, gegen Optimierung resistent zu sein. Entscheidungen mit Anwendung möglich. Anwendung möglich. langfristigem Fokus treffen Probleme zuerst lösen Fokus ist die Planerfüllung. Für Aufgaben Anwendung möglich. außerhalb des Plans müssen Puffer vorgesehen werden, sonst scheint eine Planerfüllung schwer möglich. Menschen und Teams weiterentwickeln Eher von der Organisationskultur als von der Methode abhängig. Eher von der Organisationskultur als von der Methode abhängig. Entscheider aus dem Siehe vorhergehender Punkt Siehe vorhergehender Team Selbst kümmern Entscheidungen im Konsens treffen Klare Vorgaben für Rollen und Aufgaben. Proaktives Handeln wird eher verhindert als unterstützt. Entscheidungen werden durch das Management getroffen bzw. sind bereits durch die Methode vorgegeben. Punkt Anwendung möglich. Anwendung möglich. Lean weitertragen Anwendung scheint nicht möglich Anwendung möglich. Kontinuierliche Anwendung möglich. Verbesserung Regeln gemeinsam definieren Eine Prozessoptimierung bedingt Plananpassungen. Dies ist in plangetriebenen Methoden unerwünscht. Plangetriebene Methoden neigen dazu, gegen Optimierung resistent zu sein. Regeln werden durch die Methode und das Management festgelegt. Tabelle 4: Lean Prinzipien in plangetriebenen und agilen Vorgehensmethoden Anwendung möglich. Aus dieser Gegenüberstellung lassen sich aus meiner Sicht die folgenden Schlüsse ziehen. Plangetriebene Vorgehensmethoden sind für die Anwendung der Lean Prinzipien ungeeignet. Überall dort, wo Interaktionen mit Projektteilnehmern erforderlich sind, sind durch die Methode klare Regeln vorgegeben. Agile Methoden unterstützen die Lean Prinzipien. Dort, wo keine explizite Unterstützung vorliegt, werden die Prinzipien zumindest nicht behindert. Aus diesen beiden Feststellungen lassen sich folgende Schlüsse für Architekturaspekte in Projekten mit plangetriebenen und agilen Methoden ziehen. In einem mit agilen Vorgehensmethoden durchgeführten Projekt kann durch die Anwendung der Lean Prinzipien eine Lean Architecture erreicht werden. Voraussetzung dafür ist, dass die Regeln der Methode in Bezug auf die Architektur um die Lean Prinzipien erweitert werden. 18

19 In Projekten mit plangetriebenen Vorgehensmethoden ist dies wegen fehlender Unterstützung der Lean Prinzipien nicht denkbar. 19

20 4 Ansätze In den Abschnitten und wurde beschrieben, dass architekturgetriebene Tätigkeiten bei Anwendung agiler Methoden, konkret am Beispiel Scrum, eher vernachlässigt oder versteckt werden. Mit Abschnitt 3.3 wurde abgeleitet, dass agile Vorgehensmethoden gut geeignet sind, Lean Prinzipien und ihre Ausprägungen im Zusammenhang mit Architektur zu unterstützen. Hier besteht insofern ein Widerspruch dass Eignung für Lean Prinzipien nicht automatisch zu deren tatsächlicher Verwendung führt. Was augenscheinlich fehlt, sind Methoden, die den konkreten Lean Prinzipien Anwendung verschaffen. In den folgenden Abschnitten werden mehrere Ansätze beschrieben, die die Einhaltung der Lean Prinzipien bei der Erstellung und Pflege von Softwarearchitektur unterstützen oder darüber hinaus wichtige Denkanstöße liefern können. Zu jedem der Ansätze werden der oder die korrespondierenden Lean Prinzipien genannt. 4.1 Angemessenheit der Geschäftsprozesse Ein häufig beobachtetes Muster bei der Implementierung eines Systems ist das fehlende Hinterfragen der Angemessenheit der zu implementierenden Features. Wenn die Klärung z.b. folgender Punkte nicht stattfindet, besteht eine hohe Wahrscheinlichkeit, dass die Features des Systems dem in Abbildung 2 dargestellten Schema entsprechen. Sind die Prozesse optimal geschnitten? Befasst sich das System mit mehr als einer Aufgabenstellung? Enthalten die Prozesse überflüssige Features oder fehlen Features? Ist das System klar von seiner Umwelt abgegrenzt? 20

21 Niemals Selten Manchmal Oft Immer 19 Abbildung 2: Wie häufig werden Features eines Systems durchschnittlich genutzt [Standish Group 1994] Die Erhebung aus dem Jahr 1994 in Abbildung 2 mag veraltet erscheinen, die enthaltenen Zahlen sind aus eigener Erfahrung aktuell. Im Kontext Lean Architecture erscheint folgende Interpretation angebracht. 64 Prozent der Features einer Software sind unwichtig, da sie nicht oder nur selten genutzt werden; von einer Realisierung muss aus Kostengründen abgesehen werden 20 Prozent der Features sind wichtig; diese Features müssen umgesetzt werden 16 Prozent der Features werden manchmal genutzt; die Realisierung muss für jedes der betroffenen Features genau abgewogen werden Im Ergebnis werden durchschnittlich zwischen 20 und 36 Prozent der Features eines Systems wirklich benötigt. Nur diese Features sind wichtig, über die Realisierung der restlichen 64 bis 80 Prozent der Features darf gar nicht erst nachgedacht werden. Die Komplexität des Systems reduziert sich auf etwa ein Drittel der Gesamtmenge der Features, was jedoch nicht mit einem Drittel des angenommenen Umfangs verwechselt werden darf. Diese verringerte Komplexität beeinflusst hoffentlich die Architektur des betroffenen Systems, da sie mit dem Wissen um die wichtigen Features ebenfalls weniger komplex ausfällt. Leider lässt sich der Schnitt zwischen wichtigen und unwichtigen Features im Vorfeld zur Implementierung eines Systems nur selten zuverlässig ermitteln. Es gibt mindestens zwei denkbare Vorgehensweisen inkrementelles Vorgehen, bei dem nach jedem Inkrement erneut abgewogen wird, ob und welche weiteren wichtigen Features im System noch fehlen (siehe Abschnitt 4.3) 21

22 irrtümlich als wichtig betrachtete Features werden wieder aus dem System entfernt und damit Abhängigkeiten im System verringert (siehe Abschnitt 4.2) Der in diesem Abschnitt beschriebene Abstraktionslevel System und seine Features ist nur ein Beispiel für das hier beschriebene Prinzip. Die Regel kann analog auf die Funktionalität einer einzelnen Komponente oder die Gesamtheit der Systeme einer Organisation angewendet werden. Eine Komponente neigt zu Funktionalität, die künftig ganz sicher gebraucht wird, letztlich aber nie verwendet und irgendwann zurückgebaut wird. Auf der Ebene der Systeme einer Organisation wiederum tauchen zwischen den Systemen sich häufig überschneidende Funktionsumfänge auf. Die Prüfung der Angemessenheit einer Lösung / eines Systems unterstützt implizit die Lean Prinzipien Kontinuierliche Verbesserung, Entscheidungen mit langfristigem Fokus treffen und Wertflussoptimierung an. 4.2 Refactoring Unter Refactoring oder auch Refaktorisierung wird ein Prozess zur Anpassung der inneren Struktur bzw. des inneren Verhaltens einer Software verstanden, während das äußere Verhalten der Software unverändert bleibt. Die interne Anpassung der Software erfolgt zur Verbesserung ihres Designs (siehe [FOWLER05, S. XVIII]). Ändern sich Anforderungen oder kommen neue Anforderungen hinzu, muss bestehender Code häufig angepasst werden, damit das System diesen neuen oder geänderten Anforderungen gerecht werden kann. Wird dabei ausschließlich Wert auf die Realisierung der Anforderungen gelegt, leidet die Qualität des Codes. Die Wartbarkeit der Software verschlechtert sich. Änderungen können im Lauf der Zeit nur mit immer größeren Aufwänden vorgenommen werden. Die Entwickler hinterlassen im System technische Schulden. Spätestens jetzt sind Refactorings zwingend erforderlich, um die Software wieder in einen wartbaren Zustand zu überführen. Das äußere Verhalten der Software wird mit Hilfe automatischer Tests festgestellt und nach der Anpassung mit Hilfe derselben Tests verifiziert. Verfügt die Software über keine automatischen Tests, ist ein Refactoring praktisch nicht möglich, da nicht sichergestellt werden kann, dass das äußere Verhalten der Software nach dem Refactoring unverändert geblieben ist. Verbesserung des Designs einer Software meint im Kontext Refactoring auch eine Verbesserung der Architektur. Weiterführende Informationen zum Refactoring auf Code- und Designebene können beispielsweise [FOWLER05] entnommen werden. Refactoring auf die Code- und Designebene zu beschränken, greift aus meiner Sicht zu kurz. Die Konsolidierung der Anwendungslandschaft einer Organisation oder die Aktualisierung eines Standards kann ich durchaus als Refactoring interpretieren. Auf dieser Abstraktionsebene sind allerdings automatische Tests schwer erzeugbar. Die Beibehaltung des äußeren Verhaltens muss durch ein anderes Konstrukt überprüft werden können. In Abschnitt 4.1 wurde beschrieben, dass durchschnittlich 64 bis 80 Prozent der Features einer Software nicht oder nur selten verwendet werden. Wenn ein System mit 100 Prozent der Features entwickelt wurde, weil alle Features aus Kundensicht hohe Priorität hatten, lohnt sich die Erhebung der Häufigkeitsklassen im Nachhinein immer noch. Wenn wir es schaffen, dem Kunden die Erkenntnis 22

23 der nicht verwendeten Features zu vermitteln, können diese Features im Rahmen eines Refactoring entfernt und die Flexibilität der Software für künftige Änderungen erhöht bzw. wieder hergestellt werden. Refactoring zielt implizit auf die Lean Prinzipien Kontinuierliche Verbesserung, Probleme zuerst lösen, Selbst kümmern und Wertflussoptimierung ab. 4.3 Evolutionäres Design Evolutionäres Design zeichnet sich durch einen regelmäßigen Abgleich zwischen Problem- und Lösungsdomäne aus. Unter Problemdomäne kann im Kontext mit Architektur der Verbund aus Anforderungen und Rahmenbedingungen verstanden werden; die Lösungsdomäne umfasst alle Aktivitäten, die mit der Erfüllung dieser Anforderungen verbunden sind. Zur Verdeutlichung des Abgleichs zwischen Problem- und Lösungsdomäne zeigt Abbildung 3 das Koevolutionsmodell des Designs nach Maher, Poon und Boulanger. Nach diesem Modell kommt es während des Designs nicht darauf an, ein Problem vollständig zu beschreiben und anschließend eine Lösung für dieses Problem zu suchen, sondern vielmehr darum, Problem und Lösung kontinuierlich zu entwickeln und so dafür zu sorgen, dass sich Problem- und Lösungsraum mit fortschreitender Entwicklung immer mehr annähern [BROOKS11, S. 79f]. Abbildung 3: Koevolutionsmodell des Designs nach Maher, Poon und Boulanger von 1996 [BROOKS11, S. 79] Bei evolutionärem Design wird grundsätzlich zwischen drei Ansätzen unterschieden. Divide, Conquer and Integrate (DCI) Inkrementelles Design Rapid Prototyping In den folgenden Abschnitten werden diese drei Ansätze beschrieben. Der Kontext zu den Lean Prinzipien wird für jeden der Ansätze hergestellt. 23

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

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

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

Das Wasserfallmodell - Überblick

Das Wasserfallmodell - Überblick Das Wasserfallmodell - Überblick Das Wasserfallmodell - Beschreibung Merkmale des Wasserfallmodells: Erweiterung des Phasenmodells Rückkopplungen zwischen den (benachbarten) Phasen sind möglich Ziel: Verminderung

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

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

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

Mehr

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

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

Scrum for Management Praxis versus Theorie oder Praxis dank Theorie. ALM Day 26.Oktober 2011 Urs Böhm

Scrum for Management Praxis versus Theorie oder Praxis dank Theorie. ALM Day 26.Oktober 2011 Urs Böhm Scrum for Management Praxis versus Theorie oder Praxis dank Theorie ALM Day 26.Oktober 2011 Urs Böhm Übersicht Kurze Situationsübersicht Diskussion Prozesse Challenges in der SW-Entwicklung Wie geht Scrum

Mehr

Agile Programmierung - Theorie II SCRUM

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

Mehr

Agile 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

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

Agile Software-Entwicklung im Kontext der EN50128 Wege zum Erfolg

Agile Software-Entwicklung im Kontext der EN50128 Wege zum Erfolg Herzlich willkommen Agile Software-Entwicklung im Kontext der EN50128 Wege zum Erfolg Heike Bickert Software-/Systemingenieurin, Bereich Quality Management Braunschweig // 17.11.2015 1 Agenda ICS AG Fragestellungen

Mehr

SCRUM. Vertragsgestaltung & Vertragsorientierte Projektdurchführung. Katharina Vierheilig Vorlesung: Juristisches IT-Projektmanagement 08.01.

SCRUM. Vertragsgestaltung & Vertragsorientierte Projektdurchführung. Katharina Vierheilig Vorlesung: Juristisches IT-Projektmanagement 08.01. SCRUM Vertragsgestaltung & Vertragsorientierte Projektdurchführung Katharina Vierheilig Vorlesung: Juristisches IT- Agile Softwareentwicklung SCRUM 2 SCRUM Agiles Manifest Individuen und Interaktion Prozesse

Mehr

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.1 Wie kommt es zu einem Projektauftrag? Auftraggeber Projekt-Idee / Ziele [Anforderungen/Spezifikation/

Mehr

Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer

Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer Wasserfall vs. Agile: Eine Erfolgsstory 2 Umsetzung agiler Prinzipien Entwicklungsprozess 2009 30.6% 13.4% 20.6% 35.4% Agil Iterativ

Mehr

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

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

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

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

Agile Management Einführung in agiles Management

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

Mehr

Umsichtig planen, robust bauen

Umsichtig planen, robust bauen Umsichtig planen, robust bauen iks Thementag Mehr Softwarequalität Best practices für alle Entwicklungsphasen 19.06.2012 Autor: Christoph Schmidt-Casdorff Agenda Softwarearchitektur Architekturkonformität

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

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander?

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander? INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung Rütistrasse 9, Postfach 5401 Baden, Switzerland Phone: +41 56 222 65 32 Internet: www.infogem.ch Robust und Agil gegeneinander oder miteinander?

Mehr

Alle Inhalte dieses ebooks sind urheberrechtlich geschützt. Die Herstellung und Verbreitung von Kopien ist nur mit ausdrücklicher Genehmigung des

Alle Inhalte dieses ebooks sind urheberrechtlich geschützt. Die Herstellung und Verbreitung von Kopien ist nur mit ausdrücklicher Genehmigung des Alle Inhalte dieses ebooks sind urheberrechtlich geschützt. Die Herstellung und Verbreitung von Kopien ist nur mit ausdrücklicher Genehmigung des Verlages gestattet. Agiles Projektmanagement Scrum, Use

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

30 Multiple Choice-Fragen - pro Frage gibt es immer 1-4 richtige Antworten

30 Multiple Choice-Fragen - pro Frage gibt es immer 1-4 richtige Antworten SCRUM Foundation MUSTERPRÜFUNG Closed Book, d.h. keine Hilfsmittel zulässig Dauer: 60 Minuten 30 Multiple Choice-Fragen - pro Frage gibt es immer 1-4 richtige Antworten Beispiel für die Bewertung Annahme

Mehr

IT-Projekt-Management

IT-Projekt-Management IT-Projekt-Management email: vuongtheanh@netscape.net http: www.dr-vuong.de 2005 by, Bielefeld Seite 1 Vorgehensmodell 2005 by, Bielefeld Seite 2 Was ist ein Vorgehensmodell? Strukturbeschreibung über

Mehr

Gelebtes Scrum. Weg vom Management hin zur Führung

Gelebtes Scrum. Weg vom Management hin zur Führung Gelebtes Scrum Weg vom Management hin zur Führung Herausforderungen Was ist Scrum? Wer? Pigs Chicken Bild: http://www.implementingscrum.com/ Nein Danke, ich würde da voll drinstecken, aber du wärest

Mehr

Agile Prozessverbesserung. Im Sprint zu besseren Prozessen

Agile Prozessverbesserung. Im Sprint zu besseren Prozessen Agile Prozessverbesserung Im Sprint zu besseren Prozessen Ziel und Agenda Ziel: Wir wollen zeigen, wie Prozesse durch den Einsatz einer agilen Vorgehensweise noch projektfreundlicher verbessert werden

Mehr

Projektmanagement. Agile Vorgehensweise / Scrum. Version: 1.0 Stand: 23.06.2016

Projektmanagement. Agile Vorgehensweise / Scrum. Version: 1.0 Stand: 23.06.2016 Projektmanagement Agile Vorgehensweise / Scrum Version: 1.0 Stand: Lernziel Sie können in eigenen Worten darstellen warum Agilität notwendig ist. Sie können mit eigene Worten das Framework Scrum beschreiben.

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

Einführung eines agilen Vorgehensmodells auf der Basis von Werkzeugen und eines Leitbildes

Einführung eines agilen Vorgehensmodells auf der Basis von Werkzeugen und eines Leitbildes Einführung eines agilen Vorgehensmodells auf der Basis von Werkzeugen und eines Leitbildes Andreas Romahn Leipzig, 28.09.2010 InMediasP GmbH Neuendorfstraße 18 a 16761 Hennigsdorf www.inmediasp.de gestalten

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

Lösungen zum Test objektorientierter Software

Lösungen zum Test objektorientierter Software Lösungen zum Test objektorientierter Software Pieter van den Hombergh Fontys Hogeschool voor Techniek en Logistiek Software Engineering 14. März 2013 HOM/FHTeL Lösungen zum Test objektorientierter Software

Mehr

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

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

Andrea Grass & Dr. Marcus Winteroll oose Innovative Informatik GmbH. Geschäftsprozessmanagement und Agilität geht das zusammen?

Andrea Grass & Dr. Marcus Winteroll oose Innovative Informatik GmbH. Geschäftsprozessmanagement und Agilität geht das zusammen? Andrea Grass & Dr. Marcus Winteroll oose GmbH Geschäftsprozessmanagement und Agilität geht das zusammen? Agenda I. Wozu eigentlich BPM? II. Vorgehen und Rollen im abpm III. Methoden und Techniken IV. Resümee

Mehr

Warum sich das Management nicht für agile Softwareentwicklung interessieren sollte - aber für Agilität

Warum sich das Management nicht für agile Softwareentwicklung interessieren sollte - aber für Agilität Warum sich das Management nicht für agile Softwareentwicklung interessieren sollte - aber für Agilität Marcus Winteroll oose GmbH Agenda I. Ziele und Zusammenarbeit II. Was wir vom agilen Vorgehen lernen

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

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

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

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

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

Mehr

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

Scrum ist ein agiles Framework zur Software-Entwicklung. SCRUM bei Festo. Was ist SCRUM? Frank M. Hoyer, House of Software

Scrum ist ein agiles Framework zur Software-Entwicklung. SCRUM bei Festo. Was ist SCRUM? Frank M. Hoyer, House of Software SCRUM bei Festo Frank M. Hoyer, House of Software SI-MS/Frank M. Hoyer Scrum bei Festo 15. März 2010 geändert: 16. September 2014, HOY Was ist SCRUM? Scrum ist ein agiles Framework zur Software-Entwicklung.

Mehr

Vorstellung. Wie entsteht Architektur in Scrum

Vorstellung. Wie entsteht Architektur in Scrum Vorstellung Thema Architektur - Begriffsdefinition Eine Architektur (vοn griechisch αρχή = Anfang, Ursprung und lateinisch tectum = Haus, Dach) beschreibt in der Informatik im Allgemeinen das Zusammenspiel

Mehr

Agile Methoden. David Tanzer. Oliver Szymanski

Agile Methoden. David Tanzer. Oliver Szymanski Agile Methoden David Tanzer Oliver Szymanski Ziel von Softwareentwicklung Anforderungen zuverlässig und effizient in lauffähige Software verwandeln. Ziel von Softwareentwicklung Bedürfnisse des Kunden

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

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

IT-Basics 2. DI Gerhard Fließ. Vorgehensmodelle

IT-Basics 2. DI Gerhard Fließ. Vorgehensmodelle IT-Basics 2 DI Gerhard Fließ Vorgehensmodelle Sichtbarkeit Die Sichtbarkeit von Membervariablen und Methoden können durch die folgenden Schlüsselworte geregelt werden: private nur in der eigenen Klasse

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

Kanban Agile 2.0? Thomas Schissler artiso AG

Kanban Agile 2.0? Thomas Schissler artiso AG Kanban Agile 2.0? Thomas Schissler artiso AG Vorstellung Thomas Schissler Coach und Consultant artiso AG Schwerpunkte sind Team Foundation Server Agile Entwicklungsprozesse Software-Qualität Software-Architektur

Mehr

Risiken auf Prozessebene

Risiken auf Prozessebene Risiken auf Prozessebene Ein Neuer Ansatz Armin Hepe Credit Suisse AG - IT Strategy Enabeling, Practices & Tools armin.hepe@credit-suisse.com Persönliche Vorstellung, kurz 1 Angestellter bei Credit Suisse

Mehr

DevOps in der Praxis. Alexander Pacnik 24.11.2015

DevOps in der Praxis. Alexander Pacnik 24.11.2015 DevOps in der Praxis Alexander Pacnik 24.11.2015 Einführung... DevOps Versuch einer Definition Alexander Pacnik IT Engineering & Operations Project Management inovex GmbH 2 Einführung... DevOps Versuch

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

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

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

Mehr

Sollten folgende drei Fragen durch das Team positiv beantwortet werden, sind wichtige SCRUM-Elemente in Ihrem Team erfolgreich installiert.

Sollten folgende drei Fragen durch das Team positiv beantwortet werden, sind wichtige SCRUM-Elemente in Ihrem Team erfolgreich installiert. SCRUM-CHECKLISTE Teilen Sie diese Liste an alle Teammitglieder aus. Jeder soll einen Haken an der Stelle setzen, die er für Ihr SCRUM Team als erfüllt ansieht. Anschließend diskutieren Sie über fehlende

Mehr

Qualitätsmanagement. Software-Engineering für große Informationssysteme TU-Wien, Sommersemester 2004 Klaudius Messner

Qualitätsmanagement. Software-Engineering für große Informationssysteme TU-Wien, Sommersemester 2004 Klaudius Messner Qualitätsmanagement Software-Engineering für große Informationssysteme TU-Wien, Sommersemester 2004 Klaudius Messner 2004, Bernhard Anzeletti, Rudolf Lewandowski, Klaudius Messner, All rights reserved,

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

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

Agilität auf Unternehmensebene - Was hält uns davon ab?

Agilität auf Unternehmensebene - Was hält uns davon ab? Agilität auf Unternehmensebene - Was hält uns davon ab? Alexander Birke, Juli 2015 Copyright 2015 Accenture All rights reserved. Wie stellt sich Agilität heute dar? Das Scrum Framework: einfach und mittlerweile

Mehr

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

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

Mehr

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16 Probeklausur Lenz Belzner January 26, 2015 Lenz Belzner Probeklausur January 26, 2015 1 / 16 Definieren Sie Software Engineering in Abgrenzung zu Individual Programming. Ingenieursdisziplin professionelle

Mehr

The big picture: Prince2 featuring SCRUM. Bernd Lehmann, Prince2-Tag Köln, 12. Mai 2011

The big picture: Prince2 featuring SCRUM. Bernd Lehmann, Prince2-Tag Köln, 12. Mai 2011 The big picture: Prince2 featuring SCRUM Bernd Lehmann, Prince2-Tag Köln, 12. Mai 2011 Agenda PRINCE2 Scrum Scrum = Framework für das Managen (komplexer) Projekte Page 2 Prinzipien von Scrum Transparenz

Mehr

Höchst elastisch Scrum und das Wasserfallmodell

Höchst elastisch Scrum und das Wasserfallmodell Höchst elastisch Scrum und das Wasserfallmodell Kraus Wolfgang www.sourceconomy.com 1 Abstract Das Projekt bietet zwar alle Voraussetzungen für ein agiles Vorgehen, doch der Auftraggeber und das Kunden-Management

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

Was ist Application Lifecycle Management?

Was ist Application Lifecycle Management? Was ist Application Lifecycle Management? Von David Chappell Gefördert durch die Microsoft Corporation 2010 Chappell & Associates David Chappell: Was ist Application Lifecycle Management? Seite 2 von 7

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

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

(Titel des Berichts)

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

Mehr

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

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

Projektmanagement: Prozessmodelle

Projektmanagement: Prozessmodelle Projektmanagement: Prozessmodelle Martin Wirsing Institut für Informatik Ludwig-Maximilians-Universität München WS 2006/07 Ziele Wichtige Prozessparadigmen und Vorgehensmodelle wiederholen und in Zusammenhang

Mehr

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

Ü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

White-Paper zur Studie Lean-IT

White-Paper zur Studie Lean-IT White-Paper zur Studie Lean-IT Riesiges Verbesserungspotential in der Durchführung von IT-Projekten In Zusammenarbeit der Universität Hohenheim mit mm1 Consulting & Management Königstraße 10c D-70173 Stuttgart

Mehr

Di 7.2. Sprinten mit dem V-Modell XT. Olaf Lewitz. January 26-30, 2009, Munich, Germany ICM - International Congress Centre Munich

Di 7.2. Sprinten mit dem V-Modell XT. Olaf Lewitz. January 26-30, 2009, Munich, Germany ICM - International Congress Centre Munich Di 7.2 January 26-30, 2009, Munich, Germany ICM - International Congress Centre Munich Sprinten mit dem V-Modell XT Olaf Lewitz Sprinten mit dem V-Modell XT Olaf Lewitz microtool GmbH, Berlin Konkurrenz

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

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

Agile Softwareentwicklung Scrum vs. Kanban

Agile Softwareentwicklung Scrum vs. Kanban Agile Softwareentwicklung Scrum vs. Kanban Betül AtIiay, Ganna Shulika, Merve Yarat Universität Salzburg 29. Jänner 2016 Atliay, Shulika, Yarat (Univ. Salzburg) Agile Softwareentwicklung. Scrum vs. Kanban

Mehr

Agile Softwareentwicklung

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

Mehr

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

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert The Rational Unified Process Eine Einführung von T. Langer und A. Nitert Übersicht Einleitung Probleme der SW-Entwicklung, Best Practices, Aufgaben Was ist der Rational Unified Process? Struktur des Prozesses

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

Modellbasiertes Anforderungsmanagement für Change Requests Ein Praxisbericht. München, 11.03.2014

Modellbasiertes Anforderungsmanagement für Change Requests Ein Praxisbericht. München, 11.03.2014 Modellbasiertes Anforderungsmanagement für Change Requests Ein Praxisbericht München, 11.03.2014 Vorstellung Ihr Referent Ralf Nagel Senior Consultant für modellbasierte Anforderungsanalyse MID GmbH Kressengartenstraße

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

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

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

Planung in agilen Projekten

Planung in agilen Projekten Planung in agilen Projekten Angelika Drach DeutscheScrum 2012 improuv GmbH Agile Leadership. h7p://improuv.com Über mich Lange Jahre Erfahrung in der Bauplanung Planung und Agiles Vorgehen sind ein Widerspruch?

Mehr

Zielvereinbarung. Team JAMT.

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

Mehr

Die Softwareentwicklungsphasen!

Die Softwareentwicklungsphasen! Softwareentwicklung Die Softwareentwicklungsphasen! Die Bezeichnungen der Phasen sind keine speziellen Begriffe der Informatik, sondern den allgemeinen Prinzipien zur Produktion integrierter Systeme entliehen.

Mehr

16 Architekturentwurf Einführung und Überblick

16 Architekturentwurf Einführung und Überblick Teil III: Software-Architekturentwurf 16 Architekturentwurf Einführung und Überblick 16.1 Software entwerfen Warum? Beim Arbeiten im Kleinen nicht oder nur ansatzweise (Detailentwurf) Größere Software

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

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

Wie viel Geschäftsprozess verträgt agile Softwareentwicklung?

Wie viel Geschäftsprozess verträgt agile Softwareentwicklung? @LeanAgileScrum #LASZH LAS Conference 2012 Sponsoren Wie viel Geschäftsprozess verträgt agile Softwareentwicklung? Marcus Winteroll 16:15 Auditorium Organisationsteam Patrick Baumgartner (Swiftmind GmbH)

Mehr

WSR 2004. Softwarewartung und Prozessmodelle in Theorie und Praxis. Urs Kuhlmann Andreas Winter

WSR 2004. Softwarewartung und Prozessmodelle in Theorie und Praxis. Urs Kuhlmann Andreas Winter WSR 2004 Softwarewartung und Prozessmodelle in Theorie und Praxis Urs Kuhlmann Andreas Winter Universität Koblenz-Landau 1 Gliederung Wartungsbegriff Prozessmodelle Fallstudien Problembereiche Fazit 2

Mehr

Projekt: Requirements Engineering Sommersemester 2002. Anforderungsspezifikation im X-Treme Programming

Projekt: Requirements Engineering Sommersemester 2002. Anforderungsspezifikation im X-Treme Programming Projekt: Requirements Engineering Sommersemester 2002 Vortrag von Bernd Simmchen Anforderungsspezifikation im X-Treme Programming Gliederung 1 XP Eine kurze Einführung 2 Anforderungsspezifikation Klassisch

Mehr

Objektorientierter Software-Entwurf Grundlagen 1 1. Analyse Design Implementierung. Frühe Phasen durch Informationssystemanalyse abgedeckt

Objektorientierter Software-Entwurf Grundlagen 1 1. Analyse Design Implementierung. Frühe Phasen durch Informationssystemanalyse abgedeckt Objektorientierter Software-Entwurf Grundlagen 1 1 Einordnung der Veranstaltung Analyse Design Implementierung Slide 1 Informationssystemanalyse Objektorientierter Software-Entwurf Frühe Phasen durch Informationssystemanalyse

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

1 Einleitung. 1.1 Unser Ziel

1 Einleitung. 1.1 Unser Ziel 1 Dieses Buch wendet sich an alle, die sich für agile Softwareentwicklung interessieren. Einleitend möchten wir unser mit diesem Buch verbundenes Ziel, unseren Erfahrungshintergrund, das dem Buch zugrunde

Mehr