What is your favorite Software Engineering methodology?

Question

I'm hoping the SO crowd can help me expand my definitions of methodology buzzwords such as SCRUM, Agile, XP, Waterfall, etc, and give some enlightenment as to which approach is the best. If there's some specific book or web page that really captures your philosophy on constructing software with teams of programmers, please indicate it.

EDIT: Please don't say, "I use a little of everything." without any more detail. If you haven't read any books or websites that have been helpful, now's your chance to enlighten the world by describing your experience-learned methodology. I would encourage the moderators to up-vote more descriptive answers. It's OK if you haven't read any books and made up your own style from experience, but please describe that style so we can learn from you. Thanks for taking the time to answer my question.

Answer 1

XP.
I think this was the only method which really changed a lot for me in a real-life commercial project... Concepts of pair programming, frequent commits/builds and test-driven development are most valuable in XP.

Answer 2

Agile development + Pair Programming + Test Driven Development

Answer 3

I am partial to the "Keep Learning About Programming And Do What Works" (tm) approach.

Answer 4

I use a mish mash of whatever methodologies are useful. I mean, i have rarely found one single methodology to be the best for any situation. So i bend a few methodology-rules and adapt the best practices for one particular case.

EDIT: The methodologies i usually draw ideas from are: Waterfall, agile development, prototyping, iterative development etc I learnt all of those in this book: Software Engineering: A Practitioners approach - Pressman which i stronly recommend for anyone wanting to learn the basics of software engineering. For XP, there is a lot of good information available on the net. I also checked out This book from my library.

Answer 5

My project is so big and my customers so disorganized that only Waterfall can give me the structure I need to design and build and deliver a good product. It sounds really good to execs and, though clunky, really boosts the quality of your design, by forcing you to consider the big picture. It also allows me and my team to work independently and with minimal interruptions. A good spec goes a very long way.

Answer 6

BDUF = Big Design Up Front

Software development is much more than source code writing. You create a new world of interlinked notions and objects, functions and processes. Every bit of it requires careful planning and thinking. I prefer to do that up front. It's only easy in theory but that is what I'm striving for

Answer 7

I like SCRUM (although I have never implemented it just right).

The most interesting things about SCRUM for me are:

• One of the rules is that during an Iteration, the customer can be present in the team's daily meetings, but cannot change priorities or change features. That gives the team freedom during an iteration and makes the customer more aware of the need to wisely choose the features for the next iteration.

• It promotes a 'formal' architectural phase previous to the beginning of the development, unlike most other agile practices.

• The Scrum Master is not 'the boss' but the facilitator of the team

• The backlog is, in my opinion, a good way for the customer to see graphically in one place how the work is being dispatched and how the priorities need to be set in order for the backlog to make sense for the following iterations.

In the end, the premise of giving a good team freedom and empowerment to get great software.

I'm not saying SCRUM is the only one that uses these concepts. I'm just saying I like that it uses them all.

EDIT: To answer the comment by bmdhacks: I first learned about SCRUM listening to this talk and to this other talk by its creator, Ken Schwaber. This guy is so amazing and his thoughts so provoking I almost cried =)

Answer 8

I'll throw in another vote for SCRUM (project management) plus XP (technical practices). After doing waterfall development for many years, I can't imagine going back to that. My customers really like the visibility that it gives them into the process, and the ability they have to 'steer' the project. They also like being able to see finished working features on a regular basis. The discipline that is required to work this way is substantial, but for the teams I have worked on, it has worked extremely well.

As far as a book, I think that "Scrum and XP from the Trenches" (available both as an e-book and in dead-tree form) has really been one of my favorites. Available at http://www.infoq.com/minibooks/scrum-xp-from-the-trenches

Answer 9

I think XP (eXperienced Programming -- pun intended here) is the single most productive methodology ever. When you got to know and use many tools, read many articles and books, met many smart guys (and girls), worked in many shops with different languages, in many diverse environments then you get things right fast.

Picking the more apt method is a matter of preferences, team composition, project and deadline. Anyway agile methodologies seem to have an edge in that they tend to give the final customer a taste of what's going on very early, avoiding the "impact" which usually brings nasty surprises just when it's too late.

EDIT: as a side note TDD is something that everyone should do, waterfall, spiral, fireworks, sierpinsky, EVERYONE!

EDIT 2: ok, so you'd like more descriptive answers.

At University I've been introduced to the classic waterfall method: requirements gathering, design phase (with UML), development, test, deploy and maintenance. I could never apply this method, mostly because of the fuzzy and ever changing requirements. Plus, since you learn new stuff on the job, you are very likely to get back to the code wrote earlier and look at it in disdain.

I've been lucky enough to have a mentor who used agile (XP in particular) and taught me the value of unit tests, design patterns (and anti-patterns), code documentation and embracing changes. Unfortunately we could never pair program because he worked in UK while I travelled a lot, so I can't say if that could have worked (even if I suspect it would).

At the moment I'm trying SCRUM with my team. I do like in particular the concept of requirements as stories because it gives you a definite working set. I don't like how SCRUM handles the layers (or - more likely - we are doing something wrong). For example: I'm in charge of DB+Hibernate, so of course I have new tasks for every single story my colleagues are developing. I know we would better define some guidelines and develop every story from top-down as a separate entity, but I believe that a certain degree of specialization is not only unavoidable, but even welcome (provided that you can switch roles from time to time to let everyone learn new skills).

IMHO it all boils down to some tools and techniques that are universal: unit testing, for example, the value of communication between colleagues and with the customer, the importance of code review and refactoring, the classic DRY, KIS, DOTW, YAGNI. What I think everyone in favor of a mixed approach is trying to say is that you should not throw away the initial design phase (waterfall) but you have to "steer" the work on the run involving customer and writing code that's easy to change according to the new requirements (agile).

Answer 10

Agile works great for me. I like to have a working (partial) solution as soon as possible because it is a great way to discover omissions in the design phase.

But most important, if yo use any method, don't forget about common sense and intuition. And be creative.

Answer 11

There is no one best strategy, it all depends on what you are doing, how critical it is, how many programmers are working on it, etc. For example, Agile development might be really good for creating a game, but it would be totally unsuited to writing mission critical software for the Space Shuttle.

As far as organizing large teams of programmers goes, a couple good reads are

• The Mythical Man Month, which talks about organizing large teams of programmers and problems with this (such as adding programmers to a late project makes it later)
• The Cathedral and the Bazaar, which talks about how and why open source project organization works (essentially, a team distributed all over the world)

Answer 12

Agile principles, implemented via the scrum process. Results are more important than process.

Be an Agile advocate, don't be Agile Evangelist!!

Answer 13

My experiences have driven home two interrelated facts:

(1) Without talented people who have some experience it doesn't matter what methodology you use, you're screwed.

(2) Talented people can usually be successful regardless of which methodology they end up using (or are forced to adopt).

So, it's almost like you need to learn a lot of this stuff the hard way; by screwing up. With that in mind I like a lot of the agile techniques because they let you see the project is a disaster WAAAAAYYYY sooner than something my long-cycle like waterfall.

Then you can start over or move on with a powerful lesson learned. If you continually make the same mistakes, well, you need more than a methodology...

Answer 14

Prototyping (Majorly)

Iterative +

Automated Tests