Sigi Herzog
Dieser Gesamtentwicklungsprozess hat zu einem wesentlichen Teil mit Kommunikation, aber auch zu einem großen Teil mit Management von Dokumenten zu tun. Dokumente müssen erstellt, überarbeitet, weitergegeben und schlussendlich abgelegt werden und zwar in einer Form, die es allen Projektbeteiligten ermöglicht jederzeit darauf zuzugreifen.
Da sich die Firma Uptime in der Entwicklung von Software (Web) Projekten hauptsächlich auf Open Source Software (OSS) stützt, lag es nahe sich auch um OSS Tools für oben genannte Anforderungen umzusehen. (Vor- und Nachteile von OSS wurden im MONITOR bereits mehrfach thematisiert, zuletzt im Heft 1/03 ab Seite 52, daher werde ich hier darauf nicht näher eingehen.)
In jeder dieser Entwicklungsphasen werden spezielle Tools verwendet, um in den einzelnen Phasen optimale Ergebnisse zu erreichen. Neben den Fragen, die sich in diesem Zusammenhang ergeben (Wie werden alle Phasen aus der Sicht des Projektmanagements integriert? Welche Prozesse sind dafür notwendig? Wie schnell können diese Prozesse in ein Team integriert werden? Usf.) ist vor allem auch die Betrachtung des Umfelds wichtig, in dem Projekte abgewickelt werden, die auf diese Tools zurückgreifen: Welche Entwicklungsmethodik wird verwendet? Wie groß ist das Projektteam? Wo liegt die Erfahrung des Teams? Mit welchen externen Teams wird zusammengearbeitet? Welche Tools werden in diesen Teams verwendet? Wie ist die Anbindung externer Teams?
Alle diese Tools habe eines gemeinsam: Es handelt sich um webbasierte Client Server Lösungen. Das heißt, sämtliche in den einzelnen Tools vorhandenen Dokumente (HTML-Seiten) können direkt adressiert werden. Auf diese Weise können durch einen einfachen Link zwischen all diesen Tools Verbindungen zu den gewünschten Dokumenten hergestellt werden, so dass über jeden beliebigen Browser darauf zugegriffen werden kann. Da sämtliche Tools ein Login erfordern, funktioniert diese Möglichkeit auch über das firmeneigene Netzwerk hinaus und ist - zumindest auf Client Seite - völlig Plattform unabhängig. Ein nicht zu unterschätzender Vorteil, was die Annahme der Tools, vor allem aber die Einarbeitungszeit und Wartung betrifft.
Die hier angesprochenen Tools werden in folgendem Entwicklungsumfeld eingesetzt: Die meisten Projekte haben eine Teamgröße von vier bis zehn Personen mit unterschiedlichster Erfahrung. Sämtliche ProjektmitarbeiterInnen befinden sich den Großteil der Zeit an einem Standort. Bei der Entwicklungsmethodik wurden starke Anlehnungen an agilen Entwicklungsmethoden (extreme Programming, u.a.) genommen, da die meisten Projekte in kurzen überschaubaren Releases abgewickelt werden.
Es hat sich gezeigt, dass für diese Teamgrößen und für diese Methodik diese Tools völlig ausreichend sind und sie auch - im Gegensatz zu integrierten Gesamtlösungen - genug Spielräume für kürzere und effizientere Problemlösungen zulassen. Nicht zu vernachlässigen ist in jedem Fall der Kommunikationsaufwand, der aber bei agilen Entwicklungsmethoden bereits vorausgesetzt werden muss. Doch nun zu den Tools im einzelnen.
Mailinglisten
Da in jedem Projekt der Anteil der Projektkommunikation einen wesentlichen Anteil einnimmt, stellt sich zuerst die Frage wie wird in dem Projekt hauptsächlich kommuniziert. Wenig überraschend, dass dabei E-Mail einen wesentlichen Anteil hat und jeder Projektmitarbeiter - inklusive Kunden - seinen präferierten Mailer (Outlook, Mozilla, Entourage, Mutt, ...) verwenden will und soll. Eine wesentliche Frage ist auch, wie auf bereits versendete Mail zugegriffen werden kann. Dies ist vor allem für später hinzugekommene Projektmitglieder relevant.
Da E-Mail eine der frühesten Anwendungen und neben dem Web die Anwendung des Internets schlechthin ist, war es nicht weiter schwierig hier zu einer Lösung zu gelangen. Daher ist es auch nicht weiter überraschend, eine Mailingliste mit zusätzlicher Archivfunktion für die angeführten Zwecke einzuführen (Sympa, http://www.sympa.org). Jedes Projekt erhält eine eigene Mailingliste, auf die jeder Projektmitarbeiter - einschließlich des Kunden - subskribiert ist. Jeder Projektmitarbeiter hat somit die Möglichkeit sämtliche E-Mail Kommunikation zu verfolgen. Neue Projektmitglieder haben die Möglichkeit wichtige Informationen über das Archiv - via Webbrowser - zu erreichen. Das Archiv hat - neben anderen Möglichkeiten - eine integrierte Suche, so dass auch über diesen Weg Information effizient gefunden werden kann. Da die einzelnen Mails als HTML-Seite abgespeichert werden, können die einzelnen Mails auch direkt via URL verlinkt werden. Eine nicht zu unterschätzende einfache (!) Möglichkeit, ohne die das WWW nicht denkbar wäre.
Bug Tracking
Ein weiteres typisches und unvermeidliches Problem ist die Verfolgung von Fehlern. Aufgrund der Erfahrung unserer Entwickler wurden wir sehr schnell auf ein Produkt aufmerksam, mit dem Bugs sehr schnell und ohne aufwändige Einschulung erfasst werden konnten (Mantis, http://mantisbt.sourceforge.net). Die Bedienung erfolgt über jeden beliebigen Webbrowser. Für das Projekt, bei dem dieses System das erste mal getestet wurde, konnte ohne nennenswerte Einarbeitungszeit jeder beteiligte Entwickler damit sofort produktiv sein und einen spürbaren Produktivitätsgewinn erzielen. Weil außerdem der Source Code vorliegt, konnten kleine Anpassungen an das Produkt auch sofort selbst erledigt werden. Das Bugtraq System wächst gleichsam mit den Anforderungen mit.
Versionierung
Da jeder Software Entwicklungsprozess naturgemäß einen iterativen Charakter hat, ist die Verwaltung und Verfolgung von Änderungen in einzelnen Files bis hin zu einzelnen Versionen (Releases) unabdingbar. Dazu gibt es unzählige Versionskontrollprogramme von denen das CVS (Concurrent Versioning System, http://www.cvshome.org) in der Open Source Community wohl das am weitesten verbreitete ist.
Vielleicht denken Sie jetzt sofort an Software-Entwickler, die damit ihre Programme (Quelltext) verwalten - also primär Text - und nicht unbedingt an Projektmanagement, wo es doch hauptsächlich um die Verwaltung von Word-Dokumenten und anderen Dokumenten geht (MS-Excel, MS-Powerpoint, MS-Project, ...) und nicht um "nur" Text-Dokumente. Doch halt! - ein Dokument ist ein Dokument- und das muss nicht zwangsläufig ein Word-Dokument sein! Trifft man diese Annahme, dann reicht aus meiner Erfahrung für die meisten Dokumente ein einfaches ASCII-Format (reiner Text) völlig aus. Damit erscheint auch die Verwaltung durch ein CVS in einem völlig anderen Licht. Es muss hier fairer Weise angemerkt werden, dass auch Binärdateien wie MS-Word Dokumente mit dem CVS verwaltet werden können. Es muss aber dazu gesagt werden, dass praktisch alle Eigenschaften, welche mit dem Vergleichen von Text Files zu tun haben, grundsätzlich bei Binärdaten nicht funktionieren.
Auf alle Files im CVS, egal ob binär oder Text Files kann über ein eignes Webinterface zugegriffen werden. Es besteht die Möglichkeit sich die benötigten Files in verschiedenen Versionen anzusehen und wenn notwendig herunterzuladen. Sogar Vergleiche zwischen einzelnen Versionen sind möglich, solange es sich um Textfiles handelt. Diese Vergleiche können wiederum direkt adressiert werden. So lassen sich sehr komfortabel Änderungen in Dokumenten verfolgen.
Die Tools Mailingliste, Bugtracker und CVS bilden den Kern des Vorgehensmodells. Die im folgenden erwähnten Tools sind in manchen Phasen zusätzlich sehr wertvoll.
Wikis
Als ein nicht zu unterschätzender Teil in allen Projekten gilt die schnelle Aufbereitung von Information für alle Projektmitglieder. Für diesen Fall haben sich Wikis (http://c2.com/cgi/wiki?WelcomeVisitors) bewährt. Wiki ist hawaiianisch und heißt schnell. Die Idee ist die, dass man mittels strukturiertem Text einfach und schnell HTML-Seiten erstellen und zu einer Site integrieren kann. Structured Text ist Text, welcher in einem bestimmten Format in ein Formular eingegeben wird. Zum Beispiel können durch einfaches Voransetzen eines Sterns (*) Listen erzeugt werden. Wikis haben sich vor allem im Bereich der Programmierer etabliert, um Informationen unaufwändig zu sammeln und zur Verfügung zu stellen.
Gallery
Eine immer wiederkehrende Problematik vor allem aus der Sicht eines Projektmanagers ist das Problem eine gemeinsame Sprache innerhalb des Projektes zu finden. Jeder kennt kick-off Meetings bei denen auf Flipcharts lange und ausführlich Diagramme und Szenarien entworfen werden, die nach dem Meeting ungenügend oder falsch kommuniziert werden. Zu diesem Zweck ist es einfach aber sehr effizient die Flipcharts zu fotografieren und danach - nein, nicht per Mail zu versenden, sondern auf einer Gallery (Fotoserver) zur Verfügung zu stellen. Dieser Server bietet nicht nur die Möglichkeit die Bilder direkt zu adressieren, sondern auch die Möglichkeit für alle (berechtigten) User, Kommentare zu den einzelnen Bildern zu schreiben um damit die Verständlichkeit zu erhöhen.
Die hier dargelegten Tools sind ein minimalistischer und auf das notwendigste reduzierter bottom-up Ansatz. Die Erfahrung hat aber gezeigt, dass dieser Ansatz unter den erwähnten Randbedingungen hervorragend funktioniert. Der wichtigste Punkt ist jedoch der, dass es ein gemeinsam erarbeitetes und definiertes Vorgehensmodell gibt, welches von allen Beteiligten akzeptiert und auch eingehalten wird. Denn nur so kann das gesamte Kreativitätspotential der beteiligten Entwickler freigesetzt werden.
Mag. Sigi Herzog arbeitet als IT-Manager bei Uptime Systemlösungen mit dem Schwerpunkt auf Projektmanagement im Bereich Softwareentwicklung
Referenzen
- Mailinglisten: http://www.sympa.org
- Bug Tracking: http://mantisbt.sourceforge.net
- Versionierung CVS: http://www.cvshome.org
- Wiki: http://c2.com/cgi/wiki?WelcomeVisitors
- Gallery: http://gallery.menalto.com
- Agile Entwicklungsmethoden: http://www.agilealliance.com/home
- Open Source: http://www.opensource.org




1/2012
8/2011
7/2011


