Creating software allways follows a process. It can be a very Agile process, without even knowing you are following a process, but you can also use one of the familiar processes. Think about Rational Unified Process, Extreme Programming, Agile and Goal Oriented Design.
What is a Process?
Dictionary.com A series of actions, changes, or functions bringing about a result.
How does this relate to software engineering. I think a lot come to think of it:
- Actions - designing, analysing, coding, documenting, etc.
- Changes - Requirements management and Bugtracing
- Function - What the end results should be doing
- Result - Piece of software with which the user can reach their goals.
What process to use?
Using a process while developing software makes your life easier, really. It also results in a better product, really. The most important part of this is discipline. All people on the project should have a lot of it. What is therefore the most important part about a process? In my opinion the most important thing about a process is that it is your process as a team. With respect to gridshore, the process is very important. What do you do with requirements, how are the user goals analysed. What kind of documentation do you write. What kind of tools do you use, oops that is not process, but configuration management is.
To my opinion RUP is a good starting point for everyone, there is a lot of good information to find about the iterative appraoch and the different disciplines involved in a project. As with all other processes you need to tune RUP to your own project needs. During this tuning Goal Oriented design and even Extreme Programming can help. In the next part I will explain why and what I mean with this.
When looking up information on the WWW you can find a lot of verbal wars about the best process. Especially the Extreme Programming forums are pretty extreme. There is a lot of discussion about Design Upfront or not. The generals in this battle are Kent Beck for XP and Alan Cooper on the Goal Oriented Design side and of course there are RUP and CMM(I) on top of it.
The most important thing to learn as stated is to make it your process, feel comfortable about it. A lot of best practices are the same over different processes. To my opinion some form of an agile process is the best. Make it lean, do not produce documentation that is never read or used. Build on trust, go for quality and only do what the customer needs. Find a way to respond to changes in the customers needs. Most of all have fun while doing it.
James Dobson has created his own view on a perfect agile process, he has called it Conservative Xp. He has some very interesting ideas about customising the Extreme programming process.