2006/05/02

Auf Grundlage meiner Erfahrungen mit - auch kritischen - Projekten bevorzuge ich Projekte nach den Grundsätzen der agilen Softwareentwicklung und eXtrem Programming, gekoppelt an klaren und offenen formalen Richtlinien.

• Die Qualität des Softwareproduktes soll sich schon zu einem frühen Zeitpunkt in Tests, Konfigurationsmanagement, Logging, System- und Nutzerdokumentation niederschlagen.
• Als Entwicklungsleiter muss man auch inhaltlich im Zentrum der Softwareentwicklung stehen. Der Entwicklungsleiter muss sämtliche Aspekte des Softwareprozesses verstehen.
  
• Design und wichtige technische Details werden innerhalb der Entwicklergruppe diskutiert. Im Zweifelsfalle entscheidet der Entwicklungsleiter.
  
• Der Einsatz von Unittests, die in einem automatischen Regressionstest eingebunden werden können, ist unabdingbar.
  
• Der Einsatz einer Versionsverwaltung ist unabdingbar und sollte alle projektrelevanten Dokumente umfassen.
  
• Designwerkzeugen und CASE-Tools (wie etwa Rational Rose) sollen nicht die Softwareentwicklung determinieren, sondern umgekehrt. Reine UML Diagramme überdecken oft die in dem Projekt innewohnende zu lösende Probleme. Klare deutsche (oder englische) Sätze, illustriert mit UML Diagrammen, Pseudocode oder Prototypen müssen ein klares Verständnis innerhalb des Projektteams und bei dem Kunden vermitteln.
  Softwareentwicklung soll in media res geschehen.
  
• Entwicklung möglichst aus 'produktiven' Prototypen.
  
• Mit den Mitarbeitern (ggf. mit den Kunden) werden Wochen- und Monatsziele vereinbart und jeweils nach Ablauf kontrolliert und protokolliert.
  Probleme können frühzeitig erkannt werden, unrealistische Aufwandseinschätzungen können korrigiert werden.
  
• Externe Schulungen können die Aus- und Weiterbildung innerhalb eines Teams nicht ersetzen, höchstens ergänzen. Von der Projekt- und Entwicklungsleitung müssen die Rahmenbedingungen geschaffen werden, damit die Weiterbildung von Anfängern und Fortgeschrittenen den Erfahrenen nicht als Last und Strafe vorkommt.
  In der Vergangenheit habe ich zwischen 5 - 50% meiner Zeit in Projekten mit Weiterbildung und Coaching verbracht.
  
• In komplexen Projekten, in denen keine adäquaten Aufgaben gefunden werden können, haben Anfänger (Umschüler) nichts zu suchen.
  
• Vom Hinfallen lernt man das Laufen nicht. Einer der wichtigsten Motivation eines Entwicklers ist der Erfolg des Projektes.
  

• Bei größeren Projekte, gestufte Pflichtenhefte mit jeweiliger Beschreibung des Abnahmeprozesses.
  
• Dokumentation des Projektverlaufes mittels eines Projekttagebuches.
  Das für Entwickler und Kunden möglichst offene Projekttagebuch enthält folgende Elemente:
  
  • Pflichtenhefte, Spezifikationen.
    
  • Projektplanung und Personaleinsatzplanung.
    
  • Kommunikationsprotokolle mit Kunden (Jour Fixe, Telefonate).
    
  • Teambesprechungen mit Wochenzielen (siehe unten).
    
  • Testprotokolle, Offene Punkte, Fehlerliste.
    
  • Bei Produktionsbetreuung, wichtige Logfiles Fehlerberichte.
    
  Email und Word-Dateien haben oft den Charakter von Write-only Dokumente. Im optimalen Fall ist das Projekttagebuch ein Intranet, an dem sich alle Projektbeteiligten einbringen können.
  
• Enger Kontakt zu Kunden, um Fehlentwicklungen zu vermeiden.
  
• Hierbei möglichst ehrlichen und offener Kommunikation mit Kunden.
  
• Eigentlich banal aber dennoch in der Praxis problematisch: Besprechungen innerhalb des Projektes oder mit dem Kunden in möglichst kleinem Kreis. Ergebnisse werden im Projekttagebuch festgehalten, die für alle Beteiligten Pflichtlektüre sein sollte.
  
• Ein großes Problem bei Client-Server Projekten, bei denen der Kunde mittels des Frontends mit dem Produkt in Kontakt kommt, ist die relative lange Zeit in der das Projektteam mit Backend und technischer Infrastruktur zu kämpfen hat und aus Sicht des Kunden das Projekt scheinbar nicht vorankommt.
  Mit einem Prototyp, dem Projekttagebuch mit einem transparenten Projektplan kann vor Frustration vorgebeugt werden.
  
• Bei mittleren (> 3 Entwickler) und großen Projekten soll die Rolle des Projektleiters (globale Steuerung des Projektes, Kommunikation mit Geschäftsführung) und Entwicklungsleitung (Leitung/Steuerung des Entwicklerteams, auch inhaltlicher Kopf der Entwicklung) nicht durch die gleiche Person abgedeckt werden.
  Projektleiter und Entwicklungsleiter haben in vielen Aspekten gegensätzliche Interessen zu vertreten. Wenn beide Rollen von einer Person abgedeckt werden, passiert es oft, dass eine der Rollen zum Schaden des Projektes vernachlässigt wird.
  Projekt- und Entwicklungsleiter müssen eine gemeinsame Strategie entwickeln und in ihrem Wirkungskreis umsetzen.

 ProjectForge