Nicht nur große Unternehmen und Dienstleister aller Art planen Einsätze und Projekte mit Hilfe von Computersystemen. Auch Vereinen und privat organisierten Dienstleistern spart eine Software-Lösung Zeit, Nerven und bares Geld. Taskjuggler ordnet alle Ressourcen und verschafft den Überblick.
Aufgaben und Projekte, die es zu organisieren gilt, gibt es seit Menschengedenken in Hülle und Fülle. Eher spärlich gesät sind aber Menschen und Software, die Ressourcen und Aufgaben sinnvoll und vor allem effizient zuordnen können. Der Taskjuggler von Chris Schläger und Klaas Freitag tut nicht nur dies, sondern präsentiert sich auch als eine Art Eier-legende Wollmilchsau, die jede Situation optimiert, die sich in Projekte und Ressourcen zerpflücken lässt.
Kosten-Definitionen und eine einfache Kosten-Kontrolle können dabei ebenso festgelegt werden wie Schichten und Prioritäten. Das Programm erwartet in Text-Dateien mit der Erweiterung .tjp beschriebene Objekte und verarbeitet diese auf den einfachen Aufruf von
taskjuggler dateiname.tjp
hin. Seine dabei erstellten Berichte liefert Taskjuggler als HTML- oder CSV-Dateien ab – bestens geeignet zur Publikation im Internet oder zur Aufbereitung in einer Tabellenkalkulation wie OpenOffice. Alternativ exportiert das Programm XML-Daten, die sich in jedes gewünschte Zielformat konvertieren lassen und damit zum Beispiel den Weg in Content-Management-Systeme ebnen.
Mehr Funktion in der Entwicklerversion
Wir stellen an dieser Stelle die Entwicklerversion 1.9.2 vor, die bereits einige neue Features integriert, zum Beispiel besagte CSV-Reports. Außer einem C++-Compiler wie dem g++ aus der “GNU CCollection” GCC benötigen Sie die Entwicklungspakete zum X-Window-System. Entgegen der Dokumentation auf der Taskjuggler-Website http://www.taskjuggler.org/ setzt die Software zudem mindestens die Version 3.1 der Qt-Bibliothek voraus.
Das Taskjuggler-Paket von der Heft-CD entpacken Sie mit
tar xjf taskjuggler-1.9.2_unstable.tar.bz2 cd taskjuggler-1.9.2_unstable
Nun startet der Kompilierungsprozess mit den Befehlen
./configure --with-kde-support make
Haben Sie kein KDE installiert, lassen Sie entsprechend die Option --with-kde-support weg. Die Konfigurationsroutine ist so angelegt, dass sie den Voraussetzungen des Rechners entsprechend soviel Funktionalität wie möglich übersetzt. So generiert sie die Dokumentation neu, sobald sie alle Docbook-Bibliotheken findet.
Sind Perl und die CPAN-Module XML::Parser, Postscript::SimpleDate::CalcClass::MethodMaker und Data::Dumper installiert, erstellt der Build-Vorgang auch das Programm tjx2gantt, das Gantt-Diagramme wie in Abbildung 1 erzeugt.
Nach erfolgreichem make-Durchlauf installiert man das Taskjuggler-System als privilegierter Benutzer mit dem Befehl make install .
Projekte, Schichten und Ressourcen
Für eigene Projekte erstellt man am besten ein Verzeichnis, in dem Taskjuggler alle zugehörigen Definitionen und Berichte ablegen soll. Ein komplettes Beispiel finden Sie auf der Heft-CD im Verzeichnis LinuxUser/ootb/beispielprojekt/.
Die darin enthaltene Projektdefinitionsdatei ShiftSchedule-deutschkommentiert.tjp – ein auf Deutsch kommentiertes Beispiel von der Taskjuggler-Webseite – besteht für jedes Projekt aus vier Teilen: der Projektdefinition, den Schichten, den zur Verfügung stehenden Ressourcen und den Aufgaben.
Zunächst geht es im Abschnitt project (siehe Listing 1) um das Projekt selbst. Mit shifts erhält es einen Identifikator, anschließend folgt die Projektbezeichnung – es dreht sich um die Verteilung von Arbeitsschichten in einem Systemadministrationsteam. Die letzten beiden Parameter grenzen in der Form JJJJ-MM-dd den ungefähren Zeitraum ab, in dem das Projekt stattfindet. Hier sollte man gerade beim Enddatum eher großzügig sein, denn außerhalb dieser Spanne liegende Aufgaben fallen unter den Tisch.
Zudem braucht man als dritten Parameter eine Versionsnummer. Das kann ein einfaches “1.0” sein; wer die Taskjuggler-Dateien mit einem Versionskontrollsystem verwaltet, schreibt hier den entsprechenden Platzhalter (für CVS “$Id”) hinein.
Auf diese verpflichtenden Parameter folgen in geschweiften Klammern optionale Angaben wie die tägliche Arbeitszeit (im Beispiel acht Stunden) und die Anzahl der Arbeitstage im Jahr (im Beispiel 256).
Nun folgt die Definitionen von Arbeitsschichten mit dem Stichwort shifts. Schichten fassen das Zeit-Budget aller Mitarbeiter am Projekt zusammen, die zur selben Zeit arbeiten. Die konkreten Zeiten legt das Attribut workinghours für jeden Tag fest, für den man per Default sein englisches Kürzel (tue für Dienstag, wed für Mittwoch usw.) hinschreibt. Möchte man in einem Projekt einen Tag als frei markieren, zeigt man dies mit dem Keyword off an. Fehlt ein Tag, nimmt Taskjuggler an dieser Stelle die Standard-Arbeitszeiten des Projekts auch für die Schicht an.
Jede Schicht bekommt wieder eine ID (zum Beispiel phonesupport für die Zeit, die Mitglieder des Sysadmin-Teams an der Hotline Dienst tun) und eine Überschrift.
Alle betroffenen Mitarbeiter definiert man wie in Listing 2 mit dem Schlüsselwort resource. Außer dem eindeutigen Kürzel (zum Beispiel joe) bietet sich als Beschreibung der Name an. Optional legt das Attribut vacation einen Ferienzeitraum fest; maxeffort bestimmt einen Faktor, mit dem sich Teilzeit berechnen lässt: Anders Gundstrom arbeitet bei einer 40-Stunden-Woche täglich nur 8@L: *0,8=6,4 Stunden. Das Attribut shift bindet Khaled Safri an besondere Arbeitszeiten, in unserem Fall die Zeiten aus Listing 1, die Studenten ausfüllen.
Das Wichtigste folgt zum Schluss: die zu erledigenden Aufgaben (Listing 3). Zuerst definiert unserer Beispiel einen Aufgabenbereich (task) sysadmin, der innerhalb der geschweiften Klammern in einzelne Aufgaben aufgesplittet wird. Der Punkt start setzt einen Meilenstein (milestone), an dem andere Tasks beginnen. So kann der User-Support erst anfangen (depends), wenn die Aufgabe start abgeschlossen, sprich, wenn der 1. Juni 2002 vorbei ist. Dank der Zeile flags hidden erscheint der Meilenstein nicht in den Auswertungen.
Den Support, den wir zunächst für zwei Monate (duration 2m) planen, übertragen wir der Schicht phonesupport mit der Priorität 900. 1 wäre extrem unwichtig, 1000 hat allerhöchste Priorität. Das Attribut allocate ordnet der Aufgabe Mitarbeiter zu: Von joe, anders, khaled und sally werden diejenigen herangezogen, die am wenigsten mit anderen Aufgaben belastet sind (select minloaded). Alternativ sucht das Auswahlkriterium maxloaded den jeweils beschäftigsten Mitarbeiter aus, order den oder die erste freie Mitarbeiter/in aus der Liste, und random wählt zufällig jemanden davon aus.
Listing 1
Schichtdefinitionen
project shifts "Duty Schedule SysAdmin Team" "$Id" 2002-06-01 2002-08-01 {
dailyworkinghours 8
yearlyworkingdays 256
}
flags hidden
shift phonesupport "Phone support" {
workinghours mon 9:00 - 12:00
workinghours tue 9:00 - 12:00
workinghours wed off
workinghours thu 14:00 - 17:00
workinghours fri 9:00 - 12:00
}
shift studenthours "Student Hours" {
workinghours mon 9:00 - 14:00
[…]
workinghours fri 9:00 - 14:00
}
Listing 2
Ressourcendefinitionen
resource joe "Joe Bughunter" {
vacation 2002-06-10 - 2002-06-13
}
resource khaled "Khaled Safri" {
shift studenthours
}
[…]
resource anders "Anders Gundstrom" {
maxeffort 0.8
}
resource paul "Paul Gutier" {
vacation 2002-07-02 - 2002-07-08
}
Listing 3
Aufgabendefinitionen
task sysadmin "System Administration" {
# Die folgende Aufgabe ist eigentlich keine, sondern legt nur
# den Projektbeginn fest.
task start "Start of plan" {
start 2002-06-01
milestone
flags hidden
}
task usersup "User Support" {
depends !start
duration 2m
shift phonesupport
priority 900
allocate joe { alternative anders, khaled, sally select minloaded }
}
[…]
} # Ende der Sysadmin-Aufgaben
Planung ganz einfach
Stehen die Rahmenbedingungen fest, sorgt Taskjuggler für Planungshilfen: Fügt man in die .tjp-Datei die Zeile
xmlreport "ShiftSchedule.tjx"
ein, generiert der taskjuggler-Aufruf einen XML-Report und legt ihn in der Datei ShiftSchedule.tjx ab. Er lässt sich natürlich mit XML-Editoren u. a. Programmen betrachten, eignet sich aber speziell zum Datenimport. Die passende DTD findet sich unter http://www.taskjuggler.org/show_dtd.php. Verfüttert man die XML-Datei an das zu Beginn erwähnte Perl-Skript tjx2gantt, macht es daraus Gantt-Diagramme.
Aber auch ohne Zusatz-Tools generiert der einfache taskjuggler-Aufruf bereits nützliche Reports – in HTML. So ergänzt man die .tjp-Datei für Sallys Kalender aus Abbildung 2 um den Code aus Listing 4: htmlweeklycalendar generiert in der Datei Kalender-sally.html einen Wochenplan für den Projektzeitraum.
Die Funktion isresource(sally) filtert alle Aufgaben der Ressource sally heraus, und hideresource versteckt (englisch: “to hide”) alle, die diesem Kriterium nicht (~) entsprechen. columns schedule sorgt dafür, dass davon ein detaillierter Zeitplan ausgegeben wird. Lässt man die Zeile hidetask 1 weg, enthält der HTML-Kalender zwischen Datum und Aufgaben jeweils eine Zelle mit Raum für Notizen.
Auch die neuen CSV-Reports definiert man wie in Listing 5 in der .tjp-Datei. Der csvtaskreport listet von allen nicht mit dem Flag hidden markierten Tasks den Namen und den zeitlichen Aufwand (effort) in Stunden (loadunit hours) für jeden Tag vom 01. 06. 2002 bis zum 01. 07. 2002 einzeln auf (Abbildung 3).
Listing 4
Sallys Arbeitsplan
htmlweeklycalendar "Kalender-sally.html" {
headline "Arbeitsplan für Sally"
columns schedule
hidetask 1
hideresource ~isresource(sally)
}
Listing 5
Überblick über die pro Tag anfallenden Stunden je Aufgabe
csvtaskreport "aufwand.csv" {
columns name, daily, effort
start 2002-06-01
end 2002-07-01
hidetask hidden
loadunit hours
}
Gut geplant ist halb gewonnen
Ob Übersichten nach dem Motto “Wer arbeitet wann wie lange an welcher Aufgabe?” oder Einsatzpläne für Mitarbeiter – Taskjuggler bietet eine Menge weiterer Möglichkeiten, die ein ganzes Referenzhandbuch (auf CD im Verzeichnis LinuxUser/ootb/manual/ zu finden) füllen. Weitere Beispiele finden Sie auch im Verzeichnis Examples des taskjuggler-Quellarchivs. Dort wie auch in der vollständigen Beispieldatei finden sich weitere Anregungen, zum Beispiel zur Verwendung von Makro-Skripten und mehrteiligen Projekten.
Glossar
- CSV
- Dateien im “Comma Separated Value”-Format vereinfachen den Daten-Austausch für Tabellen. Die Zelleninhalte sind darin durch Kommata und Zeilenumbrüche getrennt; Formatierungen gehen allerdings verloren.
- C++
- Die Programmiersprache C++ wurde vor mehr als 20 Jahren entwickelt, um die Sprache C um Daten-Abstraktion, Objekt-orientierte Programmierung und andere moderne Konzepte zu erweitern. C++ ist seit einigen Jahren ISO-zertifiziert und auf beinahe sämtlichen Architekturen und Betriebssytemen verfügbar.
- Docbook
- Eine “Document Type Definition”, also eine Beschreibung, welche Auszeichnungen in einer XML-Datei verwendet werden dürfen. Docbook definiert die Elemente, aus denen ein Buch besteht. Damit lassen sich Texte auszeichnen, die sich professionell sowohl in Print- als auch in Online-Formate wandeln lassen. Open-Source-Projekte verwalten ihre Dokumentation oft zumindest teilweise im Docbook-Format.
- CPAN
- Das “Comprehensive Perl Archive Network” bietet unter http://cpan.perl.org/ Software, Module und Dokumentation rund um Perl an.
- Gantt-Diagramme
- Zeigen die zeitliche Anordnung von Aufgaben (Tasks) an, die abgeschlossen sein müssen, um ein Projekt zu vervollständigen. Jeder Task nimmt dabei wie in Abbildung 1 eine eigene Reihe im Diagramm ein. Gantt-Charts empfehlen sich vor allem dann, wenn sich die Anzahl der zu planenden Aufgaben in überschaubarem Rahmen hält. Ihr Name geht auf den Ingenieur und Management-Berater Henry Laurence Gantt (1861-1919) zurück. Gantt-Diagramme wurden bereits beim Bau des Hoover-Damms in Arizona in den 1930ern mit großem Erfolg eingesetzt.





