In a recent research we saw that many companies for IT doesn't use any process or methodology for their projects. But anyone that have studied any development process know that chose the right model is very important and have big results in any project.

Soo, fellow monks, what process/methodology do you use?

I'm interested to know what methodology do you use in your company or in any project, and how it works. If you, as programmers, really know the methodology adopted, if it really works, and if everybody follow it.

Update: I use UP, Unified Process, that is very popular and is becoming the standar development process. ;-P

Graciliano M. P.
"Creativity is the expression of the liberty".

Replies are listed 'Best First'.
Re: Process Model for Projects
by simon.proctor (Vicar) on Oct 02, 2003 at 08:56 UTC
    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.
[reply]
      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]
Re: Process Model for Projects
by cLive ;-) (Prior) on Oct 02, 2003 at 19:02 UTC
    1. get outline of expectations
    2. write simple summary of functionality - confirm with sponsor
    3. write tech specs - method, db table, flow etc summary - pass round dev team to see if you missed anything
    4. write, pass on for code review (informal)
    5. check in with sponsor for any feature additions
    6. pass to QA, listing params expected on each iteration (web stuff :) so can be hammered
    7. publish to Beta server
    8. write end user docs, support docs, dev docs
    9. publish to live servers

    Well, that's the theory, anyway :)

    tilly just leant me Peopleware, and I've found that very useful, and Rapid Development, that I have yet to make a large dent in. I think both are worth reading though.

    And no matter what environment you're in, argue for clear docs from the start, and testing. It *will* save you time in the long run.

    I guess it all depends on the environment you work in though ;-)

    .02

    cLive ;-)

[reply]
Re: Process Model for Projects
by poqui (Deacon) on Oct 02, 2003 at 20:59 UTC
    I like something called "spiral methodology". It seems to fit actual process flow more than any other "methodology" I've worked with yet.

    1: receive request from user community (report/ new system/ whatever)
    2: mock up (potentially throw away/ better if reusable but can't count on it)
    3: user comments/ changes
    4: keep what worked, change what didn't

    Repeat this process as quickly as possible, with releases of stable code at least monthly, and major releases at least quarterly.

    Its helpful to have a spreadsheet or summat to keep track of user requests. Then a triage session weekly to include/push requirements into the next release is needed to keep the list and user expectations manageable.
[reply]
      Sounds like a less focussed version of some of the Extreme Programming principles to me. Take a look if you haven't, you'll probably like it.

      Makeshifts last the longest.

[reply]
        Yes, I agree Aristotle, now that I've taken a look at Extreme Programming...
        "Spiral Methodology" seems like a few baby steps towards "Extreme Programming" from the Anarchy we had, called the "Waterfall" method. ;-)
[reply]
Re: Process Model for Projects
by Roger (Parson) on Oct 02, 2003 at 23:26 UTC
    I have worked with a large international company in the past, and I was impressed by their software development approach. The development cycle is as follows:

    The project tasks are divided in various stages. The project plan for each phase is further divided into 3 categories:
  • Must have
  • Should have
  • Nice to have

    The Must-have's are requirements that must be met for this project phase. The Should-have's are requirements that should be completed for the project phase, but ok if not completed. It will slip to the Must-have's in the next phase. And the Nice-to-have's are features that are not essential for the project phase, and would progress to Should-have's in the next phase if the project slips.

    If the project is going according to plan with time to spare, then items in the Must-have, Should-have and Nice-to-have categories will be promoted, ie., Must-have's add to the should-have's in the previous phase, and should-have's add to the must-have's, and so on...

    This approach is what I believe a simplified XP (Extreme Programming) in practice. And it seems to be quite successful too.

[reply]

Back to Meditations