views:

183

answers:

4

My biggest concern is ease of use, and nothing beats a google spreadsheet or document (Except maybe Office). At some point, the free-form nature of the formats starts to cause a problem.

Specifically, I have the same conceptual data split up between two documents. This is done because both provide useful views of the data. (Note that this is meant to strictly manage feature descriptions written by "management" and then correlated with tasks created by "development")

  • Document (Basically the functional specification)
    • Contains high level descriptions of releases and features
    • This is written in user-speak but created by management/marketing/producers/customer proxy
    • Useful for a quick glance or detailed read through of the features in a release.
    • This is "user" facing
  • Spreadsheet (Basically the engineering schedule)
    • Contains line item descriptions of feature tasks, estimates, and resource assignments
    • This is developer facing
    • Updated collaboratively by developers as they work
    • Useful for a detailed view of the effort required (and spent) for features in a release.

Sometimes we want to reprioritize features, or add/remove ones, and that happens in the document. That restructuring then needs to be duplicated in the spreadsheet. This is a pain in the ass.

  • My ideal solution would
    • Easily support batch rearrangement of arbitrary groups of items (like a spreadsheet does).
    • Be completely usable without touching a mouse.
    • Be able to switch back and forth from a narrative outline view to a detailed line item view.
    • Have different data visible in each view, but have the data travel with the items if they move.
    • Support basic rich-text formatting
    • Support simultaneous-ish editing by multiple users (Ala google apps, zoho, etc.)
    • Absolutely no support for diagramming.

So how do you to track this stuff?

A: 

At a past employer we build a simple system to manage the releases. It served to communicate release dates, release notes, and defect tracking. Worked very well and it probably took someone a week to write in PHP or something.

/Allan

Allan Wind
Could you elaborate on exactly what the system did and how users interfaced with it? Did it require a lot of mouse clicking or could it be done completely with the keyboard? How about re-ordering items? Was that difficult?
Jason Citron
+1  A: 

Fogbugz is an excellent solution. It's also developed by the company owned by one of the co-creators for stackoverflow.com.

phloopy
A: 

If you're a model-a-holic, there is a nice tool called Enterprise Architect which can help you with your "spreadsheet" management. Its multi-user, and has a lot of functionality built in. It can also generate higher-level views, but I would not consider them customer/marketing views. Those are best hand tuned and edited in my opinion. EA is sometimes compared to Rational Rose without the suck, which is a fairly good description.

If formality and extensive modeling is not your strong suit (its not mine), even a simple Bugzilla instance (or other issue-tracker) can be used. Bugzilla does time tracking, priorities, can be smashed into doing resource planning, etc. Other options here are Trac or Redmine.

Another popular tool for the diagram-happy crowd is Microsoft Project. It does suffer from the multi-user usability problem though.

Note that all of these are "developer" tools, not customer/user tools. As I said above, you should really produce this by hand. When you do a release (even interim releases), spend a couple of hours looking through your developer-side tool on completed tasks and transform them into something customer or higher-up ready. If you can't devote the time at the end, create 'large' tasks and mark tasks as dependent on these higher level ones.

Yann Ramin
A: 

There's bunch of ways of doing this, obviously. I've been in few projects where we've used wikis which have had integrated task management like trac and then there has been a larger scale software called JIRA.

Trac is open source and I've seen it use in fairly big open source projects. The wiki is brilliant for documentation because of the collabaritive nature of wikis and task management is really nice for features as well as bug tracking. You can assign tasks and developers can give them estimates. I don't really know what kind of reporting you can get out of Trac but at least there are some things already available Trac Reports. I've been using Trac mainly from the developer and project oversight perspective but I think it could be adapted to also management. I can recommend at least looking into it.

I have had only developer experience from JIRA, but just because the thing has been used in large scale systems I suppose it must have fairly good reporting facilities. At least it draws diagrams and we know how the management likes them. ;) It doesn't have wiki feature, but I've been using Confluence with it. They're both from the Atlassian so they can be integrated together at some fashion.

These are tools I've had really good experience with. Wiki kind of enviroments are fairly widely used and you can really modify them for your own use. Task management is really pain in the ass if you have to do all the modifications manually. With proper tools and reporting facilities you get better view of the progress of your project.

Bleadof