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 #

Kosten/Aufwand
Zeit
Funktionalität
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.