Projektmanagement Empfehlungen

Verstehen der Kundenwünsche

Am Besten Feedback holen vom Kunden. Man sollte sich nicht nur auf den Kundenproxy verlassen.

So früh wie möglich formal werden

Beim Zeichnen der Domain-Modells kommen Fragen auf. Auch Halbformale Texte wie Use Cases, Risikoliste oder Tests bieten einen Mehrwert.

Stabile Requirements von Beginn bis Ende sind eine Illusion, denn Software ist immer was Neues - Altbekanntes würde fixfertig gekauft.

Spätestens zum Zeitpunkt von End of Elaboration sollte der Scope fixiert sein, denn anonsten wird es schwer, die vier Projektvariablen einzuhalten. Deshalb kein Projekt über mehr als neun Monate. Wenn es länger dauert, dann mehrere Projekt draus machen und squenziell abarbeiten.

Der Projektleiter muss den Scope im Griff haben

Die vier Projektvariablen

  1. Kosten/Aufwand
  2. Zeit
  3. Funktionalität
  4. Qualität
  • Wenn die Zeit nicht reicht, kann der Projektumfang reduziert oder in Teilprojekt zerlegt werden, die dann sequenziell abgearbeitet werden.
  • Alternativ kann der Zeitplan verlängert werden
  • Mehr Leute funktioniert selten (Brooks’Law). Denn diese Leute müssen zuerst eingelernt werden, müssen die bereits erstellten Lösungen verstehen und dürfen sich dann nicht gegenseitig in den Weg kommen.
  • Keine dirty Lösung, da das dann zur technischen Schuld wird und einem dann irgendwann einholt.

Software ist Kommunikations-intensiv

Management by walking around. Ansonsten noch ein wiki und/oder daily standup meetings)

Entfernung ist teuer

Dr. Dobb’s Journal, December 02, 2008, http://www.ddj.com/ „The Distributed Agile Team - Communication challenges are your greatest risk“, by Scott W. Ambler

Gehen Sie täglich auf die Baustelle

  • Wer macht was?
  • Wer ist auf der Baustelle?
  • Wie weit sind wir?

Ausserdem ist die Baustelle auch:

  • Der Programm-Code
  • Versionskontroll-Werkzeuge: Wer macht was? Was wird oft angefasst?
  • Bug Tracking
  • Architektur-Dokumente

Prioritäten

Es soll eine Definition der Priorität geben.

Immer iterativ vorgehen

  • Durch die Zwischenresultate wird ein positives Gefühl vermittelt.
  • Die kontinuierliche Integration ist einfacher als eine big bang Integration
  • Fehler und Fehleinschätzungen werden früher erkannt.

Feedback vom Kunden

Inspect - Adapt

Scrum kennt dafür die Begriffe “Inspect - Adapt”, d.h. man schaut, wie es steht, und passt gegebenenfalls die Richtung an.

Projekt-Kontrolle

Budgetkontrolle plus Fortschrittskontrolle Management by walking around; Anwesenheit schafft Verbindlichkeit Kein Abtauchen (seit drei Wochen programmiert Joachim…)

Regelmässig aufschreiben:

  • Meilensteine (erreicht/verpasst)
  • Anzahl Mitarbeitende
  • Ausgegebenes Geld
  • Schwierigkeiten
  • Besondere Vorfälle

Wenn Sie regelmässig eine Art Dump der ganzen Projektdaten machen, dann können Sie später nachvollziehen, wie das Projekt gelaufen ist.

Daily Build

Continuous Integration sind ’Daily Builds’ die jedesmal ablaufen, wenn jemand eine Änderung auf den Hauptzweig des Repositories gepusht hat, das kann – uns soll – mehrmals täglich der Fall sein.

Die üblichen Werkzeuge

  • Versionskontrolle
  • Verwaltung der Arbeitspakete
  • Unit Testing Frameworks
  • Metriken und Code Prüfer wie findbugs, checkstyle usw.
  • Separater Build Server

Build Breaks and Branches

Branch or not to Branch" Nicht zuviele (zentrale) Seitenzweige, denn Verzweigungen können den Punkt „wie weit sind wir?“ stark verwedeln.

Mindestens Daily Build + Regelmässige Releases: alle 2-3 Wochen für das Team bei den Sprints, mit Demo für den Kunden-Proxy; alle 2-3 Monate für die Endkunden zum Testen. Rollouts für Endkunden finden manchmal sogar noch seltener statt, das hängt stark von der Umgebung ab.

Zurück
Weiter