Sigi Herzog, <herzog@aleph.at>, Jan. 2k3
Dieser Artikel ist in der Februar Ausgabe (2003) der Zeitschrift Monitor erschienen. http://www.monitor.co.at/index.cfm?storyid=5489
Softwareprojekte durchlaufen mehrere typische Entwicklungsphasen. Je nach verwendetem Entwicklungsmodell gehen diese von der Analyse, Anforderungen, Design und Architektur, Implementation, Test und Abnahme bis hin zur Wartung. Alle diese Entwicklungsphasen werden durch das Projektmanagement begleitet, welches - eingebettet in eine bestimmte Entwicklungsumgebung - den Gesamtentwicklungsprozess steuert. 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 wurde bereits im Jänner- Heft dieser Zeitschrift etwas genauer untersucht, daher werde ich darauf nicht näher eingehen. Der interessierte Leser findet hier unter Referenzen einen entsprechenden Link.
In jeder dieser Entwicklungsphasen werden spezielle Tools verwendet, um in den einzelnen Phasen optimale Ergebnisse zu erreichen. Wie werden aber 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? Zu welchem Preis ist eine Integration zu erreichen? Wie erweiterbar ist dieser Prozess?
Was mir neben diesen Fragen aber viel wichtiger erscheint, ist die Betrachtung des Umfelds 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?
Diese Fragen werde ich versuchen im Folgenden zu (er)klären.
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. Mit anderen Worten: durch einen einfachen Link können zwischen all diesen Tools Verbindungen zu den gewünschten Dokumenten hergestellt werden, sodass ü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.
Für die hier angesprochenen Tools und in dem Entwicklungsumfeld in dem diese zum Einsatz kommen, wurden die meisten Projekte mit einer Teamgröße von vier bis zehn Personen und unterschiedlichster Erfahrung eingesetzt. Sämtliche ProjektmitarbeiterInnen befinden sich den Grossteil 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 vernachlässigt werden darf in jedem Fall der Kommunikationsaufwand werden, welcher 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, daß 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 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). 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, sodass 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 namens aufmerksam, mit dem Bugs sehr schnell und ohne aufwändige Einschulung erfasst werden konnten (Mantis). Die Bedienung erfolgt über jeden beliebigen Webbrowser (Abb.1). 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. Dadurch dass 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.
Abb.1: Screenshot eines Eintrages im Bugtraq-System. Beachten Sie die Referenz (Hyperlink) in das Concurrent Versioning Systen (CVS). Nur der in diesen Kontext referenzierte Teil dieses viel umfangreichen Dokumentes ist wichtig. Es handelt ich um den Unterschied zwischen Revision 1.8 und 1.10. Durch diese einfache Methode können sehr schnell mit minimalem Aufwand Zusammenhänge hergestellt werden.
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) in der Open Source Community wohl das am weitesten verbreitete ist. Vielleicht denken Sie jetzt sofort an SW Entwickler die damit ihre Programme (Quell Text) verwalten - also primär Text - und nicht unbedingt an Projektmanagement, wo man 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 ist Dokument, oder? Was ist also falsch an der Gleichung Dokument ist gleich Word-Dokument? Vermutlich die nicht hinterfragte Annahme, dass aufgrund der Verbreitung von Word jedes Dokument im Word-Format vorliegen müsse. Trifft man diese Annahme nicht, 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 (Abb.2).
Abb.2 Aus einem sehr umfangreichen Dokument können durch einen Vergleich von verschiedenen Revisionen eines Dokuments gezielt Änderungen verfolgt werden. Beachten Sie den Link zurück zum Ausgangspunkt im Bugtraq-System.
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 bewährt. Wiki ist hawaiianisch und heißt schnell. Die Idee ist die, dass man mittels strukturiertem Text einfach und schnell HTML-Seiten erstellen kann 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 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.
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
- Agile Entwicklungsmethoden: http://www.agilealliance.com/home
- Gallery: http://gallery.menalto.com
- Open Source: http://www.opensource.org
Diesen Artikel als [pdf 112kB]