What software development process do you use?

Question

I have always used the agile Feature Driven Development process for developing software. What does everyone else use, and why do you prefer it? I prefer FDD because that's what I started with fresh out of college. In college, everything was very free-form and my "customer" was typically my professor, who might not have had much industry experience outside of doing research for the university.

Now, my customer(s) are not so forgiving and I do a lot of work in the medical field. Being agile and having a high level of quality is a must!

Answer 1

Test Driven Design TDD

The confidence you get from knowing that a code change has not broken something subtle is great

Answer 2

I go with Agile Scrum, It gives me feeling of 'connected to the team. And have good control over the milestones and indivudual taks.Morning scrums are very useful. We use Agile Scrum project template in Team System http://www.scrumforteamsystem.com/en/default.aspx

Answer 3

Code and Fix !!

Just kidding, TDD is really a wonderful way to go.

Answer 4

Cowboy - shoot from the hip... ;)

Answer 5

I second the vote for Agile. I am exploring Lean these days, but like with any development process, it's not something you can just drop in on your current group. However, there are features of Lean and Agile that can be eased into your current processes and gain immediate value.

My former project used the Waterfall method and were proud of it. They've since weaned themselves off of Waterfall and on to Prototype, which is a good step.

Answer 6

Agile development methodologies with a combination of XP Engineering Practices:

• TDD coupled with Refactoring
• YAGNI (You ain't gonna need it)
• KISS (Keep it simple stupid)
• Refactor to Design Patterns
• Pair programming with switching pairs
• Shared Code Base
• Deploy early and often

Answer 7

+1 for scrum!

Answer 8

Whatever the current project requires.

I do a lot of consulting on my own time for various (mostly PHP-based) web dev. I haven't devoted the time to get to TDD for those projects yet, and many of them are using existing frameworks that don't really make TDD all that easy.

At work we're not tooled for TDD yet, so we use a hybrid of agile and old-style spec-based processes. Trying to get a movement towards TDD, but we're a small shop with well-entrenched existing projects (lots on maintenance work) and integration work with ERP systems. I think I could get TDD going on my own integration work (and am making baby steps in that direction) but the other stuff is largely a lost cause.

Answer 9

Design by Contract with a complement of unit testing

Answer 10

There seems to be some confusion here:

TDD is more about how you implement code and not about managing the overall development of a software project. TDD will not help you decide which features to schedule, when to deliver, or how to set priorities.

In contrast, things like Lean/Agile or even Waterfall are about these higher level issues. (My vote is for Scrum which falls firmly into the Lean/Agile area.)

XP (Extreme Programming) is interesting because is blends ideas from both of these areas.

Answer 11

I work for a company that does both web and systems development. Our development model is Rapid Development. We use the more modern definition of it, so it is similar to Agile Development. Without the XP concepts.

Answer 12

We use scrum too... I think standups can be good in some respect, but sometimes the quick 15 minutes becomes at least 30.

Answer 13

I guess I am old school. I develop to client spec. A vigorous design phase followed by a heads-down development, test, bug-fix cycle. Then, implement.

Once the spec is defined and agreed, no further changes can occur. All changes are to wait for development and bug fixes to have been completed. This prevents scope-creep and allows the software to get written, tested, debugged and implemented. At that point changes become enhancements, new features, etc.

I have come to find that for almost all my clients over the past 10 years, about 90% of the things that they would have "thrown in" during development, creating scope-creep, are thought of as not being necessary. I cant tell you how many clients have thanked me for keeping them at bay. So I dont know what process you would call this but it works for me and for many other developers I know.

Answer 14

At work we use the ICONIX process. It is a subset of AGILE techniques and it is behavioural requirements driven. The ICONIX process aims to be as low-celebration as possible having as little documentation as possible - in order to allow you to easily keep it up-to-date (this is a big difference from other AGILE processes, for example XP practitioners often do not seem to maintain documentation up-to-date after the 1st draft claiming that their code is the documentation).

Here's a practical overview of the process:

1. Quick Draft of Functional Requirements
2. Quick Definition of a Domain Model
3. Model Use Cases on the base of previous steps
4. Optional - Draw a throw-away robustness diagram for each use case, just to understand relations between your classes
5. Draw a Sequence Diagram for each use case
6. Model your test-cases on the use cases
7. Implement
8. Test

At each step you review your work as a whole updating your domain model (it's impossible to get it right first time) and adding comments on your use cases. By the end of step 5) you end up with ready-to-implement classes and logic with just little documentation to maintain if you re-factor or change anything:

• Use case diagram
• Sequence Diagram for each use case
• Test case diagram (or test plan)

If you need to add a feature, you add a new use case and follow the whole process.

Resources:

Iconix process website

Iconix Software Engineering website

Books References:

AGILE Development with ICONIX Process

Answer 15

I'm a fan of Lean Software development, which is promoted by the Poppendiecks, largely based on principles from lean manufacturing, with Toyota as the poster child. It's got a lot in common wit the other Agile methodologies, the focus is on eliminating waste, making use of queueing theory, and a "just in time" mindset (e.g. specifying a story at the last responsible moment).

Lean is often associated with Kanban, which is a method for tracking tasks through a pipeline.

Answer 16

We use waterfall where I work but after some pushing on my part we're moving more towards an agile/TDD/CI hybrid model for some of our new projects. God willing, we'll be able to ditch the waterfall method. Every maintenance release we do, our main customer just ignores reqs deadlines and hands us requirement changes right at the last second and then just stares blankly at us while we explain why they can't keep doing that.

Answer 17

My personal leanings over the past few years have been toward Lean Development, with a heavy influence of everything that I've learned from XP. I think it's important to note here that Scrum is insufficient as a development process as it does not inform the work of software development, but the work of trying to manage the flow of software development tasks. My thinking has been informed by ICONIX as well. I think it's a great way to approach a use-case and diagram driven environment without getting bogged down in counter-productive bureaucracy.

Answer 18

Does anybody know anyone who is using ICONIX with TFS?