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

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was

Mehr

Agile 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

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

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

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

Ü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

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

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

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

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

Projektmanagement. Dokument V 1.2. Oliver Lietz - Projektmanagement. Probleme bei Projekten

Projektmanagement. Dokument V 1.2. Oliver Lietz - Projektmanagement. Probleme bei Projekten Projektmanagement Agile Methoden: Extreme Programming / Scrum Dokument V 1.2 Probleme bei Projekten Viel Arbeit, die an den Zielen vorbeigeht Viel Dokumentation für f r unbenutzte Bestandteile Fehlende

Mehr

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

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

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

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

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

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

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

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

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

6 Architektur-Mittel (WOMIT)

6 Architektur-Mittel (WOMIT) 6 Architektur-Mittel (WOMIT) Abb. 6-1: Positionierung des Kapitels im Ordnungsrahmen. Dieses Kapitel befasst sich mit der WOMIT-Dimension des architektonischen Ordnungsrahmens, indem es grundlegende Konzepte

Mehr

Lean Architecture. Zum Kennenlernen. Ramon Anger Dresden, 04.01.2012

Lean Architecture. Zum Kennenlernen. Ramon Anger Dresden, 04.01.2012 Lean Architecture Ramon Anger Dresden, 04.01.2012 Zum Kennenlernen Ego Technischer Architekt bei Capgemini davor debis, T-Systems, TomTom, Materna als Entwickler, Architekt, Teamleiter, Technischer Projektleiter,

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

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

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

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

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

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

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

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

Mehr

Systemen - Testen im Softwarelebenszyklus

Systemen - Testen im Softwarelebenszyklus P r a k t I s c h e Entwicklung und Test Testen von Software-Systemen Systemen - Testen im Softwarelebenszyklus Entwickler erstellen ihr System bzw. ihre Software und testen es/sie zur Entwicklungszeit

Mehr

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

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

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

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

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

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

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

Software Engineering (SE) 2) Phasenübergreifende Verfahren

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

Mehr

IT-Projektmanagement bei basecom. Manuel Wortmann, Patrick Rolefs

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

Mehr

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

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

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

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

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

Mehr

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

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

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

Das Kanbanboard Ein Beitrag zum Lean Software Development

Das Kanbanboard Ein Beitrag zum Lean Software Development Reklamations- QUALITY APPs Applikationen für das Qualitätsmanagement Das Kanbanboard Ein Beitrag zum Lean Software Development Autor: Prof. Dr. Jürgen P. Bläsing Bei Lean Software Development handelt es

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

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

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

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

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

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

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

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

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

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

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

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

Von 0 auf 13 oder mit Vollgas ins agile Zeitalter

Von 0 auf 13 oder mit Vollgas ins agile Zeitalter Von 0 auf 13 oder mit Vollgas ins agile Zeitalter Silvio Simone, Bison Group Susanne Mühlbauer, HOOD GmbH Scrum Day 2012 Bison Schweiz AG Surentalstrasse 10 CH-6210 Sursee www.bison-group.com HOOD GmbH

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

Einführung in die SWE

Einführung in die SWE Einführung in die SWE Inhalte der Vorlesung Allgemeine Ziele der Lehrveranstaltung Entwickeln einer kleinen Applikation nach professionellem Vorgehensmodell Erlernen des objektorientierten Herangehens

Mehr

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

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

10 Jahre agile Softwareentwicklung Wie erwachsen sind wir geworden?

10 Jahre agile Softwareentwicklung Wie erwachsen sind wir geworden? 10 Jahre agile Softwareentwicklung Wie erwachsen sind wir geworden? Stefan Roock stefan.roock@akquinet.de Hintergrund 1/2 Senior IT-Berater bei der akquinet AG extreme Programming seit Anfang 1999, dann

Mehr

Scrum E I N F Ü H R U N G

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

Mehr

Starke vs. Schwache Prozesse. Seminarvortrag

Starke vs. Schwache Prozesse. Seminarvortrag Starke vs. Schwache Prozesse Seminarvortrag 1 / 16 Gliederung des Vortrags Starke vs. Schwache Prozesse 1. Hintergrund 2. Begrifflichkeiten 3. Vergleich agiler und plangesteuerter Prozesse (Orientierung

Mehr

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

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

Mehr

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

Agile Entwicklung in IT-Projekten - Anforderungen an Systemintegratoren

Agile Entwicklung in IT-Projekten - Anforderungen an Systemintegratoren Agile Entwicklung in IT-Projekten - Anforderungen an Systemintegratoren Unternehmensberatung H&D GmbH AFCEA Mittagsforum M. Sc. Dipl. Ing. (FH) Matthias Brechmann Agenda Unternehmensberatung H&D GmbH Anforderungen

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

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

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

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

Mehr

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

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

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

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

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

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

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

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

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

Was fehlt Scrum? 31. März 2014 Erich Oswald CTO Ergon Informatik AG

Was fehlt Scrum? 31. März 2014 Erich Oswald CTO Ergon Informatik AG Was fehlt Scrum? 31. März 2014 Erich Oswald CTO Ergon Informatik AG Scrum ist eine Erfolgsstory Aus der Praxis entstanden Nachweislich erfolgreich Gut geeignet für komplexe Probleme Produktentwicklung

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

Projektmanagement durch Scrum-Proxies

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

Mehr

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

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

Mehr

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

Herkömmliche Softwareentwicklungsmodelle vs. Agile Methoden

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

Mehr

Extremes Programmieren

Extremes Programmieren Extremes Programmieren Übersicht, Demonstration, Erfahrungen ACM/GI Regionalgruppe Hamburg, 16.3.2001 Frank Westphal unabhängiger Berater westphal@acm.org http://www.frankwestphal.de Tammo Freese OFFIS,

Mehr

Kurzübersicht Unified Process und Agile Prozesse

Kurzübersicht Unified Process und Agile Prozesse Kurzübersicht Unified Process und Agile Prozes Rainer Schmidberger schmidrr@informatik.uni-stuttgart.de Copyright 2004, Rainer Schmidberger, Universität Stuttgart, Institut für Softwaretechnologie, Abt.

Mehr

3.4 Unified Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process.

3.4 Unified Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process. 1996 Philippe Kruchten: Rational Unified Process Produkt der Firma Seit 2002 Teil des IBM Konzerns Objektorientiertes

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

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

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

Klassische vs. agile Methoden der Softwareentwicklung

Klassische vs. agile Methoden der Softwareentwicklung Klassische vs. agile Methoden der Softwareentwicklung Vorgetragen am 03. November 2004 durch Jonathan Weiss Emel Tan Erstellt für SWT Methoden und Werkzeuge zur Softwareproduktion Agenda I. Einleitung

Mehr

Seminar: Softwareentwicklung in der Wissenschaft. Agile Softwareentwicklung

Seminar: Softwareentwicklung in der Wissenschaft. Agile Softwareentwicklung Seminar: Softwareentwicklung in der Wissenschaft Agile Softwareentwicklung Benjamin Pöpel Fakultät für Mathematik, Informatik und Naturwissenschaften Fachbereich Informatik Betreuer: Christian Hovy 23.

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