Which software development method?

Question

Hello,

I'm a member of a software development team working on a small project (we think that we can release a beta quality product after 2 or 3 month continuos work). since this is our first teamwork, I decided to ask you to suggest me a good development methodology.

so Which software development methodology would you suggest for a small project with small number of developers (less than 10)?

Answer 1

This really does depend on what you are intending to build. If the project is going to be something you want to build upon and have regular intervales something like Agile / Scrum would be very suited.

But it really depends on what the project is to determine release iterations and the like etc.

Answer 2

I think that you need to start from Joel Test and try to implement most of this list: http://en.wikipedia.org/wiki/The_Joel_Test

And as product development use KISS = Keep It Simple & Stupid, for first release

Also really good start is Getting Real book, available free from 37 signals: http://gettingreal.37signals.com/toc.php

Answer 3

There are two approaches to software development:

1. Write down what you are going to do, do it, then agree that you have done it.
2. Start developing stuff, agree that what you have done is good, repeat until finished.

Both have their adherents and both pop up repeatedly under a variety of names. Each new generation of software developers (ie about every 2 years, this is a fast changing industry and software developers have the lifespan of a mayfly) rejects the previous generation's approach, re-discovers the approach used by the generation before last, renames it something funky and declares it to be the ONE TRUE WAY.

The choice between the approaches ought to depend on the culture of (a) the customer organisation and (b) to a lesser extent, the culture of the supplier organisation (ie your software developer team).

So, if you work for a buttoned-down conservative enterprise approach 1 is indicated. If you look down and see that you are wearing surf shorts and came to work this morning on your skateboard, go with approach 2.

And, in case you have read this far, the most serious bit is the paragraph before the one before this final one, ie the one starting 'The choice ...' This is a cultural / organisational issue rather than a technical one. Both approaches have been used on many many successful projects, neither has a monopoly on unsuccesful projects.

Answer 4

This really does depend on your customer.

• If the customer can accept fixed time, fixed resources, fixed quality (100% working code), and slightly variable scope, I recommend choosing an agile methodology.

• If the customer cannot accept the above, i.e. the pre-condition for using an agile methodology is not present, I recommend choosing any methodology you like.

The important thing is that you do have a methodology, learn what is working as you go, and use the knowledge to adapt the methodology.

Answer 5

Don't do waterfall, this never worked and will never work. Thinking waterfall is a working methodology is like thinking banging your head against the wall is good, because even the sturdiest wall MUST crumble at some point.

I'd go with a reasonable agile methodology, like Scrum (XP is a bit harsh). Also, introduce things like TDD, DDD, DBC and you should be fine.

Answer 6

I wont suggest this as THE best answer, without having a better idea of the context and circumstances, but I am personally becoming a fan of the Lean / Kanban approach. In general I find a lot of the agile / scrum methods can be fairly developer focused, and almost anti-manager sometimes, which is sometimes appropriate but not always. The lean approaches tend to address the entire value stream rather than just the development itself.

You can read more about it at :http://www.limitedwipsociety.org/