Kennen Sie die folgende Situation? Ein Software Projekt wird neu gestartet und die einzelnen Aufgaben werden im Projektteam verteilt. Irgendwann sind (fast) alle Rollen vergeben, allerdings hat niemand an das Konfigurationsmanagement gedacht. Diese Rolle wird dann noch schnell dem Projektleiter zugeteilt, den, so die Annahme, da ist eh nicht viel zu tun und daher kann der Projektleiter diesen Job noch leicht nebenbei erledigen.
Dann wird das Projekt gestartet, und für recht lange Zeit läuft das Projekt gut, obwohl der Projektleiter im Alltagsgeschäft nicht Zeit findet sich um das Konfigurationsmanagement zu kümmern. Selbst die erste Lieferung an den Kunden kann erfolgreich durchgeführt werden.
Je komplexer und umfangreicher das Projekt aber ist, desto eher beginnt nun aber eine Phase in der man realisiert, dass das Projekt ohne Konfigurationsmanagement zunehmend schwieriger zu steuern ist. Immer häufiger treten Probleme auf, bei der Zuordnung von Tests zur Software. Die Requirements passen nie richtig zu den Tests und der Software. Selbst bei den Planungsdokumenten finden sich immer mehr Inkonsistenzen.
Nun rückt der Zeitpunkt näher an dem das Projektteam und der Projektleiter realisieren, dass das Projekt ausser Kontrolle zu geraten droht, wenn nicht die Rolle des Konfigurationsmanagers aktiv ausgefüllt wird. Der Projektleiter merkt, dass die Aufgabe von Ihm „so nebenbei“ nicht zu erledigen ist und es wird dann oft das Team vergrößert und ein Konfigurationsmanager eingesetzt.
Zu diesem Zeitpunkt im Projekt ist es dann oft eine große Herausforderung eine passende Konfigurationsmanagement Strategie auszuarbeiten und umzusetzen. Zum Einen besteht ein enormer Zeitdruck und zum Anderen sind zu so späten Zeitpunkten in Projekten oft viele Dinge auch nicht mehr zu ändern.
Die Grafik illustriert die Aufgabenstellung.

Konfigurationsmanagement statt Versionskontrolle

Über Tool-Grenzen hinweg müssen unterschiedlichste Artefakte zu einem Konfigurationsstand zusammengefasst werden. Hier wird eine Strategie für die Vorgehensweise benötigt. Der Einsatz von Tools ist notwendig aber nicht hinreichend um die Aufgabenstellung erfolgreich zu bewältigen. Nachfolgend eine Auswahl von Fragen die man sich  bei der Ausarbeitung der Konfigurationsmanagement-Strategie stellen sollte:

1. Was ist der Inhalt eines Konfigurationsstandes?
2. Wie oft wird ein neuer Konfigurationsstand erzeugt?
3. Welche Namenskonventionen für „Labels“ ist geschickt und hilfreich?
4. Wie werden Artefakte die in verschiedenen Tools entstehen übergreifend zu einem Konfigurationsstand zusammengefasst?
5. Was bestimmt die Synchronisierung zwischen Änderungsmanagement und Konfigurationsmanagement?
6. Wie wird das Konfigurationsmanagement während der Produktentwicklungsphase mit der langfristigen Archivierung der Entwicklungsergebnisse abgestimmt?

Wenn Sie zumindest diese Fragen zu einem frühen Projektzeitpunkt pro-aktiv lösen, steht einem erfolgreichen Konfigurationsmanagement in Ihrem Projekt nichts mehr im Wege und Sie können jeder Zeit den Stand Ihrer Entwicklung abfragen und feststellen.

Ihre individuellen Fragen zum Konfigurations- und Änderungsmanagement beantworten wir gerne in einem ersten, kostenlosen 30min Beratungsgespräch!
Vereinbaren Sie gleich einen Termin: Eine kurze Mail an info[at]heicon-ulm.de genügt, oder greifen Sie gleich zum Telefonhörer: +49 (0) 7353 981 781 (Mo bis Fr 08:00 – 18:00Uhr).