Changes between Version 31 and Version 32 of AnalyzePlugin
- Timestamp:
- Apr 9, 2012, 1:43:53 AM (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
AnalyzePlugin
v31 v32 9 9 1. '''Milestone Dependency Analysis''' - ensures dependent tickets are in current or prior milestones 10 10 1. '''Queue Dependency Analysis''' - ensures dependent ''peer'' tickets in a queue are ordered correctly 11 1. '''Project Dependency Analysis''' - ensures dependent ''child'' tickets in a queue are ordered correctly 12 13 These analyses all build off of the [wiki:MasterTicketsPlugin master tickets plugin]. The second and third also build off of the [wiki:QueuesPlugin queues plugin]. (Be sure to use the latest version of the queues plugin so that the included jquery-ui versions match to avoid conflicts!) See below for examples. 11 1. '''Project Queue Analysis''' - ensures dependent ''child'' tickets of parent tickets in a queue follow the parents' ordering 12 1. '''Project Rollup Analysis''' - summarizes (or rolls up) the child tickets' fields in the parent ticket 13 14 All of the analyses above build upon the [wiki:MasterTicketsPlugin master tickets plugin]. The second and third analyses also build off of the [wiki:QueuesPlugin queues plugin]. (Be sure to use the latest version of the queues plugin so that the included jquery-ui versions match to avoid conflicts!) See below for examples. 14 15 15 16 [[Image(ask_analyze.png)]] … … 56 57 == Example == 57 58 58 This plugin currently includes threeanalyses that can each be individually enabled for one or more reports. Each analysis is configured by modifying the {{{[analyze]}}} section of {{{trac.ini}}} - see below for examples. When an analysis is enabled for a report, an '''Analyze...''' button appears at the top of the report and the analysis' name will appear in the subsequent dialog box when the button is clicked. You can either choose a single analysis or all analyses in this dialog box. Selecting "All" will run them serially.59 This plugin currently includes four analyses that can each be individually enabled for one or more reports. Each analysis is configured by modifying the {{{[analyze]}}} section of {{{trac.ini}}} - see below for examples. When an analysis is enabled for a report, an '''Analyze...''' button appears at the top of the report and the analysis' name will appear in the subsequent dialog box when the button is clicked. You can either choose a single analysis or all analyses in this dialog box. Selecting "All" will run them serially. 59 60 60 61 '''Important:''' The current analyses are powerful and yet are limited. They do not, for example, detect circular dependencies nor can they handle complex relationships all in one pass. What this means is that after a pass of fixes, the changes may have caused or exposed other issues that another analysis pass will uncover. So the general usage pattern is to continue re-running analyses until "quiescence" is reached - i.e., until there are no more issues to fix. … … 106 107 Detected problems are shown with an option to automatically fix the problem by moving tickets above or below each other in the queue - see screenshot above. 107 108 108 ==== Project DependencyAnalysis ====109 This analysis is for ''project'' queues (instead of work queues) meaning that the dependency semantics is parent-child. For example, you may have a report of project (or "epic" in agile-speak) tickets whose sub-tasks are represented in their {{{blockedby}}} dependencies. Re-prioritizing a project/epic/parent ticket does not automatically re-order their child tickets, respectively. That's where this Project DependencyAnalysis comes in.109 ==== Project Queue Analysis ==== 110 This analysis is for ''project'' queues (instead of work queues) meaning that the dependency semantics is parent-child. For example, you may have a report of project (or "epic" in agile-speak) tickets whose sub-tasks are represented in their {{{blockedby}}} dependencies. Re-prioritizing a project/epic/parent ticket does not automatically re-order their child tickets, respectively. That's where this Project Queue Analysis comes in. 110 111 111 112 [[Image(issue-project.png)]] … … 122 123 The {{{project_type}}} option above is the ticket type of your projects (e.g., "epic" (the default), "project", etc.). Project tickets must be of this type. 123 124 124 The default behavior of an analysis is to refresh the current report if any fixes were made. This is so that changes can be viewed (assuming they would change the content of the report). In the case of Project DependencyAnalysis, you would usually also need another report refreshed - i.e., the impacted work queue. Use the {{{refresh_report}}} option to specify this impacted work queue which will also get refreshed at the end of this analysis if there were any fixes. You can add params to the report as well if needed:125 The default behavior of an analysis is to refresh the current report if any fixes were made. This is so that changes can be viewed (assuming they would change the content of the report). In the case of the Project Queue Analysis, you would usually also need another report refreshed - i.e., the impacted work queue. Use the {{{refresh_report}}} option to specify this impacted work queue which will also get refreshed at the end of this analysis if there were any fixes. You can add params to the report as well if needed: 125 126 {{{ 126 127 [analyze] … … 131 132 132 133 Detected problems are shown with an option to automatically fix the problem by moving the sub-task/child tickets above or below each other in their queue (to match their parent's relative positions) - see screenshot above. 134 135 ==== Project Rollup Analysis ==== 136 This analysis summarizes a project by "rolling up" its child tickets using one of several statistical methods. For example, you may have a report of project (or "epic" in agile-speak) tickets whose sub-tasks are represented in their {{{blockedby}}} dependencies. You would like the project tickets' fields to represent a summary (or roll up) of the child tickets. That's where this Project Rollup Analysis comes in. 137 138 [[Image(rollup-project.png)]] 139 140 This analysis will enforce that the child tickets (usually found in a separate work queue report) are ordered relative to one another in the same general order as the parent/project tickets. To enable this analysis for a given report, list those reports in {{{trac.ini}}} as follows: 141 {{{ 142 [analyze] 143 rollup_reports = 1,2,3,9 144 }}} 145 146 In the example above, this analysis is available for reports 1, 2, 3, and 9. If no {{{rollup_reports}}} is provided, then the project_reports list is used instead. 147 148 The available rollup stats are: 149 * sum 150 * min 151 * max 152 * median 153 * mode 154 * pivot 155 156 All but {{{pivot}}} apply to numeric fields, and all but {{{sum}}} apply to select option fields. Here are several examples of specifying a stat for different fields: 157 {{{ 158 [analyze] 159 rollup.effort = sum 160 rollup.severity = min 161 rollup.captain = mode 162 rollup.phase = implementation 163 }}} 164 165 In the example above, the project's 166 167 * effort field sums all of its children numeric values 168 * severity field gets set to the minimum (index) value of its children 169 * captain field gets set to the most frequent captain of its children 170 * phase pivots on the 'implementation' select option value 171 172 In brief, the pivot algorithm is as follows (using the option's index): 173 174 * if all values are < the pivot value, then select their max value 175 * else if all are > the pivot value, then select their min value 176 * else select the pivot value 177 178 Detected changes to rollup field values are shown with an option to automatically update the value - see screenshot above. 133 179 134 180 == Tips! ==