In Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle, Ian F. Alexander and Neil Maiden mention periodic design refactoring:
A variant of the Incremental model appears to be the ‘Extreme Programing (XP)’ approach put forward in Beck (2000) in which integrity of the system architecture across all increments is maintained by periodic design ‘refactoring.’
While I’m not a fan of Big Design Up Front, I am a fan leveraging the following techniques up front to help reduce risk:
- System stories up front (where system stories include the ‘ilities and quality attributes, such as performance, security, reliability, … etc.)
- Architectural spikes (time-boxed exploration to do some focused, end-to-end tests around high-risk areas)
- Candidate architectures
- Tests for success
I think these lightweight techniques help avoid dead-ends and help you figure out what you know, don’t know, and need to know next.
This also ties in with the emergent architecture http://www.scrumlabs.com/2008/07/emergent-architecture-yes-or-no/
and technical debt http://www.scrumlabs.com/tag/technical-debt/
debates that I have been having with myself 🙂
I agree with your points on leveraging techniques.
I agree with your leveraging techniques quoted.
This whole area ties in the emergent Architecture and Technical Debt debates.
http://www.scrumlabs.com/2008/07/emergent-architecture-yes-or-no/
http://www.scrumlabs.com/2008/07/technical-debt/
Thanks.
Hey Gerald
These are lessons learned from the school of hard knocks. I’ve seen projects that couldn’t see the forest from the trees, as well as projects that discovered too little too late. I’ve also experienced projects that did too much up front planning that turned out to be wasteful, over-engineering.
In today’s market, the key is to cast a wide net up front, identify your key risks, and spiral down, staying flexible and adaptable along the way. In other words, expect the unexpected, and don’t try to plan for every exception. Have a vision, but be able to refine it as you go.