What types of specific development patterns support agile development?

Question

And the converse: "What type of specific development patterns DO NOT support agile development?

To be more concise: I'm not looking for "methodologies" or "theory". I'm talking about specific patterns for writing code in the itterative process that is agile.

Obviously, some patterns for development are more taylored to Waterfall. Others, for agile.

I'm looking for specifics revolving around your own personal experiences writing code. That's why this isn't subjective.

Answer 1

Iterative development is a necessary (though not sufficient) part of agile, while "waterfall" doesn't support it.

Answer 2

I think Rapid-Application Development, Iterative/Incremental Development, and even Chaos Strategy would all support an Agile Methodology.

Anything that requires everything solidified during the requirements phase would not support an Agile Methodology, e.g. waterfall model, Capability Maturity Model(CMMI), Cowboy Coding, and even Use Case-Driven Development.

Answer 3

Actually, the best answer I've been able to find is the book: "Agile - Principles, Patterns and Practices in C#"

Answer 4

I have a few to share but I'm not sure that these are what the OP is wanting listed:

• Pair programming - Having a pair of developers on any new feature to ensure knowledge isn't isolated to just one person.

• Test-Driven Development - Writing tests first to ensure requirements are met rather than waiting until after an implementation is done to add tests late.

• Continuous Integration - Having an automated build machine that can verify whether or not a code change breaks existing functionality.

I would note that there isn't just one way to be Agile as the manifesto is quite open to interpretation and can be perverted.

Answer 5

Good interpersonal aspects:

• A team of developers that trust each other and appreciate the different skills they bring to the team. - Do most devs feel they can speak openly? if yes then you have this.
• A flexible attitude.
• People who don't feel the need to demonstrate they 'know it all'
• People with enough courage to admit they're wrong.
• Willingness to try something new - within bounded parameters ("Let's try spiking it for 15 minutes... if it goes nowhere we'll throw it away.")
• Mutual-respect and eager co-operation between business and devs - a "same team" attitude. "We're all inside 'the circle of trust'" ;-)

Business conditions that help

• A business with zero interest in methodology that trusts the devs to get on with it is a big help. (I.e. no interference)
• Having a pay-per-use application really helps the business measure the effect of software releases on revenue. This depoliticizes the planning game because decisions are based on feedback in the market.

Programming languages aspects:

• runtime/debug systems that leave the program running continuously whilst you edit it (No time-wasting, energy sucking big builds between every dev step.)
• ... where you can type in some code and instantly evaluate it against the running program. This removes the need to have a debate over what some code will do - it's easier and more accurate to just run it!
• ... where you can have tiny units of code in your check-in - e.g. individual methods or a small class - definately no waiting minutes while some eliphantine source control system does book-keeping
• ... where you only have to think in one paradigm - i.e. only in objects or functions or whatever - no SQL, or XML or programmable template languages or other extra-lingual hacked on stuff. This means you can push work around from one place to another in the codebase when you're refactoring, without paying a "complexity toll" to cross borders into SQL, XML or templates or whatever other hack language it is...
• using a language which has very few concepts that integrate cleanly (Smalltalk, Lisp, Prolog, Ruby) rather than languages which are made up of every syntax hack in the world - making it impossible for mortals to understand the semantics of code (like C++ and Perl)
• languages that tolerate failure by throwing exceptions or responding in other ways - rather than crashing - means you can do TDD without stopping, starting and rebuilding all the time

I've phrased most of these things positively but you can imagine the absence or the opposite of any of these things as a negative...