Requirements for a new and improved Gantt plugin
Chris Nelson
I'll start here and if this isn't the right forum, we can copy my comments to whereever they belong.
A Gantt plugin for Trac should analyze ticket dependencies and produce an interactive, explorable Gantt chart showing task progress and project status.
By "project", I mean a set of related milestones. Perhaps a software project has a Design Phase, an Alpha Release, a Beta Release, and a General Release. Each would be a milestone with a target date and tickets to complete the work for that milestone. There must be a way to specify which milestones to include either listing explicitly or by giving a pattern or substring filter.
The chart should be able to show all tickets, though that may be a very complex chart.
The chart should support interactively "folding" groups of tasks to hide detail.
Tasks/tickets in the chart should be links to the tickets they represent.
To effectively display project progress, tickets must have estimated and actual times as in the TimingAndEstimation plugin. Each task's bar in the chart should show actual hours.
The chart should have a Today line
Ticket dependencies that must be supported include:
1. Task B must follow task A.
2. Task A is composed of tasks B and C. A's estimated time is the total of B's and C's.
3. Tasks A and B start at the same time
4. Tasks A and B must end at the same time
Type 1 dependency is implemented in the MasterTicket plugin. Note that a task may have many predecessors and many successors.
Type 2 dependency is necessary to support "folding" or "zooming" detail in the chart. It is also generally useful and might be implemented as its own plugin that the Gantt chart could require. Note that is should be possible to create a tree where A is composed of B and C, and B is composed of D and E, and C is composed of F, G, and H.
Types 3 and 4 are more unusual and a useful Gantt chart can be created without immediate support for these links in the first release.
It is also desirable to have loop detection to error-proof the tool used to create dependencies.
It would be nice to be able to choose an As Late As Possible or As Soon As Possible algorithm for laying out tasks.
The chart (or an accompanying report or tool) should aid in resource leveling by (at least) showing overcommitted resources.
That's a start. Comments?
Chris
--
Christopher Nelson, Software Engineering Manager
SIXNET, 331 Ushers Road, Ballston Lake, NY 12065
Phone: +1(518)877-5173, Facsimile: +1(518)877-8346
Innovative. Open. Industrial Data Products. http://www.sixnetio.com
Joseph, Ray
> From: trac-...@googlegroups.com [mailto:trac-...@googlegroups.com]
> On Behalf Of Chris Nelson
> Sent: Wednesday, April 08, 2009 4:06 PM
> To: trac-...@googlegroups.com
> Subject: [Trac] Requirements for a new and improved Gantt plugin
>
>
> The consensus on http://groups.google.com/group/trac-
> users/browse_thread/thread/83c0b6a248040542?hl=en seemed to be that we
> would like a better Gantt plugin. I'd like to gather the requirements
Yes, a method is a great start: Define the problem, develop a
goal/vision, collect requirements, define a functional architecture . .
.
Step 1:
Can a consensus be obtained for a problem statement?
Ray
______________________________________________________________________
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain information which is confidential to, and/or privileged in favor of, CDI Corporation or its affiliated companies (CDI) or CDI's customers. Any review, use, reproduction, disclosure or distribution by the recipient is prohibited without prior written approval from an authorized CDI representative. This notice must appear in any such authorized reproduction, disclosure or distribution. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message and any attachments. Thank you.
Greg Troxel
2. Task A is composed of tasks B and C. A's estimated time is the
total of B's and C's.
This makes sense, and I think it would be good to have support for this
independent of a gantt plugin.
nit: Task A might have hours for A, in addition to subtasks B and C.
You might want to ban this by policy, but it makes sense for some people.
In the requirements, it's not clear to me if the scheduling is supposed
to be resource aware or not. It's easy to push tasks to earlier when
they don't depend, but that can use more resources than are available.
So the question is are we trying to make pretty pictures to show a
schedule that we sort of figured out some other way, or to ask
trac/plugins what the best guess at the schedule really is.
3. Tasks A and B start at the same time
4. Tasks A and B must end at the same time
I don't think this is realistic from the reality point of view. I think
it's more like point 2 above that has A composed of B and C and C
depends on B so you get
A_start <= B_start [resource] B_end <= C_start [resource] C_end <=
[resource for A]? A_end
which is perhaps a reason not to allow time in A not in subtasks.
And if there is no time in A, then A_start = min(Asub_start) and A_end
is max(Asub_end).
Chris Nelson
> 2. Task A is composed of tasks B and C. A's estimated time is the
> total of B's and C's.
>
> This makes sense, and I think it would be good to have support for
> this independent of a gantt plugin.
Yes. I agree. It would be a nice piece of separate functionality that
a Gantt plugin could require. Shall we call it CompositeTicket for the
purposes of discussion?
> nit: Task A might have hours for A, in addition to subtasks B and C.
> You might want to ban this by policy, but it makes sense for some
> people.
If A is do B and C and spend time coordinating them, I'd argue that that
coordination is task D. (Though I admit that time might be concurrent
with A and B. Maybe the solution is to pad tasks B and C for the
management overhead in coordinating them.) But I really wouldn't want
to have time in a task that's decomposed into other tasks.
> In the requirements, it's not clear to me if the scheduling is
> supposed to be resource aware or not. ...
That's a good question. As long as it's isolated in a plugin and not
tangling up the core, I don't know that it's a bad thing that the Gantt
plugin is resource aware. Or maybe there's a Resource Leveling plugin
that requires the Gantt plugin. (And a Project Management package that
bundles TimingAndEstimation, MasterTicket, CompositeTicket, Gantt, and
Resource.)
> 3. Tasks A and B start at the same time
> 4. Tasks A and B must end at the same time
>
> I don't think this is realistic from the reality point of view.
I have an associate who's a certified project planner and he couldn't
come up with examples of those uses either, though he confirmed that
they are considered valid to project management weenies.
> ...
Jeff Hammel
>
> Greg Troxel wrote:
> > 2. Task A is composed of tasks B and C. A's estimated time is the
> > total of B's and C's.
> >
> > This makes sense, and I think it would be good to have support for
> > this independent of a gantt plugin.
>
> Yes. I agree. It would be a nice piece of separate functionality that
> a Gantt plugin could require. Shall we call it CompositeTicket for the
> purposes of discussion?
I've always like SubTasks, but nomenclature aside, its functionality that I've wanted for a long time (or more correctly, that other people have repeatedly asked for). Ideally, I'd like to see this in core, but since I know that's unlikely, at least as its own plugin that other plugins could consume.
> > nit: Task A might have hours for A, in addition to subtasks B and C.
> > You might want to ban this by policy, but it makes sense for some
> > people.
>
> If A is do B and C and spend time coordinating them, I'd argue that that
> coordination is task D. (Though I admit that time might be concurrent
> with A and B. Maybe the solution is to pad tasks B and C for the
> management overhead in coordinating them.) But I really wouldn't want
> to have time in a task that's decomposed into other tasks.
>
>
> > In the requirements, it's not clear to me if the scheduling is
> > supposed to be resource aware or not. ...
>
> That's a good question. As long as it's isolated in a plugin and not
> tangling up the core, I don't know that it's a bad thing that the Gantt
> plugin is resource aware. Or maybe there's a Resource Leveling plugin
> that requires the Gantt plugin. (And a Project Management package that
> bundles TimingAndEstimation, MasterTicket, CompositeTicket, Gantt, and
> Resource.)
>
>
> > 3. Tasks A and B start at the same time
> > 4. Tasks A and B must end at the same time
> >
> > I don't think this is realistic from the reality point of view.
>
> I have an associate who's a certified project planner and he couldn't
> come up with examples of those uses either, though he confirmed that
> they are considered valid to project management weenies.
Weighing in on this discussion late, I haven't used the GanttPlugin but am very interested in time-tracking via Trac. I co-wrote the TracHours plugin in response to user-critiques of the TimingAndEstimation plugin. Still, the latter is more mature and TracHours still lacks much functionality. I would love to see a definitive solution to time-tracking in Trac and am willing to contribute what I can in terms of expertise (and less so in time, unless it becomes an organizational priority again) to this end.
Jeff
Olemis Lang
>
> I'd like to gather the requirements for it.
:o)
> Is it best to do it in a thread on this mailing list or start a wiki page at Trac-Hacks ?
>
both ;o)
-1 for tickets, so far ...
> I'll start here and if this isn't the right forum, we can copy my comments to whereever they belong.
>
wiki page
> A Gantt plugin for Trac should analyze ticket dependencies and produce an interactive, explorable Gantt chart showing task progress and project status.
>
+1
> By "project", I mean a set of related milestones.
Milestones *SHOULD* be represented in the diagram as a single point at
due time | date
> Perhaps a software project has a Design Phase, an Alpha Release, a Beta Release, and a General Release. Each would be a milestone with a target date and tickets to complete the work for that milestone. There must be a way to specify which milestones to include either listing explicitly
+1
> or by giving a pattern or substring filter.
>
+0.5
> The chart should be able to show all tickets, though that may be a very complex chart.
>
or alternately all those tickets matched by a (query | report) or any
other ticket group provider ;)
> The chart should support interactively "folding" groups of tasks to hide detail.
>
+1
> Tasks/tickets in the chart should be links to the tickets they represent.
>
+1
> To effectively display project progress, tickets must have estimated and actual times as in the TimingAndEstimation plugin.
Is this sched vs execution (plan vs real progress ;) time?
> Each task's bar in the chart should show actual hours.
>
+0
> The chart should have a Today line
>
+1
> Ticket dependencies that must be supported include:
>
> 1. Task B must follow task A.
> 2. Task A is composed of tasks B and C. A's estimated time is the total of B's and C's.
What does this means exactly ? How will it be represented in the chart?
Two many lines is annoying ...
> 3. Tasks A and B start at the same time
> 4. Tasks A and B must end at the same time
>
+1
> Type 1 dependency is implemented in the MasterTicket plugin. Note that a task may have many predecessors and many successors.
>
> Type 2 dependency is necessary to support "folding" or "zooming" detail in the chart. It is also generally useful and might be implemented as its own plugin that the Gantt chart could require. Note that is should be possible to create a tree where A is composed of B and C, and B is composed of D and E, and C is composed of F, G, and H.
>
About providing the data to Gantt plugin and the interaction with
other plugins, specific interfaces (dont know if they'r already there
;) should be included in order to gather the data about WBS and deps,
and so on. I mean instead of requiring a plugin, IMHO it is better to
say «if you want to render data in your Gantt chart, implement
interfaces X, Y, Z and config» instead of «Gantt plgin depends on
plgin X, Y, Z». This also means that users will be able to use their
own estimation and deps algos if they want to.
> Types 3 and 4 are more unusual and a useful Gantt chart can be created without immediate support for these links in the first release.
>
+1 ...
> It is also desirable to have loop detection to error-proof the tool used to create dependencies.
>
hmmm ... perhaps stated like this :
«loops and other errors should be highlighted in the graph»
> It would be nice to be able to choose an As Late As Possible or As Soon As Possible algorithm for laying out tasks.
>
IMHO this should be left to other plugins (components), in order to
allow different approaches (perhaps providing a default impl, ok I
agree)
> The chart (or an accompanying report or tool) should aid in resource leveling by (at least) showing overcommitted resources.
>
But this is a completely different & potentially complex (yet useful)
development needed. Perhaps it should be deferred ... practical dev is
important ;)
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Se retira el BDFL ... ¿El fin de Python 3k? -
http://feedproxy.google.com/~r/simelo-es/~3/HpncxTKfB1c/se-retira-el-bdfl-el-fin-de-python-3k_02.html
Olemis Lang
> On Wed, Apr 8, 2009 at 4:06 PM, Chris Nelson <Chr...@sixnetio.com> wrote:
>
>> Type 1 dependency is implemented in the MasterTicket plugin. Note that a task may have many predecessors and many successors.
>>
>> Type 2 dependency is necessary to support "folding" or "zooming" detail in the chart. It is also generally useful and might be implemented as its own plugin that the Gantt chart could require. Note that is should be possible to create a tree where A is composed of B and C, and B is composed of D and E, and C is composed of F, G, and H.
>>
>
> About providing the data to Gantt plugin and the interaction with
> other plugins, specific interfaces (dont know if they'r already there
> ;) should be included in order to gather the data about WBS and deps,
> and so on. I mean instead of requiring a plugin, IMHO it is better to
> say «if you want to render data in your Gantt chart, implement
> interfaces X, Y, Z and config» instead of «Gantt plgin depends on
> plgin X, Y, Z». This also means that users will be able to use their
> own estimation and deps algos if they want to.
>
To be more precise in this point. Trac Gantt may be considered a
potential example of MVC architecture. In other words :
- Model : Tickets, resources, and othe PM-spec «artifacts», part of
Estimation, and deps
- View : TracGantt, but nothing (little ;) beyond UI
- Controller: Parts of Estimation, deps ...
If we have interfaces to put all this together and be able to change
all layers at any time then we have a flexible design, and a useful
and manage-able set of components which can be devd ...
Chris Nelson
> On Wed, Apr 8, 2009 at 4:06 PM, Chris Nelson <Chr...@sixnetio.com>
> wrote:
>>
>> I'd like to gather the requirements for it.
>
>> o)
>
>> Is it best to do it in a thread on this mailing list or start a wiki
>> page at Trac-Hacks ?
>>
>
> both ;o)
I'll start the page after in a few days and summarize this thread there.
> ...
>> By "project", I mean a set of related milestones.
>
> Milestones *SHOULD* be represented in the diagram as a single point
> at due time | date
Little diamonds like Microsoft Project? Yes, I agree.
>...
>> The chart should be able to show all tickets, though that may be a
>> very complex chart.
>
> or alternately all those tickets matched by a (query | report) or any
> other ticket group provider ;)
Oh, that'd be nice. Have a "Chart these" button on a ticket report page.
>...
>> To effectively display project progress, tickets must have estimated
>> and actual times as in the TimingAndEstimation plugin.
>
> Is this sched vs execution (plan vs real progress ;) time?
My bias is for the way we use it here: actual is how much time you've put in. Estimate is how long it's expected to take. When we accept a ticket, we put in an initial estimate. If we find out that the task is much more or less complex than originally believed, we revise the estimate. Time remaining is always estimate-actual. However, since this seems to be a matter of contention, I think I'd take Yogi Barra's advice (When you get to a fork in the road, take it.) and add a configuration option to specify whether remaining time is in the DB or must be computed.
>...
>> Ticket dependencies that must be supported include:
>>
>> 1. Task B must follow task A.
>> 2. Task A is composed of tasks B and C. A's estimated time is the
>> total of B's and C's.
>
> What does this means exactly ? How will it be represented in the
> chart?
That would depend on what level of detail you'd zoomed to. I would expect to see only A until I drilled down by clicking on it or something then A would be replaced by B and C.
>...
> About providing the data to Gantt plugin and the interaction with
> other plugins, specific interfaces (dont know if they'r already there
> ;) should be included in order to gather the data about WBS and deps,
Remind me what WBS is?
> and so on. I mean instead of requiring a plugin, IMHO it is better to
> say «if you want to render data in your Gantt chart, implement
> interfaces X, Y, Z and config» instead of «Gantt plgin depends on
> plgin X, Y, Z». This also means that users will be able to use their
> own estimation and deps algos if they want to.
Yes, I see your point. Gantt would have configuration options to specify what fields to get things out of so you could layer it on TimingAndEstimation or TracHours or whatever. Those configuration values could default to expecting a certain plugin but not require that plugin.
>> Types 3 and 4 are more unusual and a useful Gantt chart can be
>> created without immediate support for these links in the first
>> release.
>
> +1 ...
You're in favor of type 3 and 4 dependencies or of deferring their implementation?
>> It is also desirable to have loop detection to error-proof the tool
>> used to create dependencies.
>>
>
> hmmm ... perhaps stated like this :
>
> «loops and other errors should be highlighted in the graph»
Maybe.
>> It would be nice to be able to choose an As Late As Possible or As
>> Soon As Possible algorithm for laying out tasks.
>
> IMHO this should be left to other plugins (components), in order to
> allow different approaches (perhaps providing a default impl, ok I
> agree)
Maybe. I'm not sure how this would work.
>> The chart (or an accompanying report or tool) should aid in resource
>> leveling by (at least) showing overcommitted resources.
>
> But this is a completely different & potentially complex (yet useful)
> development needed. Perhaps it should be deferred ... practical dev
> is important ;)
I agree it's not integral to charting dependencies.
Eirik Schwenke
Hash: SHA1
Olemis Lang skrev 09. april 2009 15:54:
> On Thu, Apr 9, 2009 at 8:43 AM, Olemis Lang <ole...@gmail.com> wrote:
(...)
> To be more precise in this point. Trac Gantt may be considered a
> potential example of MVC architecture. In other words :
It was, in fact, used in the first ever paper on MVC:
http://folk.uio.no/trygver/2007/MVC_Originals.pdf
"I made the first implementation and wrote the original MVC reports
while I was a visiting scientist at Xerox Palo Alto Research
Laboratory (PARC) in 1978/79."
(...)
"They are described in my first note of May 12, 1979:
THING-MODEL-VIEW-EDITOR -.an Example from a planningsystem."
(...)
"Date 12 MAY 1979
The purpose of this note is to explore the thing-model-view-editor
metaphors through a coherent set of examples. The examples are all
drawn from my planningsystem, and illustrate the above four notions."
(...)
"The diagram is an instance of class GanttView, which is a subclass of
ChartView. ChartView knows about the diagram background: axis with
legend, gridding etc. It does not know anything about the information
to be put into the diagram, in this case the horizontal bars."
Still an interesting read, almost 40 years later, to the day.
You might also find the newest paper by Trygve Reenskaug (same author)
and James Coplien interesting:
http://www.artima.com/articles/dci_vision.html
"The DCI Architecture: A New Vision of Object-Oriented Programming"
- -e
- --
.---. Eirik Schwenke <eirik.s...@nsd.uib.no>
( NSD ) Harald Hårfagresgate 29 Rom 150
'---' N-5007 Bergen tlf: (555) 889 13
GPG-key at pgp.mit.edu Id 0x8AA3392C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkneDtoACgkQxUW7FIqjOSyaiQCgnXGSJlpsFhLp1dUAmbaxewNR
++IAoKHUN8EpvCit8QyjK0kuKTfNQ7gI
=52s3
-----END PGP SIGNATURE-----
Eirik Schwenke
Hash: SHA1
Eirik Schwenke skrev 09. april 2009 17:06:
> Olemis Lang skrev 09. april 2009 15:54:
>> On Thu, Apr 9, 2009 at 8:43 AM, Olemis Lang <ole...@gmail.com> wrote:
> (...)
>> To be more precise in this point. Trac Gantt may be considered a
>> potential example of MVC architecture. In other words :
>
(...)
>
> "Date 12 MAY 1979
(...)
>
> Still an interesting read, almost 40 years later, to the day.
Erm. Lets see. 2009-1979=30 ... oh well. Still a good while back.
- -e
- --
.---. Eirik Schwenke <eirik.s...@nsd.uib.no>
( NSD ) Harald Hårfagresgate 29 Rom 150
'---' N-5007 Bergen tlf: (555) 889 13
GPG-key at pgp.mit.edu Id 0x8AA3392C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkneD7QACgkQxUW7FIqjOSx+uACgiA7XmZ9KNmEJB2dtZTc4D0gU
c4kAniVOmxva2zyt8BDriHov/mFwuTut
=fUwQ
-----END PGP SIGNATURE-----
Olemis Lang
> Olemis Lang wrote:
>> On Wed, Apr 8, 2009 at 4:06 PM, Chris Nelson <Chr...@sixnetio.com>
>> wrote:
>>...
>>> To effectively display project progress, tickets must have estimated
>>> and actual times as in the TimingAndEstimation plugin.
>>
>> Is this sched vs execution (plan vs real progress ;) time?
>
> My bias is for the way we use it here: actual is how much time you've put in. Estimate is how long it's expected to take.
This could look like progress bars representing tasks in the chart ;)
> think I'd take Yogi Barra's advice (When you get to a fork in the road, take it.) and add a configuration option to specify whether remaining time is in the DB or must be computed.
>
Let's write an interface for this and everybody will be able to do it
their own way ;)
>>> Ticket dependencies that must be supported include:
>>>
>>> 1. Task B must follow task A.
>>> 2. Task A is composed of tasks B and C. A's estimated time is the
>>> total of B's and C's.
>>
>> What does this means exactly ? How will it be represented in the
>> chart?
>
> That would depend on what level of detail you'd zoomed to. I would expect to see only A until I drilled down by clicking on it or something then A would be replaced by B and C.
>
Oh yes ! This being said, it seems to be a great option !
>>...
>> About providing the data to Gantt plugin and the interaction with
>> other plugins, specific interfaces (dont know if they'r already there
>> ;) should be included in order to gather the data about WBS and deps,
>
> Remind me what WBS is?
>
Work-Breakdown Structure
;o)
>> and so on. I mean instead of requiring a plugin, IMHO it is better to
>> say «if you want to render data in your Gantt chart, implement
>> interfaces X, Y, Z and config» instead of «Gantt plgin depends on
>> plgin X, Y, Z». This also means that users will be able to use their
>> own estimation and deps algos if they want to.
>
> Yes, I see your point. Gantt would have configuration options to specify what fields to get things out
Or what IGanttProvider (the name is a joke, the idea is serious but
possibly more than a single interface) will provide the (useful) data
about the tickets being rendered, since possibly some of them may be
computed at «display-time» and are not stored in tickets .
> of so you could layer it on TimingAndEstimation or TracHours or whatever. Those configuration values could default to expecting a certain plugin but not require that plugin.
>
... What t(he)ll, you 'r the first person ( since too long ) that
understands me ... that's why I love Trac ;)
>
>>> Types 3 and 4 are more unusual and a useful Gantt chart can be
>>> created without immediate support for these links in the first
>>> release.
>
>>
>> +1 ...
>
> You're in favor of type 3 and 4 dependencies
+1
> or of deferring their implementation?
>
... but include'em later ;)
>>> It would be nice to be able to choose an As Late As Possible or As
>>> Soon As Possible algorithm for laying out tasks.
>>
>> IMHO this should be left to other plugins (components), in order to
>> allow different approaches (perhaps providing a default impl, ok I
>> agree)
>
> Maybe. I'm not sure how this would work.
>
ok .. when details be out there, we'll c ... I'm in to develope this
Greg Troxel
"Chris Nelson" <Chr...@sixnetio.com> writes:
> Greg Troxel wrote:
>> 2. Task A is composed of tasks B and C. A's estimated time is the
>> total of B's and C's.
>>
>> This makes sense, and I think it would be good to have support for
>> this independent of a gantt plugin.
>
> Yes. I agree. It would be a nice piece of separate functionality that
> a Gantt plugin could require. Shall we call it CompositeTicket for the
> purposes of discussion?
There is already on the wiki
http://trac.edgewall.org/wiki/SubTickets
This seems ok, but perhaps overly complicated. I see this being either
very much like a second copy of MasterTickets, or a modification to
MasterTickets to add a new column to the dependency table to distinguish
between blocks and is-part-of. It seems like almost the same thing
mechanically as blocking/blocked-by, with a property on each dependency
saying which kind it is.
>> nit: Task A might have hours for A, in addition to subtasks B and C.
>> You might want to ban this by policy, but it makes sense for some
>> people.
>
> If A is do B and C and spend time coordinating them, I'd argue that that
> coordination is task D. (Though I admit that time might be concurrent
> with A and B. Maybe the solution is to pad tasks B and C for the
> management overhead in coordinating them.) But I really wouldn't want
> to have time in a task that's decomposed into other tasks.
This is probably a reasonable view, but what you're doing is making
decisions about what kinds of project management rules people can have
and still use the SubTickets and TimingAndEstimation plugins. But, all
it forces is for people to make one more ticket to have the work that
would have been in the parent ticket, and that probably makes life
simpler more than it hurts.
>> In the requirements, it's not clear to me if the scheduling is
>> supposed to be resource aware or not. ...
>
> That's a good question. As long as it's isolated in a plugin and not
> tangling up the core, I don't know that it's a bad thing that the Gantt
> plugin is resource aware. Or maybe there's a Resource Leveling plugin
> that requires the Gantt plugin. (And a Project Management package that
> bundles TimingAndEstimation, MasterTicket, CompositeTicket, Gantt, and
> Resource.)
I think it would be the other way around, that Gantt would require
Scheduling, but one could view that as one of Gantt's core jobs. To me,
the whole point is to look at all the data of what needs to be done and
generate a valid schedule. Displaying the schedule is necessary to
understand the data, but isn't the main point.
Can you explain a use case for Gantt without Scheduling? How would
dates be chosen for drawing? Why would this make any sense?
(Not trying to be difficult - I really do not get it.)
>> 3. Tasks A and B start at the same time
>> 4. Tasks A and B must end at the same time
>>
>> I don't think this is realistic from the reality point of view.
>
> I have an associate who's a certified project planner and he couldn't
> come up with examples of those uses either, though he confirmed that
> they are considered valid to project management weenies.
There is the notion of a start time, and then the more important notion
of how many hours of each resource are applied in each period. If it's
started but has no resources, then it doesn't mean much.
But, if we extend MasterTickets to have a dependency type, these could
be expressed easily enough.
yoheeb
need is something that can "gantt" A MasterTickets tree, and sum
serial tasks up into a field in the parent ticket (ok, probably 2,
SEQUENTIAL, and totals) Essentially what Agilo can do for linked
ticket types. of course, most gantts use days as a time frame, and
most tickets use estimated hours, so a conversion. I wouldn't even
want it to dynamically adjust on a ticket in progress. A ticket is
either "complete" or fully in the chart.
That said, a macro, plus the TracGViz extension recently created,
would let you throw it out to google, then get back that information
in any fancy way you want.
I am COMPLETELY against patching trac core to support features for
purely resource planning, PM facilities. I would however, welcome a
plugin, or set of plugins, if flexible.
Essentially, if you plot a master-tickets DepGraph sideways, and sum
up the paths, you have your gantt, it has all the scenarios you
want. parallell, sequential, both. Just need to add in the sums, and
put dates on the plots. I happen to use a feature-branch model, with
feature/child tickets, and create a "sub" milestone, so I am half way
there. (and child tickets can have children....)
The ability for summed fields of "linked" tickets is more versatile
than just gannt charts. business value points of "features", scoring
severity sums of ticket paths, etc.
So, right there, I think I have identified 2, maybe 3 separate plugins
that could be created as stand along, but leveraged into the whole
thing...
Just a thought.
Chris Nelson
> "Chris Nelson" <Chr...@sixnetio.com> writes:
>
>> Greg Troxel wrote:
>>> 2. Task A is composed of tasks B and C. A's estimated time is
>>> the total of B's and C's.
>>>
>>> This makes sense, and I think it would be good to have support for
>>> this independent of a gantt plugin.
>>
>> Yes. I agree. It would be a nice piece of separate functionality
>> that a Gantt plugin could require. Shall we call it CompositeTicket
>> for the purposes of discussion?
>
> There is already on the wiki
>
> http://trac.edgewall.org/wiki/SubTickets
Thanks for the reference.
> This seems ok, but perhaps overly complicated. I see this being
> either very much like a second copy of MasterTickets, or a
> modification to MasterTickets to add a new column to the dependency
> table to distinguish between blocks and is-part-of. It seems like
> almost the same thing mechanically as blocking/blocked-by, with a
> property on each dependency saying which kind it is.
I don't like the "MasterTickets" name. To me, it implies composition,
not serial dependency. As noted elsewhere in this thread, I think we
want the Gantt to have an interface or configuration option or something
which tells it what field to examine to get each type of dependency
information but not enforce a specific plugin as the means to create
that information.
>...
>>> In the requirements, it's not clear to me if the scheduling is
>>> supposed to be resource aware or not. ...
>>
>> That's a good question. As long as it's isolated in a plugin and not
>> tangling up the core, I don't know that it's a bad thing that the
>> Gantt plugin is resource aware. Or maybe there's a Resource Leveling
>> plugin that requires the Gantt plugin. (And a Project Management
>> package that bundles TimingAndEstimation, MasterTicket,
>> CompositeTicket, Gantt, and Resource.)
>
> I think it would be the other way around, that Gantt would require
> Scheduling, but one could view that as one of Gantt's core jobs. To
> me, the whole point is to look at all the data of what needs to be
> done and generate a valid schedule. Displaying the schedule is
> necessary to understand the data, but isn't the main point.
>
> Can you explain a use case for Gantt without Scheduling? How would
> dates be chosen for drawing? Why would this make any sense? (Not
> trying to be difficult - I really do not get it.)
Maybe I'm thinking about Pert more than Gantt (which might be useful,
too) but if the milestones are fixed in time (because they have due
dates) and if the Gantt can just analyze composition and start-to-end
dependencies, and estimates, it can work backward from the deadline and
show you how the tasks lay out. I see value in that even if I can't
change from ALAP to ASAP, level resources, etc., etc.
>...
Olemis Lang
> That said, a macro,
iGoogleGadget for sure (even if the way to do it is not documented ...
yet ;) Where is the gadget that renders Gantt charts? If any I could
try ASAP
> plus the TracGViz extension recently created,
> would let you throw it out to google, then get back that information
> in any fancy way you want.
TracGViz plugin has the advantage of providing the following alt to
develop new features:
- build GViz data src
- Feed data to visualizations
- Embed GViz gadgets using iGoogleGadget macro
[the short way until here]
- Build a web UI item to render the same data without needing iGoogle
containers, basically assuming the new widget will use the plain JSON
format using inline (in the HTML page) data ...
However you could just obviate the third step ;)
GViz protocol is all about decoupling UI from backend and app logic |
config | platform.
> I am COMPLETELY against patching trac core to support features for
> purely resource planning, PM facilities. I would however, welcome a
> plugin, or set of plugins, if flexible.
That's what we are talking about ... isnt it?
> Essentially, if you plot a master-tickets DepGraph sideways, and sum
> up the paths, you have your gantt,
Havent tried DepGraph yet ... :-/
yoheeb
> On Thu, Apr 9, 2009 at 10:34 AM, yoheeb <yoh...@gmail.com> wrote:
> > That said, a macro,
>
> iGoogleGadget for sure (even if the way to do it is not documented ...
> yet ;) Where is the gadget that renders Gantt charts? If any I could
> try ASAP
>
library:http://code.google.com/apis/visualization/documentation/
gadgetgallery.html
I linked just to the library, since there are a couple others there
that might acutally work as well, that offer different options, such
as
- the Timeline widget
- The Annotated Timeline widget
- Motion graph
etc. the gantt one is most likely the simplest in terms of this topic
Olemis Lang
> On Apr 9, 1:13 pm, Olemis Lang <ole...@gmail.com> wrote:
>> On Thu, Apr 9, 2009 at 10:34 AM, yoheeb <yoh...@gmail.com> wrote:
>> > That said, a macro,
>>
>> iGoogleGadget for sure (even if the way to do it is not documented ...
>> yet ;) Where is the gadget that renders Gantt charts? If any I could
>> try ASAP
>>
> well, you could try the Gantt one under the visualization
> library:http://code.google.com/apis/visualization/documentation/
> gadgetgallery.html
> I linked just to the library,
Yoheeb ... Could u please send me the exact link since I see nothing
below «Click a visualization below to see documentation and examples.»
in that page ? ... :(
Besides it seems that gadget is not syndicated since I couldnt find it
in iGoogle dir :-/
> since there are a couple others there
> that might acutally work as well, that offer different options, such
> as
> - the Timeline widget
> - The Annotated Timeline widget
> - Motion graph
Yes, I've seen'em all ... pretty cool gadgets ;o)
yoheeb
>
> Yoheeb ... Could u please send me the exact link since I see nothing
> below «Click a visualization below to see documentation and examples.»
> in that page ? ... :(
>
> Besides it seems that gadget is not syndicated since I couldnt find it
> in iGoogle dir :-/
>
your own copy link:
http://spreadsheets.google.com/ccc?key=pCQbetd-CptFuIeF11YJzCA&newcopy
( I can't follow it form work since the google login site is blocked
here at work.....)
and here is the link to the sponsoring companies site:
http://www.viewpath.com/SignupIQ/AP/Google/Docs/
The other ones mentioned:
timeline:
http://spreadsheets.google.com/ccc?key=pCQbetd-CptFcoG8LMqABJA&newcopy
get your own copy
http://jrochelle.googlepages.com/97g-timeline-about.html help/about
docs
Yunior Armando Hernandez Andrade
functionality, not just an external plug-in... although all options
within the functionality should be able to be disabled in the Admin page
in case project does not require it.
About that I think you are all missing some things, there are two
concepts within Project planning:
1- Resource Planning, and
2- Resource Tracking.
Understand "Resource" as time, workers, spendable objects (as paper,
ink, etc) and long life objects(as hammers, computers, etc)... Resource
Planning aims to set tasks (macro-tasks at beginning, that will most
likely be composed of other tasks as the project advances), task
dependency (four dependency types), estimated task's start and duration
time, estimated milestone dates, set each worker's working time and
dates, assign workers to tasks, assign time to objects that require it,
assign objects to tasks and/or to workers, and so but all that before
project starts the hard working.
Now, Resource Tracking aims to set task's REAL start and end date,
moving subsequent task's start and end dates for next tasks at user wish
or simply leaving empty time when wanted, reassign workers and objects
to tasks, reassign worker's working time and then reschedule the whole
subsequent tasks according to that, rearrange task's dependencies
TimeAndEstimation plugin solves SOME of the features in Resource
Tracking, MasterTickets almost solves 2 dependency types, etc... but no
plugin solves everything needed en project planning.
Jeff Hammel
>
> I think Trac should support project planning as an internal
> functionality, not just an external plug-in...
I disagree unless we're talking about way way long term. I think the first thing to do is cultivate agreement on HOW to do this (hard enough) and then start to work towards that coherent vision. There's a bunch that needs to be done in Trac core, and expanding scope at this point won't make that any faster.
Jeff
Olemis Lang
>
>
>>
>> Yoheeb ... Could u please send me the exact link since I see nothing
>> below «Click a visualization below to see documentation and examples.»
>> in that page ? ... :(
>>
>> Besides it seems that gadget is not syndicated since I couldnt find it
>> in iGoogle dir :-/
>>
> not sure exactly what "direct" link you are after
The link to the gadget descriptor file (xml) which is :
http://www.viewpath.net/Website/Modules/Gantt.aspx
> but here is the :get
> your own copy link:
> http://spreadsheets.google.com/ccc?key=pCQbetd-CptFuIeF11YJzCA&newcopy
That's for the example data so its not very useful ;)
> ( I can't follow it form work since the google login site is blocked
> here at work.....)
The only thing I can tell you so far is that tha supposed former
infatuation Gantt chart is not displayed with that example data, at
least for me
:-/
Thnx very much o<|:)
Olemis Lang
<yaher...@estudiantes.uci.cu> wrote:
>
> I think Trac should support project planning as an internal
> functionality, not just an external plug-in... although all options
> within the functionality should be able to be disabled in the Admin page
> in case project does not require it.
-1 ... Trac offers a minimalistic approach to PM ... so ...
> About that I think you are all missing some things, there are two
> concepts within Project planning:
> 1- Resource Planning, and
> 2- Resource Tracking.
> Understand "Resource" as time, workers, spendable objects (as paper,
> ink, etc) and long life objects(as hammers, computers, etc)... Resource
> Planning aims to set tasks (macro-tasks at beginning, that will most
> likely be composed of other tasks as the project advances), task
> dependency (four dependency types), estimated task's start and duration
> time, estimated milestone dates, set each worker's working time and
> dates, assign workers to tasks, assign time to objects that require it,
> assign objects to tasks and/or to workers, and so but all that before
> project starts the hard working.
> Now, Resource Tracking aims to set task's REAL start and end date,
> moving subsequent task's start and end dates for next tasks at user wish
> or simply leaving empty time when wanted, reassign workers and objects
> to tasks, reassign worker's working time and then reschedule the whole
> subsequent tasks according to that, rearrange task's dependencies
> TimeAndEstimation plugin solves SOME of the features in Resource
> Tracking, MasterTickets almost solves 2 dependency types, etc... but no
> plugin solves everything needed en project planning.
>
Perhaps all that is true ... however IMHO that indicates that few
people have decided to implement all those things, so *MAYBE* its not
as mandatory as it seems .
Chris Nelson
> functionality, not just an external plug-in... although all options
> within the functionality should be able to be disabled in the Admin
> page in case project does not require
I admit to being on the fence about this. Properly done, bits of add-in
functionality are more maintainable, more approachable, lower overhead,
etc. (And more easily developed by a distributed community, I think.)
I think of this as the UNIX tools model vs. the 'Windows monolithic blob
model. BUT, this is how Eclipse is built and I can't get Eclipse
installed with the plugins I need either one at a time or from a
pre-built bundle.
> About that I think you are all missing some things, there are two
> concepts within Project planning:
> 1- Resource Planning, and
> 2- Resource Tracking.
> Understand "Resource" as time, workers, spendable objects (as paper,
> ink, etc) and long life objects(as hammers, computers, etc)...
Yes, I see that. But if you're a professional project planner working
on the mission to Mars, you're not going to use Trac. There are
industrical-strength tools for that. I have 5 developers on my team.
We're in a larger group of a dozen engineers. We have 10-15 active
projects at once. That's too big to manage intuitively but, I think,
too small for all the bells and whistles of resource planning to be
necessary. I would not want to give up the information I'd get from a
quick-and-dirty Gantt because we are trying to develop One Module that
tracks paper clips as well as hours.
> Resource Planning aims to set tasks (macro-tasks at beginning, that
> will most likely be composed of other tasks as the project advances),
> task dependency (four dependency types), estimated task's start and
> duration time,
Maybe ALAP is just ingrained into my workflow and organization but to me
start dates are irrelevant. I work backwards from tasks in multiple
milestones trying to answer the question, "What should I be working on
today?" (for myself and for my group).
> ...
Yunior Armando Hernandez Andrade
> Yes, I see that. But if you're a professional project planner working
> on the mission to Mars, you're not going to use Trac.
Why not???? Trac is customizable, easy to learn, robust and more
important: Trac is free software. In the name of all heavens, Trac is
great! And I don't say it for myself, 96% of the Cubans that work in
some kind of project says it. Why not to use it in my "mission to mars"
project??? Answer: Lacks functionality.
From my point of view Trac can easily become the best project management
tool ever IF we all think what to do to accomplish that and stop been so
conformist. The idea of this being great and not to need new things just
because it works for what I do is not the best way to make it.
> Maybe ALAP is just ingrained into my workflow and organization but to
me
> start dates are irrelevant. I work backwards from tasks in multiple
> milestones trying to answer the question, "What should I be working on
> today?" (for myself and for my group).
Well you'll have to agree with me that then YOU ARE planning, just not
from the right approach. You plan everyday what you're going to do that
day, so you start date is...(background suspense music)... TODAY!
My people, planning is the key to controlled progress, just that we all
have not enough team work culture to plan everything in advance doesn't
mean your project don't need it or you don't need it.
Anyway, maybe is not a priority for you all. So I'll keep learning
python so that I could do it myself.
Olemis Lang
<yaher...@estudiantes.uci.cu> wrote:
>
> Cris Lang wrote
Oh my ! What t(he)ll !
I've a cloned out there ! ... Is this a chimera ? How many heads ?
Oh my god ! What plugin did I install to get that done ?
Please tell me ... Did Emperor Vader send it to conquer the Earth ?
jevans
On Apr 9, 9:01 am, "Chris Nelson" <Chr...@sixnetio.com> wrote:
> >> To effectively display project progress, tickets must have estimated
> >> and actual times as in the TimingAndEstimation plugin.
>
> > Is this sched vs execution (plan vs real progress ;) time?
>
> My bias is for the way we use it here: actual is how much time you've put in. Estimate is how long it's expected to take. When we accept a ticket, we put in an initial estimate. If we find out that the task is much more or less complex than originally believed, we revise the estimate. Time remaining is always estimate-actual. However, since this seems to be a matter of contention, I think I'd take Yogi Barra's advice (When you get to a fork in the road, take it.) and add a configuration option to specify whether remaining time is in the DB or must be computed.
actual work time spent, and the remaining estimate. During
development, I am most interested in the current estimated time
remaining. After completion it can be useful to compare the time it
actually took with the initial estimate.
- jevans
Chris Nelson
> On Apr 9, 9:01 am, "Chris Nelson" <Chr...@sixnetio.com> wrote:
>>>> To effectively display project progress, tickets must have
>>>> estimated and actual times as in the TimingAndEstimation plugin.
>>
>>> Is this sched vs execution (plan vs real progress ;) time?
> Personally, I'd like to see 3 values - the original estimate, the
> actual work time spent, and the remaining estimate. During
> development, I am most interested in the current estimated time
> remaining. After completion it can be useful to compare the time it
> actually took with the initial estimate.
I agree but since the initial estimate is still in the db, we don't really need three values. We run estimate accuracy estimates for our projects all the time.
Joseph, Ray
> Sent: Friday, April 10, 2009 11:46 PM
> To: Trac Users
> Subject: [Trac] Re: Requirements for a new and improved Gantt plugin
I am very glad to see the conversations on each of our visions of the proposed system.
All of the time fields discussed are relevant. They are not all directly related. They each have their own value in existence and can be used in comparisons and relationships but they are different and should be kept separate.
There is an initial estimate, time expended fact, time remaining calculation, and estimated time to completion, etc. Not all of these data points are 'owned' by the ticket responder. Tickets are used in many different ways: A ticket may be an execution token for a particular activity in an overall business solution program, an activity of a business program's project, a derivation of a project activity, or simply a step in a standard workflow. In each case, the data may be owned by someone other than the ticket responder (TR).
Of course, the ticket responder may have envisioned data structures of time fields for activities she wishes to accomplish. The responder is given time data from previous stakeholders. The TR has other activities that may need to be addressed in parallel with the ticket at hand, thus there are time durations for ticket activities but there are also timing considerations to efforts of other, possibly, non-related tasks. For example, the TR may have many tickets each with expected durations and possibly iterations with others in subtasks of the ticket at hand. The TR is not responsible for the subtasks that others are performing on the ticket and thus can only produce data on her own activities and can only report or 'pass forward' data on subtasks. Since the TR has other responsibilities, 8 hours on a ticket doesn't mean it will get done today. It may have many other tickets ahead of it on that TR's input queue. So there are task specific durations and there are integrated schedule durations. All of which must be considered.
So, when I am working at a company that has a business program to develop forestry products for South America and a business program to maintain existing supply chains for North Atlantic oil rigs, and there are projects under each of those programs for which I have tasks to perform in my domain of customer relations management, do I put timing data about my forestry program efforts in the ticket for the offshore rig program so I can keep them coordinated? As time goes on, the timing data will change. The business programs and projects are different, I am the only common stakeholder and through me they are related. If something changes in one, it affects the other. How many places do I put my timing data? When that data changes, where are all the places I have put that data that I will need to change?
How much information do I want my issue tracker application to carry? Can I keep my timing data in a separate store and let the issue tracker/project management tool access my time data store so the most up-to-date data is available to tracking concerns? In such a matrix organization, there are many people in my same situation and their commitments affect project schedules across the enterprise.
I know my vision is simplistic in comparison to coordination efforts of many others, but I would like to make sure that the lower level concerns are at least viewed if not addressed.
Ray
______________________________________________________________________
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain information which is confidential to, and/or privileged in favor of, CDI Corporation or its affiliated companies (CDI) or CDI's customers. Any review, use, reproduction, disclosure or distribution by the recipient is prohibited without prior written approval from an authorized CDI representative. This notice must appear in any such authorized reproduction, disclosure or distribution. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message and any attachments. Thank you.
Chris Nelson
>> ...
> I am very glad to see the conversations on each of our visions of the
> proposed system.
A flexible system can serve many needs.
> ... The business programs and
> projects are different, I am the only common stakeholder and through
> me they are related. If something changes in one, it affects the
> other. How many places do I put my timing data?
My goal would be only one place!
> When that data
> changes, where are all the places I have put that data that I will
> need to change?
>
> How much information do I want my issue tracker application to carry?
> Can I keep my timing data in a separate store and let the issue
> tracker/project management tool access my time data store so the most
> up-to-date data is available to tracking concerns? In such a matrix
> organization, there are many people in my same situation and their
> commitments affect project schedules across the enterprise.
I work in a multi-project matrix organization as well. I'm very
sensitive to the fact that one project can affect another in unexpected,
undesireable, and sometimes unavoidable ways. The key, to me, is that
you *know* those effects and can work around them. Being surprised on
the day of a milestone is not good.
Olemis Lang
>
> Joseph, Ray wrote:
>>> ...
>> I am very glad to see the conversations on each of our visions of the
>> proposed system.
>
> A flexible system can serve many needs.
>
:)
>
>> ... The business programs and
>> projects are different, I am the only common stakeholder and through
>> me they are related. If something changes in one, it affects the
>> other. How many places do I put my timing data?
>
> My goal would be only one place!
>
Even if it changes from one company to the other.
yoheeb
for me to say it shouldn't be part of the core, but some set of
coordinated plugins to achieve the final "goals" Similar to how
several tools have taken data from the TimeAndEstimation plugin to
achieve the end "goals"
As for the above comment about Eclipse. Actually, the reason I
stopped using Eclipse was as it matured, enough specific preferences/
usage expectations were added to the core, that it was more productive
to go back to Vi and command-line scripts for development.
Anyway, I am curious to see how this goes, there are some specific
things from the PM side I would love to pluck out and use in my trac
sites.
Chris Nelson
http://groups.google.com/group/trac-users/browse_thread/thread/83c0b6...
> Seemed to be that we would like a better Gantt plugin. I'd like to
gather the
> requirements for it. Is it best to do it in a thread on this mailing
list or start
> a wiki page at Trac-Hacks or create a ticket against an existing
plugin or what?
> ...
I tried to boil down this thread, my thoughts, and some other
discussions I've had into
http://trac-hacks.org/wiki/ProjectManagementIdeas . Feedback welcome.
Olemis Lang
I have written a little in there ... hopefully tomorrow I'll add a few
more things ...
Does this mean we are moving ? I think that it's nice to put the names
of all the potential contributors to this idea after your name in the
disclaimer (or somewhere else ...) so as to be aware of how many we 'r
;)
Is it a good idea ?
Chris Nelson
> On Thu, Apr 16, 2009 at 2:15 PM, Chris Nelson <Chr...@sixnetio.com>
> wrote:
>...
>> I tried to boil down this thread, my thoughts, and some other
>> discussions I've had into
>> http://trac-hacks.org/wiki/ProjectManagementIdeas . Feedback
>> welcome.
>
> I have written a little in there ... hopefully tomorrow I'll add a
> few more things ...
OK. Thanks.
> Does this mean we are moving ?
I hope so.
> I think that it's nice to put the
> names of all the potential contributors to this idea after your name
> in the disclaimer (or somewhere else ...) so as to be aware of how
> many we 'r ;)
>
> Is it a good idea ?
That's fine. I don't stake any claim; I'm just the scribe.
Crusty Applesniffer
I've just read your wiki page and I found (at the end of the page) a link to
"add" that return:
Error: Failed to load processor gantt
No macro or processor named 'gantt' found
A plugin may be missing in trackhacks (probably the "Gantt Chart Plug in")
Regards
-:: Crusty Applesniffer ::-
-----Message d'origine-----
De : trac-...@googlegroups.com [mailto:trac-...@googlegroups.com] De la
part de Chris Nelson
Envoyé : jeudi 16 avril 2009 21:15
À : trac-...@googlegroups.com
Objet : [Trac] RE: Requirements for a new and improved Gantt plugin
Michael Renzmann
> I've just read your wiki page and I found (at the end of the page) a link
> to "add" that return:
>
> Error: Failed to load processor gantt
>
> No macro or processor named 'gantt' found
>
> A plugin may be missing in trackhacks (probably the "Gantt Chart Plug in")
/wiki/add is the user page of user "add". No idea why someone added
content that is expected to be rendered with the gantt-processor, but it's
unlikely that this plugin gets installed on trac-hacks.org.
Bye, Mike
Joseph, Ray
> -----Original Message-----
> From: trac-...@googlegroups.com [mailto:trac-...@googlegroups.com]
> On Behalf Of Chris Nelson
> Sent: Thursday, April 16, 2009 2:15 PM
> To: trac-...@googlegroups.com
> Subject: [Trac] RE: Requirements for a new and improved Gantt plugin
>
> I tried to boil down this thread, my thoughts, and some other
> discussions I've had into
> http://trac-hacks.org/wiki/ProjectManagementIdeas . Feedback welcome.
The wiki is a great summary and platform for discussion. I see two
items of interest:
owner (who is working on it)
reporter (who wrote the ticket)
An implication for a team effort is that projects will be broken down
into sufficiently small tasks such that each task can be owned by an
individual. Further, all such tasks are subject to a rollup that will
be sufficiently concise that non-technical stakeholders will be able to
make sense of what they see and the team can, at a glance, see how the
project is progressing.
A fallout of this suggests that at least, there will be either an
internal or external tool to help breakdown a project into sufficiently
small tasks that there can be a single owner, assure that all the
requirements are covered by this task breakdown, all the task are
allocated (owned) by someone, all the tasks are being worked on, and
that all the tasks are being reported on.
With all the activities involved in the overall process, it would be
handy if there was some way to plan and keep track of these setup
activities and a method to help users assure that they address all the
steps in their planning and execution.
Having the right tools to do a job is great. Having them organized is .
. .
Olemis Lang
>> -----Original Message-----
>> From: trac-...@googlegroups.com [mailto:trac-...@googlegroups.com]
>> On Behalf Of Chris Nelson
>>
>> discussions I've had into
>> http://trac-hacks.org/wiki/ProjectManagementIdeas . Feedback welcome.
>
> The wiki is a great summary and platform for discussion. I see two
> items of interest:
> owner (who is working on it)
> reporter (who wrote the ticket)
>
But you mean that this info be included in the Gantt chart. The way I
see it (so far) is that this should be accomplished by filtering the
result set using the underlying infrastructure found in TracQueries +
reports.
>
> A fallout of this suggests that at least, there will be either an
> internal or external tool to help breakdown a project into sufficiently
> small tasks that there can be a single owner, assure that all the
> requirements are covered by this task breakdown, all the task are
> allocated (owned) by someone, all the tasks are being worked on, and
> that all the tasks are being reported on.
>
> With all the activities involved in the overall process, it would be
> handy if there was some way to plan and keep track of these setup
> activities and a method to help users assure that they address all the
> steps in their planning and execution.
>
I think this is cool, but it seems to me that this is beyond Gantt
charts ... isnt it ? The way I see it (so far) is that this should be
done apart of Gantt plugin, as well as many other features needed for
PM ... I dont see how this fits in Gantt charts dev effort ...
Chris Nelson
> On Mon, Apr 20, 2009 at 6:30 AM, Joseph, Ray <Ray.J...@cdicorp.com> wrote:
>>> From: trac-...@googlegroups.com
>>> [mailto:trac-...@googlegroups.com]
>>> On Behalf Of Chris Nelson
>>>
>>> I tried to boil down this thread, my thoughts, and some other
>>> discussions I've had into
>>> http://trac-hacks.org/wiki/ProjectManagementIdeas . Feedback
>>> welcome.
> I think this is cool, but it seems to me that this is beyond Gantt
> charts ... isnt it ? The way I see it (so far) is that this should be
> done apart of Gantt plugin, as well as many other features needed for
> PM ... I dont see how this fits in Gantt charts dev effort ...
Note the title of the wiki page I created: _Project_ _Management_ Ideas. While a Gantt chart is important, it's one of several modules necessary to make Trac better for project management.
Joseph, Ray
> From: trac-...@googlegroups.com [mailto:trac-...@googlegroups.com]
> On Behalf Of Olemis Lang
> Subject: [Trac] Re: Requirements for a new and improved Gantt plugin
> > A fallout of this suggests that at least, there will be either an
> > internal or external tool to help breakdown a project into
> sufficiently
> > small tasks that there can be a single owner, assure that all the
> > requirements are covered by this task breakdown, all the task are
> > allocated (owned) by someone, all the tasks are being worked on, and
> > that all the tasks are being reported on.
> >
> > With all the activities involved in the overall process, it would be
> > handy if there was some way to plan and keep track of these setup
> > activities and a method to help users assure that they address all
> the
> > steps in their planning and execution.
> >
>
> I think this is cool, but it seems to me that this is beyond Gantt
> charts ... isnt it ? The way I see it (so far) is that this should be
> done apart of Gantt plugin, as well as many other features needed for
> PM ... I dont see how this fits in Gantt charts dev effort ...
>
Olemis,
Yes, thank you for the clarification. That is, the intent here is just
Gantt chart, no other PM tools. The open challenge (from the previous
message) is a roll-up. Now that we have say 10 (50) team members and
each has 5 (20) tasks, the chart will have 50 (1000) entries. The Gantt
chart is useful from different viewpoints. A team member may want to
see the activities relative to herself or the lead may want to see
activities presented relative to dependencies. Can we sort the tasks
according to viewpoints and can we roll up tasks according to milestones
or functions?
Olemis Lang
agreed
> A team member may want to
> see the activities relative to herself or the lead may want to see
> activities presented relative to dependencies. Can we sort the tasks
> according to viewpoints and can we roll up tasks according to milestones
> or functions?
>
My Q here is : Can we do that today using Trac query + reports (let's
say rendered as a table ;) ? If we can, then the only thing needed is
to get the data from any ticket group providers, and let the user
write the specific query ... ;)
Olemis Lang
Hmmm ... you 'r right. However there are many other features, and that
page could be really heavy. Should another page containing comments
specific to Gantt charts be added ? I have the feeling that the page
could be more like an index page ... but I'm not sure though.
BTW IMHO the page should be restructured somehow. AYCS there is a lot
being said just for Gantt charts (and content spreads throughout the
whole page). There are many things needed for PM, so perhaps it'd be
cool to have a structure in the wiki page just to add ideas about
further subjects (especially if everything will be included in a
single page ;).
I mean, even if the name is PMIdeas, the content and structure is very
specific to Gantt charts ;)
In the mean time I have added a few more text right over there. Feel
free to revert my changes, move that text to any other wiki page, or
whatever ...
Chris Nelson
> On Mon, Apr 20, 2009 at 8:32 AM, Chris Nelson <Chr...@sixnetio.com>
> wrote:
>...
>> Note the title of the wiki page I created: _Project_ _Management_
>> Ideas. While a Gantt chart is important, it's one of several
>> modules necessary to make Trac better for project management.
>
> Hmmm ... you 'r right. However there are many other features, and
> that page could be really heavy. Should another page containing
> comments specific to Gantt charts be added ? I have the feeling that
> the page could be more like an index page ... but I'm not sure
> though.
I'm not sure where it'll end up but the goal of a Gantt chart seems (for now) to be a major enabler for better PM so I'm OK with them being a little intertwined.
> BTW IMHO the page should be restructured somehow. AYCS there is a lot
> being said just for Gantt charts (and content spreads throughout the
> whole page). There are many things needed for PM, so perhaps it'd be
> cool to have a structure in the wiki page just to add ideas about
> further subjects (especially if everything will be included in a
> single page ;).
>
> I mean, even if the name is PMIdeas, the content and structure is
> very specific to Gantt charts ;)
>
> In the mean time I have added a few more text right over there. Feel
> free to revert my changes, move that text to any other wiki page, or
> whatever ...
OK. I'm doing some editing today.
Yunior Armando Hernandez Andrade
about project planning that we had forgot: Tasks Time Limits.
Normally we set some estimated dates and numbers for tasks, like
estimated start date and estimated amount of time and then we manage
time from delays and such as we wish, giving more time to other tasks or
setting estimated end dates after. But, sometimes we also set time
limits for end and start. Let's say "this must be finished Jan, 10th";
that's a finish time limit that we for some reason, cannot break. The
same happens with start limits, for some reason (other tasks we don't
need to put in our planning maybe?) a task cannot start before an
specific date.
Time Limits can be:
* Start Limit: Task cannot start before a given date.
* End Limit: Task cannot end after a given date.
Chris Nelson
An End Limit is something like a milestone (a date by which work has to
be complete) but I realize it's not quite the same (certainly not the
same as a Trac milestone). The Start Limit is a new data item. These
may be extra data needed for full PM functionality that gets deferred --
like FF dependencies -- in the interest of getting something done now
with a vision of a more complete solution later.
yoheeb
> > something
I just scanned it to. are we REALLY going to try to put all this into
trac? Sure hope you don't have to modify the core.
Just seems to me there are applications that already do all this, and
you just need a way to get Trac info into them. Not sure why you
don't go down the route of writing a plugin for MS Project, which
seems to the be the "tool of choice" by this efforts' sponsor, and a
plugin to pull any additional data needed to fill-in project details.
Might even only need some new custom fields, plus MasterTickets, and
TimingAndEstimation. it just doesn't need to be real time. you could
upload the project files, or exported images as often as your project
needs to some page on the trac site. (say, via xmlrpc, as part of the
project plugin)
Anyway, good luck. I hate project, so I don't really see the use in
this personally. Just saw what seemed to me as a missed opportunity
in the design approach.
Olemis Lang
>
>> > I was rereading theProjectManagementIdeaspage and remembered
>> > something
> I just scanned it to. are we REALLY going to try to put all this into
> trac? Sure hope you don't have to modify the core.
>
> Just seems to me there are applications that already do all this, and
> you just need a way to get Trac info into them. Not sure why you
> don't go down the route of writing a plugin for MS Project,
Basically because I dont wnat to pay licences for MS Project,
especially since I cannot know what it's doing or even modify it the
way I want, or ... is it open source already?
> which
> seems to the be the "tool of choice" by this efforts' sponsor, and a
> plugin to pull any additional data needed to fill-in project details.
> Might even only need some new custom fields, plus MasterTickets, and
> TimingAndEstimation. it just doesn't need to be real time. you could
> upload the project files, or exported images as often as your project
> needs to some page on the trac site. (say, via xmlrpc, as part of the
> project plugin)
>
> Anyway, good luck. I hate project, so I don't really see the use in
> this personally. Just saw what seemed to me as a missed opportunity
> in the design approach.
If using TracGViz plugin that info could be available in the form of a
data table, in different formats : CSV, JSON, HTML (... and if anybody
wants another -e.g. an std format for PM data ... is there something
like that ? - then a formatter could be added to get it done ;))
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Here comes the Sun ... turu ruru. It's Oracle's ! -
http://feedproxy.google.com/~r/simelo-es/~3/EMxV1KHhl60/here-comes-sun-turu-ruru-its-oracles.html
Olemis Lang
> On Thu, Apr 30, 2009 at 2:31 PM, yoheeb <yoh...@gmail.com> wrote:
>>
>>> > I was rereading theProjectManagementIdeaspage and remembered
>>> > something
>> I just scanned it to. are we REALLY going to try to put all this into
>> trac? Sure hope you don't have to modify the core.
>>
>> Just seems to me there are applications that already do all this, and
>> you just need a way to get Trac info into them. Not sure why you
>> don't go down the route of writing a plugin for MS Project,
>
> Basically because I dont wnat to pay licences for MS Project,
> especially since I cannot know what it's doing or even modify it the
> way I want, or ... is it open source already?
>
>> which
>> seems to the be the "tool of choice" by this efforts' sponsor, and a
>> plugin to pull any additional data needed to fill-in project details.
>> Might even only need some new custom fields, plus MasterTickets, and
>> TimingAndEstimation. it just doesn't need to be real time. you could
>> upload the project files, or exported images as often as your project
>> needs to some page on the trac site. (say, via xmlrpc, as part of the
>> project plugin)
>>
>> Anyway, good luck. I hate project, so I don't really see the use in
>> this personally. Just saw what seemed to me as a missed opportunity
>> in the design approach.
>
> If using TracGViz plugin that info could be available
I mean, data availabilty for third party systems should be a
requirement since the very beginning, and that would allow what you
are mentioning above ;)
Didnt I include that in the wiki ? Pls, feel free to add it ;o)
yoheeb
> > especially since I cannot know what it's doing or even modify it the
> > way I want, or ... is it open source already?
> requirement since the very beginning, and that would allow what you
> are mentioning above ;)
>
> Didnt I include that in the wiki ? Pls, feel free to add it ;o)
>
system, and custom plugins and things like TracGViz or whatever, it
already IS available, and has been. (not to mentioun good 'ole http)
That said:
>>"Basically because I dont wnat to pay licences for MS Project,"
Trac is a bad idea, I don't want to poo-poo the endeavor, just seems
like there are MANY project management tools out there that could be
leveraged and it is a TON of work. So you don't like/want project,
how about TaskJuggler, OpenWorkbench, dotProject or.....the list goes
on, those are just 3 that are open source. I would guess there are
dozens more, and possibly some other proprietary ones worth the look.
thought it might be worth considering. For us, projects consist of
way more than just the code, so pm tools need to cover many other
things that don't readily fit in trac so the "import the software
specific crap into your other big unweildy tool" model is nice due to
the decoupling.
anyway, again, good luck, if my observations are irrelevant, please
feel free to label me a heretic and ignore them :D
Olemis Lang
>
>> > Basically because I dont wnat to pay licences for MS Project,
>> > especially since I cannot know what it's doing or even modify it the
>> > way I want, or ... is it open source already?
>> I mean, data availabilty for third party systems should be a
>> requirement since the very beginning, and that would allow what you
>> are mentioning above ;)
>>
>> Didnt I include that in the wiki ? Pls, feel free to add it ;o)
>>
> Um, not sure what you mean, but between rss, xmlrpc, the report
> system, and custom plugins and things like TracGViz or whatever, it
> already IS available, and has been. (not to mentioun good 'ole http)
>
What I mean is that if data needs to be available so that an external
system can do whatever with it ... That's fine ... Being either «rss,
xmlrpc, the report system, and custom plugins and things like TracGViz
or whatever, ». Nonetheless, I am not sure about whether a PMS accept
RSS so as to get the data needed to render a Gantt chart. Therefore if
there is a std format to exchange that data, that's cool, and that
should be included in the plugin (the only formats that come to my
mind know so far are GViz protocol & something like the one used for
calendars, but they are as specific as I'd like to ;).
> That said:
>>>"Basically because I dont wnat to pay licences for MS Project,"
>
> is a bad reason to jam it into trac. I am not saying putting it into
> Trac is a bad idea, I don't want to poo-poo the endeavor, just seems
> like there are MANY project management tools out there that could be
> leveraged and it is a TON of work.
Oh yes ! good point ! ...
> So you don't like/want project,
> how about TaskJuggler, OpenWorkbench, dotProject or.....the list goes
> on, those are just 3 that are open source.
... that's why I already tried the latest (dotProject) & Redmine ;o)
> I would guess there are
> dozens more,
>
You 'r right. If we can reuse something. Let's be it ! Does any of
those includes a JavaScript | Flash-based widget so that you can
supply the data? Yes? Can we use it ?
+1 for reusing all that ;o)
> and possibly some other proprietary ones worth the look.
not interested, for evident reasons ;o)
> thought it might be worth considering. For us, projects consist of
> way more than just the code, so pm tools need to cover many other
> things that don't readily fit in trac so the "import the software
> specific crap into your other big unweildy tool" model is nice due to
> the decoupling.
>
What about my enterprise having trac and other Trac-based web apps,
wishing to have Gantts and Pert charts plus others?
> anyway, again, good luck, if my observations are irrelevant, please
> feel free to label me a heretic and ignore them :D
Nooo they 'r just cool :
Where were you when we were burned and broken ?
While the days slipped by from our wiki writing
;o)
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Microsoft Magic bugs : ¿Por qué utilizar software libre? -
http://feedproxy.google.com/~r/simelo-es/~3/cXNYovsJJ5s/microsoft-magic-bugs-por-que-utilizar.html