StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Well, it depends. You didn't specify how big project, how many programmers will work, how often do you plan to deliver.</p> <p>Stating that, here's how we use Trac on one big project spanning several years that consists of number of smaller subprojects. </p> <ul> <li><p><strong>Milestones</strong> are defined as points where we have some features in subproject ready for delivery. First milestone in each subproject is usually the longest. We usually name milestones as "Subproject Name v0.01". Versions are just increments 0.01, 0.02, ... When we implement everything expected for subproject we mark last milestone as v1.00. Subsequent bug fixes go to milestone that we mark "Subproject Name - v1.00 - bugfix" </p></li> <li><p>Milestone description contains only list of new features or bug fixes. Documentation is written in wiki and in tickets.</p></li> <li><p><strong>Trac Wiki</strong> usually have at least one page about new features that will be implemented in specific milestone. It is usually higher level description of expected behavior of application. Often, there are examples of expected results application should produce.</p></li> <li><p><strong>Tickets</strong> contain detailed description of feature or bug that have to be implemented. </p> <ul> <li>Bug reporting tickets contain description of bug and steps to reproduce (almost always).</li> <li>Feature tickets contain detailed description of feature that must be implemented. One ticket contains <strong>work for up to 6 hours</strong>. When we plan work, we divide features to be in range from 1 - 6 hours of work. If we estimate that feature needs more time, than we split it in several tickets so each of them can fit in 1-6 hours of work. We picked 6 hours because we feel it is the top that we can estimate with error not bigger than 30% (meaning that this 6 hours estimate almost always can be done in range between 4-8 hours). Of course, there are exceptions from this stats. In our experience, main reason for wrong estimates is in bad specifications that we wrote. That, almost always, happens because we (developers) misunderstood business requirements of our users. </li> </ul></li> <li><p>There are few Trac plugins for estimating and time tracking. Check this page: <a href="http://trac.edgewall.org/wiki/TimeTracking" rel="nofollow noreferrer">http://trac.edgewall.org/wiki/TimeTracking</a> . We use <a href="http://trac-hacks.org/wiki/TimingAndEstimationPlugin" rel="nofollow noreferrer">Timing And Estimation Plugin</a> . You can enter estimated time for ticket and time spent working on ticket. Then you can get reports how much time you spent on tickets/milestones and how much time you need to finish. </p></li> </ul> <p>After two years, we can pretty accurately estimate time needed to do some work. When we correctly understand users needs and requirements, we usually can deliver in promised timeframe. Currently, our stats show that we overestimate time needed for tickets for about 10%. </p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload