Project Management Basics

• [Projektimpuls]
• Initialisierungsphase
• Konzeptionsphase
• Realisierungsphase
• Einführungsphase
• [Nutzung]

• [Phase: Ergebnis]
• Initialisierung: Lastenheft
• Analyse: Pflichtenheft
• Entwurf: Softwarearchitektur
• Realisierung: Softwarekomponenten
• Einführung: Handbücher
• Nutzung

Zu jeder Analyse- und Konzeptionsphase gibt es eine Testphase:

• customer requirements (verified by) acceptance tests
• detailed requirements (verified by) system tests
• system design (verified by) integration tests
• implementation/refactoring

• iterativ
  • Aktivitäten des Entwicklungszyklus werden mehrmals durchlaufen
  • bereits aus frühen Iterationen resultieren lauffähige Prototypen
• inkrementell
  • jeder Release hat einen grösseren Funktionsumfang als dessen Vorgänger

• agil, iterativ und inkrementell
• 3 Säulen:
  • Transparenz
  • Überprüfung
  • Anpassung
• unterstützt Entwicklung komplexer Produkte
• besteht aus:
  • Scrum-Teams
  • Rollen
  • Ereignissen
  • Artefakten
  • Regeln
• Feedback maximieren durch iterative und inkrementelle Produktlieferung
  • dadurch steht immer eine potenziell gebrauchsfertige und nutzbare Version des Produktes zur Verfügung

• das "Herz" von Scrum
• gleichmässige und feste Dauer ("timeboxing")
• liefert fertiges, getestetes, potenziell auslieferbares Produktinkrement
• Bestandteile:
  • Sprint Planning
  • Daily Meeting
  • Entwicklungsarbeit
  • Sprint Review (Abnahme)
  • Sprint-Retrospektive
• ermöglichen Vorhersehbarkeit und Anpassung an Planung/Zielsetzung durch regelmässige Überprüfung des Arbeitsfortschritts

• ProductBacklog verwalten (laufend):
  • Einträge erfassen und ausformulieren
  • Einträge nach Fertigstellungsreihenfolge ordnen (priorisieren)
  • Pflege ("Grooming")
• Sprintplanung (zu Beginn jedes Sprints):
  • Inhalt von Sprint-Backlog mit Entwicklungsteam verhandeln
• Sprintabschluss (bei Sprintende):
  • Inkrement gemäss Testplan ("accepted"-Kriterien) freigeben
  • Restarbeit ermitteln und hochrechnen
• keine übergeordnete Projektplanung

• Auswahl der Organisationsform
• Erstellen der Projektorganisation
• Zuordnung von Aufgaben, Kompetenzen, Verantwortung (AKV)
• Festlegen der Form der Informationsvermittlung und Projektdokumentation
• Bestimmung und Zuordnung von Sachmitteln

• Aufbau- und Ablauforganisation zur Abwicklung eines Projekts (temporäre Projektorganisation)
• Grundformen:
  • reine Projektorganisation (Linien-Projektorganisation)
  • Projektkoordination (Stab-Linien-Projektorganisation)
  • Matrix-Projektorganisation
  • Mischformen

• Die Projektmitarbeiter werden für die Dauer des Projektes aus ihrer Linie herausgelöst
• Kompetenzen des Projektleiters:
  • finanziell
  • fachlich
  • disziplinarisch
  • administrativ
• die volle Projektverantwortung liegt beim Projektleiter

• Die Projektmitarbeiter verbleiben in ihrer Linie
• Kompetenzen des Projektleiters:
  • Koordination
  • keine Weisungsbefugnis
• der Projektleiter hat nur eine beschränkte Projektverantwortung

• Die Projektmitarbeiter haben während der Dauer des Projekts zwei Vorgesetzte (Projektleiter/Abteilungsleiter)
• Kompetenzen Projektleiter:
  • Was
  • Wann
• Kompetenzen Linienleiter
  • Wer
  • Wie
  • Wo
  • Womit
• der Projektleiter hat nur eine beschränkte Projektverantwortung

• Software Development agile
• auf Scrum gestützt: iterativ-inkrementelles Vorgehen
• auf eine künstliche Trennung von Konzeption und Realisierung wird verzichtet

• Projektleiter
• ProductOwner
• Scrum Master (optional)
• Scrum Team

In einem Schulprojekt könnten mehrere Rolle von einem Studierenden eingenommen werden.

• Ziel: Was soll mit einem Projekt erreicht werden?
• Was soll nach dem Projekt besser sein als vorher?
• Das Ziel beschreibt einen Zustand/eine Situation.

• Ziel:
  • Aussage über einen angestrebten künftigen Zustand
  • nach Inhalt, Zeit und Ausmass bestimmt
• Anforderung:
  • Aussage über eine Eigenschaft/Leistung
  • eines Produktes, Prozesses oder einer am Projekt beteiligten Person

"S.M.A.R.T"

• specific/spezifisch: klare Rahmenbedingungen
• measurable/messbar: in Qualität und Quantität
• appropriate/angemessen: "richtiges" Ziel gesetzt?
• realistic/realistisch: den Rahmenbedingungen entsprechend erreichbar
• terminated/terminiert: zeitlicher Rahmen vorgegeben

• Arbeitsergebnisse, die ein Projekt abliefern muss
• präzise und vollständig definiert und beschrieben

• für Meilensteinplan
• für Arbeitspakete und Aufwandsschätzung
• für Projektcontrolling
  • Aufwandskontrolle
  • Kontrolle Resultaterreichung
• für Projektreporting

• klassisch:
  • Ziel
  • Hauptresultat
    • Teilresultate
      • Arbeitspakete
• hyprid:
  • Ziel
  • Hauptresultat
    • Sprintziel
    • SprintBacklog-Items

• Software
• Dokumentation
• Prozesse/Betriebsorganisation
• Migration (optional)
• Rollout
• Projektmanagement-Ergebnisse

• geplanter Punkt im Projektablauf
• an dem vorher festgelegte und messbare Zwischenergebnisse vorliegen
• ist erreicht, wenn Artefakte (Prototyp, Release, Testprotokoll etc.) vorliegen
  • und ihre Überprüfung (Review/Test) erfolgreich ist

• Endtermin (von aussen vorgegeben)
• Starttermin (meist später als erhofft)
• Meilensteine gemäss Phasenmodell festlegen
  • Lieferobjekte identifizieren
  • in Meilensteine umformulieren
  • Termine/Deliverables (Artefakte) festlegen

• Gültigkeitsbereich, Handlungsspielraum, Rahmen
• beschreibt
  • was zum Projekt gehört (in scope)
  • und was nicht zum Projekt gehört (out of scope)
  • Einschränkungen (constraints)
• schafft gemeinsames Verständnis
• vermeidet Interpretationsspielraum

• beschreibt:
  • Soll-Aussage über ein System/einen Prozess
  • etwas für einen Beobachter/ein Umsystem Wahrnehmbares
    • Eigenschaft, Leistung (erwünschtes Verhalten)
• je einfacher die Erfüllung geprüft werden kann, desto besser ist eine Anforderung formuliert

• in genügender Tiefe beschreiben, sodass sie nach 3 Monaten noch immer verständlich sind
• klassisch:
  • Anforderungskatalog
  • möglichst vollständig
  • fixe Priorisierung
  • Änderungen nur per Change Management
  • werden zu Arbeitspaketen
• hybrid:
  • Produktbacklog
  • zu ca. 80% grob erfasst
  • flexible Priorisierung
  • Änderungen jederzeit möglich
  • werden zu UserStories

1. Titel/Name (möglichst aussagekräftig)
2. Beschreibung (so viel wie nötig, so wenig wie möglich)
3. Priorität (1: hoch, 2: mittel, 3: tief)
4. Status (proposed, accepted, postponed) [nur im klassischen Vorgehensmodell!]
5. Quelle
6. Komplexität (durch Projektleiter oder per "Planning Poker")
7. Nutzen

• klassisch:
  • Anforderungen fest
  • Zeitraum geplant
  • Aufwand muss evtl. angepasst werden
• hybrid:
  • Anforderungen flexibel
  • "noch ein Sprint?"
  • Aufwand festgelegt und gesteuert

• Projekt-Strukturplanung (Arbeitspakete)
• Ablaufplan (Abhängigkeiten zwischen den Arbeitspaketen)
• Aufwandsplanung (Aufwände abschätzen)
• Ressourcenplanung (Verteilung der Arbeitspakete)
• Kostenplanung

Mit einem Arbeitspaket gelangt man von einer Anforderung zu einem Resultat.

• Titel und Beschreibung
• ca. 2-20 Arbeitstage Aufwand
• Ein Arbeitspaket wird einem (höchstens zwei oder drei) Mitarbeitern zugewiesen
• Ein Mitarbeiter arbeitet gleichzeitig nur an ein bis zwei Arbeitspaketen
• kleine Arbeitspakete (< 2 Tage) sollten zusammengefasst werden

• Arbeitspakete zu Phasen gruppieren
  • In Phase n müssen die Arbeitspakete der Phase n-1 abgearbeitet sein
• Abhängigkeiten innerhalb der Phasen setzen wo nötig
  • ansonsten sind die Arbeitspakete parallel bearbeitbar

• Beschreibung einer Anforderung an eine Software auf hoher Abstraktionsstufe in Alltagssprache.
• Story Decomposition: aus einem Epic werden mehrere User Stories

"D.E.E.P"

• detailed appropriately (sodass umsetzbar)
• estimated (durch das Team)
• emergent (entwickelt sich: "grooming")
• prioritized (Zuordnung zu einem Sprint)

• Formulierung aus Benutzersicht: "Als [Rolle] möchte ich [Ziel/Wunsch], um [Nutzen]."
• Akzeptanzkriterien: "Angenommen [Vorbedingung], wenn [Aktion], dann [Ergebnis]."
• dadurch soll der Aufwand schätzbar werden