What types of specific development patterns support agile development?
And vice versa: "What kind of specific development patterns DO NOT support agile development?"
To be more concise: I am not looking for "methodology" or "theory". I'm talking about certain patterns for writing code in an iterative process that is flexible.
Obviously, some development patterns are more tied to Waterfall. Others are for flexible.
I'm looking for specifics revolving around your personal coding experience. This is why it is not subjective.
source to share
I think Rapid-Application Development, Iterative / Incremental Development and even Chaos Strategy will support Agile methodology.
Anything that requires anything that is solidified during the requirements phase will not support Agile methodology, for example. waterfall model, maturity maturity model (CMMI), cowboy coding and even using case-driven development.
source to share
Good interpersonal aspects:
- A team of developers who trust each other and appreciate the different skills they bring to the team . - Most developers think they can speak openly? if yes then you have it.
- A flexible attitude .
- People who don't feel the need to demonstrate that they "know everything"
- People with the courage to admit they are wrong.
- Willingness to try something new - in limited parameters ("Try to slip for 15 minutes ... if it doesn't work, we'll throw it away.")
- Mutual respect and impatient collaboration between business and developers is a "one team" relationship. "We are all inside the" circle of trust ", -)
Business environment that helps
- A business with zero interest in methodology that trusts developers to handle this is a big help. (I.e. no interference)
- Having a pay-per-use app really helps a business assess the revenue impact of software releases. This depoliticizes game planning because decisions are based on market feedback.
Aspects of programming languages:
- runtime / debug systems that leave the program running continuously while you edit it (no time wasting, energy sucking large assemblies between each dev step).
- ... where you can enter a code and instantly rate it against the current program . This removes the need to discuss what some code will do - it's easier and more accurate to just run it!
- ... where you can have tiny units of code when registering - eg. individual methods or small class - definitely no waiting minutes while some sort of eliphantine sourcing management system does the accounting.
- ... where you only need to think in one paradigm - that is, only in objects or functions, or whatever - without SQL, or XML, or programmable language templates, or other non-language hacks. This means you can nudge work from one place to another in the codebase when refactoring without paying the "complexity" to cross boundaries in SQL, XML or templates or any other hacking language - that's ...
- using a language that has very few concepts that are cleanly cleaned up (Smalltalk, Lisp, Prolog, Ruby) rather than languages that are made up of every syntactic hack in the world - for mortals to understand the semantics of code (like C ++ and Perl)
- languages that fail by throwing exceptions or reacting in other ways - rather than crashing - means you can do TDD without stopping, starting and rebuilding all the time
I have phrased most of these things positively, but you can present the absence or opposite of any of these things as negative ...
source to share
I have a few to share, but I'm not sure if this is what the OP requires:
-
Steam programming. Having a couple of developers on any new feature to ensure that knowledge is not isolated from just one person.
-
Test-Driven Development - Writing tests first to ensure compliance, not waiting until an implementation is done to test the tests later.
-
Continuous integration. Having an automatic build machine that can check if a code change breaks existing functionality.
I would note that there is not only one way to be flexible, as the manifest is quite open to interpretation and can be twisted.
source to share