[kplato] CVS Diff changes

[Chris Clarke]

On Thursday 05 July 2001 00:07, Thomas Zander wrote:

[Snip agreed to stuff]

[Snip my change that milestones can have dependencies]

> But not children, right?  (meaning; there can be nothing dependent on a
> milestone) Then the addDependParentNode() is a better choice.

I think you're right.  This might be a question to throw up to the more 
serious project managers.  Just for clarification, when I refer to a 
milestone I'm used to it being something that's contractually defined for 
partial payment, i.e. once we've completed this set of tasks the customer 
signs off on it, we get paid for that portion and continue work on the next 
part.

I can't think of any realistic situations where we would hold up work on 
something until that milestone is signed off.

> Oops, I see I replaced the addDependNode with addDependChildNode and
> addDependParentNode in KPTNode, but not in its decendants..
> Could you, I'm leaving in an hour.
>
> > * Added a virtual removeDependNode to KPTNode (for completeness)
>
> same as above.

Ok.

[Snip my (knowingly controversial) idea that a resource is actualy a node]

> Well, you are right that it exists in the tree structure, but not right in
> saying its in the same leagea as a  node.
>
> - Resources exist outside of the project scope, they can be used over
> several projects.
> - Resources don't have about halve the functionality stated in the kptnode,
> things like starttime/duration dependent nodes are all not for resources.

Resources share more with a node than you might think.  Examples:

- I'm getting loaned somebody from another team, but they're not available 
until mid-July, that could be a start-by constraint (this could also be 
covered in the availability calendar though)

- Developer 1 requires specific hardware in order to do the work.  This 
hardware is shared across multiple departments.  I would put a start-start 
dependency on this, since the availability of the hardware depends on prior 
schedules.

(BTW if you notice me harping a lot on the "hardware available" issue, this 
is due to past experience when it was a significant problem to me and I have 
never found software that can adequately deal with it).

Definitely the relationships won't be as complicated as the tasks, but I can 
still see them being there.

I will go through the KPTNode definition in more detail today and see if 
there is enough commonality between that and a resource to warrant the 
inheritance.  If not I'll revert it :-)

> My goal was to add a resource-pool later which manages the resources
> (between different projects etc), this can't be done in a nice way if
> resources are not a seperate object.

Agreed.  I think resources need to function as a seperate object for the 
pool.  I also have a feeling that they really need to look like a node when 
we're looking at them from the task breakdown.  Again, I'll go through this 
in detail today and get back to you with a complete analysis.

> > * KPTRisk (and all the associated functions) get moved out of KPTResource
> > and up into KPTNode.  The theory behind this is when I'm planning,
> > anything in the near future will be broken down into subtasks, then
> > resources, and planned down to the last person.  Things farther in the
> > future will not be planned to the same detail -- I'll give the task an
> > estimated duration and risk, then when I get closer I'll break it down
> > into resources.  Basically the test is any node that does not have
> > children can have a duration and a risk assigned to it.
>
> hmm, does that not break the things we discussed earlier, that only a
> resource combined with a task can have a risk??

Hmm, you're right there, as I think about it in my experience the following 
can have risk:

- Resource combined with a task
- Task with no resources yet allocated to it (more below)

And a resource alone cannot have a risk.

> I don't fully understand your reasoning here, we are working or relations
> and you talk about user behavior..
>
> If you are right that a task can have a duration and risk, no problem, but
> this is new to me.

Okay, this is another one we should probably throw up to the more experienced 
project managers, but here's what I've been taught for long term project 
planning:

1. Plan out the entire network at a high level of detail.
2. Do the detailed breakdown and assignment of resources for the next six 
months (as this about as far ahead as I can accurately guess resources)
3. For the rest of the high level, I would assign estimated duration based on 
experience (i.e. other projects of similar size), and assign a risk that 
indicates my confidence in that estimate.

In order to be able to do that we need to be able to associate a 
risk/duration with a task alone.  One way around this would be to assign a 
default resource to a task if there isn't one.  We could then enforce the 
constraint that only task/resource pairings have durations and risks (come to 
think of it this is a good idea, and could solve some other problems I see 
arising).

I need to do some thinking about this, because there are a few problems to 
solve:

1) The constraint that assigned risk (calculated is another matter) only 
exists in a task/resource pairing.

2) An effort is associated with a class of resources; i.e. adding a computer 
doesn't affect the number of man hours available.

3) Technically a task alone does not have an effort (effort is assigned time, 
duration is calculated time).  Example "Develop x module" requires 150 
manhours -- this only makes sense if a developer is assigned. 

I think I'm beginning to see a way around this and to pull KPTResource back 
out from under KPTNode.  I still need to think about it a bit, but I'll throw 
up some code later.

> > * Moved all KPTResource functions (which were KPTRisk originally :-) out
> > of KPTNode and into KPTTask; from what I can see it only makes sense to
> > assign resources to tasks -- we wouldn't assign them to milestones or
> > other resources.
>
> Right, makes OO programming a tad harder, since we have to make sure to use
> KPTTaks at the points we are using risks/resources.
> But ok.

I think this is a valid constraint -- we would only ever have risks/resources 
assigned to a task (even more specifically, only to tasks that have no 
subtasks).  But I'm open to suggestions otherwise.

[Snip encapsulating duration into its own object]

> Sounds good, I think you should have a data-only class for that and leave
> the calculations stuff in the node-and-friends. So asking a task will
> do something like:
>  do we have a timing-object?
>  yes: use it to calculate stuff, and return that.
>  no: ask all our children to calculate theirs and add that, then return.

Sounds good.

[Snip]

> Ok, as I have about 30 mins left before I leave, I just commited this,
> please take care about the point of resouces, that is the only thing I
> think you made a thinking error.

I'll think about that in a lot more detail today.  I know there were 
questions about that when I first brought it up last month too.  

> Further; looks good and thanks ;)
>
>
> ps. you can always use cvs update -D "yesterday" or simular to get back
> to an earlier version.
> (cvs update -D "1 May 2001", cvs update -A to get back to current version)

I will keep that in mind :-)

Chris.
-- 
Chris Clarke
chris.clarke@cfourconsulting.com
http://cfourconsulting.com