Re: Resource leveling

On Sat, 2007-10-13 at 15:56 +0200, Maurice van der Pot wrote:
> On Thu, Aug 16, 2007 at 08:48:36AM -0400, Kurt Maute wrote:
> > The thing is - I've been trying to get Planner to do priority based
> > resource allocations (otherwise, we should just dump the priority field
> > - it doesn't do anything else).
> ...
> > here's where I was going:
> > 
> > Create a sorted list of tasks:  dependency, priority, then wbs order
> > Loop back thru dependencies, scheduling all predecessors first.
> > 
> > Tricky part:
> > Say you have:
> >  Task T1 - no priority assigned
> >  Task T2 with a priority of 10, T1 is predecessor
> >  Task T3 has priority 5
> > If T3 wants to be scheduled during the same time as T1, it will steal
> > its resources and push it out.  T2, with its higher priority than T3 is
> > also pushed out, which is uncool.
> > 
> > This led me to reason that priorities of predecessors should be derived
> > from their dependent tasks, if higher than their own assigned priority.
> > Likewise, the priority of a child task should be inherited from a parent
> > (summary task) if higher.
> > 
> > That is pretty much where I left off... I was adding this
> > derived/inherited priority concept.
> > 
> > Here's a copy of the changes so far, if you're brave enough to take a
> > look.  ;-)
> 
> I've been thinking about what I would expect from simple resource
> leveling as a user and also tried out your patch just now. Maybe we can
> discuss a bit through mail what our expectations are, because
> prototyping this takes too much effort just to show the concepts.

ok

> For the simplest solution, I would still expect the user to
> order/prioritize the tasks. Planner would just try to satisfy the
> constraints given. This matches with what your patch does.
> 
> There are a few things that differ from what I expected though. 
> 
> The first is that tasks with the same resource and no deps still all
> start at the same position. No work is being done for all but one and
> the bars are not filled, but they start anyway. I would rather expect it
> to look like a bunch of finish-to-start deps without the arrows.

Yes, this is behavior that I left in from the simple priority scheduling
code that Matteo Nastasi created.  I agree it would be more straight
forward to display the task as starting when work is actually scheduled
to be done on it.

> The second is related to the first: split tasks are introduced. The work
> for a task can be done in parts. Take the tricky case you mentioned, but 
> imagine T1 is assigned to a different resource than T2 and T3. In this
> case T3 will span from the start of T1 to beyond the end of T2 and it
> will have part of its work done before the start of T2 and part of it
> after the end of T2. 
> On one hand split tasks are useful to maximize resource usage, on the
> other automatically splitting/joining tasks may make manipulating the
> schedule less intuitive. I haven't made up my mind which I find more
> important.

I don't think other PM tools split tasks - they show them as continuing
even though there's no work being performed on them at the time.  I
think this was sort of a nice feature of Matteo's code - that it would
show the amount of work expected to be done on a task throughout its
duration.

> I was also thinking of a way to more easily adjust priorities. Suppose
> the user can drag the start of tasks to indicate where the task belongs
> in the priority order of all tasks. Compare this to the way you can
> reorder (automatically arranged) icons on a Windows desktop. When you
> drag one in between others a caret will appear to show what would happen
> if you released the mouse button.
> 
> It's not quite as simple for tasks as it is for icons on a desktop,
> because a dragged task will not necessarily move to the spot in between
> two other tasks because of things like deps or the resource being
> available even earlier. I'll have to think some more on how to represent
> this in a UI while dragging

It might be best to represent in its own view as a simple list (or maybe
as an option in the task list)?

> I think it'd be good to move this discussion over to the -dev list. 
> Will you include the list on your reply if you agree?

Done.


-- 
Kurt Maute <[email protected]>