Someone at work, new to agile approaches, asked me
about when agile projects do design. I thought I would share my answer in case others were still wondering, and to try and explain where experience may have lead to us activities that are not textbook.
The short answer is ‘all the time’ and
‘just-in-time’. The long version is ‘all the time’ in that we are always
thinking about design during story gathering, planning etc. which is why you
want as many people on the team involved as possible. When we say ‘just in time’
we mean that we leave it to the ‘last responsible moment’. Of course the hard part is figuring
out when the ‘last responsible’ moment is. I like Alistair Cockburn’s model that the objective of any activity ins software development is to provide just enough for the next activity to take place. So we would tend to do just enough design to let us being development.
Being more concrete:
- Agile projects do
design through TDD, so called emergent design or incremental re-architecture. - XP supplements TDD with
pair programming, so at least two people design everything.
- XP recognizes that some
design needs to be all team, and has an optional CRC path, in each iteration,
for contentious design choices or complex problems.
- Crystal does not mandate pair-programming,
and scales to larger teams, so it has more ceremony. It’s not uncommon for a
crystal project to model the core domain model up front.
- Most agile teams
recognize that there is a nebulous conception or inception phase when you gather
user stories, organize and understand them, do just-enough modelling, set up
build servers etc. It is the great unspoken step of many agile
methodologies. - We care more about the
domain model when modeling than about the
infrastructure. Early on I would never tend to model the infrastructure. - Any ‘up-front’ modeling, before coding, is high-level, not low i.e. we care about classes, roles,
responsibilities, and collaborators, but not attributes, methods etc. I tend to
favour Rebecca Whirfs-Brock’s Responsibility Driven Design for this, and would
consider this her Exploratory Design phase. - The conversation is
more important than the artifacts the conversation produces. This is why CRC cards are great because the
artefact is less important than the design discussion among the team and running
the scenarios. You may produce a UML sketch of the system at the end, but it’s
just an aide-memoir to the discussions, not a blueprint. It is also why design
needs to be ‘all-play’. We don’t want to punt documents over the wall to
developers, we want them to be involved in the activity of design from the
beginning. That way the documents don’t inform, they just record the discussion.
That’s what a document is after all. - CRC cards also work well because they have feedback – running through scenarios. We tend to divide up the cards and throw a ball between participants as the system calls their classes act. That means you get some testing around your design as you do it.
- Remember that you are
looking for ENUF, just enough design to make the next step, development,
possible. If you end up throwing away too much of your initial design when you
get to coding you have created waste, which we are trying to avoid, so don’t
push this exploratory design step too far. Just do enough to answer the key
questions - Be proportional. If you
have ten user stories you may not need much of a conception phase. If you have
two hundred you may need more.
The N-Tier with LINQ posts almost finished so should be out in the next few days. There is really only one post in the series after that, then we will move on to looking at hard-to-test areas in TDD.
