In Projekten, in denen mehrere Personen oder Abteilungen am Aufbau eines Enteo Softwareverteilungs-System beteiligt sind, steht der Verantwortliche oft vor der Herausforderung, den Kommunikationsfluss zwischen den Verantwortlichen zu steuern. Sehr schnell werden hier verschiedene Systeme aufgebaut, die dieses Problem mehr oder weniger lösen sollen. Oft werden dieses Möglichkeiten aber nicht von allen im Projekt beteiligten Personen wahrgenommen, wofür es auch allzu häufig sehr triftige Gründe gibt:

Konzepte

 Ein Konzept mit mehreren Dutzend (oder hundert) Seiten kann ich definitiv nicht jedem im Projekt aufbürden. Splitte ich die Konzepte sinnvoll thematisch auf, muss ich mich als Verantwortlicher darum kümmern den Lesestoff den passenden Personen zuzuteilen. Dazu kommt, dass es schwierig ist, kleine Änderungen (z.B. ein Wert in der Infrastruktur) im Konzept zu pflegen und an alle zu kommunizieren. Ein Konzept ist absolut erfolgsentscheidend für ein komplexes Projekt und hilfreich für die Einarbeitung neuer Mitarbeiter, aber nicht nützlich um viele kleine Changes sauber zu protokollieren.

Sharepoint/ Wiki/ MS-Project / …

Oft werden diverse Backendsysteme aufgebaut, um die schnelle Kommunikation und Dokumentation innerhalb eines Projektes zu erledigen. Alle Systeme haben aber den gemeinsamen Nachteil, dass Sie Experten Know-How benötigen, um administriert zu werden und Know-How auf der Bedienerseite aufgebaut werden muss. Auch für diese Systeme gilt, dass Sie einem Projekt durchaus dienlich sind, aber auch hier ist ein vollständiges Tracking aller Changes extrem schwierig.

Nutzung eines Helpdesk

 Eigentlich ein naheliegender Gedanke: nachdem einmal die Basis eines Enteo-Systems implementiert ist, werden alle Änderungen im hauseigenen Ticketsystem aufgenommen und dann erst durchgeführt. Ich persönlich bin ein Freund dieses Ansatzes, verstehe aber auch die Kritikpunkte, die im Laufe meiner Projekte dazu zu hören bekam:

• Aufgrund der Konformität zu den ITIL Prozessen, trifft man kaum noch einfache Ticketsysteme an. Dies führt dazu, dass für jede kleine Änderung ein Incident mit allem nachgelagerten Aufwand eröffnet werden muss.

• Die Servicemanagement Tools sind oft nicht für den internen Gebrauch innerhalb der IT gedacht (was mir immer wieder ein Rätsel ist…). Dies äußert sich in nicht vorhandenen Berechtigungen für das Projektteam, keinen schreibenden Zugriff auf die KB, etc.

Regelmässige Meetings

Ebenfalls durchaus sinnvoll, speziell wenn die Projektmitarbeiter räumlich getrennt arbeiten. Meetings sind hilfreich um Strategien zur Problemlösung zu besprechen, allgemeine organisatorische Dinge zu kommunizieren, die sozialen Belange des Teams zu pflegen, aber nicht, um zu kommunizieren, dass beim Pilotuser Herrn Chang in Peking ein Problem in der Kommunikation zwischen SAP und Office beim Drucken von eingebetteten Visio-Grafiken auftritt.

Lösungsansatz

Wir haben nun verschiedene durchaus hilfreiche Methoden kennengelernt, um die Kommunikation innerhalb eines Projektteams zu steuern und gesehen, dass es da eine eklatante Lücke gibt, die oft genug dafür sorgt, dass Probleme innerhalb des Projektes entstehen. Ein Mitarbeiter fällt aus, die Bedeutung eines Registry Keys, der vor 4 Monaten gesetzt wurde, ist nicht bekannt, es entstehen Phänomene auf einer Anzahl Systeme die aufgrund einer nicht dokumentieren Änderung entstanden ist…

Ich denke, es wissen alle Leser, wovon ich hier schreibe. Um diesem Problem Herr zu werden, möchte ich einen weiteren Lösungsansatz vorstellen, der mir mindestens teilweise in den Projekten geholfen hat, diese Lücke zu schließen.

Seit Jahren nutzt speziell die Open Source Gemeinschaft Bugtracker Systeme, um Änderungen an Programmen, Sourcecode, Dokumentationen, etc. zu verwalten und an die Öffentlichkeit zu kommunizieren. Das populärste dieser Projekte ist sicherlich der Bugzilla, der entwickelt wurde, um die Changes in den Softwareprojekten der Mozilla Community zu tracken. Diese Bugtracker Systeme haben einige deutliche Vorteile:

• Die Installation & Administration gestaltet sich in der Regel sehr einfach. Die vollständige Installation und Ersteinrichtung ist innerhalb eines halben Tages erledigt.

• Die Bedienung ist sehr intuitiv und erfordert (für einen IT Mitarbeiter) keinen Schulungsaufwand.

• Der Aufwand zum einpflegen eines „Bugs“ ist nahezu identisch zum Schreiben einer E-Mail.

• Alle Bugtracker Systeme unterstützen SMTP Mail. Über diese Mechanismus können Reports versandt und Benutzer informiert werden, wenn sich Änderungen an Ihren „Bugs“ ergeben.

Ich persönlich habe sehr gute Erfahrungen mit Bugtracker.NET gemacht. Auch das zuvor genannte BugZilla erfüllt seinen Zweck, es empfiehlt sich aber die Installation auf einer Linux Platform. Die NWC-Services nutzt Flyspray als Bugtracking System für Softwareprojekte, da hier eine Integration die Joomla Engine möglich ist. Dieser meisten dieser Systeme sind kostenlos verfügbar, die Bedienung unterscheidet sich nur marginal voneinander.

Grundsätzlich werden in den Bugtracker Systeme Projekte (z.B. Enteo, AD, SQL) aufgebaut, innerhalb derer wiederum Kategorien (für Enteo: Packaging, Infrastruktur, Targeting), Berechtigungen (Reporter, Reader, Admin) und Metadaten (Bugstatus, Priorität eines Bugs, Datumswerte) verlinkt sind.

Dabei wird für jede Kategorie ein Verantwortlicher bestimmt, der automatisch E-Mails über Änderungen bekommt und den Status der Einträge in der jeweiligen Kategorie überwacht. Dass auch ein Verantwortlicher für mehrere oder alle Kategorien sein

Jede wichtige gewünschte Änderung im Projekt wird nun in dem Bugtracker System (dabei muss es sich nicht zwangsläufig um einen Bug handeln) eingepflegt. Ist die Änderung durchgeführt, wird dies über den Status protokolliert. Natürlich sollte dieses System mit ein wenig Pragmatismus betrieben werden. Wird einfach eine neue Applikation paketiert, handelt es sich eher um eine Änderung im Rahmen des Regelbetriebs. Wird eine neue Site eingepflegt um Server mit einer anderen Repository Cache zu versorgen, ist das durchaus eines Eintrags würdig.

Da ein Bugtracker aber eben nur auf einzelne Changes bezogen ist, sollte er auch nur dafür verwendet werden. Durch die Einführung eines Bugtracker darf weder die persönliche Kommunikation noch die Pflege eines gemeinsamen Konzeptes leiden. Somit teilt sich ein Projekt wie folgt auf:

Die Gewichtung ist natürlich nur exemplarisch und unterscheidet sich von Projekt zu Projekt. In manchen Projekten macht der Einsatz eines Projektmanagementtools wenig Sinn, in anderen ist der persönliche Austausch dadurch gegeben, dass alle Mitarbeiter im gleichen Büro sitzen und somit dedizierte Jourfix Meetings entfallen können.

Somit erfordert auch dieses System ein wenig Training, bis es auf die Bedürfnisse des Projektes abgestimmt hat. Vor allem in der ersten Zeit, muss der Projektverantwortliche seine Mitarbeiter dazu auffordern, das Bugtracker System auch zu nutzen. Meine Erfahrung ist aber, dass die meisten Personen das System nach einiger Zeit gerne verwenden und die Vorteile sehen. Man kann nun einen Bug auch erst mal aufschreiben, anstatt sich sofort darum kümmern zu müssen, man kann über die Volltextsuche nach speziellen Einstellungen suchen, die Mitarbeiter X vor 4 Monaten getätigt hat. Einige Male hat sich dieses System auch so etabliert, dass es für andere Projekte verwendet wurde, oder in den Regelbetrieb übernommen wurde.

Ich hoffe, ich konnte mit diesem Artikel einen wertvollen Betrag zu dem eine oder anderen Projekt leisten und freue mich über Erfahrungen und Kommentare zu diesem Eintrag.