Ian Oliver (2007) Experiences of Formal Methods in Conventional Software and Systems Design. BCS-FACS Meeting on Formal Methods in Industry. December 2007
The moral here is that being "agile" isn't about the languages and processe but rather the state-of-mind used:
- understanding your long-term goals
- understanding how your chosen languages and techniques etc work
- understand the need for abstraction, refinement, retrenchment
- understand the difference between modelling and architecting (see point above!)
- understand what your models are for, how they are to be used, what they tell you and how they are structured and related to each other
- make sure that you have a good set of tests (stop implementing individual use cases: this leads to madness, intractible feature interactions etc, use then as tests and validations to your system!)
- validate/verify/test/animate/simulate your system often
- understand what these validations/verifications/tests/animations/simulations tell you
- interact with the customer often - show them your results
- repeat until done.
Anyway, here's the blog posting:
What Agile Isn't
Posted by Eugene Wallingford, September 22, 2010 4:38 PM
Traffic on the XP mailing list has been heavy for the last few weeks, with a lot of "meta" discussion spawned by messages from questioners seeking a firmer understanding of this thing we call "agile software development". I haven't had time to read even a small fraction of the messages, but I do check in occasionally. Often, I'll target in on comments from specific writers whose expertise and experience I value. Other times, I'll follow a sub-sub-plot to see a broader spectrum of ideas.
Two recent messages really stood out to me as important signposts in the long-term conversation about agile software development. First, Charlie Poole reminded everyone that Agile Isn't a "Thing".
The ongoing thread about whether is always/sometimes/not always/never/ whatever "right" for a given environment seems to me to be missing something rather important. It seems to be based on the assumption that "agile" is some particular thing that we can talk about unambiguously.
It isn't.
