Projektmanagement 2. Vorgehensmodelle Dozentenversion!!! Masterstudiengang Wiki: http://prof-ruf.de/wikina Login: ruf PW mediawiki Blog: http://prof-ruf.de/wpna2013 PW: wie immer Nordakademie https://moodle.nordakademie.de/ Login: walterruf PW: adminruf © Prof. Dr. Walter Ruf

2. Vorgehensmodelle in IT-Projekten 2.1 Grundlagen für Vorgehensmodelle 2.2 Sequentielle Vorgehensmodelle 2.3 Inkrementelles Vorgehensmodell 2.4 Iterative, inkrementelle Entwicklung 2.5 Agile Softwareentwicklung 2.5.1 Kennzeichen und Ziele der Agilität 2.5.2 Werte der agilen Softwareentwicklung 2.5.3 Die 12 Prinzipien des agilen Manifestes 2.5.4 Vergleich „klassisches PM“ vs „agiles PM“ 2.5.5 Überblick zu agilen Methoden 2.6 Ausgewählte agile Methoden 2.6.1 Exterme Programming (kurze Whlg.) 2.6.2 Scrum 2.6.3 Software-Kanban 2.6.4 Fazit © Prof. Dr. Walter Ruf

2. Vorgehensmodelle in IT-Projekten Lernziele von Kapitel 2 In diesem Kapitel wird die fundamentale Bedeutung von Vorgehensmodellen beschrieben. Der Leser lernt die Grundstrukturen kennen und kann später konkrete Vorgehensmodelle auf ein eigenes IT-Projekt hin anpassen. Zu allen Modellen werden die immanenten Vor- und Nachteile erkannt. Zusammengefasst: Das sollten Sie nach diesem Kapitel wissen: Was sind Vorgehensmodelle und woraus setzen sie sich zusammen? Wie wird ein sequentielles Vorgehensmodell gebildet? Welche Kennzeichen hat das Wasserfallmodell? Über welche Struktur verfügt ein inkrementelles Vorgehensmodell? Was verbirgt sich hinter einem iterativen, inkrementellen Vorgehensmodell? Sie können die Funktionsweise von agilen Methoden und hier speziell von Extreme Programming darstellen. Wie kann eine Softwareentwicklung nach dem V-Modell XT erfolgen? © Prof. Dr. Walter Ruf

2.1 Grundlagen für Vorgehensmodelle © Prof. Dr. Walter Ruf

2.2 Sequentielle Vorgehensmodelle © Prof. Dr. Walter Ruf

Kennzeichen der sequentiellen Vorgehensmodelle Am Ende einer Phase steht ein Phasenprodukt, das geprüft werden kann. Die Nachfolgephase wird gestartet, wenn die Vorgängerphase abgeschlossen ist. Die erstellten IT-Systeme können nach Abschluss der Entwicklung gegen die in der Spezifikation aufgestellten Anforderungen geprüft werden. © Prof. Dr. Walter Ruf

Wasserfallmodell © Prof. Dr. Walter Ruf

2.3 Inkrementelles Vorgehensmodell Die inkrementelle Softwareentwicklung ist dadurch gekennzeichnet, dass ein komplexes IT-System in sinnvolle, selbständig entwickelbare Teile, die nacheinander oder parallel erstellt werden, aufgeteilt wird. © Prof. Dr. Walter Ruf

2.3 Inkrementelles Vorgehensmodell © Prof. Dr. Walter Ruf

2.4 Iterative, inkrementelle Softwareentwicklung © Prof. Dr. Walter Ruf

2.5. Agile Softwareentwicklung agil [lat.], von großer Beweglichkeit; geistig wendig; schnell; flink Idee: Optimierung der Softwareentwicklung durch „leichtgewichtige“ (ligthtweight) Methoden 2001 Agiles Manifest 17 Berater und Entwickler treffen sich in Utah www.agilemanifesto.org Es wurden zentrale Werte und Prinzipien festgeschrieben, die bei einer agilen Softwareentwicklung zu beachten sind. © Prof. Dr. Walter Ruf

2.5.1 Kennzeichen und Ziele agiler Verfahren bauen auf dem Grundmodell der inkrementellen Entwicklung auf während der Entwicklung kommt es immer wieder zu Modifikationen Modifikationen und die Auslieferung lauffähiger Softwareversionen laufen parallel zueinander ab Auftraggeber und Entwickler arbeiten eng zusammen wenig Dokumentation Anwendung in kleinen Teams (< 10 MA) © Prof. Dr. Walter Ruf

2.5.2 Werte der agilen Softwareentwicklung linke Seite rechte Seite 1. Individuen und Interaktionen sind mehr als Prozesse und Werkzeuge 2. Funktionierende Software ist mehr als umfassende Dokumentation 3. Zusammenarbeit mit dem Kunden ist mehr als Vertragsverhandlung 4. Reagieren auf Veränderung ist mehr als das Befolgen eines Plans Die Bedeutung der linken Seite wird höher eingeschätzt als die Bedeutung der rechten Seite (in Anlehnung an das Agile Manifest) http://agilemanifesto.org/iso/de/manifesto.html © Prof. Dr. Walter Ruf

2.5.3 Die 12 Prinzipien des agilen Manifestes Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden. Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne. Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten. Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen. Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteam zu übermitteln, ist im Gespräch von Angesicht zu Angesicht. © Prof. Dr. Walter Ruf

Die 12. Prinzipien des Agilen Manifestes (Fortsetzung) Funktionierende Software ist das wichtigste Fortschrittsmaß. Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können. Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität. Einfachheit ist essenziell. Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an. Agile Manifest http://agilemanifesto.org/iso/de/manifesto.html © Prof. Dr. Walter Ruf

2.5.4 Vergleich „klassisches PM“ vs. „agiles PM“ Äderungen nur durch Change Request-Verfahren. Ein priorisierter Arbeitsvorrat (Backlog) enthält Teilaspekte. Umsetzung durch Planung und Ausführung von kleinen, abgeschlossenen Teilprojekten. Änderungen im Ablauf jederzeit möglich. Pröpper, N.: Agile Techniken für klassisches Projektmanagement, S. 33 © Prof. Dr. Walter Ruf

„klassischer“ Projektverlauf: „agiler“ Projektverlauf © Prof. Dr. Walter Ruf

2.5.5 Überblick zu agilen Methoden Extreme Programming Gefordert wird Software mit einem langfristigen Nutzen. Man will auf sich ändernde Anforderungen schnell und präzise reagieren. SCRUM Es wird akzeptiert, dass der Softwareentwicklungsprozess eigentlich nicht genau vorhersehbar ist. Software Kanban Feature Driven Development (FDD) … © Prof. Dr. Walter Ruf

Linkliste Websites von Autoren: Wolf, H.; Bleek, W.-G.: Agile Softwareentwicklung – Werte, Konzepte und Methoden; dpunkt-Verlag, 2. Auflage 2011 www.henningwolf.de www.wolfgideonbleek.de © Prof. Dr. Walter Ruf

2.6 Ausgewählte agile Methoden Extreme Programming Scrum Software-Kanban © Prof. Dr. Walter Ruf

2.6.1 Extreme Programming (kurze Whlg.) „Extreme Programming is a discipline of software development based on values of simplicity, communication, feedback and courage. It works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are and to tune the practices to their unique situation“ (Jeffries, R.: (2001), Abruf am 7.5.2007). © Prof. Dr. Walter Ruf

Wertestruktur beim Extreme Programming Kommunikation i.d.R. verbale Kommunikation offener Informationsaustausch Einfachheit Umsetzung in kleinen übersichtlichen Schritten Entwickler können gegeneinander ausgetauscht werden Feedback permanente Reflektion der Arbeit im Team Mut Fehler werden offen kommuniziert und schnell beseitigt auftretende Veränderungen werden aktiv angenommen Gelegentlich wird noch „Respekt“ aufgenommen. Entwickler respektieren die Kunden und die Kunden die Entwickler. Jedes Projektmitglied respektiert das Andere. © Prof. Dr. Walter Ruf

Wertestruktur beim Extreme Programming Retrospektive = rückblickende Reflexion der Projektbeteiligten. Aus Fehlern der Vergangenheit will man Erkenntnisse für die Zukunft gewinnen. Refactoring = sofern Softwareentwickler während der Umsetzung Möglichkeiten entdecken, das Design weiter zu vereinfachen, so wird dies gleich gemacht. Umstrukturierung unter Beibehaltung der Funktionalität © Prof. Dr. Walter Ruf

Techniken im Extreme Programming Managementtechniken Kunde vor Ort (customer on site) Planungsspiel (planning game) Kurze Releasezyklen (short releases) Retrospektive (retrospective) Teamtechniken Metapher (metaphor) gemeinsame Verantwortlichkeiten (common ownership) Fortlaufende Integration (continuous integration) Programmierstandards (coding standards) Nachhaltiges Tempo (sustainable pace) Programmiertechniken Test (testing) Einfaches Design (simple design) Refactoring Programmieren in Paaren (pair programming) © Prof. Dr. Walter Ruf

Beispiel zu Stories Bei Extreme Programming beschreibt der Auftraggeber die Anforderungen für Stories. Jede Story beschreibt einen konkreten Vorfall, der für den Betrieb des Produktes notwendig ist. Beispiel: Parkhaus-Story: Der Fahrer bleibt an der geschlossenen Schranke stehen und fordert einen Parkschein an. Hat er diesen entnommen, offnet sich die Schranke Der Fahrer passiert die Schranke, die sich wieder schließt. Weitere Situationen (volles Parkhaus, Stromausfall. . . ) werden ebenfalls durch eigene Stories beschrieben. © Prof. Dr. Walter Ruf

Typische Rollen bei XP Programmierer Kunde Projektleiter Softwareentwicklung Design Architektur Kunde inhaltliche Entwicklungsprozesse Bereitstellung der Finanzmittel Projektleiter Koordination im Projekt Verwaltung der Ressourcen, Kosten, Zeitpläne Weitere Rollen: Tester Sie sind identisch mit den Programmierern. Sie helfen den Anwendern bei der Umsetzung und Formulierung von Akzeptanztests. Verfolger Sie verfolgen den Entwicklungsprozess, erstellen Budgetkontrollen, beobachten die Effektivität der Programmierung usw. XP-Trainer Kennt die XP-Methodik und erläutert diese allen Beteiligten. Technologieberater Beratung der Beteiligten bei der Lösung technischer Probleme. © Prof. Dr. Walter Ruf

Zusammenfassung und Wertung XP wird in die Gruppe der iterativen, inkrementellen Vorgehensmodelle eingeordnet. Das Modell weist Merkmale von Prototypingmodellen auf. Eignet sich wenn Anforderungen am Anfang nur „vage“ sind oder sich schnell ändern. Ein Release erstreckt sich über 1 – 3 Monate Nachteile Das Entwicklerteam nähert sich den Anforderungen des Kunden durch viele kleine Schritte. Das Modell ist nur für kleine bis mittelgroße Projektteams (ca. 10 – 15 Personen) geeignet. Eine Projektunterstützung in virtuellen Teams und verteilten Projekten ist nicht gegeben. Die Projektumsetzung erfordert erfahrene, gut ausgebildete Entwickler und Manager. Die Ausbildung und Integration von mehreren neuen Mitarbeitern ist problematisch. Es muss mit Schwierigkeiten bei der Ermittlung des Projektaufwands zum Zeitpunkt des Projektbeginns gerechnet werden. Das Vorgehensmodell orientiert sich an der Entwicklung von objektorientierten Softwaresystemen. Für das Modell gibt es kaum Managementtools. XP beinhaltet keine formale Spezifikation der Inhalte. Eine permanente Zusammenarbeit mit dem Kunden ist erforderlich. Outsourcing von Programmierleistung ist damit nicht möglich. Zusatzaufwand beim Kunden Probleme bei einer effektiven Kostenkontrolle (Metrik zur Kostenkontrolle fehlt) konkrete Planwerte fehlen © Prof. Dr. Walter Ruf

Besondere Vorteile von XP Testfälle vor der Implementierung / kontinuierliche Tests Mut für Neues Programmierung in Paaren hat zur Folge, dass: Paare produzieren bessere Qualität Paare sind schneller fertig vgl. Williams et al., Strengthening the Case for Pair-Programming, IEEE Software, 2000 http://www.st.cs.uni-saarland.de/edu/lehrer/xp.pdf © Prof. Dr. Walter Ruf

2.6.2 Scrum Scrum = Gedränge; Begriff aus dem Rugby Mit Scrum verbindet man die Namen Ken Swaber, Jeff Sutherland und Mike Beedle 2001 veröffentlichten Swaber / Beedle das Buch „Agile Software Development with SCRUM“ © Prof. Dr. Walter Ruf

2.6.2.1 Rollen 1. Product Owner 2. Team 3. Scrum Master Formulierung, Auswahl und Priorisierung der Anforderungen an ein neues Softwareprodukt => Produktverantwortliche (verantwortlich für das Produkt-Backlog) Im Idealfall steht er dem Projekt in Vollzeit zur Verfügung. 2. Team überwiegend Entwickler, die für die Umsetzung der Anforderungen eigenverantwortlich zuständig sind. Das Team verhandelt mit dem Product Owner welche Anforderungen in welcher Zeit erledigt werden. selbstorganisiertes, eigenverantwortliches Team 3. Scrum Master unterstützt den Product Owener und das Team bei der Projektdurchführung. (Er sollte kein Teammitglied sein – „Diener“ des Teams) verantwortlich für die Prozesse bei der Umsetzung Product Owner Er stellt die Schaltzentrale im Projekt dar. Er repräsentiert den Kunden und verfolgt seine Interessen. 2. Team Ein Team besteht aus 7 +/- 2 Vollzeitarbeitskräften Im Team sind Programmierer, Designer und Tester! 3. Scrum Master Der Scrum Master ist verantwortlich für den Erfolg des Scrum-Prozesses. Er ist nicht befugt, Anweisungen zu erteilen oder Arbeitszeiten vorzugeben. („Servant Leader“ = „Dienstleistender Anführer“) -> dienen statt führen Er hat folgende Aufgaben: Probleme und Hindernisse beseitigen (Scrum-Rollen werden falsch verstanden; Product Owner fehlt; Kompetenzverteilung im Team; Arbeitsplatz ist zu geräuschvoll; Teamkonflikte, …) Schulungen von Scrum Regeln von Scrum werden von ihm vermittelt © Prof. Dr. Walter Ruf

Scrum – Rollen und deren Beziehungen Wirdemann, R.: SCRUM mit User Stories; 2. Auflage, S. 37 © Prof. Dr. Walter Ruf

2.6.2.2 Scrum Prinzipien Transparenz Beobachten und Anpassen sämtliche Aspekte, die den Prozess oder das Ergebnis beeinflussen sollen, sichtbar dargestellt werden. Umsetzung u.a. mit Sprint Backlog, Daily Scrum, … Beobachten und Anpassen der Prozess, das Team und die produzierten Ergebnisse werden ständig beobachtet. Umsetzung u.a. mit Codereviews, Unit Tests, Sprint Reviews Bei relevanten Abweichungen muss sofort reagiert werden. Timeboxing Managementtechnik, bei der ein bestimmtes Zeitbudget für alle Tätigkeiten zugeordnet wird. Das Zeitende „ist in Stein gemeisselt“. Umsetzung u.a. Sprints mit fixer Dauer; Daily Scrum = 15 Min.; Sprint Planning Meeting = 1 Tag; Transparenz Hier geht es darum, die guten und die nicht so guten Dinge offen darzulegen. Vom Team werden gerne die guten Dinge präsentiert. Scrum will aber auch, dass gerade die Dinge offen dargelegt werden, die nicht so gut laufen. Beobachten und Anpassen Merkt man z.B. während des Ablaufs der Kunde, dass die realisierte User Story seinen Erwartungen nicht entspricht, kann er über den Produkt Owner und dem Team ein gemeinsames Verständnis schaffen, wie er die Dinge gerne hätte. Oder: Merkt der Product Owner, der das Geschäftsmodell kennt, dass das Projekt vom eigentlichen Ziel abweicht, muss er für eine Kursanpassung sorgen. Eine Anpassung erfolgt über User Stories und Prioritäten. Timeboxing Es wird mit Macht an einem zugesagten Termin festgehalten. Stellt man z.B. fest, dass die im Sprint Planning Meeting festgehaltenen User Stories nicht umgesetzt werden können, so reduziert man den Funktionsumfang der Stories oder lässt einzelne Stories weg. Die Deadline wird jedoch im Gegensatz zum traditionellen Managmentvorgehen nicht verschoben. Würde man die Deadline verschieben, würde man dem Team vermitteln, dass eine Zeitverzögerung doch gar nicht so schlimm ist. Das Team würde unzuverlässig werden. Durch die Daily Scrums wird dem entgegengewirkt, dass Zeitschätzungen für Aufgaben viel zu großzügig bemessen werden. © Prof. Dr. Walter Ruf

Scrum Prinzipien Dinge abschließen Maximierung vom Geschäftswert abgeschlossene Stories werden als „done“ bezeichnet. Stories, die am Sprintende nicht fertig sind, wandern zurück ins Produktbacklog Umsetzung durch Product Backlog, Taskboard Maximierung vom Geschäftswert von Anfang an soll der Kunde von dem kontinuierlich geschaffenen Mehrwert profitieren die Planungsphase wird auf ein Minimum reduziert Umsetzung durch Product Backlog; Priorisierung von User Stories Team scheitert nicht keiner macht Fehler freiwillig. Aus Fehlern will man lernen. Umsetzung durch reduzierte Entwicklungsgeschwindigkeit und die Frage: „Was geht noch?“ Ergebnisorientierung es zählt, was am Ende herauskommt! Umsetzung durch: Produktvision wird durch Sprints umgesetzt. Innerhalb der Sprints werden User Stories umgesetzt Dinge abschließen Wenn man zu viele offene „Baustellen“ hat, dann wird der Durchsatz reduziert. Dinge behindern sich gegenseitig. Wenn eine Story als „done“ bezeichnet wird, dann kann der Auftraggeber jederzeit kommen und sagen „prima“, gefällt mir gut, wir bringen die Story „live“. Keiner vom Team darf nun sagen „Moment – ein paar Kleinigkeiten sollten noch gemacht werden…“ Stories, die am Sprintende nicht „done“ sind, wandern zurück ins Product Backlog. Der Wert einer Story ergibt sich erst, wenn etwas zu 100% fertig ist, sonst ist der Wert = 0. Maximierung vom Geschäftswert In traditionellen Ablaufmodellen kann es Monate dauern, bis der Kunde ein Ergebnis sieht. Bei Scrum wird versucht, die erste Software nach dem ersten Sprint nach 1 – 4 Wochen fertigzustellen. Nach z.B. 3 – 4 Sprints kann ggf. der Kunde mit der Software damit Geld verdienen. © Prof. Dr. Walter Ruf

Begriffe Product Backlog User Story zentrales Werkzeug für die Planung und Priorisierung von Anforderungen im Scrum-Projekt User Story beschreibt eine Anforderung an ein Softwaresystem wird in der „Sprache des Kunden“ formuliert Beisp. Entwicklung eines Personalinformationssystems: Beschäftigte können ihr eigenes Profil erfassen und verwalten Falsch: Die Software wird in Java geschrieben Falsch: Die Anwendung muss auf zwei Applikationsservern laufen User Story Eine User Story beschreibt einen Mehrwert für den Kunden. © Prof. Dr. Walter Ruf

2.6.2.3 User Story eignen sich für eine iterative Entwicklung besteht aus 3 Teilen Story-Karte 1 Satz zur Anforderungsbeschreibung Konversation (Abstimmung mit den Entwicklern) Akzeptanzkriterien eignen sich für eine iterative Entwicklung Die Story-Karte soll an offene Aufgaben erinnern. Wenn sie umgesetzt werden soll, wird der Product Owner mit dem Team darüber sprechen, (Konversation) was man genau unter dieser Anforderung verstehen soll. Der Product Owner prüft die Priorität dieser Story und bei der Umsetzung, ob die Kriterien für „done“ erreicht werden. Beispiel für Story-Karte Als Verkaufsleiter will ich eine Kampagne mit Kunden starten können. Als Einkäufer will ich einen direkten Kontakt zu den Lieferanten aufbauen können. Banksoftware: Als Kunde will ich Geld auf andere Konten überweisen. Banksoftware: Als Kunde will ich Unterkonten einrichten. © Prof. Dr. Walter Ruf

User Story Karteikarten (z.B. A5-Format) werden am Whiteboard platziert können Details durch Aufzählungen beinhalten handschriftliche Karten können einfach ergänzt / verändert werden auf der Rückseite können Akzeptanzkriterien (vom Product Owner und Team) aufgetragen werden Während der Entwicklung dürfen Vorder- und Rückseite verändert werden Mitarbeiter soll sein eigenes Profil verwalten. PDF-Formular-Upload Welche Felder? Freischaltung vom Admin Anschrift und Kommunikations- parameter sind Pflichtfelder Wahlfelder für Hobby und berufliche Interessen Wahlfelder für Erfahrungen Oft wissen Kunden erst, ob sie etwas gebrauchen können, wenn sie eine erste Softwareversion zur Verfügung haben. Vorderseite Rückseite © Prof. Dr. Walter Ruf

User Story Qualitätseigenschaften guter User Stories Begriff User Stories sollen: I Independent - unabhängig voneinander sein N Negotiable - verhandelbar sein V Valuable - einen Wert für den Kunden haben E Estimatable - schätzbar sein S Small - klein und übersichtlich sein T Testable - selbständig testbar sein © Prof. Dr. Walter Ruf

2.6.2.4 Projektablauf bei Scrum Scrum im Überblick Jedes Scrum-Projekt beginnt mit einer Vision des zu entwickelndem Produkts. Die ersten Visionen sind oft noch sehr unpräzise formuliert, sie werden jedoch im Verlauf des Projektes immer deutlicher. (vgl. Schwaber 2007,S.8) Die Vision wird vom Kunden zusammen mit dem Product Owner formuliert, dabei werden u.a. Anforderungen an die Funktionalität, Käuferbedürfnisse und Unterschiede zu Wettbewerbern berücksichtigt. Alle Anforderungen an das Produkt werden vom Product Owner als User Stories formuliert und in das Product Backlog eingetragen. Dabei wird jede Story mit einer Priorität versehen, die Komponente mit dem wahrscheinlich höchsten Nutzen trägt die höchste Priorität und wird als erstes entwickelt. (vgl. Wirdemann 2011,S.29) Ein Sprint stellt einen Iterationsschritt im Projekt dar. Das Produkt wird also inkrementell weiterentwickelt. Ein Sprint dauert ca. 7 - 30 Tage. Pro Entwicklungstag findet ein Daily Scrum statt. Sofern erkennbar wird, dass ein Sprint nicht zum Erfolg führt, kann er vom Scrum-Master abgebrochen werden. Am Ende eines Sprints findet ein Sprint Review und ein Retrospective Meeting mit dem Ziel statt, Transparanz und Verbesserungsmöglichkeiten herzustellen. © Prof. Dr. Walter Ruf

2.6.2.4 Projektablauf bei Scrum Ausgangspunkt ist die Vision von einem Produkt Projektanforderungen können von allen Projektbeteiligten erstellt werden. Produkt-Backlog Projektanforderungen werden im Product-Backlog gesammelt und ggf. priorisiert. Sprint Backlog Der Product Owner wählt aus dem Product-Backlog die Anforderungen aus, die im nächsten Schritt (Sprint) umgesetzt werden sollen. So entsteht ein Sprint Backlog. © Prof. Dr. Walter Ruf

Sprint Abarbeitung der Anforderungen aus dem Sprint Backlog Sprintdauer immer von gleicher Länge (z.B. 30 Tage) keine neuen oder geänderten Anforderungen während eines Sprints tägliche Abstimmung innerhalb des Teams (15 Minuten, festgelegter Ort); „Daily Scrum Meeting“ Jeder beantwortet die Fragen: Was habe ich seit dem letzten Daily Scrum Meeting getan? Was werde ich bis zum nächsten Meeting machen? Was behindert mich? es findet keine Diskussion statt (nur Klärung von Verständnisfragen) Präsentation der Ergebnisse nach dem Sprint beim Product Owner Durchführung eines Sprintreviews. daraus können sich neue Anforderungen für das Backlog ergeben „Lessons Learned“ gewonnene Erkenntnisse für die nächste Sprintplanung (z.B. Aufwandschätzungen) © Prof. Dr. Walter Ruf

Sprint Planung jeder Sprint beginnt mit einem eintägigen Sprint-Planning Meeting Product Owner stellt dem Team die Stories vor, die im nächsten Sprint bearbeitet werden.l Sprint-Planning setzt sich zusammen aus: Sprint-Planning 1 (Dauer: 4 h; Vormittag) es geht um die Frage „WAS“ wird im nächsten Sprint gemacht Sprint-Planning 2 (Dauer: 4 h; Nachmittag) es geht um die Frage „WIE“ werden die Aufgaben umgesetzt die zur Umsetzung erforderlichen Tasks werden ermittelt. Die Tasks werden im Sprint-Backlog festgehalten (To-do-Liste für den nächsten Sprint) Der Zeitaufwand für die einzelnen Tasks wird geschätzt. Im Sprint-Planning 1 committet sich das Team zu einer ausgewiesenen Anzahl an User-Stories. Die ausgewiesenen User-Stories werden im Selected Backlog festgehalten. Im Sprint-Planning 2 geht es um die Ableitung von einzelnen Aufgaben (Tasks), die für die Umsetzung der Userstory erforderlich sind. Man klärt Designfragen, Architekturfragen oder entwirft z.B. das Datenbankmodell. © Prof. Dr. Walter Ruf

Übersicht zum Scrum-Projektablauf Wolf, H.; Bleek, W.-G.: Agile Softwareentwicklung; 2011, S. 164 © Prof. Dr. Walter Ruf

Burndown Chart Sprintverlauf tägliche Aktualisierung Das Burndown Chart kann tagesbasiert (im Beispiel 20 Tage) aufgebaut werden. In der Praxis hat sich gezeigt, dass es nicht einfach ist, ein korrektes Burndown Chart zu erstellen, da man den „idealen“ Verlauf nicht kennt. Oft verschätzt man sich bei der Darstellung des geplanten Verlaufs. Durch das Chart wird ein zusätzlicher Druck auf das Team erzeugt. © Prof. Dr. Walter Ruf

Retrospektive nach dem Sprint Ziel: Schrittweise und kontinuierliche Verbesserung des Entwicklungsprozesses Zentrale Fragen: Was haben wir gut gemacht? Was können wir das nächste Mal verbessern? Teilnehmer: Scrum Master (Leiter), Team und möglichst Product Owner Dauer: 3 h wird oft am letzten Tag des Sprints durchgeführt Ergebnis: Aktionspläne und geordneter Abschluss Daten sammeln: Welche User Stories wurden umgesetzt? Welche User Stories sind liegengeblieben? Welchen Höhen und Tiefen gab es? Wie lief der Produktionssupport? Was hat gestört? Was gab es zu feiern? Einsichten generieren Guter Teamgeist Gute Einbindung neuer MA Büroarbeitsplatz zu laut Viele Fehler nach Live-Gang Pünktlichkeit der Mitarbeiter Bugfix nur mit großen Verzögerungen Codequalität Was können wir tun? Man kann viele Vorschläge sammeln, auf einer Tafel aufschreiben und vom Team bepunkten lassen. Daraus lässt sich dann eine Prioritätsliste ableiten. Beispiel: Weniger User Stories annehmen Codequalität durch klare Programmierregeln verbessern Neues Büro suchen Definition von Done ändern Aktionsplan erstellen Programmierregeln aufstellen (Otto – Senior im Team) Verbesserungen im Bürobereich suchen (Paul) Abschluss Scrum-Master macht eine „Retrospektive der Retrospektive“ Teammitglieder erhalten Post-it-Zettel und der Scrum Master bittet festzuhalten, was an der Retrospektive gut oder weniger gut war. Übung © Prof. Dr. Walter Ruf

Taskboard Story to do in process to verify done © Prof. Dr. Walter Ruf Entwicklungs-umgebung einrichten done Benutzerprofil verwalten Login und Identifikation Lohnabrech-nungsdaten einsehen Benutzerprofil verwalten Benutzerprofil verwalten Domainaus- wahl und Re-gistrierung Steuerbe- scheinigungen erstellen © Prof. Dr. Walter Ruf

Tools für Scrum Scrumwise https://www.scrumwise.com/scrum/ © Prof. Dr. Walter Ruf

2.6.3 Software-Kanban Kanban = [jap.] Karte Änderungen in Softwaresystemen sollen „evolutionär“ und nicht „revolutionär“ erfolgen. Änderungen in kleinen Schritten in Abstimmung mit den Teammitgliedern. Die Anzahl an paralleler Arbeit soll vermieden werden. Kanban enthält keine Iterationsschritte Kanban verwendet kein Rollenkonzept © Prof. Dr. Walter Ruf

Prinzipien von Software-Kanban Visualisierung Darstellung der Prozessschritte (z.B. Analyse, Entwicklung, Test, Deployment) auf einem Kanban-Board. Board enthält „Haftzettel“ oder „Karteikarten“, die als Tickets das Board durchlaufen. Auf den Tickets kann man den Bearbeiter festhalten. Durch die Visualisierung hat man einen transparenten Überblick und erkennt Überlaststellen. Wolf, H.; Bleek, W.-G.: Agile Softwareentwicklung; 2011, S. 172 © Prof. Dr. Walter Ruf

Beispiel 2: Kanban-Board Rook, A.: Software-Kanban, in: ProjektMagazin; http://www.projektmagazin.de/node/996703/#visualisierung; abgerufen am 2.1.2013 © Prof. Dr. Walter Ruf

Prinzipien des Software-Kanban (Fortsetzung) Pull statt Push die Tickets sollen vom Ende her betrachtet und von dort aus „gezogen“ werden. Ein Entwickler nimmt sich das nächste Ticket, wenn er eine Aufgabe erledigt hat. Vorteile: Entwickler werden nicht mit offenen Aufgaben überhäuft. Dadurch lassen sich „Stress-“Fehler vermeiden. keine dauerhafte Überlastung © Prof. Dr. Walter Ruf

Prinzipien des Software-Kanban (Fortsetzung) Begrenzung paralleler Arbeit Will man den Durchsatz steigern, so muss man die Anzahl an parallel ablaufenden Aufgaben begrenzen. Damit die Tickets möglichst schnell durchlaufen wird eine Begrenzung der Tickets in den Prozessschritten festgelegt. An der aktuellen Spaltensumme erkennt man gut Engpassprobleme. max: 6 6 6 6 © Prof. Dr. Walter Ruf

Prinzipien des Software-Kanban (Fortsetzung) Erhebung solider Daten Es wird großen Wert auf die Erhebung von verlässlichen Daten gelegt. Die eingesetzten Metriken sind abhängig vom Projektkontext. Beisp. für Metriken: Durchlaufzeiten, Durchsatz, Fehlerraten häufig verwendet: Cumulative Flow Diagramme LT = Lead Time (beschreibt „Time to Market“) WIP = Work in Progress WIP = work in Progress LT = Lead time (Mit dieser Kenngröße kann man „Time to Market“ beschreiben. http://www.google.de/imgres?imgurl=http://open.bekk.no/wp-content/uploads/2009/11/CFD-annotated.001.png&imgrefurl=http://open.bekk.no/cumulative-flow-diagrams-with-google-spreadsheets/&h=582&w=750&sz=64&tbnid=wjbhGejCLzrl1M:&tbnh=91&tbnw=117&zoom=1&usg=__i6lLHJAxqb4u-AGEjqW06keKj6U=&docid=cM0Z7dkZTJD9qM&sa=X&ei=L4PkULXiJYfcsgbQ9IGoDQ&ved=0CDkQ9QEwAA&dur=47; abgerufen am 2.1.2013 © Prof. Dr. Walter Ruf

Prinzipien des Software-Kanban (Fortsetzung) Kaizen Durchführung von kontinuierlichen Verbesserungsmaßnahmen Alle Teammitglieder dürfen Verbesserungsvorschläge einbringen. weitere Basiselemente tägliche Standup-Meetings regelmäßige Retrospektive (Operations Reviews) © Prof. Dr. Walter Ruf

2.6.4 Fazit Software-Kanban ist nicht eine eigenständige Methode, sondern wird in Zusammenhang mit anderen Methoden (Scrum, Extreme Programming, oder sogar dem Wasserfallmodell) verwendet. Scrumban = Kombination von Scrum und Kanban (C. Ladas 2008) Kanban stellt damit eine gute Möglichkeit dar, eine traditionelle Softwareentwicklung mit agilen Aspekten zu ergänzen. gute Eignung für Wartungs- oder Systemadministrationsprojekte © Prof. Dr. Walter Ruf

2.6.4.1 Was spricht gegen den Einsatz von agilen Methoden? Kontraindikation im Bereich des Kunden Projektziel ist nicht SMART (spezifisch, messbar, angemessen, relevant, terminiert) zu beschreiben. Prozess wird vom Kunden vorgegeben (z.B. Behörden) Nice-to-have-Projekte (Kunde muss ein vitales Interesse an der Entwicklung haben) lange Entscheidungswege beim Kunden langwierige Change-Request-Verfahren kein Anwenderkontakt möglich Erstellung von lebenskritischen Softwaresystemen (Systeme mit max. Sicherheit) keine Arbeit vor Ort möglich Festpreisprojekte Erstellung von lebenskritischen Softwaresystemen (Systeme mit max. Sicherheit) Hier kann man nicht anfangen, erstmals ein kleines Teilstück zu realisieren und später „Schritt für Schritt“ dieses zu vervollständigen. (z.B. Raketensteuerung; Kraftwerksteuerung; Sicherheitssysteme; …) vgl. Wolff, H.; Bleek, W.-G.: Agile Softwareentwicklung, 2011, S. 176 ff. © Prof. Dr. Walter Ruf

Was spricht gegen den Einsatz von agilen Methoden? Kontraindikation im Bereich der Entwickler keine Erfahrung mit agilen Projekten und kein Coach vorhanden Lernunfähigkeit und Lernunwillen Kultur von Befehl und Gehorsam Entwickler wollen keinen Anwenderkontakt hohe Fluktuation keine Arbeit vor Ort gewünscht Kontraindikation im Bereich der Technologie Lange Build-Zeiten vgl. Wolff, H.; Bleek, W.-G.: Agile Softwareentwicklung, 2011, S. 180 ff. © Prof. Dr. Walter Ruf

2.6.4.2 Was spricht für den Einsatz von agilen Methoden? Indikationen im Bereich des Kunden Start-ups (besonders Internet Start-ups) Innovative Projekte Neue Anwendungsbereiche schnelle Auslieferung ist notwendig (time-to-market) kleine Projekte … Indikationen im Bereich der Entwickler neugierige, jedoch eigenverantwortlich arbeitende Entwickler keine oder wenige externe Dienstleister im Entwicklungsbereich Arbeit beim Kunden vor Ort ist gegeben Konkrete Probleme können benannt werden Indikationen im Bereich von Technologien Verwendung von inkrementellen Compilern (z.B. für Java) Interpretierende Scriptsprachen Nutzung von Testframeworks vgl. Wolff, H.; Bleek, W.-G.: Agile Softwareentwicklung, 2011, S. 182 ff. © Prof. Dr. Walter Ruf

Interessante Links zu SCRUM GPM http://www.gpm-infocenter.de/PMMethoden/SCRUM Wirdemann, R.: SCRUM Mit User Stories 2. Auflage, Hanser-Verlag ISBN 978-3-446-42660-3 Scrum Kompakt http://www.scrum-kompakt.de/ © Prof. Dr. Walter Ruf