Re[4]: Idea: Dependencies between Tasks

On 04 Jul 2002 11:03:06 +0200 Mikael Hallendal <[email protected]> wrote:

MH> In the example you described there _is_ to phases (or more) of the
MH> large
MH> task that you have. The design of the API is it's own subtask and
MH> should
MH> be described as such. 

Yes, but is it really worth define it as a task, considering that it may
add nothing to the control you have on the project?

MH> I think that having some kind of "events" that does the exact same job
MH> as the subtasks (in a much fuzzier way) is only confusing and doesn't
MH> really solve anything that isn't done correctly by using subtasks.

I guess one could get religious about stuff like this, but you are right:
the events are a fuzzy, very fuzzy version of the sub-task. I would like
it, because I have come across situations where separating the
implementation of tens and tens of modules in 'Design', 'Implementation'
and 'Unit test' may be syntactically correct, but practically rather
annoying (not to mention the queer looks you get from your manager and
developers). 

What I am trying to say it that it would be good to be able to introduce
stuff like 'Joe just told me that the module can be tested' in the
dependency diagram, without having to get down to a level of task detail
which I never intended to reach in the first place.

As I mentioned in my previous mail: I have the choice between the task
detail level I want and an incorrect dependency model, or zillions of tasks
nobody realy wants and the correct dependency model.

Anyway, it was just an idea ...

Ciao ;o)

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