Projektmanagement Basic

Epics sind ProductBacklog-Items.

Epics sind frei von technisch oder fachlichen Umsetzungsdetails. Anforderungen werden grob als Epics formuliert.

Diese müssen bei der Sprintplanung in einzelne UserStories zerlegt werden.

Product Owner

• neue Einträge (Anforderungen) werden erfasst
• Einträge werden gelöscht bzw. korrigiert/ergänzt
• bestehende Einträge bei Bedarf neu schätzen
• neue Priorisierung der Einträge (nach Nutzen, Risiko und Notwendigkeit) im ProductBacklog.

So wird das Changemanagement in den normalen Projektablauf vollständig integriert. Das grooming ist Voraussetzung für das SprintPlanning.

Detailed Apropriately (angemessen detailiert)

Estimated (geschätzt)

Emergent (entwickelt sich, wird gepflegt)

Prioritized (priorisiert)

• Rahmenplanung
• aktualisierten Risikobewertung
• Rückstande aus dem SprintReview
• priorisierter ProductBacklog

Es wird überprüft wie viele ProductBacklog-Items in den SprintBacklog übernommen werden können sodass:

• ein sinnvolles Sprintziel (in sich geschlossen, testbar, shippable),
• mit den verfügbaren Ressourcen,
• in der vorgesehenen Timebox

erreicht werden kann.

UserStories werden aus der Benutzersicht erstellt:

"Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen>"

In der Sprintplanung werden alle Stories um Akzeptanzkriterien und Aufwand für die Umsetzung (in Personen-Tage) ergänzt.

Beispiel: Als Student/in will ich mich online zu einer Vorlesung anmelden, sodass ich einen Platz in der Übung erhalte.

Risiko ist die kalkulierte Prognose eines möglichen Schadens (bzw. Verlust eines Gewinns).

Ein Risiko ist ein Problem, dass erst noch auftreten muss.

Ein Problem ist ein Risiko, das eingetreten ist.

Hinweis: Ein Risiko kann – muss aber nicht – das Projekt beeinflussen.

Technische Risiken:

• Zu wenig Know-how zu einer Technologie
• Technische Spezifikation von Produkten nicht korrekt
• Termintreue und Qualität von Lieferanten
• Patente von Mitbewerbern
• System wird gehackt

Implementierungsrisiken:

• Anforderungen ändern sich oder Konflikte nicht aufgelöst
• Architektur & Design falsch
• Entwicklungsprozess wird nicht beherrscht

Wirtschaftliche, Industrielle und Geschäftsrisiken:

• Ressourcen stehen nicht zur Verfügung
• Änderung am Markt
• Mitbewerber haben bessere Produkte
• Verlust an kritischem Knowhow durch Mitarbeiterfluktuation
• Nachfrage am Markt für mein Produkt

Ziele des Risikomanagement

Risiken frühzeitig erkennen um sie zu bewerten und dann agieren zu können.

• Potenzielle Probleme vor dem Auftreten erkennen
• Massnahmen ergreifen, damit diese Probleme nicht auftreten
• Risiken kontrollieren, nicht Risiken vermeiden!
• Frühzeitig an den Ursachen der wichtigsten Risiken arbeiten
• Gutes Projektmanagement minimiert Risiken

1. Identifizieren (Technisch, Wirtschaftlich, Implementierung)
2. Analysieren (Ursachen, Eintrittswahrscheinlichkeit, Schadensmass)
3. Priorisieren (Risikoeinstufung – Relevant oder nicht, Verantwortung festlegen)
4. Massnahmen erarbeiten (Risikovermeidung, Schadensreduzierung)
5. Überwachen (Regelmässig bewerten, Massnahmen initiieren, Wirksamkeit der Massnahmen überprüfen)

Vermeiden: Eintrittswahrscheinlichkeit reduzieren

Begrenzen: Auswirkungen abschwächen, Eventualfallplan erarbeiten

Behandeln: Zusätzlicher Aufwand einstecken um Wahrscheinlichkeit und Auswirkungen zu reduzieren, Risikohafte Tätigkeiten früh einplanen, bei Eintritt gemäss Eventualfallplan agieren

Ignorieren: (you know what's gonna happen... =P)

Die Projektkontrolle umfasst alle Aktivitäten, um projektbezogene Abweichungen zwischen dem Plan- und dem IST-Zustand aufzudecken. Die Projektkontrolle bietet nebst einer guten Zielvorgabe die Grundlage für eine erfolgsversprechende Projektplanung und -steuerung.

Das Ziel wurde innerhalb des vorgegebenen Kosten- und Zeitbudget erreicht.

• Linien-PO
• Stab-Linien-PO
• Matrix-PO

• Projektplanung
• Konfig.-Management
• QS Planung
• Test- und Abnahmeplanung
• Entwurf
• Code
• Testprotokolle
• Anforderungen
• Installation
• Betrieb

Projektleiter

• Initialisierungs- und Einführungsphase
• Rahmenplanung, Organisation, Meilensteine, Releases & Einführung

Product Owner

• Konzeptions- und Realisierungsphase
• ProductBacklog-Pflege & -Priorisierung, Sprint-Planung & -Abnahme

Scrum Master

• Leader für Team und P-Owner
• Unterstützt korrektes Vorgehen und sichert Qualität

Scrum Team

• Entwickler: Selbstorganisiert und eigenverantwortlich entwerfen, erstellen, testen

Hinweise: Ein Mitglied kann auch mehrere Rollen wahrnehmen. Scrum-Master wird nicht zwingend benötigt.

S.M.A.R.T

Spezifisch (konkret/Rahmenbedingung)

Messbar (Qualität/Quantität)

Angemessen (besteht ein Bedarf)

Realistisch (erreichbar)

Terminiert (zeitlicher Rahmen)

Arbeitsergebnisse die das Projekt abzuliefern hat.

Resultate müssen präzise und vollständig definieret werden.

Resultate sind keine Aktivitäten!

Zeitpunkt an dem ein vorher festgelegtes, messbares Zwischenergebnis vorliegen sollte.

z.B. Prototyp, Releases, Testprotokolle.

Ein Meilenstein ist erreicht, wenn die geforderten Dokumente vorliegen und überprüft wurden.

Meilensteine sind ein Kontrollelement.

Damit sollen Probleme rechtzeitig erkannt werden.

Gegen aussen kommt ihnen zudem ein show-off-Effekt hinzu. (Promotion)

Eine beschreibende Soll-Aussage über ein System, deren Leistung und Eigenschaften.

Hinweis: Je besser die Anforderung formuliert – je einfacher deren Überprüfbarkeit

1. Titel
2. Description (stichwortartig in aber adäquate tiefe verfasste Beschreibung)
3. Priority (1-high,2-medium,3-low)
4. Status
5. Source (von wem stammt die Anforderung)
6. Complexity
7. Benefit (Stichwortartig Nutzen beschreiben)

Hinweis Status:

- Klassisch: (proposed, accepted, postponed)

- Hybrid: immer proposed (erst bei Sprint Planung wird entschieden ob eine Anforderung umgestezt wird oder nicht)

Hinweis Komplexität:

- Klassisch: PL schätzt Aufwand und Komplexität

- Hybrid: bei der Aufnahme in den SprintBacklog wird Aufwand und Komplexität vom Team abgeschätzt