Changes between Version 6 and Version 7 of TimeEstimationAndQuotingSpecification


Ignore:
Timestamp:
Sep 18, 2015, 2:27:03 PM (9 years ago)
Author:
figaro
Comment:

Cosmetic changes, tagged as project

Legend:

Unmodified
Added
Removed
Modified
  • TimeEstimationAndQuotingSpecification

    v6 v7  
    1 = #369 Time Tracking, Estimation, and Quoting Specification =
     1= #369 Time Tracking, Estimation, and Quoting Specification
    22
    3 == Requirements and Rationale ==
    4  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)
    5  1. a ticket should show a summary of the time spent per developer and in total
    6  1. a ticket should have an estimated time field attached (probably just a custom field specified in trac.ini). 
     3== Requirements and Rationale
     4
     5 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 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`. 
    78 1. Tickets should also provide a rate or fixed cost bounty field so that there is a corresponding price for the estimated time.
    8  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)
    9  1. we should be able to query the amount over/under our estimation we were per per ticket / component / milestone / project (trac instance)
    10  1. A permissions set that is associated with viewing and  adding/editing these fields
    11  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 shouldnt be too much work in total.
     9 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 1. We should be able to query the amount over/under our estimation we were per per ticket / component / milestone / project (Trac instance).
     11 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 shouldnt be too much work in total.
    1213
    13 == Specification ==
     14== Specification
    1415
    15 === Time Tracking ===
    16 In order to track how much time each developer is spending on a ticket, there should be some easy, queryable 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. 
     16=== Time Tracking
    1717
    18 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.
     18To track how much time each developer is spending on a ticket, there should be some easy, queryable 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. 
    1919
    20 === Time Estimation and Price Quoting Facilities ===
    21 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.  Toward 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.
     20If 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.
    2221
    23 === Querying Time Information ===
    24 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.
     22=== Time Estimation and Price Quoting Facilities
    2523
    26 === Permissions ===
    27 There should be a permission structure in place to (dis)allow viewing and editing of the various bits of data we are adding.  I would like this to mirror the trac built in permissions structure as much as possible. 
     24We 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.
     25
     26=== Querying Time Information
     27
     28There 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.
     29
     30=== Permissions
     31
     32There should be a permission structure in place to (dis)allow viewing and editing of the various bits of data we are adding:
    2833 1. TIME_VIEW
    2934 1. TIME_EDIT
     
    3237 1. ESTIMATE_EDIT
    3338
    34 === Future Feature Possibilities (A place to hold feature creep) ===
    35  1. It would also be nice to be able to have graphs of some of the various data bits.  This could be provided through an svg/javascript graphing package.
     39I would like this to mirror the trac built in permissions structure as much as possible.
     40
     41=== Possible Features (a place to hold feature creep)
     42
     43 1. It would also be nice to be able to have graphs of some of the various data bits. This could be provided through an svg/javascript graphing package.