Iterative Prozessmodelle/SCRUM Marcus Hörger Seminar Iterative Prozessmodelle/SCRUM 14. Dezember 2010

Größe: px
Ab Seite anzeigen:

Download "Iterative Prozessmodelle/SCRUM Marcus Hörger Seminar Iterative Prozessmodelle/SCRUM 14. Dezember 2010"

Transkript

1 Iterative Prozessmodelle/SCRUM Marcus Hörger Seminar Iterative Prozessmodelle/SCRUM 14. Dezember Zusammenfassung - In dieser Arbeit wird zunächst der Begriff des Prozesses erläutert, und anhand des Software- Entwicklungsprozesses vorgestellt. Anschließend folgt eine Einführung in den Bereich der Prozessmodelle, wobei die linearen Prozessmodelle anhand des Phasenmodells erläutert werden. Bei den iterativen Prozessmodellen wird SCRUM ausgeführt. Es folgt eine kurze Einführung in das Risikomanagement anhand des Risikomamangement-Modells, bevor schließlich der Bezug zum Studienprojekt LaVida hergestellt wird U I. EINLEITUNG m zu verstehen, was ein Prozessmodell ist, wie es definiert wird, wozu man es in der Softwareentwicklung benötigt, welches Konsequenzen dadurch in den Entwicklung entstehen, muss man sich zunächst den Begriff des Prozesses vor Augen führen. Das Institute of Electrical and Electronics Engineers (IEEE) definiert den Prozess als A sequence of steps performed for a given purpose; for example, the software development process. (IEEE Standard) also eine Folge von Schritten, die für einen bestimmen Zweck durchgeführt werden. Im Folgenden wird der in der Softwareentwicklung wichtigste Prozess betrachtet, der Software-Entwicklungsprozess. A. Software-Entwicklungsprozess Die Grundlage aller Prozessmodelle ist der Software- Entwicklungsprozess. Er dient als Vorlage für die Aktivitäten, welche in den einzelnen Prozessmodellen definiert werden. Der Software-Entwicklungsprozess ist dabei definiert als Der Software-Entwicklungsprozess bestimmt also die einzelnen Schritte der Softwareentwicklung, von den Benutzerwünschen, bis hin zum fertigen Produkt. B. Prozessmodelle Der Software-Entwicklungsprozess ist die Grundlage für die Durchführung von Projekten. Um diesen Prozess in seiner Komplexität beherrschbar zu machen, bedient man sich verschiedener Prozessmodelle. Sie stellen eine Beschreibung dieses Prozesses als präskriptives Modell für die Durchführung der Projekte dar. Ein Prozessmodell beschreibt also das Vorgehen zur Organisation und Durchführung des Software-Entwicklungsprozess. Der Inhalt eines Prozessmodells besteht dabei zunächst aus den durchzuführenden Aktivitäten und der Definition der daraus entstehenden Teilprodukte. Gleichzeitig wird die Reihenfolge und Abhängigkeiten dieser Aktivitäten definiert. Prozessmodelle erlauben es, die Planung für jedes Projekt nicht von Grund auf neu durchführen zu müssen, sondern Planungen von der Stange zu verwenden. So lässt sich für jeden Projekttyp das passende Prozessmodell finden. Gleichzeitig können die Methoden der Softwareentwicklung standarisiert, und in das Prozessmodell mit aufgenommen werden. Ein weiterer Aspekt der Prozessmodelle und spezielle der iterativen Prozessmodelle ist die stetige Weiterentwicklungsmöglichkeiten der Modelle. So können Erfahrungen aus früheren Projekten in das Prozessmodell einfließen und dabei helfen, es zu verbessern und mögliche Schwachstellen zu erkennen, um diese in zukünftigen Projekten zu vermeiden. The process by which user needs are translated into a software product. The process involves translating user needs into software requirements, transforming the software requirements into design, implementing the design into code, testing the code, and sometimes, installing and checking out the software for operational use (IEEE Standard) Abb.: Software-Entwicklungsprozess

2 II.LINEARE PROZESSMODELLE Lineare Prozessmodelle weisen, im Gegensatz zu iterativen Prozessmodellen, ein streng sequenzielles Vorgehen vor. Dabei wird die Reihenfolge der Aktivitäten durch das Prozessmodell fest vorgegeben. Die Dokumentation ist in linearen Prozessmodellen durch das Prozessmodell definiert. Das bedeutet, es wird genau vorgegeben, welche Dokumente während des Projekts entstehen. Dadurch ist die Anpassung des Prozessmodells and das Projekt (Tayloring) nur im geringen Maße möglich. Sollte ein Prozessmodell für einen bestimmten Projekttyp ungeeignet sein, bleibt nur die Möglichkeit ein anderes, passenderes Prozessmodell zu wählen. Man spricht bei linaren Prozessmodellen auch von aktivitäten-orientierten Prozessmodellen, da die genaue Durchführung der durch das Prozessmodell vorgegebenen Aktivitäten im Mittelpunkt steht. A. Das Phasenmodell Abb.: Phasenmodell 2 freigegeben. Anschließend wird das geänderte Dokument erneut nach den Kriterien geprüft, welche für das Dokument festgelegt wurden. Da eine solche Fehlerkorrektur einen großen Mehraufwand darstellt, ist es in einigen Fällen ratsam, den Fehler hinzunehmen und zu versuchen, dessen Auswirkungen zu minimieren. Durch die Einteilung des Projekts in Phasen und Meilensteine, kann das Projekt zu Beginn relativ präzise geplant und organisiert werden. Budget und Personalbedarf stehen dann schon nach der Planungsphase fest. Allerdings sind die Anforderungen selten schon zu Beginn des Projekts vollständig bekannt. Während der Entwicklung ändert der Kunde oft seine Anforderungen, es kommen neue hinzu, oder bereits erhobene Anforderungen fallen wieder weg. In linearen Prozessmodellen, und speziell im Phasenmodell, ist es nur mit erheblichem Aufwand möglich, während der Entwicklung grundlegende Änderungen der Anforderungen zu realisieren. Ein weiterer Nachteil linearer Prozessmodelle ist die Tatsache, dass sich Fehler häufig erst in späteren Phasen des Projekts bemerkbar machen, häufig mit großen Auswirkungen auf bereits entstandene Dokumente. Korrekturen erforden dadurch einen deutlichen Mehraufwand. Dies hat zur Folge, dass Risiken vertärkt gegen Projektende auftreten ( Big Bang ). Aus diesen Gründen findet man heute in der Praxis häufig iterative Prozessmodelle vor. Ein typisches lineares Prozessmodell ist das Phasenmodell. In ihm werden die einzelnen Schritte des Software-Entwicklungsprozesses in Phasen eingeteilt. Zwei aufeinanderfolge Phasen werden dabei von Meilensteinen getrennt. Dadurch überlappen die einzelnen Phasen nicht und werden streng sequentiell abgearbeitet. Dabei ist durch den Meilenstein genau festgelegt, wann die eine Phase endet, und die nächste Phase beginnt. Es wird daher für jeden Meilenstein genau definiert III. ITERATIVE PROZESSMODELLE Bei iterativen Prozessmodellen verläuft die Entwicklung nicht in linearen, sequentiellen Phasen, sondern in mehreren geplanten Iterationsschritten. Ein Iterationsschritt durchläuft dabei die Tätigkeiten 1. Welche Ergebnise (Dokumente) vorliegen müssen 2. Wer nach welchen Kriterien welche Prüfung vornimmt 3. wer entscheidet, ob der Meilenstein erreicht ist. Erst wenn alle für den Meilenstein festgeschriebenen Dokumente vorliegen und geprüft wurden, ist ein Meilenstein erreicht. Dadurch wird sichergestellt, dass alle während des Projekts entstehenden Dokumente den Qualitätsanforderungen entsprechen. Da jedoch keine Prüfung Fehler komplett ausschließen kann, ist es unvermeidbar, bereits geprüfte und freigegebene Dokumente zu korrigieren, um den Fehler zu beseitigen. Dies geschieht allerdings unter Berücksichtigung des Budgets und der akutellen Phase. Änderungen werden zunächst untersucht und anschließend durch den Projektleiter Abb.: Iteration Jeder Iterationsschritt mündet dabei in einem Release, einem überabeiteten, verbesserten und erweiterten System, welches in seiner Funktionalität gegenüber dem vorhergehenden Release verfeinert wurde. Jedes dieser Releases ist voll funktionsfähig. Änderungen, die während der Entwicklung des Projekts aufkommen, werden im nächsten Iterationsschritt vorgenommen, womit es sehr einfach ist, auf die Änderungen zu reagieren.

3 Gleichzeitig fließen die Erfahrungswere einer Iteration in den nächsten Iterationsschritt mit ein. Es findet also eine stetige Verbesserung des Prozesses statt. 3 Die folgenden Rollen, Artefakte und Methoden von SCRUM stellen eine Implementierung dieser Grundsätze und Annahmen dar. Sie sind keinesfalls in dieser Form vorgegeben, sondern lassen sich an das Projekt anpassen. A. Rollen in SCRUM 1) Product Owner Abb.: Iterationsprozess Beispiele solcher iterativer Prozessmodelle sind das in jüngster Zeit populär gewordene extreme Programming, das teiliterative Feature-Driven-Development und das hier vorgestellte SCRUM. IV. SCRUM SCRUM (engl. für Gedränge) ist ein Prozessmodell, welches von Ken Schwaber, Jeff Sutherland und Mike Beedle entwickelt wurde, und erstmals in dem Buch Wicked Problems, Righteous Solutions (1991) Erwähnung fand. Bevor sich SCRUM in Softwareentwicklungsprojekten etabliert hat, wurde das Prozessmodell zunächst von den beiden Professoren Hirotaka Takeuchi und Ikujirō Nonaka; beides bedeutende Vertreter des Wissensmanagements; in ihrem Werk The New Product Development Game als Produktentwicklungsmethode eingeführt. Im Mittelpunkt von SCRUM steht die Philosophie der ständigen Weiterentwicklung und Verbesserung von Prozessen, Methoden und Mitarbeitern, um stets höchste Qualität bei niedrigsten Kosten zu erreichen. SCRUM ist ein Prozessmodell, welches durch seine Methoden diese Weiterentwicklung aller Entwicklungsbereiche fördert und fordert. Dabei erfüllt SCRUM stehts das von Ken Schwaber und Jeff Sutherland formulierte Agile Manifest: 1. Individuen und Interaktionen sind wichtiger als Prozesse und Wekzeuge 2. Funktionierende Programme sind wichtiger als ausführliche Dokumentation 3. Die stetige Abstimmung mit dem Kunden ist wichtiger als die ursprüngliche Leistungsbeschreibung in Verträgen 4. Der Mut und die Offenheit stehen über dem Befolgen eines festgelegten Plans Eine der im Agilen Manifest festgelegten Richtlinien besagt, dass die ständige Einbeziehung des Kunden in die Entwicklung des Projekts ausschlaggebend für dessen Erfolg ist. Diese Einbeziehung des Kunden wird in SCRUM durch die Rolle des Product Owner realisiert. Der Product Owner vertritt während der gesamten Projektdauer den Kunden, und hält ihn stets auf dem Laufenden. Der Product Owner stellt also eine Art Schnittstelle zwischen dem Entwicklungsteam und dem Kunden dar. Dabei legt der Product Owner die gemeinsamen Ziele fest, die das Team mit ihm erreichen muss. Er priorisiert die Elemente des Product Backlogs anhand der Prioritäten des Kunden. Dabei ist der Product Owner NICHT der Vorgesetzte des Teams. Er besitzt keine Managementrechte und greift nicht in die Teamorganisation ein. 2) SCRUM-Master Der SCRUM-Master hat die Aufgabe, den SCRUM Prozess zu überwachen, zu unterstützen und dessen Produktivität zu gewährleisten. Er sorgt dafür, dass keine störenden Einflüsse von aussen (z.b. Abwerbung der Mitarbeiter durch andere Projektteams; Bürokratische Hürden des Managements) auf die Entwicklung einwirken und diese negativ beeinflussen. Er hält den Entwicklern in dieser Hinsicht den Rücken frei und sorgt dafür, dass sich diese möglichst ungestört dem Projekt widmen können. Gleichzeitig macht der SCRUM-Master Vorschläge zur Verbesserung des SCRUM-Prozesses und versucht diese gemeinsam mit dem Product Owner und dem Entwicklungsteam umzusetzen. Er nimmt dabei keinen Einfluss auf die eigentliche Softwareentwicklung, unterstützt das Entwicklungsteam aber bei der ordnungsgemäßen Durchführung der Entwicklung. 3) Team Das eigentliche Entwicklungsteam, welches die im Sprint- Backlog definierten Aufgaben im nächsten Sprint realisiert. Es ist in der Regel interdisziplinär (Architekten, Entwickler, Tester, etc.) zusammengesetzt und besteht idealerweise aus fünf bis neun Personen, um eine effiziente Kommunikation innerhalb des Teams aufrecht zu erhalten. Größere Teams sollten daher in mehrere kleinere Teams aufgeteilt werden. Das Team organisiert sich selbst und verteilt die Aufgaben des Sprint-Backlogs autonom an die einzelnen Teammitglieder. Daher wird vom Team erwartet, intuitiv für jede Aufgabe eine optimale innere Organisationsstruktur zu bilden. Der SCRUM-Master achtet dabei darauf, dass der

4 Product-Owner nicht in diesen Selbstorganisationsprozess eingreift. B. Artefakte in SCRUM 1) Product-Backlog Der Product-Backlog enthält alle funktionalen Anforderungen des Kunden in Form von Features. Der Kunde ist stets über den Inhalt informiert und hat idealerweise lesenden Zugriff auf das Dokument. Dadurch werden Konflike zwischen den Anforderungen des Kunden und dem fertigen Produkt vermieden. Um noch besser auf die Wünsche des Kunden einzugehen, werden die Elemente des Product-Backlogs vom Product-Owner priorisiert. Auf Elemente mit hoher Priorität wird während der Entwicklung ein besonders großes Augenmerk gelegt. Da während der Entwicklung häufig Änderungen bezüglich der Funktionalität des Projekts auftreten, können Elemente zwischen den Sprints neu priorisiert, hinzugefügt und entfernt werden. Es ist somit gewährleistet, dass geänderte Anforderungen des Kunden ohne große Hürden realisiert werden können. 2) Selected-Backlog Der Selected-Backlog wird vor jedem Sprint vom Product- Owner zusammen mit dem Team gepflegt. Er enthält jene Einträge des Product-Backlogs, welche im nächsten Sprint realisiert werden sollen. Der Umfang des Selected-Backlogs richtet sich dabei nach der Sprintlänge und der Kapazität des Teams. Der Selected-Backlog dient als Grundlage für die Abnahme der im nächsten Sprint inkrementell verbesserten Software. 3) Sprint-Backlog Um die Einträge des Selected-Backlogs realisieren zu können, werden diese in Aufgaben zerlegt und im Sprint- Backlog erfasst. Dabei sollte das Erledigen einer Aufgabe nicht länger als einen Tag benötigen. Komplexere Aufgaben werden daher in mehrere kleinere Aufgaben zerlegt. Neben den Aufgaben, die vom Team im nächsten Sprint realisiert werden sollen, enthält der Sprint-Backlog die Aufgabenverteilung und die Verantworlichkeiten für die einzelnen Aufgaben. So ist stets nachvollziehbar, welches Teammitglied welche Aufgabe zu erledigen hat. 4) Burndown Chart Das Burndown-Chart ist eine grafische Repräsentation des noch zu erbringenden Aufwands innerhalb des Sprints. Es wird täglich aktualisiert. Dabei wird der Restaufwand in einer t-a-achse aufgetragen. Anhand dieser entstehenden Kurve kann durch die negative Steigung schon früh beurteilt werden, ob der Aufwand innerhalb des Sprints zu bewältigen ist. Das Burndown-Chart wird dokumentiert und in der Retroperspektive analysiert. 5) Impediment-Backlog Im Impediment-Backlog werden alle Hindernisse und Probleme aufgerlistet, welche die Arbeit an dem Projekt behindern. Diese Probleme, seien sie organisatorischer, technischer oder personeller Natur, sind meist vielfältig. Es ist die Aufgabe des SCRUM-Masters diese Probleme zu erkennen und gemeinsam mit dem Team auszuräumen. C. SCRUM-Zyklus 1) Sprint-Planugsmeetings Die Sprint-Planungsmeetings sind zwei Meetings, welche vor jedem Sprint abgehalten werden. Im ersten Meeting präsentiert der Product-Owner dem Team die höchstpriorisierten Einträge des Product-Backlogs. Anschließend übernimmt der Product-Owner in Absprache mit dem Team die Elemente in den Selected-Backlog, welche im nächsten Sprint realisiert werden sollen. Im zweiten Meeting werden diese Elemente in Aufgaben zerlegt und an die Teammitglieder verteilt. Das Ergebnis des zweiten Planungsmeetings ist der Sprint-Backlog. 2) Sprint Der Sprint ist das zentrale Element des Scrum-Zyklus. Er dauert meist zwischen einer und vier Wochen. Während des Sprints werden die Elemente des Sprint-Backlogs von den einzelnen Teammitglieder abgearbeitet. Dabei organisiert sich das Team selbst, ohne Einflüsse durch den SCRUM- Master oder den Product-Owner. Das Ziel des Sprints ist eine inkrementell verbesserte, lauffähige und getestete Software. Das bedeutet, dass innerhalb des Sprints für jedes Element des Selected-Backlogs der Software- Entwicklungsprozess, von der Analyse, bis zum Test, durchlaufen wird. 3) Daily SCRUM Der Daily-SCRUM ist ein kurzes, 15 minütiges Meeting, welches täglich vor Arbeitsbeginn stattfindet. In ihm berichten Teammitglieder, was sie seit dem letzten Daily- SCRUM geleistet haben und was sie bis zum nächsten Daily- SCRUM erreichen wollen. Dabei berichten sie auch von eventuell aufgetretenen Problemen, welche in den Impediment-Backlog aufgenommen werden. Auch wenn der Daily-SCRUM grundsätzlich ein offenes Meeting ist, haben lediglich der SCRUM-Master und das Team eigenständiges Rederecht. 4

5 4) Review D. Zusammenfassung 5 Um eine möglichst hohe Qualität der während des Sprints enstehenden Dokumente zu erreichen, werden diese; wie in vielen anderen Prozessmodellen ebenfalls; einem Review unterzogen. Das Review wird vom Team zusammen mit dem Product-Owner abgehalten. Dabei prüft der Product-Owner, ob das Ergebnis des Sprints den Vorgaben des Selected- Backlogs entspricht. Sollte dies nicht der Fall sein, so werden Änderungen in den Product-Backlog aufgenommen, wo sie neu priorisiert werden. 5) Retroperspective SCRUM basiert auf einer Philosophie der ständigen Weiterentwicklung, nicht nur der Mitarbeiter und des Arbeitsprozesses, sondern auch des SCRUM-Prozesses an sich. Um dem gerecht zu werden, gibt es nach jedem Sprint eine Retroperspective, in der die vergangene Sprint Phase von allen in SCRUM beteiligten Personen betrachtet wird. Dabei werden wichtige Ereignisse notiert. Dadurch wird versucht, Verbesserungspotentiale für den SCRUM-Prozess zu finden und Misstände jeglicher Art aufzudecken. Verbesserungspotential, welches die Teamorganisation betrifft wird im Impediment-Backlog festgehalen, projektbezogenes Verbesserungspotential im Product- Backlog. SCRUM ist, wenn es richtig eingesetzt wird, ein mächtiges Prozessmodell, dass allen am Projekt beteiligten Personen hilft, sich stets weiterzuentwickeln um somit das bestmögliche Ergebnis zu erzielen. SCRUM hat in den letzten Jahren stark an Bedeutung gewonnen, was nicht zuletzt dem Umstand der besseren Kundennähe im Gegensatz zu anderen Prozessmodellen geschuldet ist. Allerdings ist SCRUM sowohl für unerfahrene, als auch für fest eingespielte Teams nicht leicht zu realisieren, da sich viele Methoden von SCRUM von anderen Prozessmodellen unterscheiden. Es benötigt daher etwas Zeit, um die Vorteile von SCRUM ausschöpfen zu können. Abb.: SCRUM-Zyklus

6 V. RISIKOMANAGEMENT B. Analyse 6 Die Wahl eines geeigneten Prozessmodells für die Projektdurchführung... Um diesen Risiken und deren Auswirkungen auf das Projekt möglichst zu minimieren, oder bestenfalls komplett auszuräumen betreibt man Risikomanagement. Dabei versteht man unter einem Risiko: In der Analysephase werden die zuvor identifizierten Risiken auf ihre Eintrittswahrscheinlichkeit und den Schaden, den sie bei Eintreten verursachen, bewertet. Dies erfolgt anhand einer dreiwertigen Skala. Ein Problem, das noch nicht eingetreten ist, aber wichtige Projektziele oder Projektergebnisse gefärdet, falls es eintritt. Ob es eintreten wird, kann nicht sicher vorraus gesagt werden. (Hindel et. al.) Die Ziele eines effektiven Risikomanagements bestehen zunächst in der Identifikation von Risiken. Ein Risiko, welches nicht bekannt ist, kann auch nicht gemanaged werden. Die identifizierten Risiken werden anschließend analysiert und quantifiziert, um daraus geeignete Gegenmaßnahmen zu entwerfen. Dieser Prozess des Risikomanagements wird durch das von Marvin J. Carr entworfene Risikomanagement-Modell beschrieben: Abb.: Risikobewertung Zunächst untersucht man die Eintrittswahrscheinlichkeit des Risikos und weist ihm einen Wert gemäß obiger Sakal zu. Hat beispielsweise die Untersuchung des Risikos r ergeben, dass es nicht überraschend wäre, dass das Risiko eintritt, so wird dem Risiko r der Wert 2 zugewiesen. Genauso verfährt man mit dem Schadenausmaß, wodurch das Risiko nun zwei Werte erhält. Diese Werte werden miteinander Multipliziert und in folgende Skala eingetragen: Abb.: Risikomanagement-Modell A. Identify In dieser Phase werden die Risiken, welche das Projekt behindern, oder gefärden, identifiziert, bevor diese eintreten. Um eine möglichst umfassende Liste von Risiken zu erhalten, müssen alle am Projekt beteiligten Experten zugezogen werden. Die Identifikation der Risiken findet meist in moderierten Workshops statt. Diese Identifikationsphase findet dabei nicht nur zu Beginn des Projekts statt, sondern ist ein fortlaufender Prozess, da Risiken oftmals erst während der Projektdurchführung auftreten (z.b. durch personelle Veränderungen). Abb.: Risikoskala Dadurch lassen sich Risiken nach ihrer Eintrittswahrscheinlichkeit und dem verursachten Schadenausmaß quantifizieren. Risiken mit großen Werten müssen folglich stärker betrachtet werden als Risiken mit kleinen Werten.

7 C. Plan In dieser Phase des Risikomanagments werden für die zuvor identifizierten und quantifizierten Risiken Gegenmaßnahmen entwickelt. Dabei unterscheidet man 3 Arten von Maßnahmen. 1) Notfallmaßnahme Eine Notfallmaßnahme ist eine Gegenmaßnahme, sollte das Problem bereits eingetreten sein. 2) Präventivmaßnahme Die Präventivmaßnahme zield darauf, ein gewisses Risiko von vornherein zu vermeiden. Besteht beispielsweise das Risiko, dass ein fähiger Mitarbeiter während des Projekts abgeworben werden könnte, so bestünde eine Präventivmaßnahme darin, ein großzügiges Honorar für den Projektabschluss zu garantieren. 3) Risiko in Kauf nehmen und nichts unternehmen Hat ein Risiko während der Analyse einen sehr kleinen Risikowert erhalten, ist der Aufwand entsprechende Gegenmaßnahmen zu entwickeln unter Umständen größer, als der Nutzen, den man durch die Vermeidung des Risikos zieht. In diesem Fall nimmt man das Risiko in kauf, ohne Gegenmaßnahmen zu entwickeln. Wichtig bei der Entwicklung von Gegenmaßnahmen ist, dessen Konsequenzen zu betrachten. Oftmals bergen Maßnahmen, die gegen ein bestimmtes Risiko gerichtet sind, neue Risiken. Hier gilt abzuwägen, ob die Maßnahme dem Risikomanagement wirklich nützt, oder ob sie durch neue Risiken im Endeffekt eher schadet. Alle so entwickelten Gegegmaßnahmen werden im Projektplan festgehalten. D. Track In den seltensten Fällen bleiben Risiken und die zugehörigen Risikowerte während der gesamten Projektphase konstant. Daher ist eine stetige und fortlaufende überwachung der Risiken und deren Werte vonnäten. Diese Überwachung ist dabei Aufgabe des Projektmanagements. E. Control Nicht nur Risiken müssen fortlaufend überwacht werden, auch die entsprechenden Gegenmaßnahmen müssen kontrolliert werden, da sich Maßnahmen und dessen Auswirkungen ändern können. Hat beispielsweise eine Maßnahme zu Beginn des Projekts einen hohen Nutzen, kann dies sich im Verlauf des Projekts ins Gegenteil umkehren und eine Maßnahme würde dem Projekt eher Schaden. Es ist daher nötig, die Maßnahmen in regelmäßigen Abständen zu kontrollieren und bewerten und gegebenenfalls zu ändern. 7 Im Zentrum des Risikomanagement-Modells liegt der Communicate Begriff. Dies soll die Durchziehung durch alle Phasen des Risikomanagements verdeutlichen. Ohne funktionierende Kommunikation ist ein effektives Risikomanagement nicht möglich. Es muss möglich sein, zwischen den einzelnen Phasen des Risikomanagements Risiken austauschen zu können, um den Zusammenhalt des Modells zu gewährleisten. Gleichzeitig muss zwischen jeder Ebene des Projekts, vom Management bis zu den Entwicklern eine Kommunikation stattfinden, ohne die das Risikomanagement-Modell seinen Nutzen einbüßen würde. VI. BEZUG ZU LAVIDA Um zu entscheiden, welche Art von Prozessmodell für das Studienprojekt LaVida geeignet ist, müssen zunächst die Ausgangsbedingungen des Projekts betrachtet werden. Das Team besteht aus zwölf Studenten mit insgesamt geringer Berufserfahrung, woraus folgt, dass die Entwicklung anhand eines iterativen Prozessmodells für die meisten Teammitglieder neu ist. Daher würde es ein Risiko darstellen ein rein iteratives Prozessmodell für die Projektentwicklung zu wählen. Das Team wurde nur für dieses Studienprojekt zusammengestellt, was bedeutet, dass es sich hierbei um kein eingespieltes Team, welches bereits an mehreren Projekten gemeinsam gearbeitet hat, handelt. Die Teamgröße wird sich während des Projekts sehr wahrscheinlich nicht ändern, es werden also weder Teammitglieder durch andere Projektgruppen abgeworben, noch werden andere Entwickler hinzugezogen. Es existieren also insgesamt wenig personelle Risiken, was es einfacher macht, den einzelnen Teammitgleidern feste Rollen zuzuweisen. Die Teamstruktur ist zunächst nicht vorgegeben, wird aber vor Projektbeginn vereinbart. Durch die freie Wahl der Teamstruktur, werden der Wahl eines Prozessmodells diesbezüglich alle Freiheiten eingeräumt. Für das Projekt gilt, dass dessen Auslieferungsdatum bereits fest steht, der Zeitrahmen also sehr starr ist, was das Projekt gut planbar macht. Die Anforderungen stehen bereits vor Projektbeginn fest. Es wird diesbezürlich während des Projekts wenig Änderungen geben. Somit spielt die Notwendigkeit, optimal auf geänderte Anforderungen des Kunden reagieren zu müssen, eine eher geringe Rolle. Für die Realisierung der Anforderungen gibt es wenig Bestimmungen und große Freiräume. So werden weder die Architektur, noch die Entwicklungsumgebung und deren Programmiersprache vorgegeben. Weiterhin ist das Projekt an keinerlei Budgetbeschränkungen gebunden, wodurch das Team alle ihm zur Verfügung stehenden Arbeitsmittel optimal ausschöpfen kann. Ausgehend von diesen Grundannahmen wird hier für das Studienprojekt LaVida ein teiliteratives Prozessmodell vorgeschlagen.

8 8 Das Projekt wird dabei in zwei Phasen eingeteilt, der sequentiellen Phase und der teiliterativen Phase. In der sequentiellen Phase werden die wichtigsten Dokumente (Analyse, Spezifikation, Grobentwurf) in einer linearen Vorgehensweise entwickelt. Dabei wird jedes entstehende Dokument nach anerkannten Richtlinien geprüft und abgenommen. Anschließend kommt das Projekt in die iterative Phase, in der die Aktivitäten Feinentwurf, Codierung und Test iterativ durchgeführt werden. Es ist dabei stets möglich, von der iterativen Phase in die sequentielle Phase zurückzukehren. Dadurch wird gewährleistet, dass Fehler ohe großen Aufwand korrigiert werden können. Alle Änderungen, die dadurch an den in der iterativen Phase entstehenden Dokumente gemacht werden müssen, werden dann im nächsten Iterationsschritt durchgeführt. Dieses teiliterative Prozessmodell kombiniert die Vorteile beider Prozessmodellarten. Durch die Einteilung in Phasen kann das Projekt zu Beginn relativ präzise geplant werden. Der Aufwand, welcher bei linearen Prozessmodellen für die Fehlerkorrektur erbracht werden muss, fällt hier größtenteils weg. Gleichzeitig machen sich Risiken gleichmäßig während der gesamten Entwicklung bemerkbar, nicht erst gegen Ende des Projekts ( Big Bang ). Für das Team ist das teiliterative Modell einfacher zu realisieren, als ein rein iteratives Prozessmodell, da der große Organisatorische Aufwand, der ein iteratives Vorgehen nach sich zieht, auf die iterative Phase beschränkt wird. Dadurch sind die einzelnen Iterationen weniger komplex und können gut bewältigt werden. Desweiteren kann sich das Team in der sequentiellen Phase dank des gewohnten linearen Vorgehens auf die Qualität der kritischsten Dokumente konzentrieren. LITERATUR [1] Carr et al., Taxonimy-Based Risk Identification, Carnegie Mellon University, 1993, Juni, S. 3-5 [2] Lichter, Horst/Ludewig, Jochen, Software-Engineering Grundlagen, Menschen, Prozesse, Techniken., 1. Aufl, Heidelberg, dpunkt.verlag GmbH, 2007 [3] Szabo, Lazlo l., Iterative Softwareentwicklung in der mobilden Welt: Alternativen zu traditionellen Prozessmodellen, 2008, S. 1-3 [4] Wikipedia, Scrum, [5] Wirsing,Martin, Vorlesung Projektmanagement: Prozessmodelle, LMU München, Prozess.pdf

Agile Programmierung - Theorie II SCRUM

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

Mehr

SCRUM. Software Development Process

SCRUM. Software Development Process SCRUM Software Development Process WPW 07.08.2012 SCRUM Poster www.scrum-poster.de Was ist Scrum? Extrem Schlanker Prozess 3 Rollen 4 Artefakte Wenige Regeln Die Rollen Product Owner Der Product Owner

Mehr

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

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

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

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

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

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

Mehr

Agile 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

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

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

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

Agile Entwicklung nach Scrum

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

Mehr

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

AGILE SOFTWAREPROJEKTE IN REINFORM WAS BEDEUTET DAS RECHTLICH? RA Daniel Schätzle Berlin, 22. April 2015

AGILE SOFTWAREPROJEKTE IN REINFORM WAS BEDEUTET DAS RECHTLICH? RA Daniel Schätzle Berlin, 22. April 2015 AGILE SOFTWAREPROJEKTE IN REINFORM WAS BEDEUTET DAS RECHTLICH? RA Daniel Schätzle Berlin, 22. April 2015 Agiles Vorgehen 2 Agiles Vorgehen 3 WAS BEDEUTET AGIL Abstimmung über Ziel (nicht konkretes Entwicklungsergebnis)

Mehr

Agile 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

Seminar Softwareentwicklung in der Wissenschaft

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

Mehr

Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle. Windhoff Software Services GmbH www.wind-soft.

Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle. Windhoff Software Services GmbH www.wind-soft. Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle Folie 2 Agenda Projektmanagement: Ziele und Methoden Agile Methoden: Scrum Agile Methoden im BI Umfeld PM

Mehr

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

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

Mehr

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 Management Einführung in agiles Management

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

Mehr

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

Seminarausarbeitung AW1

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

Mehr

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

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

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

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

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

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

Informatik für Ingenieure (InfIng)

Informatik für Ingenieure (InfIng) Informatik für Ingenieure (InfIng) SW-Engineering 2 Doz. Dipl.-Ing. H. Hiller WS 2012/13 Entwicklung von Software Vorgehensweise Manche lieben es klassisch, machen lieben es agil Klassisches Vorgehen Agiles

Mehr

Requirements Engineering für die agile Softwareentwicklung

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

Mehr

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

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

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

Prozesse und Projekte

Prozesse und Projekte Universität Stuttgart 30.04.08 Prozesse und Projekte Planung unter schwierigen Randbedingungen Matthias Wetzel wetzelms@informatik.uni-stuttgart.de Abteilung Software Engineering 1 / 24 Agenda Inhalt der

Mehr

Agiles + traditionelles PM - ein unschlagbares Team?! www.pmcc-consulting.com

Agiles + traditionelles PM - ein unschlagbares Team?! www.pmcc-consulting.com Agiles + traditionelles PM - ein unschlagbares Team?! www.pmcc-consulting.com Vortrag PMI Chapter Frankfurt, Eschborn am 7. April 2015 00. Agenda Agenda 1. Projektmanagement 2. Probleme und Erkenntnisse

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

Seminar. Scrum. Author: Crina-Maria Iliadis Matrikel-Nr. 45482. Betreuender Professor: Roland Dietrich

Seminar. Scrum. Author: Crina-Maria Iliadis Matrikel-Nr. 45482. Betreuender Professor: Roland Dietrich Seminar Scrum Author: Crina-Maria Iliadis Matrikel-Nr. 45482 Betreuender Professor: Roland Dietrich 11. Januar 2015 Inhaltsverzeichnis 1 Einleitung 2 1.1 Motivation.............................. 2 1.2

Mehr

Agiles Projektmanagement mit Scrum

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

Mehr

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

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

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

Mehr

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

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

Der Business Analyst in der Rolle des agilen Product Owners

Der Business Analyst in der Rolle des agilen Product Owners Der Business Analyst in der Rolle des agilen Owners HOOD GmbH Susanne Mühlbauer Büro München Keltenring 7 82041 Oberhaching Germany Tel: 0049 89 4512 53 0 www.hood-group.com -1- Inhalte Agile Software

Mehr

Softwareentwicklung und Application Lifecycle Management als Geschäftsprozess

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

Mehr

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

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

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

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

Abgrenzung bzw. Kombination traditionelles und agiles Projektmanagement

Abgrenzung bzw. Kombination traditionelles und agiles Projektmanagement Abgrenzung bzw. Kombination traditionelles und agiles Projektmanagement Vortrag im Rahmen des IKT-Forums 2015 Salzburg-Urstein am 21. Mai 2015 www.organisationsgesta 00. Agenda Agenda 1. Projektmanagement

Mehr

Agiles Anforderungsmanagement mit SCRUM im regulierten Umfeld

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

Mehr

Teststrategie festlegen und Teststufen aufeinander abstimmen

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

Mehr

Wie unterstützt CMMI-DEV 1.3. agiles Projektvorgehen?

Wie unterstützt CMMI-DEV 1.3. agiles Projektvorgehen? Wie unterstützt CMMI-DEV 1.3 agiles Projektvorgehen? Bernhard Fischer Fischer Consulting GmbH Folie 1 Agenda SCRUM als Beispiel agilen Projektvorgehens Wir machen SCRUM, aber SCRUM und CMMI Zusammenfassung

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

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

Wie funktioniert agile Software-

Wie funktioniert agile Software- Wie funktioniert agile Software- Entwicklung mit SCRUM Zürich, 8. Mai 008 Jean-Pierre König, namics ag Software Engineer Bern, Frankfurt, Hamburg, München, St. Gallen, Zug, Zürich www.namics.com Agenda»

Mehr

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

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

Grundprinzipien der agilen Softwareentwicklung

Grundprinzipien der agilen Softwareentwicklung Grundprinzipien der agilen Softwareentwicklung Marie Claire Dzukou 38539 Natali Brozmann 40464 Wintersemester 14/15 1 Inhaltsverzeichnis 1 Agile Softwareentwicklung 3 2 Entstehung der agilen Softwareentwicklung

Mehr

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

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

Mehr

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

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

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

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

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

K N O W - H O W SCRUM. Abstract. 1 Einleitung. 2 Scrum die Projektrollen

K N O W - H O W SCRUM. Abstract. 1 Einleitung. 2 Scrum die Projektrollen K N O W - H O W SCRUM Prof. Dr. Eckhart Hanser, Duale Hochschule Baden-Württemberg (DHBW), D-79539 Lörrach Abstract Dieser Artikel beschäftigt sich mit der agilen Projektmanagement-Methode Scrum. Nach

Mehr

AGILER TESTMANAGER EIN OXYMORON?

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

Mehr

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

Checkliste für Scrum-Meetings

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

Mehr

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

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

Mehr

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

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

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

Mehr

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

2 Agiles Projektmanagement in der Softwareentwicklung

2 Agiles Projektmanagement in der Softwareentwicklung 2 Agiles Projektmanagement in der Softwareentwicklung Im folgenden Kapitel werden einleitend die zentralen Aspekte des agilen Projektmanagements erläutert (siehe Abschnitt 2.1). Ferner wird der fokussierte

Mehr

Abb.: Darstellung der Problemfelder der Heine GmbH

Abb.: Darstellung der Problemfelder der Heine GmbH Entwicklung eines SOLL-Konzeptes Kehl Olga 16.05.10 Wie aus der Ist-Analyse ersichtlich wurde, bedarf die Vorgehensweise bei der Abwicklung von Projekten an Verbesserung. Nach der durchgeführten Analyse

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

Praxisbericht und Demo-Projektabwicklung mit der ATLASSIAN Toolchain und Continuous Integration. Markus Stollenwerk, Noser Engineering AG

Praxisbericht und Demo-Projektabwicklung mit der ATLASSIAN Toolchain und Continuous Integration. Markus Stollenwerk, Noser Engineering AG Praxisbericht und Demo-Projektabwicklung mit der ATLASSIAN Toolchain und Continuous Integration Markus Stollenwerk, Noser Engineering AG Agile Softwareentwicklung Crash-Kurs Markus Stollenwerk, 27.9.2013

Mehr

Modellgetriebene agile BI-Vorgehensweise

Modellgetriebene agile BI-Vorgehensweise Modellgetriebene agile BI-Vorgehensweise Thomas Neuböck Konrad Linner 12.11.2013 Inhalt Anforderungen und Lösungsansatz Agile Vorgehensweise Orientierung nach Fachthemen Architekturrahmen Modellorientierung

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

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

AGILE-PRODUKTENTWICKLUNG AXEL SCHRÖDER & PARTNER UNTERNEHMENSBERATUNG AGILE-PRODUKTENTWICKLUNG DER RHYTHMUS FÜR MEHR F&E-EFFIZIENZ DER RHYTHMUS Klare Ziele, Timeboxing und schnelles Feedback. Höhere Produktivität und motivierte

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