which process is best?

[ankur rathi]

Which process is best??

I know it is very subjective question, but there must be something to say and debates...

Thanks a lot.

[Tony William]

I think there is no process that could fit / win in all situations.

There are a lot of variance / affect that can affect the choice of process (or how the development apply the processes / put focus on particular areas of a process), e.g. project scale & timeline, no. of people in the team, nature of projects etc.

[Rudy Harianto]

There are a lot of variance / affect that can affect the choice of process (or how the development apply the processes / put focus on particular areas of a process), e.g. project scale & timeline, no. of people in the team, nature of projects etc.

This is where the "experienced manager" highly expected in the project

[Jared Richardson]

Originally posted by rathi ji:
Which process is best??

I know it is very subjective question, but there must be something to say and debates...

Thanks a lot.

You should read about and study ~several~ processes then pick the process (or process parts) that work best in your shop.

Honestly, there is no single best process. You'll meet people who think XP is for everyone, others who think SCRUM is the only way to go. Learn them both (and more) and see what works for you.



Here's an article by Martin Fowler that gives you a good overview.

[Scott Ambler]

At Choose the Right Software Method for the Job I overview, compare, and contrast a wide variety of processes.

Effective developers have a wide range of techniques in their intellectual toolkits.

- Scott

[Tony William]

To add my little opinion / experience:

We should be able to find tons of books / web sites telling us the details of the processes. At the same time, we need to know the processes, see which one is best for your organization (or project team), make a choice, try it out, review what the process bring to your organization....

In some cases, you may even want to 'modify' the process, say, by not strictly following it. For example, there is process that put focus on reviewing the project status / stage with reference to the delivery of document. But if certain doc is really meaningless to your team (or there is existing doc in your organization that serve the same purpose), I see no reason why we need to follow the same doc set as what the process states.

May be someone can share with us on "modifying the well-known processs".

[Peter Sin]

Originally posted by Tony William:
I think there is no process that could fit / win in all situations.

There are a lot of variance / affect that can affect the choice of process (or how the development apply the processes / put focus on particular areas of a process), e.g. project scale & timeline, no. of people in the team, nature of projects etc.

Agreed.

[Ilja Preuss]

Originally posted by rathi ji:
Which process is best??

The one that the development team comes up with during the project and that is closely tailored to its current specific needs.

In my experience, it's much easier to start very lightweight and grow it along the way, than to start heavyweight and shrink it down.

[Ilja Preuss]

Originally posted by Tony William:
In some cases, you may even want to 'modify' the process, say, by not strictly following it.

I'd even say that a good team will continuously adapt its process to the current situation.

[Tony William]

In my experience, it's much easier to start very lightweight and grow it along the way, than to start heavyweight and shrink it down.

Any suggestions on what "lighweight" activities to be first introduced to the team?
[ August 05, 2005: Message edited by: Tony William ]

[Lasse Koskela]

Originally posted by Tony William:
Any suggestions on what "lighweight" activities to be first introduced to the team?

I'll give you two answers coming from my personal opinion.

1) I'd say the first practice to introduce would be short increments--have the team develop software in strictly time-boxed, 1-4 week iterations each delivering *working features*. The key is not the length, not the time-boxing, and not the features themselves. The key is that together all of this gives you concrete feedback on how fast you're moving.

2) If, however, your team's internal quality is on a level that doesn't exactly assure you'd be able to sustain an incremental development process, focus on the internal quality before moving to incremental development. This might mean ramping up test automation (for quickly catching regression), introducing pair programming or frequent code reviews, and adopting test-driven development.

The biggest gains in productivity can be achieved with project management level practices (1) but that often requires introducing also some of the supporting development techniques (2).

[Jared Richardson]

You might want to look Continuous Intergration. CI requires (1) source code managment and (2) a scripted build. If your team doesn't use these two, you can set them up yourself on your desktop for a proof of concept.

Then you install CruiseControl, AntHill, Continuum, etc (any one of the many Continuous Integration systems available). Use your desktop if you can't get a space on another machine. You can provide CI reports, email notification (if appropriate) and constant compiles with a location for automated tests to run... and you haven't "changed" the way the developers work.

They still compile, they still commit their code, just like always, but now, from the CI machine, they get small quality notifications. The code was good, the code was bad, test X passed or test Y failed. Developers will begin to expect these notices and get in the habit of more frequent commits, because they know it's "safe".

CI adds a lot of benefits without forcing anyone to change the way they work outright... and it gets the smart people introduced to CI. That means they hit Martin Fowler's site for the CI paper, etc. This introduces them to a whole new community. You've gotten them thinking about Agile processes without having to preach Agile. Then when you do introduce ideas, it's not the first time they've heard of them.

[Ilja Preuss]

Originally posted by Tony William:

Any suggestions on what "lighweight" activities to be first introduced to the team?

I'd suggest to tackle some of your worst problems.

For example, when I joined my current company, integration was a serious problem. Making a distribution typically took days, simply because the code wouldn't compile when put together.

What I did was taking responsibility for the Ant script and installing Cruise Control. Today, we automatically get a new working distribution every night, and we notice immediately (that is, within two hours) when someone breaks something.

[Jared Richardson]

Ilja makes a great point... don't introduce anything if it doesn't solve a problem your team has.

Don't use Agile because it's Agile. Use Agile if it solves one of your problems.