[n00b alert] Resource pools -- how to?

[Jorn W Janneck]

Hi there.

I am new to TaskJuggler, and I love the concept and the
implementation, but I am running into a seemingly simple problem that
feels like there is probably a simple solution, but I just don't know
how to do it. Pointers very welcome.

I want to model resource pools, without necessarily breaking them down
to individual resources. The pool could be N workers, or N pieces of
equipment and so on, and a task would specify how many items of a type
of resource are required. The individual resource allocation is not
relevant, but what matters is the overall resource use profile, i.e.
how *many* items of a resource have been used over time.

As a next step, I then would like to control the number of available
resources in each pool over time, reflecting e.g. gradual staffing of
a project, so more resources of e.g. the "developer" pool become
available over time.

Is there a way to do this in TJ, and how would one approach this kind
of thing?

Thanks a lot in advance!

-- j

[zanerock]

On the first question of how to create a task pool, how about defining
a team and set of macros, like:

resource devpool "Pool of Developers" {
resource dev1 "Dev1"
resource dev2 "Dev2"
resource dev3 "Dev3"
}

Now define a macro that selects from the pool:

macro devSelect [ allocate dev1 { alternative dev2, dev3 select
minloaded} ]

Now, you include the macro in each task however many times, and that
controls how many pool members are assigned:

task doubleUp "A task for two" {
start 2009-11-01
effort 1d
${devSelect}
${devSelect}
}

(I tested this approach, but wrote this out manually, so I apologize
for any typos, but this should work.)

Now, as far as controlling over time, try defining shifts, then
assigning each resource to shifts as they become available or not.

On Oct 30, 2:26 pm, Jorn W Janneck <jwjann...@gmail.com> wrote:
> Hi there.
>
> I am new to TaskJuggler, and I love the concept and the
> implementation, but I am running into a seemingly simple problem that
> feels like there is probably a simple solution, but I just don't know
> how to do it. Pointers very welcome.
>
> I want to model resource pools, without necessarily breaking them down

> to individual resources. Thepoolcould be N workers, or N pieces of

> equipment and so on, and a task would specify how many items of a type
> of resource are required. The individual resource allocation is not
> relevant, but what matters is the overall resource use profile, i.e.
> how *many* items of a resource have been used over time.
>
> As a next step, I then would like to control the number of available

> resources in eachpoolover time, reflecting e.g. gradual staffing of

[Jorn W Janneck]

Hi there,

Thanks for the response.

> On the first question of how to create a task pool, how about defining
> a team and set of macros

That is what I ended up doing (although I did not know about minloaded
-- that's a great idea), but it gets cumbersome very quickly if the
number of resources (i.e. the size of the resource pool) gets large,
or if you want to vary that number e.g. for different scenarios.
Basically, I was wondering whether there was "array notation" for
resources, or whether I actually had to introduce each single one of
them by name.

> Now, you include the macro in each task however many times, and that
> controls how many pool members are assigned:
>
> task doubleUp "A task for two" {
>   start 2009-11-01
>   effort 1d

>   ${devSelect}.)
>   ${devSelect}

I did not know about the use of more than one allocate property to
allocate more than one resource --- that's really useful, thanks. (And
again, some "parametric" way of doing this would be nice here, but it
is a start

> Now, as far as controlling over time, try defining shifts, then
> assigning each resource to shifts as they become available or not.

I ended up giving my resources "vacation", which I guess is a similar
idea.

Thanks again for taking the time to respond.

Cheers,

-- j

[zanerock]

I myself am new to TJ, but as far as I can see, there's not much in
the way of arrays or loops or anything like that which could
"generate" resources--like "${makePool 10}" to create a resource pool
of 10.

When I've run into this, I've ended up writing tiny ruby scripts. I've
done this for recurring task (like 'close books') that happen
regularly. A few lines of ruby to generate a dozen macro calls.

Googling on recurring tasks, it really does seem like "repeat the
macro" is really how it's done. Which, considering what else TJ
offers, is just fine with me. Maybe someone else knows a better trick.

[Chris Schlaeger]

TaskJuggler can handle various ways of sloppy data input but it always
maps it to some exact representation internally. In may cases that
works fine, but it could end up going into another direction than
you'd expect. In the end it pays off to try to provide as many details
as possible.

Not sure if this works for you, but you can allocate teams.

resource team "Team" {
resource a "A"
resource b "B"
}

task foo "Foo" {
efford 2m
allocate team
}

Chris

[Jorn W Janneck]

Hi zane,

I agree with what you say --- for now it's merely an inconvenience,
and not a major one. I guess part of my question was to make sure that
I am not missing something obvious. The plan I am preparing is
intended to be shared as a basis for a discussion, so I would like to
make as educated a use of the features as possible. Incidentally, one
of the reasons I like TJ is that you can, in fact, send someone a
fairly concise and readable text document, and they can understand it
with little or no additional explanation. Kudos to the authors.

-- j

[Jorn W Janneck]

On Nov 1, 1:13 am, Chris Schlaeger <cschlae...@gmail.com> wrote:
> TaskJuggler can handle various ways of sloppy data input but it always
> maps it to some exact representation internally. In may cases that
> works fine, but it could end up going into another direction than
> you'd expect. In the end it pays off to try to provide as many details
> as possible.

In my case, it is not so much about uncertainty or precision, but
about expressing the intent of fungibility, and of playing out
scenarios with different size resource pools --- the idea being that I
have a pool of N resources (or in fact several pools of various
sizes), where N may be different for different scenarios, and each
task uses a certain number of them. The kind of question I am trying
to answer is how the schedule is affected by varying the sizes of
resource pools, and how the utilization of one resource pool depends
on the size of another, for instance.

TaskJuggler would be the perfect platform for experimenting with this
kind of problem, because it has a great interface (the language), and
it has most of the scheduling machinery in place. I can set this up
for small pools by hand (along the lines of what the other poster was
suggesting), so right now I am fine. But it would be great to see this
become part of a future version of TJ. (I have never done any serious
Ruby before, but it is tempting... ;-)

Cheers,

-- j

[gra...@harris.net.nz]

sorry for tagging such an old thread, but I haven't found an explicit statement anywhere and I want to clarify...

resource sa "Solution Architects" {

resource a "A"
resource b "B"
}

task infoed 'InfoEd Replacement' {
    task infoed_sa 'infoed_sa' { effort 55d allocate sa { persistent } }

so sa is a team of 2 people, will TJ3 allocate as many of those people as it can to work on task infoed?

Will it allocate them concurrently if resource, prioity etc allows?

[gra...@harris.net.nz]

solved my own query by a bunch of experiments with a simple single file and TJ3 3.7.1. 

If a task allocates a group of resources, the effort is shared between the group according to individual resources' availability, as you would expect.

The more interesting thing came when I experimented with two tasks competing for resources in various ways:

1. tasks A and B both allocating the same group

2. task A allocating the group, task B allocating a group member

3. task A allocating the group, task B allocating a group member with an alternative from the group

4. task A allocating the group, task B allocating two members using a macro as described above

5. tasks A and B both using macros to allocated two members of the group.

One common thread was that tasks with greater effort seem to get the lions share of resources, completing before a similar task with less effort. I tested it on most versions by reversing the effort.

experiment 3 showed something strange: allocating an alternative for the individual resource delayed that task compared to not allocating an alternative.