in reply to Process Model for Projects

My development process varies but can be summarised as follows:
1. Get verbal spec (we want it to do something like . . . .)
2. Ask for written spec
3. Get told it will be easier to just have it built
4. Build it according to guesses
5. Told it doesn't do what they want, please change
6. While !(satisfied) goto 2.

And believe it or not this has been at every company since leaving University.

Now for documentation

1. "We don't have the time for you to document your project"

followed 6 months later by.....

2. "Please explaing to ... how your project works"
And so on . . . .

Still, phwoooaar eh ;)

SP :)

PS:

Oh yes, I've tried the UP, as far as I'm allowed to go is UML diagrams. The best I can do for requirements capture is stage 2 (above) and then attempt a steely gaze when I see wasted effort ahead. I'd like to do XP but I'm in a team of one when it comes to my projects so no pair programming there :).

Still . . I'm on salary so I get paid the same now matter how much of my time they waste.

Replies are listed 'Best First'.
Re^2: Process Model for Projects
by adrianh (Chancellor) on Oct 02, 2003 at 12:18 UTC
    I'd like to do XP but I'm in a team of one when it comes to my projects so no pair programming there

    I try and do as much of XP as I can on a project - even if you cannot do all the practices, the ones you can do help. For example I can imagine that having user stories, acceptance tests and small iterations would help you with the more... annoying... aspects of your current "methodology" :-)

    At the moment I am sole developer, so I cannot do pair programming. I also don't have an onsite customer, so they're not around to answer questions immediately or help write acceptance tests. However everything else in XP is working just dandy (planning game, iterations, test-first, etc.)

[reply]

In Section Meditations