projektmanagement 2. vorgehensmodelle dozentenversion!!! masterstudiengang wiki: login: ruf pw...
TRANSCRIPT
Projektmanagement
2. Vorgehensmodelle
Dozentenversion!!!Masterstudiengang
Wiki: http://prof-ruf.de/wikina Login: ruf PW mediawikiBlog: http://prof-ruf.de/wpna2013 PW: wie immer
Nordakademiehttps://moodle.nordakademie.de/
Login: walterrufPW: adminruf
1© Prof. Dr. Walter Ruf
2. Vorgehensmodelle in IT-Projekten
2.1 Grundlagen für Vorgehensmodelle2.2 Sequentielle Vorgehensmodelle2.3 Inkrementelles Vorgehensmodell2.4 Iterative, inkrementelle Entwicklung2.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 Methoden2.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
2. Vorgehensmodelle in IT-Projekten
Lernziele von Kapitel 2In 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?
3© Prof. Dr. Walter Ruf
2.1 Grundlagen für Vorgehensmodelle
4
Freigabe Phase
Phasenauf-gaben
bearbeiten
Vorgaben:- Aufgabenpaket- Termin- Ressourcen- Qualität
Phasenergebnisse
Phase fertiggestellt
Prüfung Phasen-
ergebnisse
Phasenergeb-nis nicht o.k.
Phasenergebnis o.k.
XOR
XOR
Freigabe Folgephase /
Projekt-abschluss
© Prof. Dr. Walter Ruf
2.2 Sequentielle Vorgehensmodelle
5
Spezifikation
Entwurf
Implementie-rung
Integration
Einführung
Phase
Zeit
© 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.
6© Prof. Dr. Walter Ruf
Wasserfallmodell
7
Phas
e
Zeit
SpezifikationValidierung
Entwurf
Validierung
Implemen-tierung
Validierung
IntegrationTest
EinführungProduk-tionstest
© 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.
8© Prof. Dr. Walter Ruf
2.3 Inkrementelles Vorgehensmodell
9
Problem-spezifikation
System-spezifikation
System-konstruktion
Sockel 1
Sockel 2a
Sockel 2b
Sockel 3
Fertigstellungs-anteil
Version 1
RealisierungModul-spezifikation
Reali-sierung
Modul-spezifikation
Inte-gration
RealisierungModul-spezifikation Integration
Reali-sierung
Modul-spezifikation Integration
Betrieb und Wartung
Ein-führung
10%
10%
10%
10%
© Prof. Dr. Walter Ruf
2.4 Iterative, inkrementelle Softwareentwicklung
10
20%20%
20%20%20%
20%20%
20%20%20%
20%20%
20%20%20%
20%20%
20%20%20%
20%20%
20%20%20%Projekt-
spezifikationSystem-
spezifikation
Modul-spezifikation
Modul-spezifikation
Realisierung
Realisierung Integration
Sockel 1
Sockel 2a
Sockel 2b
Sockel 1
Sockel 2a
Sockel 2b
Sockel 3
I1.I2.
I3.
I1.I2.
I3.
I1.I2.
I3.
I1.I2.
I3.
I1.I2.
I3.
System-konstruktion
I1.I2.
I3.
I1.I2.
I3.
I1.I2.
I3.
Modul-spezifikation Realisierung
I1.I2.
I3.
I1.I2.
I3.
I1.I2.I3.
Integration
I1.I2.
I3.
Modul-spezifikation Realisierung
I1.I2.
I3.
I1.I2.
I3.
I1.I2.I3.
Integration
I1.I2.
I3.
EinführungBetrieb
undWartung
Sockel 3
I1.I2.
I3.
I1.I2.
I3.
Legende:
I3. = 3. Iterations- schritt
I1. = 1. Iterations- schrittI2. = 2. Iterations- schritt
Sockel x
Fertig-stellungs-
anteil
© 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.
11© 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)
12© Prof. Dr. Walter Ruf
2.5.2 Werte der agilen Softwareentwicklung
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
13
linke Seite rechte Seite1. 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
© Prof. Dr. Walter Ruf
2.5.3 Die 12 Prinzipien des agilen Manifestes
1. Unsere höchste Priorität ist es,den Kunden durch frühe und kontinuierliche Auslieferungwertvoller Software zufrieden zu stellen.
2. Agile Prozesse nutzen Veränderungenzum Wettbewerbsvorteil des Kunden.
3. Liefere funktionierende Softwareregelmäßig innerhalb weniger Wochen oder Monate undbevorzuge dabei die kürzere Zeitspanne.
4. Fachexperten und Entwicklermüssen während des Projektestäglich zusammenarbeiten.
5. Errichte Projekte rund um motivierte Individuen.Gib ihnen das Umfeld und die Unterstützung, die sie benötigenund vertraue darauf, dass sie die Aufgabe erledigen.
6. Die effizienteste und effektivste Methode, Informationenan und innerhalb eines Entwicklungsteam zu übermitteln,ist im Gespräch von Angesicht zu Angesicht.
14© Prof. Dr. Walter Ruf
Die 12. Prinzipien des Agilen Manifestes (Fortsetzung)
7. Funktionierende Software ist daswichtigste Fortschrittsmaß.
8. Agile Prozesse fördern nachhaltige Entwicklung.Die Auftraggeber, Entwickler und Benutzer sollten eingleichmäßiges Tempo auf unbegrenzte Zeit halten können.
9. Ständiges Augenmerk auf technische Exzellenz undgutes Design fördert Agilität.
10. Einfachheit ist essenziell. 11. Die besten Architekturen, Anforderungen und Entwürfe
entstehen durch selbstorganisierte Teams. 12. In regelmäßigen Abständen reflektiert das Team,
wie es effektiver werden kann und passt seinVerhalten entsprechend an.
15
Agile Manifesthttp://agilemanifesto.org/iso/de/manifesto.html
© Prof. Dr. Walter Ruf
2.5.4 Vergleich „klassisches PM“ vs. „agiles PM“
16
Pröpper, N.: Agile Techniken für klassisches Projektmanagement, S. 33
Ä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.
© Prof. Dr. Walter Ruf
• „klassischer“ Projektverlauf:
• „agiler“ Projektverlauf
17© 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)
• …
18© 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
19© Prof. Dr. Walter Ruf
2.6 Ausgewählte agile Methoden
• Extreme Programming• Scrum• Software-Kanban
© Prof. Dr. Walter Ruf 20
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).
21© 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
22© Prof. Dr. Walter Ruf
Wertestruktur beim Extreme Programming
23
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)
24© 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.
25© Prof. Dr. Walter Ruf
Typische Rollen bei XP
• Programmierer– Softwareentwicklung– Design– Architektur
• Kunde– inhaltliche Entwicklungsprozesse– Bereitstellung der Finanzmittel
• Projektleiter– Koordination im Projekt– Verwaltung der Ressourcen, Kosten, Zeitpläne
26© Prof. Dr. Walter Ruf
Zusammenfassung und Wertung
27© Prof. Dr. Walter Ruf
• 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
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
28© 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“
29© Prof. Dr. Walter Ruf
2.6.2.1 Rollen
1. Product Owner• 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 Team3. 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
30© Prof. Dr. Walter Ruf
Scrum – Rollen und deren Beziehungen
31
Wirdemann, R.: SCRUM mit User Stories; 2. Auflage, S. 37
© Prof. Dr. Walter Ruf
2.6.2.2 Scrum Prinzipien
• Transparenz– 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;
32© Prof. Dr. Walter Ruf
Scrum Prinzipien
• Dinge abschließen– 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
33© Prof. Dr. Walter Ruf
Begriffe
• Product Backlog– 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
34© Prof. Dr. Walter Ruf
2.6.2.3 User Story
• besteht aus 3 Teilen– Story-Karte
• 1 Satz zur Anforderungsbeschreibung– Konversation (Abstimmung mit den Entwicklern)– Akzeptanzkriterien
• eignen sich für eine iterative Entwicklung
35© 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
36
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 beruflicheInteressen
- Wahlfelder für Erfahrungen
Vorderseite
Rückseite
© Prof. Dr. Walter Ruf
User Story
• Qualitätseigenschaften guter User Stories
37
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
38© 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.
39© 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:
1. Was habe ich seit dem letzten Daily Scrum Meeting getan?2. Was werde ich bis zum nächsten Meeting machen?3. 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)
40© Prof. Dr. Walter Ruf
Sprint Planung
41
• 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.
© Prof. Dr. Walter Ruf
Übersicht zum Scrum-Projektablauf
42
Wolf, H.; Bleek, W.-G.: Agile Softwareentwicklung; 2011, S. 164
© Prof. Dr. Walter Ruf
Burndown Chart
• Sprintverlauf• tägliche Aktualisierung
43© 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
44© Prof. Dr. Walter Ruf
Übung
Benutzerprofil verwalten
Taskboard
Story to do in process to verify
Entwicklungs-umgebung einrichten
done
45
Benutzerprofil verwalten
Lohnabrech-nungsdaten einsehen
Steuerbe-scheinigungen erstellen
Benutzerprofil verwalten
Login und Identifikation
Domainaus-wahl und Re-gistrierung
© Prof. Dr. Walter Ruf
Tools für Scrum
• Scrumwise– https://www.scrumwise.com/scrum/
46© 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
47© 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.
48
Wol
f, H
.; B
leek
, W.-G
.: A
gile
Sof
twar
eent
wic
klun
g; 2
011,
S. 1
72
© Prof. Dr. Walter Ruf
Beispiel 2: Kanban-Board
49
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
50© 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.
51
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
52
LT = Lead Time (beschreibt „Time to Market“) WIP = Work in Progress
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)
53© 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
54© 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
55
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
56
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
57
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 Stories2. Auflage, Hanser-VerlagISBN 978-3-446-42660-3
• Scrum Kompakt– http://www.scrum-kompakt.de/
58© Prof. Dr. Walter Ruf