Creating a project plan and tracking a running project are two completely different things that require different tools.
TaskFalcon
supports planning and tracking projects and the tool for tracking projects effectively is called updates
.
An update describes any kind of change to the project after the project has been started.
Most of the details of project tracking are covered in the third TaskFalcon
tutorial: Tracking Projects
An update consists of a date and an arbitrary amount of project changes, which with some exceptions are following the usual configuration file options.
project:
# Your project settings go here
tasks:
# Your task definitions go here
resources:
# If available, your resources go here
updates:
- update: 2020-06-01 # This is the date from which on the changes apply
project:
# Your updates for project settings go here
tasks:
# Your task updates go here
resources:
# Your resource updates go here
- update: 2020-06-08 # Next update
project:
# Your updates for project settings go here
tasks:
# Your task updates go here
resources:
# Your resource updates go here
As you can see, each update starts with the update definition, that includes the date when this update will be applied.
Inside the update section, you have the same sub-sections, you usually have in a TaskFalcon
file:
Inside the sections underneath the update definition, you can use the very same settings as in the original project definition with a very few exceptions:
The tasks inside an update must be flat. There are no nested tasks allowed. However, you can still address any of your previously defined tasks by using their fully qualified identifier.
project:
name: Update example
start: 2020-06-01
tasks:
- group: Hello
priority: 100
tasks:
- task: World
length: 1d
- task: TaskFalcon
length: 2d
updates:
- update: 2020-06-08
tasks:
- task: Hello
priority: 200
- task: Hello.World # Identifies the task "World" inside the group "Hello"
length: 2d
- task: Hello.TaskFalcon
length: 1d
In the update section, you can update all of the regular task/group/milestone properties. There are some settings especially in your task definitions that can only be used for updates. These will be covered below.
Type: Map of [Resource + Duration]
With bookings you can circumvent the automatic task scheduler and explicitly tell TaskFalcon
who was working on a task.
This especially is useful in combination with the tracking
option.
updates:
- update: 2020-06-08
tasks:
- task: T1
bookings:
w2: 1d # explicitly booking 1 day worth of efforts of resource w2 to task T1
It is important to understand that bookings ignore existing assignments. This means that no matter what a resource was supposed to work on, the bookings tell TaskFalcon
what he was actually working on, even if he never was assigned to a task before or the task is not yet/anymore in progress.
However, bookings don’t ignore things like working hours. If you enter a booking for 10 hours for a resource, but the given resource only works 6 hours per day, the booking will continue with the remaining 4 hours on the second day.
# File: bookings.yaml
project:
name: Bookings
start: 2020-06-01
resources:
- resource: w1
name: Worker 1
- resource: w2
name: Worker 2
tasks:
- task: T1
efforts: 2w
assign: w1
priority: 30
- task: T2
efforts: 1w
assign: w1
start: 2020-06-15
priority: 20
- task: T3
efforts: 3w
assign: w2
priority: 10
updates:
- update: 2020-06-08
tasks:
- task: T2
bookings:
w2: 1w
- task: T3
bookings:
w1: 3d
In the first picture, we see the result without the bookings (the clean project schedule).
In the second picture, we see the result with the bookings applied.
As you can see Worker 2
started and completed T2
despite the fact that he was never supposed to work on it at all and the task wasn’t supposed to start before 2020-06-15. And Worker 1
was helping out on T3
even though he was supposed to work on a different task with a higher priority.
Type: Duration
effortsleft
tells the scheduler how much efforts are still required to get the task done.
During tracking a project you can use effortsleft
to tell the scheduler, where the task is at in reality, opposed to the previously scheduled plan.
tasks:
- task: T1
start: 2020-06-01
allocate: dev1
efforts: 5d
updates:
- update: 2020-06-04
tasks:
- task: T1
effortsleft: 8d # The task was more complex than thought.
# 3 days after the task was started, it was
# estimated to require 8 more days, (totalling 11 days)
Type: Duration
Like what effortsleft
does for an effort based task, lengthleft
does for a length based task. It tells the scheduler the remaining duration required to complete the task.
tasks:
- task: T1
start: 2020-06-01
length: 5d
updates:
- update: 2020-06-04
tasks:
- task: T1
lengthleft: 8d # The task was more complex than thought.
# 3 days after the task was started, it was
# estimated to require 8 more days, (totalling 11 days)
Type: Boolean
When an update changes the scheduling of a task or milestone, TaskFalcon
will keep the previous start and end times for a locked task/milestone. To avoid this, you can use two updates to unlock
the task in the first update and lock
it again in the second.
The property reschedule
provides a more convenient way of doing this. It will unlock a given task/milestone for the duration of a single update.
tasks:
- task: T1
start: 2020-06-01
length: 5d 4h # Without further changes, this task will finish on 2020-06-08
- milestone: M1
depends: T1
updates:
- update: 2020-06-03
tasks:
- task: T1
lengthleft: 5d
- milestone: M1
reschedule: true # Without this line, the update would break this Milestone,
# since the Milestone would still expect T1 to finish on 2020-06-08