Re[2]: Idea: Dependencies between Tasks

On Mon, 01 Jul 2002 13:00:03 +0100 Ian Phillips <[email protected]> wrote:

IP> Hi Michele,
IP> 
IP> Maybe I'm missing something, but I don't see how your "events" are any
IP> different 
IP> from breaking a task down into sub-tasks.

Hi

There is no difference, it is an alternative which I think would add
flexibility and provide a 'light-weight' way to define dependencies between
tasks. 

Assume that you have a task worth 10 days of development effort which is
being done by a single developer, Joe. He knows what to do and could take the
task and run with it. In a way, such a task is a 'natural' work unit.

However, another developer needs for his upcoming work, the API of the
module in development, which is going to be ready (if all goes well) after
3 days worth of work.

I find that having to split the task in two (or more) just to be able to
build my dependencies correctly is cumbersome: create a new task, describe
it (not really necessary, Joe knows exactly what he has to do), assign a
resource (with the chance that resource leveling will put it somewhere in
2010), an effort, etc.

An 'event' would simply be a satisfied condition or a state within a task.
I would have to give it a label, may be a planned completion time (date or
% of task) and eventually set the flag.

In principle, these 'events' are nothing else but a way to define
dependencies between any two points within tasks.

I often met situations as the example above in the past, where one had to
decide between the bore and effort to define zillions of almost senseless
tasks (ok, ok I am exagerating a bit), or accept that the dependency
network was in principle incorrect.

Ciao

-- 
Michele Ravani                  [email protected]
"Those who live hoping, die singing" My Gran