> On Behalf Of jevans > Sent: Friday, April 10, 2009 11:46 PM > To: Trac Users > Subject: [Trac] Re: Requirements for a new and improved Gantt plugin > > >> 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. > > 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. > - jevans
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. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~----------~----~----~----~------~----~------~--~---
