Changes between Version 7 and Version 8 of TimeEstimationAndQuotingSpecification
- Timestamp:
- Jan 18, 2016, 5:15:25 PM (8 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
TimeEstimationAndQuotingSpecification
v7 v8 1 = #369 Time Tracking, Estimation, and Quoting Specification 1 [[PageOutline(2-5,Contents,pullout)]] 2 3 = Time Tracking, Estimation, and Quoting Specification (#369) 2 4 3 5 == Requirements and Rationale … … 5 7 1. We wish to be able to note on a ticket the amount of time a developer spent on it. This should be a list rather than a single box with total hours, because many developers may work on this ticket many times before the ticket is complete. Currently we plan to add this to comments on a ticket. Possibly as a separate table that references comments. 6 8 1. A ticket should show a summary of the time spent per developer and in total. 7 1. A ticket should have an estimated time field attached, probably just a custom field specified in `trac.ini`. 9 1. A ticket should have an estimated time field attached, probably just a custom field specified in `trac.ini`. 8 10 1. Tickets should also provide a rate or fixed cost bounty field so that there is a corresponding price for the estimated time. 9 11 1. We wish to be able to query per ticket / component / milestone / project (Trac instance) how much time has been spent per developer and in total. We should also be able to query this for different time periods: how much time this month did we spend on ticket 1, etc. 10 12 1. We should be able to query the amount over/under our estimation we were per per ticket / component / milestone / project (Trac instance). 11 13 1. A permissions set that is associated with viewing and adding/editing these fields. 12 1. Integrate into webadmin to allow setting permissions on all of the newly added fields. This will be the most user friendly way of editing permissions and shouldn t be too much work in total.14 1. Integrate into webadmin to allow setting permissions on all of the newly added fields. This will be the most user friendly way of editing permissions and shouldn't be too much work in total. 13 15 14 16 == Specification … … 16 18 === Time Tracking 17 19 18 To track how much time each developer is spending on a ticket, there should be some easy, query able way to add time spent to a ticket. My first thought on this is to add two fields next to the comment that are time spent (in hours) and whether or not this is billable time (a checkbox). Then the developer (name) associated with that comment is also associated with the time. When a comment is added it should also add that time to the time log and update the total time spent for this ticket (which should probably be displayed in ticket properties as three fields, billable nonbillable, total) or a new time management section. When displaying comments, where it currently displays "date time changed by user" we should append a time spent.20 To track how much time each developer is spending on a ticket, there should be some easy, query-able way to add time spent to a ticket. My first thought on this is to add two fields next to the comment that are time spent (in hours) and whether or not this is billable time (a checkbox). Then the developer (name) associated with that comment is also associated with the time. When a comment is added it should also add that time to the time log and update the total time spent for this ticket (which should probably be displayed in ticket properties as three fields: billable, non-billable, total) or a new time management section. When displaying comments, where it currently displays "date time changed by user" we should append a time spent. 19 21 20 22 If there is an error in a reported time, the plugin should allow the user to enter a second comment with a negative time. This will allow us to have a record of both the positive allotment of time as well as the redaction of that time. … … 22 24 === Time Estimation and Price Quoting Facilities 23 25 24 We wish to be able to offer bounties / quote prices on a ticket. In addition to this [ http://en.wikipedia.org/wiki/Estimation_in_software_engineering time estimation] has proven to be a difficult problem for software developers. The most commonly expressed way of becoming good at it, is to systematically record your estimations, compare that with actual output and adjust your estimations accordingly. To this end, every ticket should have an estimated time on it. The price / bounty should be expressable in either amount per hour or total cost.26 We wish to be able to offer bounties / quote prices on a ticket. In addition to this [wikipedia:Estimation_in_software_engineering time estimation] has proven to be a difficult problem for software developers. The most commonly expressed way of becoming good at it, is to systematically record your estimations, compare that with actual output and adjust your estimations accordingly. To this end, every ticket should have an estimated time on it. The price / bounty should be expressible in either amount per hour or total cost. 25 27 26 28 === Querying Time Information 27 29 28 There needs to be a way to query all of the time data that we will be adding to the database. We want this to be limitable based on time of entry, developer,billable/not billable. We also want the capability to compare the total amount of hours spent to total estimated.30 There needs to be a way to query all of the time data that we will be adding to the database. We want this to be by time of entry, by developer, and billable/not billable. We also want the capability to compare the total amount of hours spent to total estimated. 29 31 30 32 === Permissions … … 37 39 1. ESTIMATE_EDIT 38 40 39 I would like this to mirror the trac built in permissions structure as much as possible.41 I would like this to mirror the Trac built in permissions structure as much as possible. 40 42 41 43 === Possible Features (a place to hold feature creep)
