Projektmanagement

Anmerkung: Änderungen am Dokument sind noch möglich, bitte prüfen Sie vor abgaben den Änderungsverlauf:

• 2024-10-22 Dokument veröffentlicht.
• 2024-11-05 Risikomanagement entfernt (ist im Spezifikationsdokument)

Übersicht

• Agil
  • Funktionierende Software in jeder Iteration
  • AGs definieren und priorisieren Features
  • AG kann anhand existierender Software herausfinden was gewollte ist

Das erste Treffen

• TB erklärt AG den Prozess
• AG erklärt Projektziele
• AG klärt Rahmenbedingungen
  • Wie/wo muss die Software laufen
  • vorhandene Infrastruktur
  • Zugangsrechte für Sourcecode Repositories etc.
  • Softwarelizenz
  • siehe Spezifikationsdokument
• Welche Qualitätsmerkmale (vgl. QS Vorlesung) sind für das Projekt wichtig?
• Erste Schritte Planen
  • eventuell schon User Storys
  • oft erst Einarbeitung in den Bereich
• Regelmäßige AG Treffen vereinbaren (immer am Ende der Iteration zur Abnahme der alten und Planung der nächsten Iteration)

Bewertungskriterien für ein Erfolgreiches Projektmanagement

Es ist an den Teambegleitungen darauf zu achten, dass die Teams sich an den Prozessen beteiligen. Will oder kann ein Team eine Anforderung nicht umsetzen ist dies zu Dokumentieren, und liegt dann in der Verantwortung des Teams.

Projekt-Verständnis

• Die Projektvision des Auftraggebers ist verstanden.
• Der bisherige Stand des Projekts ist verstanden.
• Die konkreten Projektziele sind definiert.
• Die Stakeholder des Projekts wurden identifiziert.

Projekt-Management-Prozesse

Prozesse

• Es gibt klar definierte Prozesse
  • Wer, Was, Wann, Wie?
• Es wird überprüft, ob Prozesse befolgt werden.
• Es gibt Maßnahmen zur Prozessverbesserung.

Anmerkung:

• Es ist wichtig klarzumachen, dass Prozesse nicht in Stein gemeißelt sind.
• Innerhalb der Lehrveranstaltung ist es wichtig, dass die Studenten darüber sprechen und sich eigene Gedanken machen.
• Wenn solche Dinge festgelegt und -gehalten werden vermeidet das später Streit in der Gruppe.
• Es ist uns egal eine die Methode genannt wird (SCRUM, Agile, ...) wir wollen, dass die Teams beschreiben was sie unter ihren Prozessen verstehen.
• Reflektieren, wie viele Meetings wirklich nötig sind. Diese werden sonst ein Zeitfresser.

Anforderungsverwaltung

• Anforderungen werden in einer sinnvollen Form erfasst.
• Anforderungen werden in einem Backlog abgelegt.
• Es gibt einen Prozess, um Änderungen aufzunehmen.
• Quelle und Entwicklung einer Anforderung ist nachvollziehbar.
• Ergebnisse von Meetings werden protokolliert und abgenommen.
• Anforderungen sind Priorisiert.

Messung und Analyse

• Zeiten werden erfasst.
• Zeiten werden kategorisiert.
• Erfasste Daten werden analysiert und Ergebnisse werden diskutiert.
  • Teammitglieder haben etwa gleichen Zeitaufwand (Abweichungen begründet).
  • Das Team weiß, wie viel Zeit in jede Iteration geflossen ist.
  • Es wird eine Velocity berechnet.
  • Es ist klar wie viel Zeit im Projekt „noch übrig“ ist.

Monitoring und Steuerung

• Der Projekt-Fortschritt wird erkennbar gemacht.
• Der Projekt-Fortschritt wird regelmäßig überprüft.
• Es gibt einen Prozess, um auf festgestellte Abweichungen zu reagieren. (insb.: Schätzungen der Restaufwände werden regelmäßig aktualisiert.)
• Jede erledigte Aufgabe hat einen eindeutigen Verantwortlichen.

Konfigurationsverwaltung

• Alle Artefakte stehen unter Versionsverwaltung.

Qualitätssicherung

• Es wurden Ziele identifiziert und der Projektbezug erläutert.
• Es wurden Maßnahmen definiert.
• Ziele und Maßnahmen sind verbunden.
• Systematik der QS ist erkennbar.
• QS-Maßnahmen müssen durchführbar und überprüfbar sein.

Zeitplan

• Alle bekannten Anforderungen sind geschätzt.
• Alle festen Termine wurden identifiziert.
• Es sind Milestones für Abgaben definiert.
• Unterschiedliche Kompetenzverteilung im Team ist berücksichtigt.
• Freizeiten sind berücksichtigt (Urlaub, Klausuren, etc.)
• Abgaben für die Uni (Dokumente und Vorträge) wurden sinnvoll berücksichtigt.

Interner Entwicklungsprozess

• Es gibt klare Kommunikationswege, um den Overhead zu minimieren.
• Es gibt einen Review-Prozess für Code.
• Es gibt einen Review-Prozess für Design Entscheidungen.
• Es gibt einen Test-Prozess für das Projekt.