Agile Softwareentwicklung

Größe: px
Ab Seite anzeigen:

Download "Agile Softwareentwicklung"

Transkript

1 Agile Softwareentwicklung Yelve Yakut 29. Mai 2008 Inhaltsverzeichnis 1 Einleitung 1 2 Problematik 2 3 Vorgehensmodelle Das Wasserfallmodell Aspekte Vorteile Nachteile Agile Vorgehensmodelle Das Agile Manifest Gegenüberstellung Unterteilung Scrum Rollen Der Prozess Skalierbarkeit Fazit Feature Driven Development Rollen Der Prozess Skalierbarkeit Visualisierung Aspekt Orientierung Fazit Einleitung Die folgende Ausarbeitung behandelt agile Vorgehensweisen in der Softwareentwicklung. Zuerst wird die Notwendigkeit für eine strukturierte Projektplanung in der Softwareentwicklung gezeigt. Konservative Prozesse und ihre Nachteile werden näher betrachtet um daraus die Notwendigkeit für neue Methoden abzuleiten. Verschiedene Formen agiler Vorgehensweisen werden dargestellt und anhand der Vorgehensweisen Scrum und Feature Driven Development konkretisiert. 1

2 Bemerkung: Im Folgenden werden die Begriffe Vorgehensweise, Prozess, Prozessmodell und Methode synonym verwendet. In Kapitel 3 wird der Begriff näher erklärt. 2 Problematik Das Projektmanagement mauserte sich seit ihren Anfängen vor ca. 100 Jahren zu einer festen Teildisziplin der Ingenieurswissenschaften. Seit dem Auftreten erster, großer Softwareprojekte versucht man die selben Verfahren auch in der Informatik anzuwenden. Dabei zeigen sich jedoch viele Probleme, denn die Projekte unterscheiden sich grundsätzlich voneinander. Vergleicht man Projekte der klassischen Ingenieursdisziplinen mit denen der Softwareentwicklung stellt sich heraus das letztere Gruppe an einem akuten Mangel an Informationen leidet. Kundenspezifikationen sind unklar. Architekturen sind unklar. So konkretisieren sich viele Informationen erst im Laufe des Projektes. Beispielsweise könnte erst in der Testphase festgestellt werden, dass ein geplanter Algorithmus von seiner Funktionsweise her zwar einwandfrei funktioniert, allerdings kann er trotzdem nicht eingesetzt werden, weil er bei der Verwendung mit mehreren Benutzern zu langsam ist. Probleme dieser Art lassen sich aufgrund der unendlichen Vielfalt von Algorithmen nur bedingt vorhersagen. Zum Vergleich sei der Hausbau beispielhaft aus [CD05] herangezogen. Dem Bauherrn und seinem Team ist die Architektur des Hauses bereits bei Baubeginn schon sehr genau klar. Änderungen an der Architektur stellen eher die Ausnahme das, weil man im Vorfeld durch eine gute Kenntnis der Naturgesetze schon sehr genau weiß, welche Vorhaben realisierbar sind und welche nicht. Ein Architekt weiß bereits im Voraus das sein geplantes Haus mit hoher Wahrscheinlichkeit nicht einstürzen wird. Folgende Statistik, erhoben von QSM veranschaulicht die Problematik. Richten Sie Ihr Augenmerk auf den Punkt der Requirements. Diese änderten sich bei den betrachteten Projekten im Mittel um ein Viertel! Von 210 Projekten im Zeitraum von 1997 bis 1999: Zeitplan: 83 Projekte verspäteten sich um etwa 67%. Kosten: 70 der Projekte verbrauchten 127% mehr Mittel als erwartet. Requirements: Änderung der Anforderungen im Mittel um 22%. Organisation: Bei 98 Projekten waren die ursprünglichen Zahlen nicht mehr aufzufinden. Für eine differenziertere Betrachtung müssen jedoch zuerst konventionelle Vorgehensweisen näher betrachtet werden. 3 Vorgehensmodelle Vorgehensmodelle im Allgemeinen versuchen einen generischen Weg zur Entwicklung von Software zu beschreiben. Sie beantworten die Fragen: Welche Rollen müssen besetzt werden?, Was muss getan werden? In welche Aktivitäten kann man die Prozesse unterteilen? und In Welcher logischen Reihenfolge stehen diese und wie lange dauern sie?. 2

3 Abbildung 1: Das Wasserfallmodell nach Winston Royce.[Roy70] 3.1 Das Wasserfallmodell Ein typisches Vorgehensmodell ist beispielsweise das in Abbildung 1 dargestellte Wasserfallmodell. Es gehört zu den sogenannten linearen, prozessorientierten Vorgehensweisen. Das Wasserfallmodell beschreibt das Vorgehen aus der Sicht der Planung, es werden also keine Vorschriften zur operationalen Ausführung der Prozessschritte gemacht. Linear meint hier das ein Schritt vollständig abgeschlossen wird bevor der Folgeschritt eingeleitet werden kann. Im Folgenden werden typische Aspekte, Vor- und Nachteile aufgelistet Aspekte Ein Schritt wird vollständig abgeschlossen bevor Folgeschritte eingeleitet werden. Ein- und Austrittsbedingungen für die Schritte sind festgelegt. Damit die Ergebnisse eines Teilprozesses von dem darauffolgenden verstanden werden können müssen diese gründlich dokumentiert sein Vorteile Wenn die Kundenwünsche völlig klar sind und sich im Laufe des Projektes nicht ändern können Kosten und Zeit eingespart werden. Big Design Up Front meint eine möglichst gründliche Planung. Ein Bug der sehr früh also beispielsweise in der Entwurfsphase erkannt wird wäre um ein vielfaches teuer gewesen wenn man ihn erst beim Testen gemerkt hätte. Da Ein- und Austrittsbedingungen für jeden Schritt festgelegt sind gibt es keine Unklarheiten über Zuständigkeiten. Durch den hohen Anteil an Dokumentation ist ein Großteil der Entscheidungen nachvollziehbar. Neue Teammitglieder können sich leichter einarbeiten da alles gut dokumentiert ist Nachteile 1. Sobald sich die Kundenwünsche im laufe eines Projektes ändern, muss die aktuelle Phase unterbrochen werden woraufhin wieder bei der Anforderungsanalyse die geänderten Aspekte betrachtet werden müssen. 3

4 2. Wenn in einer der frühen Phasen unsauber gearbeitet wird, kann auch von Bug Design Up Front gesprochen werden. Ein Bug der dort übersehen wird kostet automatisch sehr viel Geld und Zeit. Dies geschieht sogar zwangsläufig so, da es extrem schwierig ist das Problem schon in der Anforderungs- und Designphase vollständig zu verstehen. 3. Der Aufwand für die Dokumentation ist deshalb so hoch weil die Ergebnisse eines Teilprozesses von den darauffolgenden Prozessschritten nachvollzogen werden müssen. Dieses Vorgehen wird auch als Throw Over The Wall bezeichnet. Ein großer Batzen Ergebnisse und Dokumentation werden über eine metaphorische Mauer zum nächsten Prozessschritt geworfen. Die Empfänger müssen dann sehen wie sie damit zurechtkommen. 4. Es stellt sich relativ spät bzw. gar nicht heraus wie teuer ein einzelnes Feature ist. Eine realistische Kosten-Nutzen Schätzung ist erst sehr spät im Projekt machbar. Wenn der Kunde im Laufe des Projekts ein Feature als zu teuer empfindet, kann es nur noch schwer und mit hohem Kostenaufwand aus den durchlaufenen Prozessschritten entfernt werden. Des weiteren ist das Geld, das in die bisherigen Prozessschritte investiert wurde, verloren. 5. Erst sehr spät im Prozess ist es möglich dem Kunden eine Alpha-Version der Software vorzuführen. Dies erzeugt Unsicherheit auf beiden Seiten. 6. Jeder der Phasen benötigt ganz spezifische Fähigkeiten. Durch die Linearität der Phasen ist es schwierig die Ressourcen effizient einzuteilen. Entweder müssen die Mitarbeiter alle Phasen gut beherrschen oder die Firma muss mehrere Projekte versetzt laufen lassen. 7. Da die Arbeit nach Tayloristischem Motto aufgespalten wird, lassen sich eine Reihe von Nachteilen daraus ableiten: Die Identifizierung der Mitarbeiter mit dem Produkt sinkt. Dadurch wiederum das Qualitätsbewustsein und die Motivation der Beteiligten. Die haben schlecht entworfen und jetzt muss ich das implementieren Nur wenige kennen inhaltlich den gesamten Prozess. Die Innovationsfähigkeit für Produkt und Aktivitäten wird eingeschränkt. Ich bin doch nur ein kleines Rädchen. Was soll ich schon ändern können. 4 Agile Vorgehensmodelle Aus all den Problemen und Nachteilen die aus herkömmlichen Vorgehensweisen entstehen, haben sich eine Reihe von agilen Vorgehensweisen entwickelt. Sie zeichnen sich durch folgende Punkte aus: Iterativ: Das Design kann durch Erkenntnisse aus den Implementierungs- und Test- Phasen beeinflusst werden. Kontinuierliche Releases in kurzen Intervallen: Der Kunde kann früh im Projekt Ergebnisse sehen. Und damit auch frühzeitig Fehler in den Anforderungen erkennen. Unkompliziert und leicht erlernbar: Der Prozess ist überschaubar und alle Beteiligten können ihn leicht nachvollziehen. Anpassungsfähig: Auf sich ändernde Bedingungen und Anforderungen kann mit wenig Aufwand eingegangen werden. Regelmäßige Kommunikation nach Innen wie nach Außen: Kommunikation fördert Motivation. Direkte Kommunikation ist ein viel besseres Mittel zur Informationsvermittlung als Dokumentation. Der Aufwand zur Dokumentation kann reduziert werden. 4

5 4.1 Das Agile Manifest Einige agile Vorgehensweisen wurden publiziert und an großen Softwareprojekten erprobt. Durch deren zunehmende Popularität und Erfolg keimte auch der Wunsch, Gemeinsamkeiten zu finden und diese niederzuschreiben. Am 13. Februar 2001 trafen sich namhafte Verfechter der agilen Bewegung und verfassten das Agile Manifest. [man] Das agile Manifest ist einerseits allgemein genug gefasst um künftigen Vorgehensweisen genug Raum für Innovation zu lassen, bringt aber andererseits genau auf den Punkt was agile Softwareentwicklung von herkömmlichen Vorgehensweisen unterscheidet und worauf es eigentlich bei der Softwareentwicklung ankommt. 1. Individuen und Interaktionen gelten mehr als Prozesse und Tools. Zwar sind wohldefinierte Entwicklungsprozesse und hoch entwickelte Entwicklungswerkzeuge wichtig, wesentlich wichtiger ist jedoch die Qualifikation der Mitarbeitenden und eine effiziente Kommunikation zwischen ihnen. 2. Funktionierende Programme gelten mehr als ausführliche Dokumentation. Gut geschriebene Dokumentation kann zwar hilfreich sein, das eigentliche Ziel der Entwicklung ist jedoch die fertige Software. Außerdem ist eine intuitiv verständliche Software hilfreicher als umfangreiche Dokumentation, die sowieso niemand liest. 3. Die stetige Zusammenarbeit mit dem Kunden steht über Verträgen. Ein Vertrag ist normalerweise die Grundlage für die Zusammenarbeit. Was der Kunde aber wirklich will, kann nur in ständiger Kommunikation mit ihm ermittelt werden. 4. Der Mut und die Offenheit für Änderungen steht über dem Befolgen eines festgelegten Plans. Im Verlauf eines Entwicklungsprojektes ändern sich viele Anforderungen und Randbedingungen ebenso wie das Verständnis des Problemfeldes. Das Team muss darauf schnell reagieren können. 4.2 Gegenüberstellung Man kann nun sehen wie die Nachteile des Wasserfallmodells aus Kapitel durch agile Vorgehensweisen adressiert werden. Zu Punkt 1: Zum einen sind die Vorgehensweisen direkt auf sich ändernde Bedingungen ausgelegt. Zum anderen stellt sich durch regelmäßige Kommunikation mit dem Kunden und regelmäßige Releases, viel früher heraus ob Anforderungen angepasst werden müssen. Durch die frühe Erkennung minimiert sich auch der Aufwand. Zu Punkt 2: Da in kurzen Iterationen gearbeitet wird, ist das Design meist auch auf diese beschränkt. Dadurch ist die Planung überschaubar und weniger fehleranfällig. Selbst planungslastige Vorgehensweisen wie Feature Driven Development(Kapitel 4.5) versuchen nicht alles im Vorfeld bis ins kleinste Detail zu planen. Entsprechend unwahrscheinlicher ist auch das Auftreten dieses Problems. Zu Punkt 3: Die Dokumentation verliert an Bedeutung, da die Throw Over The Wall Methode in agilen Verfahren nicht vorkommt. Intern wird ein hoher Kommunikationsaufwand betrieben damit jeder das Design, die Schnittstellen sowie die Domänenund Systemdetails kennt. Extern wird versucht Software möglichst intuitiv zu gestalten damit Dokumentation nicht mehr so wichtig ist. Zu Punkt 4: Durch häufige Iterationen wird früher klar wie hoch der Aufwand für ein Feature ist. Der Designaufwand beschränkt sich auf die aktuelle Iteration, so wird 5

6 Abbildung 2: Nebenläufige Prozessmodelle. auch nicht viel Planung in ein Feature investiert das sich bei einer Kosten-Nutzen Schätzung im Laufe des Projektes als unvorteilhaft herausstellt und unerwünscht ist. Vorgehensweisen wie z.b. Feature Driven Development(Kapitel 4.5) sind darauf ausgelegt diese Abschätzung möglichst genau zu betreiben. Dort kann der Kunde sehr leicht nachvollziehen wie lange ein Feature benötigt hat und voraussichtlich benötigen wird. Zu Punkt 5: Wieder zeigen sich die Vorteile der Iterativen Herangehensweise. Einige agile Prozesse erfordern von jeder Iteration das sie eine getestete und funktionsfähige Software als Ausgabe bereitstellt. Der Kunde kann ständig den Verlauf der Entwicklung ausprobieren. Bei den Prozessen wo das nicht explizit erfordert ist können die Iterationen so ausgelegt werden das beispielsweise die Iteration Nr.123 solch eine Vorversion zur Verfügung stellt. Zu Punkt 6: Entweder die gesamte Planung oder zumindest ein Großteil der Planung geschieht innerhalb der Iterationen. Da Iterationen jedoch in der Regel nicht länger als einen Monat dauern und man oft sogar mehrere Iterationen von mehreren Teams gleichzeitig bearbeiten lassen kann, lassen sich Ressourcen sehr viel leichter einteilen. Zu den Punkten 7, 8 und 9: Agile Vorgehensweisen räumen den Menschen einen höheren Stellenwert ein. Das Team steht bei Prozessen wie Scrum (Kapitel 4.5) im Mittelpunkt. Das maximiert die Identifizierung mit dem Produkt und bezieht den Mitarbeiter voll in den Prozess ein. Selbst eher hierarchisch organisierte Vorgehensweisen wie Feature Driven Development machen es sehr deutlich das ausnahmslos jeder Mitarbeiter in der Planungsphase auch den Prozessen beiwohnt, die auf einer höheren Hierarchieebene liegen. So weiß Jeder wie Design und Anforderungen entstanden sind und hat Einfluß auf die Prozessschritte. Des weiteren ist agilen Prozessen inhärent, leicht verständlich zu sein. Dann weiß nicht nur Jeder wie die Ergebnisse entstanden sind, sondern auch warum man ausgerechnet gerade an einem bestimmten Problem arbeitet. 4.3 Unterteilung Im Folgenden werden agile, prozessorientierte, nicht-linearen Modelle betrachtet. Hierfür werden diese weiter in nebenläufige, iterative und inkrementelle Prozesse aufgeteilt. Allgemeine, generische Varianten sind in den Abbildungen 2,3 und 4 dargestellt. 6

7 Abbildung 3: Iterative Prozessmodelle. Abbildung 4: Inkrementelle Prozessmodelle. 4.4 Scrum Direkt übersetzt bedeutet Scrum, das Gedränge. Das Wort stammt aus dem Rugby und beschreibt die Standardsituation um das Spiel nach einem Regelverstoß zu starten. [scr] Scrum ist ein agiler, iterativer Prozess, bei dem das Scrum-Team im Mittelpunkt steht. Erstmals veröffentlicht wurde der Prozess auf der OOPSLA ([JS97]) von Jeff Sutherland und Ken Schwaber, basierend auf einer Idee von Hirotaka Takeushi & Ikujiro Nonaka([HT86]) Rollen Im Folgenden sind die Rollen des Scrum Prozesses aufgelistet. Die Rollen sind nicht Disjunkt, das heißt eine Person kann mehrere Rollen innehaben. Scrum Team: Betreibt die eigentliche Wertschöpfung. Design, Implementierung und das Testen der Software. Das Scrum-Team steht im Mittelpunkt der Softwareentwicklung. Es besteht aus nicht mehr als 10 Personen. Scrum Master: Delegierter des Scrum-Teams. Dient als Schnittstelle zur Außenwelt und hat die Aufgabe das Scrum-Team möglichst abzuschirmen. Hat keine Weisungsbefugnis innerhalb des Scrum-Teams. Er ist eher vergleichbar mit einem Schiedsrichter, denn er achtet auf die Einhaltung der Scrum-Regeln. Product Owner: Schnittstelle zwischen Kunde und Projekt. Er achtet darauf das Projekt- Intern alles auch aus Kundensicht seine Richtigkeit hat. Er ist maßgeblich für die Erstellung des Product-Backlog(Siehe Kapitel 4.5 und Abbildung 7) zuständig. Außerdem kümmert er sich um die Abnahme der Sprints, der Zwischenversionen und des Endproduktes. 7

8 Abbildung 5: Die Scrum-Phasen Pre-Game, Game und Postgame im Überblick. Management: Das Management schirmt das Scrum-Team auf höherer Ebene ab. Beispielsweise wenn sich ein Kunde unkooperativ zeigt. Es gibt grobe Anforderungen und stellt grobe Anforderungen. Es hat bei Unklarheiten das letzte Wort Der Prozess Abbildung 5 zeigt die allgemeine Vorgehensweise in Scrum. Die Pre-Game-Phase dient der allgemeinen Projektplanung und des Designs der Grobarchitektur. In der Game-Phase spielt sich die eigentliche Entwicklung in Iterationen, den sogenannten Sprints ab. Ein Sprint wird hierbei so gewählt das es nicht länger als 30 Tage dauert. Im Post-Game schließlich findet die Endabnahme statt, es werden abschließende Tests durchgeführt und die Dokumentation wird soweit nötig erstellt. Im Folgenden werden die einzelnen Prozessschritte und die daran beteiligten Rollen näher beleuchtet. Abbildung 6 soll hierbei der Übersicht dienen. Pre-Game In der Pre-Game-Phase geht es insbesondere um die Planung und das Design der Grobarchitektur. Die Projektplanung dient hierbei der Festlegung der Projekt-Rahmen-Bedingungen. Das Management bestimmt unter Einbeziehung der Beteiligten aus welchen Mitarbeitern die Teams bestehen oder auch welche Technologien und Werkzeuge zu verwenden sind. Sogar Code-Konventionen die eingehalten werden müssen werden während der Projektplanung festgelegt. Daraufhin wird eine erste Version des Product Backlogs, in Zusammenarbeit mit dem Product Owner, erstellt. In dem Stadium enthält das Backlog alle Funktionalitäten die das spätere Produkt erfüllen soll. Das Product Backlog ist praktisch eine Todo-Liste. Sie kann ganze Features enthalten oder auch sehr spezifische Bugfixes und Refactorings. Abbildung 7 zeigt dies beispielhaft. Es ist wichtig anzumerken das ein Product Backlog nicht in Stein 8

9 Abbildung 6: Eine detaillierte Ansicht des Scrum Prozesses. (1): Pre-Game, (2): Game, (3): Post-Game gemeißelt ist. Anfangs ist es sogar bewusst allgemein gehalten und ändert sich ständig im Laufe des Projekts. Auf der Grundlage des Product Backlog wird das Grobdesign erstellt. Im Design Review Meeting werden daraufhin erstellte Modelle überprüft und verbindlich ausgewählt. Game Im Anschluss auf die Pre-Game-Phase folgen die Iterationen bzw. die Sprints. Die eigentliche Entwicklung spielt sich in dieser Phase ab. Im Sprint Planing Meeting werden die Ziele innerhalb eines Sprint Backlog für den folgenden Sprint festgelegt. Das Ergebnis nennt sich auch Sprint Goal. Innerhalb des Sprints ist das Scrum Team auf sich gestellt und hat (fast) freie Wahl über Methoden und Herangehensweisen um das Sprint Goal zu erreichen. Damit die Entwicklung nicht aus dem Ruder gerät, werden tägliche Stand-Up-Meetings gehalten. Diese Meetings werden morgens veranstaltet und dürfen nicht länger als 15 Minuten dauern. Die Teammitglieder tauschen kurz Informationen aus. Folgende Fragen werden geklärt: Was hast du gestern getan?, Was wirst du heute machen? und Wurdest du durch etwas gehindert?. Wenn vorhanden ist es die Aufgabe des Scrum-Masters diese Störungen zu beseitigen. Bei diesen Meetings haben nur die sogenannten Pigs Rederecht. Pigs sind diejenigen Mitarbeiter die beim aktuellen Sprint aktiv zur Produktion des Endproduktes beitragen. Alle anderen Mitarbeiter sind Chickens und dürfen sich nicht in die Meetings einbringen. Das Sprint Review Meeting findet statt sobald das Sprint Backlog abgearbeitet ist oder maximal 30 Tage vergangen sind. In diesem Meeting wird in Zusammenarbeit mit dem Product Owner entschieden ob es einen weiteren Sprint geben wird. Wenn nicht macht man bei der Post Game Phase weiter.im Sprint gewonnene, neue Erkenntnisse werden in das Product 9

10 Abbildung 7: Beispiel eines Product Backlogs. Quelle: Mountain Goat Software Größter Scrum mit 600 Mitarbeitern [mgsa]. Backlog eingepflegt. Post-Game Nach einigen Sprints hat die Software den vom Kunden gewünschten zustand erreicht. Diesen gewünschten Zustand bestimmt hierbei der Product Owner. Das Ergebnis wird daraufhin integriert und ausführlich getestet und falls nötig auch dokumentiert. Bugs die in dieser Phase gefunden werden sind in das Product Backlog einzutragen und in einem neuen Sprint abzuarbeiten Skalierbarkeit Obwohl die Scrum Teams auf maximal 10 Personen beschränkt sind ist es möglich größere Scrums aufzubauen. Hierbei wird Fraktal vorgegangen. Scrums höherer Ordnung bestehen aus den Scrum Mastern der Scrums niederer Ordnung. Die Scrums höherer Ordnung gehen nach dem gleichen Schema vor, wobei die Stand-Up-Meetings nicht täglich stattfinden und länger als 15 Minuten dauern dürfen. Die Entscheidungen die dort getroffen werden, betreffen immerhin sehr viele Mitarbeiter und sind es wert ausdiskutiert zu werden. Mountain Goat Software hat mit dieser Methode einen Scrum von über 600 Mitarbeitern aufgebaut. Abbildung 8 zeigt dies beispielhaft für 243 Mitarbeiter Fazit Kurzum ist Scrum ein Musterbeispiel für agile Softwareentwicklung. Leicht überschaubar, iterativ, kommunikationsintensiv, anpassungsfähig und skalierbar. Den Scrum-Teams werden viele Freiheiten überlassen. Das fördert die Identifikation der Mitarbeiter mit dem Produkt und der Vorgehensweise. Durch die Freiheiten steigen jedoch auch die Anforderungen an die Fähigkeiten der Entwickler. Das Team muss interdisziplinär sein, sollten Projekterfahrung haben und einen hohen Anteil an Selbstständigkeit und Eigenverantwortung zeigen. Da keine Praktiken innerhalb der Sprints vorgegeben werden, können sich die Scrum Teams für Praktiken aus dem Extreme Programming entscheiden [Bec99]. 10

11 Abbildung 8: Ein Scrum of Scrums mit 243 Mitarbeitern. Quelle: [mgsb] 4.5 Feature Driven Development Feature Driven Development ist ein agiler Prozess, der durch seine geschachtelten Prozessschleifen ein gleichzeitig iterativer und inkrementeller Prozess ist. Jeff De Luca bekam die Aufgabe, ein als verloren geglaubtes Projekt, die Softwareplattform einer Bank in Singapur, zu reengineeren [ffd]. Für dieses Projekt erfand er FDD auf Basis von Ideen von Peter Coad. Für das Projekt standen 50 Entwickler und 15 Monate Zeit zur Verfügung. Es wurde innerhalb des zeitlichen und finanziellen Rahmens abgeschlossen. Später wurde FDD erstmals in [JDL99] veröffentlicht und in [SRP02] weiter verfeinert Rollen Im Folgenden ist die verhältnismäßig hierarchische Rollenverteilung des FDD aufgelistet. Jeder ist für einen bestimmten Teil des Projektes verantwortlich. Die Rollen sind nicht Disjunkt, das heißt eine Person kann mehrere Rollen innehaben. Insbesondere ist jeder Chefprogrammierer auch ein Klassenbesitzer. Projektmanager: Verantwortlich für den Zeitplan und die Ressourcenverteilung. Chefarchitekt: Er muss den gesamten Entwurf verantworten. Alle Meetings die das Gesamtmodell angehen stehen unter seiner Schirmherrschaft. Entwicklungsmanager: Plant gemeinsam mit dem Projektmanager die Ressourcenverteilung. Außerdem Organisiert er die tägliche Jobs der Programmierer. Chefprogrammierer: Erfahrener Programmierer. Fungiert als Teamleiter für die ihm zugeordneten Klassenbesitzer/Programmierer. Ist zuständig für Analyse, Entwurf und Implementierung von Features. Zu seinen Aufgaben gehört auch die regelmäßige Berichterstattung. 11

12 Abbildung 9: Die 5 Phasen des FDD im Überblick. Klassenbesitzer: Jeder Klasse ist genau ein Programmierer zugeordnet. Dieser ist dann der Klassenbesitzer. Nur er hat die Befugnis seine Klassen zu ändern(code Ownership). Da jeder Klasse ein Programmierer fest zugeordnet ist, wird es leichter für das Management die Leistungen der Mitarbeiter einzuschätzen und zu beurteilen. Domänenexperte: Der Domänenexperte ist der Kunde bzw. der Benutzer des Systems und kennt die Anforderungen. Er wird tief in den Entwicklungsprozess integriert. Berät in allen Fragen die das Gesamtmodell oder die Problemdomäne betreffen. Zusätzlich existieren in FDD folgende, unterstützende Rollen. Release Manager: Analysiert die Berichte der Chefprogrammierer und leitet daraus den Projektfortschritt ab. Programmiersprachen-Guru: Ist Experte für eine Programmiersprache und berät bei entsprechenden Fragen. Build Engineer: Betreibt Build- und Releasemanagement. Toolsmith: Entwickelt kleine Tools, die die tägliche Arbeit der Projektbeteiligten vereinfachen. Systemadministrator: Stellt die benötigte Infrastruktur bereit. Installiert die für das Projekt benötigte Hard- und Software. Tester: Prüft das System auf Korrektheit. Deployer: Konvertieren beim Reengineering-Prozess bereits existierende, alte Dateien in ein neues Format. Scribe: Schreibt online und gedruckte Benutzerhandbücher Der Prozess Abbildung 9 zeigt eine grobe Betrachtung von FDD. Zuerst wird anhand der Spezifikationen und in Zusammenarbeit mit den Domänenexperten die Problemdomäne modelliert(1). Dann erzeugt man eine Feature-Liste(2). Plant daraufhin die Implementierung von jedem Feature(3). In den folgenden Iterationen plant man zuerst die Features der aktuelle Iteration(4) und implementiert diese dann(5). Im Folgenden werden die einzelnen Prozessschritte und die daran beteiligten Rollen näher beleuchtet. Abbildung 10 soll hierbei der Übersicht dienen. Ein Merkmal von FDD ist das alle 12

13 Programmierer auch in den ersten 3 Planungsphasen an den Meetings teilhaben sollen. Da es nicht praktikabel ist mit allen gleichzeitig Meetings zu veranstalten, wird das Personal das weniger wichtig für das entsprechende Meeting ist, mittels Rotation eingeladen. Eine andere Besonderheit an FDD ist das jedes der fünf Prozessschritte jeweils Ein- und Ausgangskriterien hat und Möglichkeiten zur Überprüfung der Ergebnisse bietet. (1) Gesamtmodell In der ersten Phase geht es insbesondere um die Planung und das Design der Grobarchitektur in Form eines Domänenmodells. Unter Schirmherrschaft des Chefarchitekten wird in Zusammenarbeit mit den Domänenexperten das Gesamtmodell erstellt. Das Gesamtmodell besteht hierbei aus einer Reihe von Modellen die die Problemdomäne veranschaulichen sollen. Das Modell wird dann bei bedarf in Teilbereiche unterteilt und weiteren Teams zugeordnet die daraufhin parallel an detaillierteren Teilmodellen arbeiten. Eingangskriterien umreißen kann. Hierbei reicht es wenn der Kunde die Anforderungen an das System Überprüfung Da in dieser Phase die Domänenexperten sehr eng mit einbezogen werden und die Ergebnisse dem Team Vorgestellt werden ist keine weitere Überprüfung notwendig. Ausgangskriterien Es existiert das Gesamtmodell. (2) Feature-Liste Anhand des Gesamtmodells erstellt das Feature-List-Team eine priorisierte Feature-Liste. Beispielhaft ist eine Feature-Liste in Abbildung 11 zu sehen. Ein Feature besteht immer aus einer Aktion das auf einem Objekt ausgeführt wird und ein Ergebnis produziert. Es sind Entitäten die für den Kunden einen konkreten Wert darstellen. Weiterhin können Features in Featuresets gruppiert werden und weiter in Hauptfeaturesets auf der obersten Ebene zusammengefasst werden. Im Beispiel wäre Studienangelegenheiten ein Hauptfeatureset und Studentenverwaltung ein Featureset. Eine weitere Bedingung an die Features ist, das diese in maximal 2 Wochen implementierbar und testbar sein müssen. Ist das mal nicht der Fall werden entsprechende Features in einer weiteren Iteration in Teilfeatures aufgespalten. Außerdem ist darauf zu achten das im Feature-List-Team auch Domänenexperten sind um die Korrektheit der Ergebnisse zu gewährleisten. Phase 1 wurde erfolgreich abgeschlossen. Es existiert also ein Gesamt- Eingangskriterien modell. Überprüfung Wie in Phase 1 geschieht die Überprüfung automatisch da die Domänenexperten auch hier eng mit in die Planung einbezogen werden. Ausgangskriterien Eine priorisierte Feature-Liste mit einer Gliederung in Featuresets und Hauptfeaturesets existiert. 13

14 Abbildung 10: Eine detaillierte Ansicht von FDD. (1): Gesamtmodell (2): Feature-Liste (3): Planung je Feature (4): Entwurf je Feature (5): Konstruktion je Feature. 14

15 <Aktion> <Ergebnis> <Objekt> Studienangelegenheiten Studentenverwaltung Student hinzufügen Student anhand Filtermaske suchen LV-Verwaltung LV löschen Interne Angelegenheiten Mitarbeiterverwaltung Sekretärin hinzufügen Administrator löschen Datenbankadministration Backup der Datenbank in einer Datei erstellen Abbildung 11: Beispiel für eine nicht priorisierte Feature Liste. (3) Planung je Feature Der Projektmanager muss nun in Zusammenarbeit mit dem Entwicklungsmanager und den Chefprogrammierern den Zeitaufwand, die Abhängigkeiten und die Reihenfolge für die einzelnen Features einschätzen. Jedem Chefprogrammierer wird daraufhin ein Teil der Geschäftsdomäne zugeordnet. Entwicklungsmanager und Chefprogrammierer weisen den Programmierern die Klassen zu. Eingangskriterien Einteilung. Es existiert eine priorisierte Feature-Liste mit grober, domänenspezifischer Überprüfung Wie in den vorherigen zwei Phasen geschieht alles in Teamarbeit. Eine Überprüfung findet dadurch automatisch statt. Ausgangskriterien Die Planungs-Teams haben einen Projektplan erstellt die vom Entwicklungsmanager und dem Chefarchitekten abgesegnet werden müssen. Der Projektplan enthält Fertigstellungsdaten für alle Features, Featuresets und Hauptfeaturesets. Jeder Geschäftsdomäne ist ein Chefprogrammierer zugeordnet und jeder Klasse ein Programmierer. (4) Entwurf je Feature Die eigentliche Entwicklung spielt sich in dieser und der nächsten Phase ab. Die Chefprogrammierer haben die Aufgabe, gemäß dem Projektplan, ein Feature umzusetzen. Sie bilden hierfür mit den betroffenen Klassenbesitzern, Entwurfs-Teams. Dabei wird das Gesamtmodell weiter verfeinert und Sequenzdiagramme werden erstellt. Der Chefprogrammierer ist hierbei für die Qualität und die Stimmigkeit mit dem Gesamtmodell verantwortlich. Um das sicherzustellen, werden die Ergebnisse in einer Designinspektion vorgestellt. Aus dem Gesamtmodell können jetzt bereits Objekt-Stubs automatisch generiert werden. Klassen müssen in diesem Schritt von den Klassenbesitzern dokumentiert werden. Bei Unklarheiten können hier wieder die Domänenexperten hinzugezogen werden. 15

Agile Softwareentwicklung. Yelve Yakut

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

Mehr

SCRUM. Legalisierung der Hackerei? GI Regionalgruppe Dortmund 07.12.2009 Dipl.-Inform. (FH) Dirk Prüter. Dirk.Prueter@gmx.de

SCRUM. Legalisierung der Hackerei? GI Regionalgruppe Dortmund 07.12.2009 Dipl.-Inform. (FH) Dirk Prüter. Dirk.Prueter@gmx.de SCRUM Legalisierung der Hackerei? GI Regionalgruppe Dortmund 07.12.2009 Dipl.-Inform. (FH) Dirk Prüter Dirk.Prueter@gmx.de Überblick Was ist SCRUM Wie funktioniert SCRUM Warum lohnt es sich, SCRUM anzuwenden

Mehr

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

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

Mehr

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

Software Engineering. 4. Methodologien. Franz-Josef Elmer, Universität Basel, HS 2014

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

Mehr

Agile 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

myscrum Scrum in der Praxis Markus Schramm compeople AG Frankfurt

myscrum Scrum in der Praxis Markus Schramm compeople AG Frankfurt myscrum Scrum in der Praxis Markus Schramm compeople AG Frankfurt Überblick Agilität und Scrum Grundlagen der agilen Softwareentwicklung Rahmenbedingungen bei der Einführung eines agilen Projektvorgehens

Mehr

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

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

Feature Driven Development

Feature Driven Development Driven Development Die andere agile Methode Dipl.-Inform. Henning Wolf henning.wolf@it-agile.de Überblick Warum mit FDD beschäftigen? Woher kommt FDD? Was ist FDD? 5 (Teil-)Prozesse Rollenmodell Vorteile

Mehr

SCRUM. Scrum in der Software Entwicklung. von Ernst Fastl

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

Mehr

Agile Softwareentwicklung mit SCRUM

Agile Softwareentwicklung mit SCRUM Agile Softwareentwicklung mit SCRUM 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

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

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

Grundlegende Veränderungen in der Software-Dokumentation durch agile Entwicklung?

Grundlegende Veränderungen in der Software-Dokumentation durch agile Entwicklung? Grundlegende Veränderungen in der Software-Dokumentation durch agile Entwicklung? Marlis Friedl Christina Wirth Comet Computer GmbH tekom-jahrestagung 2010 5. November, UA 17 Überblick Die agile Software-Entwicklung

Mehr

Referat Extreme Programming. Von Irina Gimpeliovskaja und Susanne Richter

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

Mehr

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

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

Wasserfall, «Death March», Scrum und agile Methoden. 08. Dezember 2011 Embedded Software Engineering Kongress Urs Böhm

Wasserfall, «Death March», Scrum und agile Methoden. 08. Dezember 2011 Embedded Software Engineering Kongress Urs Böhm Wasserfall, «Death March», Scrum und agile Methoden 08. Dezember 2011 Embedded Software Engineering Kongress Urs Böhm Übersicht Warum Projektmanagement? Gängige SW Entwicklungsprozesse Wasserfall V-Modell

Mehr

Agile Entwicklung nach Scrum

Agile Entwicklung nach Scrum comsolit AG Hauptstrasse 78 CH-8280 Kreuzlingen Tel. +41 71 222 17 06 Fax +41 71 222 17 80 info@comsolit.com www.comsolit.com Agile Entwicklung nach Scrum Seite 1 / 6 Scrum V 1.0 1. Wieso Scrum Die Entwicklung

Mehr

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

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

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

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

Einleitung. Was ist das Wesen von Scrum? Die Ursprünge dieses Buches

Einleitung. Was ist das Wesen von Scrum? Die Ursprünge dieses Buches Dieses Buch beschreibt das Wesen von Scrum die Dinge, die Sie wissen müssen, wenn Sie Scrum erfolgreich einsetzen wollen, um innovative Produkte und Dienstleistungen bereitzustellen. Was ist das Wesen

Mehr

Agile Software Development with Scrum

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

Mehr

Extreme Programming: Überblick

Extreme Programming: Überblick Extreme Programming: Überblick Stefan Diener / Apr 18, 2007 / Page 1 Prinzipien Rollen Planung Implementierung Praktiken weitere Vorgehensweisen Grenzen Inhalt Stefan Diener / Apr 18, 2007 / Page 2 Prinzipien

Mehr

Empirische Evidenz von agilen Methoden. Seminar in Software Engineering Wintersemester 03/04

Empirische Evidenz von agilen Methoden. Seminar in Software Engineering Wintersemester 03/04 Empirische Evidenz von agilen Methoden Seminar in Software Engineering Wintersemester 03/04 Agenda Einleitung Bedeutung von agil Kurzübesicht agiler Methoden Überprüfung des (agilen) Erfolges Ausgewählte

Mehr

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

XP, Scrum, Crystal, FDD:

XP, Scrum, Crystal, FDD: XP, Scrum, Crystal, FDD: Welche agile Methode passt zu uns? Henning Wolf Christoph Kemp Was ist Agilität? Teil 1: Das agile Manifest We are uncovering better ways of developing software by doing it and

Mehr

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

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

Extreme Programming. Referat von Viktoria Schwarzhaupt und Andrea Schuhmann

Extreme Programming. Referat von Viktoria Schwarzhaupt und Andrea Schuhmann Extreme Programming Referat von Viktoria Schwarzhaupt und Andrea Schuhmann 1. Was ist XP - Prozessmodell für die objektorientierte Softwareentwicklung - leichter Softwareentwicklungsprozess Analyse Design

Mehr

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

- 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

Projektmanagement. Projektmanagement

Projektmanagement. Projektmanagement Projektmanagement Dipl.-Ing. Oliver Lietz Was ist ein Projekt? Projektmanagement Eindeutiges Ziel Individuell (einmalig) Begrenzt (Anfang und Ende) Komplex (keine Routineaufgabe) Warum Projektmanagement

Mehr

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

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

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

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

Scrum. Eine Einführung

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

Mehr

Software Engineering (SE) 2) Phasenübergreifende Verfahren

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

Mehr

Agile 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

Lieferung 4.3 Entwicklungsprozess für mobile Anwendungen

Lieferung 4.3 Entwicklungsprozess für mobile Anwendungen Lieferung 4.3 Entwicklungsprozess für mobile Anwendungen für das BMBF-Projekt Modellgetriebene agile Entwicklung für mobile Anwendungen (ModAgile Mobile) Arbeitspaket Arbeitspaketleitung Förderkennzeichen

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

Agile Softwareentwicklung mit Scrum

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

Mehr

Informationswirtschaft II Rational Unified Process (RUP)

Informationswirtschaft II Rational Unified Process (RUP) Informationswirtschaft II Rational Unified Process (RUP) Wolfgang H. Janko, Michael Hahsler und Stefan Koch Inhalt Historische Entwicklung Kennzeichen von RUP Lebenszyklus und Phasen Arbeitsabläufe Das

Mehr

Informationswirtschaft II

Informationswirtschaft II Rational Unified Process (RUP) Informationswirtschaft II Wolfgang H. Janko, Michael Hahsler und Stefan Koch Seite 1 Inhalt Historische Entwicklung Kennzeichen von RUP Lebenszyklus und Phasen Arbeitsabläufe

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

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

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

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

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

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

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

Einführung in die Informatik

Einführung in die Informatik Einführung in die Informatik Softwareentwicklung Probleme bei großer Software Life-Cycle-Modelle Teilphasen eines Software-Projekts Methoden und Werkzeuge 01101101 01011001 11010011 10011000 00000011 00011100

Mehr

Das Who s Who der agilen Methoden Golo Roden

Das Who s Who der agilen Methoden Golo Roden Das Who s Who der agilen Methoden Golo Roden www.goloroden.de www.des-eisbaeren-blog.de Über mich > Wissensvermittler und Technologieberater >.NET, Codequalität und agile Methoden > MVP für C#, zweifacher

Mehr

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

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

Mehr

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

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

Mehr

Copyright [2007] Verlag des IUK Instituts Dortmund. http://www.iuk.com/iuk/iuk_start.htm

Copyright [2007] Verlag des IUK Instituts Dortmund. http://www.iuk.com/iuk/iuk_start.htm Electronic version of an article published in Fahney, R.; Herrmann, A.; Weißbach, R. (Hrsg): Anforderungsbasiertes Projektmanagement. Beiträge zum Workshop Fulda 14./15.06.2007. Erschienen in der Reihe

Mehr

Ganzheitliches IT-Projektmanagement

Ganzheitliches IT-Projektmanagement Ganzheitliches IT-Projektmanagement Kapitel 2 nach dem Buch: Ruf, Walter; Fittkau, Thomas: "Ganzheitliches IT-Projektmanagement" Wissen - Praxis - Anwendungen R. Oldenbourg Verlag München - Wien 2008;

Mehr

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

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

Mehr

Agile Softwareprozess-Modelle

Agile Softwareprozess-Modelle Agile Softwareprozess-Modelle Steffen Pingel Regionale Fachgruppe IT-Projektmanagement 2003-07-03 Beweglich, Lebhaft, Wendig Was bedeutet Agil? Andere Bezeichnung: Leichtgewichtiger Prozess Manifesto for

Mehr

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme Tillmann Schall, anaptecs GmbH : Agenda Grundlagen modellgetriebener Entwicklungsprozesse Schritte zur Einführung Erfahrungen

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

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

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

Agiles Projektmanagement mit Scrum. Name: Eric Dreyer

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

Mehr

extreme Programming (XP)

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

Mehr

Einführung in die Softwaretechnik 9. Softwareprozesse

Einführung in die Softwaretechnik 9. Softwareprozesse 9. Softwareprozesse Klaus Ostermann (Mit Folien von Christian Kästner, Gabriele Taentzer und Wolfgang Hesse) 1 Agenda Wie kommt man vom Kundenwunsch zur fertigen Software? Wie strukturiert man ein Softwareprojekt?

Mehr

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

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

Mehr

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

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

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

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

1 Agile Softwareentwicklung aus Auftraggebersicht *

1 Agile Softwareentwicklung aus Auftraggebersicht * 1 Agile Softwareentwicklung aus Auftraggebersicht * Wichtig Unwichtig Egal? Prof. Dr. Helmut Balzert»Didaktik ist unsere Stärke«Folien zum Vortrag»Agile Softwareentwicklung aus Auftraggebersicht«Treffpunkt@IT

Mehr

3. Vorgehensmethoden/Prozessmodelle

3. Vorgehensmethoden/Prozessmodelle 3. Vorgehensmethoden/Prozessmodelle Vorgehensmethode/Prozessmodell: Ablauforganisation des Projektes für eine effektive und zielgerichtete Softwareentwicklung Wasserfallmodell Spiralmodell Agiles Vorgehen

Mehr

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

Leichtgewichtige Traceability im agilen Entwicklungsprozess am Beispiel von Scrum

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

Mehr

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung Block R (Rahmen): SE Aktivitäten 21.10.04 1 Vorlesung Methoden des Software Engineering Block R Rahmen Aktivitäten der Software-Entwicklung Martin Wirsing Einheit R.2, 21.10.2004 Block R (Rahmen): SE Aktivitäten

Mehr

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

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering mit Übungen Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering 2 Organisation Ort: Seminarraum 05.002, Spiegelgasse 5 Ablauf: 15:15 Vorlesung Prüfung: Schriftlich,

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

HWR-Chat Ein Chat für Studenten, Dozenten und interne Mitarbeiter der Hochschule für Wirtschaft und Recht

HWR-Chat Ein Chat für Studenten, Dozenten und interne Mitarbeiter der Hochschule für Wirtschaft und Recht Christian Gebauer, Sebastian Große, Benjamin Pfeiffer, Nico Smeenk, Jonathan Wiens Im Auftrag von Frau Prof. Dr. Dagmar Monett-Díaz HWR-Chat Ein Chat für Studenten, Dozenten und interne Mitarbeiter der

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

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

Klassisches Projektmanagement und agil

Klassisches Projektmanagement und agil Klassisches Projektmanagement und agil (K)ein Widerspruch!? OPITZ CONSULTING GmbH 2011 Seite 1 Klassisches Projektmanagement und agil (K)ein Widerspruch!? Dr. Andreas Wagener, Project Manager OPITZ CONSULTING

Mehr

Welche agilen Prozesse führen zum Ziel?

Welche agilen Prozesse führen zum Ziel? Welche agilen Prozesse führen zum Ziel? Andreas Lechner, hotel.de AG Dr. Florian Irmert, hotel.de AG 24.10.2012 PM Forum Nürnberg Seite 1 Andreas Lechner Jahrgang 1974 Studium der Informatik mit Nebenfach

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

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

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

Scrum. Golo Roden. www.goloroden.de www.des-eisbaeren-blog.de Scrum Golo Roden www.goloroden.de www.des-eisbaeren-blog.de Über mich > Wissensvermittler und Technologieberater >.NET, Codequalität und agile Methoden > MVP für C#, zweifacher MCP und CCD > Autor, Sprecher

Mehr

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

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

Mehr

Internet Briefing Agile SW-Entwicklung

Internet Briefing Agile SW-Entwicklung 1 www.namics.com Internet Briefing Agile SW-Entwicklung 6. Februar 2007 Peter Stevens, Principal Consultant Bern, Frankfurt, Hamburg, München, St. Gallen, Zug, Zürich Agenda 2 www.namics.com 3 www.namics.com

Mehr

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I)

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Historisch Kulturelle Informationsverarbeitung Hauptseminar: KLIPS 2.0 Dozent: Prof. Dr. Thaller Referent:

Mehr

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

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

Mehr

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