| 72 | | In its most basic form, a Gantt chart shows: |
| 73 | | |
| 74 | | Tasks:: Self-contained units of work |
| 75 | | |
| 76 | | Dependencies:: Relationships between tasks that constrain when they can be done |
| 77 | | |
| 78 | | Milestones:: Dates by which one or more tasks must be completed |
| 79 | | |
| 80 | | It may also show resource assignments and progress in tasks. It often includes a "today" line to show where a project stands. (If the project is on schedule, all tasks to the left of ''today'' are complete and any task that spans ''today'' has a progress bar to the right of ''today''.) |
| 81 | | |
| 82 | | A Gantt chart may also show slack time for tasks, how much they can slip before affecting the overall schedule. It often also highlights the ''critical path'', the set of tasks which determine the overall length of the project and which delay the project completion unit-for-unit as they are delayed or extended. |
| 83 | | |
| 84 | | == Component Data == |
| 85 | | |
| 86 | | Each Gantt chart component or feature requires data to support it. For Trac-based project management, this data is often in addition to the core ticket data. |
| 87 | | |
| 88 | | In general, we might expect to have multiple resources assigned to a task but if we use a Trac ticket as the basis for a task, we have only a single resource, the ticket owner. |
| 89 | | |
| 90 | | === Core Fields === |
| 91 | | |
| 92 | | Core ticket fields include relevant to project management include: |
| 93 | | |
| 94 | | * owner (who is working on it) |
| 95 | | * milestone (what milestone this ticket is part of) |
| 96 | | * status (new, assigned, ..., closed) |
| 97 | | * summary (short description) |
| 98 | | |
| 99 | | Core milestone fields relevant to project management include: |
| 100 | | |
| 101 | | * name |
| 102 | | * due (date and time) |
| 103 | | * completed (treated as a Boolean: open or closed) |
| 104 | | |
| 105 | | === Additional Data === |
| 106 | | |
| 107 | | For project management, we must have the following additional information about a task/ticket: |
| 108 | | |
| 109 | | * estimate (expected work required to complete task) |
| 110 | | * percent complete |
| 111 | | * dependencies |
| 112 | | * percent effort |
| 113 | | |
| 114 | | '''NOTE:''' While Gantt charts typically show percent complete, this can be computed from time remaining vs. total estimate or time worked vs. total estimate. We will not, necessarily, store percent complete. It is intuitive for display and analysis but difficult for data entry. |
| | 73 | It often includes a "today" line to show where a project stands. (Need an example.) |
| | 74 | |
| | 75 | A Gantt chart may also show slack time for tasks, how much they can slip before affecting the overall schedule. (Need an example.) |
| 158 | | = Roadmap = |
| 159 | | |
| 160 | | There seems to be a consensus that grandiose project management features for Trac should be implemented with a combination of plugins which provide useful functionality on their own. The following plan assumes that approach. |
| 161 | | |
| 162 | | == Dependency and Duration == |
| 163 | | |
| 164 | | There is some benefit to very basic Gantt that showed just tasks and their dependencies and the resultant schedule. |
| 165 | | |
| 166 | | [[Image(simple-gantt.PNG)]] |
| 167 | | |
| 168 | | Disregarding any resource constraints, this chart shows |
| 169 | | |
| 170 | | * circuit board design and firmware development follow schematic design |
| 171 | | * package design can proceed independently |
| 172 | | * assembly can't be done until the circuit boards and packaging are ready |
| 173 | | * the product can't ship until it's assembled and has firmware. |
| 174 | | * the overall project will take 9 calendar days |
| 175 | | |
| 176 | | (Clearly this is a gross simplification and likely not accurate in many ways.) |
| 177 | | |
| 178 | | This requires only that the ticket have some information about estimated effort or duration of the task and simple FS task dependency. |
| 179 | | |
| 180 | | == Progress == |
| 181 | | |
| 182 | | If we also track work on tasks, we can monitor project progress at a glance. |
| 183 | | |
| 184 | | [[Image(gantt-progress.PNG)]] |
| 185 | | |
| 186 | | == Resource Allocation == |
| 187 | | |
| 188 | | When a resource is not available 100% of the time, tasks take longer than the work suggests. By assigning effort to resources, we can chart this time dialation. |
| 189 | | |
| 190 | | [[Image(gantt-resource.PNG)]] |
| 191 | | |
| 192 | | When the hardware and software engineers are only available half time, the project gets delayed. |
| 193 | | |
| 194 | | == Critical Path == |
| 195 | | |
| 196 | | Some tasks affect project schedule and some do not. The tasks which affect the schedule are on the ''critical path''. |
| 197 | | |
| 198 | | [[Image(critical-path.PNG)]] |
| 199 | | |
| 200 | | Packaging design and circuit board layout are so short -- relative to other activities -- they speeding them up doesn't really help the project. But if we could shorten schematic design or firmware, every day we take out of one of those activities we also take out of the project schedule. |
| 201 | | |
| 202 | | == Sub-tasks == |
| 203 | | |
| 204 | | To manage the complexity of the chart, we can break tasks down into sub-tasks and show various levels of detail. |
| 205 | | |
| 206 | | [[Image(roll-up-1.PNG)]] |
| 207 | | |
| 208 | | [[Image(roll-up-2.PNG)]] |
| 209 | | |
| 210 | | |
| 211 | | = Development Plan = |
| 212 | | |
| 213 | | 1. Fork !MasterTickets as !TicketDep (or something) and add ''composed of''/''part of'' dependencies and [http://trac.edgewall.org/wiki/SubTickets#CreatingSubtickets means to create them]. Plan for but do not yet implement ''starts with'' and ''ends with'' dependencies. |
| 214 | | 1. Specify the interfaces necessary for a scheduling plugin to use dependencies, estimates, and time worked to determine project schedule. |
| 215 | | * Consider adding a percentage available when scheduling resources. |
| 216 | | 1. Specify the interfaces necessary for a Gantt chart to get data from tickets. |
| 217 | | * Each task must have a name, duration, percent complete, and start or end. (The start or end comes from schedule calculations, not direct ticket data.) |
| 218 | | * Access to dependencies between tickets is also needed so as to render the chart. |
| 219 | | 1. Implement those interfaces on top of TimingAndEstimationPlugin. |
| 220 | | |
| 221 | | = Disclaimer = |
| 222 | | |
| 223 | | The bulk of this page was prepared by Chris Nelson who makes no claim to be certified project planner or anything of the sort. It is based on his understanding of project management after 25 years of software development. [#Contributors Other developers] have also offered some hints and useful comments (according to their experience) in order to enhance this page, and get a better understanding of the features and requirements needed. |
| 224 | | |
| 225 | | == Contributors == |
| 226 | | |
| 227 | | - Olemis Lang |
| 228 | | |
| 229 | | = Appendix : Microsoft Project Task Properties = |
| | 120 | == Microsoft Project Task Properties == |
| | 155 | |
| | 156 | = Roadmap = |
| | 157 | |
| | 158 | There seems to be a consensus that grandiose project management features for Trac should be implemented with a combination of plugins which provide useful functionality on their own. The following plan assumes that approach. |
| | 159 | |
| | 160 | == Dependency and Duration == |
| | 161 | |
| | 162 | There is some benefit to very basic Gantt that showed just tasks and their dependencies and the resultant schedule. |
| | 163 | |
| | 164 | [[Image(simple-gantt.PNG)]] |
| | 165 | |
| | 166 | Disregarding any resource constraints, this chart shows |
| | 167 | |
| | 168 | * circuit board design and firmware development follow schematic design |
| | 169 | * package design can proceed independently |
| | 170 | * assembly can't be done until the circuit boards and packaging are ready |
| | 171 | * the product can't ship until it's assembled and has firmware. |
| | 172 | * the overall project will take 9 calendar days |
| | 173 | |
| | 174 | (Clearly this is a gross simplification and likely not accurate in many ways.) |
| | 175 | |
| | 176 | This requires only that the ticket have some information about estimated effort or duration of the task and simple FS task dependency. |
| | 177 | |
| | 178 | == Progress == |
| | 179 | |
| | 180 | If we also track work on tasks, we can monitor project progress at a glance. |
| | 181 | |
| | 182 | [[Image(gantt-progress.PNG)]] |
| | 183 | |
| | 184 | == Resource Allocation == |
| | 185 | |
| | 186 | When a resource is not available 100% of the time, tasks take longer than the work suggests. By assigning effort to resources, we can chart this time dialation. |
| | 187 | |
| | 188 | [[Image(gantt-resource.PNG)]] |
| | 189 | |
| | 190 | When the hardware and software engineers are only available half time, the project gets delayed. |
| | 191 | |
| | 192 | == Critical Path == |
| | 193 | |
| | 194 | Some tasks affect project schedule and some do not. The tasks which affect the schedule are on the ''critical path''. |
| | 195 | |
| | 196 | [[Image(critical-path.PNG)]] |
| | 197 | |
| | 198 | Packaging design and circuit board layout are so short -- relative to other activities -- they speeding them up doesn't really help the project. But if we could shorten schematic design or firmware, every day we take out of one of those activities we also take out of the project schedule. |
| | 199 | |
| | 200 | == Sub-tasks == |
| | 201 | |
| | 202 | To manage the complexity of the chart, we can break tasks down into sub-tasks and show various levels of detail. |
| | 203 | |
| | 204 | [[Image(roll-up-1.PNG)]] |
| | 205 | |
| | 206 | [[Image(roll-up-2.PNG)]] |
| | 207 | |
| | 208 | |
| | 209 | = Development Plan = |
| | 210 | |
| | 211 | 1. Fork !MasterTickets as !TicketDep (or something) and add ''composed of''/''part of'' dependencies and [http://trac.edgewall.org/wiki/SubTickets#CreatingSubtickets means to create them]. Plan for but do not yet implement ''starts with'' and ''ends with'' dependencies. |
| | 212 | 1. Specify the interfaces necessary for a scheduling plugin to use dependencies, estimates, and time worked to determine project schedule. |
| | 213 | * Consider adding a percentage available when scheduling resources. |
| | 214 | 1. Specify the interfaces necessary for a Gantt chart to get data from tickets. |
| | 215 | * Each task must have a name, duration, percent complete, and start or end. (The start or end comes from schedule calculations, not direct ticket data.) |
| | 216 | * Access to dependencies between tickets is also needed so as to render the chart. |
| | 217 | 1. Implement those interfaces on top of TimingAndEstimationPlugin. |
| | 218 | |
| | 219 | = Disclaimer = |
| | 220 | |
| | 221 | The bulk of this page was prepared by Chris Nelson who makes no claim to be certified project planner or anything of the sort. It is based on his understanding of project management after 25 years of software development. [#Contributors Other developers] have also offered some hints and useful comments (according to their experience) in order to enhance this page, and get a better understanding of the features and requirements needed. |
| | 222 | |
| | 223 | == Contributors == |
| | 224 | |
| | 225 | - Olemis Lang |
| | 226 | |
| | 232 | == Component Data == |
| | 233 | |
| | 234 | Each Gantt chart component or feature requires data to support it. For Trac-based project management, this data is often in addition to the core ticket data. |
| | 235 | |
| | 236 | In general, we might expect to have multiple resources assigned to a task but if we use a Trac ticket as the basis for a task, we have only a single resource, the ticket owner. |
| | 237 | |
| | 238 | === Core Fields === |
| | 239 | |
| | 240 | Core ticket fields include relevant to project management include: |
| | 241 | |
| | 242 | * owner (who is working on it) |
| | 243 | * milestone (what milestone this ticket is part of) |
| | 244 | * status (new, assigned, ..., closed) |
| | 245 | * summary (short description) |
| | 246 | |
| | 247 | Core milestone fields relevant to project management include: |
| | 248 | |
| | 249 | * name |
| | 250 | * due (date and time) |
| | 251 | * completed (treated as a Boolean: open or closed) |
| | 252 | |
| | 253 | === Additional Data === |
| | 254 | |
| | 255 | For project management, we must have the following additional information about a task/ticket: |
| | 256 | |
| | 257 | * estimate (expected work required to complete task) |
| | 258 | * percent complete |
| | 259 | * dependencies |
| | 260 | * percent effort |
| | 261 | |
| | 262 | '''NOTE:''' While Gantt charts typically show percent complete, this can be computed from time remaining vs. total estimate or time worked vs. total estimate. We will not, necessarily, store percent complete. It is intuitive for display and analysis but difficult for data entry. |
| | 263 | |
| | 264 | |
