Managing Milestones and Web development Project

Question

Hello,

I am trying to implement Trac+SVN. But am encountering a project management issue. To give you a background, most of my projects are related to web development (they go thru phases like design, programming, testing etc.).

Now I am implementing Trac for my projects. Now the problem is what should I place as milestones and tickets. For tickets how granular should I get? e.g. should I say Make X part of Y feature or Make Y feature only. The more tickets I make, the more time I spend making these tickets.

Also, for milestones, I have seen projects like CakePHP etc. When they use Trac, they set their milestones as version numbers (corresponding to tags in the SVN). Is that the best way?

So say I have a client whose final deadline is X date. Then I set my milestone as 1.0 with deadline as X. But then how do I track the project say weekly? Cause I don't want to realise one day before the release date that that too much is left. I want to have somehow weekly checks.

Also I want to take into account enhancements/bugs also as tickets and club them together as milestones.

Ive imagined something like 1.x.x where first x corresponds to group of feature enhancements while second x corresponds to bug fixes. Is there a better way? How do I manage weekly status in such a system?

Is there a standard way to do this? How do I go about it? Am totally confused.

Thank you.

Answer 1

Setting your 1.0 milestone to the deliverable date is fine, but you'll want to define earlier milestones - make them weekly if that's a good interval for you, and number them appropriately. For a 4 week project, maybe 0.2, 0.5, 0.7, and 1.0 would work. List relevant bits on each milestone: 'Design complete', 'Coding complete', 'Testing complete', etc. If you're not on target, then the real project management work starts!

Answer 2

I see you have several options and a couple of decisions to make.

You could think about Feature Driven Development. You could use trac to support communication rather that control. Coarse-grained tasks, fine-grained tickets and early releases.

Make a list of the features to be developed and state that the release, say... version 1.0, happens when all the features are developed and tested. Make umbrella tickets for all features. There are coarse-grained and will define development rhythm.

Now define a couple of milestones based on the amount of features planned and time. The first milestone should contain at least one feature, since the goal of a milestone is get the project built for testing and feedback. Define one or more milestones to mark when all features are completed, call them "beta", "release candidate" or whatever.

If during development there is a need to finer-grained tasks, don't be shy in making them. And make the umbrella tasks dependent on these newer tickets.

A bug report doesn't need to be under any of those, and can have as much detail as needed. These are fine-grained. These will not define development rhythm. One exception is a bug squashing sprint to eliminate showstoppers. Publish the names of the developers with more assigned and not solved bugs to compel them to solve the issues.

Part of the process of making a milestone, a beta or a release candidate is tag the source to make the process repeatable, and be able to spot bugs even when the trunk source has already changed. On SVN, the usual way to tag consists of copying the trunk source to a directory on "tags" and make sure nobody commits into that branch.

I believe a two number version number is enough for most cases. The first number denote compatibility and the second, the release. But there are several variables that can be inside a version number: source compatibility, binary compatibility, bugfix level, release, companion product version (ala oracle), protocol compatibility, etc.

Answer 3

Well, it depends. You didn't specify how big project, how many programmers will work, how often do you plan to deliver.

Stating that, here's how we use Trac on one big project spanning several years that consists of number of smaller subprojects.

• Milestones 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"

• Milestone description contains only list of new features or bug fixes. Documentation is written in wiki and in tickets.

• Trac Wiki 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.

• Tickets contain detailed description of feature or bug that have to be implemented.

  • Bug reporting tickets contain description of bug and steps to reproduce (almost always).
  • Feature tickets contain detailed description of feature that must be implemented. One ticket contains work for up to 6 hours. 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.

• There are few Trac plugins for estimating and time tracking. Check this page: http://trac.edgewall.org/wiki/TimeTracking . We use Timing And Estimation Plugin . 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.

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%.

Answer 4

I've been using Trac/SVN for two and a half years now.

Here is what I suggest:

• Split production of software version into several iterations: Inception, Elaboration, Transition (or call them whatever you want)
• Plan features for the very first iteration. For others plan enhancement and bugfixes
• Tasks (tickets) should be as granular as possible provided each ticket has a client-valuable deliverable
• Saving time on ticket creation is not a good idea. More granular and smaller tasks --- more control over the progress. Thus, earlier discovery of planning shortcomings and more time to manage out.
• Tickets can split even when in progress. If developer reached the result that can be shown to the customer but did not complete the whole task, then developer can split the task and mark the completed part as "closed" or "resolved" which gives some more granular control.
• Track the progress daily, not weekly (or at least several times a week)

The Trac is a very nice tool. The best feature or Trac is ability to put WikiLinks everywhere, including changeset comments. If you demand putting ticket # in changeset comment and then putting changeset number to the ticket comment this links the tasks and changes to the code. Later these links make it easier to track the evolution of the software. It is a life saver especially if the project goes beyond a couple of month in duration.