Req. Gathering, Proj. Mgmt., Bug Tracking, etc!

[RhythmAddict112]

Hi everyone - thanks for reading my post,
I'm a developer on a relatively small team, wtihin a sizeable organization. Our team has very, very little in place in terms of formal practices for the following:
- Requirements Gathering
- UML (or similiar) process flow diagramming
- Bug tracking
- Project Mgmt. in general

Basically, I'm looking into software packages that would help us facilitate any of the above, or anything along those lines. It would be nice to see some open source packages that we can customize, but we're not averse to paying for anything, either. So far I've looked into things like ArgoUML, and Bugzilla...What other S/W packages should I be looking into, and is there a comprehensive source I can go to for more information and these types of packages? Any information is apprecaited!

All hail the INTERWEB!

 

[MikeLacey]

Hi,

I'd suggest that that list is in completely the wrong order *smile*.

Put Project Management at the top, define the structure of the project first and then define specialist documentation once you know the aims, limits, timescales, team members of the project.

Mike

You cannot really appreciate Dilbert unless you've read it in the
original Klingon.

Want great answers to your Tek-Tips questions? Have a look at faq219-2884

 

[grooke]

Here are some off the cuff ideas.

Mike is spot on. Get control of the project first.

Perhaps, I would do one other thing first. Find out what the Big Organisation is doing. If you remain small, they may ignore you, but if you grow, they will take an interest, They will usually try to force you to follow their existing systems, which for Big organisations usually come out of the ark. Try to plan with this in mind. Make sure that your planning is strong enough to face such an attack or that it is flexible enough to fall into line with them.

1. Get a set of directories on your shared drive:
Templates for use in documentation; get someone to make some good ones and avoid hand crafting indexes and other crazy schemes.
Team Structure and its position within the Big Organisation; use links to Big Organisation diagrams.
Where to go for Software tools help, PC Desk Help, Telephone Help, car parking tickets, etc.
Product brief, so that people can see where they are going.
Project Documentation Ditectories.
This all sounds trite, but it starts making a happy project. Each person sets up one of these and they all find them helpful.
(One for yourself) A good simple project task/resource tracking system. Use it for planning but dont get bogged down with detailed monitoring; gut feeling or simple % complete seems to work as well as detailed monitoring; you are a small project.
If you follow the policy that Fri afternoon is a good time for tidying, then set the team to produce one of these each next friday.

3. Get someone looking at the working configurations, machines, networks tools etc. Nothing starts until you have some basics in place.

2. Requirements are just bugs; 'the system doesn't have that feature (working) yet'. So I would split the requirements gathering into two parts:
i) Gather the requirements in UML from the very start; use case driven or domain driven or both. Get you customers familiar with the simplest UML you can produce. My experience is that they love Use Case Diagrams if YOU get them right: no functions, ONLY statements of what the user wants. Become a psychologist, and distinguish the users desires from how you will implement it. This step is CRITICAL to UML success.
ii) Size the use cases etc using whatever rules you can find. Then add them into your bug system with a 'User cant do this!' approach.

This has eliminated one of your catagories.

3 UML and other Software tools.
Get one good opinion that is supported by at least one other reliable person and then go for it. Make it work. I have seen several projects where they were still trying to decide which software tool to use when the project finished. Only consider existing tried and tested tools; no 'Vapour-ware'. Certainly NO 'home-grown' tools.

Buy every team member a copy of Martin Fowlers Distilled book and say that that is the standard you will use without an amazingly good reason for one special feature. Insist on good naming of use cases, classes etc. Most confusion is caused by people using several names for the same thing.

4. Finally, Keep your team informed. I have worked on projects using almost XP like development. The morning meetings were brilliant. 5 -10 minutes. Make sure that they just say what they achieved yesterday, what they are doing today, and who they need to communicate with today or tomorrow. Insist on terminology that every one understands. BAs may not know what 'Harligan's ghost data access pattern' is. One good sentence outlining it makes a world of difference.

Make other meetings few and far between, Keep them simple. Minute topics and action. When checking progress on actions only accept one word answers: 'Done' or 'Not Done' (Woops 'NotDone'). If someone wants to know what was done or to dispute the answer, let them bring it up under general business.

Sorry. This is a 15 minute brain dump of things that I have not thought through. They may give you some other ideas. Nothing in here is complete or necessarily sound. I just felt like waffling. But I hope the thoughts help somewhere.

Gil