TaskJuggler

under construction

I wrote this page in 2008. The software has changed a lot since then.

TaskJuggler - project management tool to plan and track projects, resources, tasks, costs and deliverables. TaskJuggler is written in Ruby and leverages parts of the KDE environment. Original code came from SUSE Linux in Germany (now Novell). The software is used by many people/organizations like AMD and there is good support in the active forums and mailing lists. Source code is maintained on GitHub.

There is a new version - TaskJuggler III - that is in beta now, and the system is a complete rewrite of the C++ system in ruby, maintained in a git repository instead of Subversion. The project is still maintained by Chris Schlaeger.

Unfortunately, it does not appear that there is any QT4 development work going on, so it remains doubtful when we'll see TaskJuggler in KDE4 -- however the 2.4 version is available in Ubuntu repos and appears to work as before (so perhaps it's not dependent on KDE3)

Using TaskJuggler

The GUI application front-end is called specifically TaskJugglerUI while the commandline tool is taskjuggler. Aside from managing all aspects of a project including calendars, dependencies, costs and scenarios, the software provides HTML reports that make it very convenient to communicate the project status easily. The software is based on KDE, and as such has a great deal in common with the Quanta or Kate editing enviroments. Still, you may find it useful to edit the files in the full-blown Quanta or Kate. See the Contribs section for more info on using an external editor.

Training

• TaskJuggler-Workshop.pdf (328KB, MIME TYPE: application/pdf) Adobe Portable Document format
• http://www.taskjuggler.org/download/TaskJuggler-Workshop.sxi (source)

is a complete set of slides used in the TaskJuggler training workshop.

Help

There is extensive help distributed with the application and available online in HTML format. From inside the application, you can press F1 to launch the KDE Help Center. The equivalent command line would be khelpcenter file:/usr/share/doc/kde/HTML/en/taskjuggler/index.html The tutorial included inside the application help also provides complete example project files.

Cheatsheet

Assigning the effort, duration and length of a particular task is fundamental to getting the right results.

effort

is a measure of how much a person must do. Warning to project managers and estimators: effort 10d does NOT equal 5d when you have two resources to divide up the task. The software will let you say so, but that doesn't make it reality. The ONLY time this is reality is if the effort can be partitioned without adding ANY overhead. For more information, read "The Mythical Man-Month" by Frederick P. Brooks, Jr.

length

is a measure in working days I.e. length 20d = 1 month

duration

is a measure in calendar days I.e. duration 30d = 1 month

interval

is similar to duration with specific start and end dates. There is no keyword, you just specify (or inherit) the start date and specify the end date. E.g. start 2007-05-01 end 2007-05-15

In the Logical Expressions supported by TaskJuggler, the tilde character means 'NOT' e.g.

icalreport "drupalProjectGregIcalReport.ics" {
# Only export tasks that Greg is assigned to
hidetask ~isDutyOf(Greg, plan)
}

In the dependency scoping, it is normal to use a relative reference so that sections are more easily portable throughout the project definition. The notation for relative references is to use the exclamation character '!' to mean one level up. The ! carries exactly the same meaning as ../ in filesystem notation. In addition to relative references, object paths are represented using '.' dot notation. E.g.

depends !!implementation.gui.theming

One approach to balancing resource loads is to use the limits property right in the allocation. You can also define limits in the resource defintion, or you could adjust (artificially) workinghours

task baseActivities "Baseline Activities" {
effort 3000h
start 2008-04-01
allocate GregRundlett { mandatory limits { dailymax 4h } }
allocate SallyStar { mandatory limits { dailymax 4h } }
allocate JoeDoe { mandatory limits { dailymax 4h } }
}

Files

.tjp

The TaskJuggler project file will have the .tjp extension.

.tji

Since projects can be defined so as to include other resources, those include files are named .tji.

.tjx

created by the report function, these are the (compressed) XML versions of the source data

XML

Using the XML report function, you can export the project into XML format (identified with the .tjx extension). These XML files are actually compressed (with gzip). Thus, in order to edit them directly you would need to uncompress them and give it an .xml extension gunzip -S tjx --stdout myProject.tjx > myProject.xml or zcat myProject.tjx > myProject.xml The TaskJuggler DTD defines the XML syntax. The application can read either the tjp source or tjx source files equivalently.

Once you have the XML source, you can use any XML editor like Kate or Quanta as an editing interface rather than the TaskJuggler software. When finished, you need to convert the XML source back into tjp syntax, and I haven't found a script or XSL to do that yet

Integration

VI

For instructions on setting up syntax highlighting so that Vi 'knows' about TJP and TJI syntax, see Syntax Highlighting

FreeMind

FreeMind is a mind mapping tool that can be used to quickly break down and organize the things that need to happen in a project (aka the Work Breakdown Structure or WBS). FreeMind has built-in ability to export nodes as TaskJuggler include files. Just name the node TASKS or RESOURCES and use the File->export menu option. Then include the resulting files in your TaskJuggler project. See http://freemind.sourceforge.net/wiki/index.php/FreeMind_0.9.0:_The_New_Features#TaskJuggler_Integration

Wiki

To manage projects in a bottom-up fashion, you could create a wiki template or series of templates that allow participants to view and define the project plan in a medium that enables collaboration, cross-referencing to support and linking to other resources by all project participants. At any given moment, you can then take these defined tasks from the wiki and roll them up into a TaskJuggler file. Conversely, you could take a top-down approach by defining tasks in TaskJuggler and publish that information via (XML) export to the wiki

<!-- template guide -->
{{task
| id = myProject  
| name = "Distribute Free Software to 400,000 in India"
| account =
| allocate =
| complete = 
| depends = 
| duration = 
| effort = 100d
| endbuffer = 
| endcredit = 
| end = 
| flags = 
| journalentry = 
| length = 
| maxend = 
| maxstart = 
| milestone = 
| minend = 
| minstart = 
| note = 
| period = 
| precedes = 
| priority = 
| projectid = 
| purge = 
| reference = 
| responsible = 
| scheduled = 
| scheduling = 
| shift = 
| startbuffer = 
| startcredit = 
| start = 
| statusnote = 
| supplement =
| task =}}
 

Extensions / Contribs

See the source code for contributed code that extends the application e.g. /usr/local/src/taskjuggler-2.2.0/Contrib/ There are Contribs for

• emacs
• kate
• tjGUI
• TJ-Pert
• tjx2gantt
• vim

So, in the case of Kate, there is a DTD that defines the markup structure so that Kate can easily assist you in editing the file

There is also a similar DTD available for Quanta Download it, extract it into the DTEP directory and you can use it on .tjx files. (.tjx files are compressed. See the note in the files section)

There is also a website page http://www.taskjuggler.org/contrib.php that lists some resources which are not distributed with the source code

Example Project File

http://www.taskjuggler.org/manual-svn/example.html shows this example file (presented here with syntax highlighting)

/*
* This file contains an example project. It is part of the
* TaskJuggler project management tool. It uses a made up software
* development project to demonstrate some of the basic features of
* TaskJuggler. Please see the TaskJuggler manual for a more detailed
* description of the various syntax elements.
*/
project acso "Accounting Software" "1.0" 2002-01-16 2002-04-28 {
# Pick a day during the project that will be reported as 'today' in
# the project reports. If not specified, the current day will be
# used, but this will likely be outside of the project range, so it
# can't be seen in the reports.
now 2002-03-05-13:00
# Hide the clock time. Only show the date.
timeformat "%Y-%m-%d"
# The currency for all money values is the Euro.
currency "EUR"

# We want to compare the baseline scenario to one with a slightly
# delayed start.
scenario plan "Plan" {
# Mark all paths as critical that have less than 10% slack time.
minslackrate 10.0
scenario delayed "Delayed"
}
}

# This is not a real copyright for this file. It's just used as an example.
copyright "© 2002 Crappy Software, Inc."

# The daily default rate of all resources. This can be overridden for each
# resource. We specify this, so that we can do a good calculation of
# the costs of the project.
rate 310.0

# Register Good Friday as a global holiday for all resources.
vacation "Good Friday" 2002-03-29

# This is one way to form teams
macro allocate_developers [
allocate dev1
allocate dev2 { limits { dailymax 4h } }
allocate dev3
]

flags team

resource dev "Developers" {
resource dev1 "Paul Smith" { rate 330.0 }
resource dev2 "S�bastien Bono"
resource dev3 "Klaus M�ller" { vacation 2002-02-01 - 2002-02-05 }

flags team
}
resource misc "The Others" {
resource test "Peter Murphy" { limits { dailymax 6.4h } rate 240.0 }
resource doc "Dim Sung" { rate 280.0 vacation 2002-03-11 - 2002-03-16 }

flags team
}

# In order to do a simple profit and loss analysis of the project we
# specify accounts. One for the development costs, one for the
# documentation costs, and one account to credit the customer payments
# to.
account dev "Development" cost
account doc "Documentation" cost
account rev "Payments" revenue

# Now we specify the work packages. The whole project is described as
# a task that contains subtasks. These subtasks are then broken down
# into smaller tasks and so on. The innermost tasks describe the real
# work and have resources allocated to them. Many attributes of tasks
# are inherited from the enclosing task. This saves you a lot of typing.
task AcSo "Accounting Software" {

# All work-related costs will be booked to this account unless the
# subtasks specify something different.
account dev

task spec "Specification" {
# The effort to finish this task is 20 man-days.
effort 20d
# Now we use the macro declared above to allocate the resources
# for this task. Because they can work in parallel, they may finish this
# task earlier than in 20 working-days.
${allocate_developers}
# Each task without subtasks must have a start or an end
# criterion and a duration. For this task we use a reference to a
# milestone defined further below as the start criterion. So this task
# can not start before the specified milestone has been reached.
# References to other tasks may be relative. Each exclamation mark (!)
# means 'in the scope of the enclosing task'. To descent into a task, the
# fullstop (.) together with the id of the tasks have to be specified.
depends !deliveries.start
}

task software "Software Development" {

# The software is the most critical task of the project. So we set
# the priority of this task (and all its subtasks) to 1000, the top
# priority. The higher the priority, the more likely the task will
# get the requested resources.
priority 1000

# All subtasks depend on the specification task.
depends !spec

task database "Database coupling" {
effort 20d
allocate dev1, dev2
}

task gui "Graphical User Interface" {
effort 35d
# This task has taken 5 man-days more than originally planned.
# We record this as well, so that we can generate reports that
# compare the delayed schedule of the project to the original plan.
delayed:effort 40d
depends !database, !backend
allocate dev2, dev3
}

task backend "Back-End Functions" {
effort 30d
# This task is behind schedule, because it should have been
# finished already. To document this, we specify that the task
# is 95% completed. If nothing is specified, TaskJuggler assumes
# that the task is on schedule and computes the completion rate
# according to the current day and the plan data.
complete 95
depends !database
allocate dev1, dev2
}
}

task test "Software testing" {

task alpha "Alpha Test" {
# Efforts can not only be specified as man-days, but also as
# man-weeks, man-hours, etc. By default, TaskJuggler assumes
# that a man-week is 5 man-days or 40 man-hours. These values
# can be changed, of course.
effort 1w
# This task depends on a task in the scope of the enclosing
# task's enclosing task. So we need two exclamation marks (!!)
# to get there.
depends !!software
allocate test, dev2
note "Hopefully most bugs will be found and fixed here."
}

task beta "Beta Test" {
effort 4w
depends !alpha
allocate test, dev1
}
}

task manual "Manual" {
effort 10w
depends !deliveries.start
allocate doc, dev3
account doc
}

task deliveries "Milestones" {

# Some milestones have customer payments associated with them. We
# credit these payments to the 'rev' account.
account rev

task start "Project start" {
# A task that has no duration is a milestone. It only needs a
# start or end criterion. All other tasks depend on this task.
milestone
start 2002-01-16
# For some reason the actual start of the project got delayed.
# We record this, so that we can compare the planned run to the
# delayed run of the project.
delayed:start 2002-01-20
# At the beginning of this task we receive a payment from the
# customer. This is credited to the account associated with thhttp://www.taskjuggler.org/manual-svn/example.htmlis
# task when the task starts.
startcredit 33000.0
}

task prev "Technology Preview" {
milestone
depends !!software.backend
startcredit 13000.0
}

task beta "Beta version" {
milestone
depends !!test.alpha
startcredit 13000.0
}

task done "Ship Product to Customer" {
milestone
# The next line can be uncommented to trigger a warning about
# the project being late. For all tasks, limits for the start and
# end values can be specified. Those limits are checked after the
# project has been scheduled. For all violated limits a warning
# is issued.
# maxend 2002-04-17
depends !!test.beta, !!manual
startcredit 14000.0
}
}
}

# Now the project has been specified completely. Stopping here would
# result in a valid TaskJuggler file that could be processed and
# scheduled. But no reports would be generated to visualize the
# results.

# A traditional Gantt Chart for the TaskJugglerUI
taskreport "Gantt Chart" {
headline "Project Gantt Chart"
columns hierarchindex, name, start, end, effort, duration, chart
# For this report we like to have the abbreviated weekday in front
# of the date. %a is the tag for this.
timeformat "%a %Y-%m-%d"
loadunit days
hideresource 1
}

# A list of tasks showing the resources assigned to each task.
taskreport "Task Usage" {
headline "Task Usage Report"
columns hierarchindex, name, start, end, effort { title "Work" }, duration,
cost, revenue
timeformat "%Y-%m-%d"
loadunit days
hideresource ~isLeaf()
sortresources nameup
}

# A list of all tasks with the percentage completed for each task
taskreport "Tracking Gantt" {
headline "Tracking Gantt Chart"
columns hierarchindex, name, start, end, effort { title "Work" }, duration,
completed, chart
timeformat "%a %Y-%m-%d"
loadunit days
hideresource 1
}

# A graph showing resource allocation. It identifies whether each
# resource is under- or over-allocated for.
resourcereport "Resource Graph" {
headline "Resource Allocation Graph"
columns no, name, rate, utilization, freeload, chart
loadunit days
hidetask 1
}

# A list of all project resources, both human and material resources,
# together with the associated costs.
resourcereport "Resource Sheet" {
headline "Resource Sheet"
columns no, name, efficiency, id, maxeffort, rate
loadunit days
hidetask 1
}

# A list of resources and each task associated with each resource.
resourcereport "Resource Usage" {
headline "Resource Usage Report"
columns no, name, utilization, freeload, cost
loadunit days
hidetask 0
}

# This report looks like a regular calendar that shows the tasks by
# their dates.
htmlweeklycalendar "Calendar.html" {
# Only show work days in the calendar.
weekdays mon - fri
}

# This report is a status report for the current week. It also
# provides an outlook for the next week.
htmlstatusreport "Status-Report.html" {
}

# A P&L report for the project.
htmlaccountreport "Accounting.html" {
# Besides the number of the account and the name we have a column
# with the total values (at the end of the project) and the values
# for each month of the project.
columns no, name, scenario, total, monthly
headline "P&L for the Project"
caption "The table shows the profit and loss analysis as well as
the cashflow situation of the Accounting Software Project."
# Since this is a cashflow calculation, we show accumulated values
# for each account.
accumulate
scenarios plan, delayed
}

xmlreport "XML-Report.tjx" {
version 2
hidetask 0
hideresource 0
scenarios plan, delayed
}

HyperText Markup Language = structured text that uses logical links (hyperlinks) between nodes containing text.

Extensible Markup Language = a system for markup such that you can create your own 'schema' of terms rather than a specific markup language.

A worker machine in a Kubernetes cluster.