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. Vorlesung 8, Übung Gr.2 09.04. Keine Vorlesung, Ostermontag 11.06. Vorlesung 9, Übung Gr.1 16.04. Vorlesung 2, Übung Gr.1 18.06. Vorlesung 10 23.04. Vorlesung 3, Übung Gr.2 25.06. Vorträge, Übung Gr.1 30.04. Vorlesung 4, Übung Gr.1 02.07. Vorträge 07.05. Vorlesung 5, Übung Gr.2 09.07. Vorträge 14.05. Vorlesung 6, Übung Gr.1 21.05. Vorlesung 7, Übung Gr.2 Vorlesungsfolien immer nach der Vorlesung unter http://www.f4.htw-berlin.de/~patzelt/ 2
Vortrag FAQ Q: Welche Vorgaben gibt es ihrerseits zum Vortrag? Q: Gibt es ein Beispiel, wie alles im Endeffekt aussehen soll? A: 10-15 Minuten mit höchstens 5 Minuten Diskussion. Ich werde diesmal (wegen der vielen Vorträge) alle nach spätestens 15 Minuten warnen und nach 20 Minuten abbrechen (müssen :-(!), 2. jeder aus dem Team muss was sagen. 3. Ich will eine Kopie des Vortrages (Vortragstext als.txt,.ppt, open document oder.pdf) A: Ja: Schwarzer Text auf weissem Hintergrund Q: Soll es eine Präsentation sein oder kann es einfach eine Pdf-Datei sein? A: Egal. Aber per Beamer anzeigen: Alle Studenten sollen es sehen können! Q: Sollen im Vortrag folgende Punkte behandelt werden: Lastenheft, Pflichtenheft, Projektplan, Schwierigkeiten bei Entwicklung des Produktes, Produktdemo? A: ja, ja, ja, ja, ja: Pflichtenheft will ich vorher haben: Jetzt! Aber Achtung: Wer auf die Dokumente zu genau eingeht, braucht zu lange! Q: Sollen wir den Vortrag vorher per E-Mail schicken? A: Es reicht eine Kopie am selben Tag, nachdem sie den Vortrag gehalten haben. Vorher nur, wenn mein Rechner die Datei anzeigen soll. 3
Produkteigentümer (Product Owner) Definiert Produkt-Features Bestimmt Auslieferungsdatum und Inhalt Priorisiert Features Passt Features und Prioritäten nach Bedarf für jede Iteration an Akzeptiert Arbeitsergebnisse im Sprint Review oder weist sie zurück 4
Scrum Master Repräsentiert das Management gegenüber dem Projekt Dient dem Team, aber auch dem Prozess: Schützt das Team vor äußeren Störungen und entfernt Hindernisse Ist verantwortlich für die Einhaltung von Scrum-Werten und -Techniken Stellt sicher, dass das Team vollständig funktional und produktiv ist 5
Das Team Typischerweise fünf bis zehn Leute Programmierer, UI-Designer, aber auch Testabteilung Mitglieder sollten, aber müssen nicht Vollzeitmitglieder sein Teams organisieren sich selbst Mitgliedschaft sollte sich nur zwischen Sprints verändern 6
Daily SCRUM Meeting Parameter täglich, 15-minütig Stand-up Nicht zur Problemlösung (das ist besonders schwer zu trainieren, ohne das Team abzuwürgen) Drei Fragen: Was hast du getan? Was wirst du morgen tun? Welche Hindernisse sind in deinem Weg? 7
Daily SCRUM Meeting Warum täglich? Weil man Verspätungen früh erkennen will. Frage: Wie verspätet sich ein Projekt um ein Jahr? - Antwort: Um einen Tag zu einem Zeitpunkt. Können Scrum-Meetings durch Berichte per E-Mail ersetzt werden? Nein Vorteil: Das ganze Team erhält täglich einen Projekt- Überblick Erzeugt Druck von Team-Kollegen, auch wirklich das zu tun, was man sagt, das man tut 8
Sprint-Review-Meeting Team präsentiert, was es während eines Sprints erreicht hat Typischerweise in Form einer Demo von neuen Features oder der zugrunde liegenden Architektur Informell Zwei-Stunden-Vorbereitung -Regel Teilnehmer Kunden Management Produkteigentümer Andere Entwickler 9
Product Backlog Eine Liste von allen erforderlichen Projektarbeiten Wie eine Todo-Liste oder ein Projektplan Liste wird vom Produkteigentümer priorisiert 10
Sprint Start Meeting Das Scrum-Team nimmt das Sprint-Ziel und entscheidet welche Arbeiten zur Erreichung notwendig sind Das Team organisiert sich auf eine Weise, die es ermöglicht das Sprint-Ziel zu erreichen Manager weist keine Arbeiten zu Manager entscheiden Nichts für das Team Das Sprint-Backlog wird erstellt 11
Das Backlog während des Sprint Änderungen Das Team nimmt - wenn nötig - neue Aufgaben auf, die zum Erreichen des Sprint- Ziels notwendig sind Das Team kann unnötige Aufgaben entfernen Aber: Das Sprint-Backlog kann nur durch das Team aktualisiert werden Zeitschätzungen werden täglich aktualisiert 12
Burndown Chart 13
Trotz Agiler Entwicklung braucht man Dokumente! Als Dokument Lastenheft (aus der Sicht des Auftraggebers) Pflichtenheft (aus der Sicht des Auftragnehmers) Projektplan (Präsentation) Als Listen / Programme Fehlerliste Source code control 14
Was gehört alles zum Pflichtenheft? 15
Was gehört alles zum Pflichtenheft? --> Nichts vom wie - alles vom was Pflichtenheft 16
Das Pflichtenheft ist fertig - und nun? Testen des Pflichtenheftes Kunden : Hallway Testing, Produkt-Validierung...und daraus lernen bzw. das Produkt überarbeiten Für Profis/größere Firmen: QFD (Quality Function Deployment): Bewerten der Produkteigenschaften Projektplan - für alle Abteilungen: Entwicklung, Test, Dokumentation,... Design-Spezifikation / Technische Beschreibung / Technical Specification Produkt-Architektur Komponenten-Design-Spezifikation Aufwandsabschätzung Und gerne übersehen: Risiko-Management-Plan
Änderungen Prozesse: Schaffen Sie sich Regeln, wann und wie Sie Änderungen OK finden Änderungskontrolle (Change Control Process) Regeln z.b.: Nur Änderungen mit Aufwand kleiner 1 Tag Änderungsverfolgung: Mitschreiben, Protokollieren, ob Änderung wie geplant verlaufen ist (um zu lernen, nicht um jemanden zu bestrafen) Keine Änderungen ist keine Alternative Zu viel Verwaltung ist nicht gut, da Menschen leicht dazu neigen, dann den Prozess und die Verwaltung wichtiger zu nehmen als das eigentliche Ziel