Changes between Version 6 and Version 7 of ProjectManagementIdeas
- Timestamp:
- Apr 20, 2009, 2:29:25 PM (15 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
ProjectManagementIdeas
v6 v7 15 15 [http://willbarton.com/code/tracgantt/ TracGantt]:: has potential but has some funky fields (e.g., Due to Assign) that don't seem to be appropriate to what we want to do with a Gantt chart. 16 16 17 There is a [http://www.viewpath.net/Website/ganttcharts/googlegadget.aspx Google Gadget Gantt chart] which might be leveraged for the visualizations once the data is made available . The chart is developped and maintained by a company (i.e. [http://www.viewpath.net/ ViewPath]). Besides users need access to the internet and their projects environments '''have to''' be available too so that the iGoogle container be able to retrieve the data to display in the chart. All this means that local deployments (intranets, ...) are not possible.17 There is a [http://www.viewpath.net/Website/ganttcharts/googlegadget.aspx Google Gadget Gantt chart] which might be leveraged for the visualizations once the data is made available (e.g. using [https://opensvn.csie.org/traccgi/swlcu/wiki/En/Devel/TracGViz/ TracGViz plugin]). That widget is developped and maintained by a company (i.e. [http://www.viewpath.net/ ViewPath]). Besides users need access to the internet and their projects environments '''have to''' be available too so that the iGoogle container be able to retrieve the data to display in the chart. All this means that local deployments (intranets, ...) are not possible. 18 18 19 19 = Requirements = … … 43 43 * type (bug, task, enhancement, etc.) 44 44 * time (when the ticket was created) 45 45 46 * owner (who is working on it) 47 48 {{{ 49 owner is duplicated. Is it core or additional field ? 50 }}} 51 46 52 * reporter (who wrote the ticket) 47 53 * milestone (what milestone this ticket is part of) … … 76 82 While Gantt charts typically show percent complete, this can be computed from hours remaining vs. total estimate or hours worked vs. total estimate. We will not, necessarily, store percent complete. It is intuitive for display and analysis but difficult for data entry. 77 83 78 79 84 === Dependencies === 80 85 … … 101 106 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. 102 107 103 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. A "chart these" button on a report page would be very nice. 108 == What do we need in the backend ? == 109 110 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. 111 112 To effectively display project progress, tickets must have estimated and actual times as in the TimingAndEstimation plugin. 113 114 It is also desirable to have loop detection to error-proof the tool used to create dependencies. 115 116 It would be nice to be able to choose an As Late As Possible or As Soon As Possible algorithm for laying out tasks. 117 118 == What do we need in the user interface ? == 119 120 A "chart these" button on a report page would be very nice. 121 122 Tasks in the chart should be links to the tickets they represent (preferently opened in a separate tab | window). 123 124 Milestones should be displayed in the chart as well 104 125 105 126 The chart should support interactively "folding" groups of tasks to hide detail. 106 127 107 Tasks in the chart should be links to the tickets they represent. 108 109 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. 128 Zooming in order to see the WBS in more detail 129 130 Panning or scrolling in order to display the schedule at a 131 different time. 132 133 Each task's bar in the chart should show actual hours. 110 134 111 135 The chart should have a Today line 112 136 113 It is also desirable to have loop detection to error-proof the tool used to create dependencies.114 115 It would be nice to be able to choose an As Late As Possible or As Soon As Possible algorithm for laying out tasks.116 117 137 The chart (or an accompanying report or tool) should aid in resource leveling by (at least) showing overcommitted resources. 118 138 139 Visual indications about delays, task completion and other 140 significant events 141 142 Drag n' Drop so that users can change the order of the tickets (yes, I'm drunk ... hip .o: ) 143 119 144 = Related Work = 120 145 … … 124 149 125 150 TimingAndEstimationPlugin and TracHoursPlugin add estimated and actual hours fields to tickets. There is some disagreement about whether the estimate is the remaining time (so total estimated time is actual + estimate) or total time (so remaining time is estimate - actual). A Gantt chart typically wants estimate and percent complete. It is possible to extract this from either recording convention and we should likely allow either convention via a configurable interface. 151 152 = Design guidelines = 153 154 In order to agree about how to implement this functionality, the 155 very first step should be to describe the possible(s) architecture(s) 156 (i.e. how the different components are going to interact with each other 157 since the moment the request is sent by the client until the Gantt chart 158 is rendered by the browser) 159 that will be considered. 160 161 == Components == 162 163 In order to add flexibility to the final solution, the 164 '''MVC pattern''' ''should'' be considered during its development. 165 Hence the following components need to be implemented in order to add 166 Gantt charts to Trac. 167 168 === The Model === 169 170 It provides the data in the Gantt chart and is not just a 171 single element but a set of components like the following : 172 173 * The ticket models, which provide data about the issues found 174 in the project environment 175 * Trac query mechanism which provides a way to select (filter) the 176 tickets being shown. 177 * [#RelatedWork Other plugins] used to track ticket dependencies 178 * [#RelatedWork Other plugins] used to track task/subtask relationships 179 * [#RelatedWork Other plugins] used to estimate the time needed to finish the given tasks 180 * Maybe one (a few) component(s) whose role is to provide the 181 functionality specific to Gantt charts, thus acting as a central 182 access point and a mediator so as to put all the other 183 components together. 184 185 === The View === 186 187 It ''should'' be a JavaScript component (is this possible ?) 188 responsible for rendering the data provided by ''the model''. 189 Besides it ''might'' support [#What_do_we_need_in_the_user_interface__ other dynamic features] 190 191 === The Controller === 192 193 {{{ 194 ¿What do we need this for? 195 }}} 196 197 === Implications === 198 199 The aforementionned separation ''should'' allow the replacement of 200 any of the components involved. Hence the following modifications 201 ''should'' be made easily (the list being intentionally incomplete) : 202 203 - Replace the JS-based view by another made with Flash. 204 - Use a custom, or specific estimation strategy. 126 205 127 206 = Roadmap =